Re: Shortcuts in Update

On 19 Jul 2010, at 14:32, Andy Seaborne wrote:

> 
> 
> On 18/07/2010 8:53 PM, Lee Feigenbaum wrote:
>> On 7/16/2010 1:02 PM, Alexandre Passant wrote:
>>> Hi,
>>> 
>>> While we closed ISSUE-24 [1] and allow moving data between graphs [2],
>>> I'd like to re-open the discussion on shortcuts for the related
>>> commands - started by Steve and Andy [3].
>>> 
>>> In particular:
>>> 
>>> 1) Copy data from one graph to another
>>> 
>>> COPY ( [GRAPH]<g2> | DEFAULT) INTO ( [GRAPH]<g1> | DEFAULT)
>>> 
>>> shortcut for
>>> 
>>> DROP SILENT (GRAPH<g1> | DEFAULT)
>>> INSERT { ( GRAPH<g1> | DEFAULT) { ?s ?p ?o } } WHERE { ( GRAPH<g2> |
>>> DEFAULT) { ?s ?p ?o } }
>>> 
>>> 2) Move data from one graph to another
>>> 
>>> MOVE ( [GRAPH]<g2> | DEFAULT) INTO ( [GRAPH]<g1> | DEFAULT)
>>> 
>>> shortcut for
>>> 
>>> DROP SILENT ( GRAPH<g1> | DEFAULT)
>>> INSERT { (GRAPH<g1> | DEFAULT) { ?s ?p ?o } } WHERE { (GRAPH<g2> |
>>> DEFAULT) { ?s ?p ?o } }
>>> DROP ( GRAPH<g2> | DEFAULT)
>>> 
>>> 2) Add data from one graph to another
>>> 
>>> ADD ( [GRAPH]<g2> | DEFAULT) INTO ( [GRAPH]<g1> | DEFAULT)
>>> 
>>> shortcut for
>>> 
>>> INSERT { (GRAPH<g1> | DEFAULT) { ?s ?p ?o } } WHERE { (GRAPH<g2> |
>>> DEFAULT) { ?s ?p ?o } }
>>> 
>>> Previous concerns by Andy and Steve where about "attempting to define
>>> syntactic shortcuts in a language that's not in widespread use yet".
>>> Yet, I find that these command could reduce the burden of some useful
>>> patterns, e.g. when having temporary graphs and then moving their data
>>> into "permanent graphs".
>>> Might be relevant when dealing with temporal information (blogs,
>>> sensors, etc.) that needs to be processed / validated before being
>>> considered stable enough.
>>> 
>>> I'd like to start the discussion here and follow-up on a next t-con
>>> (27th, I'm not available next week) depending on how it goes.
>> 
>> FWIW, I strongly share the concerns quoted above. I think it's a bad
>> idea to define shortcuts for language that doesn't exist yet. Once
>> SPARQL Update is a Rec and people begin using it, implementors will
>> receive feedback from users and begin implementing new syntactic forms
>> where needed, and these can be standardized the next time around. I fear
>> that including these sorts of shortcuts at this point raises the
>> learning curve and overall complexity of the language without having any
>> empirical evidence to go by that their value outweighs their cost.
> 
> The particular short cuts proposed correspond to key file manipulation operations (cp, mv, cat >>) which do form a common set of operations and are proven elsewhere for handling files.
> 
> I don't agree with the raising the learning curve argument if we have to teach the complicated way to do certain common operations.
> 

Right, I don't think that these shortcuts raise the learning curve - actually, I see them as a way to lower that curve, especially for people that learn SPARQL from scratch (i.e. not using the current SPARQL Update member submission).

> I don't think the use cases of temporary graphs are strong enough in themselves but because manipulating files, and SPARQL HTTP Update for PUT, GET and POST/append operations, form a common;y understood set of operations, I think it's worth considering.
> 
> Maybe underlying Alex's suggestion might be the idea that SPARQL Update might be used interactively for data management.

Well, besides the temporal graphs use-case, I'm indeed seeing these operations as an easy way to aggregate / transmit data from / between different graphs.

E.g. :

I want to add dbpedia data into my default graph: "ADD <http://dbpedia.org/data/SPARQL> INTO DEFAULT"
Then, I want to create a new DEFAULT graph every X days, but keep the previous state somewhere (overall and per-period). "
COPY DEFAULT INTO <http://example.org/backup>
MOVE DEFAULT INTO <http://example.org/timestamp>
"

etc.

I still believe that these shortcuts (as pointed out by Andy, coming from known shell command), might reduce the learning curve for such use-cases.

Alex.

> 
> 	Andy
> 
>> 
>> Lee
>> 
>>> 
>>> Alex.
>>> 
>>> [1] http://www.w3.org/2009/sparql/track/issues/24
>>> [2] http://www.w3.org/2009/sparql/meeting/2010-01-12#resolution_8
>>> [3]
>>> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0676.html
>>> 
>>> --
>>> Dr. Alexandre Passant
>>> Digital Enterprise Research Institute
>>> National University of Ireland, Galway
>>> :me owl:sameAs<http://apassant.net/alex> .
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> Please consider the environment before printing this email.
>> 
>> Find out more about Talis at http://www.talis.com/
>> shared innovation™
>> 
>> Any views or personal opinions expressed within this email may not be
>> those of Talis Information Ltd or its employees. The content of this
>> email message and any files that may be attached are confidential, and
>> for the usage of the intended recipient only. If you are not the
>> intended recipient, then please return this message to the sender and
>> delete it. Any use of this e-mail by an unauthorised recipient is
>> prohibited.
>> 
>> Talis Information Ltd is a member of the Talis Group of companies and is
>> registered in England No 3638278 with its registered office at Knights
>> Court, Solihull Parkway, Birmingham Business Park, B37 7YB.

--
Dr. Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
:me owl:sameAs <http://apassant.net/alex> .

Received on Monday, 19 July 2010 14:17:59 UTC