W3C home > Mailing lists > Public > public-linked-json@w3.org > February 2014

Re: CSV-LD proposal

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:41 UTC