- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Sat, 26 Mar 2005 11:00:18 +0100
- To: public-rdf-dawg-comments@w3.org
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