Page Tree:

Child pages
  • Activity Definition Template - Instructions

This wiki space contains archival documentation of Project Bamboo, April 2008 - March 2013.

Skip to end of metadata
Go to start of metadata

This page describes the parts of an Activity Definition in the Activity Definition Template. New activity definition starts from the Activity Definitions page, where there is also an automatically updated list of activities defined to-date.

If defining a single activity takes longer than about 10-15 minutes, not including research involved in preparing the definition, less detail is probably in order.

The purpose of defining activities is to prepare a rough but concrete survey of elements of scholarly practice. This survey will be useful insofar as it can be understood by scholars to be connected to their work and points-of-view; it will be useful to technologists insofar as it suggests capabilities, inputs, and outputs to be defined more exactly in potential later phases of service modeling and definition.

In a subsequent phase of work, a high-level collection of re-usable, composable services will be mapped from the elements in this survey. A high-level map of composable services will permit the Bamboo community to identify priorities for shareable-service development during the project's implementation phase.

go back to Activity Definitions page

Activity Name

  • A succinct, descriptive name for the activity is included as a header (H1) at the top of the definition page. This activity name should also be the name of the definition page itself (save to your new name, not the automatically generated, "Copy of..." page name generated from the template).
  • The Activity Name should be recognizable by a scholar as an element of her work.
  • If the name you "need" is too elaborate, consider whether you're trying to define/describe multiple activities.

The purpose of the name is to convey a quick, soundbyte sense of the nature of the activity. When scholars look at a list of activity names, they should recognize elements of their work. When technical professionals look at the same list, they should recognize functionality and/or entities involved in the activity.


Activity Definition keywords describe categories, concepts, or type of 'scholarly stories' into which activities fit. It will probably be common to find activity definitions with multiple, sometimes disparate keywords. Keywords, in these senses, are a lot like "tags."

The purpose of attaching keywords to activity definitions is to identify commonalities as our collection of defined activities becomes large.

Only keywords on the controlled-vocabulary list should be added. However, working group members working on activity definitions should feel free to add new keywords to the list if those already included do not fit the category, concept, or type of 'scholarly story' you wish to associate with one or more activities.

Activity Definition(s)

  • Activity definition(s) should be limited to one or two short sentences.
  • Include major component steps. (e.g., see Gist - approximate translation...)
  • Where clarity would be significantly enhanced, definitions may be described in greater detail by using bullets to list component steps that make up the activity. (e.g., see Citation Surfing)

An activity may have multiple definitions (e.g., multiple algorithms for comparing two digital images). Where multiple definitions and bulleted component steps are included in the definition a "footnote" style is preferred for inclusion of the component steps. This helps a reader to see the bigger-picture definitions at a glance, and to drill deeper into each as need and interest suggest. [EXAMPLE!!]

Activity definitions should touch on:

  • constituent entities (scholars, digital resources - the subjects and objects of the activity); and,
  • capabilities (what is to be done with those resources).
  • However: the definitions at this stage of work are not meant to be complete or detailed.

Scholars' Stories (scenarios)

  • Include links to narrative, enumerated, or graphical descriptions of work performed by a scholar.
  • Links included in this section are to stories in which the activity defined on this page occur.

The purpose of this section is to ground the definitions of relatively small, atomic activities in the context of scholarship, broadly defined. "Scholarship" is likely to mean research and/or dissemination of research materials or findings; but might also be teaching, public service, curatorial, or other work closely related to arts and humanities research. Stories / scenarios are the means by which practitioners of arts and humanities scholarship (e.g., faculty) can identify the relevance of an activity to their particular, often unique modes of work.

Scholars' stories may:

  • be collected from the larger Project Bamboo community (e.g., by the Stories working group);
  • be artifacts (use cases, user stories, user scenarios, or other documentation) of tools or collections projects in the digital humanities;
  • occur in reports, reviews, or other papers focusing on methods of arts and humanities scholarship, communication, and/or production.

Tools (examples)

[Examples in this section are optional, but the utility of good examples is expected to be very high.]

In a table (see template):

  • List tools which perform some or all of the defined activity.
  • Note for each tool what part of the activity it supports, and where/how it falls short of supporting the defined activity.
  • Provide for each tool links to the relevant tools project or vendor web sites (i.e., who built and/or maintains it).
  • Links to humanities projects in which the tool is utilized should likely be part of the "Scholars' stories / use cases" section of the activity definition, rather than this section.

Tool examples are meant to provide more fully-specified guidance to future service modelers of the types of capabilities, inputs, and outputs necessary to provide utility to scholars. A "Bamboo service" might offer capabilities that span those offered by multiple tools, or that usefully abstract the functionality of multiple tools.

Applicable Standards or Standards Bodies

[Entries in this section are optional, but the utility of identified standards is expected to be very high.]

In a table (see template):

  • List the names of standards or standards bodies applicable to the defined activity.
  • Give for each standard very short description
  • Provide a URL to an authoritative statement or copy of each standard, or to the web site of each standards body.

These might include formatting standards (e.g., for storage or interoperability), standards for annotation, cataloging standards, standards of authenticity or reliability, etc.

An understanding of standards related to an activity will provide significant detailed guidance to service modelers in future stages of service identification, analysis, modeling, and definition.

Notes, comments, related activities, concerns

[Material in this section is optional.]

Include here one or more note, comment, link to related activities, or concerns that further enriches this activity's definition. Organize the material in this section in whatever way is most accessible - bullets, paragraphs, tables - whatever fits.

Remember that this definition is not intended to be complete at this stage of modeling. Material in this section should be concise, and should serve as a pointer to those engaged in later, deeper definition or modeling of this activity.

go back to Activity Definitions page

  • No labels