Re: Call for Editors!

Gregg Kellogg
gregg@greggkellogg.net

On Mar 21, 2014, at 10:22 AM, Andy Seaborne <andy@apache.org> wrote:

> On 21/03/14 16:54, Gregg Kellogg wrote:
>> On Mar 21, 2014, at 4:04 AM, Andy Seaborne <andy@apache.org> wrote:
>> 
>>> On 20/03/14 23:47, Gregg Kellogg wrote:
>>>> On Mar 20, 2014, at 10:53 AM, Ivan Herman <ivan@w3.org> wrote:
>>>> 
>>>>> Sorry if I sound like a broken record, but I would really like
>>>>> to see and understand the CSV->RDF use cases, also in terms of
>>>>> the people who are likely to use that. Learning CSV-LD or
>>>>> R2RML-CSV requires a learning curve. The question is which of
>>>>> the two is steeper for the envisaged user base.
>>>> 
>>>> The CSV-LD use case involves first constructing a CSV-LD mapping
>>>> frame (basically a JSON-LD context for mapping the column
>>>> headings and using that within the body of the JSON-LD as
>>>> described in the Wiki). * Subsequently, using the CSV-LD mapping
>>>> frame, use it along with the CSV to generate a JSON-LD document.
>>>> * For other JSON-LD expressions, run additional framing steps *
>>>> For RDF, run JSON-LD to RDF conversion steps
>>>> 
>>>> For extra credit, when generating RDF, we can compact these steps
>>>> so that RDF is streamed out as the CSV is processed, but running
>>>> the JSON-LD to RDF algorithm on each record as it is mapped to
>>>> JSON-LD.
>>>> 
>>>> The Direct mapping use case can be handled by recognizing the
>>>> absence of a CSV-LD mapping frame and generating one based on the
>>>> column headers treating each field as a string and issuing a
>>>> sequence of unnamed (or row-fragment identifier named) JSON-LD
>>>> nodes for each record.
>>>> 
>>>> The CSV-LD use case is most appropriate for someone already
>>>> familiar with JSON-LD, and is looking to get CSV into that form.
>>>> An understanding of JSON-LD is necessary to create a mapping
>>>> frame, but is not required to use the CSV along with a provided
>>>> mapping frame.
>>>> 
>>>> Gregg
>>>> 
>>> 
>>> Gregg,
>>> 
>>> Is CSV-LD addressing CSV->JSON or CSV->RDF? both?
>> 
>> As with JSON-LD, it address both JSON and RDf mappings.
> 
> As output syntax or as metadata syntax?

It accomplishes both. The metadata syntax is partly in the context (which can be shared by all records) and partly in the JSON template. By applying a CSV to the template, you directly transform to the output syntax. Once you have it as JSON-LD, you can use other JSON-LD tools, such as framing, to change the look of the data further; for instance, collapsing duplicate record definitions.

Gregg

>>> CSV-LD is one possibility for CSV->RDF.
>>> 
>>> N-Triples is the format used for triple store loading.
>>> 
>>> I would want to be sure that going CSV -> N-triples does not end up
>>> assuming a JSON-LD+@extension+framing extension stack.
>> 
>> If some metadata is required to do such a mapping, then it will
>> require some format for specifying that.  The CSV-LD mapping frame is
>> (IMO) a natural way to express this for mapping to JSON. Certainly,
>> there are many other ways it could be done for a straight-to-RDF
>> mechanism, such as R2RML or TARQL. Leaving aside that JSON-LD _is_
>> just as much RDF as any other serialization format, the fact that
>> triples (or quads) pop out of this is a happy by-product.
>> 
>>> There might be other ways - perl/ruby/sed/awk/... doing a textual
>>> rewrite should be possible as well.  If not, we need a strong use
>>> case to show why not.
>> 
>> I do custom CSV to RDF work in RDF all the time, the point is
>> defining a generic mapping that can be implemented on a variety of
>> platforms. This means defining a metadata/mapping format.
>> 
>>> So I'd rather see the spec define the output, showing the RDF
>>> triples that come from the CSV.  Just defining the algorithm is I
>>> believe a barrier to other transformation mechanisms.
>>> 
>>> CSV-LD is one way to do that makes it especially useful for the
>>> JSON-LD world.
>>> 
>>> Andy
>> 
>> Gregg
>> 
> 

Received on Friday, 21 March 2014 17:36:23 UTC