[Fwd: Re: [seek-kr-sms] ontology/folder UI design in Kepler]

[Serguei Krivov]

The major difficulty  in creating ontologies perhaps is not the
availability of tools, but the underlying complexity of the intellectual
component.   Either before Linnaeus and after Linnaeus, serious and
useful classifications have never been developed just in a couple of
hours. On the other hand, when ontology is created (E.g. by a group of
scientists dedicated to just creating the ontology) it could be used by
others with relatively little efforts. In this case it is also important
to have an easy way to browse it. 

May be if by use of formal ontologies in ecological application and in
SEEK we  mean mainly the use of existing ontologies then it is safe to
assume that domain experts will be able to handle it. Perhaps the
creation of ontologies  will be always a bit a challenge and often the
difference between ontology editors is marginal comparing to the
intellectual component(E.g. writing "Hamlet" in MSWord would be easier
then writing it all by a goose feather, but the difference is obviously
marginal comparing to the intellectual component of the work).

serguei
 


Shawn,

I think we can use our own experiences to clarify what an ecologist
might or
might not be able to do, at least in the near term.  In the few times
that I've
tried to organize a set of terms into an "ontology" for you, and in the
times
I've watched the postdocs/faculty try to do it, none of us have ever
given you
anything remotely close to what you needed.  That's definitely a
concern, if
we're going to have the ecologists do it themselves. I honestly don't
think
you're going to get what you want from most ecologists without
substantial
training.  I think the likelihood of them going after such training is
small. 
Its telling that many of the people at this last workshop took offense
when I
suggested that it would be a good idea for them to learn how to
program...and
the usefulness of that should have been much more obvious to them than
the
usefulness of creating ontologies. I think we are a long way from having
a
community of ecologists who have the skills or desire to invest
considerable
effort learning how to do this.  Perhaps eventually we will develop a
community
of ecoinformatics people who are more on the domain side than the IT
side, who
can learn how to do this and work at the interface.  For the short term,
I don't
see any way around having a "knowledge engineer" work with the
ecologists.  But,
I reserve the right to change my mind when you demonstrate an ontology
tool that
is, in fact, easy to use for a domain person :-)

Deana


Quoting Shawn Bowers <sbowers at ucdavis.edu>:

> 
> Some comments:
> 
> Laura L. Downey wrote:
> >>Shawn writes:
> >>I think that this is (or at least was) exactly one of the "missions"
> in 
> >>SEEK: to get scientists involved in creating and using *formal*
> ontologies.
> > 
> > 
> > Using formal ontologies, yes.  I have definitely seen some
excitement
> when
> > semantic mediation has been talked about in a way that will make
their
> jobs
> > easier -- of finding other data sets they would not otherwise have
> found,
> > when identifying actors that would be useful to them that they
> otherwise
> > might not have identified etc.  And yes, creating the ontologies
> themselves
> > too, because they know their domains better than we do, but formally
> > specifying them so that machines can make use of them? I'm not so
sure
> about
> > that from what I've seen.  But again, remember I'm new to the
project
> so
> > bringing an outsider perspective and maybe one that needs to be more
> > informed.
> 
> I think "formally specifying ontologies" is a loaded phrase ... it is 
> being used to refer to the languages (such as OWL) and tools (such as 
> Protege) that have known deficiencies not only for "domain scientists"
> 
> but also in general for capturing knowledge. OWL is a W3C
specification
> 
> that is based on XML and is overly verbose (being expressed in XML)
and
> 
> often misused. It is really just an interchange format, and not really
a
> 
> language unto itself (it's meant to encompass many languages so as to
be
> 
> a good middle-ground for tools that use disparate languages).  Protege
> 
> is a tool that is still young and is just starting to be more widely 
> used. It is, however, in many ways still designed for a very small, 
> highly technical user group.
> 
> Ontology tools should be such that they present a sound and intuitive 
> user model (i.e., the conceptual constructs used to create
ontologies),
> 
> shielding the user from the underlying interchange format. Most tools 
> that are out there essentially present a low-level graphical version
of
> 
> the language, not of these higher-level conceptual constructs. A
counter
> 
> example is CMAP, however, it's model in my opinion is too
unconstrained,
> 
> and offers little support in terms of helping users to create 
> well-designed and "consistent" ontologies.
> 
> I also think this notion that a domain scientist will "informally" 
> construct an ontology and then pass it off to a "knowledge engineer"
to
> 
> "make it formal" is (a) not a scalable solution, (b) "passes the buck"
> 
> to an unknown entity (i.e., the non-existent "knowledge engineers"),
and
> 
> (c) in general, is not always a sound approach.  (I'm not picking on
you
> 
> here Laura -- these are just some observations; and I'm trying to 
> stimulate some discussion as to what the approach should be for SEEK.)
> 
> I think in SEEK, this notion of a knowledge engineer has been used in 
> place of providing useful tools to our users.  I think if anything,
the
> 
> "knowledge engineer" should be built into the tool -- which is
starting
> 
> to emerge in some other tools, including protege.
> 
> I think that the challenge in defining a "formal ontology" for a 
> particular domain is that as a user: (1) you need to have a clear 
> understanding of the domain, the concepts, their definitions (very 
> challenging in general), and (2) you need to understand how to
represent
> 
> this information in the knowledge representation language/tool.  If a 
> domain scientist gives the knowledge engineer the first item (1), then
> 
> the scientist could have just as well input the information in a 
> well-designed ontology tool. If the knowledge engineer gives a vague
and
> 
> imprecise description of (1), then the knowledge engineer has no
chance
> 
> of doing (2).  My argument is that to "create ways for regular users
to
> 
> provide the appropriate input to the knowledge engineers so that items
> 
> are formally specified" essentially means that the "regular users"
have
> 
> already specified the ontology -- and they don't need the KE (of
course
> 
> this could be an iterative process, where the KE "holds the hand" of
the
> 
> scientist through the process -- which is again not going to scale and
> 
> is probably not that practical).
> 
> Of course, not only do we want to make (2) easy, we also want tools to
> 
> help scientists/users get to (1). I think there are lots of ways to
help
> 
> users get to (1), e.g., by:
> 
> - describing a process/methodology, like in object-oriented analysis
and
> 
> design that can help one go from a fuzzy conceptualization to a
clearer
> 
> model (we want to target scientists, however, instead of software 
> designers/developers)
> 
> - providing tools to help people "sketch" out their ideas before 
> committing to an ontology language (but make it explicit that they are
> 
> doing the "sketch" as part of a process) ... e.g., by allowing some 
> free-text definitions mixed with class and property defs, etc. 
> Essentially, provide a tool that can facilitate someone to go from 
> informal/unclear to formal/clear.
> 
> - adopting some known approaches for "cleaning up" an ontology
(similar
> 
> to OntoClean, e.g.)
> 
> - providing tools that can identify inconsistencies and possible 
> "pitfalls" in the ontology (useful for getting to a clearer, more
formal
> 
> model)
> 
> - providing lots of examples of "well-defined" ontologies
> 
> - letting people edit and reuse existing well-formed ontologies (in 
> fact, I think that once we have a basic framework, this will be the 
> typical model of interaction for many scientists ...  )
> 
> 
> In terms of "machine understandable ontologies", this really just
means
> 
> that the ontology is captured in one of these ontology languages, like
> 
> OWL.  It doesn't mean that a scientist should have to literally put 
> their ontology into this language -- that is the job of the tool. Our 
> goal should be to help users specify ontologies using "structured" 
> approaches.  That is, essentially in restricted languages that are not
> 
> as ambiguous and not as unconstrained as natural language -- which is 
> typically done using graphical tools (box and line diagrams).  Also,
the
> 
> user should be completely unaware that their definitions are being 
> stored in these low-level languages; which is why the existing tools 
> fail for domain scientists / non computer-science folks.
> 
> 
> 
> 
> > Is the goal here to figure out a way to allow scientists with no
> formal
> > ontology experience to easily specify formal ontologies in a way
> that
> > machines can make use of them?  That seems like a daunting task to
me
> -- and
> > one that would require considerable time and resources.  Didn't I
just
> read
> > from Mark (in the IRC convo) that the knowledge engineers themselves
> have
> > trouble with their own tools like Protégé?  Creating and specifying
> formal
> > ontologies is a complex and challenging job even for those trained
in
> it.
> > 
> > I agree that scientists understand their domains better than others,
> but
> > that doesn't mean they understand how to formally represent that
> domain in a
> > way that can be utilized by a machine.  They user their own
> experience,
> > intuition, and knowledge to create ontologies.  They make decisions
> and
> > understand possible exceptions.  But that is a different task than
> formally
> > specifying that ontology to a rigid set of rules that can be
utilized
> via
> > machine processing.  I'm thinking that is still a task to be done by
> a
> > trained knowledge engineer.
> > 
> > And if we create ways for regular users to provide the appropriate
> input to
> > the knowledge engineers so that items are formally specified in such
a
> way
> > that the system can make use of them to the benefit of the regular
> users, I
> > would see that as a definite win and demonstration of the power of
> semantic
> > mediation to make scientists jobs easier.
> > 
> > Laura L. Downey
> > Senior Usability Engineer
> > LTER Network Office
> > Department of Biology, MSC03 2020
> > 1 University of New Mexico
> > Albuquerque, NM  87131-0001
> > 505.277.3157 phone
> > 505.277-2541 fax
> > ldowney at lternet.edu
> >  
> > 
> > 
> > _______________________________________________
> > 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
> 



**************************
Dr. Deana D. Pennington
Long-term Ecological Research Network Office

UNM Biology Department
MSC03  2020
1 University of New Mexico
Albuquerque, NM  87131-0001

505-277-2595 (office)
505 272-7080 (fax)
_______________________________________________
seek-kr-sms mailing list
seek-kr-sms at ecoinformatics.org
http://www.ecoinformatics.org/mailman/listinfo/seek-kr-sms