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

Re: Using schema.org Dataset metadata properties

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Mon, 15 Sep 2014 21:24:43 +0100
Cc: Ivan Herman <ivan@w3.org>, W3C CSV on the Web Working Group <public-csv-wg@w3.org>
Message-Id: <5D2B7567-F55D-4659-A0FF-3612E4F669A2@greggkellogg.net>
To: Jeni Tennison <jeni@jenitennison.com>

Gregg Kellogg
gregg@greggkellogg.net

On Sep 15, 2014, at 6:57 PM, Jeni Tennison <jeni@jenitennison.com> wrote:

> Ivan,
> 
> Given that we’re adopting JSON-LD for the metadata file, anyone *can* use any vocabulary. I was thinking that we should including the binding of ‘dc’ to the Dublin Core namespace so that people can easily add metadata in that scheme if they want to.
> 
> I think there is huge value in having a predictable structure to metadata, as it helps with validation, display and conversion. Adopting JSON-LD in effect enforces a particular structure, eg saying that “publisher” must look like:
> 
>   “publisher”: {
>     “@id”: "http://www.hefce.ac.uk/“,
>     “name": "Higher Education Funding Council for England (HEFCE)"
>   }
> 
> or
> 
>   “publisher”: "http://www.hefce.ac.uk/“
> 
> and not
> 
>   “publisher”: "Higher Education Funding Council for England (HEFCE)"
> 
> Adopting schema.org normatively would mean saying that “publisher” means what it means in schema.org, which I think is what we would want to do.

+1, but note that the schema.org content model for publisher would allow either a URI or a plain literal in this place.

I do think that using schema.org is the most forward-thinking way to go, and as there is quite an active community, perhaps more amenable to change driven by our use cases, if the need arises.

Certainly having a standard context which includes common prefixes, similar to RDFa’s initial context, makes a lot of sense.

Gregg

> Cheers,
> 
> Jeni
> 
> -----Original Message-----
> From: Ivan Herman <ivan@w3.org>
> Reply: Ivan Herman <ivan@w3.org>>
> Date: 14 September 2014 at 08:07:03
> To: Jeni Tennison <jeni@jenitennison.com>>
> Cc: W3C CSV on the Web Working Group <public-csv-wg@w3.org>>
> Subject:  Re: Using schema.org Dataset metadata properties
> 
>> 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 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  
>>> Reply: CSV on the Web Working Group >
>>> Date: 10 September 2014 at 13:23:37
>>> To: 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
>> 
>> 
>> 
>> 
>> 
>> 
> 
> --  
> Jeni Tennison
> http://www.jenitennison.com/
Received on Monday, 15 September 2014 20:25:09 UTC

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