W3C home > Mailing lists > Public > www-tag@w3.org > February 2011

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

From: Jonathan Rees <jar@creativecommons.org>
Date: Mon, 28 Feb 2011 11:31:01 -0500
Message-ID: <AANLkTim8j7aNsMmVmHLr28SeabHHyhgQRZM9Z7qHDm3U@mail.gmail.com>
To: www-tag@w3.org
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
  - 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

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.


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.


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.


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.


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?


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.


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:37 UTC