Handling property inheritance in SHACL shapes

[costezki]

ePO issue 664 discusses how to handle property inheritance in the generated OWL and SHACL shapes.

This is a new feature that can be implemented in model2owl.

Overview:
This issue involves enhancing the model2owl tool to handle property inheritance when generating OWL and SHACL shapes from UML models. The goal is to ensure that property inheritance in UML diagrams is accurately reflected in the generated OWL and SHACL artefacts. This enhancement is related to ePO Issue #664, which addresses property inheritance handling in SHACL.

Acceptance Criteria:

• UML conventions related to property inheritance are documented and integrated into the conventions set (aka StyleGuide) in model2owl documentation.
• Formal transformation rules for handling property inheritance are written and documented in the model2owl documentation.
• UML checkers for validating property inheritance are defined and implemented.
• The transformation process successfully handles property inheritance according to the documented formal transformation rules.
• Thorough testing of the solution is conducted, with appropriate unit tests demonstrating correct behavior.

[rousso]

@cristianvasquez the description is vague. Please provide a clear description for this ticket.

[gkostkowski]

The following solution was presented during an early feedback meeting.

The description below includes scope, solution and an example demonstrating the designed behaviour.

The solution will be implemented in model2owl and described in the documentation.

Scope

• Supported UML element type: association
• Affected artefacts:
  • HTML conventions report
  • model2owl documentation
• Not affected artefacts:
  • SHACL shapes
  • Restrictions
  • OWL core
  • Glossary

Solution specification

HTML conventions report

HTML conventions report will be used to report any violations detected in the model (as described in the Validation section).

Validation

The following conventions will be formulated and the corresponding checkers will be implemented in order to validate the generated model:

1. property inheritance requires class inheritance: if association ends (on the same side) are linked to two different classes, the the classes needs to be linked with a class inheritance connector.
2. direction of inheritance must be the same: the direction of the class inheritance connector must follow the direction of the property inheritance connector.
3. connector direction must be the same: both associations must have same direction (roles defined on the same side of association end).

In case of a violation, a proper warning will be reported in the HTML convention report.

Documentation

The conventions and checkers will be documented in the model2owl documentation: in the UML Conceptual Model Conventions and the UML Convention checker inventory sections.

[muricna]

@gkostkowski According to OP-TED/ePO#664 (comment) the property inheritance is already covered in the OWL .

I see in the OWL file two subproperties:

<rdf:Description rdf:about="http://data.europa.eu/a4g/ontology#isSubjectToLotSpecificTerm">
<rdfs:subPropertyOf rdf:resource="http://data.europa.eu/a4g/ontology#isSubjectToTerm"/>
</rdf:Description>

<rdf:Description rdf:about="http://data.europa.eu/a4g/ontology#isSubjectToProcedureSpecificTerm">
<rdfs:subPropertyOf rdf:resource="http://data.europa.eu/a4g/ontology#isSubjectToTerm"/>
</rdf:Description>

What is the current situation of how Model2OWL treats inheritance with regard to the OWL file?
Why was it thought a solution for SHACL shapes was needed and why was this need subsequently rejected?

[gkostkowski]

@muricna the OWL transformation rule is indeed already implemented. Apologies for the mix-up, the above solution description has been updated to reflect that.

To address the part about the SHACL shapes, here is the explanation of how the nature of the ticket has changed over time.
First of all, what we concluded in December (and still stand by that position) that there are no SHACL shapes that could be generated for property inheritance. The related tickets (ted-rdf-mapping-eforms#18, epo#635 and epo#632) have provided some insights on what was thought to be needed, that is additional constraints in existing SHACL node shapes for classes being domains of properties in inheritance relationship.
As we re-analysed the matter, we discovered that the current modelling practice (conflation of inheritance and overriding) needs to change. New need indicates that property overriding shall be treated separately from property inheritance. The discovery also shed some light on why the SHACL shapes were requested in the first place. The need for SHACL shapes is valid, but it affects overriding that hasn't been considered in the scope (as confirmed recently by @cristianvasquez and @victoriobentivogli ).
Lastly, the scope of the ticket evolved into conducting a research on property overriding.

As for now, the scope of the ticket contains:

1. missing parts for property inheritance: documentation of conventions and checkers and implementation of the checkers (as described in the solution description)
2. two new GitHub tickets for property overriding: the first one will be created in ePO project for work needed to introduce overriding or an alternative modelling technique to address the discovered need to express the relationship between two properties. The ticket will provide specific action points needed to lay the foundations for the second task that will be created in model2owl project and aim to provide support for the new feature in model2owl
3. we propose compiling findings from the research we made as a part of this ticket into a report to be delivered

As for the other artefacts previously included in the solution description, support for the glossary has been excluded as we concluded that it would be rather relevant for overriding than inheritance case.