How to move ISSUE-57 off the TAG's plate

Here is an idea to consider among the others. It is partly technical,
partly procedural. This does not directly
address ISSUE-57 and its implementation does not call for TAG development
of the baseline document, so it is not couched as a change proposal.
The implementation of this proposal does not have to use these words
or be in this form, I am just giving the gist.

- The TAG [should it agree to this proposal] recognizes that the
  referential use of hashless retrieval-enabled http: URIs (what they
  "identify") is not prescribed by any suitable standard.  It is
  agreed that such a URI can be used to refer to *something*,
  particularly in RDF, and there is overall consensus on the desire to
  nurture a global namespace (i.e. have any such URI be used to refer
  to pretty much the same thing wherever it is used to refer), but there is
  uncertainty as to how to bring this about.  RFC 2616 and HTTPbis do
  not shed any light on this question as, by design, they do not
  explain how to determine what an http: URI "identifies" or what
  constitutes an acceptable "representation" of something.

- The TAG recommends a very common extant practice, which is that
  hashless retrieval-enabled URIs be used to refer to a generic
  resource whose instances are retrieved using the URI.  [See for "instance of".]
  This allows these URIs to be used in a natural way in RDF, without
  any "opt in" based on what comes in either the headers or content of
  protocol responses.  The agent(s) providing the representations does
  not need to know anything about RDF or have to make any statement
  about what the URI "identifies" in order for a URI to be used in
  this way.

- The TAG recognizes that not everyone follows or will follow this
  recommendation - some will use these URIs for other purposes.  There
  are many reasons for this, including ignorance, error, and
  differing engineering judgment.  The preceding recommendation should be
  followed with extreme caution if it appears others might be using
  the URI in a different way, especially if common use of "opt out"
  markers emerges.

- For the purpose of dispelling uncertainty, i.e. to rule out other
  interpretations, use of the 'instanceURI' predicate is recommended.
  This predicate might be used in representations retrieved from the
  URI, or in other places when anyone wants to clarify that they are
  using the URI refer to its generic resource.  (See for details.)  The TAG
  will take on the responsibility for naming, documenting, and
  deploying the 'instanceURI' predicate.

- [optional] In response to ISSUE-57, the TAG recommends the use of
  hash URIs in order to avoid performance and difficulty of deployment
  issues related to the use of 303.  Use of hash URIs should also be
  easier to understand for those new to linked data, based on the
  "local identifier" narrative, and they avoid problems with URI
  substitution in the browser address bar.  We hope the use of the
  postfix "#it" or "#_" or "#" pattern for indirection will be
  promoted when it is called for, perhaps as an additional option in
  some future revision of "Cool URIs for the Semantic Web".

- The TAG recognizes that the semantic web / linked data community is
  the proper place for continuing consideration of this set of issues
  as they pertain to URI occurrences in RDF documents.
  If consideration of solutions to ISSUE-57 other than the one given
  above is a community priority, this should be taken up in a
  forum such as an RDF-related working group or a W3C community
  group, that involves those who have a stake in the matter.

- The above, together with the work of the HTTP WG on 303 responses to
  GET requests, supersedes the advice given in .

Received on Sunday, 25 March 2012 23:01:41 UTC