Re: HTTP, URIrefs and resources not "on the web"

(Patrick, this response is delayed because I was waiting for permission to 
post some off-list messages from Pat Hayes to WWW-Archive)

At 11:42 AM 5/27/02 +0300, Patrick Stickler wrote:
>On 2002-05-23 20:46, "ext Graham Klyne" <GK@ninebynine.org> wrote:

[...]

> > Er, you're right.  This will be very sketchy:
> >
> > 1. The interpretation of a fragment identifier depends on the MIME type of
> > the representation it's applied to.
> >
> > 2. URIs without fragment identifiers are generally presumed to map to some
> > resource for which a Web representation (or several) can be retrieved.
> >
> > 3. RDF uses URI-references to denote things that aren't necessarily
> > web-retrievable.
> >
> > 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)
> >
> > (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.
> >
> > (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.
> >
> > (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"?  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.
>
>All in all I can accept this point of view as reasonable and workable,
>with two exceptions or caveats (and I appreciate that your comments
>were offered off-the-cuff and quickly -- so feel free not to respond
>if any of the following is off the mark from your actual views):

Thanks!

>1. I wouldn't presume to require every uriref someuri#frag
>that is used to denote a resource in RDF to require that
>someuri resolve to a representation of an RDF instance.

Thus far, I agree.  That's what I tried to say.

>  The
>real requirement is simply that it consistently resolve to
>an instance of the same MIME type such that the fragment
>identifier has a consistent interpretation in all cases.
>Yes, that's more difficult to determine/ensure, but that's
>really what the true requirement distills down to, I think.

My point here was that when used within RDF, the #fragid would be presumed 
to be interpreted as if with respect to the RDF MIME type -- I think that's 
needed for consistency within RDF.  If there's also an 
application/mydatatype with its own interpretation of fragments, there's no 
reason that a particular use of RDF shouldn't align its use of fragments 
accordingly.

Example:  an HTML document http://www.example.org/doc may contain chapters 
written by different authors.  An RDF document can still make statements like:

   <http://www.example.org/doc#chap1> dc:author "First author" .
   <http://www.example.org/doc#chap2> dc:author "Second author" .

etc.  This usage presumes the (possible or notional) existence of an RDF 
document representing the same resource, in which statements about the 
fragments are made accordingly; e.g.

   <http://www.example.org/doc#chap1> ex:isPartOf 
<http://www.example.org/doc> .
   <http://www.example.org/doc#chap2> ex:isPartOf 
<http://www.example.org/doc> .

(for some appropriate interpretation of ex:isPartOf).

See also some comments by Pat Hayes (from a private exchange, posted to 
www-archive with permission):
- http://lists.w3.org/Archives/Public/www-archive/2002May/0018.html
- http://lists.w3.org/Archives/Public/www-archive/2002May/0019.html
- http://lists.w3.org/Archives/Public/www-archive/2002May/0020.html
and also:
- http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Feb/0494.html


>2. I'm not comfortable with the very last comment, which seems to suggest
>that "1st class" URIs would not be used to denote things which are not
>"on the web". Whether you have foo://bar#cat or foo://bar/cat in no
>way determines whether the thing is "on the web" and a representation
>of it is obtainable. This is perhaps the primary point of friction
>between the needs of "traditional" web applications which are concerned
>with stuff that is web accessible, and newer semantic web applications
>which, in addition to being concerned with stuff that is web accessible,
>is also concerned with alot of stuff that is not web accessible, either
>because it's not digital, or because it is abstract.

My comments about "on the web" were definitely half-baked.

Yes, current usage does rather go against this.  There is an issue to be 
squared here:  if a URI <foo://bar/cat> is used to describe an abstract 
concept, and subsequently a document is put on the web at that URL, how are 
these related?  What does the URL refer to?

I'm afraid I just don't buy your proposals about URI taxonomies or 
additional mechanisms here.  (By which, I mean that I don't accept them as 
universal proposals:  I have no argument with their use as a convenient 
mechanism by you or any other developers.  But I think it must also be 
allowable to strip any URI down to the minimalist purpose of identifying a 
resource, without any extra baggage or assumption about what is identified 
based on the form of URI.)

#g


-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Wednesday, 29 May 2002 08:21:49 UTC