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

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