Following last week’s progress on front-end development, I’ve now re-directed my focus toward some needed extensions for OPeNDAP’s code base. To highlight what changes are needed, some background on our provenance designs will be helpful.
Based on discussions throughout the summer, our group has settled on a provenance record design following this pattern (for those unfamiliar with RDF’s Turtle syntax, click here):
Essentially, what this figure is expressing is that the data product CA_OrangeCo_2011_000402.nc.ascii was derived from the file NC_File through a process called Back-End Server (BES) process, or BES_Process. In-turn, the Back-End Server runs by following a sequence of steps in BES_Plan, each of which calls a particular OPeNDAP module and performs a specific function.
In our provenance record design, we assume that identifiers for specific versions of OPeNDAP modules will be referenced, and that various metadata about the modules (e.g., its function, who developed it) will be readily accessible. However, OPeNDAP’s current code base provides only limited support for obtaining either of these kinds of information.
One step I am be taking to help resolve this issue is develop a lightweight extension to the code for a set of OPeNDAP modules, capable of returning URIs for specific module versions. For each module file – two new functions will be added:
- Get_Version: Returns the software version hard-coded into the module.
- Get_Name: Returns the module name.
Based on these two functions, a third function – which can be called for any module – will then assemble URIs for any module instance desired.
Additional updates to OPeNDAP code base – capable of exposing additional module metadata – are still actively being discussed. More to come on this next week.
James and I worked closely with two of the people who participated in the W3C Prov recommendation on developing the information model to be generated by the OPeNDAP Back-End Server (BES). Stephan Zednik and Tim Lebo were a huge part in developing the W3C Prov Recommendation, and their feedback has been invaluable. And this project, providing provenance in the OPeNDAP software framework, has also provided some key work in support of the recommendation, flushing out some implementation details that had been thought of during the process, but not yet developed. Specifically, the use of prov:Plan concept in the recommendation and the ping-back service.
We are very happy with the work so far, with a lot to move forward with.