Review of TAG issues related to "URI meaning" (long)

Review of TAG issues related to "URI meaning" (cf. ACTION-532; I was
inspired to write this by Larry's comments during the 2011-02-24 telcon)

Keep in mind that there are many communication channels open for
influencing how and when URIs are generated and interpreted (what they
"mean"):
  - RFC 3986
  - URI scheme specifications
  - the lexical content of the URI itself (e.g. data:)
  - Web dereference (e.g. HTTP GET)
  - namespace and/or idiosyncratic documentation (RDF, prose) deployed
    in various ways (hash, 303, .well-known)
  - how they are used (e.g. @href)
  - word of mouth
and so on.  Some channels are "normative", others aren't.  Often more
than one channel applies, in which case a meaning might be inferred by
combining information obtained from multiple sources.

9  uriMediaType (closed)
        To me this appears to be a special case of ISSUE-50, for which see
        below.

14 httpRange (closed)
 This issue is mistitled "what is the range of the HTTP
        dereference function".  The answer to that was already known
        ("representations") and in any case the question is not what
        anyone asked.  The resolution of the issue had two parts.  The
        200 clause arbitrates between competing claims over the use of
        resolvable http: URIs - they are better used for documents, not
        cars. The 303 clause offers an answer to the question, given
        that 200 is unavailable and # is ruled out (for reasons I'm
        not clear on), of how to choose a URI to refer a car and
 deploy documentation that communicates this intent.

 As part of my AWWSW 'task force' work I've been struggling to
 articulate clearly the value proposition for reserving
 dereferenceable URIs to refer to the documents they
 dereference to, and I believe I've made some progress on this.

31 metadataInURI (open)
 Under what circumstances can/should one impute meaning to
 parts of URIs?  The answer is that it might be OK to infer
 meaning from the URI's lexical form, but only if there has
 been prior coordination.

 The issue was reopened to clarify whether the finding ought to
 discourage URI-based CSRF defenses or stay out of their way.

 http://www.w3.org/2001/tag/doc/metaDataInURI-31.html

36 siteData (closed)
        This issue was closed (IIRC) with the publication of RFC 5988, which
        covers both the /.well-known/ URI space and the Link: header.

 RFC 5988 takes a portion of every http: authority's URI space
        by eminent domain, so those URIs are supposed to get their
        meaning from documents linked from an IANA registry, not in
        the usual way.  This sets a very interesting precedent and
        presents unknown opportunities.
 
        In addition, /.well-known/host-meta (expired draft?) has been
        suggested (by me, I think) as a way for a host to communicate
        re the intended meaning of its own URIs.  This nose-following
        method is superior to 303 or Link: because it requires fewer
        round trips.

 http://tools.ietf.org/html/draft-hammer-hostmeta-13
 http://www.w3.org/QA/2010/07/new_opportunities_for_linked_d.html

39 rdfURImeaning (open)
 I'm not sure I get this one, but it seems like it relates to
 the extent of "authority" of "URI owners", the question of
 "web closure" for RDF, how to deal with risks associated with
 information (RDF) coming from untrusted or unstable sources,
 and so on. This precipitated a long and interesting discussion
 that fizzled out inconclusively around 2004.  The discussion
 reminds me of recent TAG discussion of versioned
 specifications and specification/practice divergence.

 http://lists.w3.org/Archives/Public/public-sw-meaning/

49 schemeProtocols (open)
        This asks about ways in which meaning of a URI in one context
 relates, if at all, to use in others - that is, to what extent
 URI meaning is (in)dependent of URI scheme and/or
        protocol. Dormant since Noah's last finding draft in 2005.

 http://www.w3.org/2001/tag/doc/SchemeProtocols.html

50 URNsAndRegistries (open)
        This asks the question, when you want to import a
 namespace into URI space, or establish a new one there, what
 are the pros and cons of doing so in the http: region of the
        URI space?

 http://www.w3.org/2001/tag/doc/justSayHTTP

51 selfDescribingWeb (closed)
        This is a plea to make meaning-coordinating documents
 discoverable, so that these documents can be more effective at
 coordinating communication between agents. It describes how,
 in theory at least, the Web acts as a giant prescriptive
 dictionary for URI meaning. There is an interesting figure at
 the end of the corresponding finding that contains much
 intriguing material not explained in the text.

 http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html

57 HttpRedirections (open)
 This issue has been a bit of a hodgepodge. It has its origins in
 email from Giovanni Tumarello expressing problems experienced
 with using the HTTP 303 as a way to give meaning to individual
 URIs, so the issue of "URI meaning" is clearly central to it.
 It's unfortunate that the issue is described in terms of the
 solution space (HTTP redirections) instead of the problem
 (choosing URIs for things, and deploying information about the
 association that is findable by nose-following).

62 UniformAccessToMetadata (open)
        Since metadata and URI meaning interact in a confusing way,
 this issue centers on the part of the "URI meaning" problem
 that is concerned with documents (not all URIs are).  That is,
        a URI that you can dereference is useful as far as it goes,
        but it has more "meaning" if you have more information
        available than what you find in its representations.  For
        example, knowing stability and provenance both help the URI to
        be more "meaningful".

 Issues 57 and 62 are really just two cases of the same
 problem, how to tell people what you want a URI to mean.

63 metadataArchitecture (open)
 This issue is not specifically about URIs, and certainly
 doesn't cover all semantic web use cases.  However, this topic
 naturally touch on how URIs are used to obtain metadata
 subjects (data) and the use and interpretation of URIs
 occurring in metadata encoded in formats that use them.

 This seems more like a product than an issue to me, but I
 guess we have to have an issue because tracker only associates
 email and tracker comments with issues, not products?

Received on Monday, 28 February 2011 16:33:02 UTC