Re: RDF graph merging: How useful is it really? (was Re: Blank Nodes Re: Toward easier RDF: a proposal)


 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.

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).


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:
> 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
Tél:+33(0)4 77 42 66 03
Fax:+33(0)4 77 42 66 66
Member of team Connected Intelligence, Laboratoire Hubert Curien

Received on Thursday, 29 November 2018 17:03:41 UTC