W3C home > Mailing lists > Public > www-rdf-interest@w3.org > May 2001

Re: Another fragment issue

From: Pierre-Antoine CHAMPIN <champin@bat710.univ-lyon1.fr>
Date: 21 May 2001 14:22:03 +0200
To: Sean "B." Palmer <sean@mysterylights.com>
Cc: (wrong string) érôme Euzenat <Jerome.Euzenat@inria.fr>
Message-Id: <990447725.1110.1.camel@lisiperso3>
On 18 May 2001 15:58:23 +0100, Sean B. Palmer wrote:
> > Some document in DI claims that there is no fundamental
> > difference btw URIs and URI refs. [...]
> 
> Hmm... maybe you're reading a totally different set of TimBL's
> DesignIssues to me.

It's a shame I don't find it now, but I really thought I read that one
day :)
It surprised me just as much as you, however.

> How could there be no fundamental difference
> between URIs and URI refs? The complication (annoyance) is that in
> RDF, a "resource" can be identified by a URI or a URI-Ref, whereas in
> the URI RFC, a resource is what's identified by a URI, and a URI-Ref
> is a "view" of that resource. It was a bit foolish to reuse the same
> word for a different concept.

I'm not sure the concept of resource is different between URI and RDF.
According to the document you quote below, its is just that RDF uses
URIs in a strange way :

although URIs were first used to locate digital documents,
it seems that with the SW, they vill be used to identify virtually
anything with an identity.
Indeed, any kind of URI scheme could be imagined to do so

  http://www.w3.org/    : a generic digital document
  urn:isbn:123456       : a published document
  urn:wordnet:freedom/1 : freedom according to WordNet (def #1)

Instead, most RDF'ers seem to prefer identifying non-HTTP resources with rdf:ID, like

  http://www.isbn.org/numbers#123456
  http://www.wordnet.org/definitions#freedom-1

which can be read as "what ISBN calls 123456" and "what WordNet calls freedom-1".
This makes any URI scheme other than HTTP useless,
since RDF can be transported over HTTP.
Not a bad idea indeed.


However, there is the fragment issue :
although http://www.isbn.org/numbers is supposed to be (possibly) generic,
the use of the fragment makes it bound to have an RDF content.

More embarassing,
this makes talking about isbn:123456 or freedom dependant:
- on RDF, which may very well evolve over time
- on HTTP, which may also evolve over time
- on retrieval processes

  Pierre-Antoine

> Still, according to TimBL (as far as I can tell from DesignIssues) in
> HTTP, a URI identifies some material "suitable for HyperText
> transfer", but not some kind of generic concept. Some people disagree
> with this (Sandro?), stating that "the homepage of Dan" can also be
> used to represent Dan himself, as long as the two aren't muddled...
> but it's murky ground.
> 
> Anyway, I think that the following is quite explicit:-
> 
> [[[
> It is important, on the Semantic Web, to be clear about what is
> identified. An http: URI (without fragment identifier) necessarily
> identifies a generic document. This is because the HTTP server
> response about a URI can deleiver a rendition of (or location of, or
> apologies for) a document which is identified by the URI requested. A
> client which understands the http: protocol can immediately conclude
> that the fragementid-less URI is a generic document. This is true even
> if the publisher (owner of the DNS name) has decided not to run a
> server. Even if it just records the fact that the document is not
> available online, still a client knows it refers to a document. This
> means that identifiers for arbitrary RDF concepts should have fragment
> identifiers. This in term means that RDF namespaces should end with
> "#".
> ]]] - http://www.w3.org/DesignIssues/Fragment
> 
> Because "resources" in RDF covers URI-Refs as well, I normally use
> namespaces with a "#" on the end just to be safe. It's easier for
> maintainance purposes that way as well (although not always).
> 
> --
> Kindest Regards,
> Sean B. Palmer
> @prefix : <http://webns.net/roughterms/> .
> :Sean :hasHomepage <http://purl.org/net/sbp/> .
> 
> 
Received on Monday, 21 May 2001 08:21:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:49 GMT