W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > July 2006

Re: Semantic content negotiation (was Re: expectations of vocabulary)

From: Reto Bachmann-Gmür <reto@gmuer.ch>
Date: Fri, 28 Jul 2006 21:42:17 +0200
Message-ID: <44CA6899.9070607@gmuer.ch>
To: Xiaoshu Wang <wangxiao@musc.edu>
CC: 'Danny Ayers' <danny.ayers@gmail.com>, public-semweb-lifesci@w3.org, 'Semantic Web' <semantic-web@w3.org>
Xiaoshu Wang wrote:
> --Danny,
>
>   
>> Similarly a hi-res prepresentation of my FOAF profile might 
>> contain a few hundred statements. A low-res representation 
>> might only contain
>> these:
>>
>> <> a foaf:PersonalProfileDocument ;
>> foaf:primaryTopic _:me .
>> _:me a Person .
>> _:me foaf:mbox "mailto:danny.ayers@gmail.com" .
>>     
>
> I don't know why you are constantly trying to disguise a clear "part_of"
> relationship into somethingelse?  The Accept header value is in the format
> MIME type/Quality.  For the image, the lower resolution is a poorer quality
> of representation.  Bit wise, it can be a subset of a higher resolution
> image but doesn't have to be.  But RDF is a directed labeled graph. I am not
> sure how do you define which subgraph is "better" than the other.
>   
If the URI identifies a concrete graph you're right, similarly if the
URI identifies a concrete RDF/XML file. The high and the low resolution
images may have their own URIs and for such an URI (the URI naming for
example the image at high resolution) returning a subset of the data
contained in the high resolution image is just wrong.

But the example was a URI naming Danny's personal profile. This resource
can be represented by a number of graphs, and yes, defining a technique
for the server to find out which one is better is exactly the question.
> [dropping: sparql-argument]
> [dropping: reference to the general use-case I didn't find]
>
> [dropping: plea to end discussion]
>   
cheers,
reto


Received on Friday, 28 July 2006 19:42:54 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:00:44 GMT