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

On 7/26/06, Xiaoshu Wang <> wrote:
> --Reto,
> > > The HTTP protocol is not designed to do content partition.
> > Not sure, after all we have Byte Ranges for binary content.
> It is for the purpose of transportation.  Again, let's use UPS as an
> example, byte range is like, O.K. give me the first three package first.
> But not give me all the packages that contains books.  Because what is
> inside a package is irrelevant to their tasks.

How does UPS deal with Accept-Language?

> > It's not about about (arbitrary) queries but about selecting
> > the representation. Representation of a resource may be
> > incomplete, so if G is an appropriate representation of R
> > every subgraph of G is as well.
> What is the definition of "appropriate"?

Whatever the server thinks best.

By your logic, a picture of your
> forehead is an appropriate representation of a face?  Selecting partial
> representation is a totally different matter from selecting different kinds
> of representation.

How do you define "partial representation"? As you keep insisting,
such issues are not relevant to the transport (but the transport can
relay related information). A forehead may be a perfectly good
representation of a face to an agent that is only interested in frown
lines. The representations of a typical weblog change from one week to
the next. Without additional constraints in your example, tomorrow you
might get a completely different person's face.

> Of course, in an open world, no one has the complete information about a
> resource.  So, all RDF is only a "partial" representation of the resource.
> However, if this "partial" information is a complete or adequate
> representation of the resource is the choice of the resource owner, who must
> understand the consequence of his/her choice.

In part (!), yes, but noting that what the user of the data considers
adequate/complete may be very different than what the resource owner
has in mind.

> Take HTML page as an example. If I want to put up a long article on the web,
> I can elect to put them in two ways:
> 1. As one big html page under one URI
> 2. As multiple pages, each of which has a URI.
> It is up to me to weight the tradeoff and make appropriate decision.  It is
> an engineer/design issue but not a transportation issue.

True. But if the client is a small-screen device, a shorter version of
the page may be requested (and may be delivered).

Henry's example snipped, but I do think Reto's onto a good inference
things. That's a great example of where some form of negotiation could
be useful. If the client hasn't many cycles available, let the server
do a bit more work.

Xiaoshu, believe it or not I'm still not entirely sure where your
objections lie. Would you be against negotiation information being
part of the payload? That may prove a better approach, but in the
general case I'd suspect you'd end up with something SOAP-like, not
using HTTP to its full advantage. HTTP is designed to be extensible,
it includes negotiation capabilities on syntax, why shouldn't it
happen on semantics?



Received on Wednesday, 26 July 2006 14:51:22 UTC