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

Re: IRI Templates

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Fri, 21 Feb 2014 10:16:33 -0800
Cc: Linked JSON <public-linked-json@w3.org>, W3C CSV on the Web Working Group <public-csv-wg@w3.org>, public-csv-wg-comments@w3.org
Message-Id: <CB4C9320-EE3C-48AE-952E-F0F5935EC465@greggkellogg.net>
To: Markus Lanthaler <markus.lanthaler@gmx.net>
On Feb 21, 2014, at 2:12 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> +CC public-csv-wg(-comments)
> 
> 
> On Friday, February 21, 2014 6:33 AM, David Booth wrote:
>> Personally, I would prefer not to overload JSON-LD this way.  This
>> essentially amounts to a transformation rule.  And although
>> transformation rules are useful and neede, I would prefer to have them
>> specified as a separate layer.
> 
> I've raised an issue regarding IRI templates 2 years ago [1] and we
> concluded back then to "not add any normative language relating to IRI
> templates or other transformations".
> 
> As is, framing is not really suitable for this as it expects the input to
> already be valid JSON-LD. I think what you want is a generic mechanism to
> map CSV to RDF. You can then easily serialize it (and frame it) in JSON-LD.
> 
> I haven't followed the work in the CSV WG at all till now but it appears to
> me that there exists already an (almost complete) solution that you could
> leverage: R2RML [2] (I'm sure this has already been discussed). If you add a
> way to reference a JSON-LD context or frame, you are quite close to what you
> want to achieve I think:
>  CSV -> RDF -> JSON-LD

You might glance at the CSV-LD wiki page [3], as I've proposed just using JSON-LD frames as a representational format that can be used to help map CSV to JSON-LD, so it's not really about a framing algorithm, but about using the frame representation to help map CSV column values into a JSON structure. As I said in a response to Manu, the IRI templates could be an extension made in the CSV-LD spec, and do not need to be described as any part of JSON-LD directly.

Gregg

> Cheers,
> Markus
> 
> 
> [1] https://github.com/json-ld/json-ld.org/issues/108
> [2] http://www.w3.org/TR/2012/REC-r2rml-20120927/
[3] https://www.w3.org/2013/csvw/wiki/CSV-LD
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 
> 
> 
>> On 02/20/2014 08:50 PM, Gregg Kellogg wrote:
>>> As part of work on the CSV WG, I've put forward the concept of CSV-LD
>>> [1]. As I've discussed before, the idea is to use something like a
>>> JSON-LD frame to map column values in a CSV to turn it into JSON-LD.
>>> 
>>> I discussed the idea of IRI Templates (really @id templates) on the
>>> mailing list [2]. The idea is that fields in a CSV may be used to
>>> identify entities, but they may not explicitly include an identifier.
>>> In some cases, it may take two columns to determine a unique
>>> identifier, for example when a database dump has a composite primary
>>> key.
>>> 
>>> The idea I had is that one or more column values might be used to
>>> create a template for an IRI or Blank Node. This concept might be
>>> more generally useful for JSON-LD framing, but I wanted to get some
>>> reaction from this list. From the email:
>>> 
>>> [[[ I've been hand-waving around this, but one way to do this might
>>> be to extend the context definition to describe identifier
>>> templates:
>>> 
>>> { "region_id": {"@id": "_:{Sales Region}", "@type": "@idTemplate"} }
>>> 
>>> I'm sure we can do much better, but the basic idea is that column
>>> values can be used within a template used to construct an IRI or
>>> BNode identifier, using some suitable rules. We could then use
>>> "region_id" in the frame, with the understanding that it will be
>>> expanded using the template defined in the context.
>>> 
>>> { "@id": "region_id", "@type": "ex:SalesRegion", "Sales Region":
>>> null, "ex:period": { "@type": "ex:SalesPeriod", "Quarter": null,
>>> "Sales": null } } ]]]
>>> 
>>> The idea would be that if a term is of type @idTemplate, it could be
>>> used as a key or value (in this case, the value of @id), and it would
>>> be processed based on other properties of the associated node ("Sales
>>> Region" here). Obviously, this would require some normalization as
>>> well, so that the result would be legal. A more complete example
>>> would be the following:
>>> 
>>> { "@context": { "dc": "http://purl.org/dc/terms/", "rdf":
>>> "http://www.w3.org/1999/02/22-rdf-syntax-ns#", "ex":
>>> "http://example/", "Sales Region": "dc:title", "Quarter":
>>> "dc:title", "Sales": "rdf:value", "region_id": {"@id": "_:{Sales
>>> Region}", "@type": "@idTemplate"} }, "@id": "region_id", "Sales
>>> Region": null, "ex:period": { "Quarter": null, "Sales": null } }
>>> 
>>> I suppose that filling in the template term would be part of
>>> compaction, and the @idTemplate would allow such a term to be used as
>>> the value of @id. This could presumably be done in a CSV-LD spec, but
>>> it might be more generally useful as part of JSON-LD Framing.
>>> 
>>> Thoughts?
>>> 
>>> Gregg Kellogg gregg@greggkellogg.net
>>> 
>>> [1] https://www.w3.org/2013/csvw/wiki/CSV-LD [2]
>>> http://lists.w3.org/Archives/Public/public-csv-wg/2014Feb/0119.html
>>> 
>>> 
>>> 
> 
> 
Received on Friday, 21 February 2014 18:17:04 UTC

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