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

Re: [dxwg] Profiles may inherit clauses from one or more parent profiles (6.1)

From: Rob Atkinson via GitHub <sysbot+gh@w3.org>
Date: Sun, 06 May 2018 22:40:42 +0000
To: public-dxwg-wg@w3.org
Message-ID: <issue_comment.created-386922374-1525646441-sysbot+gh@w3.org>
This is an important discussion about implementation - while the implementation and the model are different, we should see if the model should provide better support for certain implementation patterns.

Certainly profiles cannot be realistically created "flat" - and must be constructed from a hierarchy - and here I will cite several reasons, (others may exist)
1) the burden on clients to work out what is the same and what is different from complicated flat (self-contained) profiles is far greater than that to combine profiles
2) services and catalogs can do all the work of creating flat views of profiles
3) descriptive object languages all implement hierarchy
4) Its far easier to write an extension with a few extra clauses than package up a and document a self-contained profile
5) We probably lose semantic information about intent (even if it is possible to compare flat profiles for equivalence)
6) comparison of flat profiles will be dependent on being able to parse the actual profile constraints lagnguage used. This is simply not feasible for text forms in current practice, and would require delving into the details of those languages where we think it can be done.
7) specific  constraints might need to specify where they come from - possibly creating a burden on us to choose a canonical profile constraints or a set of conformance criteria about the expressivity of such languages

So, given that clients _will_ want to access a flat view - is there anything we can do in the model to help:

for example, SKOS has skos:broader and skos:broaderTransitive

A profileOf B
B profileOf C

should entail A profileOfC

A profileOf B,C 

is legal - but loses the hierarchy. If we make  profileOf point to the immediate parent only, then its hard to refactor - to create an extra category of profiles of B with commonalities.

These are quite well known patterns - it would be great to agree on the most useful form for a "self-contained view" of a profile and how this may be defined (its probably a profile of the profile ontology :-) )

GitHub Notification of comment by rob-metalinkage
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/212#issuecomment-386922374 using your GitHub account
Received on Sunday, 6 May 2018 22:40:45 UTC

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