What does sharing publicly accessible material mean?

From the time a distributed open digital library was a glimmer in the eye of Digital Library Federation leaders, the words "shared collections" rarely appear in DLF writings without being modified by "publicly accessible" or "openly accessible". We are now implementing services for shared collections and asking contributing libraries to sign a submission agreement as we include their collections in Aquifer. The submission agreement is broad and asks libraries to agree to allow both metadata and digital objects to be aggregated within Aquifer. Some libraries have pushed back on agreeing that the objects can be collected and have marked up the submission agreements, restricting aggregation to metadata only. At this point, we can accept the restricted agreements. Currently, we are only aggregating metadata.

However, it is clear that to meet our goal of making material easier to use as well as find and identify, we will need to pool or cache more than descriptive metadata--likely some kind of surrogate for the item, as defined by asset actions. Although it is unlikely that we would need to aggregate copies of the objects themselves, future plans to enable object re-use begin to call into question what exactly we mean when we talk about "publicly accessible" or "openly accessible" collections. Do we mean that anyone can view the object or that anyone can capture the object for educational use or for commercial use? Are there any restrictions on further distribution, re-use or re-mixing?

Within the Aquifer initiative, we are considering a variety of activities to help with definitions, including a discussion session at DLF Fall Forum and possible experimental mapping of the MODS accessCondition statement for some collections to Creative Commons licenses. One goal would be to confidently re-expose Aquifer collections as open educational resources. More generally, we want to enable scholars to quickly and easily determine how these digital materials can be used. We welcome ideas and suggestions for other activities and approaches we should consider.

Glossary update

I've slightly modified the Aquifer glossary and added a few new terms as they relate to the ASHO website. It's posted as a background document in the Project Management area of the Aquifer wiki.

I'm still wrestling with defining the term "facet" and I'd appreciate any feedback on that one.

Please also let me know if there are other terms that you think should be included at this time.

Thanks!

Zotero Integration with the Aquifer Portal

Here are some miscellaneous notes on Integrating Zotero into the Aquifer portal:

Initially what we want is for Zotero to be able to easily slurp citations from the portal. Secondly we want the digital objects themeselves to be importable into Zotero. It appears there are several options for doing this.

1) Write a custom Zotero translator just for our portal site. This seems to be the most complex solution, plus the portal web site is undergoing constant changes right now, so this doesn't seem like the best solution. There may be some benefit to eventually doing this once the portal is solidified, but probably not.

2) The path of least resistance appears to be using COinS, so this was my initial solution. COins are OpenURL Context Objects inside of HTML span tags. For example:


<span class='Z3988' title='ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fdlfaquifer.org%3Aportal&rft_id=info:oai/oai%3Aoai.dlib.indiana.edu%3Aarchives%2Fcushman%2FP10267&rft.title=St.%20Gaudens%27%20Lincoln%20in%20Lincoln%20Park%20Chicago&rft.identifier=http%3A%2F%2Fpurl.dlib.indiana.edu%2Fiudl%2Farchives%2Fcushman%2FP10267'></span>


The COinS contains the encoded metadata for the citation. Zotero is able to parse COinS from any web page and import them as citations into its database. A disadvantage of COinS is that OpenURL Context Objects do not support the full fidelity of metadata that might be desired, for example there is no way to embed the abstract.

3) Zotero also supports unAPI. This is a simple API for discovering and retrieving digital objects associated with a given web page. It is similar to COinS in that it embeds identifiers in special HTML tags (in this case abbr tags), but this API also requires a web service component which is able to retrieve the identified digital objects in different formats. This API probably holds the most promise for the long term, but requires some additional server side coding. We might be able to directly import MODS using unAPI, but I still need to investigate this.

4) A fourth option is embedding RDF metadata directly in the web pages. This has some potential in that it might support the full richness of metadata that we desire, but in my opinion is not quite as clean or simple as either the COinS or unAPI solutions.

So, right now we have implemented COinS, but the likely long term implementation will done using unAPI.