Re: pound sign vs. slash as final URI delimiter

On Feb 17, 2004, at 15:08, ext Ralph R. Swick wrote:

> At 02:11 PM 2/17/2004 +0200, Patrick Stickler wrote:
>> There is no guaruntee that the base
>> URI will denote and resolve to an RDF/XML instance, nor is there
>> any guaruntee that the fragment identifier will occur as the
>> value of an rdf:ID attribute.
>
> But this is entirely under the control of the issuer of the URI.
> I.e. if you cannot promise that
>
>   GET http://mydomain.com/foo HTTP/1.1
>
> returns something relevant to the resource whose identifier
> is http://mydomain.com/foo#bar then you should use some
> other service than mydomain.com.

???

My comment was specifically about using a URIref with
fragment identifier as a means to obtain a particular
XML element within an RDF/XML instance having an rdf:ID
attribute value corresponding to the fragment identifier.

Still, the present TAG web architecture doc does *not*
require that there be any semantic relationship between
the resource denoted by a base URI and the resource
denoted by a URIref with fragment identifier, nor that
any representation that might be returned when dereferencing
the base URI have any relationship whatsoever to the
resource denoted by the URIref with fragment identifier.

The secondary resource denoted by the URIref with fragid
can be *anything*.

Personally, I don't think that's right. I think there
should be some inferrable semantic relationship between
the resource denoted by the base URI and the resource
denoted by the URIref with fragid, and further, that
that relationship should be some kind of "part of"
or superordinate/subordinate or general/specific
relationship.

To that extent, I agree that if the base URI doesn't
provide a representation which in some way subsumes
a representation (of sorts) of the "secondary resource"
then it reflects poor usage.

But the specs don't say that, so folks don't know
that pitfalls exist with such practices.

>
>> Furthermore, even if the fragment
>> identifier occurs in an rdf:ID attribute, that doesn't mean
>> that the element bearing that attribute contains the complete
>> definition of that resource, even in that particular RDF/XML
>> instance, as there can be other elements with rdf:resource
>> and the full URI defining additional statements about the
>> resource.
>
> Certainly.  This is true of every resource on the Semantic Web.
> "Anyone can say anything ...".  This is a design principle.

Yes, but it has long seemed to me that most folks who want
to use fragids, want to use them in the same way that one
would use anchor names in HTML, to identify the *definition*
of some term in an RDF/XML instance so that one can "GET"
that definition as a component of the RDF/XML instance.

Because it is quite so that one can say anything about anything,
and anywhere, not just in the RDF/XML instance using rdf:ID,
this approach simply breaks down when the knowledge about
those resources is managed modularly in various locations.

>
>> In short, trying to rely on HTML-like fragment identifier
>> resolution to obtain authoritative definitions of terms
>> simply does not work in a sufficiently general and scalable
>> fashion for arbitrary RDF encoded knowledge.
>
> I disagree, though we might be quibbling about the application
> of the word "arbitrary".  Certainly as you have shown there are
> implications below the level of RDF.  But fragment identifiers
> can work

They can work when one has total control over one's environment.

That word 'arbitrary' is not just quibbling.

>  and their use is one way to solve the ambiguity
> between documents and other things.

Example?

Patrick

>
> -Ralph
>
>

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Tuesday, 17 February 2004 09:11:36 UTC