[seek-kr-sms] growl: owl-dl or owl full?!

[Bertram Ludaescher]

Rich Williams writes:
 > (I want to clarify that OWL is not necessarily stored in XML - the XML-RDF
 > syntax is just the most commonly chosen syntax.  You can store OWL (and RDF)
 > in much less-verbose, non-XML syntaxes.)

yes, very much such so (e.g. in one of the Sparrow variants =B-)

 > I agree that non-OWL-DL constructs should be avoided.  The extreme
 > flexibility of RDF and OWL-Full will make generic OWL-Full tools extremely
 > difficult to develop.  So far, the main thing that I have wanted to do that
 > is outside OWL-DL is to have a property that takes a class as its value,
 > rather than a class instance.  This restriction in expressivity leads to
 > some rather inelegant hacks to work around it and remain in OWL-DL.  Another
 > frequent issue is the lack of value restrictions on datatype properties, but
 > I don't think that this is available in OWL-Full either.  (One solution is
 > to subtype the xml datatypes to restrict the range of permissable values,
 > but no tools yet support this).

It seems that most of us feel that OWL-DL should be the focus -- so we
are converging. As mentioned before, constructs beyond DL might still
have some role to play in the future eg when *checking* the
consistency of a database instance w.r.t. a set of more ontology
constraints (those will in general be too powerful for *reasoning*
about them).

 > While I use Protege, I would not claim that it has anything approaching an
 > optimal user inteface, and I think that good visualization tools could play
 > a role for the so-called knowledge engineer (knowledge-model engineer?).
 > None of the graphical tools that I have experimented with have been better
 > for me than the Protege tree and dialog-box based user interface, so that's
 > what I use.
 > 
 > As far as the GrOWL UI goes, I see no reason why it can't be like the user
 > interface of many commercial software packages, where both entry-level and
 > expert users are accomodated.  There could be an easily-accessible set of
 > commonly performed operations (creating subclasses, disjoint, object and
 > datatype properties, some basic property restrictions etc), and the full
 > expressivity of OWL-DL could also be available through "advanced" or "more"
 > buttons in dialogs.

I'm wondering whether beyond the UI issues, there are even more severe
issues in creating, modeling with, and understanding of ontologies. 
Good visualizations and UIs can help to comprehend what's going on,
but a good grasp of the underlying formalism and the consequence of
different modeling choices will be important for "power
users/modelers". 

I see as a major research challenge "consequence management". Let us
be reminded that an OWL-DL ontology is a bunch of axioms. The axioms
themselves are a means to an end. The semantics of them is the set of
models (or minimal models) of the axioms. We need to be getting better
at visualizing and querying the logical consequences of axioms (not
just the axioms as such). This is a tough one. Visualizing the class
hierarchy is well understood and useful , but captures only the
(implied) isa relation. A generation of an extended UML or ER diagram
capturing some more semantics (properties/roles etc) might be useful
as well. 

Bertram

 > 
 > Rich
 > 
 > 
 > > -----Original Message-----
 > > From: seek-kr-sms-admin at ecoinformatics.org
 > > [mailto:seek-kr-sms-admin at ecoinformatics.org]On Behalf Of Shawn Bowers
 > > Sent: Thursday, June 10, 2004 10:18 AM
 > > To: Serguei Krivov
 > > Cc: seek-kr-sms at ecoinformatics.org
 > > Subject: Re: [seek-kr-sms] growl: owl-dl or owl full?!
 > >
 > >
 > > Hi Serguei,
 > >
 > > If you look at the Protege data model, they have a language that offers
 > > similar meta-modeling constructs as found in OWL-Full.
 > >
 > > In my opinion, the use of these constructs, unless you really know what
 > > you are doing, can be confusing and often leads to incomprehensible
 > > conceptual models.
 > >
 > > My general opinion is to not support similar constructs in GrOWL.
 > >
 > > But, it isn't clear to me at this point who the target user is of the
 > > GrOWL onto editing and management tools.  If it is scientists and other
 > > domain experts, I think most of the OWL-DL and even OWL-Lite constructs
 > > will be too much. For these users, I think we need to be very clear
 > > about what modeling constructs we want to support (e.g., these
 > > constructs may be at a "higher" level than OWL-DL constructs),
 > > explicitly support the needed constructs through visual notations (not
 > > OWL formulas); then figure out how those constructs are realized by
 > > OWL-Lite or OWL-DL.  Since GrOWL seems to be on track to output OWL
 > > ontologies, these can be further edited by a knowledge "engineer" if
 > > needed (to add more constraints). However, if the target user group is
 > > knowledge engineers, e.g., Rich and the KR group, doesn't Protege
 > > already offer the necessary interface?
 > >
 > > In general, the family of OWL standards are complex, with many modeling
 > > constructs, and verbose, not only because OWL is stored via XML, but
 > > also because it is based on RDF.  I think there is a definate need for
 > > ontology tools that do more than just expose OWL or any other DL -- like
 > > XML, OWL is much better suited as a storage and exchange language, not
 > > as an interface in and of itself for users.
 > >
 > > So, my overall suggestion, would be to figure out the necessary
 > > constructs for the target user group (which I'd be happy to help with),
 > > figure out how best to present these to the user (again, I'd be happy to
 > > help with this), then figure out if it is representable in OWL-Lite,
 > > OWL-DL (most likely), or OWL-Full (not likely).
 > >
 > >
 > > shawn
 > >
 > > Serguei Krivov wrote:
 > > > Hi All,
 > > >
 > > > I am working on growl editing and have an urgent design issue:
 > > >
 > > > Should we impose the editing discipline which would allow owl dl
 > > > constructs only and    do nothing when user tries to make an owl full
 > > > construct? Some editors like oil-edit (that works with owl now) are
 > > > intolerant to owl full. Personally I think that this is right since
 > > > owl-full ontologies are difficult to use. OWLAPI seems also not really
 > > > happy to see owl-full constructs, it reports error, however somehow it
 > > > processes them.
 > > >
 > > >
 > > >
 > > > Ideally one can have a trigger which switch owl-dl discipline on and
 > > > off. But implementing such trigger would increase the editing code may
 > > > be 1.6 times comparing to making plain owl-dl discipline. I would leave
 > > > this for the future, but you guys may have other suggestions (?)
 > > >
 > > > Please let me know what you think.
 > > >
 > > > serguei
 > > >
 > > >
 > > >
 > >
 > > _______________________________________________
 > > seek-kr-sms mailing list
 > > seek-kr-sms at ecoinformatics.org
 > > http://www.ecoinformatics.org/mailman/listinfo/seek-kr-sms
 > 
 > _______________________________________________
 > seek-kr-sms mailing list
 > seek-kr-sms at ecoinformatics.org
 > http://www.ecoinformatics.org/mailman/listinfo/seek-kr-sms