Re: [profgui] Definitions needed for progress

Thanks, Lars, for your comments. We didn't talk about the "open v.
closed" but I think that is a very good point. Does anyone know if any
of the DCAT-APs address this? I couldn't find evidence of it.

One other thing, you asked about "does not constrain" and that was poor
wording on my part. I think what the group was meaning was "does not add
additional constraints, just reuses as is." DCAT-ap adds constraints
because it lists the cardinality; DCAT itself does not. DCAT-AP defines
Application Profile as:

"An Application Profile is a specification that re-uses terms from one
or more base standards, adding more specificity by identifying
mandatory, recommended and optional elements to be used for a particular
application, as well as recommendations for controlled vocabularies to
be used."

(I actually like this definition more than the one we have in the
documents - maybe we can add some of what is here into that definition
in the profiles guidance document.)

So what we ponder is: what are the conditions for something to be
considered a profile? It seems that one possible answer is that the
addition of constraints over a vocabulary constitutes a profile. For the
question of "open v closed", "closed" would be a constraint.

kc

On 3/5/19 3:22 AM, Svensson, Lars wrote:
> Interesting questions! My comments inline.
> 
> On Friday, March 01, 2019 8:42 PM, Karen Coyle [mailto:kcoyle@kcoyle.net] wrote:
> 
>> I seem to have forgotten to make the minutes of yesterday's profgui
>> meeting [1] public (I've asked DaveR to help), but there are many notes
>> in the Google doc that we were working on.[2] Refreshing my memory of
>> the discussion, there are a number of concepts that we need to clarify
>> so that we can use them consistently throughout the document.
>>
>> I am recording here what we discussed. It is lengthy and complex so we
>> will need to break it down into individual topics for discussion. Some
>> link logically to already active github issues, so I will move these
>> comments to those. Others may require us to open new issues. Most of the
>> concepts in question are not limited to the profiles guidance document
>> so we need to consider them in the context of the entire suite of
>> deliverables.
>>
>> If you know of issues or discussions that are relevant but have not been
>> listed here, please add them.
>>
>> 1. Constraint (also constrain) [3]
>> The two main uses seem to be
>> a. - strict (or "hard"): to constrain means to define something that can
>> be validated or measured. A constraint example would be: propertyX is
>> mandatory
>> b. - non-strict (or "soft"): to constrain means to make statements or
>> declare something. This example would be: propertyX is included in the
>> profile but is optional; no other rules are applied.
>>
>> The group tended to favor the "soft" definition
>> Related issues:
>> https://github.com/w3c/dxwg/issues/721
> 
> If the shape (or whatever) is closed, i. e. the instance data must not contain any element not listed in the shape, the "soft" definition suddenly turns hard since a validator would throw an error if it finds an element in the instance data that is not listed in the profile, be that element mandatory or optional. IIRC one of our use cases for profiles is the possibility to validate data so I would tend to the "hard" definition.
> 
>> 2. "profile of"
>> What conditions entail that one thing is a profile of another thing?
>> a. - any use of elements (classes, properties), even if minimal (e.g.
>> just use one DC term)[4 - Tom Bakers response]
>> b. - use of all of the elements from a "base specification" and possibly
>> add elements from another another specification and/or other constraints.
>> c. - use of a "significant portion" of a base specification or other
>> profile.
>> d. - something is a profile of something else if the creator of the
>> profile declares it as such
>>
>> Note that if there is to be any formal inheritance then some of these
>> definitions would not be usable.
>>
>> Related issues:
>> https://github.com/w3c/dxwg/issues/486
> 
> a. is definitely too weak, d. feels a bit arbitrary. I tend to b. rather than c. even though I understand that there are corner cases where this can be hard. (When it comes to machine-processability I tend towards relatively strict definitions...).
> 
>> 3. Are "profile of" and "base specification" redundant?
>> It appears that every "profile of" has a base specification, so it seems
>> to be sufficient to simply talk about profiles. We have reduced the use
>> of "base specification" in this document.
>>
>> 4. "inheritance"
>> There are three types of inheritance:
>> a. inheritance of a "statement of conformance" which is the outcome of
>> the reuse of defined terms (and their constraints) (possibly to be
>> called reuse or a hierarchy)
>> b. the mechanism for handling individual constraints (axioms, algorithms)
>> c. inheritance of profiles or specifications, where implementation
>> requires accessing and including "upstream" elements in the target profile.
> 
> The way I think of inheritance is c. where a profile can build on another profile (or combine several) and all constraints defined in the parents are also present in the child.
> 
>> related issues:
>> https://github.com/w3c/dxwg/issues/643
>> https://github.com/w3c/dxwg/issues/642
>> https://github.com/w3c/dxwg/issues/748
>>
>> 5. term use v. profiling
>> Is use of terms from a vocabulary itself a profile or is something more
>> needed? a or b:
>> a. - something is a profile if it is a use of terms from other
>> namespaces even if it does not constrain
>> b. - a list of used terms is not a profile unless it defines or adds
>> constraints
>> c. - can something be a profile if it has a mix of constrained and
>> un-constrained terms?
> 
> Does "does not constrain" mean that the term cardinality is implicitly OPTIONAL ([0..])? If so, then to me a. and b. would be the same and c. would be true.
> 
>> This last brought up an interesting question: is DCAT a profile?
> 
> If we say that it is OK not to have _explicit_ constraints (since the lack of an explicit constraint implies [0..]) then every list of classes and properties is a profile and thus DCAT is a profile, albeit a very weak one since you cannot validate against it and clients must be prepared to handle data elements that are not listed in the profile. If we add that a list of classes and properties must be closed in order to be a profile, then we can at least validate that no other classes or properties are allowed in the instance data.
> 
> Best,
> 
> Lars
> 

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234 (Signal)
skype: kcoylenet/+1-510-984-3600

Received on Tuesday, 5 March 2019 19:51:04 UTC