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

Hi Xiaoshu,

> because the
> designer of one ontology would have no idea how it is going 
> to be used.

I agree with you here but ...

> And I think how to treat a set of RDF
> triples, i.e., in what kind of closure is a consumer's issue 

... I believe this is a semantic web issue also, but at a different
level--the consumer should likewise have no sense of this, the average
consumer should have some piece of information they are curious about
(for example, their patient has a cold with these interesting symptoms)
and wishes to know if there is interesting information about this.

This group seems to have forgotten that for the semantic web to be used
by more than a handful of hardcore researchers, it will need have tools
that are easy to use for the average joe researcher.  It feels like
there are a lot of levels that have gotten mixed up in the recent
discussions.

cheers,
Michael

Michael Miller
Lead Software Developer
Rosetta Biosoftware Business Unit
www.rosettabio.com

> -----Original Message-----
> From: public-semweb-lifesci-request@w3.org 
> [mailto:public-semweb-lifesci-request@w3.org] On Behalf Of 
> Xiaoshu Wang
> Sent: Monday, July 24, 2006 11:02 AM
> To: public-semweb-lifesci@w3.org; 'Semantic Web'
> Subject: RE: Semantic content negotiation (was Re: 
> expectations of vocabulary)
> 
> 
> 
> --Danny,
> 
> > In a manner, this approach is already flying. An RDF store 
> > may contain billions of triples, but by using a query 
> > protocol (i.e. SPARQL) it's possible to deliver only the 
> > subset of interest to the client. This is less burdensome 
> > that directly serving a document containing the billions of triples.
> 
> But querying is a totally different matter from web closure.  
> Because a
> query implies the result returns to meet certain criteria.  Content
> negotiation is a different representation of the same 
> resource, but not the
> different part of the same resource.  It is wrong in a 
> fundamental way.  
> 
> Let me put it in this way, if I have a resource R that is 
> composed with two
> parts A and B.  uri(R) should always return the 
> representation of R, ie.,
> (A+B) right?  If as you suggested, the uri(R) would have 
> three possible
> results:
> (1) A
> (2) B
> (3) A+B
> 
> It fundemantally breaks the purpose of URI, don't you think? 
> 
> By the same logic of this semantic cookies proposal, we can also using
> cookies for XML path to XML document, or even worse to ask 
> the HTTP URI
> fragment identifier should be handled at the server side but 
> not the client
> side?  
> 
> How to partition content is the concern of content provider.  
> How to use the
> content is a consumer's issue.  And I think how to treat a set of RDF
> triples, i.e., in what kind of closure is a consumer's issue 
> because the
> designer of one ontology would have no idea how it is going 
> to be used.
> 
> > But it seems to me there should be less demanding approaches. 
> > If, for example, the client is only interested in say Geo 
> > data, that hint could be passed (somehow) in a HTTP header. 
> > For a server that recognised that header when an RDF-bearing 
> > URI was gotten, it would be possible to redirect the client 
> > to a more appropriate resource, such as one with a static 
> > file containing only Geo-related data.
> 
> What you described is a query engine but not the transport 
> engine like HTTP.
> A URI of http://www.foo.com/?x=y is not the same as 
> http://www.foo.com,
> right?
> 
> Xiaoshu
> 
> 
> 
>

Received on Monday, 24 July 2006 20:45:49 UTC