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

Re: CSV-LD proposal

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Wed, 26 Feb 2014 19:09:24 -0800
Cc: Linked JSON <public-linked-json@w3.org>, CSV on the Web Working Group <public-csv-wg@w3.org>
Message-Id: <EC3AD378-73AF-4608-9DC6-6D38D48ED6CF@greggkellogg.net>
To: Niklas Lindström <lindstream@gmail.com>
On Feb 26, 2014, at 9:07 AM, Niklas Lindström <lindstream@gmail.com> wrote:

> Hi Gregg,
> 
> Interesting stuff!
> 
> Have you looked at TARQL [1]? From my experience, turning CSV into RDF often turn out to require way more transformation than a simple mapping like JSON-LD can handle. I have commonly used Python for that (e.g. [2]), but I've found TARQL to be an interesting, somewhat more constrained (functional, more declarative) alternative.

Cool. I added a reference to the tools page on the CSV WG Wiki: https://www.w3.org/2013/csvw/wiki/Tools#TARQL

> Also, perhaps tangentially related: some years ago I built a mechanism for turning SPARQL select results into JSON, called SparqlTree [3]. (See e.g. the JS implementation example at [4]. I know, the output could easily be made JSON-LD compatible. I really should...) But that works well since you're in full control of the resulting rows.
> 
> I do agree that JSON-LD itself should not be extended with transformational features. But in combination with a JSON transformation language, something valuable might emerge. Perhaps JSON-LD Marcros would work? In a chain like CSV -> JSON -> Macros -> JSON-LD.

IMO, the way to do this is based on the JSON-LD Framing syntax, but it really just relates to the format of the frame document, and does not involve any actual framing algorithm. Therefore, I think any transformation requirements can be contained to a CSV-LD specification.

Manu suggested a telegraphing mechanism to indicate within a document, such as a CSV-LD frame, that it is extended via another specification; that is, the JSON-LD formatted document is syntactically extended via another specification, CSV-LD in this case.

> In any case, something like TARQL is needed to add additional statements (types etc.), to construct values and IRIs, and to build up additional (b)nodes out of the flat digests of tables. I.e. full-fledged transformations, needing rich expressions. (Also, I really like the clean directness of TARQL in going from CSV to RDF. It all depends on what you need of course.)

CSVs inevitably have microformatted cells, and there will be a need to construct identifiers and relationships. This is another reason that these details should be left to another spec.

Alf Eaton mentioned the Simple Data Format (SDF) [5] which does has schema/field definitions that might just fit the bill.

Gregg

[5] http://dataprotocols.org/simple-data-format/

> Cheers,
> Niklas
> 
> [1]: https://github.com/cygri/tarql
> [2]: https://github.com/libris/skillingtryck/blob/master/sheets_to_rdf.py
> [3]: https://code.google.com/p/oort/wiki/SparqlTree
> [4]: http://js.oort.googlecode.com/hg/examples/dbpedia_nations.html
> 
> 
> 
> On Sat, Feb 1, 2014 at 3:03 AM, Gregg Kellogg <gregg@greggkellogg.net> wrote:
> FYI, the CSV on the Web working group is essentially trying to do for CSV (and other tabular formats) what JSON-LD did for JSON. I've put forward a CSV-LD proposal [1].
> 
> Doing this would require standardizing framing, with some extensions to the existing algorithms, as I note within the document, this could mean using embedded context definitions within a frame to compact embedded nodes using the most specific context definition; I created issue 315 [2] to describe this further.
> 
> Gregg Kellogg
> gregg@greggkellogg.net
> 
> [2] https://github.com/json-ld/json-ld.org/issues/315
> 
> Begin forwarded message:
> 
> > From: Gregg Kellogg <gregg@greggkellogg.net>
> > Subject: CSV-LD proposal
> > Date: January 31, 2014 at 5:52:09 PM PST
> > To: public-csv-wg@w3.org
> >
> > 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
> >
> 
> 
> 
Received on Thursday, 27 February 2014 03:09:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:39 UTC