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

On 7/24/06, Xiaoshu Wang <> 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 is not the same as,
> 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?



Received on Monday, 24 July 2006 21:21:26 UTC