Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Definition of the ranges of the restrictions #70

Open
giorgialodi opened this issue Dec 9, 2020 · 3 comments
Open

Definition of the ranges of the restrictions #70

giorgialodi opened this issue Dec 9, 2020 · 3 comments
Labels
type: feature request something requested to be implemented in a future release

Comments

@giorgialodi
Copy link

As discussed with @costezki in a recent call, in the last version of the OWL restriction file (version 07/12) restrictions do not specify the type of range. Therefore, in software like Protégé restrictions are attributed to generic "owl:Thing" when it is an object property or to "rdfs:Literal" when it is a datatype property.
I think it is important to specify the type of the range of the object and data type restrictions.

See screenshot for the class Procedure:
Screen Shot 2020-12-09 at 12 37 09

In this case for instance the property hasAccelerated should be exactly 1 xsd:boolean (in the ideal world probably is max 1 xsd:boolean but this has to be fixed at the modelling level) or hasID should be exactly 1 Identifier etc.

@costezki
Copy link
Collaborator

Restrictions shall be as non-redundant as possible.
Property range restrictions are specified in the property definitions and, not in the subclass definitions based on property-based restrictions.

Protege shows currently a generic type (owl:Thing or rdfs:Literal) in the restriction definitions. The reasoner should, however, derive the correct range from the property definition and accommodate it in the restriction definition. Hence Protege should display it accordingly.

This remains to be further tested and decided.

@giorgialodi
Copy link
Author

@costezki I am not able to run Hermit reasoner. It lasts for ages. It seems stuck in data type properties. I will retry but it does not seem good :-(

@costezki
Copy link
Collaborator

@giorgialodi, thank you for trying. We will have to plan a proper analysis for the reasoning aspects in the future so do not worry about this for the moment.

@Dragos0000 Dragos0000 added type: feature request something requested to be implemented in a future release and removed evolution labels Aug 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature request something requested to be implemented in a future release
Projects
None yet
Development

No branches or pull requests

4 participants