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.