W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2010

Re: Shortcuts in Update

From: Andy Seaborne <andy.seaborne@talis.com>
Date: Mon, 19 Jul 2010 14:32:52 +0100
Message-ID: <4C445404.5060508@talis.com>
To: Lee Feigenbaum <lee@thefigtrees.net>
CC: Alexandre Passant <alexandre.passant@deri.org>, SPARQL Working Group <public-rdf-dawg@w3.org>


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.

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.

	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.
Received on Monday, 19 July 2010 13:33:19 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:43 GMT