Ed, George, and I spent the morning in a meeting discussing Shelf2Life, a project encompassing the digitization of public domain texts, distribution of e-versions of the texts to various online vendors, and the ability to print these works on demand at the point-of-sale, at BCR. Several of our members are participating in the initiative, while others are generally interested.

We’ve begun to explore whether there is a consortial interest, as well as how to offer long-term digital archiving of the e-texts, if our members desire. Local access to and distribution of the e-texts is tied up in contracts and business models, but at the very least, we should be able to provide tiers of secure preservation services for the e-texts, and auto-loading workflows not unlike our developing OA ProQuest ETDs auto-load service. There are a lot of stakeholders involved in the Shelf2Life project, not to mention a heck of a lot of ISBNs – for the e-text, for the hard cover, for the soft cover, for the online edition, etc. There are also multiple sources of metadata, multiple formats, and many questions still to be answered regarding server and system security from the prospective of a profit-oriented vendor. The meeting – and attendees – were upbeat and positive, while we hammered out what we all thought we needed to know more about…

There is some homework, certainly future meetings, and some continued testing…but, all in all, it appears to be an interesting project. Now, I just have to lobby for the members’ royalties from the sale of these works to be dedicated to the on-going storage and preservation costs of these texts…Another “fray” to be sure!

ProQuest DISS_XML Metadata: Selected Attribute Codes and Definitions 

Overview:

Various DISS_XML metadata schema elements capture raw information from the ETD Administrator student submission process. There are attributes with coded values with some connection to open access, publishing, and other administrative and rights-related activities. The Alliance is interested in determining from members which attributes, codes, information, and actions are relevant to the deposit workflow of ProQuest-shared ETDs in the repository. The primary element attributes and values of question are: embargo_code, publishing option, third_party_search, as well as the sales_restriction element.

From dissertations_metadata Document Type Definition (DTD):

·         publishing_option (0|1)
o   default “0”
o   ProQuest comments: Publishing option can be 0 (Traditional) or 1 (Open Access). Open Access publishing requires an extra fee, in addition to the Traditional publishing fee.

·         embargo_code (0|1|2|3|4)
o   default “0”
o   ProQuest comments: Embargo code can be 0 corresponding to no embargo OR
§  1 – 6 months embargo
§  2 – 1 year embargo
§   3 – 2 year embargo
§  4 – Reserved for future use

·         third_party_search (Y|N)
o   default “Y”
o   ProQuest comments: Indicates the author would like to have his or her
     metadata indexed by search engines like Google Scholar. Use N if the
     author does not want that.

·         DISS_sales_restriction code  (0|1|2|4)  remove
o   default “0”
o   ProQuest comments: The sales restriction codes are as follows:
§  0: No sales restriction
§  1: Not available for sale
§  2: Sell to author only/copyright
§  4: Sell to author only
o   ProQuest comments: the remove attribute is a mm/dd/yyyy date on which the restriction is to be removed

• Support the aggregation of openly accessible metadata records from all institution’s repository portals into a single consortially-scoped discovery point we’ve been referring to as MINeR as part of an early branding effort
• Support harvesting of any given institution’s openly accessible metadata by said library’s vendor-supplied nextGen library discovery tools (i.e. III’s Encore  is emerging as one popular choice among the consortia’s members)
• Repurpose available OAI Dublin Core metadata to support the ingest, management, and discovery of member library content created as part of early grant projects, specifically those supported as part of the CDP’s early digital collection building support awards.

In the first two cases, we are the data providers, making our metadata available for harvest and re-use in other environments (one of which we intent to support by building on PKP’s OAI Harvester interface as a foundation. Once we gain a better foundation for our local OAI exposure activities, and cement the sharing with the vendor(s), we will encourage larger aggregators, like OAIster, to come harvest us, too. We are definitely of the approach “the more, the merrier!”

In the third case, we are actively harvesting, filtering, refining, and normalizing metadata from another resource – and really, from another, earlier time of collaborative efforts, which adds some interesting challenges to isolating specific elements like where to find the matching file name to join a record to a primary content file provided by the institution or how to validate a several-year-old URL used as an identifier. The immediate goal is to transform harvested DC records into the MODS/DC metadata components of a basic ADR METS-contained digital object.

To be on both sides of the OAI aisle is fascinating, if at times frustrating and time-consuming. We are simultaneously being challenged by our own choices to adopt an open sources repository interface and presented with a significant learning curve about how Fez approaches OAI – and how we can change that approach to meet our immediate needs and long-term anticipated needs, while we also are challenged trying to repurpose earlier efforts to do much the same…at times it’s like looking in a three-way mirror – What is reflecting where? What do we see? And, which – in any given view – is the primary object of focus? Doesn’t it kind of makes you want to ask, “Mirror, Mirror on the wall…Who’s OAI is the “fairest” of them all…?”

The Fest grew out of a combined interest in supporting federated authentication and authorization at the campuses as well as specifically within the Alliance Digital Repository service. There is a mix of library and central IT personnel participating today, and this Fest is one part of an emerging collaboration among library and IT staff.

Shibboleth is one form of authentication, along with LDAP, that is currently being investigated and  – hopefully after today – prototyped among Alliance institutions. It relies on attributes, SAML, metadata at a more technical level and ultimately an understanding of identity management on each campus.  This is new territory for many of our library member representatives. As a related activity, Alliance members have been encouraged to think about roles and workflows within the repository and generate a matrix and use cases to help support the discussion with IT staff.

Nate’s slides will be available shortly from the CHECO Web site (I will update the link here)

Many thanks to Chad Burnham, Nate Klingenstein (who’s T-Shirt provided the title of this blog post), and CHECO for organizing and supporting this event.

Take a look at the staging instances of member Fez implementations to see User Interface customizations.

You will need the login information for the development/staging server, as well as the various MARC org codes for the institutions, found on the wiki here: http://adrresources.coalliance.org/wiki/index.php/ADR_Codes

After logging in to the staging server at your own implementation, change the MARC org code value in the URL to view other institutions’ changes to the banner, footer, and color schemes.

Example: Change http://sword.coalliance.org/cod/staging/ to http://sword.coalliance.org/coccc/staging/ (replacing cod with coccc)

If you are interested in learning more about making a change, contact either the ADR Steering Committee representative from the inspiring institution, or the ADR directly (adr@coallaince.org)

At each step of ADR construction to date, though, we have incorporated features and taken actions that will support institutional branding/skinning, as well as scoped management and preservation activities. Unfortunately, these are mostly about function and have little visible impact on the oh-so-important-to-stakeholders “curb appeal,” but the need for that curb appeal and the programmatic support for has always been on the horizon and speeding straight toward us!

It may not be immediately apparent, but to ultimately get to the “my banner” and “my colors here” level of activity, the Alliance already has reworked Fedora and Fez code to accommodate institutional “buckets” for data deposit, storage, and management under Fedora. We have also made a commitment to providing customizable, best practice driven metadata profiles for a variety of material types, with the hope that one institution’s image object is both interoperable within and beyond the ADR community, while also meeting local needs. This translates to a lot of code, a lot of cloning of XSDs, and a lot of hand-holding of the relationship between Fedora and Fez.

We recently decided to pursue individual Fez instances on top of the consortial Fedora instance, to better support branding as well as security, authentication, and administration. This decision was not made lightly, as it presents a bit of a management challenge, but the gains, we feel, outweigh the costs. Multiple Fezzes has always been seen a s a “Plan B” – which inevitably has become THE plan. Our initial foray into reworking a single Fez to support not just “a look” but large chunks of underlying functionality supporting searching, browsing, administration, and authentication was more than we – or the web interactive firm we contracted out to – could do.

Each of these individual Fezzes will also have its own “name” and identity…along the lines of “DigitalUNC,” “CU Scholarship,” or maybe “BooneDocs?” (The last has been vetoed, I believe, by the powers that be at DU…but I thought it was pretty clever….DU’s recently resurrected mascot is “Denver Boone”). It will also have its own LDAP configuration, if desired, as well as its own material type templates (XSDs), communities, collections, and workflows. Essentially, from the “curb” it will appear as though every institution will have its own repository.

In October 2006, the Board of Directors of the Alliance approved a plan for the ADR that included two related, yet somewhat conflicting, deliverables – a branded interface to the repository for each member library/institution (see above) AND a consortial view that brought together all of the diverse, yet complimentary open access materials that could aid the end-user in their research, whether they be the casual “K to Gray” visitor, or the hard-core researcher… So, we add a consortial interface to the list of institutional interfaces…easy, right? We’ll see…

From a functionality perspective, initially, we thought we’d add another Fez instance and index all open Fedora objects into it, but now we are leaning toward an OAI-like (or maybe OAI with no “like”…) service – the simpler the better…

In the identity building process, it’s also time to start “branding” that consortial repository interface, much like the individual member interfaces. To date, ADR has meant the whole repository service, the Fez Interface, and Fedora repository – and any combination thereof. We tried to call the Fez interface ADRLib – but its gained little traction and we’ve heard that it is confusing. I’ve been bouncing around a couple of ideas internally, looking for traction – my goal is to come up with a name for web presence/user interface for the consortial aggregator of open repository content.

So, name-wise, what do you think of…

…MINeR: Multi-Institution Networked Repository?

This is an obvious play on the Alliance’s love of mining themed products: Prospector, Goldrush…turned into a somewhat sensible acronym

or

…ProspectorPlus?

More than once George has described the ADR as being like the existing Union Catalog for “digital stuff” – although the ADR is much more than that, for discovery and redirection for access purposes, it does make sense…

I’m hoping our member library representatives have some additional ideas we can knock around on Friday at our monthly steering committee meetings…

To the Alliance, this means that we will be able to identify at the point of deposit or batch ingest the appropriate institution’s “bucket” of repository storage to store the Fedora object in, which will greatly aid in managing dedicated storage allocations among our members, as well as reporting out content growth trends to our members. We plan to use LC’s Organizational Codes as our namespaces, we think…

It looks like the Fez folks are interested in incorporating Keith’s efforts into their code repository, which marks our first real contribution back to the open source community! Congratulations, Keith!

Those templates are what I’m working on right now, with my brand-new “super administrator” privileges in Fez. The lovely HTML form that contributors will see is generated from much-less-lovely XSDs, or XML Schema Definitions. Right now I’m using my superpowers to clean up the XSDs, taking out troublemakers (unnecessary elements from the Fez defaults) and making the streets safe for the ADR’s minimum required metadata elements, many of which are currently in hiding in the default XSDs.

If anyone is curious about the ADR minimum metadata elements, these come from the Digital Library Federation / Aquifer Implementation Guidelines for Shareable MODS Records. The DLF guidelines break out several levels of adoption for MODS elements, and the ADR uses the second level, which is called the “minimum for doing anything useful.”

This is an underwhelming name for a pretty exciting idea: by meeting this level of adoption, the ADR can

• maximize the amount of records that are eligible to be entered into the repository
• offer useful search and discovery for all repository users
• ensure that records will retain meaningful context even when they’re aggregated/harvested from afar

Pretty super, huh?

Moving forward at the ADR…

Updated: Jan 11, 2008

The Alliance Digital Repository is currently unavailable.
Access to the repository will be restored early February 2008.
We apologize for any inconvenience this may cause.

If you need immediate assistance, please contact adr@coalliance.org

During the past six months, the Alliance Digital Repository has been in a very active Beta Preview phase. We have worked with our member libraries to identify functional service needs as well as extended the scope of potential uses of the repository service. Now, we are suspending ADR Beta Service while we “re-tool” our operations to support a stable ADR 1.0 release.

ADR 1.0 will include updates to the ADR and ADRLib software, an improved user interface to ADRLib services, and enhanced image viewing capabilities.

Behind the scenes, we are also updating and expanding our end-user documentation, our issue tracking service, and hammering out the licensing and deposit agreements for permanent content submissions to the ADR.

Additional information about the ADR and the Alliance is available on the Alliance Web site.

Thank you and please visit ADR 1.0 in February, we look forward to your feedback!

***

While the ADR service is down, we will be installing and configuring the Fez 2 release candidate, upgrading our Tomcat and Fedora installations, and integrating a new, skinable user interface for our ADRLib service.

We’ll also be using this time to re-prioritize our outstanding functionality needs, update our communication strategies, and outline the next six-months of ADR activities.

 Did I mention we are shopping around what is essentially a strategic growth plan for the service to our stakeholders; gearing up for our role in DPL’s IMLS “Creating Communities” project; meeting with legal counsel to discuss liabilities, risks, and agreement language;reviewing back-up support products and data centers; and looking to finalize a couple of outstanding metadata schema mappings…

It’s a busy time at the ADR and a great way to start the new year. We look forward to all the improvements to the ADR service these activities will bring!