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

On 7/25/06, Xiaoshu Wang <wangxiao@musc.edu> wrote:

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

We could, but why would we want to?

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

Heh, I'd rather steer clear of discussion around frad ids and
identifiers in RDF... But in any case, big HTML pages isn't really a
general problem - if I find a page getting overlong, then I'll flip
out the frag id/anchor into a separate URI/page. But big RDF docs is a
growing problem - Cyc, Wikipedia3....I'm sure there must be cases
around lifesci.

There's no problem with fragments, MIME types and RDF docs - the
fragment is a subgraph served in whatever serialization format you
prefer.

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

That sounds like a "slippery slope" argument. I'm not suggesting an
XPath cookie, just something specifically to enable useful RDF graph
partitioning.

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

I'm only thinking of query/search in a very crude sense, as simple
selection. Something more efficient that doc-on-server,
all-or-nothing, but without necessarily requiring a full query/search
facility.

The other headers can already be used as selectors - the media type
being the obvious one. If you can select by format, why shouldn't you
be able to select by semantics?

Cheers,
Danny.

-- 

http://dannyayers.com

Received on Tuesday, 25 July 2006 11:15:45 UTC