Talk:Discovery Change Proposal-2

Combined with incubator DCP from Matt Cechini -- Clynnes 10:22, 17 June 2011 (MDT)

We grafted the description from Matt Cechini's incubator DCP on OPeNDAP link_type with this DCP.

However, the namespace remains in opendap.org. This is chosen as a namespace because it is more authoritative than ESIP, i.e., the keepers of the DAP standard.

From telecon discussion of handling alternate service/data links in granule-level Discovery responses -- Hook 15:12, 9 August 2011 (MDT)

• See Discovery Telecon 2011-08-09 for meeting minutes on discussion.
• To continue discussion here and vote on the preferred approach.
• Possible ideas so far:

1. Original DCP-2 idea: rel attribute value of http://xml.opendap.org/ns/DAP/3.3#.
2. "rel" could be dereferencible URI. but is fragile.
3. Could leverage the fragment part of the URI
   1. e.g. http://esipfed.org/ns/discovery/1.1/data#DAP/3.3/
4. Use space-delimitation in "rel" URI
5. Define third attribute, with appropriate namespace.
   1. As long as using namespaced attribute, it does not break in the W3C Feed Validation Service.

Pros and Cons of proposal #2 for DCP-2 (dereferenceable URIs) -- Rozele 15:24, 9 August 2011 (MDT)

• Example: ... rel="http://esipfed.org/ns/discovery/1.1/resources#DAP_3.3" ...
  • http://esipfed.org/ns/discovery/1.1/resources#DAP_3.3 should be valid URL
  • Sample content:

 <?xml version="1.0" encoding="utf-8"?>
 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
        xmlns:esip="http://esipfed.org/ns/discovery/1.1/schema#"
        xmlns="http://esipfed.org/ns/discovery/1.1/resources#">
   <rdf:Description about="DAP_3.3">
     <rdf:type about="http://esipfed.org/ns/discovery/1.1/data" />
     <rdf:type about="http://esipfed.org/ns/discovery/1.1/schema#DAP" />
     <esip:DAP_version>3.3</esip:DAP_version>
   </rdf:Description>
 </rdf:RDF>

• • in the sample above...
    • http://esipfed.org/ns/discovery/1.1/data represents the generic type
    • http://esipfed.org/ns/discovery/1.1/schema#DAP represents the specific type
    • http://esipfed.org/ns/discovery/1.1/schema#DAP_version represents the property that gives the DAP version

• Positives of dereferenceable URIs
  • Keeps the specification simple in the sense that only two attributes are used (rel and type)
  • Capable of extended semantics (extensible beyond the current use cases)
• Negatives of dereferenceable URIs
  • We will need a specification (rather, vocabulary) for the content at the URI
  • Complicates feed readers by requiring (potentially many) dereferences of URIs
  • Breaks feed elements when host of URI is down

Pros and Cons of proposal #1 for DCP-2 ("http://xml.opendap.org/ns/DAP/3.3#" value for "rel" attribute) -- Clynnes 15:45, 9 August 2011 (MDT)

Pros

1. Simple and unambiguous
2. Instantaneously interpretable (no dereferencing needed)

Cons

1. Overloads "general-purpose" rel attribute with specific purpose

Example

<link rel="http://xml.opendap.org/ns/DAP/3.3#" href="http://disc2.nascom.nasa.gov/opendap/TRMM_3Hourly_3B42/2011/001/3B42.110101.12.6A.HDF.Z"/>

Pros and Cons of Proposal #3 (add DAP indicator as URI fragment) -- Clynnes 15:54, 9 August 2011 (MDT) -- Clynnes 15:54, 9 August 2011 (MDT)

Description

Keep the ESIP data indicator, but add the DAP identifier after "#" as a URL fragment. Note that slash '/' is allowed according to the RFC, but old browsers may gag on it.

Example

<link rel="http://esipfed.org/ns/discovery/1.1/data#DAP/3.3" href="http://disc2.nascom.nasa.gov/opendap/TRMM_3Hourly_3B42/2011/001/3B42.110101.12.6A.HDF.Z"/>

Pros

1. Simple and unambiguous
2. Instantaneously interpretable
3. Allows both general purpose (before hash) and specific purpose to coexist

Cons

1. Not exactly what fragment was intended for, i.e, return a piece of the full URI