tfrancart
commented
6 years ago - SKOS explicitely allows subProperties of skos:related as a possible extension mechanism. As a matter of fact, Example 31 of SKOS is exactly a cause/effect example;
- The subproperties introduced aim at accomodating the ISO 704:2009 and ISO 1087-1:2000 standard mentionned in the introduction (see issue #85 and PR #111)
- Introducing subPropertyOf skos:related is precisely a way of staying in the SKOS niche while not drifting to OWL; there exists frequent use-cases of SKOS users that want to stay in the SKOS world while adding slightly more semantic to their KOS, and extending the SKOS model is a straightforward way to address this. Getty AAT is a good example of that.
- We acknowledge that alternative modelling are possible; the ability to create qualified relationships remains possible with the proposed modelling;
- We don't see any reason why the proposed modelling limits the ability to lift a classification to an OWL-DL ontology, or to map it with vocabularies such as schema.org
This remark is mainly for the left hand side of Figure 9 which introduces a number of relationships with attributes such as symmetric, transitive and disjoint as sub-properties of skos:related. These properties are declared as owl:TransitiveProperty, owl:SymmetricProperty (in a way which is consistent with what is done is SKOS).
While I agree that skos:related is not a panacea, my preference would be to have a mechanism allowing to annotate the type of relationships used in a linkset globally, on the model of what is done for Open PHACTS linkset (see the issue discussing mapping justifications) or locally on the model of what is done in ISO 25964 (via the HierarchicalRelationship class which does not seem to have been ported in skos-thes)
One approach worth exploring would be to introduce a "qualified ontology relationship" design pattern where the simpler relationship defined in SKOS (and maybe some selected XKOS ones) could be expanded into a richer one with an intermediate node serving as placeholder for adding new information (richer semantic characterisation, other information about the nature of the link e.g. how it is has been obtained. Simpler approaches may be required for cases where it would be worth to supply additional data at the same time e.g. weights associated to key dimensions (area, population) for classifications describing administrative areas.
Another reason to limit the drift of XKOS towards OWL construct is to firmly anchor XKOS practice in its natural niche (SKOS users) and not try to expand it (blur the boundary between the two practices). My preference is for XKOS to not tip-toe outside the SKOS "comfort zone" but it may be a good idea to document best practices from the community on cases where richer (OWL DL?) semantic relationships would be useful.
Some of the semantic relations defined in section 9 are also available from upper ontologies or from ontologies focusing on the management of time interval or event relationships and there may be other ways to enrich the classification using some sort of annotation or mapping guideline and/or instructions on how to make the content compatible to be able to lift into an OWL DL ontology or alternatively when a larger audience is targeted in a resource designed to be consumed by web developers (use of standards such as JSON-LD for which a closer alignment with schema.org meta-model and concepts may be expected).
And with such a mechanism to lift XKOS content into a fully fledge OWL DL ontology, there would be no need to add the xkos:disjoint relationship. Please remember that tool implementers will have to figure out what they can do with it.
ISO 25964 http://www.niso.org/schemas/iso25964/
PS: The question of when to use OWL and SKOS and whether to use them together or not has been debated in the past. Here are a few references:
This retrospective of the work done in the SKOS working group discusses the choices to include or ignore specific requirements known at the time of development: