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

AndyS> 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?)

Gregg> I'm not sure if this is driven by a requirements; I'm not sure why we need to drop legal URI characters from a transformation.

In this particular case I was just be deliberately awkward as is the want of many users ... I just wanted the local identifier in the URI to be numbers and letters - irrespective of whether "-" and ":" are legal characters in a URI or not!

Jeremy

-----Original Message-----
From: Gregg Kellogg [mailto:gregg@greggkellogg.net] 
Sent: 03 April 2014 18:08
To: Andy Seaborne
Cc: public-csv-wg@w3.org
Subject: Re: simple weather observation example illustrating complex column mappings (ACTION-11)

On Apr 3, 2014, at 4:59 AM, Andy Seaborne <andy@apache.org> wrote:

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

I also wasn't considering that OWL would be necessary, but in the case of CSV-LD, I do presume that transformation of field values into JSON-LD is informed by the datatype associated with the property definition in the context. For a pure RDF form, unless we invent something, using OWL Restrictions to indicate this might be a similar way to go.

> 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?)

I'm not sure if this is driven by a requirements; I'm not sure why we need to drop legal URI characters from a transformation.

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

This may be taking things too far, but we could consider referencing an XSLT for doing specific format transformations. For example, see this on parsing dateTime: http://stackoverflow.com/questions/17079954/convert-date-time-format-in-xslt.

Gregg

> 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 22:04:57 UTC