[seek-kr-sms] property restrictions in growl

Serguei Krivov Serguei.Krivov at uvm.edu
Mon Aug 2 11:55:18 PDT 2004


Hi Shawn,
Thanks for your feedback. I have a couple of questions( please see
below)

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.)


Do you mean that all syntax checkers you have used would require user to
say "property P has domain C1 and range C2) before user  can  say
something like
(forall P C3)  or (>4 P C4) (????)


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".

I understand what are restrictions defined for a class. What do you mean
by restriction defined at property level?


Thanks,
serguei

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