Re: [URI vs. URIViews] draft-frags-borden-00.txt

>Pat Hayes wrote:
>
>>  >
>>  >What is a "subresource" of Unicorn:
>>  >
>>  >suppose the URI http://example.org/Unicorn which identifies the resource
>>  >Unicorn
>>  >the URI reference http://example.org/Unicorn#LeftButtock identifies the
>>  >"subresource"
>>
>>  ****
>>  OK, but that isn't the way RDF uses frags. A fragId doesn't indicate
>>  a mereological part, like a buttock or a kidney; it identifies a
>>  piece of text in an RDF *document*.
>
>Careful, RDF uses frags in two ways:
>
>1) as you say
>2) any subject,predicate or object of any statement may be identified by a
>URI reference.

May BE a uriref, actually; but OK.

>Such URI references may have a fragment id.

Sure, but what that *means* is not specified. It could well be 
meaningless. RDF syntax allows arbitrary urirefs to occur - it 
provides no constraints forbidding any URI combinations as illegal or 
ill-formed -  but RDF provides no semantic guarantees that any such 
usage is meaningful. In particular, the one you provide seems 
nonsensical to me:

>e.g.
>
><http://example.org/Unicorn#Bottock> rdf:type foo:Bar
><http://example.org/Unicorn> rdf:type foo:Unicorn
>
>does not imply any relationship between foo:Bar and foo:Unicorn

Agreed; precisely my point. BUt the reason why it does not, is that 
there is no implied relationship between those two urirefs, either, 
other than that the *very use* of the first one implicitly assumes 
that the absolute URI is a URL of a document which contains some RDF 
using the fragID 'Buttock' as a name. If there is no such document, 
or no such use of that fragId, then RDF has no way to make sense of 
the first triple, and would probably generate a 409 error. In 
particular, if the second triple makes sense, then the first one 
probably does not, since RDF has no way to figure out what the effect 
of adding a fragID to the name of a unicorn might be intended to be.

>
>The URI reference that identifies the subject of the first statement has a
>fragment identifier.
>
>>  If http://example.org/Unicorn
>>  really means a unicorn, then it should never have a fragId attached
>>  to it in RDF.
>
>Really! This is exactly Aaron's argument.

?? It is? Then I REALLY have not understood what Aaron is saying.

>A unicorn is an example of what
>some people call an "abstract resource".

A unicorn is, sure. But the URI is a name, not what is named. Nobody 
is talking about adding a fragId to a unicorn, right?

>The way RDF would interpret
>>  http://example.org/Unicorn#LeftButtock  would be that the absolute
>>  URI is the URL of a Web document containing some RDF text that uses
>>  the identifier 'LeftButtock', and presumably contains some RDF
>>  assertions about the entity that it identifies.
>
>No this is the whole point. If one RDF treats URI references as opaque
>identifiers, then one can make any statement about any URI reference.

What does 'can' mean? RDF syntax does not forbid it, sure. However, 
it does make some implicit assumptions about how to interpret it, 
which are really part of the syntax of RDF, though implicitly so: 
they are incorporated into the very notion of 'merging' two RDF 
graphs. Those assumptions were sketched above. Now of course one 
might want to say something in RDF about a document with a URL, and 
it allows one to do that. But that use of an absolute URI as an RDF 
name is a very special use.

>This
>is the whole argument. Should RDF treat URI references as opaque or not?
>Should all URIs that use the "http" scheme identify _documents_ or might not
>the URI http://example.org/Unicorn identify a Unicorn..

I would say that if someone wants to try to use it in that way, then 
nothing should prevent them from doing so, but they should be ready 
to take the consequences of doing something that makes such fragile 
semantic sense. Probably what they write will have ludicrous 
consequences.

>For example,does your model theory contain anything pertaining to the
>syntactic substructure of a URI reference? scheme, authority, heirarchical
>part, fragment id? I don't see it.

No, it does not, because the WG consciously decided to avoid going 
into that territory. It would have been fun to try it, but it was 
outside our charter. But an adequate semantics for a web language 
should address such issues, eventually.

>  But the referring
>>  thing here is the whole uriref, not the absolute URI. That doesn't
>>  refer to anything but the document. The relationship between
>  > http://example.org/Unicorn and http://example.org/Unicorn#LeftButtock
>>  is not one of resource to subresource;
>
>Read the internet draft carefully. There is no _relationship_ defined
>between _resource_ and _subresource_. A document does contain fragments. One
>might consider a sub resource to be contained by  a resource but one can
>make entirely independent assertions about a resource and any of the
>subresources that it supposedly contains.

Ive read this several times and it still seems incoherent to me, I 
think because it applies 'sub' to 'resource' rather than 'network 
entity'. We seem to be in agreement that the resource referred to by 
a URI , and the resource referred to by some uriref which includes 
that URI, need bear no particular relation to one another at all. So 
what does it mean to say that one of them is a subresource (or a 
sub-anything) of the other? Anything in any possible world could be a 
subresource of anything else in any other possible world. Talk of any 
kind of 'containment', or the mereological kind of assumption 
suggested by your #leftbuttock example, seems to be completely out of 
place here.

In general, relationships between syntactic entities cannot be 
described coherently in terms of relationships between the semantic 
entities that those syntactic items denote. So any kind of general 
relationship of 'subresource' is off the wall incoherent, before we 
even get started.

>A resource 'contains' a
>subresource when the resource is a namespace but not generally (unless you
>are also willing to say that the "http" scheme contains the set of "http"
>based URIs.
>
>>
>  > For example, look in  http://www.w3.org/1999/02/22-rdf-syntax-ns. It
>>  contains XML-encoded RDF assertions which use, for example,  the term
>>  called there by the string 'Class'.
>
>By "look in" you mean HTTP GET I presume.

Yes. Perhaps I should have said 'look at'. But the key point about 
what I said was that I *used* the URI to *refer to* a network entity. 
Had it not done so, you wouldn't have been able to do what I 
suggested or, probably, even made sense of what I wrote.

>What is returned is not a resource
>but, _by definition_, a network entity.

Why is a network entity not a resource? Surely *anything* can be a resource.

>It is the _entity_ which contains
>XML encoded RDF assertions.

Right, and that entity is what I *referred to* by the name 
"http://www.w3.org/1999/02/22-rdf-syntax-ns" in my earlier message 
(reproduced above).

>So yes the _document fragment_ obtained by _resolving_
>http://www.w3.org/1999/02/22-rdf-syntax-ns#Class is a piece of XML. And the
>_document fragment_ is indeed contained in the document (entity).

We seem to agree. So in your example, the document fragment obtained 
by resolving http://example.org/Unicorn#LeftButtock had better be a 
piece of XML (well, RDF in any case). In other words, 
http://example.org/Unicorn had better be the URL of a document.  The 
RDF semantics might *interpret* it as anything at all, but that's 
completely irrelevant to its role in making connections across the 
semantic web; and it is only the latter role that is relevant to how 
fragIds are treated by an RDF engine.

>It is very common to conflate a resource and the entity that represents it
>at any point in time. But whether you agree or not, this is how the language
>is defined. It is not possible to understand anything about "REST" until
>this distinction is undetstood at least from a terminological point of view.

I think we are in violent agreement here.

Pat
-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Sunday, 24 February 2002 19:04:52 UTC