Re: JSON mapping document is now ready for review

Hi Jeremy,

Is there any scope to declare the type of a row?  E.g. each row is an instance of <SomeClass>.  

It’s one of the things that the standard behind use case case 21 (Darwin Core Archives) supports, but we’ve been discussing whether we should have strongly typed rows or let the values contained in the properties define it in the future, and perhaps using Owl (or similar) to document the classes.

Have you any insight as to whether that is being discussed, perhaps in the RDF serialisation work, or if it has any place here? 

Many thanks,
Tim
 


On 12 Dec 2014, at 16:33, Ivan Herman <ivan@w3.org> wrote:

> Jeremy,
> 
> first of all: you rock:-)
> 
> Please find my comments below. They are not in any order of importance; instead, they mostly reflect the way I hit the question/issue while reading the document...
> 
> And to be clear: regardless of my comments, the document is way beyond the bar for a FPWD; ie, regardless of the subsequent discussion and changes I already cast my vote as a 'yes':-)
> 
> Thanks!
> 
> Ivan
> 
> 
> - Abstract: mapping of tabular data "into json" or "onto json"? The latter sounds more natural to me, but you are the native speaker:-)
> 
> - I am not sure that even referring to an output 'graph' is a good terminology, but I can leave with it. But the note just referring to RDF would have the effect of raising red flags. Propose to remove that note altogether
> 
> - Note right after ISSUE 93: "tabular \ data" -> "tabular data"
> 
> - Right before ISSUE 62: "enirely textual" -> "entirely textual"
> 
> - 3.1.1, I am not sure I understand "The root object of the output graph shall correspond with the table." Is it corresponds _to_ the table? (Same in 4.1.1 and in 5.1.1/1.). Again, I am not a native speaker...
> 
> - 4., 2nd para after bullets, 'Direct Annotations' -> 'direct annotations'.
> 
> - I am not sure I understand "The exception is where an array of values for a property are provided using a language map (as defined in [json-ld]), in which case the array of locale-specific values shall be included in the output graph verbatim - albeit without the inferred semantics about language codes." I mean: the way I understand it is that a direct annotation should be copied verbatim regardless of whether it is a langauge map. This formulation suggest that the processor should understand what a language map is and how it opearates, and then it says it should copy verbatim...
> 
> I guess a note can say that the value may be a language map, but that is just a note. The normative part simply says: copy the damn thing verbatim:-)
> 
> - "URL expansion behaviour of relative URLs shall be consistent with Section 6.3 IRI Expansion in [JSON-LD-API]. " I am not sure about that. The JSON-LD spec talks about things that irrelevant here, like blank nodes, prefixes and suffixes, or reference to an active context. Are all of these relevant here? I am a bit afraid this will really scare away people...
> 
> - 7. step in 4.1.1, very end: it was a bit disturbing to me to say "Where inherited properties are also provided via the table description and/or schema, the value from the column description shall take precedence.". Indeed, at this point, the "column description object" already has, possibly, these properties by virtue of step 6, so referring essentially back to step 6 is a bit misleading. I would rather say something like "Inherited properties null... and default are added to the column description object, possibly overwriting values as a result of step 6."
> 
> - 4.1.3, text-direction: as I commented on the issue, I am very uneasy about that one... As an implementer, I would not even know where to start, ie, how to extract the 'strong type' from a cell value!
> 
> - 4.1.3, predicateUrl: editorially, this is a very different metadata property. Indeed, this is the only one that refers to key (or name), ie, to what is defined in 4.1.2/4. All the other terms in 4.1.3 refers to the cell value. I would propose to move the handling of predicateUrl to 4.1.2./4. instead
> 
> - At least for implementers, but maybe for users, too, it maybe helpful to realize that the handling of core tabular data is really just a special case of an annotated data. Ie, an implementation strategy may be, for a core tabular data, to (conceptually) create an annotated tabular data with a specific header line and no extra metadata, and then 'fall back' to the case of the annotated data. Something like that, in an non-normative appendix, may be a good idea.
> 
> 
> 
> 
> 
> 
>> On 11 Dec 2014, at 22:53 , Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
>> 
>> All - the [JSON mapping document][1] is now published to w3c/csvw:gh-pages and is ready for your review. Feedback welcome of course :-)
>> 
>> My next job is to to the RDF mapping document; this will follow a very similar structure …
>> 
>> Jeremy
>> 
>> [1]:http://w3c.github.io/csvw/csv2json/
> 
> 
> ----
> Ivan Herman, W3C
> Digital Publishing Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704
> 
> 
> 
>

Received on Saturday, 13 December 2014 14:54:15 UTC