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

Some related thoughts about JSON and RDF conversions:

- Conversion to JSON(sans-LD) would work with the mapping frame as defined by Gregg - there would simply be no @context section in the template

- If you want ntriples, ttl or other RDF encoding one could extend the processing pipeline methodology to convert the JSON-LD to the requisite form as defined in the JSON-LD Processing Algorithms and API <http://www.w3.org/TR/json-ld-api/#rdf-serialization-deserialization-algorithms>

Jeremy 

  

 
-----Original Message-----
From: Tandy, Jeremy [mailto:jeremy.tandy@metoffice.gov.uk] 
Sent: 03 April 2014 13:14
To: Andy Seaborne; public-csv-wg@w3.org
Subject: RE: simple weather observation example illustrating complex column mappings (ACTION-11)

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.

Jeremy

-----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.

	Andy

Received on Thursday, 3 April 2014 13:04:45 UTC