Re: RDF & fragment ids; what breaks?

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 UTC