...
At the other end of the spectrum, a print view would remove all interactive elements but include URLs in a visible form to facilitate the guides' usefulness on the printed page.
Open Question: How tightly do we integrate SRG with Sakai and Sakaibrary?
There are two primary avenues through which we could implement SRG.
Loose coupling. The first option, and most closely tied to the discussion above, is to implement SRG as a completely separate process, with Sakaibrary acting as a (very important) data source and a (very high-functionality) rendering target. In this model , the SRG authoring tool "lives" wherever it wants to, is implemented outside of the Sakai interface, and relies on web services to pull data from Sakaibrary. The coupling is very loose; Sakaibrary is just a pre-defined target and data-source.
Pros and cons of the loose coupling. This model describes an authoring tool that has the possibility of replacing Sakaibrary with another data source without drastically affecting the functionality of the system. Implementation of the authoring system can take place outside of the Sakai environment and the system/language/UI limitations that implies. The downsides are similar: all the Sakaibrary functionality is not available to the SRG authoring system (e.g, to use a citation it would have to first be put into Sakaibrary and then referenced, as opposed to searching "on the fly"), and the strengths of the Sakai system (localization, transparent data-store, etc.) would not be available. It also forces the institution to provide another environment for production, whereas we're assuming that Sakai is already up and running.
Tight coupling. The second is to make the SRG a part of Sakaibrary (or, perhaps, a special resource type with advanced connectivity to the Sakaibrary services), with direct access to all the functionality of Sakaibrary. In this case, what we're essentially building is the "next-generation" citation list, with hierarchy and annotations as built-in functionality. The rendering functionality would be transferred to Sakai, so external systems could still call into a servlet and get a rendering of a guide for use outside of Sakai.
Pros and cons of the tight coupling. Some aspects of a research guide don't fit well with the general model in Sakai the focuses on course-semesters (we want guides to live "forever") and the permissions model may need some tweaking to allow the sorts of collaboration we want. Offsetting this is the availability of all of Sakaibrary as first-order functionality in the SRG, and the ability to integrate the SRG data model with the existing Sakaibrary data model.
Bill's thoughts
I originally wrote this document with a focus on the loose-coupling model, but our Michigan conversation on Tuesday (Feb 20th) has convinced me that the tight coupling is more advantageous for a number of reasons:
- Creating the SRG as indicated gets us most of the way to a much more functional citation list document type "for free"
- An SRG tightly coupled to Sakaibrary gives more opportunity for things like canned/constrained searches and forces us to start dealing with these data types sooner rather than later.
- It avoids the overhead of designing and building a web-services infrastructure during the initial pass (although we'll likely want to think this through regardless).