Why start another way to think about the ScholarsBox? Isn't ScholarsBox/StatusSummary200402 worth getting back to? Yes, but I am feeling the need to step back one level of abstraction because we have not really fully resolved the issue of what does a small group of people do when it has super grand ambitions? The lines of work that I have been outlining might actually be more appropriate for a group with more resources than we actually have. So, why not just do a plan of work for a smaller group? Ultimately, that is the question that I need to answer. But it's nice to think a bit more expansively first.
Let me do a big brainstorm and see what I get.....
Conceptual framework for this idealized planning
Suppose that my goal is to get he ScholarsBox idea implemented and institutionalized as broadly and deeply in as short of a timeframe as possible. Moreover, we don't want to keep pouring more resources into the project after this big injection of resources. What to do?
-
Move on both ScholarsBox "in the small" and ScholarsBox "in the large" but recognize that the two types of work are complementary and require different foci. One can feed into the other -- and it would be important to identify those feedbacks.
-
Find individual creative persons or small teams that have a vision for what to do with digital objects and assign technical SWAT teams to help them out. For something concrete, I've used myself as the person I'd be designing for: ScholarsBox/DesignedForRaymondYee. This can degenerate into vanity programming -- but doesn't have to as long as we recognize that we are aiming to generalize the work we do for individuals and try to stay away from stuff that is obviously way too idiosyncratic for our general audiences to justify spending a lot of resources on the one person.
-
Deploy those SWAT teams also to work on sources of data that the individual users will want to have access to. A lot of times, barriers to full GatherCreateShare functionality are best tackled not through better ScreenScraping on the ScholarsBox (client side) but by helping the sources of materials offer better access and markup, etc. (Let me be more concrete here. Suppose there is an online source of images that we want access to. It offers a reasonable HTML interface but no WebServices framework. There are metadata available but not in a standardized fashion. What the SWAT team could do is to come in and implement a SOAP/WSDL interface and tack on DublinCore metadata -- thus making it easier for a tool like the ScholarsBox to access. We can can then assess the difficulty of doing such "interventions" and look at the question of how difficult it would be for others to do the same. Is DublinCore the right way to go? How about some other metadata specification?
-
What we learn on the SWAT teams, we use to test the general frameworks that are being thought up by people designing ScholarsBox in the large. What work would be going on in the ScholarsBox
