You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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.
@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.
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:
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.
The text was updated successfully, but these errors were encountered: