Category: Collaborations

January 13, 2015

Duoc UC, Chile, becomes the 27th Hydra Partner

(taken from the Hydra Partner List-serv)

[English version below]

Estamos encantados de anunciar que Duoc UC (http://www.duoc.cl), en Santiago de Chile, se ha convertido en el más reciente Hydra Socio formales, y nuestro primer socio en América Latina. Duoc ha estado trabajando con Hydra para construir la “Biblioteca Digital Patrimonial” (http://loncofilu.cl), un repositorio digital de planos arquitectónicos, fotografías, planes de restauración y documentos históricos relacionados con los edificios históricos más preciados de Chile, y que representa el trabajo producido por los estudiantes de la Escuela de Construcción Duoc UC. Para el 2015 están planeando el desarrollo de dos repositorios adicionales basados Hydra que se centrarán en la recogida de proyectos de títulos de estudiantes y de audio y producciones visuales de la Escuela de Comunicación.

En su carta de intención, Duoc dice que se han comprometido no sólo a la construcción de más proyectos con Hydra, sino también para la construcción de una comunidad de Hydra en América Latina mediante la traducción de la documentación en talleres españoles y explicaciones por otras instituciones de América Latina interesados en la construcción de repositorios de Hydra.

Bienvenidos, Duoc UC!

We are delighted to announce that Duoc UC (http://www.duoc.cl), in Santiago, Chile, has become the latest formal Hydra partner, and our first partner institution in Latin America. Duoc has been working with Hydra to build the “Heritage Digital Library” (http://loncofilu.cl), a digital repository of architectural drawings, photographs, restoration plans and historical documents related to the most precious historic buildings in Chile, and representing work produced by the students of Duoc’s Faculty of Construction. In 2015 they are planning to develop two additional repositories based on Hydra that will focus on the collection of student thesis projects and audio and visual productions from their Faculty of Communication.

In their letter of intent, Duoc says they are committed not only to building more projects with Hydra, but also to building a Hydra community in Latin America through the translation of documentation into Spanish and offering workshops to other Latin American institutions interested in building Hydra repositories.

Welcome, Duoc UC!

December 16, 2014

ScholarSphere Conference at Yale University Library

Yale University Library and Yale ITS are pleased to sponsor a conference and public lecture on ScholarSphere, a software project developed at Penn State University, based on the same open-source Hydra/Fedora framework in use at YUL.

Yale University Library and ITS are investigating the possible adoption of this solution to enable Yale faculty and researchers to self-archive their own digital content in a managed, secure repository for controlled or open dissemination as well as for their own use. Our speakers will talk about the ScholarSphere project both from a technical perspective and as a service model. More information on the ScholarSphere website here.

Speakers:

Patricia Hswe, Digital Content Strategist and Head, ScholarSphere User Services at Penn State University
Daniel Coughlin, Ph.D. Candidate at Penn State University

via Yale University Library News: ScholarSphere Conference Archives.

November 25, 2014

Avalon Meeting Notes for Nov 24

We had a very productive meeting with three guests: Jon Dunn, Project Director, Indiana University; Mark Notess, Product Owner, Indiana University; Julie Rudder, Product Owner, Northwestern University.

The day started with an introduction to Avalon Media Systems in the Library Lecture Hall which included demonstrations of the work of Indiana and Northwestern who very recently released their first Avalon collections to the public. Powerpoint from the presentation is attached here: Yale Avalon Conference This lecture was video taped but sound is lacking, please contact michael.friscia@yale.edu for access.

Later in the day a smaller group convened to have a technical discussion about the future roadmap of Avalon. A recent poster that gives a very high level view can be seen here: RudderAvalon2. I am hoping to acquire a copy of the powerpoint presentation which has bullet lists of all the planned work that will go into version 3.2 through 4.0.

While we are still in the discussion stages of a project to bring Avalon up at Yale, two of the most important features for us include integration with Fedora 4 and possible integration of the backend transcoding processes into Sufia (Penn State has a version of Sufia called ScholarSphere). Our goal would be to integrate the two Hydra applications together so that audio and video files loaded into the self archiving product, Sufia, would take advantage of all the features of the Avalon Media System.

In addition, we discussed many topics including scaling Avalon so that it could transcode more than one file at a time, use RDF for describing complex relationships between multiple files/tracks and digital preservation.

November 14, 2014

Fedora 4 development notes for November 2014

Fedora is used locally in a number of applications including our Hydra instance, Finding Aids Database, AMEEL and the Joel Sumner Smith collection. In our local instances we have been using versions of Fedora 3 since 2006. Fedora 3.8, to be released in December, will be the final release of the 3.x line with energy at that pointed shifted primarily to Fedora 4.

Fedora 4 consists of a complete refactoring of the fedora 3 code now built on top of the Modeshape and JCR repository APIs, with improvements in ease of installation, scaling, and RDF support. Below is a full list of features.

Yale contributes financially to the product as a bronze member and we also contribute to the programming efforts. Osman Din and Eric James, both in Digital Library Programming Services, actively participate in development. In addition, I sit on the Fedora Leadership Committee that handles the gathering of use cases, prioritization of features being programmed as well as budget planning.

Fedora 4.0 is now undergoing a cycle of beta releases to allow institutions to begin adopting it. On November 9th Fedora 4.0 Beta 4 was released again with an eye towards simple installation and support for performance and repository size. Fedora 4.1, to begin development in 2015, will focus on supporting the upgrade/migration process from Fedora 3.x. Some peers, including Penn State, have already begun to replace some of their Fedora 3 repositories with Fedora 4. We are also starting to think about how our migration strategies can dovetail with fedora 4.1 for our own adoption starting around the of summer of 2015.

With that little bit of background, I thought I would share the recent development notes. If you have questions about Fedora, do not hesitate to contact me (michael.friscia@yale.edu), Eric James (eric.james@yale.edu) or Osman Din (osman.din@yale.edu).

(note: Eric provided valuable editorial feedback for the above post)

======================================================

Release date: 9 November, 2014

We are proud to announce the fourth Beta release of Fedora 4. In the continuing effort to complete the Fedora 4 feature set, this Beta release is one of several leading up to the Fedora 4 release. Full release notes and downloads are available on the wiki: https://wiki.duraspace.org/display/FF/Fedora+4.0+Beta+4+Release+Notes.

==============

Release Manager

==============

Andrew Woods (DuraSpace)

==========

Contributors

==========

—————————-

1) Sprint Developers

Adam Soroka (University of Virginia)

Benjamin Armintor (Columbia University)

Chris Beer (Stanford University)

Esme Cowles (University of California, San Diego)

Giulia Hill (University of California, Berkeley)

Jared Whiklo (University of Manitoba)

Jon Roby (University of Manitoba)

Kevin S. Clarke (University of California, Los Angeles)

Longshou Situ (University of California, San Diego)

Michael Durbin (University of Virginia)

Mohamed Mohideen Abdul Rasheed (University of Maryland)

Osman Din (Yale University)

————————————

2) Community Developers

Aaron Coburn (Amherst College)

Frank Asseg (FIZ Karlsruhe)

Nikhil Trivedi (Art Institute of Chicago)

=======

Features

=======

—————————–

1) Removed features

In the interest of producing a stable, well-tested release, the development team identified and removed a number of under-developed features that had not been sufficiently tested and documented. These features were not identified as high priorities by the community, but they may be re-introduced in later versions of Fedora 4 based on community feedback.

– Namespace [1] creation/deletion endpoint

– Locks endpoint

– Workspaces other than the ‘default’

– Admin internal search endpoints

– Policy-driven storage

– Batch operations in single request

– Auto-versioning configuration option

– Sitemaps endpoint

– Writable nodetypes endpoint

——————

2) REST API

The REST API is one of the core Fedora 4 components, and this release brings it more in line with the emerging W3C Linked Data Platform 1.0 [2] specification. An example of this is the new tombstone functionality [3]; URIs are not supposed to be reused, so deleting a resource leaves a tombstone in its place that serves as a notification that the resource has been deleted. Child nodes of deleted resources also leave tombstones. Other examples of LDP-related REST API changes include:

– Support for hashed URIs [4] as subjects and objects in triples.

– Binary and binary description model changed:

– From: binary description at /resource, and binary at /resource/fcr:content,

– To: binary description at /resource/fcr:metadata, and binary at /resource

– Labels are required when creating new versions of resources [5].

– Content-Disposition, Content-Length, Content-Type are now available on HEAD requests [6].

—————-

3) Ontology

The Fedora 4 ontology [7] was previously broken out into several different namespaces, but these have now been collapsed into the repository [8] namespace. Additionally, the oai-pmh [9] namespace has been added to the ontology.

———-

4) LDP

Fedora 4 provides native linked data functionality, primarily by conforming with the W3C Linked Data Platform 1.0 [10] specification. The LDP 1.0 test suite [11] is executed against the Fedora 4 codebase as a part of the standard build process, and changes are made as necessary to pass the tests. Additionally, integrations tests for real-world RDF assertions [12] have also been added to the codebase.

Recent changes to suport LDP include:

– When serializing to RDF, child resources are included in responses [13], versus having to traverse auto-generated intermediate nodes.

– All RDF types on properties are now supported [14].

– Prefer/Preference-Applied headers have been updated [15] to match the latest requirements [16].

– RDF language types are now supported [17].

– The full range of LDP containers [18] are now supported

– Changed terminology from:

– object -> container

– datastream -> non-rdf-source-description

– Replaced relationships from:

– hasContent/isContentOf, to:

– describes/isDescribedBy

—————————

5) External modules

In additional to the core Fedora 4 codebase, there are a number of supported external modules that offer useful extensions to the repository. Two such modules are being introduced in the Fedora 4.0 Beta 4 release: Fedora 4 OAI Provider [19] and Fcrepo Camel [20].

The Fedora 4 OAI Provider implements the Open Archives Protocol Version 2.0 [21] using Fedora 4 as the backend. It exposes an endpoint at /oai which accepts OAI conforming HTTP requests. A Fedora resources containing set information can be created then exposed at the module’s endpoint which accepts HTTP POST requests containing serialized Set information adhering to the OAI schema.

Fcrepo Camel provides access to an external Fedora 4 Containers API [22] for use with Apache Camel [23]. Camel is middleware for writing message-based integrations, so this component can be used to connect Fedora 4 an extensive number of external systems [24], including Solr and Fuseki. This functionality is similar to that of the Fcrepo Message Consumer [25], except it is based on a well-maintained Apache project rather than being custom Fedora 4 code. Therefore, this component is likely to replace the Message Consumer in the future, though the Message Consumer will still be part of the Fedora 4.0 release.

————————

6) Admin Console

The administrative console provides a simple HTML user interface for viewing the contents of the repository and accessing functionality provided by the REST API. This release introduces support for custom velocity templates [26] based on the hierarchy of mixing types. Now, if you create a new mixin type, the templates to be used in the admin console will include the resource’s primary type, mixin types, and parent types thereof.

—————–

7) Projection

The projection [27] (also known as federation) feature allows Fedora 4 to connect to external storage media via a pluggable connector framework. A read-only filesystem connector is included with this release.

Additionally, Fedora 4 now has standardized support for externally-referenced content [28].

—————————

8) Java client library

The Java Client Library [29] is an example of a module that was conceived by Fedora community members who recognized a common need and rallied to design [30] and implement the functionality. This release includes an improvement to list the children of a resource [31] in the client library.

———–

9) Build

A key component under the covers of Fedora 4 is ModeShape [32], one that the Fedora 4 project tracks closely. Fedora 4.0 Beta 4 includes an upgrade to the production version of ModeShape 4.0.0 [33].

Fedora 4 comes with built-in profiling machinery that keeps track of how many times specific services have been requested, how long each request takes to be serviced, etc. These metrics can be visualized using Graphite [34]. Because Graphite can be difficult to setup and configure [35], this release includes a Packer.io build [36] which completely automates the process of standing up a Graphite server.

Additionally, the pluggable role-based [37] and XACML [38] authorization modules have been pre-packaged into fcrepo-webapp-plus [39]. This project builds custom-configured fcrepo4 webapp war files that include extra dependencies and configuration options.

————————-

10) Test Coverage

Unit and Integration test coverage [40] is a vital factor in maintaining a healthy code base. The following are the code coverage statistics for this release.

– Unit tests: 66.2%

– Integration tests: 69.4%

– Overall coverage: 82.5%

=========

References

=========

[1] https://wiki.duraspace.org/display/FF/Glossary#Glossary-namespaceNamespace

[2] http://www.w3.org/TR/ldp/

[3] https://wiki.duraspace.org/display/FF/RESTful+HTTP+API#RESTfulHTTPAPI-RedDELETEDeletearesource

[4] https://github.com/fcrepo4/fcrepo4/commit/5c30c743bb05ef627acc90f4b037b118c7d9de9c

[5] https://wiki.duraspace.org/display/FF/Versioning#RESTfulHTTPAPI-Versioning-BluePOSTCreateanewversionofanobject

[6] https://wiki.duraspace.org/display/FF/RESTful+HTTP+API+-+Containers