Fix missing SHACL relations

[cristianvasquez]

Hi, this pull request adds missing SHACL relations and filters out external vocabulary definitions.

Please review, there might be mistakes.

An Owl fix will be in place next week in a different branch.

[andreea-pasare]

This PR filters out external vocabulary definitions which it was agreed that it will be implemented in the next major release, ePO 5.0.0. For ePO 4.1.0 we should only add missing SHACL shapes and remove references to missing codelists ("at-voc-new" prefixes).

[cristianvasquez]

Agreed. I'll update

[cristianvasquez]

I misunderstood your comment. You were referring to OWL and not SHACL.

Exporting SHACL shapes of external vocabulary is not desirable, and the SHACL shapes are already being used.

[cristianvasquez]

Regarding some elements in the model, such as, Directive 25, Form 20. How are these elements to be interpreted?

[AchillesDougalis]

@cristianvasquez Are you referring to the multiple inheritance of epo:Not- Modification-D25? One is for standard forms, and the other for eForms.

[cristianvasquez]

Hi @AchillesDougalis, I'm referring to the elements depicted as objects in the Conceptual model, the ones that do not have a prefix. Are these describing a data-instance?

From the model, I don't know what they are, so I'm unsure if they should be in the SHACL or not

[andreea-pasare]

Hi @AchillesDougalis, I'm referring to the elements depicted as objects in the Conceptual model, the ones that do not have a prefix. Are these describing a data-instance?

From the model, I don't know what they are, so I'm unsure if they should be in the SHACL or not

Yes, those are values of the codelists and they are not transformed by model2owl. We included them just for us to have a better perspective.

[cristianvasquez]

Thanks @andreea-pasare, I'll remove them from the export.

[andreea-pasare]

The prefixes used for the shapes in ttl files are different ("a4g_shape") for all modules and it might be misleading. For example, eAccess used to have "acc-shape" and so on.

[cristianvasquez]

Thanks for the comments @andreea-pasare. I've added prefixes and removed at-voc-new

Please indicate if you foresee other changes or if it's ok to merge

[andreea-pasare]

@cristianvasquez I spotted some new mentions of a4g and a4g-shape:

Maybe you can do a check for a4g in all committed files. Thanks!

[andreea-pasare]

I did a comparison in the eContract_shapes.ttl file between a shape that it was removed and added back as modified:

The best I can do is to review whether the newly added SHACL shapes (see below) in eAccess.ttl file look good:

My review is the following:

• content wise, these 3 shapes look ok, in the sense that the target classes are the expected ones, as well as the cardinalities, the sh:path and the sh:name
• the naming conventions for the SHACL shapes are different (check first image: comparison in contract file shape)
• prefixes are different, although I assume the same namespace is behind
• shacl:targetClass is used instead of sh:class
• a4g prefix appears again
• missing sh:sparql property
• shacl:nodeKind property is additional
• shacl:name does not start with a capital letter and it has a language tag on it.

I want to mention that not all the bullet points above are necessarily errors, but these are the differences and they may compromise the alignment to the ePO architecture conventions.

As a conclusion, there are way too many changes that are foreseen for a future ePO major release (5.0.0) and I can not give my approval on this PR. It is up to you to decide if this PR can be further merged or not based on my review above. Thank you!

[andreea-pasare]

Also, the namespaces for cpv and nuts should be manually changed. You can take those from a previous release candidate: 4.1.0-rc.2:
<sh:class rdf:resource="https://data.europa.eu/nuts/scheme/2021"/>
<sh:class rdf:resource="https://data.europa.eu/cpv/cpv"/>
Changes should be reflected in all rdf/ttl shape files where these codelists are referenced.

[cristianvasquez]

@andreea-pasare Thank you!, I'll address those changes.

[cristianvasquez]

content wise, these 3 shapes look ok, in the sense that the target classes are the expected ones, as well as the cardinalities, the sh:path and the sh:name

This was a bug thanks for spotting it!

the naming conventions for the SHACL shapes are different (check first image: comparison in contract file shape)

prefixes are different, although I assume the same namespace is behind
shacl:targetClass is used instead of sh:class

I've changed the naming convention, sh: is the prefered namespace. thanks!

a4g prefix appears again

I've moved this declaration to be part of each property with plain:literal

shacl:name does not start with a capital letter and it has a language tag on it.

I've changed this one

missing sh:sparql property
shacl:nodeKind property is additional

nodeKind is beneficial. Probably sh:sparql as well, but not mandatory, I've noticed the current version contains strange declarations, which we can review later on.

Example:

sh:sparql [ sh:select "SELECT ?this ?that WHERE { ?this <https://data.europa.eu/a4g/ontology#concernsContractAmendment> ?that . ?that <https://data.europa.eu/a4g/ontology#concernsContractAmendment> ?this .}" ] .