Bamboo and shared services

"Risk that people won't use the services we propose. If Google Maps puts out a service, I'll use it because I know I'll get a few years use out of it at least. Have to have some trust; Bamboo will have to partner with organizations and monolithic institutions to borrow their sustainability in that aspect. I'll only use a service if it's really relevant to what I have to do right now. Will have to partner with people in cloud of tools to only develop tools which are absolutely relevant to a particular project right now." (W2, Q&A, Thursday afternoon - Turning Themes Into Shared Scholarly Services)

"PB might come up with "core services" that could be helpful to software engineers as they build API's." (W2, Tools and Repositories II, risks and rewards, plenary notes)

"What was incentives for institutions - building tools PB wants, not just what you want. Making something Bamboo-compliant could mean sacrificing exactly what you want to do" (W2, Tools and Repositories II, risks and rewards, plenary notes)

"Felt like there's a lot of tools out there - make it possible for people to find out what tools are there, and give them access. Blend together use of different tools." (W2, Tools and Repositories II, risks and rewards, plenary notes)

"Demonstrator projects: Service to get an image that facilitates sharing of content across multiple formats. Same sort of thing from text; multiple texts from multiple archives and ask a question to analyze across all of them. Represent discovery of content as well as tool discovery registry. Entity extraction: extracting people, locations, other things people can specify ontologies for. Mapping dates to MIT timeline, locations to Google Maps. Pull annotations across repositories. Zotero to annotate your collections, then send it to MONK (would have to be text related). Scholarly mashup environment - stitch together multiple tasks." (W2, Tools and Repositories II, plan, plenary notes)

"How is scholarly practice attached to a service identified? What is the method for selecting that service?" (W2, Service Framework, questions and concerns, plenary notes, group 6)

"Has been done already? Succeeded or failed? Ownership (privacy, anonymizing). Measures for success of failure" (W2, Service Framework, questions and concerns, group 6 notes)

"What is the big win for the institution? Priority of the services. Are we meeting the needs? How to assure connection to need of participation." (W2, Service Framework, questions and concerns, group 6 notes)

"How to make it relevant, and convey the message of relevancy. Services become a personal research environment? How to share them. Privacy and how people can opt in. Peer review for the process. Enhance and transform research in humanity should be central (building around that). Should that be driven the services?" (W2, Service Framework, questions and concerns, group 6 notes)

"Sense of disconnect between presentation yesterday of technical architecture and need to get input from A&H scholars. Feedback was that A&H scholars didn't see themselves in the list of tasks or boxes in the diagram. Belief that Bamboo can deliver some sort of tools/architecture that will support scholarship. Somewhere we've lost the principle of mapping scholars to strategic direction of technology." (W2, Service Framework, plenary notes, risks and rewards)

"We can't produce everything, we can only specify a small portion and write a grant to produce something that enables cool tools and changes to scholarship. Everything from sharing services to redefining scholarship. How do we sort through these different agendas to deliver something concrete?" (W2, Service Framework, plenary notes, risks and rewards)

"Why we need to reach out to developers. The relationship between Bamboo shared services and tools (and developers). What they need. How to encourage them to work with Bamboo services.Tool evangelist office that takes identified gaps and works with developers to fill. Development of APIs so tools can interoperate and so tools can use services (and become services). Documentation of APIs. Tool review venue that examines tools as to whether they follow best practices (including APIs). Give credit to those who collaborate. Contests - run contests to fill gaps and celebrate stuff" (Tools & Content Partners working group, Tools and Content Contributions to Proposal, 1/20/09)

"As people talk about service framework, have to understand how A&H scholars' needs map to services. How to regain some of that connection, empower A&H scholars that their needs are being addressed Or allow us to talk about that back at our institutions. Discussion of different methods to support this. To continue moving forward, we need to maintain the vision of what the particular things are that are important to support. What are the use cases, visions, etc that we agree on as a community that Bamboo should help enable? How do they map to the tasks, green boxes?" (W2, Service Framework, plenary notes, risks and rewards)

""Ideally, adherence to development guidelines and standards for data/content interoperability will be encouraged by incentives to build services more likely to become Bamboo "Common Services." -- I agree with this and wonder if it could be developed a bit more. Provisionally, is it possible to say something about what the incentives are (money, support, collaboration, recognition) and who provides them (Bamboo, external funding agencies, leaders in the Bamboo consortium)?" (Shared Services working group, Program Document Sec 3.1 - Preliminary Overview, Jim Muehlenberg, 2/20/09 comment)

"Interplay between deciding what consortium structure might look like, and what kinds of shared services would enable it. Org level at higher level has impact on shared services kind of thing" (W3, Shared Services, Report: Proposal and Moving Forward)

"Q: A lot of talk about confining/setting the limits. From an IT perspective, what can you offer? Suggestions for what the borders of PB are? What are the constraints we should think about as we move forward in the next 24 hours? Greg Jackson: From IT hat, what are contributions PB can make, rather than setting boundaries. It's priorities, not boundaries. If I had to choose priorities, we saw a lot of things based n different environments, not sure whether those environments had to be different to get the functionality. What is limited set of platforms upon which most of the things we want to do could be made to work. More of a reference-expressing exercise. "What should I develop?" -Start here if you don't have any idea where to develop. Priority #1 - that kind of standards. Providing guidance to each other." (W3, Perspectives: Information Technology, Q&A)

"local and incubator ... will incubator be provided by a Build Partner, but be available to the community? Steve: yes, that's the idea, with some level of invitation / vetting / conformity to a standard deployment infrastructure. worth looking at the SAKAI community of development as a developer/consumer "marketplace" ... how different little apps are created by different institutions all over, and they grow up into part of a core service as part of SAKAI if and as they prove interesting to the broader community." (Shared Services working group, Program Document Sec 4 - Discussion Draft of 9 March 2009, 3/11/09 discussion notes)

"are Common Services "foundational or broad"? or are they characterized by those more enterprisey terms in the paragraph following the "Capsule Summary"? Not exactly clear. Steve: yes, a bit hazy ... my hope is that we'll clarify better questions about what level of a "wedding cake" type stack we might be talking about (utility, agnostic, task, for example, as in the W2 wedding cake), and also to describe what qualities might be outcomes of the refinement process that renders a piece of software a "Common Service" ... Bamboo-certifiable, or whatever that turns out to mean. is "foundational" a level of a stack? or is it of foundational interest to A&H scholarship? clarification of and distinction between these ideas would be helpful. Where does the word 'tools' come in? Scholars aren't going to use services in the technical sense of the word. They're going to use things that are built on top of services. In a marketplace there's a mixture of stuff that goes to different audiences ... so it might be interesting to tease out who is interested in what and where they find it ... perhaps that's a part of the marketplace that's not as well defined in this draft." (Shared Services working group, Program Document Sec 4 - Discussion Draft of 9 March 2009, 3/11/09 discussion notes)

"Clearly, a lot of our activity definitions are really recipes describing business processes or workflows and we still need to drill down and find the core technical services needed to orchestrate the worklow.The services atlas needs to expose these technical services, in contexts that help to identify pain points encountered by scholars trying to work on their selected problem, and therefore the work that needs to be done to enhance existing tools or build new tools that eliminate these pain points, resulting in greater efficiencies and effectiveness or new ways of doing things. The wedding cake or brick wall diagram is probably not the best way of representing these services because they are ubiquitous and can be used or re-used in many workflows. On the other hand, dozens or hundreds or thousands of recipes will not help to expose patterns and core recipes (or service usage models.) In this context, it will be important for scholars to have a basic understanding of what a shared technology service is, and the role it plays in the orchestration of workflows. Similarly, business analysts and developers need to understand the business requirements to be addressed. And funding bodies and program managers.need to be able to see at a glance what benefits will be achieved by addressing a particular set of priorities." (Shared Services working group, Program Document Sec 4 - Discussion Draft of 9 March 2009, Judith Pearce, 3/18/09 comment)

"While I am not an epigrapher, it seems to me that the digital opportunities of this discipline -- and of the broader discipline of archaeology -- are quite well understood by its practitioners. The real problems re resources and the fact that the disciplines are often what the Germans call Orchideenfächer or 'orchid subjects.' Will Bamboo smile on or ignore projects like a (not entirely hypothetical) dictionary of 'West Tocharian colloquialisms'? An important question, and I wish I could be assured of the smile. But I worry more that in joint planning, however well-intentioned, the little and abstruse subjects in odd languages will get pushed even more to the margins." (Tools & Content Partners working group, Analyzing Scholarly Narratives, Martin Mueller, 3/27/09)

"Moving toward model of how can universities and colleges band together and develop increasing services, all the interconnections there. A fundamental model emerging is cloud computing - Google? Higher education? Cloud - lots of positive responses, but also people scratching their head; should we be focusing on this now? Part of Cloud is an investment that's not terribly relevant for a large set of Hum faculty. What becomes increasingly relevant in 3/5/10 years?" (W4, Overview of Program Document)

"Also driven by notion that PB itself has lots of different individuals/perspectives/ etc built into it. Moving one gargantuan project forward in one path, will get through 2 or 3 of the things within 100 years. Have to break this up a bit; how do we set priorities?" (W4, Overview of Program Document, Bamboo Labs)

"Final two pieces: educational working group (professional development, curricular materials), tied back to scholarly networking. Each of these are potential information components themselves; any institution will need to access these. Could be best in your own learning management system/iGoogle/etc. to be exposed in different ways. Help with overall information environment. Need to help w/ each existing in its own way" (W4, Overview of Program Document, Section 3: The Forum)

"Struggling w/ dealing w/ technology part - how do we implement this? From CIO perspective, "I've got a faculty member with a particular need, but my institution can't support it; could I go to PB and connect there, and suddenly that need is fulfilled?" If you want to create an environment that you trust, and one that's sustainable/manageable/other -ables, you have to have some kind of ordered structure. Think about providing a service: I'm providing an image processing service; if you want all the "-ables", I can't be the only person running it - if I fall off the network or a hurricane comes through, someone who's depending on the service can't access it. Need a couple other folks running it. Great for 1 service to just talk to people, but what about 100 services? -> "fuzzball diagram" of W3." (W4, Overview of Program Document, Section 4: The Cloud)

"Notion around idea of creating a "Bamboo appliance". In the box is where, over time, services that the community deems important are stored and managed. Some of the widgets and gadgets I might connect to and use; those could be there. Now you have this box, which someone else could be managing - I agree to put it in my data center; connect it with all the other universities hosting it; multiple points that back each other up. If a train derails at UofC, you don't need to know we had the derailment; your project is still working. When you want to use a service, you could go to, just like going to you could be at one of a gajillion servers. Can PB do that so when services are at that level, you don't need to worry about it - it's just part of that appliance and it'll be there." (W4, Overview of Program Document, Section 4: The Cloud)

"Creating an environment that works that way so it might not be something we realize the benefit of immediately, but will over time. Can start thinking about projects in different ways - reuse things that have already been done, reduce local work. Original propositions of Bamboo, 2/3 of the time of schol projects is sorting out the technology, but we can flip that around. Can shift from tech piece back into the scholarship. That's the idea behind the cloud; within that there's a lot of other elements." (W4, Overview of Program Document, Section 4: The Cloud)

"A question about overall balance/focus in Bamboo between real infrastructural kinds of services and social networking/extension of social networking to try to change practice in humanities. See pieces of both here, not sure any of us are comfortable w/ the balance." (W4, Program Document Section 3, Discussion of Poll #1, Faculty table discussion)

"Interesting discussion about the scope of digital humanities. Clear that part of the scope of PB is "traditional humanities disciplines employing digital tech". Very helpfully reminded that there's a whole new set of disciplines that take humanistic studies to tech artifacts and activities of various kinds (Cave studies at Brown). How much of that is in the scope of PB, and how is it going to be supported?" (W4, Program Document Section 3, Discussion of Poll #1, Faculty table discussion)

"Also a point made about how these things may interact in messy ways with institutional policy (commercialize technology through tech transfer programs). Might be able to use some of the activity in PB to help establish some norms in this area." (W4, Program Document Section 3, Discussion of Poll #1, Faculty table discussion)

"Was a set of points made about the role of commercial tools/services, how we want to make use of them when they work and try not to reinvent. Some of that in the plan, but focuses more on clouds than extant services. At the same time, there's a point where we need to be more mindful of long-term stability of services. They're becoming an integral part of communication of scholarly work; what's the exit strategy if the service goes away?" (W4, Program Document Section 3, Discussion of Poll #1, Faculty table discussion)

"Fundamental concern not that services are unstable, but there's more of a danger of what we define as stability. Infrastructure cost to enable them." (W4, Program Document Section 3, Discussion of Poll #1, Faculty table discussion, Shel Waggener)

"Volatility of services is going to be real. Was having a discussion about the history of reinvention here and frustrating lack of ability to reuse work over 20-30 year period. As we move into more volatile service environments, challenge is going to become greater in some ways. This question of migration across services is very real. Content side, we probably need strategies that think in terms of preservation environments/use environments. Content kinds of issues. Need to develop a mentality that lets us be more liberal in our willingness to replicate content in different settings for different uses. Very important issues." (W4, Program Document Section 3, Discussion of Poll #1, Faculty table discussion, Q&A)

"Main points discussed: complicated and difficult and years to achieve; need to think about how to do it with what's available, how to get started. Some of these need to be separate projects (NSF?) Some important elements here: technical architecture, raising availability of existing resources, aspects of the cloud. Bulletin board - checking in on projects, etc. Overall: talking about how to use the project to hit the low-end fruit, start building out the cloud, some work that people are already doing (e.g. JStor)" (W4, Section 4 Table Discussion)

"Concrete proposal: on shorter timeline, take projects like SEASR, Zotero, etc that are already out there, thinking about ways to interconnect, and form this as the basis for cyberinfrastructure. Help them along, pull in other things (Sakai), then we take the narratives and use some seed money to go to scholars at individual universities and say "here's this infrastructure – Zotero, Monk, etc working together, let's build a narrative about what you can do." Narrative isn't abstract-- what can you do with X? If you did that sometime around a year, you could have a proof of concept for Bamboo." (W4, Section 4 Table Discussion)

"There are still gaps we can't do individually as institutions. Finding a "killer app" or "the service" or 3-5 capabilities that individuals can't support on their own, that could fall into the platform. Supported by social/institutional networking, very light governance. A playground - coming together and exploring ideas, let market evolve for itself, recognizing that there's some discussion that has to happen. Something that enables people to share their resources. Sustainability and prestige - offering prestige, sustainability. Building onto "killer app" idea - 1st implementation, service atlas is a userufl platform we can build on, but what will get atlas into every university - need AN APPLICATION that in and of itself has return on investment. Useful, and can become more useful." (W4, Section 4 Table Discussion)

"We want caution about being too dogmatic, assuming too much out of an "appliance" "It might be lots of things". JStor was successful initially because it capitalized on market inefficiency that could only be achieved by scale." (W4, Section 4 Table Discussion)

"People are presenting content without services, then what? Risks of service-oriented architecture." (W4, Section 4 Table Discussion, IT table)

"Look carefully at last of workplans - that discussion gave me sense of how we can get rapid inter-institutional leverage by being smart re: what we do. Technical specs prob not so clear to faculty/scholars, but bottom line is we could perhaps use PB as a framework. Could make use of resources at other institutions w/o doing a lot of paperwork (terms other institutions, contract,s etc) - this would be useful outcome, probably doable very quickly (start on it at least). Need more of those kinds of opportunities. Need to be more specific re: services/what we want to package here. Talk a lot about services, but there's few examples. Specificity is important to make more tangible. What services to include, which have a larger base? We've talked about Zotero - it's a nifty piece of work, but it's a piece of work that has a user base that is much bigger than PB, cuts across people in all disciplines. How much do you want to get wrapped up in that, how much do you want to say "it's great environmental stuff, but it's not a core service, belongs at some other level"" (W4, Reflection, Cliff Lynch)

"We need to be a lot clearer about assumptions re: centralization vs. distributed things. I hear conflicting stories about that in the different parts of the plan, assumptions, maybe I'm just not understanding. Does appliance go in institutions, run by PB central? If each institution runs it, how do we deal w/ federation, backup services? How do we handle configuration management/upgrade? How do we deal w/ CIOs who are unhappy about standard config, because it doesn't map to what they think they're doing re: security. Talked about exposing campus services, content, maybe held at participant institutions/partners. Also talked about re-hosting onto these appliances. Going to want some mix of both - don't think that if Hathi Trust becomes a partner, don't necessarily want to replicate book scans in Appliances, unless you've got a huge budget for storage. Ambiguity re: centralized vs. decentralized activity." (W4, Reflection, 4/18/09, Cliff Lynch)

"This is a way to communicate to a search server to let it know what kind of search can be done, but it seems to be something that will tell you that you need a natural language parser that does x,y,z and
a. So is this a guide to what bamboo supports while the Tools and content directory is a list of everything
b. You would use the same underlying mechanism for both and simply indicate which kind it was.
c. This should be something where you can get a machineable description that tells you what protocol it understand and then it will be able to talk to the service.
d. There is no interface to this" (W4 Action Plan - 4.1 Services Atlas)

"What are some example services
a. There are almost no services at the moment—many are not ready for humanities scholars to find and use. But there are many services for computation.
b. Monk, SESAR (don’t have them yet—or they are very specific. Geo-referencing),
c. If we were to pick 6 services—we couldn’t find any that would make sense to humanists.
i. NYU classical mapping service
d. Search services
e. Image manipulation services
f. What content is the service connected to?
g. ClearForest—part of speech tagging (English, at least)
h. ARTFL" (W4 Action Plan - 4.1 Services Atlas)

"Appliance Project. It must realize a complete appliance. It must deliver multiple services. It must be built on pre-defined open-source software stacks. It must constrain the number of middleware stacks. It must constrain the number of operating systems running on the appliance. It must include at least two sites (to prototype replication). It must include three layers (Sandbox, Quality Assurance, Production). It must permit "take out" (individual software developer can instantiate a sandbox appliance on her local machine). Assumption is that deployment is source code, test mechanisms, & build scripts that live in a code repository." (W4 Action Plan - 4.3 Shared Services Lifecycle)

"One Year:
Define range of OS and software stacks supported
Deploy hosting systems for the appliance at two sites
Deploy sandbox to production layer at two sites
Define and implement promotion process that includes all layers (sandbox, qa, prod)
Two Years: Scale to multiple sites (>2)." (W4 Action Plan - 4.3 Shared Services Lifecycle)

"Even hosting our web page, we need some of this stuff. Some of this stuff is proof of concept (in the project sense). But we need some components up and running and "in production". Appliance piece needs to go forward so we'll have something to build on, minimize complexity across community. We have choices for what we want to say "first generation production stuff" - move forward with that, so we can do what we want in year 2/3/six months later. Challenge of thinking along the way - planing work we're doing now is pointing in a particular direction. Probably wouldn't think about it as proof of concept - this is Version 1, but Version 1 might be really bad and we might totally redo it for Version 2. Need components in place so ideas can advance elsewhere. Appliance is one of these ideas right now; Bernie and Steve have thought about scalability, more than two sites. Could probably do 2/3 and make it work, to call it "production" - we need to do that. Or we'll be perpetually piloting and testing, over and over - deliverables won't be there that people want to depend on / use. Some things are easy to instantiate and run, behind the scenes, to get us out the gate w/o putting pressure on one institution to do it all. We have to do a little behind the scenes to get us going." (Chad Kainz, W4 Action Plan - 4.3 Shared Services Lifecycle, discussion)

"We've talked about recipes here - database with information. A lot of us have seen in projects, if you're using someone else's database for your research - that can go down for maintenance. You don't know it's failed on Saturday, but you need it by Monday. Appliance idea - greater than two, the database could be shared across all three instances. One can go down, and you wouldn't know it - it's always there. Scaling up from there; at a certain level, sometimes you realize that PB wiki is non-responsive. Collaboration environment can be something that can be housed on the Appliance. Lots of bits and pieces depending on how far you want to go. Think about how you use Google/Facebook - don't think about going to a particular server; you go to whatever machine is available, and you have access to everything. These are the kinds of things we want to look at - not just what PB does internally, but there's components like atlas/narratives/services that help interface w/ resources at JStor, etc. there's a dependable place you can go for those things." (Chad Kainz, W4 Action Plan - 4.3 Shared Services Lifecycle, discussion)

"If you have TEI encoded set of scenarios, you want to take data and derive social relationships out of it. If there's other people who want to do that, it'd be great for you to run something as a service - send data in, get visualization out. We want to run something like that as a service, but that needs to have reliability we don't have right now. Appliance allows us to build up that infrastructure - exposing services in a more robust way. Glossing over details, but giving you a sense of the model we'd like to move towards; iportant scholarly services that span disciplines are available to people." (David Greenbaum, W4 Action Plan - 4.3 Shared Services Lifecycle, discussion)

"That's a core that we want to accomplish - a useful service lives on someone's desktop. This is what Bamboo, in my conversation w/ Mellon, is what we're expecting to do. Take existing services w/ real value and re-engineer them. Demonstrate some value, how to do this core mission." (W4 Action Plan - 4.3 Shared Services Lifecycle, discussion)

"What should be the qualities of a project in this area?
-need to find the needs that interoperability serves for scholars, or the 4-5 capabilities Bamboo can uniquely provide projects
--a suite of language analysis tools available across languages
--being able to browse disparate resources by time and space on a slick UI (google map)
---visible past (mashup google sketch, google maps, wikipedia to view ancient Rome over time)
---UC Berkeley timeline tool
-need to find something that appeals to a wide group in this community
-need to find low hanging fruit - something that can be done in 12 months and show a result
-must be able to partner with tool/project/resource owners; these folks must be willing and able to share resources
-should avoid interoperability projects already being addressed (unless we're collaborating with those projects)
-must have accessible/available faculty whose problems are being met
-requirements gathering
-validation/proof of value" (W4 Action Plan - 4.4 Tool and Application Alignment Partnerships)

"Dependencies: relationships with projects and faculty. we need a mechanism in Bamboo for submitting, identifying and selecting projects (vote? selection by program staff?) content group will be a key relationship - they are working on another facet of interoperability. we need the body within Bamboo that will design or will be able to recognize "good architecture" for the reusable pieces of projects that can be come Bamboo's core technology/platform. we need awareness of projects and standards relevant to the central problems of the tool(s) selected. need to define the incentives for working with Bamboo. need to work with relevant standards bodies. need to provide a lightweight governance of architecture/standards/protocols - similar to Internet and IETF." (W4 Action Plan - 4.4 Tool and Application Alignment Partnerships)

"caution: if we select a single tool or architecture, how to maintain working relationship with those who are not served by the application that is selected? Do we address them in year two? Do we promote co-development around a core architecture?" (W4 Action Plan - 4.4 Tool and Application Alignment Partnerships)

"We need to prove that we can take services/tools/content from multiple projects and use the same framework to support them, to show we have something that can be reused, that can help us. Moved to this group because I believed we need to be strategic about choosing those tools, "this is what we'll put together in year 1". That will give us the scope for our work. What we focused on: can we define what these projects will look like? What do we need to find re: tools?. Rundown of tools - posted on their wiki page. Things that scholars need, 4-5 things PB can provide to individual projects. Appeal to wide part of community. Low-hanging fruit; tools that already exist. Have people in those projects, resources in those projects that are able to cooperate in this effort. Mellon projects are readily available, encouraged to cooperate. Should avoid interoperability projects - don't want to re-invent the wheel. We don't want to repeat work once we're collaborating with groups. Must have faculty/scholars who understand why they want to use the tools, help us understand requirements, do testing, validate it's working." (W4 Action Plan - 4.4 Tool and Application Alignment Partnerships, discussion)

"Need to be working w/ services framework/processes to make sure we can clearly abstract reusable things. Pieces that relate to that: need people available in project who can identify things that can be generalized. Need lightweight governance - going off re: encouraging collaboration, we felt that lightweight governance model that supported interoperability between tools but was not a huge bureaucracy that required a lot of resources to maintain. Model: Internet Standards and Protocol - loose affiliation of industry people that put in request for content re: how things are interoperating. This is how we should encourage tools/services to play together." (W4 Action Plan - 4.4 Tool and Application Alignment Partnerships, discussion)

"Very specific: what we need to do is select tools and services to begin. Set of recommendations: uses Mellon list (Chris Mackie has a chart), beginning there. Take this list, a set of criteria for evaluation, to see what makes sense for us to do (and early on). Suggested some of the criteria we might want to use: 1) Extent to which tools/services are data-driven because that makes them more ready to use; 2) Germane-ness to humanities (if Mellon is funding, should be), 3) Zotero's much more extensive in range of applications; extensibility is important. Think about criteria as a way to think about our values as PB. Adjusting the list according to what we value - add and subtract as necessary. Further down road: thinking about how to incentivize development of the list by having institutions who have develop tools/services that aren't part of Mellon set to join us, build with us in the future." (W4 - Guiding Principles for Bamboo, Group 3)

"Principles - began by thinking about what should guide PB. Imperative on us to move quickly for two years only. Get something - exemplars, prototypes, etc in first year. Then , populate/add to it, etc. during 2nd/3rd years. Use extensible, build it up." (W4 - Guiding Principles for Bamboo, Group 4)

"Urge community to not think of this as a proof of concept - need a long-term vision and build out the real thing. Need to jump in and build the real thing instead of a prototype. Leverage the exiting body of work (not just not reinventing the wheel, but showing what relationship is between what PB wants to do and what others are doing/have done." (W4 - Guiding Principles for Bamboo, Group 5)

"Opened up with "focus focus focus, concrete concrete concrete". Tangible. Ended up with a possible definition of what PB is: there are a lot of projects that go through R&D phase, but this is like getting to market - 10x cost of R&D." (W4 - Guiding Principles for Bamboo, Group 7)

"Working w/ existing DigHum projects, possibility of refactoring so they could expose services; substantially different endeavor than just sharing resources across a broad community. Opportunity to take steps forward to work with those repositories, connect to services/tools in a stronger way. Haven't defined where to start with this; broad approach to take a lot of resources. Shared services lifestyle - leads up to deployment by PB consortium for sustainable services that can be used by many people." (W4, Discussion of Section 4 Poll #1, Q&A)

"Services Platform: infrastructure we run it all on. Scholarly networking / Atlas could be seen as sitting on services platform. Place where we can take services that have become common, important to community, and work through a lifecycle that eventually moves them into infrastructure. Responsibility of the community to maintain so a project doesn't have to maintain a resource forever for the community." (W5, Overview: Major Areas of Work)

"Tool developer/CIO: interest in leading in services platform, discussion of "Yahoo pipes" model - if we have a rich enough set of tool/content services, can use these environments on top of it so people can build their own remixes. People brought up work done around local, choices re: research environments. Sakai 3 - virtual research environment, involves some of what's happening in scholarly networking. Homegrown tools that could be refactored. Solving problems at scale, to help with services platform." (W5, Overview: Major Areas of Work)

"Stepped back to try to look/classify things wanted in initial step of process. Split "servies we need to offer to support Atlas/Networking" and "other services more generally useful to scholarship in the Humanities". Content, content, content. One of the issues we're trying to address: what're the right deliverables for year 1? What to do to show we're adding value on the side of the services platform?" (W5, Report Out: Major Areas of Work, Services Platform)

"Laying out outline for what criteria would be in thinking about projects we want to pursue on services platform to augment projects already underway." (W5, Report Out: Major Areas of Work, Services Platform)

"Specifically talked about the language in a couple spots during the discussion; related to the ambiguity of trying to present virtualization as a solution for services that will be made. What we gain in terms of portable containers. Services that are unique and self-contained in their own project space; existing in multiple places. Process of osmosis for scholars to mix-and-match content w/o stepping on toes of owners of those project spaces that are containerized. Some language needs to be either very deliberate (we are doing virtualization, in X/Y/Z flavors" and story of why this is necessary part of project. why is it a good thing? Even in introduction, talking more about implementing infrastructure than why it's important." (W5, Report Out: Major Areas of Work, Services Platform)

"Re: not stepping on toes of content owners, one of questions about value should be addressed - WHY. If I have those 100k digital surrogates of archaeological artifacts, why do I want it to be available?" (W5, Report Out: Major Areas of Work, Services Platform)

"Did talk about "refactoring" and what that might mean, because there's several different levels -- one form, as alluded to, is making it available as a virtual appliance. That's the simple and most plausible form - allows someone to take a thing and make it portable and useful. Other levels of refactoring, and even the term will probably shock people-- especially if they have a mature application, unless they're partnering to say "let's dissect my project, find out what you want to re-deploy in a more granular anatomy to make it useful in more environments than what it was engineered for". Have to be cautious about term "refactoring"." (W5, Report Out: Major Areas of Work, Services Platform)

"Previous two groups are all staking a claim on something we too seem to think we're providing. "Everyone's been pissing on the same tree"." (W5, Open Discussion: Major Areas of Work, Services Platform)

"Need to be able to deliver on something that people can use, not just on PB services (internal, like scholarly network). Guidelines and documentation for external purposes too. These exist in the deliverables as we have them." (W5, Open Discussion: Major Areas of Work, Services Platform)

"Measures of success: how much of an effect can there be in one year? Probably not earth-shattering. Projects have a "Powered by Bamboo" sticker that you see. Pick some projects, big projects w/ well-established user base, and have Bamboo become the provider for at least one. Projects should have established user base so it'll reach more people. Have to work with existing content; have to be able to do this. PB should become a service, not content, provider. Shouldn't expect content. If PB provides services, and scholars create content, that'll prevent Google from getting there first. Basing interoperability on other big projects like Fedora. Measure of success is voluntary enthusiastic correspondence. Possible to easily use existing data sets / corpora. Can easily build on top of things that will meet needs of researcher. ORE for humanities, or particular discipline in first year." (W5, Open Discussion: Major Areas of Work, Services Platform)

"4.3 platform services document [in BIP Discussion Draft v0.5]- most technical section. One of deliverables has to be a less technical description of this area. Better account of problems/goals this technology will address so there's a reason to create the tech." (W5, Open Discussion: Major Areas of Work, Services Platform)

"Parallel streams of work: creation of set of documents or descriptions about what the criteria are for development of Appliance software, and what standards are for interacting and for partnerships. Also, creation of software itself. So appliance sitting on top of a cloud, and 3rd thing is set of relationships w/ other pieces of the project (atlas, networking) and outside partnerships." (W5, Open Discussion: Major Areas of Work, Services Platform)

"Outside partnerships - strong element of what will drive forward use of Bamboo. Proof to people already using kinds of technologies, what PB can do to make it better." (W5, Open Discussion: Major Areas of Work, Services Platform)

"[Results of vote] Services platform: 49 yes, 1 abstain" (W5, Preliminary Vote: Major Areas of Work)

Bamboo tags: 

Add new comment