Re: CSV-LD proposal

Hey Gregg,

- A clarification please... In the section on Table Join representation[1] you say 'Data such as this does not readily transform to JSON-LD'. I want to understand this better.

It is correct, isn't it, that you can transform that into a set of JSON-LD objects, one row per object (in RDF terms, a row into a set of properties having a common bnode subject, each row being a different one). I guess what you mean is that, in ideal term, you want a mapping resulting in what you describe in the Entity mapping section[2], ie, making use of the fact that these have similar subjects. 

The similar issue in the RDB Direct Mapping spec[3] is taken care of by the fact that, in a relational database, one may have a primary key; in the direct mapping, if there is a primary key in a table, that (well, a URI representation thereof) will be chosen as the common subject (instead of a blank node). Isn't this what you are looking for?

Putting this into this context, I believe the issue is what will the metadata of the CSV file contain; that metadata (whose definition is one of the goals of this WG!) may do exactly that: designate one column as the 'primary key'. Once that is done, mapping into JSON (but, probably, XML and of course RDF) becomes way more obvious. 

Is this what you call an 'entity mapping' to JSON(-LD)?

- As for the general approach: I think there are similarities to the mapping of JSON, XML, and RDF that we have to exploit. I would probably look at [3] for a general line of thoughts, which may be moderated by some metadata (nothing as complex as R2RML[4], though) like the primary key above. I would leave XML aside for a moment; I guess what would be very important for our users is indeed, as you propose, to map the CSV file on JSON but following as much as we can the JSON-LD structures, so that the result can be turned into RDF if necessary by a suitable @context (and that @context may also be generated through the metadata). Ie, if somebody just wants JSON and does not even want to utter the term 'RDF', then that is fine, he/she can use JSON; if somebody wants RDF for whatever reasons, then, say, the @context+JSON -> Turtle mapping is already provided by current specifications.

Thx

Ivan



[1] https://www.w3.org/2013/csvw/wiki/CSV-LD#Table_Join_representation
[2] https://www.w3.org/2013/csvw/wiki/CSV-LD#Entity_Mapping
[3] http://www.w3.org/TR/rdb-direct-mapping/
[4] http://www.w3.org/TR/r2rml/

On 01 Feb 2014, at 02:52 , Gregg Kellogg <gregg@greggkellogg.net> wrote:

> I added a proposal for something I call CSV-LD to the wiki [1]. As the name might suggest, this is strongly tied to JSON-LD, and uses JSON-LD context and frame definitions to both provide meaning to CSV, allowing it to be losslessly transformed to JSON-LD, or to create CSV from JSON-LD (with or without embedding).
> 
> Consider this a straw-man proposal. It does lay out some use cases that are generally useful (and perhaps should be copied to other pages on the wiki), but there may be more use cases to consider. IMO, creating a specification for this, and extending an existing JSON-LD implementation to support this would not be too difficult.
> 
> Gregg Kellogg
> gregg@greggkellogg.net
> 
> [1] https://www.w3.org/2013/csvw/wiki/CSV-LD
> 
> 


----
Ivan Herman, W3C 
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
GPG: 0x343F1A3D
FOAF: http://www.ivan-herman.net/foaf