Re: Definitions page for Profiles

Hi Makx,

This is a very good question, I'm tempted to be lazy about it and just connect it to another issue: would this be essentially different/harder when a (versioned) profile re-use a specific version of an external namespace?

But I can also try to think a bit :-) I think both approaches that you mention should be workable. I mean each have issues, but to me they look similar to general versioning issues of interlinked resources.
One could also imagine a pattern where the 'local' elements would be declared in a 'sub-namespace' that's versioned independently from other components of the profile.
I guess choosing among the different options would require to assess what changes in the profile, and how often.

cheers,

Antoine

On 10/01/18 12:31, mail@makxdekkers.com wrote:
> OK, I understand.
> 
> One thing that does worry me is the versioning aspect. If you create a profile that contains definitions of 'local' elements, what happens with their URIs if you then create a new version of the profile?
> 
> Assume a profile lives at http://example.org/profiles/profile001/v001/, and that it defines a 'local' element http://example.org/profiles/profile001/v001/#elem001.
> Would the element in a new version of the profile at  http://example.org/profiles/profile001/v002/ get a new URI http://example.org/profiles/profile001/v002/#elem001?
> Or would http://example.org/profiles/profile001/v002/ still refer to http://example.org/profiles/profile001/v001/#elem001?
> 
> Makx.
> 
> 
> 
> -----Original Message-----
> From: Antoine Isaac [mailto:aisaac@few.vu.nl]
> Sent: 10 January 2018 10:32
> To: public-dxwg-wg@w3.org
> Subject: Re: Definitions page for Profiles
> 
> 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_De
>>>>>>> f
>>>>>>> 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 Thursday, 11 January 2018 11:55:28 UTC