Re: Attempted example CSV metadata document and template

On 24 June 2014 20:38, Tandy, Jeremy <jeremy.tandy@metoffice.gov.uk> wrote:
> I see where you're going with this. Perhaps it would be good to get some thoughts & insight from the rest of the team at tomorrow's teleconf?

Talking of which, I should've sent
https://www.w3.org/2013/csvw/wiki/Meeting_Agenda_2014-06-24 around.
Jeni will chair. I will try to get the test case repo proposal
together (which I've been promising for 2-3 weeks) circulated before
the call. Sorry I've not managed to get it done sooner :(

Do we have a scribe volunteer?

Dan

> Jeremy
>
>> -----Original Message-----
>> From: Ivan Herman [mailto:ivan@w3.org]
>> Sent: 24 June 2014 16:06
>> To: Tandy, Jeremy
>> Cc: Andy Seaborne; W3C CSV on the Web Working Group
>> Subject: Re: Attempted example CSV metadata document and template
>>
>> Hey Jeremy
>>
>> On 24 Jun 2014, at 16:24 , Tandy, Jeremy
>> <jeremy.tandy@metoffice.gov.uk> wrote:
>> <snip/>
>> >
>> >>
>> >> Moving the conditions from the metadata into the templates
>> themselves
>> >> seem to be less error prone (although ending up with essentially if-
>> >> the-else structures which may be a bit more complicated to
>> implement).
>> >> (Of course, we have the syntax issue on how to define the templates
>> >> so that it would also work well with XML, Turtle, and JSON as a
>> >> targeted output; lots of escape characters ahead...)
>> >
>> > It would be good to see these ideas encapsulated in examples; I think
>> it makes them easier to discuss!
>>
>> Right. What I had in mind is something like a template below. I did go
>> down into the weeds for the data itself, so the templates are,
>> semantically, probably wrong, but I think you would get the idea. The
>> templates has two 'if' branches triggered by one of the field name and
>> a matching regexp; if that regexp is not a match, the whole template is
>> ignored, otherwise it is used. I just used some of your condition
>> regexps:
>>
>> ex:{soc-detailed-occupation-code} a ex:SOC-DetailedOccupation ;
>> {{#{soc-detailed-occupation-code}.match("^,{3}\\d{2}-\\d{4},\\.*")}}
>>    skos:notation "{soc-detailed-occupation-code}" ; {{\#}} {{#{soc-
>> detailed-occupation-code}.match(""^,\\d{2}-\\d{2}0{2},{3}\\.*"")}}
>>    skos:somethign "else";
>> {{\#}}
>>    skos:prefLabel "{soc-title}" ;
>>    skos:broader ex:{soc-detailed-occupation-code/major-group-element}-
>> 0000,
>>                 ex:{soc-detailed-occupation-code/major-group-element}-
>> {soc-detailed-occupation-code/minor-group-element}00,
>>                 ex:{soc-detailed-occupation-code/major-group-element}-
>> {soc-detailed-occupation-code/minor-group-element}{soc-detailed-
>> occupation-code/broad-group-element}0 .
>>
>>
>> Ain't pretty, that is for sure (I used the mustache syntax) but maybe
>> it is understandable. The {...}.function notation is something we may
>> need for some other means anyway (e.g., {name}.urlencode() is something
>> that may come up...).
>>
>> I hope this makes it a bit clearer...
>>
>> Ivan
>>
>>
>> ----
>> Ivan Herman, W3C
>> Digital Publishing Activity Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> GPG: 0x343F1A3D
>> WebID: http://www.ivan-herman.net/foaf#me
>>
>>
>>
>>
>
>

Received on Tuesday, 24 June 2014 19:45:46 UTC