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

Re: resources and URIs

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Thu, 17 Jul 2003 13:19:52 +0300
Message-ID: <004401c34c4c$f9cd9090$020ca20a@NOE.Nokia.com>
To: "ext Dan Connolly" <connolly@w3.org>, "pat hayes" <phayes@ihmc.us>
Cc: <www-tag@w3.org>, "Pat Hayes" <phayes@ai.uwf.edu>

Pat Hayes said:

> >  Other examples abound,
> > eghttp://chandra.harvard.edu/photo/2003/ngc1068/index.html  is in
> > clearly about a galaxy containing a supermassive black hole, which is
> > also not something one would expect to find as part of an networked
> > information system, given the likely physical constraints on network
> > architecture. 

Dan Connoly said:

> I think that particular identifier refers to a document about
> a galaxy, not the galaxy itself; if you want to refer to
> the galaxy itself, you should use a URI with a # in it.


I wish folks would stop suggesting this approach
for several reasons:

1. Folks are already using URIs without fragIds to denote
   such resources and such usage is already prolific enough
   that an attempt to mandate its practice as "bad" is
   simply not going to succeed.

2. There are numerous practical problems with fragIds when
   it comes to implementing SW functionality on top of Web
   APIs since many clients and APIs strip off the fragID
   in various ways thus loosing the actual denotation of
   the resource in question by ending up with an entirely
   different URI (the base URI).

3. It is IMO contrary to the best practice of "don't peek 
   inside URIs". The structure of the URI should have no
   relation to its semantics, including the presence or
   absence of a fragId.

4. It introduces ambiguity when one wishes to actually refer
   to a structural/physical fragment of a resource such as
   an RDF/XML instance rather than some other resource denoted
   by the URIref with fragId. URIrefs with fragIds are an
   intuitive way to refer to structural components of an XML
   instance. The usage you propose precludes doing that in
   a convenient manner by usurping the meaning of any fragId
   to denote something other than the structural component
   it identifies in the instance.

It would be nice to see this idea let go.

> [folks with other opinions on httpRange-14 disagree,
> I believe.]

Let us hope they end up a majority.




Patrick Stickler
Nokia, Finland
Received on Thursday, 17 July 2003 06:20:04 UTC

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