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

On 03/04/14 23:04, Tandy, Jeremy wrote:
> 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!

It's a good deliberately awkward case because ":" is different to other 
characters.  It can't be in the initial segment of a relative URI where 
it would be confused with a URI scheme name i.e an absolute URI.

<2014-04-06T17:09:44.703+01:00>

is illegal.

<something/2014-04-06T17:09:44.703+01:00>

is legal.

relative-part = "//" authority path-abempty
                 / path-absolute
                 / path-noscheme
                 / path-empty

--->> This rule:
    path-noscheme = segment-nz-nc *( "/" segment )
...
    segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
                  ; non-zero-length segment without any colon ":"


	Andy

>
> 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 Sunday, 6 April 2014 16:18:44 UTC