[Fwd: Re: [seek-kr-sms] ontology/folder UI design in Kepler]
Laura L. Downey
ldowney at lternet.edu
Wed Mar 2 12:39:57 PST 2005
As someone new to the project, I'm still trying to understand which user
group we are designing for -- knowledge engineers, domain scientists, both,
or some hybrid of an ecologist with some ontological knowledge. And the
next question is to what level we are trying to support the various tasks
these users might perform within Kepler. Deana and I had a good discussion
this morning where she was catching me up on things and where she mentioned
that the KR-SMS team is still in the process of determining the target users
and associated tasks. Until we have that information we can't really fully
design the ontology UI.
We could however, as I and others have mentioned, certainly incorporate some
"picking concepts" mechanism where we display the known concepts and allow
the user to select concepts to support the task of assigning concepts to
datasets and/or actors. I'm assuming (dangerous I know) that Matt is
referring to something similar with his "browsing" terminology in his last
note and which we'll know more after he gets the wiki page up he referenced.
Later, after we have more information, it might be possible to supplement
that "concept selection" by offering some list of questions the user has to
answer in order to do their tagging. We could even consider a wizard like
UI if we managed to formulate a basic set of questions, easily
understandable by domain scientists that could be translated to work
properly within a formal ontology. But again, I would not see being able to
determine that set of questions until the KR-SMS team has hashed out their
target user group(s) and determined the kinds of tasks they would perform.
But in the interim, we could offer some hierarchical representation for
users to pick concepts from.
I noticed that Serguei has offered a set of questions based on the "tagging
task" for us to consider in trying to determine which kind of specific UI
(including metaphors) we might offer. At first I thought he was offering
these as questions as something to translate into English ;-) for the users
to answer to help them do their annotations. But Deana pointed out that was
not the case.
One quick question here, are we really thinking about letting users annotate
ports? This seems to be a very very low level of annotation that I can't
see that many users doing. Is this related to the data integration issue?
Back to Serguei's questions.... if I'm understanding them correctly (with
some help from Deana) basically he's asking does the user need to understand
all the complexity in the ontology. And if so, then a tree representation
can't adequately communicate that complexity. However, I think that the
complex graphs produced by the various ontology tools are certainly
difficult enough for experienced KE's to decipher, much less domain
scientists, even those with some ontological knowledge. Ferdinando brought
up the issue of graphic extension philosophy as a means of trying to
simplify these complex graphs but after looking at those examples, I'm not
convinced they would be applicable to scientific ontologies -- especially
after talking with Deana about the nature of scientific ontologies. Those
examples work because there are these easy binary groupings like man/woman
or mother/father etc in the family tree example, or small numbers of large
categories like chemical compounds falling into one broad category (nitrogen
compounds) with say 3 different kinds of processes to apply to them.
I think it might be possible to use the graphic extension philosophy a
little in a tree representation -- for example some symbol that indicates
that a concept is used in multiple places within the tree, with the option
of showing the various "neighborhoods" that a concept is used in. (Think
about an option that says show me all the occurrences of "concept X" and a
view of the tree being expanded one level above and below the various
occurrences of "concept x" with concept X highlighted and everything else in
the tree collapsed. I also think we could support the operation of showing
the user other items that have been assigned a certain concept. And we
might offer filtering and searching on the tree too. Lots of these
suggestions support the notion that the user has an idea how they want to
classify something and only needs to see various pieces to make a decision.
Of course if the user wants to see the entire tree, we have to make that
available too. And that is a tough problem lots of people seem still to be
working on -- visualization of large hierarchies.
Signed -- new kid on the block who has no problem with Shawn picking on her
-- she can take it. ;-)
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
-----Original Message-----
From: Matt Jones [mailto:jones at nceas.ucsb.edu]
Sent: Tuesday, March 01, 2005 4:41 PM
To: Deana D. Pennington
Cc: Mark Schildhauer; Bertram Ludaescher; Shawn Bowers; Laura L. Downey;
seek-kr-sms at ecoinformatics.org
Subject: Re: [Fwd: Re: [seek-kr-sms] ontology/folder UI design in Kepler]
Actually, I think there are two issues: what we expose to them in Kepler
for browsing, and what we expose to users in Kepler for
editing/supplementing. I'm writing up a little wiki page on this now
and will send around a link tomorrow.
Matt
Deana D. Pennington wrote:
> Very nice sum up of all the KR, Mark! So, what is your opinion about the
level
> of ontology detail that should be exposed to a Kepler user?
>
> Quoting Mark Schildhauer <schild at nceas.ucsb.edu>:
>
>
>>Hi folks,
>>
>>Since my name has come up, I guess I should join this snowball fight.
>>
>>For the KR side, I consider the main players inside the SEEK/BEAM
>>context to be Shawn, Deana, and me (and in the past, Rich, and at some
>>
>>point in the relatively near future, Rich's replacement). Serguei and
>>
>>Ferdinando are also working away at highly relevant aspects with GrOWL
>>
>>and their experiences with domain ontologies, as are Peter and Manu for
>>
>>the spatiotemporal stuff.
>>
>>I think things are progressing on all fronts. Yes-- we absolutely will
>>
>>be attempting to construct ontologies at the upcoming Davis meeting. We
>>
>>have attempted to construct them at past meetings as well. We have
>>
>>wrestled with the formalisms and tools necessary to create these
>>ontologies, from both the KE side, as well as the domain side. We've
>>tried out a bunch of tools (isaviz, protege, metalog, growl,
>>code/cmap)-- and have most recently been using Protege' on the formal
>>side (for KE/KR experts), and CMAP on the domain side (informal concept
>>
>>modeling). We have a number of formal ontologies already in hand-- our
>>
>>KR person, Rich, constructed over a dozen of these, and they reside in
>>
>>CVS. Ferdinando and Serguei similarly have ontologies available on
>>their home site.
>>
>>Deana has boldly constructed several "informal" ontologies using
>>CODE/CMAP, which Shawn has reviewed. These are challenging the notion
>>
>>that napkin-sketch ontologies are what we need. Shawn has found that
>>Deana's concept maps raise interesting issues and concerns relative to
>>
>>subsumption hierarchies from a formal side, whereas I look at them and
>>
>>see the points and feel they have heuristic value.
>>
>>We are explicitly developing ontologies for productivity and
>>biodiversity, as these tie-in with the BEAM use case. Our meeting next
>>
>>week at Davis will focus on this. Specific challenges that ontologies
>>
>>in this context will help address include data transformations on the
>>one hand (compatibility of data sets, tracking the semantics of data
>>transformation, etc.), enabling powerful data discovery via ontologies
>>
>>(e.g., a query on biodiversity reveals a data set with counts of
>>taxonomically labelled information), and tie-ins with Kepler for
>>workflows and analyses (e.g., biodiversity indicates some specific
>>algorithms such as Shannon Index, that in turn requires certain types of
>>
>>data to calculate).
>>
>>Moreover, with our other use case on Ecological Niche Modeling, we have
>>
>>developed some rough ontologies, though there utility there is not as
>>pressing as with our second use case (described above) which was
>>specifically chosen because it presented interesting opportunities on
>>
>>the KR/SMS front. We did identify an interesting perspective that in
>>some forms of scientific debate (in this case, among Terry Dawson and
>>some of his colleagues) it may be the case that developing formal
>>ontologies will clarify the fundamental differences in (terms, concepts,
>>
>>relationships) that are actually fueling the disagreement. We intend
>>
>>to follow up on this in our copious free time.
>>
>>Shawn and Rich drafted an Eco-ontology manual, which Shawn, Deana and I
>>
>>have discussed a fair bit, most recently in terms of some papers by
>>Guarino and Welty on how to create "sensible" ontologies (ONTOCLEAN
>>technique)-- but things are not simple, as this task requires
>>understanding concepts like essence, rigidity, unity, and identity.
>>Shawn and I have recently been grappling with how to distill and present
>>
>>these concepts to ecologists. Philosophy 101, anyone?
>>
>>Shawn has been engaged with the Kepler community to keep things honest
>>
>>in terms of whatever style ontologies we develop out of KR/SMS, these
>>won't be incompatible and indeed, will be powerfully exposed through
>>Kepler. Shawn has also been involved with some discussion about a
>>repository for these ontologies in terms of the Ecogrid (correct me if
>>
>>I'm out of line, here).
>>
>>We are trusting that Manu Juyal and Peter McCartney are thinking about
>>
>>and progressing with a spatio-temporal ontology, and we expect to get an
>>
>>update on this at the Davis meeting from Manu.
>>
>>Shawn, Matt, and I have been discussing the units dictionary aspect of
>>
>>the EML, especially since this is where we have a challenge with an
>>ontology like "units dictionary" that has conversion factors, and
>>tie-ing these in with EML metadata (currently at the attribute level).
>>
>>There have been some in-depth discussion of these matters recently on
>>IRC, as these impact our entire strategy for how to focus on annotating
>>
>>metadata (and hence data),and linking these up with ontologies. I think
>>
>>the unit dictionary is a clear-cut and simple case for hooking up an
>>ontology to our metadata, and we should really be focusing on
>>developing a general mechanism through this test case (and I think
>>Shawn, Peter, Matt and others feel similarly)
>>
>>The paper that was jointly submitted to SSDBM on SMS (Shawn has the ref)
>>
>>promises a lot of capabilities within the SEEK framework, so for those
>>
>>who want to know where we are going, that is a good place to check.
>>
>>Peter has recently raised the possiblity that some LTER Information
>>Managers could become involved with the KR effort to extent of
>>clarifying "canonical" variables collected across research sites on
>>standard data sets, and this is a *great* idea. Still, we want to be
>>sure these efforts are maximally leveraged in terms of building into a
>>
>>useful and compatible framework. It is not trivial to say "... and
>>we'll just make some OWL-DL ontologies that will work great". Hey, Rich
>>
>>created a bucketload of OWL ontologies, and we are still struggling with
>>
>>how to even visualize these in an effective way, much less navigate and
>>
>>understand them.
>>
>>Finally, I want to clarify this notion of Knowledge Engineer, which I
>>know sends shivers down Shawn's spines cause he envisions himself as the
>>
>>designatee for this role. I think it more likely that it would be
>>folks like me, Deana, or some other "domain" scientist, for if those of
>>
>>us in ecology with reasonable intelligence and lots of interest can't
>>deal with ontology creation, I agree with Shawn that it is not a
>>scalable, nor achievable goal for SEEK's vision. So our big challenge
>>
>>is addressing several and ideally all the above areas, and it is clearly
>>
>>challenging.
>>
>>BTW, I will also add that some of the most fertile brainstorming has
>>been appearing on IRC, so it is highly recommended that folks monitor
>>that channel. And, if as it appears, KR/SMS/BEAM issues are heating up,
>>
>>perhaps we need a dedicated channel for that, just as kepler has its
>>own.
>>
>>Sorry I was late in adding my two cents.
>>
>>Cheers,
>>Mark
>>
>>
>>
>>Deana D. Pennington wrote:
>>
>>
>>>Gee, I thought Mark and you (as KR and SMS leads) were responsible for
>>
>>this :-)
>>
>>>We'll see what the project manager says... My sense of it is that no
>>
>>one
>>
>>>really has a good feel for what, explicitly, is needed. I am hoping
>>
>>that as we
>>
>>>look at actual datasets in Davis, we can start making a list of the
>>
>>things that
>>
>>>are needed, and maybe sketch out some frameworks. Like I said, I can
>>
>>recruit
>>
>>>people to help fill in the details once I know what is needed.
>>>
>>>I don't think there is anything necessarily to "be done about" the
>>
>>concepts I've
>>
>>>worked on. I think Mark and Shawn have seen most things that I've
>>
>>done. They
>>
>>>were all done in cmap; they are too general to be appropriate for
>>
>>linking data
>>
>>>to, except perhaps at a high discovery level. I'll bring everything to
>>
>>Davis,
>>
>>>so we'll have it if it becomes useful in some way.
>>>
>>>Deana
>>>
>>>
>>>
>>>Quoting Bertram Ludaescher <ludaesch at ucdavis.edu>:
>>>
>>>
>>>
>>>
>>>>Deana:
>>>>
>>>>This is a good idea, ie, put some time aside at the Davis meeting to
>>>>do some (initial) ontology creation.
>>>>
>>>>However one thing that confuses me: who is (on the domain side!)
>>>>providing the leadership on what ontologies are being developed!?
>>>>
>>>>Let me ask the project manager ;-)
>>>>
>>>>Matt:
>>>>Who is in charge of determining what community ontologies are needed
>>>>for SEEK? A measurement ontology is a nice case study, but what do
>>
>>the
>>
>>>>scientists need to get more science done?
>>>>
>>>>Deana: I haven't seen what you sent earlier. Can you (re-?)send to
>>>>SEEK-kr-sms and we can see what can be done about it?
>>>>
>>>>cheers
>>>>
>>>>Bertram
>>>>
>>>>
>>>>
>>>>
>>>>Deana D. Pennington writes:
>>>>
>>>>>This sounds simple, but only 2 weeks ago I put together some
>>
>>biomass
>>
>>>>terms in a
>>>>
>>>>>hierarchical way that I thought made sense, and Shawn completely
>>>>
>>>>changed the way
>>>>
>>>>>it was organized (you'll have to get the details from him...it
>>
>>was
>>
>>>>all I could
>>>>
>>>>>do to follow his logic :-) So, the problem is that the simple
>>>>
>>>>examples never
>>>>
>>>>>seem to fit when you sit down to do these things. Perhaps once
>>
>>we
>>
>>>>get a fairly
>>>>
>>>>>good set of basic concepts into the ontology, maybe it'll be this
>>>>
>>>>simple. I'm
>>>>
>>>>>hoping that we will work through some examples in Davis, because
>>
>>no,
>>
>>>>BEAM (that
>>>>
>>>>>would be me) is not constructing ontologies on their (my) own. I
>>>>
>>>>looked at
>>>>
>>>>>Rich's ontologies this summer, and played with some concept maps
>>
>>for
>>
>>>>the
>>>>
>>>>>biodiversity case, but I think we need to be much more explicit
>>
>>about
>>
>>>>what is
>>>>
>>>>>needed. I could (and have) spent a good deal of time coming up
>>
>>with
>>
>>>>things that
>>>>
>>>>>aren't particularly useful. The only meetings that BEAM is now
>>>>
>>>>having are in
>>>>
>>>>>conjunction with other teams (like the KR/SMS/BEAM meeting in
>>
>>Davis),
>>
>>>>so if you
>>>>
>>>>>want ecologists to develop these, you need to work it in the
>>
>>agenda.
>>
>>>>If we get
>>>>
>>>>>to the point where I have a good sense of exactly what ontologies
>>
>>are
>>
>>>>needed,
>>>>
>>>>>then I would be happy to recruit some ecologists for a working
>>>>
>>>>meeting focused
>>>>
>>>>>on ontology generation, as long as there is someone there who can
>>>>
>>>>ensure that
>>>>
>>>>>what we come up with fits the formal requirements.
>>>>>
>>>>>Deana
>>>>>
>>>>>
>>>>>
>>>>>Quoting Bertram Ludaescher <ludaesch at ucdavis.edu>:
>>>>>
>>>>>
>>>>>>Hi Deana et al:
>>>>>>
>>>>>>I guess it's a good time to chime in now, including to throw in
>>>>
>>>>some
>>>>
>>>>>>thoughts from a KE and SEEK SMS (and KR) point of view =B-)
>>>>>>
>>>>>>First, the intuitive ontology tool that Deana asked about is
>>>>
>>>>already
>>>>
>>>>>>there (although Shawn and I haven't done a particular good job
>>
>>of
>>
>>>>>>making it available yet). It's the goose feather, oops, I meant
>>>>
>>>>the
>>>>
>>>>>>Sparrow language ;-)
>>>>>>
>>>>>>Here is what we had in mind: in our context, creating
>>>>
>>>>domain-specific
>>>>
>>>>>>ontologies is primarily about defining controlled vocabularies.
>>>>
>>>>We
>>>>
>>>>>>might use fancy GUIs for it, or just the keyboard to type in
>>
>>the
>>
>>>>>>controlled vocabulary terms:
>>>>>> measurement.
>>>>>> species_abundance.
>>>>>> biodiversity_index.
>>>>>> biomass_measurement.
>>>>>>
>>>>>>ok, you can see how a keyboard is useful for entering
>>
>>controlled
>>
>>>>>>vocabulary terms (unlike, e.g., a mouse). From this to a
>>
>>"formal"
>>
>>>>>>ontology (at least in the sense used earlier in this thread) it
>>
>>is
>>
>>>>a
>>>>
>>>>>>small step. E.g., you might want to say that
>>>>>>
>>>>>> "biomass measurements are measurements"
>>>>>>
>>>>>>Then we should be able to say just that. In fact that's almost
>>>>
>>>>valid
>>>>
>>>>>>Sparrow syntax; exactly we would write (note the small
>>>>
>>>>differences):
>>>>
>>>>>> biomass_measurement ISA measurement.
>>>>>>
>>>>>>This is human readable, easy to enter, edit, exchange and parse
>>>>
>>>>as
>>>>
>>>>>>well. Oh, and it can be translated easily into OWL so that
>>
>>other
>>
>>>>tools
>>>>
>>>>>>can work with it.
>>>>>>
>>>>>>A slightly more complex example is:
>>>>>>
>>>>>> "biomass measurements are measurements that only measure
>>>>
>>>>biomass"
>>>>
>>>>>>In Sparrow (goose feather ;-) syntax we would have to slightly
>>>>
>>>>tweak
>>>>
>>>>>>this into the following form:
>>>>>>
>>>>>> biomass_measurement ISA measurement AND item_measured ONLY
>>>>
>>>>biomass.
>>>>
>>>>>>So what Shawn meant earlier about "formal ontologies" is this
>>
>>level
>>
>>>>of
>>>>
>>>>>>refinement/sophistication that we are after. The good thing
>>
>>about
>>
>>>>the
>>>>
>>>>>>notation above (as opposed to just nodes and arrow diagrams) is
>>>>
>>>>that
>>>>
>>>>>>these statements can be translated into OWL (or directly
>>>>
>>>>first-order
>>>>
>>>>>>logic) and provide some constraints about how a biomass
>>>>
>>>>measurement
>>>>
>>>>>>relates to measurements in general, what is being measured etc.
>>>>>>
>>>>>>We also need to keep in mind, as was mentioned earlier, that
>>>>
>>>>ontology
>>>>
>>>>>>creation is not what the typical end user of Kepler should be
>>>>
>>>>doing.
>>>>
>>>>>>Ontologies are meant to be created by the *scientific
>>
>>community*
>>
>>>>(in
>>>>
>>>>>>this case ecologists) using specialized tools and this process
>>
>>is
>>
>>>>>>often done in concert with the (in)famous KE / KR/CS types
>>>>>>who can provide additional tools to check the consistency of so
>>>>>>defined
>>>>>>ontologies, visualize the inferred class hierarchy etc.
>>>>>>
>>>>>>But the (passed around) buck does stop there: at the
>>
>>willingness
>>
>>>>of
>>>>
>>>>>>the community to actually come up with controlled vocabularies
>>>>
>>>>and
>>>>
>>>>>>simple, but somewhat formal (in the above sense) ontologies.
>>>>>>So I think we do need to create more of those ontologies. Isn't
>>>>
>>>>BEAM
>>>>
>>>>>>doing that? Or who else? Someone should.. we can certainly
>>
>>help.
>>
>>>>>>Let's also see how Kepler and ontologies and all that good
>>
>>stuff
>>
>>>>>>relates (some of this was suggested before, eg. by Laura):
>>>>>>
>>>>>>- Kepler is NOT the primary tool to develop, change, update
>>>>>>ontologies. For that there is GrOWL, Protege, and yes Sparrow
>>>>
>>>>(it's
>>>>
>>>>>>built into any OS.. we just need to send you again the simple
>>>>
>>>>grammar)
>>>>
>>>>>>- Kepler should have mechanisms to *annotate* actors (as a
>>>>
>>>>whole),
>>>>
>>>>>>their ports, and datasets. This should normally NOT require
>>
>>changes
>>
>>>>to
>>>>
>>>>>>the ontology. Rather one would simply *select* concept names
>>
>>from
>>
>>>>one
>>>>
>>>>>>of possibly several pre-defined community ontologies (importing
>>>>>>different ontologies into Kepler should be easy)
>>>>>>
>>>>>>- For expert users only: If you feel that you need to define a
>>>>
>>>>new
>>>>
>>>>>>concept on top of an existing ontology, you should be able to
>>
>>do
>>
>>>>that
>>>>
>>>>>>as well from Kepler. Clearly, you are not updating the
>>
>>community
>>
>>>>>>ontology (there is a "protocol" for the latter, one needs
>>>>
>>>>endorsement
>>>>
>>>>>>from a consortium such as "Eco-GO" ;-) but rather you are
>>
>>adding
>>
>>>>to
>>>>
>>>>>>your "private ontology extensions" much like you would add new
>>>>
>>>>words
>>>>
>>>>>>to your private dictionary in Word ("Add foobar to your private
>>>>>>ontology (y/n)?"). My earlier suggestion would be to be able to
>>>>
>>>>define
>>>>
>>>>>>a new concept in this way, e.g.
>>>>>>
>>>>>>my_measurement ISA biomass_measurement AND hasLocation davis.
>>>>>>
>>>>>>Then my_measurement and davis might be new concepts which are
>>
>>added
>>
>>>>to
>>>>
>>>>>>my personal ontology (along with the Sparrow statement/axiom
>>>>
>>>>above),
>>>>
>>>>>>whereas the other terms come from the existing ontology.
>>>>>>
>>>>>>
>>>>>>OK, so much for now.
>>>>>>
>>>>>>cheers and laters
>>>>>>
>>>>>>Bertram
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>Deana D. Pennington writes:
>>>>>> >
>>>>>> > 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>**************************
>>>>>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)
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>**************************
>>>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
>>>
>>>
>>
>>
>>--
>>Mark P. Schildhauer, Ph.D. -- Director of Computing
>>NCEAS -- National Center for Ecological Analysis and Synthesis
>>735 State St., Suite 300 Santa Barbara, CA 93101-3351
>>Email: schild at nceas.ucsb.edu WEB: http://www.nceas.ucsb.edu
>>Phone: 805-892-2509 FAX: 805-892-2510
>>
>>
>>
>
>
>
>
> **************************
> 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
--
-------------------------------------------------------------------
Matt Jones jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/ Fax: 425-920-2439 Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
University of California Santa Barbara
Interested in ecological informatics? http://www.ecoinformatics.org
-------------------------------------------------------------------
More information about the Seek-kr-sms
mailing list