RE: URN as namespace URI for RDF Schema (run away... run away... ;-)

-----Original Message-----
From: ext Hammond, Tony [mailto:T.Hammond@nature.com]
Sent: 06 October, 2004 13:07
To: Stickler Patrick (Nokia-TP-MSW/Tampere); leo@gnowsis.com; mdirector@iptc.org
Cc: www-rdf-interest@w3.org
Subject: RE: URN as namespace URI for RDF Schema (run away... run away... ;-)

> 
> Hi Patrick:
> 
> One question, one observation.
> 
> I thought the advantage of using fragments was that (after
> reconstruction of the original URI from the QName) one would
> have a natural means of addressing into an XML document
> (describing the schema) using XPointer methodology. Am I wrong in this? 

No. You're quite right. 

And I didn't mean to imply that there are not valid uses
of URIrefs with fragment indentifiers. There are. And
they mostly (all?) include cases where the secondary resource
denoted by the URIref is a dc:partOf the primary resource
denoted by the base URI of that URIref.

But it seems that alot of folks seem to lose sight of
the fact that URIrefs with fragids have traditionally
(and IMO still are) document-centric identifiers, such that 
their interpretation is dependent
on a particular representation (document) of a particular
MIME type and that such identifiers are not meaningful
(as a whole) to the core web architecture (HTTP).

You can't GET anything directly via a URIref with fragid. 

You *can* first extract a base URI from a URIref with fragid,
and GET a representation via that base URI, in the context
of which you can interpret the URIref with fragid and
perhaps extract a (kind of) representation of the
resource denoted by the URIref, but that latter interpretation
of the representation is outside the scope of the
web architecture proper; it happens on the client side
"behind closed doors" after the web-specific business is 
concluded.

Resources which are denoted solely by URIrefs with
fragids are *second class* web citizens and are excluded
from the core web machinery used to directly access 
representations.

Therefore, unless it is *central* to the usage of some
resource that access be *restricted* solely to secondary
machinery in the context of a *specific* representation,
don't use URIrefs with fragids.

So... that said,

If the resource in question is a chapter of a book, then 
a URIref would make sense. The chapter is a functional part
of the book, and one would expect a representation of the
book to include a representation of the chapter. Fine.
Similarly for a section of a web page or a component of an
SVG graphic, etc.

However...

If the resource in question is a term of a vocabulary (both
of which are abstractions completely separate from any notion
of "document" or "schema"), then IMO a URIref is a bad idea;
because the complete, authoritative definition of that term 
can be expressed in any number of documents, and therefore,
to presume that a complete and comprehensive representation
of that term would be contained within a single representation
of a single document (schema) is IMO both unreasonable and overly 
constrained.

Yes, some folks seem to make that approach work, for smaller
and simpler applications, but it has never scaled for me. 

The use of a URIref with fragid also excludes the ability
of web agents to *directly* access representations of that
term, which limits the efficient discovery of authoritative
definitions of such terms using the core web machinery.

The benefit and elegance of such direct access should be
evident from the examples I provided in my previous postings
in this thread.

> I note that you use the term URIref a la RFC 2396. 

I'm trying to hold a middle ground between 2396 and 2396-bis
by always saying "URIref with fragid" rather than just "URIref"
such that I avoid conflicting with either (but it's not easy ;-)

> -bis recognizes 
> fragments as natural components of URIs. Don't you 
> feel that URIref is a somewhat challenging concept - 
> relating as it seems to an unrequited URI. ;)

Well, perhaps in a sense, yes.

What I hate most is that I have to always say "URIref with fragid"
and there is no clear terms to differentiate between a URI
without fragid and a URIref with fragid. I wish that we had
some terms such as

PrimaryURI    = scheme ":" hier-part
SecondaryURI  = PrimaryURI "#" fragment 
QueryURI      = PrimaryURI "?" query 

Sigh...  maybe I should just publish a tiny document defining
these and simply start using them...

Patrick


> Tony
>
> > But be very careful to ignore all those schemas which use URIrefs
> > with fragment identifiers to denote vocabulary terms, including
> > the official RDF schemas for RDF, RDFS, OWL, etc... ;-) ;-) ;-)
> > 
> > Particularly good example schemas to emulate [1] are:
> > 
> > http://sw.nokia.com/schemas/general/VOC-1.0.rdf 
> > http://sw.nokia.com/schemas/nokia/FN-1.2.rdf 
> > http://sw.nokia.com/schemas/nokia/MARS-3.1.rdf 
> > 
> > Note the use of the VOC-1 vocabulary to define functionally
> > significant sets of terms, including the ability to group
> > terms by subvocabularies, which fully alleviates the need
> > to pay any attentions whatsoever to any syntactic features
> > employed by the RDF/XML serialization, namely XML namespaces.
> > 
> > Also, note the benefit of using http: URIs (not URIrefs
> > with fragment identifiers) to denote your vocabulary
> > terms per the following real-world examples:

Received on Wednesday, 6 October 2004 11:09:40 UTC