- From: Andy Seaborne <andy.seaborne@talis.com>
- Date: Mon, 19 Jul 2010 14:32:52 +0100
- 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 UTC