Essentially, what this figure is expressing is that the data product CA_OrangeCo_2011_000402.nc.ascii<\/em> was derived from the file NC_File<\/em> through a process called Back-End Server (BES) process, or BES_Process.<\/em>\u00a0 In-turn, the Back-End Server runs by following a sequence of steps in BES_Plan<\/em>, each of which calls a particular OPeNDAP module and performs a specific function.<\/p>\n In our provenance record design, we assume that identifiers for specific versions<\/strong> of OPeNDAP modules will be referenced, and that various metadata about the modules (e.g., its function, who developed it) will be readily accessible.\u00a0 However, OPeNDAP’s current code base provides only limited support for obtaining either of these kinds of information.<\/p>\n 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.\u00a0 For each module file – two new functions will be added:<\/p>\n Based on these two functions, a third function – which can be called for any module – will then assemble URIs for any module instance desired.<\/p>\n Additional updates to OPeNDAP code base – capable of exposing additional module metadata – are still actively being discussed.\u00a0 More to come on this next week.<\/p>\n","protected":false},"excerpt":{"rendered":" Following last week\u2019s progress on front-end development, I\u2019ve now re-directed my focus toward some needed extensions for OPeNDAP\u2019s code base.\u00a0 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 Continue reading Week 8 Update<\/span>![\"OPeNDAP_Provenance\"](\"https:\/\/notebooks.dataone.org\/wp-content\/uploads\/2014\/08\/OPeNDAP_Provenance-177x300.png\")
<\/a><\/p>\n\n