[Fwd: Re: [seek-kr-sms] ontology/folder UI design in Kepler]

Shawn Bowers sbowers at ucdavis.edu
Thu Mar 3 08:48:56 PST 2005


Laura L. Downey wrote:
> As someone new to the project, I'm still trying to understand which user
> group we are designing for -- knowledge engineers, domain scientists, both,
> or some hybrid of an ecologist with some ontological knowledge.  And the
> next question is to what level we are trying to support the various tasks
> these users might perform within Kepler.   Deana and I had a good discussion
> this morning where she was catching me up on things and where she mentioned
> that the KR-SMS team is still in the process of determining the target users
> and associated tasks.  Until we have that information we can't really fully
> design the ontology UI.

I think there are two aspects: one is Kepler in general, and one is SEEK 
and SEEK's use of Kepler. The Kepler system is really targeted at a very 
broad user base from programmers, to domain scientists, to researchers, 
to information managers, to possibly even students learning about 
science and scientific workflows and models.

SEEK, however, I think is more targeted at the scientist/researcher (at 
least as described in the proposal) and although not necessarily 
explicit, those who manage data (e.g., "information 
managers/specialists" within LTER) or provide analytical support (e.g., 
people doing complex synthesis projects like at NCEAS).

Mark and Matt probably have more insight into the target user group; so 
they can correct me here if I am wrong.  I am not sure what Deana means 
in terms of us trying to determine the target users and associated 
tasks. My impression has always been, at least from the proposal, that 
we are charged with enabling ecological scientists and researchers via SEEK.

Also, in previous threads on this list, we discussed differences to the 
"bottom up" and "top down" design of Kepler (in the Fall I believe).  We 
agreed that we are currently going bottom up, that is, we are developing 
low-level core functionality that can eventually be built upon to get to 
a more integrated and conceptual interface. Alternatively, we had 
discussions briefly about "top down" designs, in which we start from the 
conceptual interface (e.g., high-level schemas for workflows and other 
"visions" of interface capabilities distinct from Kepler and what Kepler 
provides).  I think we have had a fairly good idea of what the 
high-level SMS tasks are, at least since I started the project.

What I think would be cool, is if we could work from both of these 
levels.  Instead of strictly focusing on the bottom-up approach (which 
we agreed is necessary to do), we also spend some additional time 
thinking about and investigating way-out there and crazy interfaces that 
may be useful to scientists wrt the workflow paradigm. Ferdinando sent 
around one such "vision" of interaction, and I think we should continue 
to pursue and develop these ideas, and even do "usability" experiments 
in this regard.

My concern is that if we only focus on Kepler as it is today; we have 
already biased our user group and that we are limiting ourselves. 
Instead, I think we should also pursue design from "the other end" so 
that we have multiple types of information to base our decisions on.

Laura, you can hopefully further enlighten us about these issues -- 
since from my experience HCI research is rich with this "top down" 
style, for example, experiments leveraging "wizard of oz" studies, 
surveys, field studies, observational studies (which could be a very 
exciting line of research: e.g., how do people currently communicate 
their datasets and analyses), and so on.

Shawn

> We could however, as I and others have mentioned, certainly incorporate some
> "picking concepts" mechanism where we display the known concepts and allow
> the user to select concepts to support the task of assigning concepts to
> datasets and/or actors.  I'm assuming (dangerous I know) that Matt is
> referring to something similar with his "browsing" terminology in his last
> note and which we'll know more after he gets the wiki page up he referenced.
> 
> Later, after we have more information, it might be possible to supplement
> that "concept selection" by offering some list of questions the user has to
> answer in order to do their tagging.  We could even consider a wizard like
> UI if we managed to formulate a basic set of questions, easily
> understandable by domain scientists that could be translated to work
> properly within a formal ontology.  But again, I would not see being able to
> determine that set of questions until the KR-SMS team has hashed out their
> target user group(s) and determined the kinds of tasks they would perform.
> But in the interim, we could offer some hierarchical representation for
> users to pick concepts from.
> 
> I noticed that Serguei has offered a set of questions based on the "tagging
> task" for us to consider in trying to determine which kind of specific UI
> (including metaphors) we might offer.  At first I thought he was offering
> these as questions as something to translate into English ;-) for the users
> to answer to help them do their annotations.  But Deana pointed out that was
> not the case.
> 
> One quick question here, are we really thinking about letting users annotate
> ports?  This seems to be a very very low level of annotation that I can't
> see that many users doing.  Is this related to the data integration issue?
> 
> Back to Serguei's questions.... if I'm understanding them correctly (with
> some help from Deana) basically he's asking does the user need to understand
> all the complexity in the ontology.  And if so, then a tree representation
> can't adequately communicate that complexity.  However, I think that the
> complex graphs produced by the various ontology tools are certainly
> difficult enough for experienced KE's to decipher, much less domain
> scientists, even those with some ontological knowledge.  Ferdinando brought
> up the issue of graphic extension philosophy as a means of trying to
> simplify these complex graphs but after looking at those examples, I'm not
> convinced they would be applicable to scientific ontologies -- especially
> after talking with Deana about the nature of scientific ontologies.  Those
> examples work because there are these easy binary groupings like man/woman
> or mother/father etc in the family tree example, or small numbers of large
> categories like chemical compounds falling into one broad category (nitrogen
> compounds) with say 3 different kinds of processes to apply to them.
> 
> I think it might be possible to use the graphic extension philosophy a
> little in a tree representation -- for example some symbol that indicates
> that a concept is used in multiple places within the tree, with the option
> of showing the various "neighborhoods" that a concept is used in. (Think
> about an option that says show me all the occurrences of "concept X" and a
> view of the tree being expanded one level above and below the various
> occurrences of "concept x" with concept X highlighted and everything else in
> the tree collapsed.  I also think we could support the operation of showing
> the user other items that have been assigned a certain concept.  And we
> might offer filtering and searching on the tree too.  Lots of these
> suggestions support the notion that the user has an idea how they want to
> classify something and only needs to see various pieces to make a decision.
> Of course if the user wants to see the entire tree, we have to make that
> available too.  And that is a tough problem lots of people seem still to be
> working on -- visualization of large hierarchies.
> 



More information about the Seek-kr-sms mailing list