SKOS Cross-Scheme Management deals with the possibility of having concepts belonging to different schemes, instead of just having separate trees (bound to different schemes) of non-interlacing concepts.
We report here a series of checks which should be made when adding/removing concepts from schemes, or when adding/removing broader relationships between concepts, which could break branches of concept trees for various schemes.
...
So, it is important that applications using OWLART (such as Semantic Turkey or VocBench) maintain that, for a given scheme, a tree based on a scheme view is never broken, that is, all of the concepts on its branches, belong to that scheme.
Legal Configurations and Integrity breaks
Note that some options may be desired. For instance, in the case of the sequence of concepts:
...
In the above case, C is inScheme S, but has not broader concept in S, nor it is a topConceptOf S, thus there is no reachability for it (i.e. there is no path going from a topConcept of S to it which passes through all concepts which are bound through a skos:broader chain AND are all belonging to scheme S).
Checks
We will start reporting here a series of checks that are expected to be carried out by applications dealing with SKOS cross-scheme management. These checks should be applied when adding/removing concepts from a scheme, when asserting/retracting broader/narrower relationships and, in general, with all other operations which could cause a integrity break according to the above configurations.
When removing a concept C from a scheme TS, the operation should be allowed unless
1) C belongs only to TS (otherwise C itself would remaing dangling )
2) there is a chainbreak (CB) due to at least one of C narrowers remaining dangling in TS.
The check should be as defined below:
For each concept N narrower of C:.
- If N doesn’t belong to scheme TS, then there it is not causing a CB.
- If N is in scheme TS, but it is a top concepts of TS, then it is not a problem, because you won’t break any chain, as it is also topconcept of TS and thus visible even if its broader is removed from TS. You could ask: how is it possible that a concept is narrower of another concept which is in TS, and be also a topConcept of TS? Well, in SKOS this is possibile… (that’s the weird thing I told in the previous email when I joked about our innocence wrt to SKOS weirdness in the first days of development of ST
). In that case, when vieweing scheme TS, you would see N both under C and as a topConcept. - One further check you could add is: if after the above checks, you have some N which seems to be causing a CB, you could check if N as some other broader (not C) which is in TS. In that case, N would be reachable in any case. Note: this check would just widen the possibilities. By not applying it, you are not causing any damage, you are just forbidding removal in a case where it could be admitted. My suggestion is that you do not carry it, and we will do everything server side in ST core SKOS services on VB2.2.