W3C home > Mailing lists > Public > www-rdf-interest@w3.org > November 2004

RE: working around the identity crisis

From: <Patrick.Stickler@nokia.com>
Date: Fri, 19 Nov 2004 14:07:38 +0200
Message-ID: <1E4A0AC134884349A21955574A90A7A50ADDAF@trebe051.ntc.nokia.com>
To: <A.J.Miles@rl.ac.uk>
Cc: <www-rdf-interest@w3.org>, <public-esw-thes@w3.org>


If you're going to restrict each term to being 
defined by a single document, where that document
only describes one term, then why not just
have a URI for the document and URI for the term
and use conneg to relate them. E.g.

http://my.org/knowlegebase/chemistry/water      the concept
http://my.org/knowlegebase/chemistry/water.html HTML representation
http://my.org/knowlegebase/chemistry/water.rdf  RDF representation
http://my.org/knowlegebase/chemistry/water.txt  text representation
http://my.org/knowlegebase/chemistry/water.jpg  JPG representation
...

or 

http://my.org/knowlegebase/chemistry/water            the concept
http://my.org/knowlegebase/chemistry/water/index.html HTML representation
http://my.org/knowlegebase/chemistry/water/index.rdf  RDF representation
http://my.org/knowlegebase/chemistry/water/index.txt  text representation
http://my.org/knowlegebase/chemistry/water/index.jpg  JPG representation

--

The key point here, though, is that using URIs without
fragids gives a publisher complete freedom to use whatever
naming methodology they like, and relate the various 
resources (terms, documents, descriptions, etc.) however
they like, without forcing a particular hard-coded and
inefficient 'document#term' organization onto clients.

When only URIs without fragids are used, clients are then
free to access representations at whatever level of resolution
is ideal for the *client*, and metadata descriptions of the
resources in question can be used to identify and access
related resources in whatever manner is ideal for the *client*.

The 'document#term' approach is like the old Biblical tales
where the father says "Sure you can marry my youngest daughter,
but only if you first marry her three older sisters..."

Forcing access to a secondary resource via a representation
of a primary resource is no different.

Personally, I would prefer a more modern, and less expensive,
approach to getting intimate with resources ;-)

Patrick
 

> -----Original Message-----
> From: www-rdf-interest-request@w3.org
> [mailto:www-rdf-interest-request@w3.org]On Behalf Of ext Miles, AJ
> (Alistair)
> Sent: 16 November, 2004 18:58
> Cc: www-rdf-interest@w3.org; public-esw-thes@w3.org
> Subject: RE: working around the identity crisis
> 
> 
> 
> 
> > The technical problem is that using frag ids raises issues when you
> > have a large set of terms and then try to efficiently GET a 
> term's URI
> > in order to receive a description (or if you would like to 
> > provide term
> > descriptions at a term's URI).
> 
> Just to say that, as Dave Reynolds pointed out a little while ago on
> public-esw-thes list, this is not necessarily true, as you 
> can do things
> like
> 
>    http://my.org/knowlegebase/chemistry/water#concept
>     http://my.org/knowlegebase/chemistry/ice#concept
> or
>     http://my.org/knowlegebase/chemistry/water#Water
>     http://my.org/knowlegebase/chemistry/ice#Ice
> 
> ... see his posting at 
> 
> http://lists.w3.org/Archives/Public/public-esw-thes/2004Sep/0016.html
> 
> Not that I'm expressing any sort of opinion on whether hash 
> or slash is best
> ;)
> 
> Al.
> 
> 
> > 
> > >If this has been discussed to death before, please feel free 
> > to tell me
> > >so and/or provide a pointer to such a discussion.
> > one related thread ("pound sign vs. slash as final URI delimiter")
> > starts at [1]
> > 
> > [1] 
> > 
> http://lists.w3.org/Archives/Public/www-rdf-interest/2004Feb/0117.html
> > 
> > regards,
> > benjamin
> > 
> > --
> > Benjamin Nowack
> > 
> > Kruppstr. 100
> > 45145 Essen, Germany
> > http://www.bnode.org/
> > 
> > @ DERI Galway from 2004-10-01 to 2004-12-02
> > http://www.deri.ie/
> > 
> > 
> > 
> > >
> > >Cheers,
> > >
> > >Jeen
> > 
> > 
> 
> 
Received on Friday, 19 November 2004 12:09:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:56 UTC