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

RE: simple weather observation example illustrating complex column mappings (ACTION-11)

From: Tandy, Jeremy <jeremy.tandy@metoffice.gov.uk>
Date: Thu, 3 Apr 2014 12:13:55 +0000
To: Andy Seaborne <andy@apache.org>, "public-csv-wg@w3.org" <public-csv-wg@w3.org>
Message-ID: <2624871D9A05174691BD59F8EFD68AE208833749@EXXCMPD1DAG3.cmpd1.metoffice.gov.uk>
Is JSON-LD acceptable in place of a normal JSON encoding? Probably - thanks to the "zero-edit" capability of JSON-LD you can make JSON-LD look identical to JSON(sans-LD) ... even the @context reference can be done in an HTTP header.

I hadn't intended to imply that the conversion was driven by OWL; only that one can supplement these complex cases where you want to annotate _every_ field in a column with the same information (e.g. unit of measurement) by defining local object properties with the necessary axioms.

I like your idea of the processing pipeline ... I'll modify the example on GitHub to incorporate this string-formatting pre-processing step.

I'll mark ACTION-11 as complete too.


-----Original Message-----
From: Andy Seaborne [mailto:andy@apache.org] 
Sent: 03 April 2014 13:00
To: public-csv-wg@w3.org
Subject: Re: simple weather observation example illustrating complex column mappings (ACTION-11)

On 02/04/14 19:04, Tandy, Jeremy wrote:
> All,
> (related action #11 <https://www.w3.org/2013/csvw/track/actions/11>)
> I've created an "Example" directory in the github repo <https://github.com/w3c/csvw/tree/gh-pages/examples>, within which I have placed the example requested by AndyS et al in today's teleconference:
> simple-weather-observation 
> <https://github.com/w3c/csvw/blob/gh-pages/examples/simple-weather-obs
> ervation.md>
> It provides:
> - CSV example
> - RDF encoding (in TTL)
> - JSON-LD encoding (assuming my manual conversion is accurate)
> - CSV-LD mapping frame (or at least my best guess)
> In the mapping frame I couldn't figure out how to construct the @id for the weather observation instances as I wanted to use a simplified form of the ISO 8601 date-time syntax used in the "Date-time" column.
> Would be happy for folks to correct/amend what I've done :)
> AndyS / Greg - if this meets your need could you close the action? (I 
> left it in "pending review" state)
> Jeremy

Jeremy - thank you.

It more than meets the action item for the RDF part at least.

A question it raises for the JSON(sans -LD) conversion is whether the JSON-LD form is acceptable.  I have no in-sight there but it is something to test before going along a partcular spec'ing path.

I wasn't thinking that the conversion would necessarily be driven by OWL, leaving that for tools beyond/better than the core spec.  It is nice to be aware of the possibility.

If there are certain common conversions of ISO 8601 syntax for the date-time, we can include those conversion.  This one is drop certain legal URIs chars (":" and "-" timezone other than Z?)

My feeling is that a real-world issue is that datetime strings are all too often not valid in the first place (systematically or not) and so the error handling is important.

As CSV is a text format, string processing can be done before CSV2RDF conversion.  Clean-up is best done at that point a well.

Seems like a processing pipeline model is emerging.

Received on Thursday, 3 April 2014 12:14:24 UTC

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