- From: Niklas Lindström <lindstream@gmail.com>
- Date: Wed, 26 Feb 2014 18:07:52 +0100
- To: Gregg Kellogg <gregg@greggkellogg.net>
- Cc: Linked JSON <public-linked-json@w3.org>
- Message-ID: <CADjV5jeo2fT1LMeu8czWH7yfdjAmFxnF1a9jHFw+WnRwkh8t7g@mail.gmail.com>
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. 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. 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.) 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 Wednesday, 26 February 2014 17:08:49 UTC