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

Re: Using schema.org Dataset metadata properties

From: Ivan Herman <ivan@w3.org>
Date: Sun, 14 Sep 2014 09:03:33 +0200
Cc: W3C CSV on the Web Working Group <public-csv-wg@w3.org>
Message-Id: <6BE2EBC0-7220-4277-8002-C48A57A94BF8@w3.org>
To: Jeni Tennison <jeni@jenitennison.com>
I have a meta-question on this. Is the list of terms listed in the document normative or informative? The current document does not make a difference (ie, by default, it is normative, including the references), but I presume this is simply because we never asked ourselves the question.

At the moment, the text says:

[[[
Descriptions may contain any properties defined by [DC-TERMS] to describe the table. This specification does not define any application behaviour associated with these properties being present, except that validation of metadata files must check that, if they are present, they adhere to the syntax defined here.
]]]

This at first suggests that the [Dublin Core] vocabulary is informative (and optional) but then it mandates specific value syntax for some of the properties when validating. I think it could be debated whether this additional validation requirement actually makes the reference normative, but it is not clear. I guess the question is whether we will have a notion of conforming metadata, of a possible metadata validator, and what they are supposed to exactly do.

Why is this question relevant? Because if the whole section is normative than we MUST make a choice on whether, for a specific goal, we choose DCTERM or schema. If it is informative, there is no problem referring to both and let the end user decide (and, actually, the exact value syntax issue could also be removed simply referring to the definition of these terms by DCMI and schema.org, respectively.)

(There is also an editorial/W3C issue. There are fairly stringent rules on whether we can refer, _normatively_, to an external document. While this is not a problem with DCTERM, this has not yet done before for schema.org, and it may lead to some discussions...)

Ivan



On 13 Sep 2014, at 18:28 , Jeni Tennison <jeni@jenitennison.com> wrote:

> Hi,
> 
> In the current metadata document here:
> 
>   http://w3c.github.io/csvw/metadata/#common-properties
> 
> the spec maps adopts the list of Dublin Core properties for describing tables etc. As ISSUE 6 says, this might not be the right choice: there might be other standard vocabularies that should be used instead or as well.
> 
> On the call this week, Dan suggested using schema.org instead, namely the properties on Dataset here:
> 
>   http://schema.org/Dataset
> 
> The properties there are informed by DCAT which itself was informed by Dublin Core.
> 
> Any thoughts?
> 
> Jeni
> 
> -----Original Message-----
> From: CSV on the Web Working Group Issue Tracker <sysbot+tracker@w3.org>
> Reply: CSV on the Web Working Group <public-csv-wg@w3.org>>
> Date: 10 September 2014 at 13:23:37
> To: jeni@jenitennison.com <jeni@jenitennison.com>>
> Subject:  ACTION-26: Write to mailing list re using schema.org rather than dublin core for metadata about csv files, then binding decision on following telcon (CSV on the Web Working Group)
> 
>> ACTION-26: Write to mailing list re using schema.org rather than dublin core for metadata  
>> about csv files, then binding decision on following telcon (CSV on the Web Working Group)  
>> 
>> http://www.w3.org/2013/csvw/track/actions/26
>> 
>> On: Jeni Tennison
>> Due: 2014-09-17
>> 
>> If you do not want to be notified on new action items for this group, please update your  
>> settings at:
>> http://www.w3.org/2013/csvw/track/users/33715#settings
>> 
>> 
>> 
> 
> --  
> Jeni Tennison
> http://www.jenitennison.com/
> 


----
Ivan Herman, W3C 
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
GPG: 0x343F1A3D
WebID: http://www.ivan-herman.net/foaf#me






Received on Sunday, 14 September 2014 07:04:03 UTC

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