[Fwd: Re: [seek-kr-sms] ontology/folder UI design in Kepler]
Deana D. Pennington
dpennington at lternet.edu
Tue Mar 1 15:33:41 PST 2005
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)
More information about the Seek-kr-sms
mailing list