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_Defi
>>>>> 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 Tuesday, 9 January 2018 23:13:34 UTC