Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

...

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

...

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: