All,

Here's my write up from the Collaboration Cell's discussions at
Illinois. My thanks to John, Catherine, Stan, and Matt B. for their
help getting the ball rolling here.

The overall focus of the conversation was on the interrelated
questions of how to publish results from MONK, how to annotate them
(and publish the annotations), and what this then means for the data
model in terms of how MONK understands state and history. All agreed
that there was significant potential for research activity here,
particularly with regard to the question of establishing principles
for what constitutes a useful history (a topic which could be
approached by way of interface design, data model, and textual
theory). The Data and Interface cell in particular will need to work
closely with us on this, as well as Users and Use Cases. A more
detailed breakdown of the discussion follows, then a short list of
action items.

1. Matt reported on milestones met, specifically the launch of the
public MONK Web site and survey of MONK's "virtual neighborhood." We
have a short list of <10 other projects/platforms/services on the Wiki
with whom we can envision collaborations ranging from the passive
(making sure our data is usable, for example ManyEyes) to considerably
more substantive. See item 6 below.

2. Matt pointed out that the Collaboration cell's mandate is really
two-fold, to allow MONK users to collaborate with one another and to
allow MONK users (or services) to collaborate (or communicate) with
non-MONK users and services. John added that this cell should also
help facilitate collaboration amongst members of the MONK project
team.

3. The first major portion of the discussion focused on an editorial
structure for MONK data. How will MONK users propose changes to a
collection curator? If a user realizes data is flawed and wants to
clean it up, how will this happen? (Simple case: an OCR error). This
might lead to something like a collaborative editing environment. At
this point we began to talk about a MONK plug-in for the Project
Gutenberg Distributed Proofreading project (http://www.pgdp.net). Matt
then asked what it would mean for MONK to integrate itself more fully
with Project Gutenberg itself, placing its analytics at the disposal
of PG's users while also making PG's texts available to MONK as a
collection. John pointed out the potential difficulty here of PG's
having multiple and incommensurate versions of a text available. He
agreed to have a follow up conversation with Paul Jones, at ibiblio.

4. The next phase of the conversation was devoted to annotation. Some
preliminary work here is available from Celeste Paul, who wrote a
paper proposing an annotation scheme for FeatureLens under Catherine's
direction. The document "chunk" will be the basic unit of annotation;
maybe also a word, maybe an arbitrary span of text, but annotations
will have to be tied to chunks: chunk, work, collection, state,
history. (A history is a series of states.) Windows might be basic
units of annotation for state and history; this would allow us to
annotate a visualization, for example. Annotations will of course take
the form of text, but possibly also audio or an RSS feed to subscribe
to annotations.(You would subscribe to the annotation feed for a
particular Project).

Annotations imply a public and private distinction, which in turn
implies user registration. Ideally we would also have user groups
(share this annotation with my group), though we might have to forgo
this in initial implementations. The most immediate objective would be
an option to make annotations public, with an option to turn
annotations on or off for any chunk you're viewing.

Users will have an option to make a "project" public.

Stan suggested looking to Manyeyes as a precedent for saving
state/history in FeatureLens.

Matt would like to see how we could push the envelope for publishing
MONK results. Right now results from text analysis and visualizations
are typically "published" in the form of screenshots embedded in an
article. With the advent of venues like Digital Humanities Quarterly
why shouldn't we aspire to dynamic publication of a MONK analytic with
state and history intact? The analogy here would be the "link to this
URL" feature in something like Google Maps, where you can link a third
party user into the map view in its current state.

This might imply something like a universal read-only MONK account for
"guest" access.

We will need to determine what is in each slice of the history. (If we
do that properly, then the annotation slice is easy. )

Similarly, we want result to be portable within MONK, so that users
can move results from one MONK service to another.

The question was raised whether Zotero become our annotation
environment. (Limitation: Zotero is a Firefox extension.) Bill and
Martin both mentioned plans to convene a group (including Zotero) to
discuss an open annotation schema at Northwestern in the fall.

5. Matt pointed out that we currently have no development support at
Maryland, and that all of the above will need to be integrated into
the project's development workflow. John replied that for now, the
Collaboration cell should be proposing features or requirements for
the other cells. We should start by plugging these things into part of
the use cases.

6. We concluded by reviewing the short list of other
projects/platforms/services on the Wiki. Zotero, as discussed above,
could potentially be a very significant partner for MONK; at a
minimum, we would want Zotero users to be able to capture MONK
analytics as part of their libraries. TAPoR demands attention both to
avoid duplication of effort and, potentially, to have crosswalks from
one project's analytics to the other. Stefan is our TAPoR expert.
ManyEyes: we agreed this was low hanging fruit we'd be crazy not to
pluck. ManyEyes provides a good palette of scientific visualizations,
and the tools to integrate them into blog sites and other features of
the Web 2.0 landscape. Stan was dubbed ManyEyes expert. Yahoo Pipes is
a visual programming environment for data mash-ups. John and Matt both
have some experience with it. If we output data as a feed, we can
expose it to Pipes. NINES/Collex is a digital curation tool deployed
in a large, distributed digital library. Matt B. agreed to become our
resident expert. The Digital Docket is a University of Maryland
NSF-funded proejct which has significant shared interests with MINK
and with whom we can share ideas and, potentially, resources. SEASR
was the subject of general convesrsation throughout the project. SEASR
could become, in John's words, a backend for MONK. Project
Gutenberg/Distributed Proofreading Project is discussed above.
Finally, a number of MONKs are interested in Second Life, specifically
the question of what it would mean to provide meaningful access to
MONK services from within SL, and/or to use SL as an environemnt for
rendering visualizations. This is likely a moonlighting project which
interesetd MONKs will pursue as time allows.

ACTION ITEMS

John: Contact Paul Jones at ibiblio about MONK/PG

Matt: Schedule next conference call (proposing: Thursday, June 21,
11:00 eastern)