Project Bamboo wiki: W4 - Action Plans

This was originally posted to the Project Bamboo wiki at https://wiki.projectbamboo.org/display/BPUB/W4+-+Action+Plans (https://wiki.projectbamboo.org/x/aACV), last modified 20 April 2009.

Discussion

Scholarly networking

  • Interested in scholarly society participation
  • Plan going forward: signing up institutions/societies to do some work
  • Over a 3-year cycle
  • 4-5 institutions wanted a leadership role
  • Q: Was preference for disciplines to do interdisciplinary work?
  • Or easiest/quickest way to get going is to go across universities?
  • A: A lot of discussion
  • Not restricting it to disciplines chosen to start with
  • Was one possibility of 3 societies that want to do something now
  • Several institutions want to do something now
  • That could be enough to get started

Scholarly Narratives

  • Most important: finding success stories, make available as recipes
  • Also make them available in terms of materials for things like communicating w/ deans
  • Tip of the iceberg kind of moment; potential for various kinds of infrastructure

Recipes

  • Plan -= create selection process for choosing narratives to focus on
  • Selection of tools
  • Has a visualization - will post after break
  • Need to be using visualization tools for what's in the narratives, what'd be in the recipes
  • How recipes would be used in different narratives
  • A number of visualizations exist - one that there already existed shows patterns, how different descriptions can use same terminology
  • Example that we're looking at showing - "I need to do this", "I need this" - we'd see a tree of the various different things
  • Narratives and recipes on one level, but dependent on each other so there's very specific kinds of narratives that work if we have specific core building
  • Those narratives/recipes are focused on that core in the first year
  • Longer timeline for recipes: more general and generic things that can be visualized, collected at large
  • For this: thinking in year 1, a proof of concept of Bamboo, there needs to be a lot of dependencies
  • DAG: Dependency connection between narratives and recipes
  • What we do in year 1/2, elsewhere in cloud, this could be a source of seeds for this
  • Made a quick decision to leave these sections separate, even though there's ties and connections
  • Inerconnection w/ service atlas, too



  • One last point: Haven't talked abut audiences
  • Talking about recipes in general - need to be focused on audience, who will be following this
  • May have to be multi-dimensional; may have to be version of recipe for tech person
  • Building certain kinds of things for a scholar in general
  • Audience hasn't really entered into consideration
  • DAG: A little discussion re: data model that exists behind recies/narratives
  • A fair amount of discussion - some people like "Recipes" , some like "Workflows"
  • "Cookbook" of recipes? - different kinds of cookbooks for different situations



  • ManyEyes visualization - doesn't need a lot of talking
  • "I need to... get/go/do/find/be/stop/start/make/see/know/take/learn/be" - can scroll through the entire tree
  • Sitting on top of Twitter feeds, and organizing them
  • Can collect any number of narratives
  • Some quirks n using ManyEyes - we could probably build a visuzation tool that would be better suited
  • *DAG: We build models for a lot of data, and harvest it in a variety of ways

Tool and Content Guide - no one came

  • DAG: certain amount of interest, no one wanted to take leadership

Education

  • Wide-ranging discussion, came up with principles to form background of education
  • Should have a dynamic interface that connects research/teaching materials and brings them together
  • Also, a selectively curated set of examples
  • Dependencies / overlaps w/ narratives
  • Visualization/relationships are important
  • Also important: break down some false dichotomies between research and teaching
  • For first year: start by beginning to select some sample projects, other things to highlight as models for what we want to do
  • Start talking with other groups to look for overlap and dependencies
  • Year two: Assessment and analysis of kinds of material from first year
  • Education technology organizations have research
  • Were aware that there's already sites that list syllabi and assignments
  • A lot of relationships w/ other tools
  • Went broad with the qualities rather than saying "every Digital Hum syllabus that's ever been used" - that's impossible



  • DAG: False dichotomy came up a lot
  • For a lot of places, there's a teaching focus that's important
  • Feeding into narratives/recipes piece
  • Concrete ways to deal w/ points that were made here; do we have a separate part of PB around this, or do we try to pull this out of other working groups?
  • Is this a labeling/naming issue, too?
  • There's something fundamental here, how do we appropriately structure this into short/long term



  • We had some of the same questions, but not strong answers
  • Scholarly narratives - selected in first year; should be able to be looked at through educational lens
  • How/what kind of tool, way of looking at things; ways to focus/highlight how education works, what role education plays
  • Pedagogical problems need to be identified to get a start on things
  • How we do this - ?



  • Took qualitative approach to PB concepts
  • Providing a front 'age that will create a certain amount of enthusiasm for Hum scholars who aren't involved
  • First year goal: related to syllabus project
  • Scalability - developing that kind of tool, making syllabi more digital enhanced/friendly
  • Dealing w/ more advanced projects in DigHum; demonstrating range within DigHum
  • Facilitating more meta-critical awareness of digital culture/schools
  • Very much enhanced what it means to Hum scholars in particular
  • Feed back into Hum tradition



  • Tried to define ways in which articulating relationship of education to teaching
  • Create cyberinfrasturcture for research - undergrads can use too
  • Also, just mentioned, a meta-reflection on how we represent ourselves digitally
  • Ability/capacity in moving to digital environment; raising specific question of representing discipline
  • If system is well-designed to get new/unique data, raises discipline specific questions
  • Teaching -> advancing disciplinary conversations
  • Nice to model, bring to the front



  • Education needs to be fundamentally up front
  • On the front page, we don't have opposition between research/education
  • Facilitating that relationship
  • What we'd be producing: students using technologies used in Hum research
  • Researchers need to communicate to students
  • Bringing this to the front page



  • Teaching on two timelines: timeline 1 -proof of concept
  • Teaching resources focused on core tools/content
  • "Bamboo verbs"



  • DAG: A number of suggestions around the way in which we can have views of visualization centered around teaching/research piece layered together
  • Abstracting that out
  • Not a lot of text in ProgDoc about this, but it's become very important here

Services Atlas

  • Major issue w/ service atlas - notion of relativity
  • Everything centers around service atlas
  • Real point is that it's linked with everything else
  • Match what we're trying to think of for 1/2 year timeframe - how do we get to some stage of having something, some kind of prdouct after a year, while still trying to figure things out
  • This is a tension right off the bat
  • Tool guide - were trying to figure out tool guide vs. service atlas
  • Some of that was tool guide was stuff that's fro wider web? Atlas is more for PB?
  • Operating prototype
  • Verdict: atlas is supposed to be richly nuanced powerful knowledge-base around tools, services, etc
  • Atlas is about metadata - need metadata development process
  • Trying to at the same time make connections back to narratives/recipes, also out into consortium * for explore/plan/build activities



  • Q: This comes up in service atlas, but also in recipes: idea that there needs to be a tight focus on what needs to be built in years 1/2
  • Proof of overall vision/design for going forward
  • Nothing explicit in plan in terms of activity
  • Highlights need for "This is good technology" - tool, interoperability standard, dependencies, etc.
  • How is that going to evolve, does there need to be more work about why a tool is good, why standards should be adopted, why Bamboo?



  • DAG: So, some kind of process in first two years which is a review/evaluation/ranking/education re: tools and services, and interoperability standards.



  • What exactly is a service atlas? Not sure.
  • Could use a more succinct description to be provided @ some point
  • Succinct description - data source (with metadata)
  • Succinct, but is that clear?



  • DAG: Why don't we try to solve this one as part of next version of strawman proposal and on the program document?
  • There are some ways to clarify that too, including questions people have been asking re: Service * Atlas' relationship w/ other pieces
  • Differentiating factor: including tools/narratives/tool-content guide, but also goes back to web services POV
  • Layer of richness and abstraction of metadata activities
  • Part of what we hae to do is find ways to clarify description, more examples for what that looks like
  • Area in second vote that got the highest number of dots was the Service Atlas
  • Something powerful there, between Forum and Cloud



    Bamboo Exchange

  • No one was there?
  • Rick Peterson - "I put a yellow dot up"
  • At Washington & Lee, with colleague, we're very excited, and have a lot of energy for this area
  • We'll work with you to figure this out



    Shared Services

  • Very small group - me and Bernie
  • Technical discussion
  • Three excruciatingly long subsections - focused on last one
  • Bamboo Appliance, talked about kinds of things; Bernie taught me a great deal about how technologists who work in data centers and provide virtualized machines think about things
  • Put some detail that might be of interest to only technologists in the section on the wiki
  • Bernie's assessment - could get fairly far in deploying an Appliance in a couple different locations
  • Distributed set of Appliances forming a Cloud?
  • Could scale to more sites than two; distribution in the Cloud



  • DAG: How many people have a question about what the Appliance is? (lots of hands)
  • A computer (server) that lives in the data center; a server that gives you a web page/application - Google is a great server farm
  • Servers can focus on storing content, servers that connect to big storage machines
  • An appliance is thinking of an analogy of a kitchen appliance
  • If you want to keep your food from spoiling, you want to keep i cold
  • Could nail together a wooden box with ice, but instead you go out and buy a refrigerator appliance - someone's figured out better engineering than you can do yourself
  • An appliance in these terms - machine configured to provide services that PB is interested in providing



  • Can be set up @ any institution's data center, or a vendor paid to host it
  • PB can provide services w/o doing a lot of the technology decision making/implementation

  • Questions?
  • Q: This sounds great, but I'm curious whether if we're trying to come up w/ proof of concept in a year or two - how would this look?
  • In the long term, this is critical, but I'd like some sense of how this ranks for initial priorities?
  • CJK: 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



  • DAG: Appliance is infrastructure that helps provide connections
  • Google Search - ties you into Google Search that's already there
  • Ties you back to a larger set of services; some kind of model, need to build initial piece of infrastructure to help universities be part of services model from the beginnin
  • There are some nice opportunities to get investments from IBM, Sun, others that have inerest in higher education
  • Leveraging other resources w/o making any particular proprietary commitment



  • Q: I like analogy of appliance like with stove, refrigerator
  • But what is this going to DO?
  • DAG: part is in program document, didn't list services
  • Imagine having stuff like housing the services that may be ore concrete scholarly services
  • CJK: 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



  • DAG: 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
  • Q: 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



  • DAG: If you look at shared services lifestyle, application/tool partnership - that's the model
  • Take services in siloed application, and figure out how to run them in a cloud
  • Some could be made available to more scholars across disciplines; there's services to be shared between different disciplines
  • That's some of the goal for the long-term, but how to start in short-term



  • Duraspace - Fedora and DSpace - building institutional repositories
  • Model where by banding together, they can use cloud-based storage services
  • Problem for how to support from digital library side
  • People are struggling forward, trying to figure out how to band together

Tool and Application Alignment Partnerships

  • Concrete things that we want to build
  • Personal note: was chairperson of scholarly narrative group between Workshop 2 and now; had to make tough decision yesterday
  • Schol narratives working group - how to decide what we're collecting? Scope?
  • This is effective in firs year or two, defining scope, showing progress; we have integrated some tools together in disparate areas/universities in Appliance
  • Poignant that services framework and atlas pointed out there need to be more than 2 sites
  • 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 cooperae 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



  • In 1 year? Don't know what resources are available
  • Chart path forward that demonstrates framework we're using
  • Needs to work w/ more than 2 sites/projects
  • Support real research for people
  • Has to produce scholarship
  • Need to have people using it w/in 1 year or 2
  • Needs to be generalizable
  • Need something functional
  • Selection problem: need to select tools, worried about how to make that selection fairly
  • How to select tools we'll bring together, maintain focus of this community
  • Probable that we can't address everyone needs in first pass
  • How to keep people engaged, not lose that segment of the community
  • Dependencies - relationships: need relationships w/ projects and faculty we're trying to help
  • 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



  • Q: Education group - YES! YES!
  • We also talked abut this; need involvement as beta testers, working w/ scholarly narratives, pulling in faculty, talking specifically abut assignments, getting students involved, educating faculty



    Content interoperability & partnerships

  • Had a good debate, but this is aptly named
  • Focus here was on PB's role in interoperability piece and dependency on partners
  • Even discovery layer, search services
  • Urge to draw distinction where PB would NOT provide its efforts re: content discovery/access
  • Mini-mission statement: focus on model that will reduce friction, lower barriers to content access, transport access to content/data in ways that scholars need them
  • Use synthesis, etc
  • Expected qualities re: standards, issues, formats
  • Useful discussion re: rights and access control - important as we move forward
  • This is a point of friction re: multi-institutional access



  • Did not talk re: dependency w/ service atlas grup
  • Forming partnerships w/ content providers, search/support services - this is key piece
  • Interoperability requirements for this part of work
  • Focused a little on concrete pieces that could be done w/in first couple years - still feels like there's a lot of analysis that needs to be done (could be pre-existing)
  • What content partners would be ideal to start with a proof of concept
  • Notion of year 1 to start looking at solutions across PB content providers
  • Synthesis that would lead towards reasonable set of proof of concepts, perhaps multiple, that would tend to be well-represented, higher-impact use cases identified through scholarly narratives
  • Pilot institutions involved in education
  • Setting requirement for institutions - must join for eligibility for API services