W3C home > Mailing lists > Public > public-esw-thes@w3.org > April 2004

Re: URIs for Concepts: Best Practices

From: Kal Ahmed <kal@techquila.com>
Date: Fri, 23 Apr 2004 10:08:49 +0100
Message-ID: <4088DD21.80905@techquila.com>
To: David Menendez <zednenem@psualum.com>
Cc: "Miles, AJ (Alistair)" <A.J.Miles@rl.ac.uk>, "'public-esw-thes@w3.org'" <public-esw-thes@w3.org>, "'public-esw@w3.org'" <public-esw@w3.org>

David Menendez wrote:

>Kal Ahmed writes:
>>On Mon, 2004-04-19 at 22:22, David Menendez wrote:
>>>It would be confusing for a URI to identify a thesaurus concept and
>>>an RDF file. The key, as I see it, is the idea that the response to
>>>an HTTP Get is a representation of the resource, not the resource
>>>itself. The fact that <http://xmlns.com/wordnet/1.6/Dog> returns an
>>>RDF/XML document, doesn't mean that it identifies that particular
>>>document. If, for some reason, you wanted to talk about that
>>>RDF/XML document instead of the word "Dog", you would need to use a
>>>blank node or a different URI.
>>It is certainly true that content negotiation gives you the problem of
>>talking about the descriptive resource as opposed to the described
>>thing. That is a strong argument against content negotiation for RDF /
>>XTM resources.
>I've always felt content negotiation was more of an opportunity than a
>problem. :-)
>If I'm reading you right, in the case of
><http://xmlns.com/wordnet/1.6/Dog>, the "described thing" is the class
>"Dog", and the "descriptive resource" is the RDF/XML document returned
>if you do an HTTP Get.
I would prefer to say that the described thing is the abstract concept 
of Dog (Dog-ness ?) because the word "class" can be misinterpreted as 
meaning the OWL class Dog, for example. But I think you understood me 

>The REST view, as I understand it, is that the URI denotes the class
>"Dog". Since you can't actually transmit a class over the internet, any
>attempt to GET that URI will result in (1) a 404 or similar error, or
>(2) a representation of the class "Dog", which could be one of many
>possible electronic documents which is selected according to
>negotiation. All of these representations are themselves distinct
>resources, even if they have no explicit URI (that is, they are blank
>nodes). Some versions of HTTP include a Content-Location header, which
>gives a URI for the particular representation being returned.
>In that case, I would actually recommend content negotiation for RDF
>terms. If I put <http://xmlns.com/wordnet/1.6/Dog> into my web browser,
>I'd rather get a human-readable HTML document than a bunch of RDF. If my
>RDF software GETs the same URI, it should get an RDF document.
>In both of those cases, the goal is to find information about the class
>"Dog". We don't care as much (or at all) about the representation which
>conveys that information.
In principal I agree with you that this would be a good way to go, and 
it fits nicely with a RESTful view of the world and I think it fits well 
with the distinction between resource and representation. However, I 
struggle with how to annotate the RDF/XML resource - how do I say that 
the author of this resource was John Smith ? In this case I am not 
interested in finding out more about Dog-ness, but I want to know more 
about this RDF description of Dog-ness - perhaps to establish whether or 
not I trust the source of information.

While writing this, a lightbulb went on and I think I now understand 
something I had missed in your previous posting.  In a prior email on 
this thread, you suggested that a way to refer to a representation could be:

[ a Representation
  ; source <http://xmlns.com/wordnet/1.6/Dog>
  ; date "2004-04-23T01:28:00Z"

So I suggest that we might extend this model to include the 
content-negotiation parameters and then we can attach representation 
metadata to the blank node.

I need more coffee before I can write out the RDF/XML syntax for this, 
but hopefully you can see what I'm getting at enough to tell me if we 
are on the same page or if I misunderstood.


Received on Friday, 23 April 2004 05:08:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:45:11 UTC