- From: Antoine Zimmermann <antoine.zimmermann@emse.fr>
- Date: Thu, 29 Nov 2018 18:02:56 +0100
- To: David Booth <david@dbooth.org>, semantic-web@w3.org
- Cc: Hugh Glaser <hugh@glasers.org>
David, From what you are describing, it seems that you may be in need of our nice language and tool, SPARQL-Generate (SG). SG introduces many improvements to SPARQL (while keeping the core syntax as SPARQL) so that you can pretty do all the Extract-Tranform fom heterogeneous data to RDF graphs, all in SPARQL. https://ci.mines-stetienne.fr/sparql-generate/ Sorry for the sameful advertisement, but you may actually like it :) There are loops and cool syntax sugar that makes it nicely concise. At the moment, we cannot generate named graphs though, or load the results directly in a triple store (it's in the todo list). --AZ Le 29/11/2018 à 16:47, David Booth a écrit : > On 11/28/18 4:58 PM, Hugh Glaser wrote: >> I used to process the stuff coming in, from csv, PDO, RDF or whatever, >> into the RDF I wanted as I imported it. >> Now, I am experimenting with doing it differently. >> I simply, and of course can quite quickly, convert the input into RDF >> using the most naive RDF structure possible. > > That is *exactly* the process that I advocate also, as illustrated on > slide 53: > http://tinyurl.com/YosemiteRoadmap20150709slides > > That process has the benefit of: (a) retaining *all* of the source > information; and (b) cleanly separating the other-to-RDF "lift" > translations, most of which can be performed using generic tools, from > custom RDF-to-RDF translations that are needed to align or connect each > data source to the desired RDF data model. > > However, I do still feel that the mechanisms available for RDF-to-RDF > translation -- conventional or non-conventional "rules" languages -- are > not as convenient as they could be. I have used SPARQL most often for > this task (specifically SPARQL INSERT, rather than CONSTRUCT, so that I > can put the result directly into another named graph), but SPARQL is > verbose and lacks the convenience of a general purpose programming > language, such as loops. > > BTW, another gap in SPARQL that I have felt, and that Bryan Thompson > aptly suggested a few years ago, is that SPARQL does not provide any > mechanism for naming or saving solution sets, even though they are a > fundamental concept in SPARQL. On a number of occasions I have wished > that I could save an intermediate result set and then refer to it later, > in producing final results. > > David Booth > -- Antoine Zimmermann Institut Henri Fayol École des Mines de Saint-Étienne 158 cours Fauriel CS 62362 42023 Saint-Étienne Cedex 2 France Tél:+33(0)4 77 42 66 03 Fax:+33(0)4 77 42 66 66 http://www.emse.fr/~zimmermann/ Member of team Connected Intelligence, Laboratoire Hubert Curien
Received on Thursday, 29 November 2018 17:03:41 UTC