W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > March 2019

RE: [profgui] Definitions needed for progress

From: Svensson, Lars <L.Svensson@dnb.de>
Date: Tue, 5 Mar 2019 11:22:15 +0000
To: "kcoyle@kcoyle.net" <kcoyle@kcoyle.net>, "public-dxwg-wg@w3.org" <public-dxwg-wg@w3.org>
Message-ID: <980d2c2b1abb44838532f33591b2088e@dnb.de>
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.



Received on Tuesday, 5 March 2019 11:22:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:42:15 UTC