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

> -----Original Message-----
> From: sandro@roke.hawke.org [mailto:sandro@roke.hawke.org]On Behalf Of
> ext Sandro Hawke
> Sent: 06 October, 2004 15:33
> To: Stickler Patrick (Nokia-TP-MSW/Tampere)
> Cc: T.Hammond@nature.com; leo@gnowsis.com; mdirector@iptc.org;
> www-rdf-interest@w3.org
> Subject: Re: URN as namespace URI for RDF Schema (run away... run
> away... ;-) 
> 
> 
> 
> 
> > > The good reasons I've heard are mostly:
> > >    (1) convenience: dereference of the URI gets the 
> ontology (schema)
> > >        without any special server configuration
> > 
> > Err... yes, that's the argument, but IMO it's deceptively false
> > because it is based on presumptions about schema management 
> practices
> > which are *known* to not encompass common practice.
> 
> What about in RDF "instance data", eg RSS items and people mentioned
> in FOAF files?  These work very nicely using fragment URIs.

I think you misunderstand my point. As I said in another
post to Tony, I recognize valid uses of SURIs, but that does
not mean that *most* usage should employ them.

> 
> > Also, exactly why would an agent want to always get the
> > entire ontology (think CYC, Wordnet, etc.) just to find out
> > what a few *specific* term mean? A parallel would be having to
> > download an entire mirror of a website to access a single page of
> > that website after downloading the whole shabang. Yes, for
> > tiny websites accessible via fast network connections, that
> > could work, but it certainly wouldn't scale.
> 
> It's really a hard problem.  Given a term in wordnet or cyc, what
> really does the naive client want transmitted?   Dan Brickley's
> Wordnet approach (giving you the class hierarchy for a term when you
> ask about it) is nice, but very slow/tedious if you want to
> traverse lots of wordnet.   Cyc's all-in-one approach is of course
> painful the first time, but then you have it all handy.

And what if the agent is running on a mobile device, where one
certainly does *not* want to keep it all handy ;-)

Again, the methodology of using SURIs to denote vocabulary
terms makes many presumptions about the application environment
which simply are not valid or scalable (up or down) in known
application areas for it to be considered the "primary" way
to do things.

The more general approach that I advocate, using PURIs to
denote most (nearly all) resources, is much more scalable.

If one *wants* the entire ontology, then in two or three
URIQA exchanges you can have it. I.e. (ideally) the description 
of the term would tell which vocabularies/ontologies it belongs
to, and the description of each vocabulary/ontology would
tell what schema document(s) define it, and you can then
GET the whole enchilada.

But an agent that only wants a small, focused description
of the term alone is not force fed some huge volume of 
data, nearly all of which it has no use for.

> Natural divisions are nice when they exist.   :-)

Yes, and it's a pity when an architecture or methodology
hinders benefiting from them.

> > >    (2) architectural coherence: some people (notably 
> TimBL) think of
> > >        non-fragment URIs as identifying documents; they find=20
> > > it jarring
> > >        (or incoherent) when such URIs are used to 
> identify properties,
> > >        people, etc.
> > 
> > I would be surprised, and disappointed, if anyone trully found
> > the idea of using PURIs to denote non-information-bearing resources
> > either "jarring" or "incoherent". 
> 
> I understand TimBL to find it so, and for a time after talking with
> him, I do so as well.   

Then consider me both surprised and disappointed ;-)

Do you not find the examples presented per
http://lists.w3.org/Archives/Public/www-rdf-interest/2004Oct/0058.html
to be the least bit motivating?

There you see several non-trivial, deployed and hard working vocabularies
which do not employ any SURIs other than those defined in the standard
RDF, RDFS, and OWL schemas -- and agents are able to easily access
complete descriptions of all terms, vocabularies, subvocabularies,
and all their interrelations efficiently and effectively -- and that
is *aside* from the additional functionality provided by URIQA, *not*
because of it. 

The key is that each term, vocabulary, etc. is denoted by a PURI, (i.e.
a Primary URI, a URI without fragment identifier), and thus one may 
access representations of each such resource *independently*
of any other resource.

Having to go through a representation of some other resource to
get the representation of the resource in question (however they
might be related) is, to me, having to go through a neighbor's
house to get to my own. It could work, I guess, in some cases,
but it wouldn't be very convenient arrangement for most folks.

After all, do we expect the terms of our vocabularies to be first
class citizens of the web, or second class citizens?

(I expect that TimBL would conclude that anything that is not
 an information-bearing-resource is a secondary and hence second
 class citizen of the web -- but I think that's missing out on
 a huge amount of potential)

> I also find it so whenever I've made the
> mistake of talking to mere mortal web developers who don't use the
> term "URI".  

;-)

I'm just so tired of having to type "URI with fragment identifier"
or "URI without fragment identifier". Given the *substantial* functional
difference between these two forms of URI, it's hard to understand
why there are not distinct terms to differentiate them...

And since there aren't, I decided to create my own.

I'm not sure yet whether I will regret it ;-)

And in fact, I kinda stole the terms from Graham Kline, from his 
comments per
http://lists.w3.org/Archives/Public/public-webarch-comments/2004OctDec/0003.html

(so blame Graham ;-)

Patrick

Received on Wednesday, 6 October 2004 13:00:37 UTC