[seek-kr-sms] property restrictions in growl

Shawn Bowers bowers at sdsc.edu
Mon Aug 2 09:40:09 PDT 2004


I believe you don't say anything incorrect below.  To use a class or 
property in OWL it has to be defined first.  All of the OWL syntax 
checkers I have used require this constraint.  (Note that not all of the 
  syntax checkers are the same, however.)

In a graphical editor such as GrOWL, I don't think as a user, I would 
want to necessarily have to follow OWL to construct a model. If I draw a 
line between two classes, name it, and give the property restrictions, 
then that should both create the property and the restriction ... or 
maybe I am missing something. Also, some "restrictions" are defined at 
the property-level and some per class -- but as a user, you shouldn't 
have to worry about these two "modes".


Shawn


Serguei Krivov wrote:
> Hi All,
> 
> We have been working hard on first alpha release of growl. Yet we have 
> got a couple of important issues which probably should be resolved 
> beforehand. A long discussion between me and Rich have not brought us to 
> a clear consensus, so the feedback from the group is wanted at least for 
> the most controversial issues.  Here is one:
> 
>  
> 
> Issue #1  Should we allow user to define property restrictions without 
> defining  explicitly the repective property? Or should we demand that 
> user alwase define a property with domain and range and only then get 
> permision to define (any) restriction on this property.
> 
>  
> 
> We are not sure what is legal in owl, specifically in owl-dl, but we 
> have different intuitions about it. On one hand when reading a property 
>  restriction with no explicit property definition owlapi   complains 
>  that it is not an owl-dl construct. Also just to exclude the 
> possibility of typos while defining restriction it would be advantageus 
> to have combo boxes that strictly confine  the names for restriction to 
> link them to the properties that have been already defined.
> 
>  
> 
> On the other hand, we know it that definition of domains and ranges is 
> not realy requred for tableaux algorithms to reason. Moreower – semantic 
> of  domains and ranges in owl-dl is defined   via property restrictions 
> which are  the elementary constructs in DL. Therefore the complains in 
> owlapi about non-dl construct  is weared. It may be related to the fact 
> that  from owl syntax it does not follow if a restriction pertained to 
> data property or object property. For example here is the code:
> 
>  
> 
> <owl:Class rdf:about="http://a.com/ontology#Object1">
> 
>   <rdfs:subClassOf>
> 
>   <owl:Restriction>
> 
>     <owl:onProperty rdf:resource="http://a.com/ontology#Relation1" />
> 
>         <owl:minCardinality 
> rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
> 
>         >2</owl:minCardinality>
> 
>   </owl:Restriction>
> 
>   </rdfs:subClassOf>
> 
> </owl:Class>
> 
>  
> 
> Is Relation1 an object property or a data property? From owl syntax it 
> does not follow and may be this is a reason for the complain. This 
> uncertainty as we see it here may be a problem of owl design , but it is 
> not problem of growl, since growl has different node types for object 
> property restrictions and data property restrictions. And if property 
> restrictions with no explicit property definitions are allowed in owl-dl 
> we have to support their editing in growl.
> 
>  
> 
> So what we have to do with so called  “non typed” property restriction 
> –allow them in growl or banish them from growl? Any of your thoughts on 
> this subject would be welcome.
> 
>  
> 
> Thanks,
> 
> Serguei
> 




More information about the Seek-kr-sms mailing list