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

RE: Attempted example CSV metadata document and template

From: Tandy, Jeremy <jeremy.tandy@metoffice.gov.uk>
Date: Tue, 24 Jun 2014 19:38:18 +0000
To: Ivan Herman <ivan@w3.org>
CC: Andy Seaborne <andy@apache.org>, W3C CSV on the Web Working Group <public-csv-wg@w3.org>
Message-ID: <2624871D9A05174691BD59F8EFD68AE20884CBEB@EXXCMPD1DAG3.cmpd1.metoffice.gov.uk>
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?

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:38:47 UTC

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