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

To cut to the chase, look for ****

>Pat Hayes wrote:
>
>[[
>The critical point to note is that these two senses of 'identify' are
>different. The RDF sense is 'denote' or 'refer to'; the RFC 2396
>......well, the fact is that RFC 2396 is ambiguous and almost
>incoherent, but the sense that is relevant to this discussion is that
>it means something like 'identify well enough to locate and retrieve
>using a transfer protocol'.
>]]
>
>Not sure about that but no matter. Clearly a resource as defined by RFC 2396
>and a resource as defined by RDF _are_ different.

That is not at all clear, as it is impossible to determine what RFC 2396 means.

>
>>
>>RDF, however, uses URIreferences as opaque identifiers for resources and
>>this identification is outside any HTTP transaction -- hence no media type
>>applies.
>
>[[
>This is what Aaron said on the RDF core WG discussion of this
>recently. But this seems to me to be confused.  RDF 'uses' them in
>this way in the sense that the RDF semantics places no restrictions
>on the RDF *interpretation* of a uriref.
>]]
>
>No doubt this issue is confused, the only question is as to whom is
>confused. But no matter, what I am saying is that the specs are ambiguous
>and the attempt is to clarify the usage of the URI + fragment identifier
>
>[[
>But that sense is irrelevant
>to any other processes that make up the computational fabric of the
>web, such as transfer protocols.  I'm sure there are RDF urirefs
>which refer to me, but I would be most upset if any kind of web were
>to tug my sleeve or call my name when someone clicked on one of them.
>]]
>
>Don't conflate a URI with a URL. A URI reference is that: an identifier.

Yeh, I know the sayings of the True Church. But this whole issue is 
only an issue for the URL interpretations, ie when worrying about 
transfer protocols. None of the actual *operation* of the WWW (or any 
other computing device ever built, except maybe some robots) is 
concerned with semantic denotation or reference.

>No
>specific need to actually touch you. That would be a network protocol. See
>CPIP (Carrier Pidgeon Internet Protocol) for chuckles.
>
>[[
>If we stick to the domain of computable operations on RDF documents,
>then RDF's use of fragment ids is quite well-defined and limited: it
>uses them to identify *syntactic parts of RDF documents* (typically,
>referring IDs located inside RDF assertions inside RDF documents
>which have an absolute URI.)
>]]
>
>Not just syntactic however, URI reference includes URI '#' fragment
>identifier, so an RDF subject predicate, object may contain a fragment
>identifier.

?? That is all still syntax.

>
>[[
>So as far as all questions concerning
>transfer protocols are concerned, RDF can be considered to *be* a
>media type, since at this level of discussion we are talking about
>RDF *syntax*, not RDF semantics. Most RDF semantics isn't even
>located on the web, in general.
>]]
>
>I don't see how you can interpret it this way. I am not talking about any
>sort of URI resolution process, simply the use of URI references as subject,
>predicate, object. The URI reference need not even be network resolvable
>e.g. "urn:uuid:xxxxx"
>
>[[
>Well, as long as RDF knows what it identifies, isn't that enough?
>]]
>
>I suppose, but if you normatively reference RFC 2396, you are committing to
>it. Certainly RDF is self consistent. And if we simply ignore several
>convenient definitions all is fine. I have no real problem with this. The
>Internet Draft is an attempt to codify this usage by RDF, not argue against
>it.
>
>[[
>Cf. your HTML/HTTP sketch, above: that seems to work for RDF in just
>the same way. The URI is used to retrieve an RDF ontology - a
>document -  and the RDF client uses the fragId to identify the term
>used in that ontology.
>]]
>
>Yes but that is all part of a URI resolution process, which doesn't occur in
>RDF applications (mostly). Even if you _do_ assume an RDF media type: what
>do you do if you run across a URI reference that doesn't use the RDF media
>type registered fragment identifier syntax? (as if one were registered).

Well, my reaction would be, then it is meaningless to RDF. So?

>
>>
>>See:
>>http://www.ietf.org/internet-drafts/draft-borden-frag-00.txt
>>
>>A generic fragment identifier syntax is defined which encapsulates known
>>fragment identifier syntaxes:
>>
>>The term "sub resource" is introduced, to define what a URI reference
>>identifies.
>
>[[
>That is meaningless in general, however. Anything can be a resource.
>What is a "subresource" of, say, a unicorn or a galaxy? You seem (?)
>to be confusing a URL sense of 'resource' meaning: part of a
>retrievable web document, with an  RDF/URI sense of 'resource'
>meaning: entity referred to by an RDF name.
>]]
>
>No. RDF need not concern itself about "sub resources". This term is
>introduced in an _IETF_ submitted document to capture an important usage by
>RDF of URI references. Again (RDF:resource := IETF:resource union
>IETF:subresource)
>
>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*. If http://example.org/Unicorn 
really means a unicorn, then it should never have a fragId attached 
to it in RDF.  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. 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; it is one of a document to a 
thing referred to by a name in the document. The URI identifies the 
place where the name can be found; the uriref *is* the name.

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'. If I want to talk about classes 
using the same term, in my document I would write 
http://www.w3.org/1999/02/22-rdf-syntax-ns#Class.
Now, this does NOT mean that the URI 
http://www.w3.org/1999/02/22-rdf-syntax-ns  names or denotes a thing 
which has http://www.w3.org/1999/02/22-rdf-syntax-ns#Class as a part, 
or a component, or  a sub-thing, or whatever. In fact, 
http://www.w3.org/1999/02/22-rdf-syntax-ns doesn't really denote 
anything in RDF; it's a document, not a resource. (OK, documents are 
resources too;  but Im sure you get my point.) Its only function is 
to locate the place on the web where I can find 
http://www.w3.org/1999/02/22-rdf-syntax-ns#Class, so that when I use 
*that* name, everyone knows what name I am using, which in turn means 
that they can put together assertions in various documents (including 
http://www.w3.org/1999/02/22-rdf-syntax-ns  itself, of course) which 
use that name, and know that it is the same name.  But all of this is 
entirely to do with syntax, not with semantics.  RDF semantics only 
applies to the fully targetted urirefs, not (usually) to the absolute 
URIs that form their prefixes. (There are exceptions to this, where 
one wants to think of a document itself as a resource, as when 
talking about what Ora wrote; but these are the exception rather than 
the rule. Most of RDF isn't *about* documents, even though it is all 
written *in* documents.)

>on the other hand the URI http://example.org/Unicorn/LeftButtock identifies
>an (IETF) resource
>
>perhaps they represent the same RDF resource?
>
>[[
>(This is the familiar
>use/mention confusion that seems to resurface in these discussions
>about every six weeks.)
>]]
>
>No. It has nothing to do with that. It is a purely definitional issue. An
>IETF:resource is defined to be identified by a URI, not a URI reference.
>That is really the entire issue.

RDF (and DAML and OWL) *must* be able to make links between names 
across the web, using URIs to identify those documents, and something 
else to indicate the syntactic pieces inside them. How this is done I 
really don't care, but fragIds seem to be a simple, robust, and 
universally used technique. I don't see any reason to change this.

>
>[[
>The resources that RDF *refers* to are,
>typically,  not the kind of things that can possibly live on any web
>or be transferred by any kind of transfer protocol.
>]]
>
>To be clear: IETF resources are not transferred from place to place by
>network protocols. A resource is mapped to a network entity (a
>representation of the resource) and it is the entity which is teleported
>around.

That does not make sense. How does one map a unicorn to anything? How 
does one map a galaxy to anything at more than light speed?

>See Fielding 2000
>http://www1.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm look
>around 5.2.1.1

I looked. This is just as confused/ambiguous as RFC 2396, and seems 
to have been largely copied from it. Fielding talks about reference 
in very grand terms:

"Any information that can be named can be a resource: a document or 
image, a temporal service (e.g. "today's weather in Los Angeles"), a 
collection of other resources, a non-virtual object (e.g. a person), 
and so on. In other words, any concept that might be the target of an 
author's hypertext reference must fit within the definition of a 
resource. A resource is a conceptual mapping to a set of entities, 
not the entity that corresponds to the mapping at any particular 
point in time."

but all his examples involve 'resources' that *consist of* 
information about the 'real' resources - documents, files, academic 
papers, hypertext -  not physical or imaginary or abstract entities 
(people, unicorns, numbers) that cannot even be put into 
computational domains (though they can of course be referred to by 
symbols that can be put into them). So, just as with RFC 2396, we are 
left with computer technology pretending to be semiotics.

Look. If a solid, physical thing like a person or a book is a 
resource, then we need to make a very clear distinction between 
things, and information about things. Things are NOT on the web, 
semantic or otherwise. Information is on the web. RDF, being text, 
consists of information. What RDF is supposed to be ABOUT is 
irrelevant to any machine processing of information (other than an 
RDF reasoning engine).

>[[
>  The resources
>that RDF *uses* are pieces of syntax - ultimately, character strings,
>in effect - that can be easily considered to be a mime type or a
>media type without straining these concepts unduly.
>]]
>
>I disagree. A URI is a piece of syntax. A URI identifies a resource. Where
>does it ever say that a resource is a piece of syntax?

It doesn't SAY that, but all the technical discussion assumes that 
implicitly or explicitly. What the spec says is irrelevant if it is 
incoherent and can have no bearing on any computational activity. 
Referring to denotation in a technical spec is like saying that 
computers have to pray to the one true god.

>
>[[
>RDF *documents*
>have parts that are identified by (not referred to by) urirefs with
>fragments.
>]]
>
>Just to be clear: are you saying that:
>
><rdfs:Class rdf:ID=:"foo">
>
>...
>
></rdfs:Class>
>
>The URIref http:// ...#foo identifies the XML element named <rdfs:Class> ?

Define 'identifies'.

I'm not saying that it DENOTES an XML element.

>That is _exactly_ what XML 1.0 says if the attribute "rdf:ID" is defined to
>have type ID. What is this RDF stuff then?

What do you mean? Its a lot of assertions, written in a language with 
formal semantics. As far as I know, XML doesn't have any semantics. 
:-)

>
>What is most interesting is the talk about RDF _assertions_ when the
>characteristics of what is being asserted differ so radically despite
>assumingly intelligent people reading the exact same documents.

Its nothing to do with people. I meant assertions that can be used by 
software agents.

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 Friday, 22 February 2002 17:41:45 UTC