 |
 |
I know this is a late response to the thread, but hey, that's what threads are for... UPEI is planning to release some sample content models with a future Islandora release that will provide examples of what Jim and others have mentioned here. Islandora is our Drupal/Fedora model, which is currently in the final documentation/testing stages for our new Drupal 6/Fedora 3 release (http://vre.upei.ca/dev/islandora). The research-focused implementation of Islandora is what we call the VRE, Virtual Research Environment. In our most recent example we have built a VRE for our Marine Natural Products Lab, which looks for new pharam/nutra-ceuticals from marine organisms. The Drupal collaborative layer allows the research conversation to unfold, including integration of research articles, lab books, etc. Some information streams are closed to specific people/groups and others are open to the public. Information/data can be restricted at both the Drupal and Fedora layers, providing a high level of security. The Fedora layer stores data that come out of the wetlab (ie. raw and transformed research data) and exposes them via browse/search in the Drupal interface. In this context Fedora acts as the scratch space that Jim refers to. We have built custom XML schemas to store metadata about the organisms (the Critter record), fraction and compound data specific to this lab's protocols, gene sequences (using industry standard schemas) and mass spectrometer chemical analysis data files (also industry standard). The researcher may choose to search for a specific species and review data, or can access a search screen that allows a search across data domains: find me data where the critter is a sponge, the fraction data in field X=Y, and so on. The researchers like the fact that the system stores their raw research data, but more importantly that it allows them to discover data and relationships not obvious otherwise. The detailed audit trail of changes to objects and datastreams is very powerful in managing changes. We are also working on data transformations using Fedora and external apps that will do things like: run a series of conversions on a batch of gene sequence on ingest; convert a proprietary mass spec data file to an XML version, exposing it to open source viewers, etc. These VRE content models will not be in the next release of Islandora (due at the end of this month) but we are planning to add additional examples to the code repository. We will also be adding content models from other groups using the Islandora system for similar projects. Future efforts will hopefully include integration with systems like MyExperiment, providing a more flexible workflow layer and tighter links between Drupal nodes/taxonomies/comments/etc and Fedora, so that all data, including conversations about a digital asset, are stored in Fedora. Fedora is perfect for this kind of application and I think offer a much more flexible path than the suggested source code repository approach. The ability to work with any XML schema and digital asset, mash them up in a presentation layer, provide a functional search layer like Solr/Lucene, orchestrate transformations, and a host of other advantages make this kind of system work for just about any requirement in the research landscape. Space for "working data" can be an issue, but I think is the easy one, as space is cheap and relatively easy to add when needed. For us there are obvious advantages to using the Library's tools and expertise to steward research data, especially in the early stages. The researchers are happy to have the assistance in creating data management approaches, and the metadata/searching/transformation skills in the library world are perfect. So I also agree that this is an obvious niche and one we need to take advantage of! Mark Leggott On 13-Mar-09, at 10:29 AM, Jim Tuttle wrote: > I've also been thinking about how to move upstream in the workflow of > campus data creators and publishers. This is the suggestion of the > University of Rochester's paper, Understanding Faculty to Improve > Content Recruitment for Institutional Repositories. Enabling > collaborative work among researchers from disparate units or > universities seems an obvious niche. > > One of the obstacles to offering versioned scratch space (isn't that > the > essence of a repository space for versioning of objects prior to the > objects being declared final?) for us is the probable space > requirement > to store multiple versions of objects. This is, as I understand it, > what University of Hull and University of Prince Edward Island are > doing > with Virtual Research Environments- offering uncurated, versioned, > collaboration-enabled space under the assumption that moving finalized > objects into the repository will be extremely simple. > > By applying delta technology to save only changes, perhaps space > considerations can be mitigated. I would worry that recreating a > specific intermediate state of an object, should the system fail, > would > be that much more complicated, though. > > I think you raise a separate question about derivative data and > managing > relationships. In the context of archiving geospatial data, we've > been > thinking about applying a FRBR model to collections and constituent > objects. Ideally, we'd like to embed a persistent identifier in the > metadata of each object that resolves to a relationship record. It > seems especially useful in light of the temporal aspect of our > content. > > Thanks for raising the topic, > > > > Chris Rusbridge wrote: >> My earlier note about how the R word was mostly being used for >> something >> else, and in particular for source code version control repositories, >> has been swirling around in the back of my brain for a few days, >> bumping >> into other stuff. In particular, I began to wonder whether there are >> elements of the typical source code repository that we could usefully >> use for our repositories. Now this thought is neither new nor >> original; >> I remember commenting in a blog post in August last year on Peter >> Murray-Rust's epiphany from April 2007 >> (http://wwmm.ch.cam.ac.uk/blogs/murrayrust/?p=259) that SourceForge >> was >> a repository. But I don't think I've seen the ideas contrasted yet, >> say >> in the context of what IRs could usefully take from source code >> repositories. >> >> A lot of what goes into source code repositories is about managing >> change: keeping track of versions, and ensuring that separate >> people are >> not changing the same element at the same time. There are also >> presumably sophisticated facilities for constructing what one might >> call >> derivative products (compiled versions, libraries, etc; it's a long >> time >> since I used one of these things in production!). >> >> IRs and related repositories have traditionally not been about >> change; >> they tend to be about maintaining a static version (I won't say >> "preserving", as it appears some object to that idea). However, the >> idea >> of moving the repository upstream into the researcher's workflow, >> as in >> the idea of a Research Repository System (eg >> http://digitalcuration.blogspot.com/2008/07/negative-click-positive-value-research.html) >> . >> This does imply managing change much more. Besides, we're beginning >> to >> be troubled by multiple version problems, and we certainly have >> derivative products (from simple Word -> PDF transformations, to more >> unclear pre-print -> post-print relationships). >> >> So my question is: has this comparison of IR platforms to source code >> repository systems been done, or is anyone doing it? >> >> -- >> Chris Rusbridge >> Director, Digital Curation Centre >> Email: [log in to unmask] Phone 0131 6513823 >> University of Edinburgh >> Appleton Tower, Crichton St, Edinburgh EH8 9LE >> >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> >> >> >> On 10 Mar 2009, at 17:44, Chris Rusbridge wrote: >> >>> I have [a twitter search] for "Repository OR Repositories". I just >>> did >>> a quick count; with around 160 tweets found in the past 2 days >>> containing one of those words, only 14 had anything to do with the >>> sort of repositories this list is interested in! >>>> >>> >>> Most of the rest appear to be to do with SVN and git etc version >>> control repositories. Quite a lot appear to be the simple dictionary >>> meaning of places to store something. >>> >>> I hadn't quite realised how much we are overloading someone else's >>> vocabulary with the R-word! > > -- > ---------------------------- > Jim Tuttle > Digital Repository Librarian > Digital Library Initiatives > NCSU Libraries > 919.513.0651 > > Mark Leggott, University Librarian University of Prince Edward Island 550 University Ave. Charlottetown, PE C1A 4P3 902-566-0460 Fax 902-628-4305 [log in to unmask]