Scheduled DB Maintenance: January 21st - 8:00 AM to 10:00 AM. Confluence will be unavailable during this time.

Navigation:
Documentation
Archive



Page Tree:

Child pages
  • Shared Services - Program Document Sec 4 - Discussion Draft of 9 March 2009

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

Skip to end of metadata
Go to start of metadata

See also the Bamboo Program Document Outline, Sec 4, v.0.1

Shared Technology Services - Discussion Draft of 9 March 2009

Program Document Sec 4 - Shared Technology Services

This is a second-draft iteration of the Shared Technology Services section of the Program Document. The outline-numbering scheme has changed since the last version; this section of the Program Document is now numbered "4." Version 0.1 of the outline of the Program Document has been posted to this wiki space, and linked from the home page. The new outline reorganizes, fleshes out, and shifts emphases, but does not radically alter the fundamental areas of Shared Technology Services activity described in the "Preliminary Overview" of this section of the Program Document, published to the community in February.

The purpose of this draft is to give a revised but still quite provisional sense of the Program Staff's evolving idea of how the Shared Services area of work might be framed. While some developed sense of where Bamboo is headed has been is included in this draft, what's most important at this juncture (March 9-18) is the questions included in each subsection. These are asked in order to encourage expression of your (and your institution's) opinions about most valuable directions to pursue, along with reasoning you can share with the community for your suggestions. Without attempting a quantitative, scientific poll, the Program Staff does want to encourage your input in the brief period before Chad and David (with the help of other members of the Berkeley and Chicago team) begin to pull together evolving pieces of a more complete draft of the Program Document for distribution before and discussion at Workshop 4.  W4 will take place in mid-April in Providence, RI.

A discussion of this draft with the Shared Services Working Group, expected to take place on 11 March, will be an opportunity to suggest additional ideas/input into that first, more complete draft of the "Program Document."

Note: "Program Document" is the working term for the document that outlines and details a range of activities for Bamboo through 2020. A subset of the work described in the Program Document, specifically between 2010 and 2013, will be included in a Bamboo implementation proposal to the Mellon Foundation in Fall 2009.

4.1. Services Atlas

Capsule Summary: The Services Atlas presents community input (Scholarly Narratives, Recipes, Activities, Tool examples, Content/Resource examples, Service Families, Service Candidates, Service Contracts, and extant Services) in easily updated, hyperlinked, annotatable forms that may be mixed, matched, categorized, and re-categorized in order to render the community's understanding of scholarly practice accessible from the multiple perspectives of diverse stakeholders native to Bamboo. Dynamic ability to incorporate and view evolving input and analysis, and quickly and clearly draw connections to broader context, will benefit faculty, librarians, funders, institutional leaders, technical architects, and service developers. These varied views of a changing landscape will enable informed governance by key stakeholders in arts, humanities, and qualitative social sciences scholarship.

A Service Atlas is, for Bamboo's purposes, a collection of information - some general some detailed - that in its expression and linkages permits individuals with different interests, skills, experience, and perspectives to understand the nature and utility of services, their purpose and relevance, and the body of work they are meant to support. A Service Atlas is intended to help funding agencies, university leaders, scholars, technologists, and technology vendors to navigate a large collection of information at the level of detail that will most effectively illuminate understanding from the viewer's or user's perspective.

The Bamboo Services Atlas will fulfill a number of purposes:

  1. Describe Scholarship: Describe areas of scholarship in the Arts, Humanities, and Qualitative Social Sciences that are suited to automation (enhancement or support via software services, including via software services whose function is to provide access to hardware-bound capabilities such as storage or telepresence)
  2. Represent Categorizations: Represent categorizations of services for scholarship appropriate to strategic planning tasks such as prioritization and application for funding
  3. Translate Across Communities: Provide a gateway for Bamboo's multiple communities to nurture trust and understanding by identifying each others' activities and concerns from multiple points of view, and to assure that technology supports scholarly need both as currently conducted and into an evolving future
  4. Identify Services: Provide a vehicle for identifying and characterizing extant services and tools of interest to scholars
  5. Surface Unsupported Scholarly Practice: Provide a vehicle for identifying extant, anticipated, and/or intended practice of scholarship for which automating services and tools do not exist or are not known to Bamboo

Principal qualities of the Bamboo Services Atlas will include:

  1. Description of activities and objects ('verbs and nouns,' or 'steps and ingredients') involved in scholarship.
  2. Support for multiple points-of-entry to facilitate understanding from multiple perspectives.
  3. Exposure of information at multiple levels of detail (or 'granularity').
  4. Provision of accessible, intuitive annotation, search, and discovery mechanisms that open access to audiences with different points of view.
  5. Support for recording and display of the characteristics of Atlas elements that are of interest to diverse communities of its users.




The diagram above is a preliminary concept for how a Services Atlas user interface might look to someone primarily interested in narratives and recipes. Higher level views more relevant to university executives or funding agencies might look more like a hyperlinked version of the Australian National Library's "high level view of a Service Framework".

The Bamboo Service Atlas will be composed from:

  • Community contributions such as the Scholarly Narratives, Recipes, Activities, Tool examples, and Content/Resource examples being collected and recorded during the Bamboo Planning Phase on the project's wiki;
  • Functionality of extant software as analyzed and 'factored' into capabilities and services; and,
  • Functionality of software 'in the pipeline' (i.e., software in some stage of planning, design, or development but not yet in release or use) as analyzed and 'factored' into capabilities and services.

The Bamboo Service Atlas, once implemented, is expected to offer much simpler and more fully facilitated input, update, and hyperlinking capability than offered by the Bamboo Planning Wiki. The goal will be to provide the Atlas in accessible formats that are easily updated, hyperlinked, and annotatable. The Atlas will support means to organize, mix, match, categorize, and re-categorize its constituent elements in order to render the community's understanding of scholarly practice accessible from the multiple perspectives of diverse stakeholders native to Bamboo. Dynamic ability to incorporate and view evolving input and analysis, and quickly and clearly draw connections to broader context, will benefit faculty, librarians, funders, institutional leaders, technical architects, and service developers. These varied views of a changing landscape will enable informed governance by key stakeholders in arts, humanities, and qualitative social sciences scholarship.

Evolution of the Bamboo Service Atlas will occur gradually and iteratively. The collection and recording of information that is occurring in 2008-2009 on the Planning Wiki should be regarded as building an initial body of information to populate the Atlas, and evolving its information architecture. Atlas elements and functionality are expected to be made available through services that may be composed and rendered in a variety of end-user views and tools, such as web browsers, faceted browsers, and scholarly-networking platforms. A primary venue for delivery of the Bamboo Services Atlas will be the Bamboo Marketplace.

Questions to Services Working Group and other reviewers about the Services Atlas sub-section

  • Do scholars at your institution think this this concept can provide value to them and others on their faculties?
  • Do librarians at your institution find this a credible concept for navigating and linking diverse perspectives on inter-related primary material and secondary analysis?
  • Do technologists at your institution believe that linkage of technical materials (service models, service contracts, service endpoints where implementations are actually deployed) to expressions of workflow, procedure, and objects-of-interest as articulated by scholarship-oriented members of Bamboo's community will improve implementations, uptake, or both?
  • Are there examples of information architectures and means of navigating through their varied views that you would suggest as valuable reference points - whether 'good' or 'bad' examples - as a Bamboo Service Atlas is modeled and designed?
  • The term "Services Atlas" is now being proposed as a replacement for "Services Roadmap." The reason for this change is that the currently-conceived content and purpose of this deliverable is broader than what is generally meant by "roadmap" as the term is used by technologists; and suggests something more comprehensive than what is usually understood by non-technologists when they hear the term used in the context of software projects. What do you think of the new term?

4.2. Marketplace of Services

This sub-section ("4.2 - Marketplace of Services") has not been significantly expanded beyond the Preliminary Overview published to the Planning Wiki on Feb 10, 2009. This sub-section will be developed further in the near future.

Capsule Summary: The Bamboo Marketplace of Services will serve as a focal point for information about services, including but not limited to services incorporated in the Service Atlas; and as a venue for exchange between marketplace participants. Incentives to participate in this marketplace will include channels of communication to and feedback from the community of institutions and disciplines participating in Bamboo, as well as an avenue for access to Bamboo's experimental "incubator" service-deployment platform (cf.Local and Incubator Services, below).

The Bamboo Marketplace will seek to aggregate and disseminate information about available services relevant to scholarship in arts, humanities, and qualitative social sciences, from a broad range of providers, but will also acknowledge that no single catalog can describe this space comprehensively. Because services applicable to scholarship have been and will continue to be developed for scholars, projects, disciplines, institutions, et al., outside the auspices of Bamboo, mechanisms will be implemented to automatically harvest public information from service-building or -providing organizations and projects, as well as from other catalogs, in order to make their work and offerings discoverable from within the Bamboo Marketplace; as well as mechanisms that allow service builders/providers to actively and explicitly register information in the Bamboo Marketplace.

Bamboo Marketplace mechanisms for discovery of available services, including but not limited to those incorporated in the Services Atlas, will help scholars identify whether their need is already addressed before they put out a "bid" to technologists who might be interested in filling or helping to fill a gap. These mechanisms will also help technologists identify services that they might compose into new, enhanced service offerings. An exchange system (perhaps based on RFPs  - Requests for Proposals - or other auction mechanisms) will enable people who need services developed to identify them, and people who want to build or provide services to share or sell them.

Mechanisms in the Bamboo Marketplace will seek to track usage of developed services, and provide for collection of feedback; these data will be modeled, collected, and presented in ways that are meaningful to scholars and to technologists.

The Bamboo Marketplace is expected to be supported by services developed or adapted, then deployed by, Bamboo Partners (cf. Common Services, below); and made available in the form of plug-ins and/or widgets based on open interface standards that allow the Marketplace to be easily incorporated into and presented/used within existing portal, virtual research environments, or other aggregation and/or research workflow systems and tools.

Adherence to development guidelines and standards for data/content interoperability will be encouraged by incentives to build services more likely to become Bamboo "Common Services," such as the opportunity to deploy services that evolve outside Bamboo in a "Bamboo Incubator" (cf. Local and Incubator Services, below). There may be minimum constraints for participation in the Bamboo Marketplace, such as open source software licensing. Another key question will be whether and how any notion of "membership" in a Bamboo, higher education, or other community comes into play.

4.3. Local and Incubator Services

Capsule Summary: Working services that are not yet refined and offered as "common" may be provided from local or regional deployments by Bamboo institutions, and listed with appropriate descriptors of service quality (SLA, Service Level Agreement) in the Bamboo Marketplace. A deploying institution or group of institutions would be wholly responsible for availability and maintenance of such services; Bamboo as a consortium would make no guarantee regarding these limited or experimental deployments. Services deployed in Local and Incubator contexts are considered to be potential candidates for refinement, standardization, and adoption as "Common Services."  Services deployed in these contexts may originate in the work of Bamboo member-institutions, or in the broader universe of service builders; it is the latter case that comprises Bamboo Incubator Service deployments, which will generally be segregated into a separate and parallel deployment context from services that originate in the development efforts of Bamboo members.

Recognizing that a world of tool and service development has occurred, is occurring, and will continue outside the formal auspices of Project Bamboo, and that innovative development and use of software is likely to occur at the edges and beyond the borders of Bamboo's processes for normalizing characteristics, standards-compliance, and deployment requirements of software services, Bamboo will make explicit provision for its partners to offer, from within a Bamboo context, services for scholarship at levels of availability and refinement that fall outside a definition of "Common Services" (see below).

Services that are not "Common Services" but are offered by Bamboo partner institutions and organizations:

  • may be listed and linked to other elements in the Bamboo Service Atlas, and accessed via the Bamboo Marketplace;
  • may be deployed in a standard "Bamboo Appliance" if the service meets some minimal alignment to Bamboo deployment infrastructure (see #Glossary and Sec 4.3 - Common Services); or on some other infrastructure operated by the host institution or organization (a less-preferred alternative once a "Bamboo Appliance" is available);
  • will not be supported by any consortial guarantees of quality (Service Level Agreements, SLA);
  • will express the level of service quality that is guaranteed by the host;
  • may originate in service development work done by a Bamboo Member or by others;
  • will, if the service originates in work outside the community of Bamboo Membership, be deployed in a separate and clearly differentiable "Incubator" context;
  • may utilize compute, storage, and network resources within the service-hosting infrastructure; or may "wrap" requests for resources provided elsewhere;
  • will require some form of identification (e.g., user or application ID) in order to track usage and facilitate notification of service outages or other changes; and,
  • will be made available to scholar-users without membership-related restrictions - that is, scholars affiliated with institutions or organizations who are not involved with Project Bamboo, and (tentatively) scholars not affiliated with any institution or organization.

Bamboo Members involved in Explore and Plan layers of activity may identify services and service-providers evolving independently of Bamboo that are of 'preliminary interest'; and may invite deployment in an "Incubator" context that offers exposure to the provider/builder and opportunity for exploration to Bamboo's community of scholarship. Local and Incubator deployments are avenues by which services may be identified - through exposure, experimentation, and observation of scholarly usage - for possible selection as candidates for refinement, standardization, and adoption as "Common Services." At least initially, no cost-recovery model is assumed to be available in the provision of services deployed in Local and Incubator contexts. Therefore, it is reasonable and expected that limits will be imposed on the quantity of resources that may be consumed as these services are utilized. Such limits will be an explicit element of SLAs associated with these service deployments.

Questions to Services Working Group and other reviewers about material in this sub-section

  • One idea (that goes beyond listing in a Services Atlas) for incenting service providers to engage with and align to a Bamboo Marketplace is "incubator deployments." What other incentives might Bamboo offer, especially ones that leverage scarce resources?
  • As currently written, this sub-section draws a line between services developed by a Bamboo Member institution or organization and those developed by others as a way to differentiate services deployed in "Local" versus "Incubator" contexts. Is this the right place to draw that line? If there are better differentiators, what might they be and why is the distinction they make more useful?
  • For Bamboo Members whose institutions are not hosting services, what avenues should be available for identification/nomination of services to be deployed in Local and/or Incubator contexts?


4.4. Common Services

Capsule Summary: Services of foundational or broad utility may become candidates for refinement into "Common Services."  Service interfaces that have been refined through a process of architectural modeling, design, alignment to applicable standards, and coordination to maximize interoperability, then developed as reference implementations, will be considered "Common Services." As such, they can and will be deployed for use by the global community of scholars by Bamboo member institutions in a redundant, distributed network of Bamboo Appliances that comprise a Bamboo Cloud. These services will include those that enable core digital infrastructure of the Bamboo Community (the Services Atlas and its component entities; and the Bamboo Marketplace, including its elements). Additional services will deliver direct support to scholarship by automating workflows (recipes) that add value to the arts, humanities, and qualitative social sciences. Some classes of service will provide resources delivered directly from servers operated by Bamboo member institutions; while others will wrap (call) or refer to compute, storage, and/or service-delivery resources operated by others. Service Level Agreements for services offered from the Bamboo Cloud, as well as those for underlying services hosted elsewhere, will be clearly articulated to service consumers.

Common Services deliver qualities that the Bamboo Consortium guarantees.  These will address stability, availability, composability (i.e., usability in multiple workflow contexts), standards-compliance, scalability, and robustness. Architectural coherence, intended to forestall problems that would otherwise follow from a scatter of arbitrary decisions (not related to delivery of functionality) that might reasonably or unreasonably be made if development is not constrained by architectural principles and standards orientation, is also a key quality of Common Services. With the exception of services deployed in close proximity to distributed tools or content, Common Services are expected to be deployable on a standard Bamboo Appliance for service-delivery (see below and #Glossary). Common Services will support or permit usage tracking (technical and functional), and add value to scholarship in the arts, humanities, and qualitative social sciences. A fundamental aspect of the commonality of "Common Services" is their composability into multiple workflows ("recipes") and interoperability with one another.

Once a service is accepted at the Bamboo Plan layer as a candidate, there is a set of refining activities that must occur before it is capable of delivering the qualities enumerated above, and is considered a "Common Service." The current draft of this document does not attempt to enumerate these activities.

Services of foundational or broad utility may be proposed for "Common Service" candidacy by Bamboo Members. A usual path to candidacy includes evolution of a service to a point where it is deployed, used, and studied in a Local or Incubator context (see Local and Incubator Services). Bamboo Members with responsibilities in the Plan areas of work will actively seek to identify candidates from services emerging in the larger world of digitally-enabled scholarship, as well as within Bamboo Marketplace, Local Services, and Incubator Services contexts. Anyone may propose a service or set of services to Bamboo as potential candidates. Services emerge as candidates for refinement into Common Services because they:

  • are foundational or of broad utility;
  • abstract or may, with relative ease, be refactored to abstract basic/utility functions and entities (such as authorization or persistence functionality; and entities representing a person or organization);
  • separate generally-applicable functionality from that which is specific to particular domains or corpora;
  • exist already, fit well within, or may, with relative ease, be refactored to fit well within loosely-coupled architectures;
  • already or can, with relative ease, be refactored to run atop stable, well-supported open-source technology stacks;
  • are implemented using good coding and documentation practices; and,
  • take and return standards-compliant input and output, or can, with relative ease, be refactored to do so.

Some classes of Common Services will provide resources delivered directly from servers operated by Bamboo member institutions; while others will wrap (call) or refer to compute, storage, and/or service-delivery resources operated by others. Service Level Agreements (cf. #Glossary) for services offered from the Bamboo Cloud, as well as those for underlying services hosted elsewhere, will be clearly articulated to service consumers.

An initial set of Common Services will enable core digital infrastructure of the Bamboo Community (the Services Atlas and its component entities; and the Bamboo Marketplace, including its elements).

A "Bamboo Appliance" for service-delivery is expected to evolve as a standardized (probably virtual) server provisioned with a technology stack on which services may be deployed and made available for consumption. A number of distributed Bamboo Appliances will respond to service requests addressed to and routed from a Bamboo Cloud, via a mechanism that provides load-balancing, fail-over capability, and diagnostics of the "health" of constituent appliances. Bamboo Members active in the Plan layer of the consortium will be responsible for defining the architecture and technology requirements for this appliance; Bamboo Members active in the Build layer will be responsible for implementing, testing, distributing, and maintaining it.


The diagram above is a very preliminary, rough, and tentative conceptual model of a set of Bamboo Appliances comprising a Bamboo Cloud. Reviewers are advised not to read it too closely, and, especially, to ignore the TLAs (three letter acronyms) in the cloud...

Questions to Services Working Group and other reviewers about material in this sub-section

  • Do you have any suggestions for terms that distinguish services that are software from services that are help/support/consultation/work-performed?
  • Are the qualities of Common Services listed in the first paragraph of this sub-section a good set to start with - not as a canonical set to which Bamboo must now commit, but as a set from which the Plan layer of Bamboo can begin to shape its agreements about what "refinement" really means? What's missing? What doesn't belong?
  • How easy or hard will it be to assemble, distribute, maintain, and evolve a service-delivery "appliance" - a virtual machine "loaded" with technology needed to deploy services - and how long will it likely take to get an initial "appliance" up and running?
    • Will one "appliance" be sufficient to deploy the range of services in question? Or do we need more? If more, what are their different characteristics, or the differing characteristics of the types of services they deliver?
    • What's a seat-of-the-pants estimate for a workable amount of CPU, memory, storage, and bandwidth that might be necessary to provision such an appliance (recognizing that at the current level of definition it's anybody's guess ... we're looking to average more guesses here!)?
    • What is or should be the relationship between an "appliance" that delivers web services, and one that delivers a set of fundamental, general tools (e.g., Fedora Commons or DSpace instantiations; Heurist or Zotero server instances; etc.) to institutions?
  • Is the concept of distributed "Bamboo Appliances" linked together to deliver services from a "Bamboo Cloud" a coherent, understandable, and achievable 'story'? What needs to be articulated more clearly or fully? What, if anything, strikes you in this story as undeliverable within the first half of Bamboo's Phase I implementation (i.e., by mid-2011)?
  • For "Common Services" to represent real value to your institution, organization, or discipline, what initial, minimal capabilities would be required?
    • Would delivery of the Bamboo Marketplace (including the Service Atlas and a multiplicity of views of its component parts) and Scholarly Networking capability be sufficient as a first stage? If not, what more would represent real value to your institution?
    • When would your institution, organization, or discipline need to see delivery of this initial set of Common Services to consider Bamboo a worthwhile endeavor?

4.5. Architectural Alignment Partnerships

Capsule Summary: Bamboo will partner with interested tool and application projects and developers to wrap and/or deliver functionality (automation capabilities) as services that can be deployed alongside, and interoperate with, Bamboo Common Services. By exposing capabilities from other projects and providers as Bamboo-affiliated services, broader and more diverse uptake of those capabilities is more likely; such exposure will also enrich the pool of service candidates being considered for refinement into Bamboo Common Services. These partnerships will deepen and broaden the Bamboo ecosystem with expertise and experience rooted in domain- and function-centric communities.

Some of the most fertile ground for development of automation capability in arts, humanities, and qualitative social science scholarship to date has been in discipline- or tool-focused communities and projects, such as (but in no way limited to) ARTFL, MONK, the Perseus Digital Library, SEASR, and Zotero. As the technology landscape evolves toward delivery of decomposed functionality as services, some discipline- and tool-focused projects will likely be interested in delivering their capability in an architecture congruent with Bamboo's. This will present opportunities for partnership.

In collaborative negotiation with projects whose valuable algorithms and implementations can be enhanced by alignment and partnership with Bamboo architecture, mutually beneficial incentives will be defined and exchanged to best advance scholarship as a whole in the arts, humanities and qualitative social sciences. Broader and more diverse uptake of partner-delivered capabilities is a likely incentive Bamboo can offer. In the other direction, Bamboo will benefit from enrichment of the pool of service candidates being considered for refinement into Bamboo Common Services, and from an ecosystem deepened and broadened by expertise and experience rooted in domain- and function-centric communities.

Questions to Services Working Group and other reviewers about material in this sub-section

  • The list of community and project examples in this section was drafted casually, without careful research or attention to disciplinary or functional breadth. What examples might round out this rough first attempt?
  • Some incentives to service and tool builders outside Bamboo are listed, as are some for Bamboo. What are others, for either or both of the participants in these partnerships?


4.6. Content-Services for Interoperability

Capsule Summary: Bamboo will partner with interested content (digital resource) providers to enable Bamboo Common Services to discover, search, and appropriately operate on their diverse and distributed holdings. Similarly, partnerships with interested repository platform providers will enable Bamboo Common Services to discover, search, and appropriately operate on resources hosted on platforms of strategic value to communities of arts, humanities, and qualitative social science scholarship. These efforts will likely take the form of modeling, implementing, and deploying service interfaces to expose strategically identified content stores and platforms. Bamboo-facilitated exposure of content via service interfaces will broaden uptake and trans-disciplinary opportunities for scholarship, as well as suggest additional candidates for refinement into Bamboo Common Services.

Objects of scholarly interest - "content" or "digital resources" in a world of bytes and networks - are the gravitational centers around which much or most scholarship in the arts, humanities, and qualitative social sciences orbits. Improving the ability of scholars to discover, inquire of, compare, integrate, decompose, and re-integrate objects of interest that reside in diverse repositories, as well as to digitize and store additional objects-of-interest, are fundamental goals of cyberinfrastructure in the academy, and key interests expressed by many participants in Bamboo workshops and in other venues - from blogs to white papers - focused on what IT can do for scholars.

Bamboo will therefore partner with library, archive, and repository partners, and those who deliver platforms on which digital repositories are hosted and accessed, to collaboratively develop interfaces and content-transformation services that will maximize exposure of unique features of diverse partners, while leveraging commonality or similarity to broaden the field of inquiry and operation over diverse and distributed content repositories.

Questions to Services Working Group and other reviewers about material in this sub-section

  • What are incentives for libraries and archives to expose their holdings via common interfaces that permit combination (or "mashup") with others' holdings?
  • What are the barriers that inhibit libraries and archives from exposing their holdings via common interfaces that permit combination (or "mashup") with others' holdings, and how might they be addressed by Bamboo?
  • What are directions Bamboo can pursue to deepen sharing beyond the lowest-hanging fruit (e.g., beyond "simple" Dublin Core)?


Glossary

This quickly-assembled glossary explains some of the terms used in this draft. A more formal and fully vetted glossary will be part of the draft Program Document considered at Workshop Four, in April 2009.

  • Activities - Steps (units of work, process, or procedure) that occur in the course of tasks or workflow that comprise scholarship.
  • Application ID - An alphanumeric string or other token of identification that ties usage of a service to another piece of software, such as a service or application.
  • Bamboo Appliance - Shorthand for a 'service-delivery appliance' - a standardized (probably virtual) server provisioned with a technology stack on which services (e.g., web services) may be deployed and made available.
  • Bamboo Cloud - A collection of service-delivery 'applicances' (cf. Bamboo Appliance in this glossary) that collectively and redundantly, using load-balancing and fail-over mechanisms, hosts Bamboo Common Services (cf. 4.3 - Common Services, above)
  • Capability - In a service, a piece of logical functionality that the service delivers.
  • Common Services - Cf. 4.3 - Common Services (above)
  • Narratives - Cf. "Scholarly Narratives" in this glossary.
  • Operation - A call that can be made to a service to execute some piece of work, with formally defined input, output, and error messages
  • Recipes - Recipes describe how to achieve goals using information technology. Recipes are written for scholars and describe the tools and steps needed to complete a task in non-technical language. In short Recipes are built on the stories academics tell about what they want to do by generalizing to shared tasks and they allow Bamboo to organize technology to support those tasks.
  • Scholarly Narratives - Expression of particular aspects of scholarship, scholarly workflow, research, and/or teaching from a scholar's perspective, and in her own language.
  • Service - A unit of software that implements functionality (capabilities) that has (have) been decomposed in order to facilitate combination and recombination with other services in support of multiple tasks or workflows.
  • Service Atlas - A collection of information - some general some detailed - that in its expression and linkages permits individuals with different interests, skills, and perspectives to understand the nature and utility of services, their purpose and relevance, and the body of work they are meant to support.
  • Service Candidate - A grouping of capabilities modeled as a set appropriate for designing and implementing as a single service.
  • Service Contract - A formal expression of Service Design (i.e., operations and message structures, as well as additional information and parameters necessary to execute operations offered by a service).
  • Service Design - The operations and message structures (input, output, error), as well as additional information and parameters necessary to execute operations offered by a service.
  • Service Endpoint - The location (generally on a network, such as the internet) where an existing, operating service can be accessed (called) in order to request delivery of its functionality.
  • Service Level Agreement - An agreement describing a measurable level of service guaranteed by a service provider to a service receiver.
  • Service Model - A rough expression of capabilities that a service is expected to offer; less detailed than Service Design.
  • Service Families - A group of related services.
  • SLA - Cf. Service Level Agreement, above.
  • User ID - An alphanumeric string or other token of identification that ties usage of a service to an individual (whether anonymized or not)
  • No labels

8 Comments

  1. Unknown User (mspalti@gmail.com)

    In the capsule description for 4.1 we say:

    will benefit faculty, librarians, funders, institutional leaders, technical architects, and service developers

    In the following paragraph the list changes to:

     to help funding agencies, university leaders, scholars, technologists, and technology vendors

     Both lists are accurate, although the order of the first version is bottom-up and begins with the faculty (scholar/teacher) while the second begins with (national and international) funding agencies and proceeds later to the individual scholar and technologist.   To the extent that order matters, perhaps the two lists should parallel each other more closely.  How one prioritizes audiences also has a effect in designing software services.

    Mike

  2. Unknown User (masover@berkeley.edu)

    Here are my notes from a group discussion of 11 Mar 2009. Names (other than my own) have been anonymized.

    • Steve discussed/summarized the current (new) draft of what is now Sec 4 for about 12 min ...
    • E: likes 4.5 & 4.6, strong additions, likes Atlas instead of Roadmap
    • A:
      • biggest concern about service-atlas is that it might not be as user-friendly to scholars as one might hope
      • e.g., a diagram like the one for Australian National Library not friendly to scholars, it's just another wedding cake
      • Steve: think of the ANL diagram as something of interest to funders and university administrators more than scholars ... that's how it's called out in the document text.
    • D
      • this is easier to react to than last version
      • re: the Services Atlas purposes list:
        • is the numbering significant? (4 2 3 5 1 is this participant's preference)
          1. Identify Services is really the #1 item here ... might it be "identify tools & services"
          2. Represent categorizations might be #2, as it falls out of the concrete services
          3. Translate is a good #3
          4. Surface Unsupported ought to be #4 ... in part because "Describe..." ought to be last
          5. Describe scholarship ought to be last ... but be careful what you call it ... it sounds comprehensive, which doesn't give the right impression
        • is the purpose here to discover new practices? it's not the first thing people look for. not even sure that this collection of things is the place to assume or hope or announce that we'll be doing this ... it may take form in here, but it's a different kind of querying or question, but maybe it'll also come out of articles, MLA list of practices, other kinds of efforts happening outside Bamboo
    • C
      • Isn't it problemmatic to place "Describe Scholarship" at the end? The problems really happen when the community of users isn't consulted early on.
      • Then Unsupported emerges from the end of the process
    • D: Is describe "practice" a better term than "scholarship"?
      • C likes this too ...
      • Describe activities that make up scholarly practice ... make sure that this section doesn't look like close description of particular areas of scholarship, instead it should look like describing activities that are suitable for automation
    • C - there's describe, and there's also "transform" scholarly practice ... it's important that this aspect be called out, be apparent in the document
    • A: 4.5 title could be clearer - to be "tools and application partnerships" - not apparent from "architecture" in the title... 4.6 perhaps "content partnerships" or "content interoperability partnerships"
    • A: questions about Marketplace ... is it a thing, a website, an online service? What's in and what's out of Bamboo? Once that's clarified, the question of whether Local and Incubator deployment contexts ought to be separate or ought to be merged.
    • D - MERLOT is not very useful. One has high hopes that you're going to get information, that you're going to get something you can use, but it's quite disappointing in the actual event. There are others to consider, will write a list. LOLA has good content, but not necessarily great categories ... it's in some respects a reaction to things like MERLOT.
    • F: e.g., cnx.org for content connection ... interesting model ... spotty, but interesting conceptually, based on Creative Commons licenses
    • E: local and incubator ... will incubator be provided by a Build Partner, but be available to the community? Steve: yes, that's the idea, with some level of invitation / vetting / conformity to a standard deployment infrastructure
    • F: worth looking at the SAKAI community of development as a developer/consumer "marketplace" ... how different little apps are created by different institutions all over, and they grow up into part of a core service as part of SAKAI if and as they prove interesting to the broader community.
    • D: are Common Services "foundational or broad"? or are they characterized by those more enterprisey terms in the paragraph following the "Capsule Summary"? Not exactly clear. Steve: yes, a bit hazy ... my hope is that we'll clarify better questions about what level of a "wedding cake" type stack we might be talking about (utility, agnostic, task, for example, as in the W2 wedding cake), and also to describe what qualities might be outcomes of the refinement process that renders a piece of software a "Common Service" ... Bamboo-certifiable, or whatever that turns out to mean
    • E: is "foundational" a level of a stack? or is it of foundational interest to A&H scholarship? clarification of and distinction between these ideas would be helpful.
    • D: Where does the word 'tools' come in? Scholars aren't going to use services in the technical sense of the word. They're going to use things that are built on top of services. In a marketplace there's a mixture of stuff that goes to different audiences ... so it might be interesting to tease out who is interested in what and where they find it ... perhaps that's a part of the marketplace that's not as well defined in this draft
  3. Unknown User (elli_mylonas)

    After a brief discussion with some of the group at Brown, we have some feedback to the program document that was discussed on the phone call on Mar. 11.  This is not a comprehensive set of feedback, and I have tried to make sense out of my discussion notes.
    On the whole, this document was well received, the ideas seemed good to people, at least as I managed to represent them. Section 1 is amply commented below. The sections on services seemed to make sense. A point Steve said was raised by others was also raised here: where are the tools? Services usually underlie tools, tools are the actual interface. Not clear who provides and so on. The Marketplace could use more clarification.

    This is a response to some parts of Part 4 of the Program document.

    4.1 Services Atlas:

    "Describing Scholarship" The discussion on this topic paralleled points made during the 3/11 phone call.

    Specifically: scholarship in the humanities is a broad activity, and the problems scholars are grappling with are abstract and theoretical. Digital tools and methods are a small part of the arsenal of the humanist, and are often deployed at early stages (information gathering) or late stages (publication). Humanists don't set out to quantify something or to visualize or annotate it. They set out to understand a text in relation to the society which produced it, or to count military graves in different parts of the Roman empire as a way to understand social change and mobility. We hope to make digital tools more accessible, easier to use, easier to develop and support and to discover new uses and new tools. This is very important and useful, but we mustn't forget that the ultimate goal for the humanist is to work on the problem they've selected.

    This sounds almost like a luddite reaction to DH, which is strange from a group that works every day on that very topic. Bamboo has to be careful with sentences like "Describe Scholarship" however. It trivializes the work and impact of the humanities. Our aim is to do a better job of supporting appropriate aspects of research in the humanities.

    "Represent Categorization:"

    Our group felt that categorization of projects, tools and methods would work best if it was "folksonomic" and came from the participants. This is a useful and interesting activity, and a way to really figure out what the community thinks it's doing!  Rigid categorization schemes, like the ones that are formally developed and require extra effort to change or supplement, can lead to a simplificaton of a domain. In scholarship, often it's useful to know how things are different from one another, as well as how they are similar.

    Funding and prioritization that are based on categories may end up ignoring significant differences among seemingly similar things. So, categorization seems useful, but identifying it as a criterion for validation seems arbitrary. A corollary to this thought is that imposed categories tend to be normative. Scholarship is about the exploration of new and different things.

    The ICT methods network (http://www.arts-humanities.net/) has made an attempt to categorize DH activities.

    Translate Across Communities: this resonated, and felt like a very important and needed contribution to the community.

    Answers to the Questions:

    *  Do scholars at your institution think this this concept can provide value to them and others on their faculties?

       Not necessarily of transcendent value.  It may be of more value to the technology/support staff, or to people whose work life revolves around the digital. Value is about competition for time and attention. Is something worth the startup time? See discussion above about what humanists are really working on. A place where examples/comparanda are gathered will be accessible to a larger audience, certainly. But it may be their support people (graduate students/library/staff) who actually use it.

       We also discussed the issue of some kind of peer review and expert review? Where does expertise live in this system.  How about curation? Amazon reviews are very useful, but that's because there are so many of them. What's to stop bad applications/solutions from being posted? Bad applications may even look like popular methods, because more than one person has tried them. (the most widely used solution isn't necessarily the best one)

       The Atlas is likely to be of immediate relevance to people in a support/implementation role. Faculty are trained to consult experts in other domains, not only in technology, but other areas of scholarship.

       Bamboo and the Atlas need to be careful of finding themselves in the role of  "source of all knowledge" or being thought to strive for that role. Totalizing systems end up being fragile and vulnerable, the Atlas doesn't want to have those problems.

    * Do librarians at your institution find this a credible concept for navigating and linking diverse perspectives on inter-related primary material and secondary analysis?

       Run of the mill librarian: if it's folksomic, they won't like it. If it's taxonomic, they'll like it, but would want to have authority over it. Librarians have an interest in being the gatekeepers for the organization of scholarly resources, which extends to digital resources in the changing library landscape.

       It's even possible that some librarians might react to by wondering why we can't just catalog services and make them available through the library catalog. This isn't likely to come from the Bamboo friendly librarians.

      The totalizing question in library terminology - Is Bamboo making a union catalog for primary sources? What about the "critical corpus?"

    * Do technologists at your institution believe that linkage of technical materials (service models, service contracts, service endpoints where implementations are actually deployed) to expressions of workflow, procedure, and objects-of-interest as articulated by scholarship-oriented members of Bamboo's community will improve implementations, uptake, or both?

       Discussions here seem to indicate that they are an important audience. Information from the Atlas may improve implementations that suffer from lack of standards and so on.

    * Are there examples of information architectures and means of navigating through their varied views that you would suggest as valuable reference points - whether 'good' or 'bad' examples - as a Bamboo Service Atlas is modeled and designed?

       Atlas is the RDF layer (ex: FOAF).
       Ravelry - a very effective social site for knitters comprising discussion boards on technical issues as well as social issues, and well planned ways to enter patterns, yarns, show examples of projects using a pattern with a particular yarn, etc. Value is that the providers (yarn companies) have a vested interest to keep their yarn catalogs up to date. so information is available and current.
       Merlot - tries to be the go-to place, but it's hard to find things.
       Intute - "Intute is a free online service providing you with a database of hand selected Web resources for education and research." http://www.intute.ac.uk/Hard to find things because the contents are varied, creating and maintaining it takes a lot of time and effort on the part of the staff. It contains authoritative information. See for ex. a detailed record in the db.
       cpan, ruby gem, fink - registries, make getting and installing easy, especially Ruby Gem.
       sharepoint - some implementations try to mix social networking with content. They are  very difficult to navigate if they are representing complex structures (not optimized for first time use), but their goal may be useful.

    * The term "Services Atlas" is now being proposed as a replacement for "Services Roadmap." The reason for this change is that the currently-conceived content and purpose of this deliverable is broader than what is generally meant by "roadmap" as the term is used by technologists; and suggests something more comprehensive than what is usually understood by non-technologists when they hear the term used in the context of software projects. What do you think of the new term?

    Atlas is better than roadmap. Sounds good.

    Answer to Questions from other parts of section 4:

    * Do you have any suggestions for terms that distinguish services that are software from services that are help/support/consultation/work-performed?

       how about 'support services' 'web services' and so on. Also 'tools and services'

    *  What are incentives for libraries and archives to expose their holdings via common interfaces that permit combination (or "mashup") with others' holdings?
    * What are the barriers that inhibit libraries and archives from exposing their holdings via common interfaces that permit combination (or "mashup") with others' holdings, and how might they be addressed by Bamboo?
    * What are directions Bamboo can pursue to deepen sharing beyond the lowest-hanging fruit (e.g., beyond "simple" Dublin Core)?

    A lot of this is already happening in libraries with digital programs (i.e. the libraries that have digital corpora to share). Bamboo should link up with library digital initiatives. See for example jangle (http://www.jangle.org/spec/1.0). An promising effort to use atomPub as a way to expose library resources. This work is coming from the library community. A good place to follow these discussions may be code4lib.
    (http://www.code4lib.org/).

    This is something that libraries are good at. Bamboo needs to piggyback.

  4. Unknown User (khayne)

    Thanks for all your work on this. From a scholar's perspective we are generally happy with the revisions, just some brief comments:
    1. the diagrams in the first draft were good - could they be updated to fit the new document with a similar level of abstraction?
    2. we are not sure about the term "Service Atlas" although think it's a good concept and don't want to get too bogged down in terminology. To engage scholars maybe it needs a name that invites participation. Any ideas out there?

    1. Unknown User (masover@berkeley.edu)

      Thank you, Katie.

      The original graphics were my own clumsy efforts ... I'm now talking with a much more graphically-talented Program Staff member than I am about developing graphic abstractions meant to be similarly helpful – only more so ( (wink) ). I hope the preliminary results, at least, will be available by the time the "version 1" draft of the Program Document is released in early April, and perhaps even sooner.

      On the "Atlas" question, given that it will certainly include elements that are the direct contributions of scholars (contributed through whatever long-term mechanism is established to collect what we're now calling "scholarly narratives"), is your suggestion that looking for other scholars' materials in something called an "Atlas" does not seem inviting or interesting? Would it help to consider that the "Atlas" is conceived (if not well-described in this draft as) an "under the hood" mechanism to which access will be possible in a variety of forms/tools/environments - and those might be called anything at all that is helpful/inviting to those who use it?

      1. Unknown User (khayne)

        My hope from the 'Service Atlas' is that it would provide for the scholar/developer/manager a sort of global one-stop-shop for digital humanities tools, services and advice. In time it would be great if it even recommended groupings of tools&services that fulfill a particular research need or workflow - recipes of common services and not so common if this is possible? If I have understood the concept I think you've got all this covered! Maybe it doesn't matter too much what it is called, especially as you say it is the 'under the hood' concept. If the entry points are user friendly enough, by "exposure of information at multiple levels of detail" (this is important), hopefully people would engage.

        I like Judith's suggestion of a background section that defines what Bamboo means by scholarly narratives, recipes and activities. I imagine a non-technical person from outside Bamboo reading this document might be confused between what is Bamboo specific terminology and what is more generic IT language. Alternatively in your glossary you could add something like - a term developed by Bamboo in the Bamboo workshops.

        Thanks Katie

  5. Unknown User (pearce.judith@gmail.com)

    In the overall program document, will there be a section that looks at the state of knowledge of scholarly practice and also other efforts to model this in the form of shared technology services? Otherwise, this section needs a background section that defines what Bamboo means by scholarly narratives, recipes and activities and how this maps to other ways of modelling business processes, workflows and technical services.

    In relation to this, I have just read this OCLC report  -'Scholarly Information Practices in the Online Environment Themes fromthe Literature and Implications for Library Service Development' (http://www.oclc.org/programs/publications/reports/2009-02.pdf). It goes back to Unsworth and ends up defining five core scholarly activities and their 'primitives' and a sixth set of cross-cutting primitives. It would be useful to return to the set of keywords we have been using to classify the stories and activity definitions (https://wiki.projectbamboo.org/display/BPUB/Activity+Definition+Keywords) and to see how these map to other ways of classifying scholaly activities in the literature. Folksonomies are useful research tools for gathering the terms used by people to describe similar concepts, but at some time these need to be mapped to common concepts to achieve the benefits of a controlled vocabulary. Bamboo is in a good position to build on research already conducted in this area.

    The scholarly primitives in the OCLC review are still not activities in the shared technology services sense. They describe business processes or workflows. In fact, you could see them as highly abstracted recipes. Understanding this helps to understand what Bamboo means by a services atlas.The shared technology services are ingredients in the recipes (or service genres or expressions in service usage models, to use e-framework terminology).

    Clearly, a lot of our activity definitions are really recipes describing business processes or workflows and we still need to drill down and find the core technical services needed to orchestrate the worklow.The services atlas needs to expose these technical services, in contexts that help to identify pain points encountered by scholars trying to work on their selected problem, and therefore the work that needs to be done to enhance existing tools or build new tools that eliminate these pain points, resulting in greater efficiencies and effectiveness or new ways of doing things.

    The wedding cake or brick wall diagram is probably not the best way of representing these services because they are ubiquitous and can be used or re-used in many workflows. On the other hand, dozens or hundreds or thousands of recipes will not help to expose patterns and core recipes (or service usage models.)  In this context, it will be important for scholars to have a basic understanding of what a shared technology service is, and the role it plays in the orchestration of workflows. Similarly, business analysts and developers need to understand the business requirements to be addressed. And funding bodies and program managers.need to be able to see at a glance what benefits will be achieved by addressing a particular set of priorities.

    So I see a section of the program document as having a pedagogic role.

    1. Unknown User (masover@berkeley.edu)

      Judith (and Katie) -

      One of the appendices of the Program Document will be a Planning Phase deliverable that we've been calling "Understanding Scholarly Practice" - it is called out on the v 0.1 Program Document outline as Section 6.1, "Scholarly Practices." Arno Bosse, of the University of Chicago, is leading the effort to produce this document, which will describe lessons learned in the early phases of the Bamboo Planning Phase, and refer forward to some of the narratives - recipes - activity definitions (etc.) work of the more recent period. Similarly, some incarnation of what we mean by a "Services Atlas" (though presumably not the fully realized, automated, service-enabled incarnation described above) is called out as Section 6.2, the "Services Atlas" appendix to the Program Document - and here we'll likely say a great deal more about what we mean by each of our more Bamboo-centric terms (e.g., what we mean by "recipes"), and how they relate to more generally understood terms (e.g., workflows and business processes).

      All that said, I think the "pedagogic" element to the PD is quite a valid - and possibly new - element to consider. I would like to see how the first and second sections of the document as currently conceived - that is, "Vision" and "Scope of Work" - look before I develop an opinion on the "newness" question ... it may be that David and Chad, who are writing those sections, will address some of the definitional and context-setting concerns you're raising there. If not, I would certainly agree that that 'translation across communities,' contextualizing material does need to be introduced into the Program Document.