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