W3C home > Mailing lists > Public > public-csv-wg@w3.org > November 2014

Re: Could primaryKey be specified directly as a column name?

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Mon, 3 Nov 2014 12:15:09 -0800
Cc: Dan Brickley <danbri@google.com>, David Booth <david@dbooth.org>, W3C CSV on the Web Working Group <public-csv-wg@w3.org>, Jeni Tennison <jeni@jenitennison.com>
Message-Id: <EE467041-2A57-41F2-9106-8716ABC59E90@greggkellogg.net>
To: Axel Polleres <axel.polleres@wu.ac.at>
> On Nov 3, 2014, at 5:32 AM, Axel Polleres <axel.polleres@wu.ac.at> wrote:
> 
> 
>> Data Shapes WG is by charter and membership wholeheartedly by/for/in RDF. CSV WG is not. The best we can expect at
>> this stage is to communicate, rather than common spec IMHO.
> 
> fair enough, what I meant here was if metadata properties were used for both groups to describe such kind of constraints,
> they should hopefully be compatible.

+1

Gregg

> Axel
> --
> Prof. Dr. Axel Polleres
> Institute for Information Business, WU Vienna
> url: http://www.polleres.net/  twitter: @AxelPolleres
> 
> On 03 Nov 2014, at 13:17, Dan Brickley <danbri@google.com> wrote:
> 
>> 
>> On 3 Nov 2014 11:37, "Axel Polleres" <axel.polleres@wu.ac.at> wrote:
>>> 
>>> Dear Jeni, all,
>>> 
>>> just a guts feeling: Things like 'primary key' are constraints on the data. Another group is primarily concerned with constraints on data and validation of these: http://www.w3.org/2014/data-shapes/
>>> 
>>> In the F2F meeting of the DRF Data Shapes WG I noted that I would be surprised if basic SQL constraints (like primary/foreign key constrainrs would NOT be covered there), so likewise here I wonder whether these constraints are something we shouldn't do in liaison with the RDF data shapes group, rather  than specifying properties in isolation.
>>> 
>>> Thoughts?
>> 
>> Data Shapes WG is by charter and membership wholeheartedly by/for/in RDF. CSV WG is not. The best we can expect at this stage is to communicate, rather than common spec IMHO.
>> 
>> Dan
>> 
>>> Axel
>>> 
>>> --
>>> Prof. Dr. Axel Polleres
>>> Institute for Information Business, WU Vienna
>>> url: http://www.polleres.net/  twitter: @AxelPolleres
>>> 
>>> On 03 Nov 2014, at 11:53, Jeni Tennison <jeni@jenitennison.com> wrote:
>>> 
>>>> Hi David,
>>>> 
>>>> This was an attempt to make the metadata JSON be good JSON-LD. The draft now just uses the “name” property and references those names within “primaryKey", which makes it easier to write but requires a bit more application logic.
>>>> 
>>>> Jeni
>>>> 
>>>> -----Original Message-----
>>>> From: David Booth <david@dbooth.org>
>>>> Reply: David Booth <david@dbooth.org>>
>>>> Date: 1 November 2014 at 20:36:05
>>>> To: public-csv-wg@w3.org <public-csv-wg@w3.org>>
>>>> Subject:  Could primaryKey be specified directly as a column name?
>>>> 
>>>>> In the 30-Oct-2014 draft at
>>>>> http://w3c.github.io/csvw/csv2rdf/
>>>>> there is a very nice, simple example in Sec 4. (Thanks for that!) But
>>>>> I'm wondering about one detail.
>>>>> 
>>>>> Example 3 shows CSV metadata, which includes:
>>>>> 
>>>>> . . .
>>>>> "columns": [{
>>>>> "@id": "_:GID",
>>>>> "name": "GID",
>>>>> "datatype": "integer"
>>>>> }, {
>>>>> . . .
>>>>> "primaryKey": "_:GID"
>>>>> }]
>>>>> . . .
>>>>> 
>>>>> I notice that the value provided for "primaryKey" above is specified as
>>>>> an indirect identifier ("_:GID") for the primary key column, instead of
>>>>> being directly specified as the column name "GID". I assume that there
>>>>> is some rationale for doing it this way -- perhaps so that the metadata
>>>>> can specify duplicate column names, though wouldn't that be a bad use
>>>>> case to support? -- but it seems cumbersome and error prone. Can this
>>>>> be simplified to allow the "primaryKey" to be specified directly as the
>>>>> column name?
>>>>> 
>>>>> Thanks,
>>>>> David
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> --
>>>> Jeni Tennison
>>>> http://www.jenitennison.com/
>>>> 
>>> 
>>> 
> 
> 
Received on Monday, 3 November 2014 20:15:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:27:45 UTC