W3C home > Mailing lists > Public > www-tag@w3.org > January 2003

Re: RDF & fragment ids; what breaks?

From: Jonathan Borden <jonathan@openhealth.org>
Date: Thu, 23 Jan 2003 23:23:05 -0500
Message-ID: <0ae301c2c360$4ab81550$7c01a8c0@ne.mediaone.net>
To: "Mark Baker" <distobj@acm.org>
Cc: <www-tag@w3.org>

Mark Baker wrote:

>
> If an HTTP client is told that "http://example.org/foo#bar" identifies
> a resource of interest to it, and attempts to dereference that URIref,
> "#bar" isn't part of that HTTP GET message that gets sent.  By
> *definition*, other HTTP components have less visibility into the
> meaning of the message than the client.
>
> > But it's absolutely not legitimate to insist that that mindset or
> > methodology is the only way of obtaining that useful property, or to
> > insist that it's privileged to the exclusion of all else. That _does_
> > break things (in this case RDF), at least politically, by effectively
> > ruling out other equally useful approaches.
>
> As I see it, in order to recover this lost visibility, one of two things
> would need to occur.  Either RDF/SW have to start identifying things
> without fragment ids, or we need to deploy some means of introducing the
> fragment id into the HTTP message envelope (Request-URI -> Request-URIref,
> an extension header, etc..).  As Tim Bray correctly (IMO) pointed out,
> it's a whole lot easier to do the former than the latter at this point
> in time.

From an entirely practical point of view, it is convenient to package an
ontology in a document referenced by a URI and each class definition that
forms the ontology as named objects in the document. A URI reference is an
excellent mechanism to name such classes.

Theoretical arguments aside it just wouldn;t be convenient to package each
and every thing we talk about in a different document.

Jonathan
Received on Thursday, 23 January 2003 23:45:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:15 GMT