- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Mon, 24 Jul 2006 23:21:11 +0200
- To: "Xiaoshu Wang" <wangxiao@musc.edu>
- Cc: public-semweb-lifesci@w3.org, "Semantic Web" <semantic-web@w3.org>
On 7/24/06, Xiaoshu Wang <wangxiao@musc.edu> wrote: > > --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. I did say "in a manner" ;-) > 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? I don't think so, no. A, B and A+B could all be representations of the same resource. If the client only needs A, what's the point in sending B over the wire too? But perhaps "content negotiation" isn't the best term, given the way it's normally intended. For a different approach, A, B and A+B could all be associated with different URIs, as in the Geo example below. > 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? Sorry, I don't understand. Example? > 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. Ok, but where's the conflict with passing hints/acting on hints in headers? > > 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? Either of those URIs could be handled server-side by static file(s) or a query engine. I don't (yet) see any breaking issue. A resource can have multiple representations, there's no reason those representations should share any kind of equivalence other than that determined by the URI-minter. So given that (serializations of) different RDF graphs/subgraphs could potentially represent the same resource, why shouldn't that be exploited to help give the client the best semantic representation for their needs? Cheers, Danny. -- http://dannyayers.com
Received on Monday, 24 July 2006 21:21:26 UTC