W3C home > Mailing lists > Public > semantic-web@w3.org > November 2018

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

From: David Booth <david@dbooth.org>
Date: Thu, 29 Nov 2018 10:47:29 -0500
To: semantic-web@w3.org
Cc: Hugh Glaser <hugh@glasers.org>
Message-ID: <2de06c40-6ab7-ce79-4453-f87401015760@dbooth.org>
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
Received on Thursday, 29 November 2018 15:47:52 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 November 2018 15:47:52 UTC