W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > January 2018

Re: Definitions page for Profiles

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Wed, 10 Jan 2018 10:31:40 +0100
To: <public-dxwg-wg@w3.org>
Message-ID: <fa586577-9ea1-a578-ee2b-1239c8db2396@few.vu.nl>
Hi Max,


On 10/01/18 09:37, mail@makxdekkers.com wrote:
> Antoine,
> 
> Is your proposal to relax the rule on not defining new terms inside a profile based on an existing case, or is it more of a theoretical consideration? Do you have an example of application designers complaining about this separation between namespace and profile? It's a rule that, as far as I know, is quite general, at least in environments that I know of. Changing the rule would need to be in response to actual problems.
> 

I don't have any complaints, rather cases of people just doing it. E.g. for the Europeana Data Model, there could be an "EDM Fashion profile" or a "DM2E EDM profile" and these may include elements from own namespace. Yet they refer to them as profiles.

>
> Your suggestion that a namespace could also include constraints means that both can then contain definitions of new terms and constraints, so they become more or less indistinguishable. Is that the intention?
> 

Yes. And again it's not a strong theoretical stance, just an observation that these things may happen. I.e. definitions of terms in OWL may include constraints (for all the shortcomings OWL has wrt. expressing constraints, it does manage to express a couple of them and these appear in OWL ontologies). Once this can happen, the line is fairly hard to draw - at least if one wants to base it only on the notion of what a constraint is or is not.

Antoine

> 
> 
> -----Original Message-----
> From: Antoine Isaac [mailto:aisaac@few.vu.nl]
> Sent: 10 January 2018 00:13
> To: public-dxwg-wg@w3.org
> Subject: Re: Definitions page for Profiles
> 
> Hi,
> 
> @Makx:The points for having the new namespace as part of the profile is mostly practical: why would one try to draw a strict line between 'ontological axioms/constraints' and 'profile axioms/constraints' when the new classes and properties are specific to the application targeted by the AP, anyway?
> In other terms, if an application designer needs to coin new elements, why would we force her to design them as if they were for re-use by other profiles, elsewhere, if she doesn't have the resource, nor a sound modeling basis to do so?
> Besides, the formalisms to express constraints at both levels may be quite similar, making it hard to draw a formal distinction: what if the designer of a namespace wants to specify SHACL constraints in there?
> 
> NB: I'm not saying that the practice Makx is refering to is bad - far from it. And I am completely ready to accept there would be some negative aspects to coin a class/property at the level of a profile, like the discovery issue that Karen mentions (if I understand it well). But I'm not sure we should be exclusive.
> 
> But well, as discussed today, maybe I should wait and see if the work on our various specs brings some clearer motivation for drawing such a line. Maybe it will. But if it does I'm fairly sure that the work on content negotiation will not draw such line: i.e. DCAT will be a 'data profile' worth being included in content negotiation, whether we think it is itself an AP or not.
> 
> Cheers,
> 
> Antoine
> 
> On 09/01/18 22:40, mail@makxdekkers.com wrote:
>> I think there is a good reason to keep the definition of properties and classes (in a namespace) separate from definitions of constraints (in profiles). Namespaces and profiles have different maintenance requirements.
>>
>> I have been using the split in all my work and I have never encountered a problem; if necessary, you just create a namespace for properties and classes that you need, and then you define constraints on those new terms in a profile which lives at a different URI.
>>
>> What would be the argument for mixing these different things into a single schema?
>>
>> Makx.
>>
>>
>> -----Original Message-----
>> From: Karen Coyle [mailto:kcoyle@kcoyle.net]
>> Sent: 09 January 2018 22:02
>> To: public-dxwg-wg@w3.org
>> Subject: Re: Definitions page for Profiles
>>
>> Antoine, I don't know exactly why that was the decision, although there is, in my mind, a practical question of what properties are needed to define new terms, and if those fit with the properties of a profile.
>> Possibly there are also issues of IRI naming and discovery.
>>
>> kc
>>
>> On 1/9/18 12:42 PM, Antoine Isaac wrote:
>>> Hi Karen,
>>>
>>> You're probably going to hate me for this reaction, especially
>>> considering the time we've worked together on APs in the DC community...
>>> But is there a very strong reason to say that something wouldn't be a
>>> profile because it originates classes and properties?
>>> To me what was core was the notion of re-using other
>>> vocabularies/model (it would be much harder to define as a profile
>>> something that *only* originates classes and properties), but it
>>> wasn't obvious that it would forbid minting own classes and properties when appropriate.
>>> So if it makes things easier and this rule of thumb can be softened
>>> (if it does exist), perhaps we could propose it to the DC community?
>>>
>>> Antoine
>>>
>>> On 18/12/17 15:31, Karen Coyle wrote:
>>>> Andrea, in answer to #2, by the Dublin Core definition, DCAT itself
>>>> would not be a profile because it originates classes and properties.
>>>> DC profiles reuse but do not create vocabulary elements. A DC
>>>> profile is always based on vocabularies defined (preferably in a
>>>> standard
>>>> way) elsewhere.
>>>>
>>>> That said, presumably you could create a DCAT profile that is
>>>> exactly all of the classes and properties that are included in DCAT.
>>>> If profiles include information such as cardinality, value pick
>>>> lists, etc., then such a profile would provide information not
>>>> included in the DCAT ontology.
>>>>
>>>> kc
>>>>
>>>>
>>>> On 12/18/17 5:05 AM, andrea.perego@ec.europa.eu wrote:
>>>>> Dear Karen, dear Ruben,
>>>>>
>>>>> Thanks for initiating this page.
>>>>>
>>>>> A couple of comments / questions:
>>>>>
>>>>> 1. I think it may be worth including an explicit reference to the
>>>>> definition of "profile" from RFC 6906 ("The 'profile' Link Relation
>>>>> Type") [1]. @Ruben, if I'm not mistaken your definitions are
>>>>> partially based on it.
>>>>>
>>>>> 2. Looking at the wiki page, it is unclear whether DCAT itself (and
>>>>> any metadata schema, vocabulary, etc.) is considered or not a "profile".
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Andrea
>>>>>
>>>>> ----
>>>>> [1] https://tools.ietf.org/html/rfc6906
>>>>>
>>>>> ----
>>>>> Andrea Perego, Ph.D.
>>>>> Scientific / Technical Project Officer European Commission DG JRC
>>>>> Directorate B - Growth and Innovation Unit B6 - Digital Economy Via
>>>>> E. Fermi, 2749 - TP 262
>>>>> 21027 Ispra VA, Italy
>>>>>
>>>>> https://ec.europa.eu/jrc/
>>>>>
>>>>> ----
>>>>> The views expressed are purely those of the writer and may not in
>>>>> any circumstances be regarded as stating an official position of
>>>>> the European Commission.
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Karen Coyle [mailto:kcoyle@kcoyle.net]
>>>>>> Sent: Sunday, December 17, 2017 5:11 PM
>>>>>> To: public-dxwg-wg@w3.org
>>>>>> Subject: Definitions page for Profiles
>>>>>>
>>>>>> Ruben and I have done the first set of definitions on the Profiles
>>>>>> Context page [1]. You should add your own definitions and also
>>>>>> comment on those that are there. This is a brainstorming exercise
>>>>>> so please toss out your thoughts, respond to definitions and
>>>>>> comments, and contribute to this.
>>>>>>
>>>>>> kc
>>>>>> [1]
>>>>>> https://www.w3.org/2017/dxwg/wiki/ProfileContext#Discussion_of_Def
>>>>>> i
>>>>>> nitions
>>>>>>
>>>>>> --
>>>>>> Karen Coyle
>>>>>> kcoyle@kcoyle.net http://kcoyle.net
>>>>>> m: 1-510-435-8234 (Signal)
>>>>>> skype: kcoylenet/+1-510-984-3600
>>>>>
>>>>
>>>
>>>
>>
>> --
>> Karen Coyle
>> kcoyle@kcoyle.net http://kcoyle.net
>> m: 1-510-435-8234 (Signal)
>> skype: kcoylenet/+1-510-984-3600
>>
>>
>>
> 
> 
> 
Received on Wednesday, 10 January 2018 09:34:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 April 2019 13:44:56 UTC