Page Tree:

Child pages
  • BIP 0.5 Bamboo Services Platform

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

Skip to end of metadata
Go to start of metadata


This is an outline for Phase 1 (24 months) of a Bamboo Implementation Proposal.

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 implementation phase. The intent of this document is to solicit community input toward the ongoing development and revision of the implementation proposal. As this is an early draft, 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 periodically and will be 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.3 - Bamboo Services Platform

4.3.1 Summary

A Bamboo Services Platform ("Platform") is foundational technology necessary to support software services for arts and humanities scholarship. Bamboo Services will run (be deployed) on a Bamboo Services Platform, as web browsers and word processors run on an operating system (e.g., Microsoft Windows).

Broadly accepted best practices in software engineering will be applied to refinement of services in iterative stages, making the software more reliable, interoperable, and maintainable over time. Bamboo's "Shared Services Lifecycle" will describe sequential stages of refinement, and the steps required for services to evolve from one stage to the next. In the most evolved stages of this lifecycle, services will run on geographically distributed instances of a Bamboo Services Platform, which will enable "always-available" guarantees to consumers of those services, and other useful efficiencies.

Partnerships with content providers, and with tool and application developers, will influence characteristics of a Platform. Technology architects will balance characteristics that best support new services and services in the general case, with choices that best align to key standards, practices, tools, and services already adopted by Bamboo's community and other national and international cyberinfrastructure initiatives.

Standardized infrastructure choices and automated procedures for realizing those choices will save money, time, and aggravation for humanists and support staff who must otherwise sink funds and effort into choosing, maintaining, and operating technology, hindering direct engagement with teaching and research.

4.3.2 Description

A Shared Services Lifecycle will establish migration stages through which software will be transformed from narrowly tailored, idiosyncratically accessed, and atypically deployed forms; to a services architecture that conforms to open standards of access, data exchange, and deployment. Application of best software engineering practices, in increasingly rigorous phases, will effect such transformations. Broadly drawn, stages of service evolution can be described as:

  • Early interest in, adoption by, or development by the Bamboo Community
  • Iterative stages of service refinement to addresses concerns like standards-compliance, reliability, and conformity to Bamboo's standard deployment models (some services new to the Bamboo community might already address some or all of these concerns)
  • Deployment on and reliable availability from a set of distributed Bamboo Service Platform instances

A Bamboo Services Platform (Platform) is a technology stack on which services will run in advanced stages of the Shared Services Lifecycle. Such a technology stack will include elements such as a service container; message mediation, transformation, and routing software; a rules engine; connectors to secure, distributed storage; a service orchestration engine; and logging capability to track and report usage metrics. A Platform will be packaged as an "appliance" - a standardized set of technologies bundled together into an easily-replicated server. The Platform appliance will be realized as a virtual machine that is managed via a standard set of interfaces appropriate to distributed ("cloud") hosting. Hosting will be provisioned by commercial, consortial, and/or institutional partners, to best address stewardship, economic, legal, and policy considerations. An appliance may also contain additional technology bundles/systems/platforms (such as Fedora, Nuxeo, JCR interfaces for Plone et al., or SEASR) where the value of co-deployed functionality is judged beneficial in reasonable proportion to operational demands and complexity of the appliance.

In Partnerships with content providers and with tool and application developers, Bamboo will identify software functionality incorporated into existing resources that can be extracted and revised ("refactored") as shared services. Shared services are reusable units of software that deliver functionality needed by multiple projects or tools; and can do so remotely, and independently of the software's implementation language or framework. Bamboo will partner with established digital humanities and related projects to solve reuse and interoperability issues, and to develop a shared services trajectory aligned to core goals and values of the partnerships. Service development and refactoring efforts will prioritize implementation-agnostic interfaces, and will focus on enabling service uptake across initial (disciplinary or other) boundaries of the contributing projects. Partnerships will invest in:

  1. selecting and promoting interoperability standards
  2. identifying and implementing (or refactoring) sharable services from existing software that supports humanist scholarship
  3. refactoring existing projects to use services deployed on the Bamboo Service Platform in lieu of separately developed and maintained functionality
  4. contribution to the Bamboo Atlas of elements related to Partnership services and other Partner-delivered content or functionality, including related scholarly narratives and recipes

Sidebar: Inclusion Challenges

A utopian "Bamboo Services Platform" (Platform) might allow services implemented in any programming language, framework, or paradigm to be deployed and maintained with frictionless ease. A utopian "appliance" might accommodate the inclusion of any tool or system or platform that promises to meet the needs of a broad sector of arts, humanities, and interpretive social science scholarship. Alas, like Galileo's "frictionless plane," such idealized outcomes are unlikely within the real-world constraints of a Bamboo Implementation project. Hard choices will have to be made. It is unlikely that any person or project will be fully satisfied by the complete set of decisions to include in and exclude from a Platform and the appliance on which it is run.

For this reason, it is practical to start with a set of criteria for inclusion and exclusion. These criteria should be designed to scope decisions to deliverables, so that a Platform and appliance address the set of problems that are the focus of a current phase of Bamboo Implementation. As Voltaire wrote, "Le mieux est l'ennemi du bien": the best is the enemy of the good. The Bamboo community will want to inoculate itself against paralyzing overambition.

This proposal does not list criteria, as their establishment is a key element of the work plan for Bamboo Implementation partners; however, the following challenging areas of decision-making relevant to inclusion/exclusion of elements in the Platform and appliance are presented as food for thought. Criteria developed by Bamboo Implementation partners might help to address these challenges effectively, to deliver the greatest achievable value to humanities scholarship:

  • What is the benefit to humanities scholarship of making a system or family of services available as part of a Bamboo appliance, versus making the technology available through some other deployment?
  • How does the benefit of including a technology in a Platform or appliance compare to the cost of configuring, operating, and/or managing its inclusion?
  • What constraints or risks - such as exclusion of valued families of services, or tight-coupling to a single vendor or project team - are associated with a technology?
  • What standards and best practices are implicit (or not) in the adoption of a technology, system, or family of services?
  • How well does a technology stack element align to support requirements of services to be deployed atop the stack in the near future?

4.3.3 Value

Bamboo will deliver technical infrastructure that permits humanities projects to transition from project-specific applications to longer-lived, more broadly supported, more efficiently operated, and more widely used, useful, and interoperable services. This transition will drive toward a future in which content and technology can be can easily discovered, combined, re-mixed, and shared to create new forms of digital research and teaching.

Insert a humanist's perspective on how discovery, combination, re-mix, and shared content/tools will enrich her work

The "cloud" model of service delivery introduces more than an approach to sharing services, connectors, interfaces, and content. Deployment of a Bamboo Services Platform "in the cloud" will minimize risk to individual institutions through guarantees of service availability inherent in well-architected redundancy, drive down data center costs through economies of scale, and leverage pooled software engineering talent.

Insert a CIO's perspective on how cloud models of service delivery are a path to efficiencies in higher ed organizations

Partnering with key content and tool projects that are able and eager to externalize general aspects of their offerings will enable other efforts in digital humanities to decrease the fraction of functionality that must be reinvented. Partners will be credited with contributing to a broader range of scholarship, a value proven by usage metrics collected for services deployed on the Platform. In turn, contributing partners who evolve their offerings to rely on contributed services deployed and maintained in a Bamboo environment will free themselves to focus on areas of specialized value and expertise.

Insert the perspective of a PI on a digital humanities project on how partnership with Bamboo will provide value to each partner

4.3.4 Work Plan

Realizing the Bamboo Services Platform will involve multiple strands of effort that will strongly influence each other in iterative increments. Some effort can (and must) occur in parallel, with appropriate coordination points and processes. Implementation Phase efforts will be informed by Planning Phase Proof of Concept accomplishments and conceptual agreements among Bamboo partners. At a high level, elements of Implementation Phase strands of effort are:

  • Year One
    1. Establish initial qualities and processes for a Shared Services Lifecycle, with attention to proof-of-concept work and preliminary conceptual development among Bamboo Partners
    2. Establish criteria for identifying and evolving partnerships with tool & application projects, and with content providers
    3. Establish criteria for selection of standards, architectures, and technologies to be included in a Bamboo Services Platform (Platform); and for selection of additional technology bundles/systems/platforms to be included in an appliance deployment of a Platform
    4. Establish Year 1 partnerships with tool & application projects, and with content providers, engaged in digital humanities scholarship
    5. Identify initial functionality to be refactored as shared services out of Year 1 partnership project/provider software
    6. Select an initial set (v0.1) of Platform standards, architectures, and technologies, with attention to proof-of-concept work and preliminary conceptual development among Bamboo Partners; focus for the v0.1 Platform will be delivery of services to deliver Bamboo Atlas and Scholarly Networking functionality; alignment with existing cyberinfrastructure initiatives; and, to the extent possible, anticipated platform-support needs for project/provider services.
    7. Explore and address legal and policy issues inherent in distributed hosting of infrastructure and services, in concert with key higher education stakeholders (e.g., Common Solutions Group)
    8. Refactor initial functionality from Year 1 partnership projects/providers into shared services deployable on a v0.2 Platform
    9. Refine criteria for identifying and evolving partnerships with tool & application projects, and with content providers
    10. Realize (implement) the v0.1 Bamboo Service Platform as a cloud-deployable appliance
    11. Deploy pre-production Bamboo Atlas and Scholarly Networking back-end services on the v0.1 Platform
    12. Map v0.2 evolution of the Platform to support services refactored from Year 1 partner projects/providers and further alignment with existing cyberinfrastructure initiatives; also, consider cost/benefit of deploying additional technology on a virtual "appliance" running a Platform
    13. Realize (implement) the v0.2 Bamboo Service Platform as a cloud-deployable appliance
    14. Seek additional partnerships for Year 2
    15. Design, deploy, and prove a service request/redirection mechanism to direct service requests to multiple backing Platforms (or, ideally, clusters of Platforms) from a single point-of-request
    16. Deploy pre-production Bamboo Atlas and Scholarly Networking back-end services, as well as pre-production refactored services developed in partnership with other projects/providers, on the v0.2 Platform
    17. Productionize the latest possible Platform to be released as a cloud-deployed appliance v1.0 by the end of Year 1, with strong prejudice to procure hosting from at least two categories of cloud provisioners (e.g., commercial, consortial, institutional)
    18. Productionize v1.0 release of Atlas, Scholarly Networking, and services refactored from partner projects/providers, with deployment on distributed (cloud-deployed) instances of v1.0 Platforms, where services are accessed through the single point-of-request mechanism
    19. Gather service/platform usage and maintenance metrics and begin to develop a sustainable financial model for running services in the cloud
  • Year Two
    1. Maintain deployed services/platforms/appliances
    2. Further evolve qualities and processes of Bamboo's Shared Services Lifecycle
    3. Establish additional partnerships with tool & application projects, and with content providers, engaged in digital humanities scholarship
    4. Identify functionality to be refactored as shared services out of Year 2 partnership project/provider software, and additional functionality to be refactored out of Year 1 partnership project/provider software
    5. Refactor initial functionality from Year 2 partnership projects/providers into shared services deployable on a v1.1 Platform
    6. Building on Platform v1.0, select v1.1 standards, architectures, and technologies - with focus on evolved Bamboo Atlas and Scholarly Networking service delivery; alignment with existing cyberinfrastructure initiatives; and support of services refactored from Year 1 and Year 2 partner/provider projects
    7. Initiate the full set of work steps described - from definition to production - for an "AlternatePlatform" distinct from the first, as judged a cost-effective investment, to support additional service development platform/framework.
    8. Deploy pre-release evolutions of Bamboo Atlas and Scholarly Networking back-end services, as well as pre-production and pre-release refactored services developed in partnership with other projects/providers, on the v1.1 Platform
    9. Further evolve the Platform (v1.2) toward v2.0 release at end of Year 2
    10. Deploy pre-release evolutions of Bamboo Atlas and Scholarly Networking back-end services, as well as pre-production and pre-release refactored services developed in partnership with other projects/providers, on the v1.2 Platform or v0.2 Alternate Platform
    11. Gather service/platform usage and maintenance metrics and further develop a sustainable financial model for running services in the cloud
    12. Productionize the latest possible Platform to be released as a cloud-deployed appliance v2.0 by the end of Year 2
    13. Productionize the latest possible Alternate Platform to be released as a cloud-deployed appliance v1.0 by the end of Year 2
    14. Productionize v2.0 release of Atlas, Scholarly Networking, and services refactored from partner/provider projects, with deployment on distributed (cloud-deployed) instances of v2.0 Platforms (or v1.0 Alternate Platforms)

Each of the elements listed will have many component pieces of work; these are fleshed out further in the Detailed Work Plans section of this proposal. The high level effort for Year 1 (2010) might be represented graphically, in sequential layers and mutually-influencing strands, as follows.


Annual Deliverables




Year 1

  • Shared Service Lifecycle v1.0
  • Criteria for partnerships and selected partners
  • Criteria for Platform and Appliance technologies, and selection of technologies
  • Platform v1.0, instantiated as an appliance
  • Platform v1.0 Appliance deployed atop two distinct categories cloud-hosting provider infrastructures
  • Productionized community services (Atlas, Scholarly Networking) running on cloud-hosted Platform v1.0
  • Productionized partner-refactored services running on cloud-hosted Platform v1.0
  • Initial draft of business model for sustainable cloud-hosted service delivery, taking account of legal and policy issues
  • Appliance may, if judged beneficial and cost-effective, include technology bundles/systems/platforms in addition to the Platform v1.0

Year 2

  • Shared Service Lifecycle (evolved)
  • Evolved criteria for partnerships and, optionally, additional selected partners
  • Evolved criteria for Platform and Appliance technologies, re-evaluation of initial selections, and evolution of the initial Platform
  • Evaluation of the utility and cost-effectiveness of an alternate Platform, and, if judged a prudent investment, identification of its characteristics.
  • Platform v2.0, instantiated as an appliance
  • Alternate Platform v1.0, instantiated as an appliance (optional)
  • Platform v2.0 Appliance deployed atop two distinct categories cloud-hosting provider infrastructures
  • Alternate Platform v1.0 Appliance deployed atop two distinct categories cloud-hosting provider infrastructures (optional)
  • Productionized, evolved community services (Atlas, Scholarly Networking) running on cloud-hosted Platform v2.0
  • Productionized, evolved partner-refactored services running on cloud-hosted Platform v2.0
  • Productionized partner-refactored services running on cloud-hosted Alternate Platform v1.0 (optional)
  • Actionable business model for sustainable cloud-hosted service delivery, taking account of legal and policy issues
  • An "Alternate Platform," built as a technology stack distinct from the first, will be developed if such an investment is judged cost-effective. The purpose would be to support an additional service development platform/framework substantively different from the first, from which Bamboo's service development community can derive significant value.
  • Should a single, clearly superior cloud-hosting paradigm emerge by Year Two of the Bamboo Implementation Phase, it may no longer be necessary or advantageous to continue exploration of multiple models.

  • No labels


  1. Unknown User (

    Breakout Groups: Major Areas of Work

    • DAG: Is our description sufficiently clear?
    • Work defining lifecycle, platform, appliance, and partnerships - at a high level, here's where we'e placed fundamental partnerships w/ existing tool partners and various content projects
    • We haven't yet put into here or plans of actions those projects that in year 1 we'd be partnering with, but some of you have already said you'd like to be part of those partnerships
    • Q: Strength of some of other sections is that there's more examples and analogies of what exists elsewhere; we would need more of that
    • Sidebar doesn't serve same purposes as "this is what Amazon would do"
      *DAG: Yes, other people have generally said that sidebars need to be fleshed out in all areas, have different kind of conversation
    • Q: Sidebars is good idea, examples are good, but too much analogy and too much metaphor is dangerous because people interpret metaphors/analogies/comparisions differently
    • First sidebar in networking, for instance; good, but particular way it's expressed should be very concrete
    • If we're too much into fables and analogies, mythology, it's caused trouble before
    • DAG: Not an argument against sidebars, but way that we do that; be concrete, be careful about things that could be misinterpreted
    • Q: Agree with this – we're now where we need to connect issues; provisioning infrastructure to provide support for certain kinds of activities
    • Year 1 step - figure out which services; but we're not being clear enough in connecting w/ what we can't do right now > this is what we can do because we're building common services, cloud, etc.
    • Need to make the connection explicit and concrete
    • DAG: Something that would go in values section, for explaining what we can't do/would be able to do? And also, overall, describe scholarly services/approaches?
    • Q: Mellon would probably want to see "current state vs. future state"' - that's the answer, making that explicit
    • Year 1, year 2 are steps to get us from here to there
    • Q: Need to figure out how you slip in language without confusing readers; cyberinfrastructure > technology platform > gadgets/widgets (but this is not software development?)
    • DAG: Philosophy is as much as possible, not re-inventing the wheel
    • We do have a language problem
    • Q: Goal to get to common services, have trouble imagining where one process stops and another begins (on evolution of services diagram)
    • Needs some examples - resources Humanists are using, what needs to happen as a result
    • DAG: for people who mention strong interest in being partnership projects, put in that example (Greg Crane?)
    • Cost-share, early commitment
    • Want early projects directly related to delivery around scholarship; work with in year 1 to help with general problems, additional services
    • One of next steps is to say "who's ready to go", what benefit from that; weave into next version
    • Could have 2-3 partnership projects that get us what we want at different levels
    • Q: Not sure if planning document needs to emphasize concreteness
    • I'll be glad when we get beyond planning to real work
    • This will all come down to the types of work, partnerships formed over the next year
    • At Northwestern, to what extent Bamboo Project and Services Platform supports/amplifies/etc work with Fedora Commons, work among CIC and California/Virginia with Hathi Trust
    • Are we a maverick idea/organization that has great ideas but not much to show immedaitely, or can we help amplify/support existing activities?
    • Q: On the phone, the area that we were most interested in had to do w/ content interoperability - "it's all about content"
    • Content providers are alluded to, but we have content creators/extant collections, the work of putting together guidelines and tools for these people to provide their content such that they don't have to re-do what they have (want to share, communicate, federate) - via standards, guidelines, tools - this is very invisible in the section
    • One of the more crucial areas: content is going to outlast any technology stack; I'm in this room for that area
    • DAG: Heard this loud and clear, almost everyone brought up content projects, saying " we want to work on this kind of content tool project"
    • Hathi Trust came up numerous times; want to build concrete partnerships
    • Q: Also some deliverables
    • Q: Missing "and content" in the Platform
    • Q: It's not content, it's ways to handle content
    • Q: Content is primary source, nowadays secondary sources like user reviews or comments might be useful in terms of generating useful secondary source (information for other use)
    • Nothing mentioned here about metadata - so many different schemas, how do you choose?
    • Existing standards, or play active role in talking w/ metadata organizations, to get arts and humanities support when lacking
    • Year 1, year 2, etc; for grant agency, would probably want to see longer term (phase 1, phase 2?); I don't see this
    • DAG: Mellon recently said that based on their funding, we originally wrote 7-10 years, but they want a year at a time; we had to write a 2-year proposal that you can slice in half
    • Q: advantages to that - we're nimble and productive and not just long-term
    • Q: Interoperability. Everyone has separate repositories, nothing works together. Also see metadata standards as not solving the problem well yet - the problem there is human, people have to get the site up, and generating the metadata and putting it in a sharable form, or coming up with consistent standards is a difficult problem
    • A lot of stuff there we need to think about attacking; some sort of community-based system for evolving standards for interoperability
    • Q: This is not the thought just here, there's work going on elsewhere
    • Q: We've been careful to say we don't want to develop Bamboo Standards, but content interoperability is the end goal, however that works out
    • Q: Beyond developing standards, is there a metadata game? Start off process and standards come out of that ongoing game; not just developing standards, but think also about developing the process
    • Q: Standards is a bad word; we could all be using Dublin Core but it'd still be horrible and uninteroperable without common guidelines/practices
    • What we're looking at is how do I know I get an X when I ask for an X
    • Can't get projects/repositories to change how they do things (necessarily)
    • What you want is a common language - interchange language, all sorts of possibilities
    • "Standards" are already there, lots of them - we need to make them talk
    • Q: Dublin Core is a great example; open to interpretation
    • Q: All big repositories are using metadata; often using certain small set of standards, the question is if they're using them in a compatible way
    • Q: Issue of collections comes first - Fedora not delivering anything substantially of value in 8 years
    • Help the IT group at Mellon redefine its own mission - why doing what they're doing
    • Need to be clear about what gain is for education today: people are getting fired, why invest in this, why not wait until better times? Need a compelling case
    • Scattered collections is a huge one; this is why I pushed for Fedora - "get me all the editions of Hamlet" from everywhere if everyone has Fedora, but this isn't happening
    • Cloud is fine, but we don't have the data in there
    • In the first year, assembling/aggregating available collections, seamlessly, with Fedora and D-Space, etc., would be a substantial step forward
    • Classicists have gotten together and demanded this - precisely this problem, got people from all over the world
    • This is all generic - text, pickers
    • "Coalition of the willing" is the wrong term these days, but whatever the politically collect version is – people eager to integrate data?
    • HTML worked because "if you do this, italics will show up..." etc.
    • If you say "put your stuff in your repository this way, then something useful will automatically happen for free" you'll get traction
    • Classicists have small but coherent community that'd do something - you can point to it
    • Q: Wasn't pushing for more metaphors in sidebars, but this is the most jargony section of the proposal, and in some ways the most important to understand
    • What we've described now, what the problems are, what the goals are
    • This would be one way to make it concrete, and less reliant on "broadly accepted best practices", hard for deans to undersatnd
    • But if "the problem now is that we have all this data, want to use them together seamlessly, this is why we need an investment, want to leverage what we have, our goal in the first year is to take a small selection of these and be able to do this, so it can be expanded in the future" - if you do this upfront, then the description of "how" will make more sense
    • Q: Language of page 2 does talk about what the structure is that's available for building/virtualization
    • Lots and lots of silos that do interesting things, all meritorious on their own, but need to have a mechanism to let them move around so other people can put their hands on it
    • Don't need to transform, even, just access in a liberal and free way
    • Virtualization accomplishes this in a physical sense - I can do what I want with my copy of it
    • This is what we're talking about on p. 2, but it doesn't say it clearly-- it makes sense to me, since this is what I do, the right catchwords are all there, but wouldn't make sense to a dean
    • Can we refine the story to a degree so we're clear about the intent - portable, so can be used/massaged in a particular environment, not so you have to check with Bob who owns it, and ask him
    • Q: The thrust of this is, a dean would like to know that you could integrate this with teaching
    • Hard to do that right now as it stands
    • Q: "Composite virtual repository" - one place you can go and get content from a wide range of places; thematically organized
    • Tools don't have to talk different protocols in 5 different places to access content
    • Universities have huge amounts of content, very little of it as accessible across these barriers
    • Q: Was at first Bamboo sessions in Princeton, all the way to now: economy has changed, who's come to this has changed due to the economy, economics of doing many of the things that we're trying to accomplish with resources is changing
    • We're seeing in our organization requests to rescue projects that are all over the place - institutions can't host things anymore
    • Mellon is concerned, they've been hit up again and again for resources
    • Paying some attention to how this landscape is changing, how we need to look at pooling of resources so we can do this, do projects like we're thinking about – have to pay attention to some of the economic factors going on right now
    • This isn't going away - hitting universities globally
    • Benefit of pooling resources
    • DAG: Can these suggestions be blended? Early focus is around a particular scholarly domain where there's been an investment, where people are ready and able to work?
    • Q: People can use this as an example, don't limit it
    • DAG: Making real progress on infrsatructure of services needed for more generalizability/interoperability towards longer-term efficiency argument
    • PB would help all of us if we could figure out those things in year 1, that we can do to help us build the right general model and solve some particular problems, move faster, not get too caught up in getting everything perfect
    • Q: Early benefits are going to be very important
    • Q: Finding those links between communities are important
    • Why connect groups? What's the project that will be the sell? Membership fees aren't that much, identity management pieces are in place even in CIC; what's the next sell? Aggregation of content? How does it benefit the researcher?
    • Why did we spend all the time on identity management? -X, Y, Z all get the benefits; I'm missing some of that here
    • DAG: Missing some of sell that's made to existing regional consortia/collaboration?
    • Q: Yes; finding other researcher to match with my researcher who's interested in the connection, shared collaborative space
    • Q: Nexus of Houston-Ferman-Holy Cross-UMis-Kansas City, transforming eduacation, using technology early
    • Tufts, etc doing similar things - how do you bring it together? We want some of the stuff they've got, but we don't have the infrastructure, but we would if we could
    • How bring existing disparate efforts together
    • There are "game changers" - "here's a model where as a sophomore you contribute real data to a real database in your second year of a language class"
    • Your undergrad thesis would never be considered significant; this could change
    • You have new sources of info, publication - can contribute knowledge before you graduate - different way of thinking about humanities degree
    • This attracts students, pleases administration - attacks problem that undergrad research doesn't happen
    • Q: What's stopped that?
    • Q: It's cyberinfrastructure; I run a collection, complicated network of resources; I don't want to run this anymore; I thought Fedora would save us in 2001, and they haven't
    • Q: Is biggest problem "who and how" will it run?
    • Q: Generalizing and refactoring some of services you see at ARTFL, etc., and putting them in a format that can manage millions of objects. Scale. Scale is a hundred language, many different categories of data, done with data structure people use rather than the ones that are easy.
    • Eternal example of pictures
    • What's still stuck at project level needs to be bumped up another level
    • As one project manager, trying to get out of that business
    • Collaboration: works now, people at different places contributing to something housed elsewhere
    • Q: Notion of business of building a semi-standard virtualized environment, mechanism for making containers portable between institutions
    • Putting containers next to each other, osmosis will naturally occur
    • We've looked at what's technically achievable, rather than the nature of the problem around the achievable/non-achievable
    • Standards, metadata interoperability - not solvable in a few years, nor even figuring out what you'd be solving
    • But figuring out containers, that's solvable, doable with tech that we have available
    • On the right path: need to be careful about how crafting language, to get the buy-in
    • DAG: Haven't specified services that would be developed on top of containers/platform
    • There's a model in the abstract that's a stack - but what are are we going to tackle first that will help us derive services of high value to scholars, that we can actually accomplish
    • Could we make progress both on particular and universal?
    • Q: Do we want to just take instance at Tufts and throw up as a common service? Bringing stuff we want to start to integrate/consolidate in terms of how we structure it
    • Commonalities of content/data structures
    • Start process to collect, host, then de-compose in a way that the 2nd year is about common scale on top of those kinds of projects?
    • Q: Doable task, but a lot of technology variety
    • Identifying what's out there, what can we accomplish – these are hard problems inter-institutionally
    • DAG: We try to abstract some of this so we can have different instances of the appliance, not get caught up in One Solution
    • We could easily get sucked into years of work trying to figure out metadata; doesn't necessarily get you where you want to go
    • Q: You can't make people change their metadata; want to get some algorithm to do the mapping
    • DAG: It's 2:57, we'll take a break then have another wave; we've addressed question 1 of 3
    • Question 2 - right deliverables for year 1, hearing some framing for that
    • See if we can work on the more concrete story, sketching this out with particular projects
    • Q: What I would like to see, "here's what's going to happen for something different in classroom/research". Money game is with undergrad research.
    • This is why technologies are enablers. If it's just technology, it's religion. Challenge to articulate what the message is, what they're getting re: education, rethinking the world; why is this different?
    • More sustainability - going to defragment this chaotic world (that's nice but whatever), but what Mellon wants is "this is changing education"
    • Be careful about generic solutions-- we want this FOR THE HUMANITIES
    • Q: Is undergrad education the game-changer? I haven't heard too much about that.
    • DAG: First set of arguments to be made about efficiency, integration, fragmentation, etc.
    • Second set of arguments is looking for a "game-changer" - doesn't have to be undergrad education, necessarily
    • Could make a "game-changer" argument, but what is that
    • Q: Not everyone's going to agree-- there's a set of people who believe undergrad education is the game-changer
    • Total consensus won't work
    • Q: It's one case, you may need an opposite/contrasting case that maybe overlaps at some point
    • Q: Suddenly you have students doing things I thought was impossible/not suitable
    • Suggesting a particular thread that could be one among several; but we DO NEED to have game-changers
    • Otherwise, how can you invest today and fire someone tomorrow as a result
    • DAG: Can diversify core arguments
    • Q: Two years ago, I thought this was crazy: digitized best manuscript of test of Homer, in Venice, written in Constantinople in 1000, arrived right before Turks
    • "We already have the text of Homer, why should we care?"
    • Students not in the Ivy League are editing the scholarly commentary associated w/ manuscript
    • This commentary has only been published a little before
    • People at commuter schools feel lucky to partiipate - produce Greek that no one's seen before
    • People are learning because they're motivated, their enrollments are up, parents aren't complaining about their kids studying Greek, and there's a model I could use myself
    • This isn't the only way to go forward, but that's an example of something I find to be compelling - evidence in enrollments, "I like this" responses
    • Other people want to do this, other departments want to participate, but work underway already is fragmented
    • Undergraduates are participating in database of syntax - changing what you can do as a sophomore, doing new research that wasn't possible before
    • This may not work for other kinds of things – not the only thing to think about, but it's a thing I'm pointing to
    • Q: This is availability of stuff, and then, tools to work on it
    • Q: Also, phenomenon of change of value of the content
    • PB could take that and make it accessible; give Harvard access to what's going on at Houston
    • We need to look for the compelling reasons to do anything in Humanities education; why invest in this today? What's the payoff? Why are you here?
    • Q: I do - a group at my university might be perfect for this; but I'm not saying "this is the game-changer"
    • Q: I'm thinking this is A game-changer, not necessarily THE.
    • DAG: Want to find 2-3 key projects to move this part of the proposal forward; make progress in year 1
    • Let's see what we've failed on before
    • Q: Enormous pressure to have a deliverable in year 1, which is why we've spent a year planning
    • DAG: Let's define success upfront, and deliver on it; implementation starts January 2010, it's awkward starting in the middle of the academic year
    • Proof of concept work before January 2010 keeps things going in the meantime
  2. Unknown User (

    This is the most technical part of the document. Its language needs to be made more accessible to readers who are not software designers. Towards this goal, the proposal could be made stronger if it began with a list the problems that the BSP addresses and a list of the specific goals of the BSP. In other words, the proposal should open with a specific account of what the payoff is.

    To take one example, the first sentence of the document reads as follows:

    A Bamboo Services Platform ("Platform") is foundational technology necessary to support software services for arts and humanities scholarship.

    It could be rephrased like this:

    The Bamboo Services Platform supports software for arts and humanities.


    A Bamboo Services Platform will support software for arts and humanities.

    This is not a quibble over style. The document as it stands is a bit unclear because its key functions are expressed in long strings of nouns and adjectives that are both abstract and vague. The more that the specific actions are represented by strong verbs, the stronger the proposal will be because it will be clearer what Bamboo will do.

    1. Unknown User (

      P.S. I'm also volunteering to participate in the revision of this section.

      1. Unknown User (

        Robin, did you also call for someone to help with value statements about this section's intersection with pedagogy?  Myself, Steve Brier, Worthy Martin & Mark Williams are working on the value statement in terms of the Atlas and pedagogy. 

  3. Unknown User (

    • Q: Coffee conversation: "Services has the most concrete task, so they can get traction, right?" And I said, "No, we're looking for a justification", and he said "Hasn't the case been made elsewhere? Aren't you just doing stuff?"
    • Q: Except we're asking for people to put in resources; going to institutions and saying " we want a programmer for Bamboo" - "so why should we give you one?"
    • I'm going back to content, we're going to be asking people to expose their content, which is time-consuming and not of direct benefit internally
    • Don't think we have to talk about game-changing; don't want to tell people how to do the humanities
    • Language you do want to use with certain people, but not with deans/faculty - they feel it's presumptuous
    • Q: This is an opportunity that affords anyone in the humanities, the ability to do analysis, curate collections - right now challenge has been that everyone has their own thing, not leveraging it
    • Q: You hit a good point, on p. 3, first sentence, ends with quoted term "refactoring" - this will be adversive right away
    • What it means is correct (you can take existing things, apply to virtualized environment, make them portable, don't require re-engineering), but term "refactoring" says "you're going to change what I've done"
    • What we're writing down might be interpreted in different ways
    • DAG: We do imagine cases where there's projects that are willing/able where we may be rewriting 5-10 years of software
    • Q: This sounds like dissecting, rather than generalized term of "refactoring" to fit into Bamboo model
    • DAG: Could be both in some cases
    • Q: Doesn't read that way to me; reads in a way that's scary-- project that's relatively mature but the folks who made it come to life are maturing in their positions, may not be willing to hear that
    • DAG: Combination of Perseus (that Greg led, faculty software PI) and ARTFL that are mature and successful projects, good example of rich content + tools bundled tightly together
    • Not going to rework whole application, but figure out evolutionary path that can derive meaningful services on both sides
    • Wouldn't be doing this unless both realized it would be difficult but worthwhile
    • Q: Exactly the problem that Mark Olsen who's been in charge of the software forever - a lot of the functionality exists in his head - tied to him, not in his interest to do the refactoring
    • What UofC is doing now is submitting a proposal to dean, asking people who are not him to take the reusable content and reusable software and make them packaged in such a way that you could double-click on a webpage and it'd install, etc.
    • For UofC, too, their funding proposal, asking for money from university, but tied up with "our part of Bamboo support"
    • Two things are tied together for funding at this point
    • DAG: This is one possible project for year 1, 2, etc; ONE possible project
    • Looking for a couple others that could help us push forward, make progress on broader goals
    • Q: Underlying point is that you have to define different altitudes of engagement, how that would take place
    • What's common across all those levels (deployment level here) - virtualization, different degrees of adaptation, dissection
    • DAG: Discussion of making the case - case is important for all three areas, would like to do some work on what the right work is to be doing
    • If we move away from this particular opportunity (Perseus/ARTFL) - other types of projects that could help us get the right kind of work done in year 1/2?
    • Q: Are there any big video projects going on that support the Humanities?
    • DAG: A number of institutions in insittutional conversations who talked about importance of video work
    • Q: Tools for tagging, making all of it easier/more efficient.
    • Q: Opencast Community - starting not just from capture/management, but that's an important part of it
    • Several years before they're a the point of producing tools, right now focus is on classroom lecture capture, mass production
    • Q: People with existing video archives; how would scholar access it
    • Q: Huge video archive at Purdue, C-Span - annotated library of everything C-Span has broadcast over a decade
    • Q: Interesting to see how scholars for whom that's an important data source use it
    • Q: Availability is part of it; annotation/transcription with timecode is a rarity
    • Put together simple example of utilization using SEASR tools to cull that content; how often did a given senator speak positive/negative
    • Q: Data mining of a different kind of "text"
    • Q: Some of the best tools are things we probably can't use; military and science-oriented military put a great deal of money into automatic content extraction
    • Q: A lot of more annotated image material that can be used intelligently
    • Making a case - faculty are dying for content of that type
    • Interest in joining disparate collections
    • Books about Rome for 16th-18th century, faculty project enriching with metadata; sister collection in Chicago
    • A little possessiveness, a lot of desire to get their hands on each other's stuff
    • Separation of data and tools
    • Q: Where John was differentiating between other elements of Bamboo (atlas, scholarly networking, etc) are applications that the Platform is going to serve up
    • They are the projects that we have to support
    • DAG: Year 1-2, one of the ways to move Atlas forward is to build it out as services on the services platform, but also concerned that if we just make progress on atlas/network, won't have made enough progress re: tools connected to scholarship
    • Q: Two issues-- supporting Bamboo-internal stuff, but also having enough other scalable need to move platform forward
    • Could find takers who'd want to plug their project into a service architecture
    • Want to write out what the characteristics of the other projects are - promote integration, or analysis, etc.
    • Q: Placeholder of 4.3.3 on values? Same ideology?

    (commence working on diagram)
    Projects outside of Bamboo

    • SEASR: Participating at many different levels for being able to manipulate/analyze data; broad range of things, you can make it do whatever you want
      • Pre-existing capability is data mining (text, images, etc.) - trying to be content-agnostic
      • Dataflow engine
      • Marriage of distinct/unrelated APIs is a practicality that could happen
    • Perseus/ARTFL
      • A little, but not the same amount of complexity
      • Work around trying to help make progress on content integration and interoperability
    • Opencast - video
    • JCR Connect - images
      • a lot of image storage silos, no common store
      • create standard called JCR for integrating content repositories that come out of the commercial world
      • implementing JCR for Fedora; gives range of different repositories including Fedora that we can connect to system
      • hub that allows content to connect, tools only have to talk to one virtual system
      • not exactly federating, doesn't handle a couple of the problems a federated search system would handle; content federating, rather than search federating
      • Separating presentation systems for repository; can use with image annotation?
      • JCR is not media specific-- general format
      • Connects with another Mellon project-- use for Opencast for video repository
      • Used for Sakai for content architecture
      • Connecting systems through these pipes; hub that allows exchange, creating content that allows people to write php/python, write presentation software outside of repository; allowing content to be repurposed/reused, maintained over time
      • Standard way to combine content, to repurpose
      • Bamboo could be a champion of JCR - benefits that could be obtained within a year
      • Can't justify Bamboo just on JCR, but could be an example of a middleware where we could be a champion for that, show substantial benefits
      • People who wouldn't have otherwise heard of it could benefit from it
    • Duraspace alliance – a heavy-hitter to target
    • Fedora projects with their own namespace
    • How do you package each of these to fit in the model we're describing?
    • How do we initiate and/or facilitate integration of API marriages; how to foster collaboration across different projects that don't know each other
    • Q: Two layers, data (image, video, text, whatever) and second layer, middleware (service layer) where you can have different tools; data stays the same...
    • Q: No, content is enriched
    • DAG: We did cover some of the value issues we're supposed to do tomorrow
  4. Unknown User (

    • DAG: Five things to cover this morning
    • Pick up on trying to figure out the traits of the things we want on the platform right away
    • Q: Disparate collections on one hand, fragmented services on the other
    • At end of first year, would like to see Greek/Latin/French/German/Arabic, up to 1700, dealt with
    • Infrastructure where you could start with what projects like ours have, then thinking more broadly
    • Don't want to make this look like ARTFL or Perseus
    • DAG: First suggestion, it's more helpful in part of discussion to drive out characteristics of different services, rather than looking at particular projects
    • More important are sub-bullets under each project; let's talk more about characteristics of services that would be valuable
    • #2 - characteristics of platform that are important
    • How do we move ahead in building what it'll look like, what best approach is, especially in rapid timeframe
    • Then, move ahead and look at outline of deliverables
    • Year 1 - deeper elaboration around process for partnership model, deriving different services, defining platform
    • Let's look at deliverables, look at your feedback
    • Fourth item: discussion of defining what success looks like
    • Fifth item: work around value statements, what is the value for different communities?
    • Placeholders for value statements; helpful material for using in other parts of the proposal
    • No time for deep conversation in any given area, but we can get your thoughts up on the wiki and use that in the next iteration of the proposal
    • Q: Don't know what we can do, better to do something well than lots of things badly
    • Need to define success
    • To work out how we do video well is going to be hard; taking one project is fine, but have to look at all of what's out there
    • Not necessarily a reason not to partner with video projects, though
    • Q: Looking at primitives of integration, API, mashup - high priority, low priority is specific APIs and media types?
    • Q: What's holding up Bamboo is "what is it?"
    • John Norman provided one articulation that resonated with people - attempt to address problem of R&D vs production
    • Lots of R&D that sorta work for limited groups
    • Yet Another Collaborative Editing Environment
    • Nobody gets over the hump of making something real infrastructure
    • Bust it out of not-quite-documented, not-quite-robust, but clearly valuable
    • NSF: $16 mil grant for HPC environment to do that in the sciences
    • How do you get it past that?
    • We can't get the scale, we're building little silos because of infrastructure issues
    • Q: This is still quite hard to get acceptance of
    • If you pick one example, one tool, and productize that well, the people who liked the other ones will have a problem
    • Have to get enough people on board to be happy with the product
    • In UK, we've only got Open Middleware Initiative - take tech built in UK universities and productize/support it (high-performance computing, etc)
    • Not so successful in pushing it back down to projects that are using it
    • Still inclined to say "eh, we'll build our own"
    • Hard to say in 5 years why uptake hasn't been greater
    • Community involvement, enough people involved, is critical
    • Q: Certain tools and facilities and resources that are a total blank slate
    • Spreadsheet, JCR, etc.
    • Then there's the full page end of things - specific method of analysis
    • There's a gap there in the middle; things that can be reused for multiple methods of analysis, but not as general as a spreadsheet
    • One of the problems is to find those things in the middle
    • Q: Two things we need to decide - audience is one
    • Focusing on two middle groups of scholars
    • Deciding based on demands of one's audience
      *If we have a stemmer in there, people have to know about stemming
    • To be able to do community design, you're demanding of all the groups involved that they engage with the problem in a certain way
    • If we want something that's more creative, requires more engagement, need to understand that might not be popular right away
    • Popular - ready materials, doing obvious stuff that they haven't been able to do (Google-type approach)
    • Think about content: existing content, and a lot of page images with metadata
    • People who might create new content when what we've done moves along
    • Without specifying what we're willing to work with (text isn't easy - what's it marked up in? what flavor? do we say just xml? who's going to make it?)
    • Draw some boxes, put things in them, and say "we're going to work with this stuff"
    • DAG: This relates to what we're doing in year 1 and success
    • Q: 2 and 3 are established criteria kind of things; thinking back to Explore/Plan
    • Is this to be done right-off, first?
    • Defining these criteria sounds first - not good to do that after you've started iterating
    • Is this end of year 1, or end of month 1?
    • DAG: In this section we haven't yet broken the workplan out into quarters
    • Q: Good as year 1 outcome, not necessarily month 1
    • DAG: Short, iterative cycles because other streams of work will inform them
    • Having some discussion about whether we can make progress on some of these things before implementation starts
    • In late fall, can we start answering these questions?
    • Architectural whitepapers once proposal is submitted - filling the lag time between funding cycles.
    • Comments on whether these are right deliverables?
    • Q: Notion of using appliances might be a platform for looking at a variety of different kinds of contents
    • Not setting constraints, but facilitating a variety of potential
    • Q: Under 7 - legal and policy issues; add also financial
    • If you group 7 and 10 closer together - not going to imiplement a cloud-deployable appliance until you work through legal issues; this will tax your patience mightily
    • DAG: Yes, some of our thinking was that we would be trying to figure out how to implement ealry forms of service platform without dealing with that
    • Q: Parallel effort- this will be a big issue especially with Big 10
    • DAG: Link to Common Solutions Group (CIOs for 35-40 universities, including CIC schools; just made a commitment in last meeting to form a series of working groups to help address some of these issues related to cloud-based services)
    • Q: They have infinite time, Bamboo has short time
    • Q: Maybe this is important characteristic for selection criteria - minimizing that as an issue
    • Q: If those 8 main things are the big categories, and 19 get slid underneath, because they're more like details
    • DAG: We want to have a chart that we can break down into quarters or half-years
    • Q: In some tactful way has to be addressed - "so what, who are users, why do they care?"
    • Right now, people don't know what it is, people wouldn't participate at this point (people I work with); people have drifted away
    • These people are Mellon's clients, funded by Mellon
    • How do you evaluate this, what's there, what's the product, what is it doing?
    • These are the humanists who are doing some of the most productive work, people to work with to get stuff done (research/teaching in humanities), most of the people I'd work with aren't here, even Mellon-funded ones
    • How to re-engage them?
    • What is the "there"? This is couched in terms of productivity, efficiency, that's all good and will go a certain way, but we need some examples of why this will make a difference, why invest today
    • Q: I agree; 18 months ago if you read the original proposal, it said it'd build shared services to help with A&H research; it still says that. So what have you done? What thing are you building? We have to articulate what it does.
    • Q: Is that an issue of the proposal, rather than what we're trying to work on, what are the goals?
    • Proposal needs to change to state a set of problems and goals that will be addressed, but that might be different from what we're trying to do now
    • DAG: Looking at one sub-section, without the context of earlier parts of proposal
    • Once we finish this painful process of deliverables, 4.3.3 - value, and places that are highlighted, will soon get into discussion of crafting value statements that go into that section, some will also help with earlier parts of proposal
    • In a moment we'll be talking about specific arguments for different audiences
    • Q: Internally, project has made a lot of progress, but in articulating this to an outside audience, explaining to my upper management - I can talk about SOA and value statements, doesn't mean anything; how does it help humanists on the ground?
    • DAG: Will get to more of that right after break
    • Only way we can make a transformative process to take a dispersed ecosystem and evolve to a place where we've got sustainable/shared architecture is through tough issues
    • Q: These deliverables are subordinate to the "why should I care?"
    • Can we think about deliverables until after we've decided where we're going?
    • These are means, not ends
    • Depends on "teaching, researcher's output, and learning" - that's what universities do
    • DAG: If you see what we've written in case statement, we've made 8 short arguments at highest level for case for Bamboo
    • We will add to that, refine it more, and some of what we'll get in value for this piece will add to that
    • All we're doing now is getting more clarification on this MAoW - last chance face-to-face
    • Q: One more comment - we're looking for the keys under the lamp right now (lamp of people who have come)
    • In the next year, need to engage people who didn't come, who didn't see connection between their work and Bamboo
    • Many of them (my colleagues), are doing work that people find useful
    • "Deliverable" or not, but need to engage a broader audience of faculty is critical deliverable in first year
    • Q: But not in section 4.3.4
    • DAG: Do we have the right deliverables? What does success look like?
    • Is the success "we have to have more faculty-driven digital humanities projects understand why partnership is important?"
    • Q: I'm here interested in content, projects, cannot speak to technology stacks
    • But first two things that platform needs to support are scholarly networking (might be built on something else) and atlas (relatively unclear and circular); we need to push the implementation to that third area more (other things)
    • As deliverable, would downgrade scholarly networking/atlas support (has to be done, who else will do it?) but have to make access to collections/projects/something based on work that people do
    • DAG: ASAP, can derive out content/tool services that are going to be of value to broader Digital Humanities scholarly community
    • Q: Craft some statement that leads to a conclusion of saying that the service platform is a delivery vehicle which provides a place to put things, provide that ability to weave things together
    • That's the principal thing - have to till the soil first, then throw out the seeds
    • DAG: This is why we're talking to people who are leading projects right now
    • Q: You have to figure out crops before you till the soil
    • Q: To have a platform to grow projects in, need to have a prepared space for them to be in
    • What's described reasonably well is what the container is, to provide portability
    • Place for weaving a tapestry of some sort
    • DAG: A lot of things relate to the development of the platform; successful ways to work with particular projects so it doesn't break down
    • Q: Workplan and deliverables together seem like the right set of things, but what we're pushing for is adjusting priorities, or giving priorities
    • Actual things described seem right
    • DAG: *But prioritize focusing on some services that matter to digital humanists today, particularly related to content*
    • Who to partner with in year 1
    • Q: *Written guidelines and defined connection points (APIs, suggested standards, crosswalks, uses of standards); This is a written thing, not a software thing, will outlast software, is very important*
    • Q: Establish might mean written document for external/internal consumption
  5. Unknown User (

    • Q: As written now, aimed at humanities projects - don't know how many there are, but there's a lot more humanists not involved in projects
    • NEH's awards for 2009, lots of digitization
    • Humanists as individuals are key
    • Q: 10,000, 15,000 sessions a day on current server we have; it grows
    • In a year, I want "Powered by Bamboo" on every page for me and ARTFL
    • Faster, more reliable, expandable - opens doors to lots of other things
    • There's a user base, we've had problems with scaling
    • We're at a scale where we're not tasked to do service
    • Project like mine can say Powered By Bamboo - it's great, and there's an API you can build things on
    • Get ARTFL, Perseus - complimentary sets of humanists and a general model
    • DAG: Can work for any project; can show that partnership model is powered by Bamboo, more robust, more scalable, more effective, capability to connect to other services
    • That's the right kind of measure
    • Q: I wouldn't have to budget to pay for staff member to run the website
    • Q: Would that really mean you wouldn't have to pay someone? Middleware and front-end?
    • Q: Everything we do right now - everything's generic; what do I know about this object? What points to it?
    • All services we provide are rarely basic; no reason we have to do any of that
    • We want to focus on creating data for putting in someone else's system
    • Would rather have consortial, transparent Bamboo environment than have Google do it
    • Q: It'll still cost someone money...
    • Q: But there's economies of scale
    • What we do works for a lot of different stuff
    • We thought Fedora would take care of it, hasn't in 8 years
    • Q: I share frustrations with how slow Fedora has moved, but I have to point out that recently there's been a new wave of "next generation" developers who are shoring up Fedora; lots of work with Drupal and Fedora; very promising
    • DAG: But aside from discussion of Fedora's worth...
    • Q: Could use Fedora as a platform
    • Q: Has to be alliance between Fedora and Bamboo, or I have more developers/leaders already committed to Fedora, I'd have to put my focus there
    • "Scholars' toolkit group"
    • We should see voluntary enthusiastic correspondence between PB and Fedora if we are succeeding
    • DAG: In brief description, we talk about for future generations of appliance, building in services from Fedora, Collection Space, etc.
    • Get a suite of those enabled and available, each institution/project doesn't have to run them
    • Q: For Fedora community people, if applications coming out of that have an icon that say "powered by Bamboo" that's a sign of success
    • Q: May be evolutionary path; Fedora can also facilitate a distributed environment; maybe that venue is step 1 that allows integration to happen, so you have a role for Bamboo to play
    • DAG: What else does success mean?
    • Q: What if success were ability for existing repository to build easily something addressing the needs of a researcher using Bamboo services
    • Q: To me, early success in Bamboo will be some exemplars we can point to-- we want to say "look what these folks have done using Bamboo!"
    • Could do that in any field
    • Can't solve everyone's, but have a successful exemplar
    • Doesn't have to be Classics, can be any nice case study
    • Q: Mellon has invested in a number of projects that want to work together, but don't have the infrastructure
    • Can you say "get me all Greek" and have it just show up from wherever?
    • "Add your inscription to this repository, and it'll pop up someplace, and someone will do something useful with it"
    • You need to take existing things and combine them; can't start from scratch for anything in year 1
    • "We're going to reconnect them in an efficient way and have a bang"
    • Q: Some example of content plugging in
    • Q: Something big like Ibo, a nickle-and-dime project where Internet Archive is a million bucks
    • Ibo is problematic
    • Q: Our work with Ibo has paid off well
    • Q: Ibo is existing, hard to use, had a purpose; making it accessible to people
    • Isn't easy for people to do much with at the moment
    • DAG: General point is that one measure is that we have one or more exemplars that are building from partnership model with some kind of connection to content
    • The particular ones is something we have to figure out
    • Q: Success is having at least one
    • Q: Ibo is going to leading early modern people, their eyes glaze over, they say they don't care
    • If you give a different field the same tools, they're all over it
    • Make sure you don't have a great collection nobody uses
    • Success for Mellon has got to be "who's using it" - was new research, teaching/learning enabled? Transformative thing? If it's just incremental, then why invest now?
    • Q: Hard to make the case in a one-year project
    • Q: Pick something where there's a bottleneck; coalition of colleges doing editing; they do it because they're early-adopters
    • Evidence that others would do it if they had the infrastructure
    • Connect editing with tree-banking would be more attractive
    • Existing things that work in small environments, we know people like it, break it out
    • Other people would have access to it
    • In a year, you'll have a little bit of an effect, and you'll have something
    • Q: Agree it's a success overall, not necessarily this particular piece
    • One dimension, Atlas and Recipes
    • Approach that was taken, small in scale but yielding great things, but Bamboo is trying to duplicate that; not take exact same thing and scale it up
    • Is scaling one particular problem the solution?
    • Taking that and applying to other kinds of corpus...
    • Q: Issue of editing in general, scholarly annotation
    • Want Greek, Latin, Arabic, each with their own problems
    • If you say "here's what's happened for this language" - we know, we've done workshops for scholars of Arabic and Persian, there's interest in this kind of work
    • Generic thing, how do you take it from a little area and broaden it?
    • N different preliminary solutions to the same problem; a lot of people have worked on it, no one's carried it to uptake
    • Can you make progress? If you had people editing 1001 nights in Arabic, Homer, medieval Latin and an Ibo book at the end of one year, in the same environment, that'd be cool
    • Q: Make, deploy, and uptake - too much for 1 year; success, but not year 1
    • DAG: If you look at 4.3.3, we're looking for quotations, stories, etc.
    • We want to weave in stronger descriptions of the value of the work
    • These are placeholders right now
    • Q: Missing the librarian
    • Q: Make it parallel to the CIO
    • Q: Both have ego stakes here
    • Q: Library is a key player
    • DAG: Volunteering to write a half page, by the end of June
    • "In this new world, it would look like this, and would have this benefit"
    • First or third
    • Q: So what does NEH do; "a rounding error on the NSF budget"; zero stimulus money - so how do we change that?
    • Does this allow us to reposition who we are and who we could be?
    • Budget is a statement of society of how important you are; that's a metric of where we fit?
    • What do people listen to? What would be success to draw attention in federal government?
    • Q: If you look at Obama's Open Government Memo, keen on government agencies working with communities not just in government sector, but commercial, education, non-profit
    • Possible; new chairman hasn't shown up yet, but fair to say that NEH is positioned to work more closely with community-engaged projects like Bamboo
    • NEH doesn't have flexibility Mellon does in funding something like this
    • Will be talking with David and Chad about how NEH can participate, at least in pieces of Bamboo
    • DAG: From funder's POV, you do have some things you're looking for in terms of solving problems everyone has
    • Q: ACLS cyberinfrastructure report articulates the need for a shared cyberinfrastructure, how that'll help the humanities; helps us from having to fund the same thing over and over
    • Q: Another program foundation officer asked how we could get buy-in at federal level; to be sustained over time, people have to understand it
    • Why does it matter in the country or world?
    • Non-trivial, powerful topic
    • DAG: Overlap with what's happening in quantitative social sciences/sciences is substantial
    • Want to share investments across disciplines
    • Something missing from overall proposal - connection to communities outside of university
    • Part of investment is making content/tools available to anybody
    • We want to strengthen that
    • Q: Content is located at private museums/libraries
    • Q: Encouragement to connect
  6. Unknown User (

    Just one comment here - I'm a bit unclear of the motivation for an alternative platform, and the amount of resources this might require.  Maybe the rationale could be made clearer or an example given that would help us see the motivation...

  7. Unknown User (

    I have added a child page to this one which aggregates all the Platform Value Statements to date. I will updates this as more trickle in.