[seek-dev] Re: new screenshot
Rod Spears
rods at ku.edu
Fri Jul 16 11:46:49 PDT 2004
It appears you have it all under control, so I will just bow out of this
discussion.
I would be interested in being a part of any discussions on Fernando's
"conceptual analysis" ideas and how we might want to address those
aspects of the project.
Rod
Matt Jones wrote:
> I also agree we're not flying blind. Lots of ecology and analysis
> experience in-house. Plus lots of contact withour target user-group.
> It would be nice to get some more sreen shots like the ones Chad has
> been developing so that we can make some intelligent design decisions
> before implementation. Chad, Shawn, Mark, and I had a good
> conversation about the screenshots before I sent this info to the
> list, so you missed some of the context, Rod.
>
> Vergil is nicely configurable, and the Ptolemy folks have encouraged
> us to continue making changes that are re-configurable. I like that
> approach, because it makes it easy for us to plug in new components as
> we go, and easy for the Ptolemy folks to ignore our chnages if they so
> desire.
>
> I think that, once we get these browsing and data query interfaces
> designed, we should consider the interface as a whole. That willbe
> easier to do if we've thought carefully about the components, in terms
> of screenshots. However, keep in mind that we need to make some
> incremental progress as well, as other parts of the project like BEAM
> are waiting to use the stuff we produce, plus we have an NSF review
> next summer that will determine our future. So...we can't just
> completely go pie-in-the-sky in terms of design. Our near-term goal
> is to have much of this released in October (see notes from SEEK
> meeting in Scotland for details). That said, I think Ferdinando's
> suggestion to simultaneously consider what the ideal 'conceptual
> analysis' interface would be is a good one. Maybe we should schedule
> a few days to do that. I'll chew on that and see if I can come up
> with a time for a small group AMS/Kepler people to meet for a design
> session.
>
> Matt
>
> Shawn Bowers wrote:
>
>>
>>
>> Chad Berkley wrote:
>>
>>> I don't think we're flying blind. We picked kepler because it had a
>>> reasonably well defined UI that we could build off of. One that
>>> seemed intuitive to us (us includes ecologists as well as computer
>>> scientists). In making that decision, we were working off of more
>>> than 3 years of development experience where we were working with
>>> scientists to build other interfaces. I'm somewhat opposed to the
>>> mentality that *everyone* must think the UI is perfect and
>>> completely intuitive at first glance. I just don't see that
>>> realistically happening. I've mostly convinced myself that the only
>>> way we are going to get a UI is to take 2 developers and 2
>>> ecologists (or whatever kind of domain scientist) and stick them in
>>> a room for a few days and let them decide. I'm not sure deciding a
>>> UI design by committee (i.e. on seek-dev) is really a good way to do
>>> things.
>>>
>>> On another note, if someone else with more UI experience than I
>>> would like to come up with the perfect interface design screenshot
>>> and check it into CVS, I would be happy to review it :)
>>
>>
>>
>>
>> The nice thing too about Ptolemy is that it is very configurable (I
>> think so much so that it gets obfuscated, but that is another issue).
>> So, making changes or tweaks even to the UI isn't that hard.
>>
>> On the other hand, I think Kepler does need to spend considerable
>> time on making the UI intuitive to the targeted users. (I think this
>> is the point of developing the screen-shots/design for actor and data
>> browsing, and so progress is being made.) Kepler now basically uses
>> the default Ptolemy UI configuration, but there seems to be lots of
>> opportunities to use some of the more advanced configuration of
>> Ptolemy to support new (and improved) interfaces.
>>
>> I agree with Chad (and Rod too I think), try some stuff, get a user
>> group (the two ecologists), see what they think, tweak, iterate
>> again, etc. There are probably some basic UI best-practices we can
>> use as we do this stuff. And we should have some basic goals, like
>> making things intuitive enough so that you don't have to read a
>> manual or have someone there to hold your hand just to start use the
>> system, etc.
>>
>> I think also that even the Ptolemy group, from what I have heard,
>> recognizes the need for a better UI.
>>
>>
>> shawn
>>
>>
>>
>>
>>>
>>> chad
>>>
>>> Rod Spears wrote:
>>>
>>>> We are flying blind...
>>>>
>>>> And I think we approaching this from the inside out (once again).
>>>> Shawn is right, instead of trying to figure out how to make our
>>>> problem fit into Kepler. We should be defining the problem, the
>>>> best UI for our target users that solves the problem, THEN see how
>>>> to implement that inside of Kepler.
>>>>
>>>> If we see the entire UI in terms of tab and tree controls then that
>>>> is how we will view our solutions.
>>>> Rod
>>>>
>>>>
>>>>
>>>> Shawn Bowers wrote:
>>>>
>>>>>
>>>>> I think that at this point, Kepler basically offers little to no
>>>>> support for really organizing and describing actors and workflows.
>>>>>
>>>>> It seems that what you are pointing out is that there needs to be
>>>>> some well thought out organization for actors, such that the
>>>>> organization actually helps people (scientists, researchers, etc.)
>>>>> develop workflows. Of course, different disciplines, different
>>>>> user groups, and different use cases may all have different
>>>>> preferred organizations.
>>>>>
>>>>> I think a benefit of the infrastructure that we are considering is
>>>>> that you can have many different organizations, i.e., different
>>>>> "views" of the same actors. One of these classifications could be
>>>>> purely in terms of ecology concepts, others could be in terms of
>>>>> the generic function of actors (aggregration, transformation,
>>>>> etc., the "building blocks" you describe), and so on. But for
>>>>> this to work, we need some default organizations, possibly some
>>>>> templates for creating configuring new ones, and maybe even some
>>>>> tools to help construct such organizations from scratch.
>>>>>
>>>>> This infrastructure may also enable some of Ferdinando's ideas of
>>>>> concept-based workflow construction/specification, where you don't
>>>>> care about the specific actor -- you basically work at the concept
>>>>> level, and let the system figure out the best actor(s).
>>>>>
>>>>> Also, I wonder if some of these organizations can be constructed
>>>>> using existing information. For example, based on semantic
>>>>> annotations of datasets using Rich's ontologies, e.g., can useful
>>>>> classifications be "extracted" -- allowing such organizations to
>>>>> be automatically constructed? Or, if actors have their input and
>>>>> outputs semantically marked up, can we easily
>>>>> configure/infer/classify actors and construct organizations using
>>>>> that information?
>>>>>
>>>>>
>>>>> shawn
>>>>>
>>>>>
>>>>>
>>>>> Daniel Higgins wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I would like to bring up another question regarding this
>>>>>> concept-based ontology display of actors that is being discussed.
>>>>>> Just what will end up as the leaf nodes of the concept tree? I
>>>>>> tend to think of actors as modules in a workflow. Now it is
>>>>>> certainly true that a complete workflow can be put in a composite
>>>>>> actor container and called an 'actor'. But there is not much
>>>>>> advantage in doing that unless this new 'actor' can be reused
>>>>>> somewhere else.
>>>>>>
>>>>>> Is the ontology based display of actors going to include all
>>>>>> workflows, or modular actors AND more complex workflows? In my
>>>>>> experience building Kepler workflows/models, one tends to use
>>>>>> some actor components in almost all models (e.g parameters,
>>>>>> displays. expressions, etc.) Many of these would seem to fit into
>>>>>> all (or none) of a higher level concept organization.
>>>>>>
>>>>>> For example, I would imagine that a large number of workflows
>>>>>> would fit into the general category of data analysis where there
>>>>>> is some data that is input., the data is massaged so that it can
>>>>>> be feed to some analysis module (e.g a statistical calculation),
>>>>>> and then the results displayed in one of many ways. There could
>>>>>> easily be a large number of such workflows that only vary in some
>>>>>> small way (e.g. one uses integer data, another floats, or one
>>>>>> plots a scatter plot as output and another a box plot). If all
>>>>>> these workflows with only small variations were listed, the
>>>>>> result would seem to be somewhat overwhelming to a new user. On
>>>>>> the other hand, they are all made up of a smaller set of more
>>>>>> atomic actors that do things like type conversion, mathematical
>>>>>> transformation, or graphical display. These more atomic actors
>>>>>> don't really seem to fit anywhere in some concept ontologies, yet
>>>>>> they are the pieces used to build almost any workflow.
>>>>>>
>>>>>> I tend to think that someone using Kepler really wants a
>>>>>> small set of atomic actors that are useful for building a variety
>>>>>> of scientific workflows. This is sort of like the electronics
>>>>>> world where only a few types of components are used to build TVs,
>>>>>> stereos, computers, and iPods.
>>>>>>
>>>>>> So I am suggesting that perhaps we distinguishg between
>>>>>> example workflows and a (hopefully) small set of 'atomic actors'
>>>>>> used to build such workflows. The example workflows are very
>>>>>> useful educationally, but are not directly used to build new
>>>>>> workflows. [As an example, the Stella system uses a very small
>>>>>> number (3 ?) of atomic actors to build all sorts of workflows
>>>>>> (models). This simplicity is one of the factors that make it
>>>>>> appealing.]
>>>>>>
>>>>>> Dan Higgins
>>>>>>
>>>>>> Rod Spears wrote:
>>>>>>
>>>>>>> I agree with the conclusions stated below in Matt's reply,
>>>>>>> except the part about menus. Actor and Data tabs should be
>>>>>>> separate (I thought we decided this long ago). The slider is
>>>>>>> confusing, mostly because it is too general and the user has no
>>>>>>> idea "specifically" what is meant by "General" or "Spefic." We
>>>>>>> understand those terms in and "general" way but we cannot tell
>>>>>>> from the UI how general "General" is or how specific "Specific"
>>>>>>> is and it is hard to tell just what the gradiation is in between
>>>>>>> the two. For example, what does half way between General and
>>>>>>> Specific mean?
>>>>>>>
>>>>>>> Also, a deadly UI sin is to have things in one tab effect things
>>>>>>> in a different tab. Tabs are many parts of the whole, for lack
>>>>>>> of a better description tabs are just a one level tree control
>>>>>>> that hides the other siblings.
>>>>>>>
>>>>>>> *As far as the menus go:*
>>>>>>> Why were toolbars invented? They were invented because menus
>>>>>>> hide UI and aren't always easy to use especially when you have
>>>>>>> to traverse past the initial drop down. Comboboxes are the same
>>>>>>> way. They save real estate but but require multiple clicks and
>>>>>>> possibly scrolling and quite often if you aren't careful they
>>>>>>> pop "away" on you. (Same for menus).
>>>>>>>
>>>>>>> The hard part is to balance how other apps work and what
>>>>>>> scientists are used to versus the usability of entirely new
>>>>>>> approach. The simple statement is, burying complex UI in menus
>>>>>>> because that is what scientists are used to is not the right
>>>>>>> answer.
>>>>>>>
>>>>>>> I wish we could have asked Ginny after the first 10-15 minutes
>>>>>>> of using that app (SAS Analyst), for which she is now an
>>>>>>> experienced user, how intuitive it was. Did she use the app
>>>>>>> because it was intuitive and easy to use, or because had to? We
>>>>>>> can't forget, scientists don't have to use our app to get their
>>>>>>> work done.
>>>>>>>
>>>>>>> If she liked the idea of menus better than the UI we showed her,
>>>>>>> maybe there was something really wrong with our UI.
>>>>>>>
>>>>>>>
>>>>>>> Rod
>>>>>>>
>>>>>>>
>>>>>>> Matt Jones wrote:
>>>>>>>
>>>>>>>> Hi Chad,
>>>>>>>>
>>>>>>>> Thanks for the additional screenshots, Chad. I'm not sure
>>>>>>>> which one works best. I do think the Actor/Data separation in
>>>>>>>> tabs is good from a usability perspective even if it isn't
>>>>>>>> strictly necessary from a classification perspective.
>>>>>>>> Particularly telling is that, even in your example, you would
>>>>>>>> use different concepts to organize data than you do actors, so
>>>>>>>> the disctinction occurs very high up in our concept space. I
>>>>>>>> think most scientists will make a strong distinction here (see
>>>>>>>> below).
>>>>>>>>
>>>>>>>> Also, I agree we should eliminate the slider altogether - it
>>>>>>>> will probably be confusing.
>>>>>>>>
>>>>>>>> The question of whether to use a) one tree with instances in
>>>>>>>> the tree, or b) two panels where the first tree filters
>>>>>>>> individuals in the lower list, is the hard one. In (a) we
>>>>>>>> can't really combine categories easily, so you are stuck with
>>>>>>>> looking at the actors in a single category, which can be
>>>>>>>> limiting and means you might have to expand lots of folders to
>>>>>>>> find what you are looking for. But the UI is very
>>>>>>>> understandable. In (b), you have a tree used as a control in a
>>>>>>>> way that is not typically done, so we need to be sure the
>>>>>>>> increased query functionality (e.g., abillity to select
>>>>>>>> multiple properties at once) justifies the hit on
>>>>>>>> intuitiveness. Also, (b) will likely suffer from screen
>>>>>>>> real-estate problems. The single panel onthe left already
>>>>>>>> seems too small because we frequently want to see 15+ rows of
>>>>>>>> actors or even more for data. Making 2 panels just makes it
>>>>>>>> worse.
>>>>>>>>
>>>>>>>> Ultimately I think we should be presenting these design choices
>>>>>>>> to users. For starters getting Deana and Samantha and other
>>>>>>>> SEEK participants to comment on the 3 screen shots would be
>>>>>>>> useful. Towards this end, I showed your screen shots to Ginny
>>>>>>>> Eckert, a quantitative ecologist (and my wife), and here's her
>>>>>>>> perspective: 1) definitely separate data and actors in two
>>>>>>>> tabs -- ecologists just think this way. 2) for the browse view,
>>>>>>>> only use one pane for the tree, as the two panels are just too
>>>>>>>> confusing. Its not clear at all how it works. Move any
>>>>>>>> advanced querying (e.g., find all numerical simulations that
>>>>>>>> are also static) into a separate advanced query dialog. 3)
>>>>>>>> Eliminate the slider -- she thought it might be useful, but
>>>>>>>> probably too non-conventional.
>>>>>>>>
>>>>>>>> Some other stuff she comented on too: 4) The main workflow
>>>>>>>> display MUST have scroll bars, and the panning control
>>>>>>>> should/could be moved to a dialog/floating panel so that the
>>>>>>>> tree has more real estate. 5) Ginny is very used to using menu
>>>>>>>> driven systems for selecting the statistics to be used ona set
>>>>>>>> of data. Her process for this type of app is 'Open the data,
>>>>>>>> select stats from hierarchical menus, configure stat, run'.
>>>>>>>> See, for example, SAS Analyst. So, she says that having the
>>>>>>>> 'models' in the tree on the left is really non-intutitive
>>>>>>>> altogether, and those hierarchies really should be menu items.
>>>>>>>> I'm not sure if we can accomodate that view, but she felt
>>>>>>>> pretty strongly about it.
>>>>>>>>
>>>>>>>> So, in conclusion, I would probably vote for something akin to
>>>>>>>> your 'actor-ontology-search-without-list-with-tab.jpg', but
>>>>>>>> also remove the slider from the bottom, and add an advanced
>>>>>>>> query dialog that parallels the data query dialog and allows
>>>>>>>> easily creating advanced logical queries.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Matt
>>>>>>>>
>>>>>>>> Shawn Bowers wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Comments interspersed ...
>>>>>>>>>
>>>>>>>>>>> It isn't immediately clear anymore why the slider is
>>>>>>>>>>> there... I thought the reason to have it was to be able to,
>>>>>>>>>>> within the directory structure, "collapse" a set of nodes so
>>>>>>>>>>> that you can, e.g., see all the individuals (actors,
>>>>>>>>>>> datasets, etc.) under a directory or any of its
>>>>>>>>>>> subdirectories, without having to navigate through to the
>>>>>>>>>>> subdirectories themselves (i.e., the subdirs aren't directly
>>>>>>>>>>> shown).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> OK, (imagine for a second that the slider is actually on 3
>>>>>>>>>> (note the slider may also just be divided proportionally, in
>>>>>>>>>> which case 2 could equal level 6, 3 level 9, etc.), where it
>>>>>>>>>> should be). You now see 3 levels of the tree. Note that
>>>>>>>>>> there are no '+' symbols next to the behavioral, functional
>>>>>>>>>> or static folders. Now, if we move the slider to the right
>>>>>>>>>> one notch so it's on 4...+ symbols would appear next to
>>>>>>>>>> behavioral, functional and static (if they actually have
>>>>>>>>>> children) and you would be able to browse there. I actually
>>>>>>>>>> now think that this slider makes more sense when the results
>>>>>>>>>> are integrated in the tree, but I still think it's useful
>>>>>>>>>> with the list view.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I agree that the slider doesn't make much sense unless you
>>>>>>>>> only have a single tree view. Otherwise, you can just use the
>>>>>>>>> capabilities of the tree view directly (with the other window)
>>>>>>>>> as I mentioned in the other email.
>>>>>>>>>
>>>>>>>>> Actually, I still think having two separate panels -- one for
>>>>>>>>> the tree w/ individuals and concepts, and one for listing
>>>>>>>>> selected individuals -- and no slider is the best way to go.
>>>>>>>>> Selecting a concept in the tree displays all individuals under
>>>>>>>>> that node, i.e., the individuals in the current concept, the
>>>>>>>>> individuals in all the subconcepts, and in their subconcepts,
>>>>>>>>> etc. Selecting multiple concepts in the tree view displays
>>>>>>>>> the union of those selected. Individuals can be selected and
>>>>>>>>> placed in a workflow, e.g., by dragging and dropping from
>>>>>>>>> either panel.
>>>>>>>>>
>>>>>>>>> My main problem with the slider is that it is
>>>>>>>>> "unconventional". It isn't a standard kind of user interface
>>>>>>>>> widget used with trees. It adds an extra level of complexity
>>>>>>>>> that I don't think is needed. And, it isn't immediately clear,
>>>>>>>>> without playing with it a bunch or reading some documentation,
>>>>>>>>> what it does or what it is for.
>>>>>>>>>
>>>>>>>>>> There are not supposed to be directories...sorry for the
>>>>>>>>>> icon, i just copied the "data" icon from kepler. Those are
>>>>>>>>>> intended to be individuals.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> OK. My mistake -- it does look a little different than a
>>>>>>>>> folder icon.
>>>>>>>>> (A better icon would be the canonical cylinder disk, but okay.)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> I think what you are proposing with actors is very simple in
>>>>>>>>>>> terms of ontological information, and doesn't apply directly
>>>>>>>>>>> to Rich's ontology. The notion being exploited in your
>>>>>>>>>>> screenshot is assignment of a controlled-vocabulary-style
>>>>>>>>>>> keyword (with some notion of subconcept, or
>>>>>>>>>>> narrower-term/broader-term) to an actor. The ontology is
>>>>>>>>>>> trying to extend the more eml-ish approach of describing
>>>>>>>>>>> what is in the dataset, so that we can do some automatic
>>>>>>>>>>> processing with it.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> What do you mean by "Rich's" ontology? This is just dealing
>>>>>>>>>> with organizing the models/actors/etc in kepler. I thought
>>>>>>>>>> Rich's ontology was the full on ecology ontology that would
>>>>>>>>>> probably be used to classify data only. Am I missing
>>>>>>>>>> something here?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I was under the impression that Rich was the only person
>>>>>>>>> actually working on ontologies for SEEK. Also, there has been
>>>>>>>>> some initial work on representing models and actors using the
>>>>>>>>> same framework, so it isn't solely for data.
>>>>>>>>>
>>>>>>>>> My point is just that to do something similar for data (and
>>>>>>>>> possibly for actors), more thought needs to go into how to get
>>>>>>>>> the concepts that would be useful for this browsing
>>>>>>>>> interface. The ontology being created does not consist of a
>>>>>>>>> set of keywords -- it consists of concepts defined in terms of
>>>>>>>>> their interrelationships, which sometimes can get pretty
>>>>>>>>> complex. This was the reason for my comment below.
>>>>>>>>>
>>>>>>>>> I think your actor-ontology-search-without-list-with-tab.jpg
>>>>>>>>> image shows this well. The concepts that show up in the tree
>>>>>>>>> are pretty much hand-picked terms that make sense to an
>>>>>>>>> ecologist for finding data (as opposed to all the various
>>>>>>>>> concepts that exist within an ontology, or even a controlled
>>>>>>>>> vocabulary but that is another story). If you just took all
>>>>>>>>> the concepts of the ontology and created a tree -- I don't
>>>>>>>>> think it would be that helpful for the kind of browsing
>>>>>>>>> interface being proposed. Also, there might be useful
>>>>>>>>> data-level items that could show up as a "directory", e.g., a
>>>>>>>>> particular species name, or a particular biodiversity index,
>>>>>>>>> etc., so that has to be taken into consideration as well. In
>>>>>>>>> general, I think we need a good way to pick out the
>>>>>>>>> appropriate terms from the ontology that are best suited for
>>>>>>>>> this style of browsing.
>>>>>>>>>
>>>>>>>>> shawn
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> The difficult thing is defining concepts so that they can
>>>>>>>>>>> capture the purpose of the structural description of a
>>>>>>>>>>> dataset, that EML provides -- which is what enables
>>>>>>>>>>> integration, e.g., or the ability to apply automatic
>>>>>>>>>>> conversions, etc. The concepts, however, I wouldn't
>>>>>>>>>>> necessarily consider as keywords per se ... although it may
>>>>>>>>>>> be possible to infer or extract keywords from the dataset
>>>>>>>>>>> directly based on the semantic "registration", or possibly
>>>>>>>>>>> to extract keywords from the ontology.
>>>>>>>>>>>
>>>>>>>>>>> A while ago, Rich and I also discussed an approach for
>>>>>>>>>>> taking a keyword list (either user-defined or some
>>>>>>>>>>> "standard" list of terms), and letting a user define the
>>>>>>>>>>> terms using the ontology. (Rich uses something simple for
>>>>>>>>>>> this in his FoodWeb work.) Then, you could "automatically"
>>>>>>>>>>> construct a structured controlled vocabulary of the terms
>>>>>>>>>>> from their definitions (automatically, assuming you did the
>>>>>>>>>>> work of mapping terms to ontology stuff).
>>>>>>>>>>>
>>>>>>>>>>> Right now, the best way to get keywords for datasets is
>>>>>>>>>>> probably to extract them directly from detailed parts of the
>>>>>>>>>>> ontology (for those parts of the ontology that reflect
>>>>>>>>>>> "keywordy" information, like subclasses of Observable Entity
>>>>>>>>>>> Properties or Observable Entities, etc). But, the concepts
>>>>>>>>>>> defined within the ontology are probably higher-level than
>>>>>>>>>>> what one would consider as keywords. For example, the
>>>>>>>>>>> concepts "Observation," "Time," "Location," and so on, don't
>>>>>>>>>>> seem like they would be very useful keywords to browse for
>>>>>>>>>>> datasets ...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> ---------------------------------
>>>>>> Dan Higgins
>>>>>> Software Developer
>>>>>> National Center for Ecological Analysis and Synthesis (NCEAS) 735
>>>>>> State St. Rm 205 Santa Barbara, CA 93101 805-892-2531
>>>>>> higgins at nceas.ucsb.edu ---------------------------------
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> seek-dev mailing list
>>>> seek-dev at ecoinformatics.org
>>>> http://www.ecoinformatics.org/mailman/listinfo/seek-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> seek-dev mailing list
>>> seek-dev at ecoinformatics.org
>>> http://www.ecoinformatics.org/mailman/listinfo/seek-dev
>>
>>
>>
>> _______________________________________________
>> seek-dev mailing list
>> seek-dev at ecoinformatics.org
>> http://www.ecoinformatics.org/mailman/listinfo/seek-dev
>
>
--
Rod Spears
Biodiversity Research Center
University of Kansas
1345 Jayhawk Boulevard
Lawrence, KS 66045, USA
Tel: 785 864-4082, Fax: 785 864-5335
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/seek-dev/attachments/20040716/507779b5/attachment.htm
More information about the Seek-dev
mailing list