Re: Graph Fragments Templates

Ivan,

What I gave was a description of the graph templating approach.  It is 
not a complete spec.   As I see it, we are trying to establish the scope 
of part of the technical work of the working group and Jeremy's example 
is a (the) example we have of CSV to RDF conversion.

Part of the scoping is the relationship of metadata to conversion.

The metadata is about what the CSV file "is", and details about it's 
publication.  So it is not capturing everything about the conceptual 
information that is CSV file is about.

An explicitly provided template for RDF conversion is what the user 
wants and puts in structure that isn't obvious from the CSV file alone 
nor declared in the metadata.

They may be different; it may be intended.  The authorship roles are 
different.

Metadata is going help display CSV files in HTML and it's a great help 
in finding CSV files on the web, and validating them. Metadata comes 
primarily from the data publisher. An advanced template comes from the 
data consumer and is the format use by the conversion tool.

Only deriving conversion from metadata makes assumptions about the 
emergence of provided metadata - I doubt that metadata info for existing 
CSV publications is going to emerge quickly and there is a lot of 
existing CSV data.  It seems dubious to me to assume the data consumer 
is going to write missing metadata to drive flat conversion, when they 
still have further steps to perform to get what they want.

When there is CSV publisher, and data consumer wanting RDF (or JSON, or 
XML), so they aren't reading the CSV file directly as CSV, all you need 
is a template, written by the data consumer, and a tool that processes 
templates.

	Andy

On 22/05/14 15:18, Ivan Herman wrote:
> Hi Andy,
>
> thanks.
>
> My problem is not with these simple cases. My problem is to understand how templates will be combined with the metadata definition in general; at the moment these are fairly disconnected.
>
> Looking at the latest draft of Jeni, each field may have its own particular set of properties (although some of them can be set for the column as a whole, it can be specialized for a specific field). This means that a pattern of the sort
>
> 	<something> <something> {colname} .
>
> may become slightly underspecified. For example, in your example, you translated the metadata including a datatype definition into something like
>
> 	<something> <something> {colname}^^xsd:double
>
> but that may not be o.

Only deriving conversion from metadata makes assumptions about the 
emergence of provided metadata - I doubt that metadata info for existing 
CSV publications is going to emerge quickly and there is a lot of 
existing CSV data.  It seems dubious to me to assume the data consumer 
is going to write missing metadata to drive flat conversion, when they 
still have further steps to perform to get what they want.  Instead, 
they'll write code to go CSV to what they want.

When there is CSV publisher, and data consumer wanting RDF (or JSON, or 
XML), so they aren't reading the CSV file directly as CSV, all you need 
is a template, written by the data consumer, and a tool that processes 
templates.k.; it should be something like
>
> 	<something <something> {colname}^^xsd:{{datatype}}
>
> where '{{datatype}}' is my ad-hoc syntax to denote the _value_ of the property "datatype". Actually, it may become more complicated insofar as the datatype value should probably not be taken verbatim, ie, if it says 'number', than it should be translated to its xml schema counterpart (either we include an if-then-else into the template language or we have to write down a specification on how exactly the template processor works for each field and its properties). Another example is the 'separator' field; if a field includes a 'separator' property, then the result of the template expansion may become something like
>
> 	<something> <something> (l1 l2 l3 l4) .
>
> It all can be done of course. But, unless we keep the templates completely disjoint from the metadata (which I think would be a mistake) we have quite some work to do reconciling the templates with the metadata definition:-( Did you have any thought on that already?
>
> Ivan
>
> P.S. Sorry, I am off-line at the moment due to a power outage, I cannot check Gregg's older document; maybe he did deal with these.
>
>
>
> On 21 May 2014, at 19:46 , Andy Seaborne <andy@apache.org> wrote:
>
>> I have written up more on graph templates:
>>
>> https://github.com/w3c/csvw/blob/gh-pages/examples/graph-templating.md
>>
>> 	Andy
>>
>
>
> ----
> 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, 27 May 2014 10:56:34 UTC