Navigation:
Documentation
Archive



Page Tree:

Child pages
  • v.0.2 - Bamboo as a Facilitator and Developer

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

Skip to end of metadata
Go to start of metadata

WORK IN PROGRESS

This is an outline for a possible 7-10 year vision for the Bamboo Community. The purpose of this document is to provide information to institutions and organizations participating in the Bamboo Planning Process so that they can help determine (1) the long term future of Bamboo and (2) define what activities Bamboo will carry out in its first, 3 year Implementation Phase (from 2010-2012). This document is designed to solicit community input, and is a draft in progress. It is not yet a commitment to carry out all or any of this work.

Please note that we are updating this document frequently based on wide ranging input from the Bamboo community. These updates will occur about every 7-10 days and are indicated as ".1", ".2", ".3", etc updates. In addition, we will occasionally make major document revisions. These are noted as "1.X", "2.X", and so forth. Between major document revisions there may be some inconsistencies in language used between the sections of the document.

4. Bamboo as a Facilitator and Developer of Shared Technology Services (Cyberinfrastructure Ring II)



Table of Contents


4.0 - Introduction

While the term 'service' may be used to describe a broad or general operational capability (e.g., a social bookmarking service, an interlibrary loan service, an e-mail service, an academic computing support service, or other forms of technical expertise), the term is used in a narrower sense in this section of the Bamboo Program Document. Services, in the sense intended here, are relatively small units of software that deliver a set of capabilities grouped to most flexibly facilitate (a) interoperability with other software and/or digital content; and/or (b) combination and recombination with other services in support of multiple tasks or workflows.

Services are usually "under the hood" components of digital tools or applications with which a person engages directly. Tools and applications are relatively larger aggregations of software, and may be composed partly or wholly of services. A familiar example might be Google's mapping service, which is accessed by programmers and web page designers using the Google Maps API (Application Programming Interface). Those who use Google mapping services to find their way to a restaurant or an archaeological excavation or a conference on 18th century French literature might use a web browser (a tool) to view a web page (a digital resource created for display using the tool) that calls on the Google Maps API to display the portion of the page that is a map; the service API exists at some remove from the user's perspective (i.e., "under the hood"). Similarly, the services described in this section may be closely related to or integrated with tools, but are not end-user oriented tools themselves. This document's Section 3.4, "Tools and Content Guide" further describes Bamboo's relationship to digital tools and content sources that are closer to the practice of scholarship than "services" in the sense intended here.

This Shared Technology Services section of the Bamboo Program Document begins with two sub-sections that address the "under the hood" character of services.

First, the Services Atlas will be a mechanism to link these "under the hood" elements to things that are more familiar to those who seek technology that benefits scholarship. Faculty and librarians in the arts and humanities disciplines, with the exception of those who have particular interests in the nuts-and-bolts of technology, are generally less concerned with "services" per se, and more concerned with tools and digital content; with the way tools and content can be applied to the constituent steps or activities of scholarship; and with the larger concepts, issues, and goals of scholarship. The Services Atlas is intended to serve as a bridge between levels of detail and perspectives native to Bamboo's multiple communities, so that scholars who wish to explore the technologies they use or contemplate using can trace from descriptions and artifacts that are familiar, all the way into the detailed models and specifications that are usually of most interest to technologists. Similarly, the Services Atlas will offer a means for technologists (and their funders and managers) to trace the software artifacts they build (or fund or manage) to the broad or specific ways that technology is adding value to scholarship.

Second, the Bamboo Exchange will provide a means for those engaged in scholarship to make connections that will help them to advance their work using services. The Bamboo Exchange will enable scholars to find tools and digital methodologies of value and interest to them, and expertise to help them build or use services that can enable or enhance those tools and methodologies to better fit scholarly need.

The latter sub-sections of the Shared Technology Services section of the Program Document address some of the logistical aspects of identifying, refining, and making services available for use (Services Lifecyle), and partnering with extant tools projects, digital archives, and others to broaden the field of easily interoperable digital aids to arts, humanities, and qualitative social sciences scholarship (Tool and Application Alignment Partnerships and Content Interoperability Partnerships).

4.1. Services Atlas

Capsule Summary: The Services Atlas records and delivers community input (Scholarly Narratives, Recipes, Activities, Tool examples, Content/Resource examples, Service Families, Service Candidates, Service Contracts, and extant Services - including community-contributed references to information outside the formal bounds of Bamboo) in easily updated, linked, 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. The services atlas is not a user interface, web page, or application; it is exposed as a set of services that may be presented in a tool, page, portal, or interface of one's choice, including but not limited to the Bamboo Exchange.

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, the tools that incorporate them, and the body of work they are meant to support. A Service Atlas is intended to help faculty, librarians, funders, institutional leaders, technical architects, and service developers 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 services atlas is not a user interface, web page, or application; it is exposed as a set of services that may be presented in a tool, page, portal, or interface of one's choice, including but not limited to the Bamboo Exchange.

The Bamboo Services Atlas will fulfill a number of purposes:

  1. Identify Existing Services: Provide a mechanism for characterizing and discovering extant services that support scholarly practice. Characterization may include expert review from one or more perspectives (including scholars' assessment of value to/impact on scholarship; durability, from a curatorial point of view; and/or technically-relevant metrics).
  2. Connect Technology Services to Scholarly Practice: Provide mechanisms to record and retrieve relationships between scholars' description of their work and services, tools, & content that support that practice.
  3. Enable Categorizations: Enable application to Atlas content of tags, keywords, and/or categories, whether contributed by users or generated by data-mining software; and, by providing access to data elements, their metadata, and their relationships, enable representation of Atlas content in the context of these contributed or generated ontologies, taxonomies, and/or folksonomies. Different representations thus enabled might be suited to a scholar's exploration of elements of interest (narratives, recipes, tools), to strategic planning tasks such as prioritization and application for funding (focusing on service families and the scholarship they advance), or to technologists' work such as modeling, designing, and implementing services (focusing on service modeling, design, and contracts).
  4. Translate Across Communities: Provide a means 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 investments support scholarly need both as currently conducted and into an evolving future.
  5. Surface Elements of Scholarly Practice that can be enhanced or advanced by technology services: By exposing its content for representation, the Atlas, to the extent it is populated, will describe areas of scholarly practice in the Arts, Humanities, and Qualitative Social Sciences that are suited to automation (i.e., suited to enhancement or support via shared technology services, including services whose function is to provide access to hardware-bound capabilities such as storage or telepresence).
  6. 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. Creating support for new and intended practice may have transformative effects, whose value must be judged and whose nature must be governed by communities of scholarship.

In order to fulfill these purposes, the Bamboo Services Atlas will incorporate artifacts that describe both activities and objects involved in scholarship ('verbs and nouns,' or 'steps and ingredients' - cf. Scholarly Narratives & Recipes); and support multiple points-of-entry to its content to facilitate understanding from multiple perspectives. Information will be exposed at multiple levels of detail (or 'granularity'), and be filterable via annotation, search, and discovery mechanisms designed to open access to audiences with different points of view. Though the Services Atlas is conceived as a (set of) 'back-end' service(s) - that is, the Atlas itself will have an API (Application Programming Interface), not a user-interface - it will support recording of and access to the characteristics of Atlas elements that are of interest to diverse communities of its users. (Bamboo will implement at least one user-interface to the Services Atlas; cf. Bamboo Exchange, below.)

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, including community-contributed references to information outside the formal bounds of Bamboo;
  • Functionality of extant software (of most any origin) 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 - within or beyond Bamboo community borders - but not yet in release or use) as analyzed and 'factored' into capabilities and services.

The Bamboo Services Atlas will consume and expose identifying and characterizing information about services from the Bamboo Service Registry, which will provide services to register and discover services, to record and obtain service contracts, and to record and discover information about service usage (consumption).

The Bamboo Services Atlas and Bamboo Exchange, once implemented, are 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 access to Atlas content in accessible formats that are easily updated, hyperlinked, and annotatable. The Atlas and its Bamboo-provided user interface 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 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, in addition to the Bamboo Exchange. The Services Atlas is not intended to catalog the totality of knowledge about scholarly practice, digital tools, or shared technology services; it will be useful to the extent it is well-populated with information by responsible and thoughtful contributors.

Questions to reviewers of this draft about material in this sub-section

  • Do scholars at your institution think 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 work, 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 used as a replacement for the term "Services Roadmap" used in the Bamboo Planning proposal to the Andrew W. Mellon Foundation. The reason for this change is that the currently-conceived content and purpose of this mechanism 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. Bamboo Exchange

Capsule Summary: The Bamboo Exchange will serve as a focal point for information about services, tools, and content, including but not limited to services incorporated in the Service Atlas; and as a venue for resource exchange between marketplace participants. Incentives to participate in this marketplace will include a community-driven award system (including monetary rewards), expanded metrics about the way services are used by scholars and campuses, publicity, 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 Exchange will allow scholars to discover new resources for their activities, explore and compare the relative capabilities of these resources, and to initiate exchanges of resources. The Exchange will feed information into, and receive information from, the Scholarly Network, to allow scholars to make informed choices among the resources offered via the exchange. The Exchange will allow resource providers to publicize and track the use of their resources, including the ability for experts (including librarians, programmers, consultants, and architects) to join and be compensated for project work housed at other institutions. The Exchange is inspired by several models in use elsewhere - Common Solutions Group, the United Way, ARTFL, and a range of online communities which track reputation and participation.

The Bamboo Exchange will 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 Exchange to be easily incorporated into and presented/used within existing portal, virtual research environments, or other aggregation and/or research workflow systems and tools.

4.2.1 Enabling Discovery

The Bamboo Exchange will seek to aggregate and disseminate information about available services, tools, and content 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 technology applicable to scholarship has 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 builders and providers, as well as from other catalogs, in order to make their work and offerings discoverable from within the Bamboo Exchange; as well as mechanisms that allow service builders/providers to actively and explicitly register information in the Bamboo Exchange.

Bamboo Exchange 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.

4.2.2 Exploration and Comparison

The Bamboo Exchange will allow for the browsing of resources, each expressed in a consistent manner to support comparison and transparency. One useful analogy which has been suggested here is the nutrition label -- a standardized view of the contents and capabilities of a resource, to allow for evaluation of the suitability, interoperability, and sustainability it offers for a given purpose and context. The Bamboo Exchange will 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. In addition, all of this information will be exposed via an API - Application Programming Interface - so that other services and projects can incorporate and extend the capabilities of the Exchange. There may be minimum constraints for participation in the Bamboo Exchange, 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 may in some situations change or restrict the availability of a given resource.

4.2.3 Initiating Exchanges of Resources

Several of the planning workshops surfaced a similar idea: what about a 'craigslist' (online classified ad system) for scholars? How can a faculty member at one institution connect with a digital humanist at another institution, simply in order to be pointed in the right direction for a technology solution and avoid reinventing the wheel? How can highly skilled research assistants be supported during gaps between grants? Through both free-form postings and an RFP forum, the Exchange will allow institutions to contract with other institutions for the use of resources. These resources might be technology, but one particular area of value is the ability to contract human resources through the exchange. This enables a scholar to gain access to expertise at other institutions for purposes of collaboration, wayfinding, and project work. For example, a scholar at the University of Puget Sound who needs access to an XSLT (Extensible Stylesheet Language Transformations) expert at the University of Chicago would be able to contract for a few hours of her time. The Exchange will support the exploration of multiple models for easing the transactional barriers between the resource pools at different institutions.

4.2.4 Rewarding Open and Interoperable Resource Creation

We will encourage and incentivize the community to build services more likely to become Bamboo "Common Services" to encourage adherence to development guidelines and standards for data/content interoperability. Some incentives include the opportunity to deploy services that evolve outside Bamboo in a "Bamboo Incubator" (cf. Local and Incubator Services, below), and a community funding redistribution model which provides resources to selected community projects. An appropriate algorithm and strategy for funding redistribution will be determined by the community. Strawman proposal.

4.3 Shared Services Lifecycle

Sub-section 4.3.1, "Local and Incubator Services," describes early phases of discovery, adoption, or development of services of interest to the Bamboo Community. Sub-section 4.3.2, "Common Services," describes a phase of service refinement that addresses concerns like sustainability, standards-compliance, and reliability. Sub-section 4.3.3, "Bamboo Service-Delivery Appliances and the Bamboo Cloud," describes how Bamboo intends to make services available for use.

 

4.3.1 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 in the Bamboo Exchange. 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. The "incubator" concept is borrowed from W3C and Apache.

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 a 'pre-consortial' 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 Service Level Agreements (SLAs) associated with these service deployments.

These 'pre-consortial' deployment avenues recognize 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 aligning characteristics, standards-compliance, and deployment requirements of software services. Bamboo will therefore 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 such as these, 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 Exchange;
  • may be deployed in a standard "Bamboo Appliance" if the service meets some minimal alignment to Bamboo deployment infrastructure; 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, modeled on the "entry path" concept that underlies the W3C and Apache incubators;
  • 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.

Questions to reviewers of this draft 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," briefly described above.
    • Is this of interest to reviewers who are (or whose institutions/projects are) service builders/providers?
    • What other incentives might Bamboo offer, especially ones that leverage scarce resources?
    • Would some notion of "Bamboo Compliant" certification be of value, and if so, what might it mean (short of being a Bamboo "Common Service")?
  • 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 running Bamboo Appliances, what avenues should be available for identification/nomination of services to be deployed in Local and/or Incubator contexts?


4.3.2 Common Services

Capsule Summary: Services of broad, deep, or otherwise valuable 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 production-ready reference implementations, will be considered "Common Services." As such, they can and will be deployed by Bamboo member institutions for use by the global community of scholars in a redundant, distributed network of Bamboo Appliances that comprise the 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 Exchange, including its elements). Additional services will deliver direct support to scholarship by enabling Scholarly Networking (cf. Section 3 of the Bamboo Program Document) and 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 sustainability, stability, availability, composability (i.e., usability in multiple workflows), standards-compliance, scalability, and robustness. Architectural coherence is also a key quality of Common Services, intended to forestall problems that would otherwise follow from a scatter of arbitrary decisions (not related to delivery of functionality) that might be made if development is not constrained by architectural principles and a standards orientation. 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. 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 thus eligible to be considered a "Common Service." The current draft of this document does not attempt to enumerate these activities.

Existing services 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, above). 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 the Bamboo Exchange, 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, or are potentially, of broad, deep or otherwise valuable utility to one or multiple areas of scholarly practice in arts, humanities and/or qualitative social science;
  • would provide, in appropriate proportion to the effort and resources needed to evolve them, greater value if engineered to deliver Common Service qualities;
  • 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 run 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.

Services that exist only as concepts must be adopted by a service design/development team in order to advance the concept to a point at which it can be meaningfully considered for candidacy, as described above. Such development teams may be Bamboo Members or not, and may have institutional, organizational, disciplinary, functional, or other focus.

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 (SLAs, 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; the Bamboo Exchange, including its elements; and services that enable Scholarly Networking).

Questions to reviewers of this draft 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?
  • 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 Exchange, 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.3.3 Bamboo Service-Delivery Appliances and the Bamboo Cloud

Capsule Summary: 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 the Bamboo Cloud, via a mechanism that provides load-balancing, fail-over capability, and diagnostics of the "health" of constituent appliances.

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 the Bamboo Cloud, via a mechanism that provides load-balancing, fail-over capability, and diagnostics of the "health" of constituent appliances. It will also be possible to request and receive service functionality from a Bamboo Appliance directly (e.g., via Local and Incubator deployment contexts described above).

Bamboo Members active in the Plan layer of the consortium will be responsible for defining the architecture and technology requirements for this appliance and for the Bamboo Cloud; Bamboo Members active in the Build layer will be responsible for implementing, testing, distributing, and maintaining them.

An early conceptual diagram of appliances supporting a "cloud" from which services may be accessed follows:



Bamboo Service Delivery Appliances and the Bamboo Cloud. This diagram is a very preliminary, rough, and tentative conceptual model of a set of Bamboo Appliances comprising the Bamboo Cloud.

Services delivered from Bamboo Appliances will, in some cases, provide resources delivered directly from the Appliance; while others will wrap (call) or refer to compute, storage, and/or service-delivery resources that originate elsewhere. Service Level Agreements (SLAs, cf. #Glossary) for services offered from Bamboo Appliances or from the Bamboo Cloud, as well as those for underlying services hosted elsewhere, will be clearly articulated to service consumers.

An early set of services will offered from the Bamboo Cloud will be those that enable core digital infrastructure of the Bamboo Community (the Services Atlas and its component entities; the Bamboo Exchange, including its elements; and services that enable Scholarly Networking). Some content is likely to be hosted in the Bamboo Cloud, including content related to the Services Atlas, Bamboo Exchange, Scholarly Networking infrastructure, and related Bamboo community endeavors; the appropriateness and extent of Bamboo cloud-hosting for digital content such as primary and secondary sources of scholarly interest will evolve over time, in accordance with community-directed decision making processes, partnerships, and resource availability.

The technology stack that enables service delivery is conceived as a "Bamboo Service Platform." It will be composed from existing, open-source technologies such as service containers, service buses, and orchestration engines, and provide the means to host and deliver services to the community.

Questions to reviewers of this draft about material in this sub-section

  • 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 does Bamboo need more? If more, what are their different characteristics, or the differing characteristics of the types of services they deliver?
    • 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 the "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 unachievable within the first half of Bamboo's Phase I implementation (i.e., by mid-2011)?

4.4. Tool and Application 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 reviewers of this draft 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?
  • This sub-section has not yet been deeply developed. What are important points or concepts to include?


4.5. Content Interoperability Partnerships

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. These partnerships are likely to look to existing initiatives around the Open Content Alliance, the Internet Archive, and similar content-centric efforts, as well as library-driven specifications for publishing digital resources such as Jangle, to build upon a range of experience and practice in capture, archiving, discovery, and dissemination of digital content.

Intellectual Property issues are likely to play a part in any content interoperability efforts.

Questions to reviewers of this draft 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 or METS)?
  • What are strategically important initiatives and specifications that ought to be mentioned in this section - not aiming for a comprehensive list, so much as a broadly representative list?
  • This sub-section has not yet been deeply developed. What are important points or concepts to include?


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 1.0 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. Cf. Activity Definitions.
  • API - cf. Application Programming Interface in this glossary.
  • Application ID - An alphanumeric string or other token of identification that ties usage of a service to another piece of software, such as another service or an application.
  • Application Programming Interface (API) - Instructions explaining how a body of software may be used to gain the benefit of its functionality. (From Wikipedia: a set of routines, data structures, object classes and/or protocols provided by [software] libraries and/or operating system services in order to support the building of applications.)
  • Bamboo Appliance - Shorthand for a 'service-delivery appliance' - a standardized (probably virtual) server provisioned with a technology stack (cf. Bamboo Service Platform in this glossary) on which services (e.g., web services) may be deployed and made available for use.
  • 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.2 - Common Services, above)
  • Bamboo Service Platform - A set (stack) of technologies that provides the means to host and deliver services from a Bamboo Appliance (cf. Bamboo Appliance in this glossary).
  • Capability - In a service, a piece of work that the service can deliver on request.
  • Common Services - Cf. 4.3.2 - Common Services (above).
  • Narratives - Cf. "Scholarly Narratives" in this glossary.
  • Operation - A call (request) 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. Cf. Recipes.
  • Refactor - (from Wikipedia): "The process of changing a computer program's internal structure without modifying its external functional behavior or existing functionality. This is usually done to improve external or internal non-functional properties of the software, such as code readability, to simplify code structure, to change code to adhere to a given programming paradigm, to improve maintainability, or to improve extensibility."
  • Scholarly Narrative - Expression of a particular aspects of scholarship, scholarly workflow, research, and/or teaching from a scholar's perspective, and in her own language. Cf. Scholarly Narratives Working Group.
  • Shared Technology Service - cf. Service, below.
  • Service - A unit of software that delivers a related set of capabilities. Services implement functionality (capabilities) that have been decomposed then logically grouped to flexibly facilitate (a) interoperability with other software and/or digital content; and/or (b) 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. Cf. 4.1 - Services Atlas (above).
  • Service Candidate - A concept for a service. 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. A service endpoint is to a service what a URL is to a web page; in the familiar case of a web page, calling http://www.google.com in a browser fetches a web page from Google.
  • 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 and formal than Service Design, but more so than a Service Candidate.
  • Service Family - 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

3 Comments

  1. Unknown User (jim.muehlenberg@doit.wisc.edu)

    I have a few questions/comments on this third draft, but the good news is I have a lot fewer of these than I did for the last two drafts, which means I'm liking what I'm seeing here a lot, and understanding it better!  Thanks for the work on this area, Steve!

    For 4.2 Bamboo Exchange, I think having the strawman proposal included helps understand what is envisioned here, that was very helpful.  In referring to the "marketplace participants" in the capsule summary, can we assume this is the entire Bamboo Community, not only Bamboo Members and Affiliates?  At least to me, it seems it should be that broad.  If so, I suggest making that clear here and referencing the "Bamboo as an Organization" section.

    In 4.3.1 Local and Incubator Services, second paragraph especially - is it reasonable to also think of tools and content in a manner parallel to how this section is thinking of services?  I.e., that tools and content from the broader Bamboo Community can possibly go through Local and Incubator status, maybe even achieve Common status?  I realize that Bamboo is not about building tools and content but rather about delivering shared services, but if we are cataloging and referring folks to these resources (as referred to in the third paragraph, "recognize that a world of tool and service development ... is occurring"), might there be some value in perhaps classifying them in the same degrees of Bamboo adoption/conformity rating?  Just a thought, maybe far-fetched.

    Also in 4.3.1, last paragraph heading up the bulleted list - this refers to services "offered by Bamboo partner institutions and organizations" - can we similarly interpret this as the broader Bamboo Community in scope?  Again, if so, perhaps a clarification will help.  (The 5th bullet seems to confirm this, "or by others.")

    Section 4.4 Tools and Apps....  last sentence before the questions - where it says "being considered for refinement into Bamboo Common Services" - wouldn't this also include candidates being considered for Local or Incubator status/hosting?

    Section 4.5 Content...  last large paragraph where OCA and Internet Archive are listed - might the NEH ODH "Digging into Data Challenge" list of cooperating repositories fit on this list?  (http://www.diggingintodata.org/Repositories/tabid/167/Default.aspx)   Also, two other initiatives/specifications to consider here are OAI-PMH (Protocol for Metadata Harvesting) and OAI-ORE (Object Reuse and Exchange) from the Open Archives Initiative (see http://www.openarchives.org/).

    1. Unknown User (masover@berkeley.edu)

      Jim,

      Again, just a reply to some of these:

      • re: 4.3.1 Tools & Content and how Bamboo might classify them, I think that the questions you raise are good ones to consider but are more likely to be addressed in Sec 3.4 than in Sec 4
      • re: 4.3.1, "offered by Bamboo partner..." - the confusion is in the verb "offered" - I'll change this to make it more explicit: "served (hosted/deployed)" instead of "offered" ... this bulleted list has to do more with where the services are deployed (i.e., in Local and Incubator appliance contexts) than with who has developed the service
      • re: 4.4 - yes, good catch - I'll change that
      • re: 4.5 - thanks for these ... though this section of the Bamboo Program Document is little-developed and may not get much more flesh on it until after Draft 1, I've added your suggestions to what we've got
    2. Unknown User (khc@uchicago.edu)

      Jim,

      I think I've broadened the language in 4.2 to address your comment. Thank you for all your work throughout this process!

       -Kaylea