Use of the class Code and the property "hasAdditionalClassification"

[giorgialodi]

in the object properties where a code should be specified, the range is both code (lower case letters see issue #59) and a class that represents the specific skos:ConceptScheme (and here there is a doubt, see below).

I think we have two possibilities:

1. either we use the class Code which is equivalent to skos:Concept (defined in the namespace of epo we said)
2. or we create specific classes (e.g., Cpv, Buyer-legal-type, Award-criterion-type, Design-contest-type, Direct-award-justification, etc.) for all the different controlled vocabularies (BTW: the convention in the naming of these classes seem different to all the other classes)

Thus object properties such as "hasAdditionalClassification", "hasMainClassification", "hasAwardStatus", "hasBuyerLegalType" will have only one range: in case of 1 the range will be Code, in case of 2) the name of the specific class that represents the specific controlled vocabulary to be used in the object property.

BTW: If I take the Cpv class it says that is equivalent to skos:inScheme value Cpv. So Cpv is a ConceptScheme or a Concept? Because if I have an object property "hasMainClassification" the range should point to a single concept CPV, not to the overall ConceptScheme.

Finally, I am not sure that the property "hasAdditionalClassification" is functional.

[costezki]

• check that the Code is properly translated into skos:Concept.
• check that the ObjectProperty domain and ranges are aggregated as expected. (sometimes the union works and sometimes it does not, why? )

"hasAdditionalClassification", "hasMainClassification", "hasAwardStatus", "hasBuyerLegalType"

[costezki]

The rest of the issue description referring to using a skos:ConceptScheme versus Class standing for a controlled list shall be taken elsewhere as it is a modelling decision and should be careful though about and documented for consistent usage/application.

Hint:
What could be done is to use the generic skos:Concept in the "ontology" definition without any reference to any specific controlled list. And, provided that it is well documented and decided, create an application profile where the controlled lists are detailed for a given context.

For example, LegalForm type which is a controlled list, shall differ from country to country and therefore in the ePO model we shall generically specify that the property epo:hasLegalFormType shall take the range skos:Concept, while in a range of application profiles defined at the national level, we can specify that epo:hasLegalFormType shall take values from xxx:SpecificLegalForm.

[giorgialodi]

Hi @costezki , I agree on the hint of your comment above! It is what happens in other core vocabularies of ISA2 for instance.

[giorgialodi]

Hi @costezki do you have news about this? Because I still see a lot of classes pointing to controlled vocabularies but now we use skos:Concept, right?
For instance "Economic-operator-size" or "Procurement-procedure-type", etc. They are also written with a different convention with respect to other classes and not used in object properties where skos:Concept is used instead.

How do we deal with these classes?

[giorgialodi]

BTW I noticed: http://publications.europa.eu/resource/authority/procurement-procedure-type --> this URI has "procurement" with lowercase.
While in the OWL restriction file there is this class http://publications.europa.eu/resource/authority/Procurement-procedure-type with P uppercase,
I think we do not need to import these classes here. We can include the fact that an EU voc should be used in the definition of the property. In this case of procurement procedure type, we can include the definition in the hasProcedureType property.
In the SHACL shapes then we can define the rules that check if the range of that property is one of the values of the related EU controlled vocabulary.

[costezki]

Dear @giorgialodi, Regarding your first comment about "Economic-operator-size" and "Procurement-procedure-type":
They are enumerations in the UML model.
When the transformation script runs it creates

• in owl core ConceptScheme definitions for each enumeration ()
• in restrictions an extensional class definition scoped to any concept that is skos:inScheme
• in shapes there is no mention to or the class

What is no longer generated, is the range restriction; that being substituted by providing a generic skos:Concept.
So it looks fine to me unless I understood it wrongly, or further changes are necessary.

[giorgialodi]

@costezki I understand the overall mechanism but I think there is something not correct because in the OWL restrictions file there is a class http://publications.europa.eu/resource/authority/Procurement-procedure-type that does not exist! And this applies to all those types of classes.
And the working group does not aspect to have these classes in the OWL restrictions file. It is more natural checking that the value of a property that has a skos:Concept as range takes the correct values of the related EU controlled vocs in shacl shapes.

[costezki]

These classes are created in the restrictions layer in order to enable the property range constraint checking (in SHACL in fact). This has been defined in the transformations documentation document and implemented accordingly.
If we do not include that, then we cannot check that a concept (from a controlled list which is a concept scheme) is a correct or incorrect range.

We can, eventually, move that class definition for every controlled list, into the SHACL layer (though it would be weird too).

[giorgialodi]

Hmmm, I need to reason about that :) In any case, the URIs of those classes should be the right ones (everything in lower case).

[giorgialodi]

@costezki the thing that it is not clear to me is the following: the property hasProcedureType has as range skos:Concept and it is correct. In which way now the restrictions say that the skos:Concept range of this property is linked to the "skos:inScheme procurement-procedure-type"?

[costezki]

In fact, not anymore. That was the original assumption and was implemented accordingly.
I'll mark this issue for future development to decide how to deal with this.

A temporary solution would be to ignore altogether any enumeration definition and any enumeration references(which is suboptimal imho and specific to ePO alone).

[giorgialodi]

@costezki for instance, how do they treat in DCAT-AP the mandatory vocabularies for specific properties? It seems to me that they check this in SHACL shapes only, leaving in the ontology part the fact that the property has as range skos:Concept (and the description of the property says which controlled voc is to be used). Am I right?
If so, we can do here the same. Obviously there is no specific automatic reasoning that can be enabled using the OWL ontology unless we find a solution with punning or something like this.

[costezki]

Decision

We distinguish two types of UML models,

• one that species the ontology and
• another one that specifies an application profile (extending the ontology)

[1] For the UML models that specify the ontology, the model2owl transformation script will generate no definition and no reference to enumerations (controlled). The enumeration and any connections to them will simply be ignored.

[2] For the UML models that specify an application profile, the model2owl transformation script will generate auxiliary classes for each enumeration (in the restriction module) and shape definitions and property restrictions involving references to the enumerations (controlled lists).

Actions

In the immediate future functionality [1] will be implemented.
In the future will be implemented a discrimination mechanism between an ontology and an application profile (defined in UML) enabling functionality [1] and [2].