[seek-kr-sms] GrOWL Applet

Ferdinando Villa fvilla at uvm.edu
Thu Jan 29 06:04:05 PST 2004 

Exactly my point - thanks Bertram for putting it in English. I think what we're
after is a graph representation of a more general ontology model, that
encompasses and transcends an OWL ontology - and is the simple and most
intuitive representation for a nonliterate user to understand. Apart from the
obvious ugliness of OWL constructs (show this to a user and they will never
come back to your site/service), we may not be using OWL forever. I think we
can restrict its role to browsing and printing, which should simplify the task,
and it doesn't need completeness for now - just those constructs that we're
really using. Ideally we should be able to define the necessary transformations
as a "style sheet" that could be changed to accommodate DAML/OIL or whatever -
but it would be enough to have it working for OWL for the time being. 

What we need is to define this model, and then find out how to translate them.
Given that OB uses a graph model internally, I don't think it should be that
hard. The graphical mapping looks easy to do for logical operators implied in a
class definition using only isa relationships - "is all of", "is any of", "is
one of" are good intuitive replacements for and, or, xor that can take the
place of the bulky Intersection, Union etc. nodes, and can work for oneOf
restrictions as well - but we need a strategy for other restrictions (something
with a "where", but how do we make it small enough). Cardinalities can just
turn into arrow shapes a la ER diagram. Other ideas? Maybe we can make a
priority list of restrictions that are both likely to see widespread use and
need a more intuitive graphical representation?

Ciao f 

On Thu, 2004-01-29 at 08:12, Bertram Ludaescher wrote:
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
> cases:
> 
> 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):
> 
> 	http://www.sdsc.edu/~ludaesch/Paper/icde01.html
> 
> 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)
> 
> Bertram
> 
> 
> >>>>> "RW" == Rich Williams <rwilliams at nceas.ucsb.edu> writes:
> RW> 
> 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> 
> RW> Test3--is-a--Test1
> RW>     |
> RW>      --is-a--Test2
> RW> 
> RW> And:
> RW> 
> RW> Test3--is-a--[is all of]----Test1
> RW>                        |
> RW>                         ----Test2
> RW> 
> RW> Rich
> RW> 
> RW> 
> 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> 
> RW> 
> 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>
> RW> 
> RW> 
> >> -----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> _______________________________________________
> 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