FindingResourceDescriptions

From W3C Wiki

Uniform Access to Links and Properties

Update 2011-03-04: Please see RFC 5988 Web Linking and New opportunities for linked data nose-following, which seem to provide the current best answer to the question.

Summary document based on this wiki page, written for the TAG http://www.w3.org/2001/tag/doc/uniform-access.html

This is a bibliographic summary of the thread started by Stuart Williams on www-tag here. Page title changed 2/29/08 following a suggestion of Henry Thompson, and again on 4/29/08 to recognize that the scope is broader than just descriptions.

The subject is a proposal to standardize on a way to obtain information (links and properties) about a thing using the thing's URI. (When the thing is a document the information is called "metadata".) The information we have in mind comes not from an arbitrary source but is associated with the administrator of the URI. One way to do this is by communicating the location of such a description in an HTTP response via the addition of a new GET response header; another is to invent a new HTTP request method for this purpose. Descriptions might include information about the thing such as bibliographic metadata, factual information, reviews or assessments, related materials, access control or licensing information, etc.

A thing may have many descriptions in many places, but the one of interest here is one that is provided by the entity that is responsible for the thing's URI. For documents (especially changing ones), one might expect such a description to be able to say things about the document that its available representations cannot.

"Thing" is jargon used to permit semantic web use cases where the URI doesn't name a document. If you prefer you may forget about this use case and just say "resource".

The issue seems to be in the scope of the POWDER WG. The subject was taken up by the TAG on 22 February 2008 (no minutes posted as of 8 April).

This is related to ISSUE-57, HttpRedirections-57. It is not a rehash of httpRange-14 as it pertains uniformly to IRs and non-IRs.

An excellent summary, created independently, can be found here: http://www.hueniverse.com/hueniverse/2008/09/discovery-and-h.html

Use cases

N.b. http://www.w3.org/2005/ajar/tab Tabulator] implements the Link: header (with rel=meta)

Solutions

The Link: HTTP header

Other HTTP headers discussion

303 asymmetry discussion

Other ways of getting a description through HTTP

  • One observer says the approach of returning description (metadata) in an HTTP response header is "egregious" - "this isn't what GET is for"
  • URIQA, Patrick Stickler, Nokia, proposes an MGET HTTP method
  • WEBDAV PROPFIND ?
  • RDDL ?
  • A suggestion of Alan Ruttenberg - /about/
  • ARK - append '?' to the URI to get URI of 'a brief metadata record'
  • Find content via metadata - URI1 leads (via #-truncation or a 303 redirect) to an RDF document with URI URI2. The RDF document contains metadata along with a triple asserting that the bits for the content named by URI1 can be found by dereferencing URI3.
  • Use content negotiation. If you ask for RDF, you get the description. If you ask for something else, you get the thing described. (The TAG, TimBL, and others have pointed out that this contradicts web architecture, which requires that content negotiation choose among things that all carry the same information. That goes for CN between RDF and HTML as much as it does for CN between GIF and JPEG.)
  • Use a multipart response, with description in one part and the intended payload in another
  • Link: headers are hard to parse. How about distinct header types for each link type? Brian Smith to ietf-http-wg
  • voiD allows to describe linked datasets and their interlinking incl. examples, SPARQL endpoints, etc.

Precedent set by other protocols

Issues

  • Is it appropriate to use HTTP headers in this way? Will all servers and clients that ought to be able to use this mechanism be willing and able to? Is this an appropriate use of HTTP headers at all?
  • What can we do to help ensure that clients understand which information (description) is about the resource itself (if an IR, then invariant across time and independent of choice of language and media type) and which information is specific to that particular response (awww:representation, if an IR)?
  • Is uniform access desirable, appropriate, necessary?
  • Should we encourage a mechanism that allows description/metadata/links to be separated from the content? (Consider copyright and licensing information, which needs to stay as close as possible to the content.)
  • Should clients even expect to be able to get this kind of information from the server specified by the URI, or should we set the expectation that independent catalogs and aggregators have to be consulted?

See also

Retrieved from "https://www.w3.org/wiki/index.php?title=FindingResourceDescriptions&oldid=48431"