advice request - dataset with SHACL - avoiding error report after adding object property

[Jan Serneels]

Hi,

I use VocBench 15.1.0

What should i do differently to avoid SHACL error report pop-up when adding an object property to an individual? 

All this is new to me, so please correct me in any way.

[1] In a self made Ontology there are some classes and some object properties defined.

Lets say:

* classes : A, B, C, D

* object properties :  'contains'

[2] A SHACL was defined and used to make the custom forms for creation of individuals.

Some rules are :

* in the shape for class A :

    sh:property [
        sh:path jan:contains ;
        sh:minCount 0 ;
        sh:class jan:B ;
        sh:message "A class A can only have 'contains' relationships with a B" ;
    ];

* in the shape for class B:
    sh:property [
        sh:path jan:contains ;
        sh:minCount 0 ;
        sh:or (
            [ sh:class jan:C ]
            [ sh:class jan:D ]
        ) ;
        sh:message "A class B can only have 'contains' relationships with a C or D" ;
    ] ;

[3] This works like a charm with custom forms for creation of individuals.

Custom forms are super good. :-)

[4] Now my real question

When selecting to add a 'contains' object property to an existing individual a popup appears for selecting an individual to relate to.

But the choice of classes in the pop-up is too large and may generate a SHACL error report popup after selecting a class that breaks the rule.

How can i avoid this?

2 things i tried :

(a) add Domains and Ranges to the 'contains' object property

Domains : A, B

Ranges : B, C, D

This gives a limited list of classes and is a step into the right direction. The list always consist of A and B independant of the selected individual where we want to add the 'contains' relationship to.

So it is still possible to make a selection that brakes the SHACL rule.

(b) add class axioms

* For class A ( rdfs:subClassOf ):

:contains ONLY :B

* For class B  ( rdfs:subClassOf )  :

:contains ONLY ( :C OR :D)

Does not seem to have any effect on the list of classes in the pop-up.

[stel...@uniroma2.it]

Dear Jan,

 

you are right, class axioms are (currently) not processed for suggesting ranges. The reason is that it might work easily on certain expressions but not in general, where a posteriori checks with a reasoner would be needed (yet, an attempt for simple cases and possibly informing of not being able to treat more complex ones, wouldn’t be bad).

Custom Ranges are bound to the property in general.

 

I see potential improvements, such as:

 

• Handling trivial range-restrictions axioms on classes (that would be my first choice)
• Having class-bound custom-ranges
• Reading SHACL constraints

 

Kind Regards,

 

Armando

 

--
You received this message because you are subscribed to the Google Groups "vocbench-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vocbench-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vocbench-user/b98b3abf-46bf-4a4c-9e58-db337a200c1en%40googlegroups.com.

[Jan Serneels]

Dear Armando,

Thank you for your response and for the software you create.

I understand what you propose.

Maybe it is interesting to also consider the custom form definition linked to the class. ( which in my case was based on the SHACL file)

For it determines the UI functionality of the "Create Individual" form (inclusive of how the 'contains' relationship can be added)

That form definition could be used to also impact the the view of the "Add property", "Delete property" functionality of the individual of a certain class.

(in the same/analoguous way as it does in the create Form)

In this way 1 mapping between class and form activates coherent functionality for creation and updating individuals.

 

Kind regards,

    Jan Serneels