[seek-kr-sms] property restrictions in growl

[Rich Williams]

>
>
> 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) (????)
>

As far as I can tell, both Jena and OWLAPI require that a property be
declared before it is used.  So for example

  <owl:ObjectProperty rdf:ID="objProp"/>
  <owl:Class rdf:ID="Test1">
    <rdfs:subClassOf>
      <owl:Restriction>
        <owl:onProperty>
          <owl:ObjectProperty rdf:about="#objProp"/>
        </owl:onProperty>
        <owl:minCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
        >2</owl:minCardinality>
      </owl:Restriction>
    </rdfs:subClassOf>
  </owl:Class>

is fine in both, but remove the first line and both complain.  So no need
for a domain and range specification, just a declaration of the property's
existence (which of course in OWL has an implicit range, since object and
data properties are differentiated).

Now for my 2-cents worth on this.  I think that when creating a property
restriction, the user interface should have a text box that incrementally
matches on the current (object or data) property names.  If the user types
in a non-existent property name, the editor should create the property, so
that it is in the list of known property names the next time a restriction
is created.  The owl file needs to be saved with a property declaration in
it, otherwise no known tool will be able to read it in.

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

I think global restrictions like functional property?

>
> 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
> >
>
> _______________________________________________
> seek-kr-sms mailing list
> seek-kr-sms at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/seek-kr-sms