[seek-kr-sms] KR Ontology Needs

[Shawn Bowers]

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