Re: Another point (was Re 2: JSON mapping document is now ready for review)

Hi Ivan - I’ve added this to the github issues list; [ISSUE #112][1]

My initial thoughts are that there are some small differences between the JSON and RDF processing - because the RDF mapping can take advantage of more properties in the metadata document, but it might be possible to organise both to create a common structure. 

Let's review this again after FPWD.

Jeremy

[1]:https://github.com/w3c/csvw/issues/112 <https://github.com/w3c/csvw/issues/112> 

> On 14 Dec 2014, at 08:50, Ivan Herman <ivan@w3.org> wrote:
> 
> another thing that I realized since I sent my previous mail. To emphasize again, I do not think this should be done _now_, but to consider it after the FPWD publication.
> 
> Several steps in 4.1.1. are not JSON specific, namely the creation of what you called column description objects. Although you have not published the RDF mapping yet, I would expect that to include the very same steps. The reason is that, in fact, the generation of JSON is based on what I would also call an expanded metadata, which essentially means the fully expanded version of the core metadata with all the inherited properties being added so that the column description objects would correspond to the "schema" part of the metadata.
> 
> I think it might be a better way of presenting this if we could somehow factor this out in the document and, actually, among the conversion documents. I see two viable possibilities
> 
> 1. As a separate section in each conversion document that would be exactly identical
> 2. As a separate section in the metadata document (hence my explicit cc to Jeni:-)
> 
> #2 would have the advantage of making the procedures clear for other applications than conversions, but it may not fit the overall goals of the metadata document. If we go #1, we may end up with a version hell. Fortunately, respec may come to our rescue for #2: the data inclusion possibility ([1], or possibly [2]) may take care of that.
> 
> I think I am more in favour of #1 at this point, but only mildly; #2 may also work.