Re: The dcterm/schema.org issue: a proposal to move forward

On 09 Oct 2014, at 11:19 , Andy Seaborne <andy@apache.org> wrote:

> I agree that defining yet more is worrisome.
> 
> I don't see this as RDF (or rather Linked Data) specific.
> 
> If the spec lists a number of terms to use, we are saying what they mean just by choosing names.  I was assuming there would be some text per term, not just a name.

Correct.

> 
> The question of how a term relates to schema.org or Dublin Core is there regardless of format.  Linked Data highlights this because properties have names and definitions but the issue is there regardless.

If I put myself into a JSON user's skin, I am perfectly content getting the terms as defined in the metadata spec in my generated JSON. As a JSON user I do not necessarily care about the existence of other terminologies like DC or schema as long as I am consistent with myself.

As a RDF user it is different: I always place myself on the Web, so to say, because I always think in terms of URI-s; it is a different, say, attitude. So the relationship to other, existing vocabularies become more critical.

So, in your opinion, what should happen if somebody puts up a metadata with those agreed terms but without specifying what the relationship to a specific vocabulary is (ie, without adding a @context to the metadata)? What should one generate into RDF, and what should one generate into JSON?

Ivan


> 
> 	Andy
> 
> On 09/10/14 09:41, Ivan Herman wrote:
> >
>> On 09 Oct 2014, at 10:33 , Jeni Tennison <jeni@jenitennison.com> wrote:
>> 
>>> I feel very uncomfortable about (a) defining yet another namespace for metadata terms and (b) creating yet another sub-list/profile of metadata terms, when in both cases there are existing standards that we could reference instead.
>>> 
>> 
>> The problem is, of course, that we have more than one (and more than two:-) to choose from... But I share your discomfort.
>> 
>> We *could* introduce a rule into the RDF conversion (the only place where this 'namespace' issue occurs) that those core terms should be mapped onto RDF if and only if the metadata @context clearly assigns URI-s to them. Otherwise they are simply skipped. I would be pretty fine with that. For a purely JSON, non-RDF usage the issue is not relevant...
>> 
>>> If we’re going to have some core terms then we should have some very clear criteria for choosing them, such as their utility in the display or validation or conversion of CSV files.
>> 
>> +1. Based on our discussion on the call, Rufus will put into the document the core set (essentially a subset of the terms that are already called out in the metadata document) and we can then take it from there. I am in favour of keeping the core set very small, and rely on people using qualified terms for anything else they want.
>> 
>> Ivan
>> 
>>> 
>>> Jeni
>>> 
>>> -----Original Message-----
>>> From: Ivan Herman <ivan@w3.org>
>>> Reply: Ivan Herman <ivan@w3.org>>
>>> Date: 8 October 2014 at 11:16:15
>>> To: Andy Seaborne <andy@apache.org>>
>>> Cc: Dan Brickley <danbri@google.com>>, W3C CSV on the Web Working Group <public-csv-wg@w3.org>>
>>> Subject:  Re: The dcterm/schema.org issue: a proposal to move forward
>>> 
>>>> 
>>>> On 08 Oct 2014, at 12:04 , Andy Seaborne wrote:
>>>> 
>>>>> On 08/10/14 10:30, Dan Brickley wrote:
>>>>>> On 8 October 2014 10:16, Andy Seaborne wrote:
>>>>>>> On 04/10/14 08:06, Ivan Herman wrote:
>>>>>>>>> 
>>>>>>>>> 1. We define a small set of core properties that we consider to be
>>>>>>>>> essential in the metadata. "We define" means that we specify the terms to be
>>>>>>>>> used in the metadata specification as well as their data types and intended
>>>>>>>>> meaning
>>>>>>> 
>>>>>>> 
>>>>>>> This makes sense though I do have one small question:
>>>>>>> 
>>>>>>> By "we define" do you include giving it a w3c-csv:xyz URI then define
>>>>>>> skos:/rdfs:/owl: mappings to other vocabularies? Or, if not, in what way is
>>>>>>> it different to defining a property or class?
>>>>>> 
>>>>>> That (creating an actual vocabulary definition) sounds the simplest
>>>>>> way of making sure we're precise. However we might not want to be more
>>>>>> precise than the mass-deployment vocabularies we're basing it on, and
>>>>>> both DC and schema.org are pretty flexible. And of course it is
>>>>>> comically close to http://xkcd.com/927/ ...
>>>>> 
>>>>> Sure but a broadly worded definition isn't trying to be completely prescriptive.
>>>>> 
>>>>> The defintion is going to be quite broad so only "precise" in the sense of a defintion
>>>> at all. "it's a title" - we don't constrain what a 'title' is.
>>>>> 
>>>>> This, and Ivan's message, are just about whether the same broad definition is given
>>>> a URI name of not. Having "http://w3/csv#" and the list in the original message seem no
>>>> more than "data on the web" to me.
>>>>> 
>>>> 
>>>> In fact, that is true, something like that is probably a way to go. When generating an RDF
>>>> for, say, 'title'
>>>> 
>>>> - if there is a @context that assigns a URI to 'title', use that as a predicate URI
>>>> - otherwise use http://www.w3.org/ns/csvw#title
>>>> 
>>>> ie, there is a URI, you are correct. Except that we do not, normatively, define any kind
>>>> of skos or owl or whatever equivalence to dc:title or schema:title; users can do that
>>>> if they wish.
>>>> 
>>>> Ivan
>>>> 
>>>> 
>>>>> Andy
>>>>> 
>>>>>> 
>>>>>> Dan
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> ----
>>>> 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/
>> 
>> 
>> ----
>> 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
>> 
>> 
>> 
>> 
>> 
> 


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