-
Notifications
You must be signed in to change notification settings - Fork 9
List of Change Categories
Some priority is mentioned but without discussion. Let's review.
Two general requirements:
-
We should support (or at least: not prohibit) restricting change reports according to certain conditions. E.g., "show me all added concepts, but only if they have a certain top concept" (expample query, which could be used for filtering, and result). Or: "Restrict results to added concepts, which are subconcepts of concepts already having a matching relationship to concepts of another ontlogy" (the "interesting" hierarchy-changed concepts in the MUTU paper)
-
We should support (or at least: not prohibit) change reports between arbitrary versions.
- Concept
- New Concept (concept in new version, not in reference version) (priority: high)
- Deprecated Concept (active concept in reference version, deprecated in new version) (priority: high)
- Removed Concept (concept in reference version, not in new version) (priority: high)
- Collection (Do we have different versions of a thesaurus which uses collections? - Joachim)
(Thesaurus Array in new YSO? - Johan) (@Sini: Could you check for YSO? - Joachim) (Thesaurus arrays are used in YSO) - Sini)
- New Collection (collection in new version, not in reference version)
- Removed Collection (collection in reference version, not in new version)
- Compound equivalence (priority: optional) - Could be based on ordered list of sequences. Each sequence is an ordered list of labels: split-NPT, PT1, PT2, ...
- New Compound equivalence
- Removed Compound equivalence
It may be critical to differentiate relationships binding concepts (or collections) in one schema and relationships binding concepts and collections in different schema. (Cfr YSO case.)
- Change semantic relation (BT, NT, RT, matching)
- New Relation
- Removed Relation
- Change collection membership
- New member
- Removed member
- Change member ordered list (low priority)
- Add concept - subordinate array relationship
- Remove concept - subordinate array relationship
##KOS changes
(perhaps these could be considered as resource changes (above) - Joachim) (Would be resource change but with "thesaurus-change" specific relationships for merge and split - Johan)
- Merged Concepts
- Split Concepts
Label changes are relative to concept. A label may be with or without URI (i.e. skos or skos-xl). Should label changes be grouped by language? Yes. Developers might be in charge of only one of the languages or only the changes in the "main language" of the KOS triggers changes. - Sini
- New Label (priority: high)
- Removed Label (priority: high)
- Changed Label (typical for prefLabel) (priority: high)
- Changed Notation (in classifications) (priority: high)
- Moved altLabel (from one concept to another - this may indicate some kind concept drift, or concept split if the latter is a new concept)
@Johan: Could you give an example of this? - Joachim
- New Label relationship
- Removed label relationship
Is maybe of low priority, because, in my experience, scope and history notes do not change that much over time. However, if they do, it could be very helpful to have some word-level highlighting of what has changed. I think just recognising these changes would be of high priority (with the brushing up of YSO there are quite many of these). The word-level hilighting would be nice to have, but low priority. -Sini
- New Scope/History/Editorial Note
- Changed Scope/History/Editorial Note (may be quite impossible to state when notes are plain literals)
- Removed Scope/History/Editorial Note