2010Jan27

From Filtered Push Wiki
Jump to: navigation, search


User: Bob Morris | User: Zhimin Wang | User: Maureen Kelly | User:Donna Tremonte | User: Paul J. Morris | User: David Lowery | User: James Macklin | User: Chinua Iloabachie | User:
"User:" cannot be used as a page name in this wiki.
| User:
"User:" cannot be used as a page name in this wiki.
| User:
"User:" cannot be used as a page name in this wiki.



Administrive

From here on, proceed directly to the tea room for meetings at 10:00 am unless otherwise notified.

Reports

  • James has some ideas about the web client interface. He has some sketches of user scenarios.

There seem to be indications that Zookeeper is more than just a means to synchronize config files; it may also implement a failover strategy.

  • Chinua and Zhimin have been working on the web interface demo. They are trying to implement an autocompletion feature but JSF 2.0 is very new and they may have to work around it (or use something else). (JSF 2 has built-in Ajax implementation.)
  • Bob reports that the n3 turtle representation of rdf is easier for humans to read than the xml version. Also, Eclipse 3.5.1 as distributed on eclipse.org is useless on Ubuntu 9.10. Get Eclipse from Ubuntu instead. It seems to be an issue involving video drivers and windowing libraries.

Discussion

There are two core ideas that came out of today's discussion on user scenarios and design for the web demo:

  • Temporal component important in user scenarios: people will want to be able to see "new" records. Maybe have a ticker on the home page that lists recent annoations/additions. It is also a larger issue, in that different perspectives may have different requirements for displaying time-related data.
  • We anticipate having to manage the display of very large amounts of data, and the user interface design will need to be critically concerned with this.

User Scenarios

There are two groups of users, collections managers and researchers, whose intentions will be divergent.

Potential metadata fields for annotations: who is doing the annotation, what reason the annotation is being made, what type of annotation is being made, e.g. new determination, correction of a single field.

Perhaps when a user creates a new annotation of "correct one field" type, the user would first choose that type from a picklist, and then be presented a list of fields in the object. Then the user picks the field by name and an annotation form targeted to that type (correction of single field, with particular field chosen) is displayed.

There will also be cases in which a "correct single field" message will be sent without a suggested correction, just an assertion that a field value is wrong.

The new annotation form could perhaps have a control for adding another annotation, which would save the first and begin data entry for the next.

There is a concern that there will be too many annotations accumulated on single data records for the user to be able to view at one time. Perhaps a "consensus" could be artificially derived for display. In that case, the user will want to have input into the consensus-creating process: an indication of which annotators or record contributors are "authoritative."

The "authority" filter could be provided by the network proposing some hypotheses for consensus building, and letting the user choose among them.

Some fields of the record should not be merged in a consensus: determination should always be unchanged.


Annotations generated by software data mining may often be of the "assertion of single field incorrect" type, without being able to provide a suggested correction.

A possible UI implementation of distinguishing fields that have more data "behind" it, in the network (i.e. there are records that disagree on the value of that field): make the field display with a distinguishing background color. When the user clicks on the field value, a list of other values appears.

Another case is that in which a field has been identified for "internal" data quality control reasons (possible misspelling of place name, e.g.)

Researchers and collections managers will want to be able to distinguish between original label data and data generated by machine reasoning. TDWG DWC schema has elements for "verbatim" fields. Very important to be able to make that distinction clear.

Many collections databases currently do not make that distinction.

Facets

  • Simile at MIT has done a lot of work on facet-based UI navigation. (http://simile.mit.edu/) Zhimin will take a look.

Faceted browsing is an example of "search acceleration". If we have mechanisms for experts to use to navigate the web site, it probably should be the same across perspectives, though it is possible that different domains/disciplines will have significant differences in use cases that require differnt approaches.

A goal for facets is that they should not be hard coded but should be ontology driven. For example, we should not pick "CollectorName" out of the air as a facet, but the ontology should somehow suggest the facets to us.