W3C home > Mailing lists > Public > public-csv-wg-comments@w3.org > February 2014

Re: Suggested requirement: A CSV+ Direct Mapping to RDF

From: David Booth <david@dbooth.org>
Date: Fri, 21 Feb 2014 15:12:13 -0500
Message-ID: <5307B31D.3020504@dbooth.org>
To: Dan Brickley <danbri@google.com>
CC: public-csv-wg-comments@w3.org


On 02/21/2014 07:07 AM, Dan Brickley wrote:
>
> On 20 Feb 2014 21:25, "David Booth" <david@dbooth.org
> <mailto:david@dbooth.org>> wrote:
>  >
>  > Above all else, regardless of what other features the working group
> may choose to define, please define a standard *CSV+ *Direct Mapping**
> from any CSV+ table to RDF.
>  >
>  > By "CSV+ Direct Mapping" I mean a mapping that is fully defined even
> in the absence of any information that is not contained directly within
> the target table.  In particular, a Direct Mapping must be fully defined
> even in the absence of any table metadata or mapping rules.
>  >
>  > Thanks!
>  > David Booth
>
> Care to ground this request in a use case writeup - i.e. how it might be
> useful in real life? What problem would it solve, and for whom?

Sure.  Would the following be adequate?

[[
Title: CSV+ Direct Mapping

The overall goal is to be able to predictably view all data uniformly as 
RDF, even though it may be serialized in a wide variety of formats, 
including those that are not natively RDF serializations, such as CSV+. 
  Independent parties using different tools should see the same 
information when viewing CSV+ data as RDF.

A key reason for using a direct mapping -- whether for CSV+, relational 
data or anything else -- is to cleanly separate the *syntactic* issue of 
mapping non-native-RDF formats to RDF, from the *semantic* issue of 
model alignment, in which model transformations are routinely needed. 
By standardizing the direct mappings, RDF-to-RDF transformations can be 
more readily shared, because they can assume a predictable starting 
point based on the direct mapping.

For example, Alice, using the W3C-compliant AlphaWorks Uniform RDF 
Deserializer, reads a CSV+ spreadsheet from http://example/table.tsv . 
The AlphaWorks Deserializer, following W3C standards, finds no 
information about the spreadsheet beyond what is contained in table.tsv 
itself.  Thus, it uses the default **CSV+ Direct Mapping** to interpret 
the spreadsheet as RDF.

Bob, using the W3C-compliant BetaTech Universal RDF Slurper, reads the 
same CSV+ spreadsheet from http://example/table.tsv .  The BetaTech 
Slurper, following W3C standards, also finds no information about the 
spreadsheet beyond what is contained in table.tsv itself.  Thus, it too 
uses the default **CSV+ Direct Mapping** to interpret the spreadsheet as 
RDF.

Alice and Bob then talk by phone about the RDF content of the 
spreadsheet.  Because they know that their software has following the 
W3C standards, they are assured that they are talking about the *same* 
RDF graph (or at least isomorphic).  This makes them much happier than 
they were before standardization, because it allows them to share 
RDF-to-RDF transformations that can be applied to the resulting RDF 
graph.  Prior to standardization, they were unable to share RDF-to-RDF 
transformations, because their RDF deserializers produced different RDF 
from the same CSV+ data.
]]

Thanks,
David
Received on Friday, 21 February 2014 20:12:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:27:51 UTC