SPARQL requirements (and INSERT)

In response to Dan's queries, my 2 cents on the optimum WG activity:

Which features now?

- SPARQL Query Language for RDF
- SPARQL Variable Binding Results XML Format

Which features later?

- SPARQL Protocol for RDF

This isn't to suggest that the protocol is less important that the QL
and results format, quite the opposite. But it's directly dependent on
those specs, so it would surely make sense to get those established
first.

Regarding the details of the QL and binding, the features that are
currently included in the drafts look to cover a good realistic range
at present (almost). So I'd suggest focussing on tidying up what's
already in place, with any requirements still in the queue being
postoned for future consideration.

With the exception of INSERT/DELETE, which I would like to see added
(alternatively called ADD/REMOVE or ASSERT/RETRACT). All I would
suggest is:

INSERT {Turtle-format graph}
add statements to the background graph

INSERT {GRAPH name, Turtle-format graph}
add statements to the named graph

DELETE {Turtle-format graph}
remove statements from the background graph

DELETE {GRAPH name, Turtle-format graph}
remove statements from the named graph

(I'd rank the INSERT operation considerably more important than
DELETE, given the open world situation outside of the local model)

Justification in short:

* allows the developer to access the data store with a uniform interface
* closer to expectations of developers coming from SQL
* makes life easier ;-)

It seems strange to me that there isn't already something like INSERT
near the top of the list. Every_single_use_case needs triples in the
store, yet no means to put them there is provided. The APIs may
support parseIntoModel(rdfxml), but doesn't it seem perverse not to
allow SPARQL to act as a uniform interface?

Ok, I understand the objection on the grounds of too much work now;
but that needn't be the case. I suggest painting this functionality in
this iteration as above, in very broad strokes, returning to it later
only if there is demand.

Not much cost, significant benefit, no? 

Cheers,
Danny.

-- 

http://dannyayers.com

Received on Saturday, 26 March 2005 10:00:19 UTC