- From: David Booth <david@dbooth.org>
- Date: Fri, 28 Feb 2014 12:10:54 -0500
- To: Richard Cyganiak <richard@cyganiak.de>
- CC: Niklas Lindström <lindstream@gmail.com>, Gregg Kellogg <gregg@greggkellogg.net>, public-csv-wg@w3.org
On 02/28/2014 10:15 AM, Richard Cyganiak wrote:
> On 26 Feb 2014, at 21:28, David Booth <david@dbooth.org> wrote:
>
>> [Excerpted from the public-linked-json@w3.org list]
>>
>> On 02/26/2014 12:07 PM, Niklas Lindström wrote:
>>> Have you looked at TARQL [1]? [ . . . ] [1]:
>>> https://github.com/cygri/tarql
>>
>> Interesting! It looks like a shortcut combination of an implied
>> CSV Direct Mapping to RDF, followed by a SPARQL CONSTRUCT query to
>> transform the native RDF model to the desired RDF model.
>
> Not quite. There is no implied CSV Direct Mapping to RDF triples.
Right, directly mapped RDF triples are not materialized or specifically
identified. But what I meant was that tarql could be viewed as a
shortcut over an implicit two step process: instead of going in two
steps from A to B to C, tarql takes a shortcut from A to C, where A is
the CSV, B is direct-mapped RDF, and C is the transformed RDF produced
by the CONSTRUCT clause.
For example, if companies.csv contains:
Stock_ticker,CIK,LEI
IBM,cik1,lei1
MSFT,cik2,lei2
then, assuming the tarql --header option, the following example tarql
query (taken from https://github.com/cygri/tarql )
CONSTRUCT {
?URI a ex:Organization;
ex:name ?NameWithLang;
ex:CIK ?CIK;
ex:LEI ?LEI;
ex:ticker ?Stock_ticker;
}
FROM <file:companies.csv>
WHERE {
BIND (URI(CONCAT('companies/', ?Stock_ticker)) AS ?URI)
BIND (STRLANG(?Name, "en") AS ?NameWithLang)
}
OFFSET 1
could be viewed as a shortcut equivalent to doing a direct mapping to
RDF like this (following the style of the W3C relational Direct Mapping):
<companies/ROWNUM=1> # ROWNUM treated as primary key
<companies#ROWNUM> 1 ; # ?ROWNUM is magic in tarql
<companies#Stock_ticker> "IBM" ;
<companies#CIK> "cik1" ;
<companies#LEI> "lei1" .
<companies/ROWNUM=2>
<companies#ROWNUM> 2 ;
<companies#Stock_ticker> "MSFT" ;
<companies#CIK> "cik2" ;
<companies#LEI> "lei2" .
followed by a regular SPARQL CONSTRUCT query like this:
PREFIX ex: <companies#>
CONSTRUCT {
?URI a ex:Organization;
ex:name ?NameWithLang;
ex:CIK ?CIK;
ex:LEI ?LEI;
ex:ticker ?Stock_ticker;
}
WHERE {
#####################################
_:r ex:ROWNUM ?ROWNUM ; # This section is
ex:Stock_ticker> ?Stock_ticker ; # auto-generated
ex:CIK ?CIK ; #
ex:LEI ?LEI . #
#####################################
BIND (URI(CONCAT('companies/', ?Stock_ticker)) AS ?URI)
BIND (STRLANG(?Name, "en") AS ?NameWithLang)
}
tarql doesn't say anything about what the directly mapped RDF would look
like, but by specifying the available bindings it does imply a certain
information content that includes things like ?ROWNUM. So although
tarql isn't a ready-made candidate for a CSV+ Direct Mapping, I think it
does give some good ideas and hints about what a CSV+ Direct Mapping
might include, such as ?ROWNUM.
David
>
> Instead, the input CSV table is directly translated to a SPARQL
> solution set, which is also a table. The solution set can then be
> further manipulated using SPARQL filters, SPARQL bind, other SPARQL
> constructs, and then finally turned into a set of triples using a
> CONSTRUCT template.
>
> Best, Richard
>
>
>
>> Maybe the implied CSV Direct Mapping convention that it uses should
>> be considered as a candidate for a CSV+ Direct Mapping.
>>
>> David
>
>
>
>
Received on Friday, 28 February 2014 17:11:23 UTC