Following ESIP, I came away with a clearer idea both on what types of demonstration software would be of interest to the OPeNDAP community, as well as how best to modify the OPeNDAP code base for our work.
Within the next week, we aim to finish a lightweight implementation of our interfaces for presenting records of provenance for OPeNDAP products, capable of exposing both OPeNDAP modules and their contributors.
In addition, through taking advantage of common design practices within the OPeNDAP code base, we have determined appropriate modifications to enable retrieval of content corresponding to our components schema:
https://docs.google.com/spreadsheet/ccc?key=0An84UEjofnaydFRrUF9YWk03Y3NHNjJqUEg0NUhUZXc&usp=drive_web#gid=0
Once offline versions of our demonstration are completed, we intend to port them to our OPeNDAP server at http://opendap.tw.rpi.edu.
A comment on our first pass at implementing provenance trace within the OPeNDAP Back-End Server (BES). We first were hoping that we would be able to provided a simple, dynamically loaded module that could generate the desired provenance trace for the data access request. Unfortunately, we determined that this after-the-fact approach was insufficient for what we wanted, so instead we came up with a new plan of action for providing in-process provenance tracing. This will require much more modification to the software framework. But, with that said, we determined that we could provide an abstraction for provenance, and that developers could implement modules that could provide specific representation of the provenance. Of course, our first module will implement the Prov-O representation of provenance (Provenance Ontology recommendation from W3C working group). But others could develop OPM or PML implementations of provenance. In a later blog post we supply the information model that we determined would best represent provenance capture within the BES.