Upload presentations and meeting notes about Adjusting Work Plans Presentation and Notes to this page.
[Steve's capture of principles Marlita wrote on flip charts ... may be incomplete or misinterpreted!!]
- Has a useful functionality
- Has an audience of scholars interested in using it to operate on collections with which Bamboo is engaging
- Has an audience of content providers who want to supply input to the tool
- The body of selected tools can work on structured and unstructured content
- Tool has to offer something that is not available from the archive/repo where the collection is hosted/served
- might meet the principle by permitting existing function to apply to a wider world of content than it was designed for or to which it was originally applicable
- has to be a community of support for the tool
- have to be ready to be deployed
- not proprietary or doesn't require distribution by Bamboo
- adhere to standards that are in wide use rather than inventing new ones
- fungibility / plug-n-play of tools – if tools are doing similar things they should have similar interfaces – or be able to integrate via connector
- ease of use – time put in is commensurate with value a scholar gets from using
- Representativeness of functionality across types and disciplines of humanist practice
- tools are amenable to workflows
[Proposed addition criteria from Bruce Barton:]
In addition to thinking about how we evaluate any single tool, we could also ask how the collection of tools we support relate to each other.
- Are the tools complementary, such that a scholar who is attracted to one tool might find other tools useful as well?
- Is there enough diversity in our mix of tools, where diversity could be measured along several dimensions:
- Is the range of scholarly problems to which they can be usefully applied broad enough?
- Do they represent a broad enough range of deployment or invocation profiles to demonstrate the kinds of capacities we want the ecosystem to have at the end of Phase I? I realize that this is vague. Examples: tool in a work space with possibly more than one style of invocation;too on the BSP as a simple RESTful service where result returns the operation payload; tool on the BSP as a RESTful service where the result is cached for later retrieval after a notice has been sent.
- Other ranges might include
- simple vs. complex/sophisticated;
- standalone vs. component of a workflow;
- produces a derivative object by a transformation vs. performs an analysis.
Tim Cole proposes, building off discussion with Neil Fraistat during the break
- create a matrix of tools, describing what's proposed for BSP deployment; then
- give folks some period to populate the table with different categories of tools.
- (Neil) or task a group to fill in the matrix, so that it becomes a vetted matrix of tools; and,
- (Tim & Neil): and then task a group (Scholarly Services group? something broader) to filter that against the principles we've compiled