[seek-kr-sms] KR Ontology Needs

[Shawn Bowers]

Deana Pennington wrote:

> I think that this meeting should focus on the data integration issues, 
> and then I'll schedule a BEAM meeting in Feb/Mar to get all of the 
> domain scientists together to develop workflows that will use the 
> integrated data.  I'll be working with Mark on an agenda this week, so 
> anyone who has specific tasks they would like to see happen can let me 
> know.  Maybe a breakout session where we develop keyword lists, or where 
> we explicitly discuss actor functional ontologies... whatever you want 
> to do.  We can remain flexible and modify the agenda on the fly, but 
> people are already asking for an agenda, so I need to get it organized 
> as much as possible.

When you say "data integration issues," what types of issues are you 
thinking about?   For example, is there a set of questions you have in 
mind to ask the scientists at the meeting?  (and if so, can you send 
them?) It sounds like you're thinking we will find out what data sets 
they need, and do the integration for them so that the data is ready for 
the meeting in Feb/Mar.

It is really great that you have gotten this buy-in -- very exciting!

I would be happy to work on an agenda with you and Mark if you wish ...

In general, at some point we'd like to do "knowledge acquisition", and 
at this point it isn't clear the best way to do that with scientists. Do 
we show the ontologies, give a demo of protege and/or GrOWL, and then 
let them have at it? Or, is there some other methodology that might be 
more effective?


Shawn


> 
> Deana
> 
> 
> Shawn Bowers wrote:
> 
>>
>> Hi all,
>>
>> Below is an IRC conversation Chad, Matt, and I had before I left for 
>> Toronto and Chad left on vacation (this discussion took place on 
>> Friday, Aug. 27th).
>>
>> Here are the main points of the conversation.
>>
>> First, for some background, we are currently trying to do some very 
>> simple, ontology-based searching for actors and (possibly) datasets 
>> for Kepler for the Oct. 15 release.  Much of the discussion below 
>> concerns some basic architectural and interface issues concerning this 
>> work. Since Chad and I discussed this, we've made some progress, and 
>> the basic concept-based searching is done -- now I am integrating the 
>> work with Chad's Kepler api (which really is not that much work).
>>
>> The approach we are starting with is to represent an actor annotation 
>> as an individual (object) that instantiates one or more concepts from 
>> an ontology (the annotation can be more general than that, but here 
>> they are fairly simple).  We have an index structure that maps an 
>> actor to it's corresponding annotation. The search uses the index to 
>> return matching actors. So, we are doing some very basic stuff here.
>>
>> However, some important issues have come up concerning ontologies for 
>> this approach. These issues are: (1) ontologies for actor 
>> classification, (2) the need for an extensive ontology, (3) keywords 
>> versus ontologies, and (4) a repository of useful keyword lists. Here 
>> is the discussion surrounding these issues.
>>
>>
>>
>> 1. This issue is mainly directed at Rich (because he is the poor soul 
>> who has had to do all the ontology development up to this point). What 
>> is the status of the ontologies for describing actors... what 
>> "functional" concepts currently exist? And, how should we develop and 
>> define these types of classifications for actors? Should we take some 
>> time and brainstorm / develop a functional class infrastructure?
>>
>>
>>
>> 2. For experimenting and demonstrating these new additions to Kepler, 
>> we need a detailed test case. The test case needs to include both 
>> actors and data, as well as a complex enough ontology to demonstrate 
>> the approach(es).  On IRC, we thought the biodiversity domain would 
>> make a good starting place, since we are about to begin meeting with 
>> experts in biodiversity, making it a good opportunity to be able to 
>> interact and engage domain scientists to help us develop an extensive 
>> ontology. Matt in particular expressed this as a "new charge" for the 
>> KR group.
>>
>> Currently, the examples I am using to test out the search interface 
>> are "brain dead."  I think for all of our work, having a detailed 
>> study area "filled out" would be benefitial (i.e., for GrOWL, for SMS, 
>> even for Taxon, etc.)
>>
>> The next two points are my own views (discussed in the IRC chat) 
>> concerning some issues we should address as we move forward.
>>
>>
>>
>> 3. The way the search interface currently is designed/implemented in 
>> Kepler is purely keyword-based.  (We've thought about slightly more 
>> complex interfaces, and at the other extreme would be an interface 
>> that allowed one to issue complex queries for actors.)
>>
>> So, our current goal is to let someone enter a classname as a keyword 
>> into the existing search interface, identify it as a classname, and 
>> exploit the annotations and the class definition in the ontology to do 
>> more advanced searching in addition to the keyword-matching on the 
>> titles of actors.
>>
>> However, the classes in an ontology are not quite the same as the 
>> keywords someone (e.g., a scientist) might want to search with.  
>> Classes are typically very high-level and generic, whereas keywords 
>> are typically more specific.  I think that often, some of the 
>> classnames might usefully serve as keywords, while many others would 
>> not. So, one question is whether we should view classnames as 
>> keywords, or somehow distinguish those classnames that make useful 
>> keywords, and those that do not, or entirely separate the notion of 
>> keywords from classnames.
>>
>> There are also a large number of keywords that probably wouldn't be 
>> found in an ontology, but are still useful for searching.  There are 
>> various reasons why a keyword might not be used as a classname: the 
>> corresponding class is already in the ontology, but with a different 
>> name; the keyword is a term for what would be an individual; the 
>> concept denoted by a keyword is represented by mutliple concepts; the 
>> keyword is non-standard in the domain, and so on.
>>
>> So, the question is how to distinguish and manage keywords with 
>> respect to ontologies.  One idea Rich and I played with a while back 
>> was to separate a keyword database from an ontology database. And, 
>> allow keywords to be defined in terms of the ontology (or possibly in 
>> terms of other keywords).  The goal would be to allow for easy 
>> creation and addition of keyword lists, without "muddying up" the 
>> ontologies. Various operations could also be automatically provided 
>> based on the keyword definitions (e.g., synonymy and 
>> broader-term/narrower-term).
>>
>> I think this is an interesting approach that needs more experimenting 
>> with. What do others think? Is anyone interested in looking at this in 
>> more detail -- possibly brainstorming tools and such?
>>
>> In general, I think we need to think about, and layout a plan on how 
>> we intend to present ontologies to scientists (not just in GrOWL, but 
>> what our larger strategies / user interaction models are) and what 
>> tools / interfaces we offer scientists to add to, edit, and interact 
>> with ontologies.  The keyword discussion above is an example of one 
>> type of stance: letting scientists work with keywords in a simple way, 
>> while still taking advantage of the power of the ontologies (through 
>> the keyword to ontology connections).  I think it would be very useful 
>> to, as a group, discuss how we would like to proceed and try to come 
>> up with a plan for how we intend to engage scientists from the KR-side.
>>
>>
>>
>> 4. A repository of keywords. I think it could be useful to begin 
>> looking for existing keyword lists and controlled vocabularies useful 
>> in ecology.  Here is one: http://eco.wiz.uni-kassel.de/ecobas.html 
>> (click on "Models" then search in database ECOBAS "by subject", and 
>> the list appears on the right-hand frame; there is also a list for 
>> "search a model: by subject").
>>
>> Does anyone know of any useful or additional lists?
>>
>> Does it makes sense to construct a repository of these lists? Maybe 
>> from the Wiki?
>>
>>
>> Shawn
>>
>>
>>
>>
>> Matt Jones wrote:
>>
>>> Take 2...
>>>
>>> Shawn
>>>
>>> Here's the log of our conversation, with some of the more boring side
>>> conversations excised for brevity.  It'll be interesting to see how you
>>> paraphrase it :)
>>>
>>> Matt
>>>
>>>
>>> ------------------------------------------------------------------------
>>
>>
>>
>> <shawn> chad, i am here now
>> <chad> hey shawn
>> <shawn> hiya
>> <chad> i just wanted to chat with you before I leave on vacation
>> <chad> I'm taking off today for 10 days
>> <shawn> oh ok
>> <chad> All of the interfaces are setup in kepler now for the ontology 
>> integration
>> <shawn> i am leaving tomorrow and get back on the following saturday too
>> <shawn> to a conference
>> <chad> ahh ok
>> <shawn> what do you mean by interfaces ... gui stuff
>> <chad> i was just going to tell you about it in case you wanted to try 
>> something while i was gone, but if you're leaving too, i'll wait until 
>> you get back
>> <chad> java interfaces
>> <chad> programmatic
>> <chad> not GUI
>> <shawn> i can look at it when I am gone ...
>> [MBJ EXCISED A SIDE CONVERSATION FROM HERE]
>> <berkleyXP> ok, so the file that's up in jedit is the configuration 
>> file for kepler
>> <shawn> Yes, and it looks like SimpleLibrarySearcher.java is highlighted
>> <berkleyXP> the part i just highlighted is what we can change for the 
>> ontology stuff
>> <shawn> i see
>> <berkleyXP> right now, it's using the ResultTreeRebuilder as the 
>> search result pane
>> <berkleyXP> and the SimpleLibrarySearcher for the search engine
>> <berkleyXP> we probably just want to replace SimpleLibrarySearcher 
>> with OntologySearcher
>> <shawn> ok, the ResultsLister
>> <shawn> ok
>> <berkleyXP> The result part just controls how the results are displayed
>> <berkleyXP> so if we want to have a fancy result view of some sort, we 
>> can change that one too
>> <shawn> ok, so OntologySearcher would subclass SimpleLibrarySearcher
>> <berkleyXP> i just brought up SimpleLibrarySearcher
>> <shawn> yep
>> <berkleyXP> it extends LibrarySearcher which is what we would want to 
>> extend with OntologySearcher
>> <shawn> ok. OntologySearcher extends LibrarySearcher
>> <berkleyXP> The LibrarySearcher interface takes in the library (a 
>> JTree) and produces a LibrarySearchResults object
>> <berkleyXP> the LibrarySearchResults object is just an extended vector 
>> that only holds TreePaths
>> <berkleyXP> so basically, the search engine just returns a vector of 
>> TreePaths that match the search results
>> <shawn> let me look at it real quick
>> <berkleyXP> sure
>> <chad> those are just the private methods
>> <chad> the only ones you really need to worry about are the 
>> constructor, init and search
>> <shawn> yeah, i was just looking
>> <chad> the factory subclass is what ptolemy uses for it's pluggable 
>> interface
>> <chad> if you noticed in the configuration.xml file, the classname was 
>> SimpleLibrarySearcher$Factory
>> <shawn> yes, saw that
>> <shawn> that is the inner class in SimpleLibSearcher
>> <chad> yeah
>> <chad> any class that's plugable will have a factory
>> <shawn> I see
>> <chad> so there are two different results handlers you can compare:
>> <chad> ResultTreeRebuilder and ResultHighlighter
>> <shawn> so basically, it takes the library, which is actually the gui 
>> component and returns LibrarySearchResults
>> <shawn> which is a vector of JTree
>> <chad> vector of TreePaths
>> <shawn> oh, tree paths, got it
>> <chad> the library is a gui component, but the model behind that 
>> component contains the whole model
>> <chad> so that's why i passed it
>> <chad> I guess I could have just passed the model instead...probably 
>> more clean that way
>> <chad> have you thought more about how we are going to asign ids to 
>> each component in the library?
>> <shawn> ah, no ...
>> <shawn> actually, if we passed the model, perhaps we could get away 
>> with assigning the semantic types there for now?
>> <chad> hmm
>> <shawn> like in edwards email ... or, we could use the JTree and have 
>> a lookup table...
>> <chad> not sure about that
>> <shawn> so, the library JTree now, does it have names of actors that 
>> are redundant?
>> <chad> the jtree doesn't, but the model does
>> <chad> the jtree is just the visual representation of the model
>> <shawn> yes ... where the leafs of the tree are presumably the actual 
>> names of actors
>> <shawn> yeah?
>> <chad> well, it's a bit more complicated than that
>> <chad> have you looked at the Entity heirarchy in ptolemy?
>> <shawn> not really
>> <chad> 
>> http://ptolemy.eecs.berkeley.edu/ptolemyII/ptIIlatest/ptII/doc/codeDoc/index.html 
>>
>> <shawn> but, when I look at ptolemy's left-panel browser, i really 
>> only see actors don't i?
>> <chad> when you get a chance, browse that a bit
>> <chad> no, you're seeing CompositeEntitys and AtomicActors
>> <chad> Actually, EntityLibrarys and AtomicActors (which are 
>> ComponentEntities)
>> <shawn> yeah, i guess i think of a composite as another actor
>> <chad> check out the heirarchy for EntityLibrary down through NamedObj 
>> in the ptolemy API docs
>> <chad> bacically, the model is built out of those components
>> <chad> The leaves are AtomicActors
>> <chad> or CompositeACtors actually
>> <shawn> so, those have unique names though, at least it seems like 
>> they do
>> <chad> yeah, the do
>> <chad> only because of their paths though
>> <chad> you can clone entities and put them in multiple places in the tree
>> <shawn> so, i was thinking just as a first cut, to have a file that 
>> basically assigns their unique names to a list of concepts
>> <shawn> just assume that the names are unique for now, then address 
>> the issue of ids later
>> [MBJ EXCISED A SIDE CONVERSATION FROM HERE]
>> <chad> ok.  so how do you want to approach tagging these things?
>> <shawn> we could have a simple file
>> <shawn> that basically has a name of a leaf item in the JTree library
>> <shawn> and associates it with an expression
>> <shawn> the expression could just be a list of concepts for now
>> <shawn> although, at some point it would need to be more complex
>> <chad> the problem is that what you see in the tree are instances of 
>> classes, not just unique classes, so there could be more than one of 
>> the same class....the path is what is unique.
>> <shawn> that's fine, we store the path
>> <chad> ok
>> <shawn> ultimately, this needs to be more robust, using some ids
>> <chad> we have a lookup table then, what's the table look like?  
>> concept | path.to.leaf.node
>> <shawn> but that is a more general issue that we probably don't need 
>> to address to get things going
>> <shawn> path.to.leaf.node -> <expression>
>> <shawn> where <expression> for now is Vector of concept-name
>> <chad> so there could be more than one concept?
>> <chad> per path
>> <shawn> sure that is a driving motivation
>> <shawn> otherwise, just store everything in a tree
>> <chad> right
>> <shawn> a fixed tree
>> <shawn> actually, the more interesting things are when there isn't a 
>> single concept
>> <chad> but in a table like that, i think the right way to do it is to 
>> have unique tuples
>> <shawn> what do you mean?
>> <chad> instead of a path linked to a vector
>> <chad> so like path1 | concept1, path1 | concept2
>> <shawn> sure, that is fine
>> <shawn> or, you could just have an xml file:
>> <shawn> <index>
>> <shawn>   <entry>
>> <shawn>    <actor>
>> <shawn>    ... path representation ...
>> <shawn>     </actor>
>> <shawn>     <annotation>
>> <shawn>       <concept name=""/>
>> <shawn>       <concept name=""/>
>> <shawn>     </annotation>
>> <shawn> etc
>> <chad> ok.  that works
>> <shawn> so, we get a "search" (not sure what the search is right now)
>> <shawn> and we use the xml file and the jtree library to calculate the 
>> search result
>> <shawn> plus the ontology
>> <shawn> a quick and dirty implementation
>> <shawn> so, what *is* the search?
>> <chad> what do you mean?  how is it structured?
>> <shawn> one thing we could start with is just to let someone enter a 
>> single concept in the current search box
>> <shawn> what we talked about in the phone conf. a while back was a very
>> <shawn> complex kind of search
>> <shawn> where a user forms a tree of some kind from the ontology
>> <shawn> and the result is the tree populated with the appropriate 
>> actors (those that "match" the index)
>> <shawn> So OntologySearch in this case takes as a input to Search() 
>> another
>> <shawn> tree, where the nodes are concepts from an ontology
>> <shawn> yeah?
>> <chad> ok
>> <chad> we could just have no real "search" but instead just rearrange 
>> the tree by concepts dynamically
>> <shawn> yes
>> <shawn> i guess that was what we talked about in the phone conf...
>> <shawn> you are right, there really isn't a "search" per se, we just 
>> use the index
>> <chad> yeah...the search could just be a keyword search of the 
>> rearranged tree or something
>> <shawn> one thing that might be cool too, is this
>> <chad> or, you could have a drop down of all the concepts (or a 
>> multiple select list box) wher eyou just choose the concepts you want
>> <shawn> yeah ... here is what we might consider
>> <shawn> keep the interface as it is
>> <shawn> maybe, like you said, have a drop-down or something for the 
>> search box
>> <shawn> or in some other way,
>> <shawn> but when someone enters a search term in the search box,
>> <shawn> try to resolve that to the ontology
>> <shawn> so that if the word matches a term in the ontology, then use 
>> that term and the index to also return results
>> <shawn> does that make sense?
>> <chad> yeah
>> <shawn> its one way to get it going fast, with little change to the 
>> interface
>> <shawn> and we could easily mock up something that shows the "power" 
>> of using the ontology
>> <chad> yeah, it would be nice to have at least a partial concept mapping
>> <chad> just to play with
>> <matt> i think that's a good start
>> <chad> We should just go through the tree and try to map say 100 
>> actors to concepts
>> <matt> showing some ontology-based searching would be awesome
>> <matt> even if the query is only a single term from the ontology
>> <chad> so, shawn, can sparrow do the ontology searching for us or are 
>> we going to have to write a search engine for this?
>> <shawn> yeah, it is about the simplest thing we could do ...
>> <shawn> well, we probably can use either sparrow (where the interfaces 
>> are really done) or something like owlapi, which is a really 
>> lightweight owl api
>> <shawn> and the complexity of the search depends on the complexity of 
>> the ontology
>> <shawn> for simple stuff, owlapi would be fine
>> <shawn> and it is all in java
>> <chad> cool
>> <shawn> I can get that part going
>> <chad> ok
>> <chad> if you could write a wrapper for that that fits in with the 
>> LibrarySearcher interface, that woudl be sweet
>> <shawn> yes, that shouldn't be hard
>> <shawn> but, we also need at least a somewhat "interesting" ontology
>> <chad> if we have to alter the interface a bit, that's not too much of 
>> a big deal...i just passed in what i thought was a flexible set of params
>> --- wernerMeeting is now known as wernerkrebs
>> <chad> define interresting
>> <shawn> i wonder if there should be a button or something on the 
>> interface to let us turn on/off ontology based keyword search
>> <shawn> checkbox, not button
>> <chad> that's possible
>> <chad> i should make that search panel into a flexible interface as well
>> <chad> right now it's kinda static
>> <chad> it just comes from the tabbedlibrarypane class
>> <chad> which is dynamic, but it's stupid to have to swap that whole 
>> class to change just the search interface
>>
>> ... The Ontology/Keyword Discussion starts here ....
>>
>> <matt> interesting means useful to a scientists
>> <matt> ie, they'll never type in the upper level classes from Rich's 
>> ontologies
>> <shawn> that is what i meant by an interesting ontology ... the 
>> ontology itself can be simple
>> <matt> but they might type in 'Estuarine" which can be linked to 
>> rich's via the habitat section
>> <matt> words that come from the science domain will be interesting to 
>> the scientists
>> <matt> density
>> <matt> abundance
>> <matt> Marine environment
>> <shawn> so, where can we find a list of terms to use?
>> <matt> zooplankton count
>> <matt> :)
>> <shawn> i like that one
>> <matt> any dataset on the KNB
>> <matt> just read the metadata
>> <shawn> how about a single place
>> <matt> nope
>> <matt> doesn't exist
>> <shawn> really? are you sure?
>> <matt> you could look at the top level terms on the knb site
>> <wernerkrebs> ilkay? do you still want to meet now?
>> <matt> for a really coarse set of terms
>> <chad> we could harvest all the keywords from the eml in the knb
>> <matt> yeah -- i've doen that
>> <matt> they are pretty ....messy
>> <shawn> since we are talking about actors, and not data, we need more 
>> functional terms, right?
>> <matt> yep
>> <matt> but we really want this mechanism to work for both
>> <shawn> what would those be? where would those be?
>> <matt> in some ways I think its easier to prototype for data
>> <matt> more concrete
>> <shawn> yeah, and data is also a lot more complex
>> <matt> take a look at this page
>> <matt> http://knb.ecoinformatics.org/
>> <matt> there's a list in the search box
>> <matt> unfortunately, nobody uses those exact terms in their metadata 
>> -- they use closely related terms
>> <shawn> for actors though, i think this is interesting
>> <matt> plurals, different spellings, synonyms, etc
>> <shawn> what terms do people use to describe components? what would 
>> someone actually want to search for?
>> <matt> that's an interesting question
>> <shawn> *is* this being done for scientists or for people like Dan?
>> <shawn> and the other keplerites?
>> <matt> most actors perform basic math operations that are not 
>> particularly domain centric
>> <chad> i wouldn't say most there
>> <matt> i wasn't finished
>> <matt> most actors perform basic math operations that are not 
>> particularly domain centric
>> <chad> :) sorry
>> <matt> but....
>> <matt> scientists put a domain flavor layer on top
>> <matt> garp is a good example
>> <shawn> yes, i was just going to say that
>> <matt> ecologists think of garp as a species prediction algorithm
>> <shawn> like "statisticalregression"
>> <matt> but its not
>> <matt> yep
>> <matt> its really just a GA
>> <matt> and garp has some preprocessing code to apply it to spatially 
>> explicit occurence data
>> --- chad is now known as chadBRB
>> <matt> making it a species predictor
>> <matt> but in terms of classification, if you remove the pre and post 
>> processing, its purely math
>> <matt> but that's not what the ecologist will look for
>> <matt> they'll want: what things can do species predictions....
>> <matt> GAs, Neural nets, etc
>> <shawn> have you seen this site: eco.wiz.uni-kassel.de/ecobas.html
>> <matt> so i think classifying the actors is gonna be harder than 
>> classifying the data
>> <matt> yeah
>> <matt> its been around for several years
>> <shawn> they have a subject list, might we take that?
>> <matt> it looks like it has improved a bunch since I last looked
>> <matt> certainly would be a reasonable place to start
>> <matt> their keyword list in interesting too
>> --- wernerkrebs is now known as wernerLunch
>> <shawn> yes, i was looking at that ... maybe take some terms from there?
>> <matt> like look at this set of terms:
>> <matt> advection
>> <matt> advection-dispersion equation
>> <matt> advective and diffusive fluxes
>> <matt> advective contaminant transport
>> <matt> advective-diffusive reactors
>> <matt> advective-transport
>> <matt> we wouldn't want to use those raw, but an ontology that 
>> decomposed the concepts woiuld be great
>> <shawn> yes ... reminds me of a discussion rich and i had a while 
>> back, that i think is really interesting
>> <shawn> basically, you take a list like this, and the ontology, and 
>> you say "advection-dispersion equation" (the term) maps to the 
>> ontology like this (and give how it is realized in the ontology)
>> <matt> that would be neat
>> <matt> this is really the work of the KR group -- to create a beast 
>> like this
>> <shawn> so, you have keywords, you have the ontology, and they are 
>> "decoupled" so that to a scientist its just a bunch of keywords, but 
>> behind the scenes it is actually very well defined
>> <matt> yes, that would be great
>> <shawn> from those defs you can do things like construct hierarchies, 
>> synonyms, and so on
>> <matt> on the data side I think the set of concepts to get going is 
>> potentially much smaller
>> <matt> which is why I have recommended starting there
>> <shawn> i think it is something people haven't looked at very much in 
>> the semweb/kr community
>> <matt> i think a term like 'advective contaminant transport' is going 
>> to take a lot to tie it firmly and correctly into the ontology
>> <shawn> probably ...
>> <shawn> it is something that would need to be done incrementally
>> <matt> at a minimum, your ontology has to deal with movement/flow and 
>> the idea of conamination
>> <matt> of course
>> <matt> compare that to columns of data, which tend to be far more 
>> concrete and unidimensional, and I think you can see why I think 
>> annotating the data is easier
>> <matt> although, the measurement context might be just as complicated 
>> there i suppose
>> <shawn> i think once you move away from saying "this dataset is about 
>> x" where x is a keyword, it gets very complicated pretty fast, 
>> especially because there are so many different types of data sets and 
>> so many different representations for the same sets of information
>> <matt> can one of you (shawn) send an email to kr-sms saying we need 
>> this ontology?
>> <shawn> which ontology?
>> <shawn> the keyword list?
>> <matt> *this* ontology :)
>> <matt> i don't know -- we need one to use as a starting point for the 
>> search engine
>> <matt> and it needs to be more domain specific than the meas ontology 
>> rich has created
>> <shawn> oh yeah... what about ferdinando's ontology
>> <matt> i think mark and rich should really be involved in creating 
>> this thing
>> <matt> ferdinando's might work
>> <shawn> as a start anyway
>> <matt> sure --
>> <matt> its about ecosystem services and economics
>> <matt> so....
>> <matt> a little fringe for our case studies
>> --- chadBRB is now known as chad
>> <matt> but probably overlaps significantly in some areas
>> <shawn> i think we just need something to "show off" what we are 
>> trying to do, not a comprehensive thing
>> <matt> yeah
>> <matt> for starters
>> <matt> eventually we need a process for scientists to extend the 
>> ontologies
>> <matt> and edit and correct them
>> <matt> but for now we can work with demonstration cases
>> <shawn> that is actually where I thought the keyword idea would come in
>> <matt> as long as they are realistic
>> <shawn> and rich has some experience with this in the foodweb stuff
>> <matt> I like the keyword idea, but it seems like a tough order given 
>> the variety of keywords in that list
>> <matt> there are other keyword lists we could start from too
>> <shawn> yeah, but it is a useful model to consider: you are a 
>> scientist and you have a keyword that you want to incorporate and so 
>> you simply define it using the ontology
>> <matt> but they would probably be equally complex
>> <matt> sure...if the ontology has the base concepts you need to define it
>> <shawn> if you can't, then the ontology could be extended
>> <matt> yeah
>> <shawn> to me it seems like a nice "user model" of how this stuff 
>> might work
>> <matt> imagine the subtlety involved in defining these two keywords 
>> from the list:
>> <matt> agricultural system
>> <matt> agriculture
>> <matt> part of the problem is that the keyword is vague -- different 
>> people could formalize it differently and both be right
>> <shawn> yes, that is the beauty of words
>> <matt> they are amazing vehicles
>> <shawn> i don't see anything wrong with have a keyword have multiple 
>> meanings
>> <matt> with a minimal amoutn of work I could get a report of all of 
>> the keywords from the KNB data set that have been used
>> <matt> me either
>> <shawn> and, if you have the definitions (i.e., keywords linked to the 
>> ontos), then an interface can say: did you mean this version or that 
>> version?
>> <matt> i'm just saying starting with a complex keyword list as input 
>> is a tall order
>> <shawn> of course ... unreasonable, i agree
>> --- ilkayGone is now known as ilkay
>> <matt> it might be easier to say:
>> <shawn> it is just something to keep in mind as we try to get 
>> scientists into using "ontologies"
>> <matt> for our biodiversity case study, what concepts are inherent in 
>> the data and models and scietists vocabulary
>> <matt> define that set, and see how far it gets you for discovery
>> <matt> but only for that one subdomain
>> <shawn> makes sense, definately
>> <matt> (although biodiversity is a large subdomain)
>> <shawn> yes, but by scientists, we mean particular scientists, that 
>> don't necessarily focus in the entire subdomain
>> <shawn> most likely
>> <matt> right
>> <matt> but even start with the term 'biodiversity'
>> <matt> formalizing it will require a notion of  'species', 'taxa', and 
>> 'diversity' at a minimum
>> <matt> none of these are simple concepts to get right
>> <matt> i think we might want to set a new charge to the KR group to 
>> engage a group of domain scietists and start producing some extensive 
>> ontologies in our case study areas
>> <matt> if they were to do so, and tie them to Rich's measurement ontology
>> <matt> we'd have something to work from
>> <shawn> sounds good to me ... i have been hoping for this
>> <shawn> it was also a motivation for starting working on the 'manual' 
>> for the ontology
>> <matt> so that's basically the email that needs to be sent
>> <shawn> so that we could easily present and talk about the stuff, and 
>> have what he has done be looked over by at least rich and myself
>> <shawn> but, i haven't had the time lately to work on it
>> <shawn> :(
>> <matt> yeah
>> <matt> i was folliong along as you worked on it
>> <matt> it helped my understanding of the subtelties of Rich's ontology 
>> a bunch
>> <shawn> me too :)
>> <matt> i think you're right that it needs to be continued
>> <shawn> it was a lot of fun too
>> <matt> a workshop with one (and only one) purpose of developing an 
>> extensive ontology for a subject area would be effective, especially 
>> if it tied into Rich;'s top level
>> <matt> because it would help to validate the top level too
>> <shawn> yes definately
>> <shawn> people generally get enjoy talking about this kind of stuff 
>> too, since it is what they do
>> <matt> yep
>> <chad> talking or arguing :)
>> <matt> ok, so when?  this fall is pretty booked up
>> <shawn> arguing is more accurate
>> <shawn> how about this fall then?
>> <matt> :)
>> <shawn> overbooking seems to work for the airline companies
>> <shawn> we can join in, and give the power to the people, and have us 
>> overbook meetings like flights :)
>> <matt> i would like to partake in this....but I can't make it till 
>> after the holidays
>> <matt> whats the agenda for the fall KR meeting at SDSC?
>> <shawn> haven't seen an agenda, but actually, we were hoping to get 
>> into some of this
>> <matt> yeah, i'll be bummin if I can't participate in that
>> <shawn> it will be a mix of topics like it was in ABQ with ricardo and 
>> everyone
>> <matt> that will be tougher
>> <shawn> but i guess with biodiversity people
>> <shawn> we'll be talking about kepler and use cases and such
>> <shawn> trying to get a feel for what they are doing
>> <matt> all over the board then
>> <shawn> i should say, educating ourselves with their problems, but 
>> yes, it will be broad
>> <shawn> and therefore, we won't get much time to delve that deeply 
>> into anything
>> <matt> yeah
>> <matt> there's a place for that too
>> <matt> but....
>> <shawn> but, it wold make sense to bring these people back in 
>> jan./feb. to get into the onto stuff, i think
>> <matt> focusing on a product at workshops leaves lasting artifacts 
>> that advance our work
>> <matt> maybe that's a good plan
>> <matt> use the Oct WS to frame the issues
>> --> ilkayLaptop (ilkay at client64-249.sdsc.edu) has joined #kepler
>> <shawn> of course, who knows where i'll be then
>> <matt> develop a straw man ontology as fodder in between
>> <matt> then run it through the ringer in jan/feb
>> <shawn> yes
>> <matt> we need a single person who will taje responsibility for 
>> shepherding such a process to completion
>> <shawn> i think that is a good idea
>> <matt> Rich comes to mind to me
>> <shawn> yes, it should be rich
>> <matt> ok. agreed.  and seeing as he's not on IRC, he can't complain
>> <matt> :0
>> <shawn> that's right, its only fair to assign the missing person the 
>> hard tasks
>> <shawn> everyone knows this
>> <matt> maybe the best thing is to just mail out this IRC conversation 
>> to kr-sms and tell people they should read it to see what they were 
>> volunteered for :)
>> <shawn> :-)
>> <matt> at least it would bring mark and rich up to speed when they return
>> <shawn> you are assuming people would read all this stuff
>> <matt> what else do they have to do ?
>> <shawn> :)
>> <shawn> i think we should just paraphrase in an email though
>> <shawn> i can start it
>> <shawn> and send it
>> <matt> how about a paraphrase, and attach the conversation for reference
>> <shawn> ok, sure
>> <matt> i think some people (mark) would like to read it
>> <shawn> send me the log
>> <shawn> and i'll do it
>> <matt> you can probably start down around where chad said 'hey shawn' 
>> 'I'm back now'
>> <matt> thanks
>> <matt> and great conversation
>> <matt> i'll catch you monday
>> <shawn> okay
>> <shawn> thanks
>> <matt> i'll send you the log
>> <matt> see ya
>> <shawn> bye
>> <chad> later
>>
>> _______________________________________________
>> seek-kr-sms mailing list
>> seek-kr-sms at ecoinformatics.org
>> http://www.ecoinformatics.org/mailman/listinfo/seek-kr-sms
> 
> 
>