- From: Richard H. McCullough <rhmccullough@att.net>
- Date: Sun, 14 Dec 2014 10:51:23 -0800
- To: Ivan Herman <ivan@w3.org>, Tim Robertson <trobertson@gbif.org>
- Cc: Jeremy Tandy <jeremy.tandy@gmail.com>, W3C CSV on the Web Working Group <public-csv-wg@w3.org>, "dave@dajobe.org" <dave@dajobe.org>
- Message-ID: <1418583083.34093.YahooMailNeo@web181503.mail.ne1.yahoo.com>
I have been making some revisions to the definition of mKR relation class to make it
easier to apply to CSV, TSV, ResultSet, etc. The relLabel, relType, relVariable, rel properties
are lists of label, type, variable, and row information. All but the rel property can be omitted
for particular cases. relKey and relMode properties can be specified for dataset.
Here's my current idea for an RDF representation.
@prefix : <http://mkrmke.net/ns/> .
:mydata a :relation;
:relFormat "CSV";
:relLabel ( "person" "phone number" "email address" );
:relType ( :Person :Phone :Email );
:relVariable ( "per" "ph" "em" );
:relKey "$per";
:relMode "SQL";
:relMeaning { "$per" a :Person; :Phone "$ph"; :Email "$em" .
"$ph" a :Phone .
"$em" a :Email . };
:rel ( "Dick McCullough" "707-123-4567" "rhm@isp" );
:rel ( "Bob McCullough" "925-987-6543" "rbm@isp" ) .
Dick McCullough
Context Knowledge Systems
What is your view?
On Sunday, December 14, 2014 1:04 AM, Ivan Herman <ivan@w3.org> wrote:
>
>
>Tim,
>
>I tried to look up previous discussions, but I did not see any written trace of this (although I may have missed something).
>
>There are two different case that we have to separate
>
>1. Possibility to assign _one_ common type for each row
>2. Possibility to assign a specific type for each row
>
>#1 is relatively easy to do, of course, because it can be managed with a schema level term, much like we do to specify the URL for a row using a URL Template. Actually, if we allow the possibility of a template instead of a fixed URL, we do some sort of a #2-lite, without too much additional problems.
>
>A full blown #2 is 'covered' by a more general issue that we discussed at the F2F. Indeed, there is a resolution, whereby:
>
>"RESOLUTION: We drop the ability in the schema to specify metadata at the row or cell level: schemas are only used to define columns"
>
>see
>
>http://www.w3.org/2014/10/28-csvw-minutes.html#res3
>
>which makes it pretty much impossible to do #2 (except for the #2-lite).
>
>To make this cleaner and not to forget this discussion, I will create a separate issue so that we would not forget it!
>
>Ivan
>
>
>
>> On 13 Dec 2014, at 15:53 , Tim Robertson <trobertson@gbif.org> wrote:
>>
>> 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
>
>>>
>>>
>>>
>>>
>>
>>
>
>
>----
>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 Sunday, 14 December 2014 18:51:52 UTC