RE: RDF query and Rules - my two cents

> IMO, for the SW to reach critical mass, we have to (1) provide a
simple,
> effortless way to get descriptions of resources having only a URI, and

> (2) get away from GETing explicit RDF/XML instances (files) rather
> than querying knowledge bases.

OK, this is a great start.  So why are some people so obsessed with
trying to shoehorn these requirements into a REST model?  It seems to me
that the main problem being addressed here is a data access problem, and
the existence of PUT/GET verbs is not even close to being the high-order
bit on a good data-access architecture.  It's hardly relevant.

With relational data we have a standard Query Language, DML, and some
defacto APIs -- all of these can *optionally* be invoked through PUT/GET
mapping layers, but that's totally orthogonal.  Nobody in their right
mind would complain that relational data adoption was slow due to lack
of PUT/GET elegance.

With semistructured data model we have a standard selection language
(XPath), and de-facto APIs (although lacking in DML, it is a good start)
-- these too can be *optionally* invoked through GET/PUT mappings.
Again, *some* people use XML this way, but nobody would argue that
PUT/GET mappings are the high-order bit in XML adoption.

Finally, with RDF data model we have crap; no defacto way of storing
models, no de-facto access API, no de-facto or prominent query
mechanisms, no de-facto update mechanism.  Anyone wanting to store or
query data models is stuck in a ghetto of half-implemented and
confusingly contradictory houses of cards.  But despite the fact that we
don't even have the slightest freekin' semblance of a consistent
data-access architecture, we still have people arguing religiously about
HOW IT SHOULD USE PUT/GET!  Does anyone else see something slightly
inverted about priorities here?

Received on Thursday, 20 November 2003 13:38:51 UTC