[seek-kr-sms] GrOWL Applet

Bertram Ludaescher ludaesch at sdsc.edu
Thu Jan 29 05:12:57 PST 2004

Hi everybody:

I'm not sure whether this is pertinent to this discussion, but here is 
what it reminded me of:

When graphically visualizing an ontology, we can distinguish two

1. The graph is a canonical representation
2. The graph is one of a number of alternative representations.

Here I'm not talking about graph *layout*, but the actual graph itself 
(i.e., the sets of vertices and edges).

(1) is what one would like to have. For example, think of a graph
database having edges representing binary relations such as parent,
sibling, ancestor, etc. For a given family, there is exactly one graph 
representing the family relationships

(2) can happen when you come up with a graph of logic formulas. 
For example, consider a set of OWL axioms, i.e., a certain set of
first-order logic formulas. You can "graph" them as we have done for
example here (called "domain maps"; Figure 1 of the first paper):


However, there is a problem with this "graphing" of a set of logic
axioms: there are many (in fact infinitely many if you're not careful
;-) ways of doing that.

That's why one should distinguish between the *axioms* (syntax) of an
ontology (there are many equivalent sets for a given set of axioms)
and the *models* (semantics) of an ontology. In the ideal situation,
one would have one canonical model (still a symbolic one) that
represents the intended semantics of the given set of axioms. 
Then one would "graph" the model (and not the axioms).

Having said that, here is my question:

What are you guys graphing: OWL axioms or OWL models? (or sth else)


>>>>> "RW" == Rich Williams <rwilliams at nceas.ucsb.edu> writes:
RW> I like the idea of labeling union nodes as 'is one of' and intersection
RW> nodes as 'is all of'.  In  some cases (perhaps most?), it is possible to
RW> entirely eliminate the intersection node, but this might involve more
RW> processing of the OWL ontology than is practical.  Consider that the
RW> following two OWL fragments are semantically identical, and so it might be
RW> nice to display them both the same.  Otherwise this example would lead to
RW> displays like:
RW> Test3--is-a--Test1
RW>     |
RW>      --is-a--Test2
RW> And:
RW> Test3--is-a--[is all of]----Test1
RW>                        |
RW>                         ----Test2
RW> Rich
RW>   <owl:Class rdf:ID="test1"/>
RW>   <owl:Class rdf:ID="test2"/>
RW>   <owl:Class rdf:ID="test3">
RW>     <rdfs:subClassOf rdf:resource="#test1"/>
RW>     <rdfs:subClassOf rdf:resource="#test2"/>
RW>   </owl:Class>
RW>   <owl:Class rdf:ID="test1"/>
RW>   <owl:Class rdf:ID="test2"/>
RW>   <owl:Class rdf:ID="test3">
RW>     <rdfs:subClassOf>
RW>       <owl:Class>
RW>         <owl:intersectionOf rdf:parseType="Collection">
RW>           <owl:Class rdf:about="#test1"/>
RW>           <owl:Class rdf:about="#test2"/>
RW>         </owl:intersectionOf>
RW>       </owl:Class>
RW>     </rdfs:subClassOf>
RW>   </owl:Class>
>> -----Original Message-----
>> From: seek-kr-sms-admin at ecoinformatics.org
>> [mailto:seek-kr-sms-admin at ecoinformatics.org]On Behalf Of Ferdinando
>> Villa
>> Sent: Wednesday, January 28, 2004 8:59 AM
>> To: Serguei Krivov
>> Cc: seek-kr at ecoinformatics.org
>> Subject: Re: [seek-kr-sms] GrOWL Applet
>> Congrats to Serguei and Rich for these encouraging results! Now what we
>> need is to make the representation easy to understand - of course we are
>> not asking our "average user" to wade through intersection nodes and
>> restrictions, but at least in browsing mode, we want a smart (and
>> hopefully configurable) graph transformation step to turn this into the
>> simplest and clearest concept map imaginable.  I think we need a wider
>> group consensus on this, but here are a few points to start with:
>> - recognize Intersection/Union nodes that link two classes and just
>> label them something like "is both" or "is one of", consistently with
>> "is a";
>> - recognize those that point to restrictions and use some variation of
>> the "is a" theme with a "where" link attached
>> Coming up with a full set of these simplifications won't be easy but I
>> think the success of the approach will rest on it. Ideas, anyone? If we
>> could define these transformations parametrically and load them into the
>> editor as a style sheet, that would be the best. We may even want to use
>> some smart graphical symbols in the future.
>> Ciao
>> ferdinando
>> On Wed, 2004-01-28 at 11:11, Serguei Krivov wrote:
>> > Here is the first version of GrOWL applet:
>> >
>> > http://ecoinformatics.uvm.edu/dmaps/growl/GrowlApplet.html
>> >
>> >
>> >
>> > It shows camera ontology:
>> > http://ecoinformatics.uvm.edu/dmaps/growl/camera.owl ,from where I
>> > deleted one import statements. Apparently displaying owl with import
>> > statements in an applet is not going to be   straightforward.  Applets
>> > are not allowed to read from urls other then the server they came
>> > from, so import of the files from other host would require some
>> > workaround . It is possible to create a java servlet   which would
>> > fetch the files from “foreign” sites, but this would also require
>> > extensive modifications to OWLAPI
>> >
>> >
>> >
>> > I replaced “anonymous” label by “restriction”, as Rich said. Please
>> > advice if this is better.
>> >
>> >
>> >
>> >
>> >
>> > Serguei
>> >
>> >
>> --
>> _______________________________________________
>> seek-kr-sms mailing list
>> seek-kr-sms at ecoinformatics.org
>> http://www.ecoinformatics.org/mailman/listinfo/seek-kr-sms
RW> _______________________________________________
RW> seek-kr-sms mailing list
RW> seek-kr-sms at ecoinformatics.org
RW> http://www.ecoinformatics.org/mailman/listinfo/seek-kr-sms

More information about the Seek-kr-sms mailing list