[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