Re: [rdfmsQnameUriMapping-6] Algorithm for creating a URI from a QName in RDF Model?

Sorry the delay, I've been really busy.

On Thu, May 23, 2002 at 06:46:35PM +0100, Graham Klyne wrote:
> Er, you're right.  This will be very sketchy:

Thanks!  Sketchy is fine.

> 1. The interpretation of a fragment identifier depends on the MIME type of 
> the representation it's applied to.

Right.

> 
> 2. URIs without fragment identifiers are generally presumed to map to some 
> resource for which a Web representation (or several) can be retrieved.

Ok.

> 
> 3. RDF uses URI-references to denote things that aren't necessarily 
> web-retrievable.

See below.

> I think so far is pretty standard stuff.
> 
> The difficulty with someurl#frag in RDF arises when you say that this is 
> interpreted by:
> (a) dereferencing 'someurl'.
> (b) interpreting #frag according to what you get back.
> This doesn't work well for RDF, because different MIME types can be 
> returned, with different interpretations of the fragment identifier, where 
> RDF requires that a URI ref have just one denotation under any given 
> interpretation.
> 
> So my approach for interpreting someurl#frag (and this is largely inspired 
> by comments from TimBL and Pat Hayes, though any errors are of course all 
> mine) is this:
> 
> (A) *assume* that 'someurl' indicates a resource which has an RDF 
> representation.  (If it's not dereferencable as such on the web, so be it, 
> but I must assume its notional existence)

Ok.

> (B) when used in an rdf document, 'someurl#frag' means the thing that is 
> indicated, according to the rules of application/rdf+xml mime type as a 
> "fragment" or "view" of the RDF document at 'someurl'.  If the document 
> doesn't exist, or can't be retrieved, then exactly what that view may be is 
> somewhat undetermined, but that doesn't stop us from using RDF to say 
> things about it.

Ok.

> (C) the RDF interpretation of a fragment identifier allows it to indicate a 
> thing that is entirely external to the document, or even to the "shared 
> information space" known as the Web.  That is, it can be an abstract idea, 
> like my cat or DanC's car.

But being external to the Web is a bad thing, no?  "Any important resource
should have a URI", etc..  And URIs can already identify abstract things,
as 2396 says;

"A Uniform Resource Identifier (URI) is a compact string of characters
for identifying an abstract or physical resource."

Using frag-ids doesn't add any value here IMO.

> (D) So any RDF document acts as an intermediary between web retrieval 
> documents (itself, at least, and also any other web-retrievable URIs that 
> it may use, including schema and references to other RDF documents) and 
> some set of abstract or non-Web entities that it may describe.
> 
> That's it.  I think it's consistent with all the conventional web axioms, 
> but it also provides an handling of URIrefs and their denotation that is 
> consistent with the RDF model theory and usage.  The "stretch", if there is 
> one, is that it somewhat extends the idea of a "fragment" or "view" beyond 
> the conventional idea that it's a physical part of a containing document.
> 
> If you accept this, then it becomes natural to take a view that URIs 
> without fragment identifiers _should_ be reserved for indicating 
> web-retrievable resources (when used in RDF), which is something TimBL has 
> promoted.  This goes against quite a lot of actual RDF usage (mine 
> included) so I don't think we can be too strict about that, but it seems a 
> reasonable principle to aim for.
> 
> It also suggests a possible answer to the question about the web and 
> URIs.  It is sometimes claimed that to be on the web means to have a 
> URI.  So are people and cats and dogs and cars "on the web"?

I am, at http://www.markbaker.ca.  I don't know about other people,
you'll have to ask them.

>  If I clarify 
> the definition of "on the web" to not include things that have URI 
> references, then the answer to that question can be "no".  But using RDF, 
> we are still free to talk about these things without actually having to 
> claim that they are "on the web", by using URI-references rather than "1st 
> class" URIs.

I think that severely cripples the Web, suggesting it only be used for
those things for which the resource and its representation are the same
thing (my interpretation of TimBL's "document" view).

The resource/representation dichotomy is at the essence of the
universality of the Web.  Not all things can be retrieved over a
network (my dog, for example), but all digital representations of things
can (pictures of my dog).  As GET means "GET me a representation of the
thing identified by the URI", this permits the Web to encompass all
things with identity, not just documents.

I know this opens up that whole cars/hills/documents discussion again,
and I didn't want to go into it.  I just wanted to point out how my
view of that issue relates to my view on this issue.  Not all of the
URIs-can-identify-anything folks see this the same way though; DanC
thinks that an HTTP URI can identify his car, but he likes fragids.
Go figure. 8-)

In the long run, I expect the fact that Web servers (and therefore apps)
don't get the fragment id, will decide this issue.  We've already seen
some of this in Dublin Core's use of namespaces, for example, since
they use purl to redirect, but you can't redirect with a fragid.
There's going to be a lot of pain in RDF land when people start
integrating it with HTTP, because of this.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Tuesday, 28 May 2002 16:03:30 UTC