Re: JSON mapping document is now ready for review

Hi Jeremy,


> On 17 Dec 2014, at 14:38 , Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
> 
> Hi Ivan, responding to the comments in line ...
> 
>> - Abstract: mapping of tabular data "into json" or "onto json"? The latter sounds more natural to me, but you are the native speaker:-)
> 
> “into” works for me; I’m thinking it’s short for “mapping tabular data *into* [the] JSON [format]”.

I yield to the native British 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
> 
> JSON people still have object graphs; although I share you concern about the use of “output graph”; couldn’t think of anything better (yet).

JSOn object?

> 
>> - Note right after ISSUE 93: "tabular \ data" -> "tabular data”
> 
> Fixed
> 
>> - Right before ISSUE 62: "enirely textual" -> "entirely textual”
> 
> Fixed
> 
>> - 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…
> 
> Changed to say “describe” - now consistent with RDF mapping doc.
> 
>> - 4., 2nd para after bullets, 'Direct Annotations' -> 'direct annotations’.
> 
> Am keeping “Direct Annotations” … I think that this is a proper noun; something defined in the metadata vocab

Yielding again

> 
>> - 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:-)
> 
> Now reads: "Where an array of values for a property are provided using a language map (as defined in [[json-ld]]) the array of locale-specific values SHALL be included in the output graph - albeit without the inferred semantics about language codes."
> 
>> - "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…
> 
> This was the reference that Gregg gave in GitHub ISSUE #91.
> 
> ACTION (please!): Can you raise a _new_ issue in GitHub for this point where we can debate the correct reference? Thanks.

Done, issue #121

> 
>> - 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.”
> 
> Agreed. Sentence about precedence removed and added “[…] overwriting values added in the previous step where properties are duplicated."
> 
>> - 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!
> 
> OK. Removed text-direction stuff.
> 
>> - 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
> 
> Agreed & done. Actually this occurred to me when doing the RDF doc which is consistent with your suggested approach.
> 
>> - 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.
> 
> Sounds reasonable. Note that Core Tabular Data doesn’t even include metadata from a header-line though.
> 
> ACTION (please!): Can you raise a _new_ issue in GitHub for this point so we can discuss this for later drafts? Thanks.
> 
Done, issue #122

Ivan



----
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