Determine opendap [minimal] configuration to dump request handling provenance

[timrdf]

Our prizms instance is set up so that any file that shows up at /home/prizms/prizms/opendap/data/source/us/opendap-prov/version/<UUID>/source/opendap-provenance.ttl will end up in a named graph at http://opendap.tw.rpi.edu/sparql.

The OPeNDAP pipeline provenance capture widget-a-ma-thing (#25) needs to be configured to such that:

• It creates REQUEST-UUID in format <YYYYMMdd>-<epoch-seconds>-<4-char-uuid> to identify each request.
• Uses "abstract dataset path" e.g. $PROV_PATH=/home/prizms/prizms/opendap/data/source/us/opendap-prov and writes its provenance record for each request at $PROV_PATH/version/<REQUEST-UUID>/source/opendap-provenance.ttl
• The provenance capture widget may also write the response at e.g. source/opendap-response.nc.
• It returns the following HTTP Response Headers.

Link: <http://opendap.tw.rpi.edu/source/us/dataset/opendap-prov/version/20140121-1390404237-df2b>;
  rel="http://www.w3.org/ns/prov#has_provenance";
  anchor="http://opendap.tw.rpi.edu/source/us/dataset/opendap-prov/version/20140121-1390404237-df2b/response"
Link: <http://opendap.tw.rpi.edu/prov-pingback/20140121-1390404237-df2b/$p3c1a7-S@uc3>;
  rel="http://www.w3.org/ns/prov#pingback";

(Note that $p3c1a7-S@uc3 never appears in the provenance record that OPeNDAP writes (opendap-provenance.ttl) nor as linked data. This is a special response-specific key that is only ever exposed within the HTTP response header. This is done to provide a [possibly weak] authentication mechanism to the http://opendap.tw.rpi.edu/prov-pingback service. The key can be omitted in the first iteration, since it requires additional support to store the request-uuid, special cause pairs (e.g. 20140121-1390404237-df2b, $p3c1a7-S@uc3). For now, just always use the value $p3c1a7-S@uc3.)

We want the opendap configuration to suit uses beyond the SDV Organization design that we're adopting, and we want as much overlap as possible between those uses and the one we chose using SDV Organization.

We discussed BES and module configuration on 2014-Jan-21, so we need to design the configuration to suit that. For examples, we need new variables like BES.LogName and BES.Catalog.catalog.RootDirectory.

[timrdf]

I set our prov_module configuration per the new documentation for it:

/opt/opendap/branch/etc/bes/modules$ grep ^Prov prov.conf 
Prov.cr_base_uri=http://opendap.tw.rpi.edu
Prov.cr_data_root=/home/prizms/prizms/opendap/data/source
Prov.cr_source_id=us
Prov.cr_dataset_id=opendap-prov

And stubbed in pseudocode for its implementation

The pseudocode needs to be implemented, built, and OPeNDAP restarted.

This ticket can be closed after @mrpatrickwest reviews and approves its design.

[mrpatrickwest]

in bes/dap directory there's BESDapTransmitter.cc. This uses libdap/mime_util.cc functions to set the mime headers. And there's no way to pass in additional response header information. SUCK. So, we can re-write the functions in the BES or we can make the changes necessary to allow for additional header information to be passed, like a key/value(s) map passed in to the functions with additional header information.

There's also code in BESUtil.cc that writes out the mime information. Not sure why they didn't use that. So we could modify that code instead and have BESDapTransmitter.cc use BESUtil instead of mime_util.

Thoughts?