RE: RDF query and Rules - my two cents

> > I think a suitable approach would be to build on the existing RDF
> > remote
> > access API - that of RDF/XML+HTTP. A http GET will retrieve a model
> > over the
> > network based on a supplied URI. The RESTful continuation would start
> > with a
> > PUT to place it on the network, DELETE remove it.
>
>
> I consider this far too coarse grained to be efficient and generally
> useful
> (note the important qualification 'generally').

Indeed, which is why I said: "more complex interactions such as
partial/filtered/query GETs and POSTs do need working out". However I'm not
sure efficiency should be an initial consideration - as long as queries can
be expressed simply and without ambiguity, efficiency shouldn't be an issue
(or at worst careful implementation will be needed).

> A given model might be *huge*. GETting and PUTting entire models seems
> to me to be a corner case, and not what most folks really need/want to
> do.

A given model might be huge, it might be tiny, but either way most people
are already doing GETs when they deal with RDF on the web. What I'm trying
to suggest is that the existing REST verbs be built on, rather than using
protocols orthogonal to existing web architecture.

> Let's please separate issues relating to knowledge management from
> those relating to knowledge discovery. What the SW needs acutely, IMO,
> is a lightweight, efficient, intuitive and easy to implement solution
> for knowledge discovery.

A fair call, though I'm not certain the difference between KBs and resources
is as clear-cut as you suggest - a KB could be a single (reified) statement.
Whether a KB appears on the web through a single queryable location or its
interface is distributed over many URIs (/URIrefs) is surely an
implementation issue.

> C.f.
> http://lists.w3.org/Archives/Public/www-rdf-interest/2003Nov/0115.html

I may be wrong, but I fear that addressing push and pull separately might
lead in the direction of new, web-unfriendly tunnelling protocol(s).

But what I'm suggesting doesn't actually conflict with the requirements you
propose, in fact passing of RDF/XML (and perhaps other syntaxes) over HTTP
is exactly what I had in mind, along with "Existing web standards should be
employed as much as possible;". My main concern is that "overloading of the
semantics of existing web protocols should be avoided" be misinterpreted as
a need for alternatives to GET, POST etc, or perhaps worse still that
everything be opaquely encoded into POSTs.

Cheers,
Danny.

Received on Tuesday, 18 November 2003 13:22:11 UTC