Goal:
Given any persistent identifier for a data publication, be able to retrieve all of the available metadata for it without customization for the identifier scheme or source
General Approach:
Combine one or more of the following approaches: common convention to get metadata based on existing resolution mechanisms, provide a (pluggable) resolution service, and/or provide a (pluggable) resolution library
For any of these, we need to define the syntax of what is returned (the following assume json-ld as a basic format, but feel free to propose others)
Common Convention Options:
1) HTTP Accept Header:
Summary: Given an id, resolve it using current mechanism, use an Accept:application/json-ld header to retrieve metadata
Example: 10.5967/M0NP22DZ is a DOI, http://doi.org/10.5967/M0NP22DZ can be accessed and will redirect to a URL such as http://example.org/publications/123456 which would usually show a landing page for that publication. Making an HTTP GET call to that same URL with an Accept: "application/json-ld" header could provide the metadata instead.
Pros:
Consistent with the idea that web calls retrieve different representations of things, with landing pages and metadata being two types of representation for the underlying data publication
Easy to support with most web service libraries, does not add a new URL
~Consistent with the approach used with DOIs (see http://citation.crosscite.org/docs.html)
Cons
Not directly accessible in a browser (where metadata in a json format could be pretty-printed)
Possible that Accept application/json-ld is already in use in some systems relevant in NDS?
Possible to confuse with the DOI mechanism (requesting a non-html type directly on a DOI returns metadata from CrossRef, using the accept header on the redirected URL gives the metadata proposed here)
2) <id>/metadata
Summary: Add /metadata to the landing page URL and return json-ld metadata there
Example doi:10.5967/M0NP22DZ is a DOI, http://doi.org/10.5967/M0NP22DZ can be accessed and will redirect to a URL such as http://example.org/publications/123456. http://example.org/publications/123456/metadata would return the metadata
Pros:
Simple, visible
~RESTful
Cons:
A purely human/NDS convention - unlike using accept headers, there's no web protocol reason to infer/assume that a <url> and <url>/metadata are related.
3) Cool URI patterns:
Summary: The general concept of CoolURIs can be found in: CoolURIs for the Semantic Web. In addition to advocating for HTTP URIs to be used as persistent references, the CoolURI document describes practices that enable one to navigate from a URI representing a thing (such as a person) and a description (e.g a webpage about the person) and to enable navigation to descriptions intended for human and machine reading. Of the 3 practices outlined in section 4, it looks like option 4.3 is most relevant to our use case: using a 303 redirect with content negotiation. In this practice, a URI for the dataset could be called with an HTTP Accept header for "text/html" or "application/json" (for example) and the response would be an HTTP 303 redirect to URIs for the data's landing page or a json/json-ld metadata document. This is similar to option 1, adding the idea of a 303 step. It could potentially be seen as a hybrid of options 1 and 2 - the 303 redirects could go to URIs related to the oroginal as in option 2. The CoolURI document mentions conventions such as having a .../landing.html and .../landing.jsonld URIs for the human and machine readable forms, or having .../data/<id> and .../metadata/<id> URIs (making anologies to the people examples in sections 4.2 and 4.3).
4) http://nds.org/resolve/<id>:
Summary: Given an id, URL encode it and send it to a service
Example: doi:10.5967/M0NP22DZ is a DOI, http://doi.org/10.5967/M0NP22DZ is a DOI specific resolver that will redirect to a URL. NDS, or other entity could run a service that would accept http://nds.org/resolve/doi%3A10.5967%2FM0NP22DZ and/or http://nds.org/resolve/http%3A%2F%2Fdoi.org%2F10.5967%2FM0NP22DZ and only return metadata (one option) or resolve to the landing page or, with an Accept:application/json-ld header, the metadata (a second option, combining the convention above with a service), or similar options. The service would use software specific to the identifier type (e.g. DOI, Handle, etc.) and/or repository/landingpage provider (e.g. Globus, Dataverse, SEAD)
Pros:
Works with any scheme/source as long as someone writes the code for that id type/source
Can be run as a service by any org (authoritatively by NDS or SHARE, or as a local service by any project)
Cons
URLs are ugly
Should service redirect if/when possible or always forward the requested content?
Library Options:
Propose something concrete! Should address language? extensibility mechanism? consistency with service approach?
Proposed Solution:
1) Metadata Retrieval
To be compliant with this specification, repositories must implement the ability to respond to HTTP Accept headers for the landing page they provide for data publication identifiers they mint. At a minimum, a "text/html" header should return human radable content about the data publication and an "application/json-ld" header should return a JSON-LD formatted document that includes all known metadata about the data publication. Repositories may respond with a 303 redirect rather than serving this content directly from the landing page URL. Repositories may also respond to other accept headers to provide metadata in other formats (e.g. RDF/Turtle, XML, etc.). Repositories are encouraged to adopt good practices in creating landing URLs, such as those in the CoolURI proposal (see above).
To access metadata given a persistent identifier, clients should resolve the identifier to a landing page URL via the persistent identifier type-specific resolver mechanism (e.g. using doi.org for DOIs), and the request that URL with an "application/json-ld" Accept header. The client should be prepared to follow a 303 redirect response from the server.
Agreement:
Issues/Concerns: