add specific subclasses of Concept or restrictions on ConceptScheme

[VladimirAlexiev]

owl-core-ePO-CM-v2.0.2-2020-11-06.ttl and owl-restriction-ePO-CM-v2.0.2-2020-11-06.ttl (in model2owl) has things like this:

<https://github.com/ESPD/ESPD-EDM/Confidentiality-level>
        a               skos:ConceptScheme ;
        rdfs:label      "Confidentiality-level"@en .

<https://github.com/ESPD/ESPD-EDM/Confidentiality-level>
        a                    owl:Class ;
        owl:equivalentClass  [ a               owl:Restriction ;
                               owl:hasValue    <https://github.com/ESPD/ESPD-EDM/Confidentiality-level> ;
                               owl:onProperty  skos:inScheme
                             ] .

This declares Confidentiality-level to be both skos:ConceptScheme and owl:Class, and then to infer that class for each skos:Concept of that scheme.

There are things that can be fixed above:

• use proper namespace and naming convention for the class
• use shapes to validate the inScheme

But the basic idea of defining specific subclasses of Concept is valuable because then you can use them in ranges.

In contrast, the current release 2.0.1 makes no restriction on the use of specific thesauri. Eg "restriction" defines ranges like this, and "shapes" doesn't add any specific check:

epo:hasAccessibilityCriterion rdfs:range   skos:Concept .
epo:hasFulfillsRequirement rdfs:range   skos:Concept .

This means that a user can use ANY concept from ANY concept scheme in these props, which is too lax.

[eprocurementontology]

Unfortunately we do not understand which model you are talking about. The ontology at this point does not cover the ESPD. Could you please provide us with a direct link to the data covered by this issue.

Please keep in mind that the controlled vocabularies identified are only recommendations in the UML and are therefore not represented in the OWL. It is foreseen that application profiles will confirm which controlled vocabulary will be used. See also gthub issue 275.

[VladimirAlexiev]

@eprocurementontology I mean files in https://github.com/OP-TED/model2owl/tree/master/data.

In my experience taxonomies are an important part of the semantics of a domain. True, one can extend them, but to leave them undefined and relegate to Application Profiles is imho "dereliction of duty". Consider that you can switch between classes and taxonomies, eg see https://www.topquadrant.com/classonomies/.

Please answer my concern: is it ok that data can use ANY concept from ANY concept scheme for each of the lookup props?

I personally prefer to use shapes to validate inScheme, rather than making subclasses of Concept . Eg this is how the Ontotext Platform works: http://platform.ontotext.com/soml/objects.html#object-typing

[VladimirAlexiev]

@giorgialodi #275 item 2 matches my suggestion "validate using shape". Looking forward to that in the "near future". IMHO the desire for extendibility is not a substitute for validating all that you can.

[costezki]

The model2owl release 2.0.0 implements shape-based validation for concept schemes. Yet it keeps in the restriction layer, the conflation of conceptScheme and class defintion.

Please refer to the documentation https://meaningfy-ws.github.io/model2owl-docs/public-review/transformation/uml2owl-transformation.html

See an example transformation here

https://github.com/OP-TED/ePO/tree/master/implementation/ePO