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 19:22:31 UTC