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

-- Danny

> I did say "in a manner" ;-)

Oh, my bad.  :-)
 
> > 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?

Of course, the intention for saving network bandwidth is good.  But to solve
one problem may potentially a lot of other problems.  IMHO, the tradeoff for
this particular case is just too much.  

> 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?

We can invent an X-Path cookie, for example, an HTTP header like:

X-Path: whatever the X-Path expression here.

And request a HTTP server to return a portion of the XML document, right?

In the case of HTTP fragment identifer. Currently, the fragment portion of
the HTTP URI is always handled at the client side, right?  By your logic, it
should be handled at the server side, because if the client only want to see
the fragment, what is the point of sending the rest portion?  There is
reason why it should be handled at the client side.  For one, it potentially
breaks the MIME type spec. What is going to be the MIME type of a HTML
fragment?

> > > 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 doubt you can handle the first URI straightup with a HTTP server.

> 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?

IMHO, it breaks too much.  See my example Xpath cookie example.  With the
provided argument, there is no point to spend so much time on web services.
Putting things in HTTP header will always do.

One of the fundmental principle of the web is "orthogonal specificiation".
The orthogonality gives the web flexibility and extensibility.  Don't you
think what you suggested will break this principle by mixing query/search
with transportation?

Xiaoshu

Received on Tuesday, 25 July 2006 04:09:42 UTC