Category: Announcements

Princeton Hydra Release: Digital Archive of Latin American and Caribbean Ephemera

Recent Announcement from Princeton:

We’ve finally soft launched our first public application that is serving content from Hydra: http://lae.princeton.edu/. There is still some tweaking to do to Solr and the CSS, but we’re getting close. Staff have been adding data to this application at a rate of 150-300 items per month since for about 6 months now, and we expect to be at a consistent rate of 300/month or more by the summer.

This public interface has some features that may not be obvious to the average end-user:
* All of the images are served via IIIIF (e.g. http://libimages.princeton.edu/loris2/puls%2F0%2Fj%2F0%2Fg%2F1.jp2/full/75,/0/default.jpg)
* The individual catalog pages are displaying data drawn from IIIF Presentation manifests: http://lae.princeton.edu/catalog/0d7hm.jsonld (and, as you can see, also available as IIIF Manifests)
* All of the data is also available as RDF, e.g.: http://lae.princeton.edu/catalog/0d7hm.ttl

Indiana University Receives NEH Grant for Digital Preservation using Hydra

The National Endowment for the Humanities recently awarded the Indiana University Libraries and WGBH Boston a grant to support the development of HydraDAM2. This preservation-oriented digital asset management system for time-based media will improve upon WGBH’s existing HydraDAM system and work seamlessly with the Avalon Media System for user access, among other features.

Both HydraDAM and the Avalon Media System grew from the Hydra community. Hydra is an open source technology framework that supports the creation of preservation and access applications for digital assets based on the Fedora repository system. A community of institutions known as the Hydra Partners works together to maintain the framework and create applications for local or shared use by libraries, archives, and cultural institutions. Both Indiana University and WGBH Boston are among the 25 Hydra Partner institutions. Indiana University is collaborating with Northwestern University on the development of the Avalon Media System and WGBH developed the original HydraDAM system with help from the Data Curation Experts group.

[complete article]

HydraDam is based on the popular Hydra application Sufia. You can view some interesting examples of institutions using Sufia for digital preservation here:

Penn State: ScholarSphere

Notre Dame: CurateND

Case Western: Digital Case

 

Hydra Project

 

ProjectHydra.org
Avalon Media Systems

 

Hydra & DuraSpace: agreement for project services

Recent news from the Hydra community, sent by Tom Cramer, Chief Technology Strategist, Stanford University Library:

HydraNauts,

I am pleased to share the news that Hydra has officially entered an agreement for DuraSpace to provide banking, financial and marketing/communication services for 2015, to help support and advance the Hydra Project.

As we have seen some remarkable growth in the last two years, it has become increasingly apparent that a service provider could help meet  the project’s growing administrative needs, and help position it for even further expansion. After canvasing the landscape for potential host organizations, DuraSpace appeared as a natural fit for the project, given its overlapping membership, stewardship of other vibrant projects (in particular Fedora), and a shared vision about the future potential of Hydra. 

After discussion over several months on the Hydra Partners list and within Hydra Steering, a unanimous vote among the Partners ratified this direction last month. This marks a significant step forward for the Hydra Project in terms of maturity, and positions us well for growth in the coming years. One of the first tasks for us will be to launch a small, volunteer fundraising campaign for 2015; more on that anon!

On behalf of the Hydra Partners and Steering Group,

– Tom

New Hydra Partner: University of Alberta

We are delighted to announce that the University of Alberta has become the latest formal Hydra Partner.  The University of Alberta has well over a decade of experience in large-scale digitization and repository projects, and has a strong team of librarians, developers, data curators and other experts migrating their existing systems to what they are calling “Hydra North.”

In their Letter of Intent, the University of Alberta says that they are committed to using their local needs as pathways to contribute to the Hydra community. Their primary areas of focus in this will be research data management, digital archives, and highly scalable object storage.

http://projecthydra.org/

code4lib 2015

C4L-ajamie

450 people from around the world gathered in Portland Oregon last week for the 10th annual code4lib library technology conference.

On Monday, approximately 18 pre-conferences were held in half and and full day sessions mostly comprised of demos, tutorials and discussion groups. I attended a morning session on linked data lead by Tom Johnson of DPLA and Karen Estlund of the University of Oregon. As a developer, the demonstration of the ruby gem ActiveTriples was particularly interesting in its ability to quickly model content into RDF classes and properties that can seamlessly connect to fedora 4 persistence or any extensible back end.

In the afternoon I attended a GeoBlacklight demo lead by Jack Reed and Darren Hardy of Stanford. The Stanford GeoBlacklight is a leading map collection interface that allows for spacial search, presentation, and discovery based on the development of metadata schemas, conversion workflows, and interface presentation components. The workshop focused on using the VirtualBox virtual machine and Vagrant setup environment to bring up an instance of geoblacklight in minutes.

On Tuesday the conference proper started with a keynote by Selena Deckelman. Her talk focused on the importance of leading the coding community based on principles of inclusion of beginners and marginal groups. The presentations on Tuesday expanded on that theme with talks focused on users, teams, developers and experiences in dealing with library technology challenges.

The presentations of Wednesday were more technically focused. Thursday morning a closing keynote was given by Andromeda Yelton who encouraged building systems with tools designed to best satisfy the “wanderlust” behind user’s and patrons’s drive to discovery. In between the 20 minute presentations were 2 hour long lighting talk session comprised of 5 minutes talks by 12 people. I thought the keynotes nicely framed the conference, the lightning talks were a great way to digest and get a pulse on what people were working on. As a developer I was particularly interested the the presentation of tools providing facility, such as Kevin Clarke’s presentation of Packer, a dev-opts tool for deploying to virtual machines, and Stanford’s OEmbed service for offering embeddable links to their digital collections, and a presentation by Stanford’s Rob Sanderson and Naomi Dushay describing the experience attempting to integrate their ILS, digital collections, and discovery indexes.

On Thursday afternoon and Friday, I attended working groups focused on fedora 4, hydra’s support of fedora 4, content modeling, and the linked data platform. The discussions were vigorous, and it was a beneficial mental exercise to spin out the various content model concepts of collection/work/file, the distinction between the “aggregates” and “members” predicate, and how to use the LDP Direct and Indirect Containers to deal with assets, rights, and ordering proxies, although I’m afraid not much was resolved. But DPLA (Digital Public Library of America) appears very interested in furthering these concepts into usable models that may promise to be a great step forward in furthering metadata discovery and interoperability.

All in all worthwhile, keeping an eye on next year’s conference, venue TBD.

Hydra Repository Now 3-Lock Data Compliant

The underlying storage infrastructure in use by Yale University Library’s Hydra repository is now 3-Lock data compliant.  Data and information at Yale is classified into three different tiers to categorize data security (more here).  3-Lock data can include things like Social Security numbers, credit card numbers, trade secrets, medical records, tax records, grades for assignments and courses, passport numbers, Veterans Administration data, and bank account numbers.  This upgrade is intended to meet the needs of units across the Library depositing material, and in particular units that are interested in the storage of digital personal papers that may contain sensitive content.  Thanks to Steve DeGroat and John Coleman of the Design & Quality Assurance team within Yale ITS Infrastructure Services.

Tufts University Becomes 25th Hydra Partner

Tufts University officially became the 25th Hydra partner on November 18, 2014. The full list of partners and Hydra adopters wishing to be publicly recognized may be viewed here: Hydra Partners.

In addition, I wanted to provide a link to the November Partner Phone call notes. Some highlights below:

  • The Hydra Steering group elected two new members: Jon Dunn, Indianna University and Michael Giarlo, Penn State University.
  • The Steering group will undertake a process to draft a set of bylaws for governance of the project given its rapid growth.
  • The Steering group is also beginning to look at contract services for banking and other legal activities such as trademark and intellectual property.
  • Significant expansion of Hydra adoption in Europe was reported as well as a successful Hydra UK event at the University of Hull.
  • Hydra had excellent presence and reception at DLF in Atlanta this past October.
  • DuraSpace conducted a Fedora 4 webinar which is now available online.
  • A proposal for formalizing the creation of Hydra special interest groups is near ratification.
  • The Hydra Archivists Working Group (HAWG) has reformed under the new leadership of Ben Goldman, Penn State University.
  • Stanford announced ArcLight as a formal project that is kicking off and seeking partnerships for planning and development. In short, ArcLight is an effort to build a Blacklight-based environment to support discovery and digital delivery of information in Archives. Which also includes integration with ArchivesSpace and EAD support.
  • Hydra expansion into South America is underway and several universities (wishing to remain anonymous at this time) are beginning Hydra development. Another major milestone is the work they are taking on to translate all of the Hydra documentation written in English into Spanish.

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

[7]  https://github.com/fcrepo4/ontology

[8]  http://fedora.info/definitions/v4/repository

[9]  https://github.com/fcrepo4/ontology/blob/master/oai-pmh.rdf

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

[11] http://w3c.github.io/ldp-testsuite/

[12] https://github.com/fcrepo4/fcrepo4/pull/579

[13] https://github.com/fcrepo4/fcrepo4/pull/542

[14] https://github.com/fcrepo4/fcrepo4/pull/587

[15] https://github.com/fcrepo4/fcrepo4/pull/451

[16] http://tools.ietf.org/html/rfc7240#page-7

[17] https://github.com/fcrepo4/fcrepo4/pull/586

[18] https://github.com/fcrepo4/fcrepo4/pull/594

[19] https://github.com/fcrepo4-labs/fcrepo4-oaiprovider

[20] https://github.com/fcrepo4-labs/fcrepo-camel

[21] http://www.openarchives.org/OAI/openarchivesprotocol.html

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

[23] https://camel.apache.org

[24] https://camel.apache.org/components.html

[25] https://github.com/fcrepo4/fcrepo-message-consumer

[26] https://velocity.apache.org/engine/releases/velocity-1.5/user-guide.html#velocity_template_language_vtl:_an_introduction

[27] https://wiki.duraspace.org/display/FF/Federation

[28] https://wiki.duraspace.org/display/FF/RESTful+HTTP+API+-+Containers#RESTfulHTTPAPI-Containers-external-content

[29] https://github.com/fcrepo4-labs/fcrepo4-client

[30] https://wiki.duraspace.org/display/FF/Design+-+Java+Client+Library

[31] https://github.com/fcrepo4-labs/fcrepo4-client/pull/12

[32] http://modeshape.jboss.org

[33] http://modeshape.jboss.org/downloads/downloads4-0-0-final.html

[34] http://graphite.wikidot.com

[35] https://wiki.duraspace.org/display/FF/Setup+a+Graphite+instance

[36] https://github.com/fcrepo4-labs/fcrepo4-packer-graphite

[37] https://wiki.duraspace.org/display/FF/Basic+Role-based+Authorization+Delegate

[38] https://wiki.duraspace.org/display/FF/XACML+Authorization+Delegate

[39] https://github.com/fcrepo4-labs/fcrepo-webapp-plus

[40] http://sonar.fcrepo.org/dashboard/index/1

New Staff in the Digital Library Programming Services Department

I’d like to introduce everyone to Tracy MacMath, she joined us this week as a User Interface Programmer who will be working primarily on Hydra, Blacklight, Ladybird and other Hydra related applications we adopt such as Avalon. Previously Tracy worked as a User Experience Producer at Gartner and received a Masters of Science in Interactive Communications from Quinnipiac University.

In addition to introducing Tracy, I thought it might help to offer some quick bios for the whole team.

Michael Friscia – Manager, Digital Library Programming Services
michael.friscia@yale.edu 
I arrived at Yale in 2007 and worked primarily supporting workstations, ILLiad and programming on various projects for the LSF, Map Department and the wide range of Digital Library interfaces. Since then Library IT has changed quite a bit and I now manage the group that is primarily responsible for working with the Hydra implementation in support of a number of grant funded projects including Arcadia, NEH and the Dr. Henry Kissinger Papers. I started programming early, my first computer arriving for Christmas in 1979 and recently celebrated 30 years of programming C++ applications though still enjoy programming in Algol and Basic on a variety of vintage computers in a collection that spans from 1964 to 1995 with some overflow in my office that I crank up from time to time. I enjoy writing software of all types but spend my free time working on several open source video game and game emulation projects.

Eric James, Senior Programmer Analyst
eric.james@yale.edu
My official title is Programmer Analyst, Library IT.  I was hired 7 years ago to work on a digital repository service that became the current YaleFindingAidDatabase, and a grant project A MiddleEasternElectronicLibrary (AMEEL) that was one of the earliest adopters of a software stack for the submission, achiving and dissemination of digital material.  This work has matured over the years and is now basically taken the form of Hydra, an interinstitutional project with these same goals bringing together such components as fedora, solr, and mysql.  I am a programmer on these these projects (php, java and ruby/RAILS) and have been involved in various teams such as the Digitization Task Force, the YFAD Coordinating Committee, the Digital Repository Archiving Committee, and most recently the Kissinger Project working to coordinate technology with our strategic plans.  I have participated as a programmer in several sprints for the fedora 4 project (the future underlying repository of most of our solutions) and in the development and use of the hydra stack, and am involved in working groups related to these projects.  Throughout these projects I have worked with software project management tools such at GIT, sharepoint, wrike, basecamp, pivotal tracker, jira, confluence wikis, and classesv2.  I have been involved in several conferences including participation as presenter, and in lightning talks and poster sessions at Open Repositories, code4lib, hydraConnect and the DigitalLibraryFoundation.

Osman Din, Senior Programmer Analyst
osman.din@yale.edu
I got into software engineering, and programming in particular, due to my background in Computer Science. My current career focus is on developing back-end large-scale services for digital content management and publishing, as well as writing web applications and tools that aid in this enterprise. Besides other assignments or projects that I participate in, the bulk of my time is dedicated currently to two major projects, Ladybird 2 and Fedora 4.  Ladybird 2 is a Java application for managing the publishing and discovery of digital content to repositories (such as Fedora) and user-facing web applications (such as the Hydra interfaces). I’m the lead developer for this project. The code is written via IntelliJ, lives in GitHub (eventually, it will become an open source project), and is managed via Jenkins for continuous integration. For Fedora 4, which is an open source repository system with about 30 developers, I keep the code that I write in a fork on GitHub, and submit it to the Fedora 4 project team lead in the form of GitHub pull requests. The code is tested automatically for integration and fitness via Travis and Jenkins; the documentation for new functionality is kept up-to-date in Confluence; the status updates for features and bugs are recorded in Pivotal Tracker. My favorite tools for software design and programming are IntelliJ, bash, Eclipse (for proprietary frameworks), Virtual Box, Git, Jenkins and LucidChart.

Lakeisha Robinson, Programmer Analyst
lakeisha.robinson@yale.edu
How I began a career in programming:
Immediately following college is when I started my career at IBM. It was there at IBM, where I designed and coded programs in C/Assembly, when I realized how much I loved programming. I had a hardware background in Electrical Engineering and didn’t have a strong programming background. When I left that job I decided to pursue a degree in Computer Science to strengthen my programming skills. I started my career here at Yale University 2 years ago. I’ve participated on many exciting projects including Quicksearch, Kissinger, Ladybird and Findit.

Projects I’ve worked on and am currently working on:
I am the technical lead on the Blacklight based Quicksearch project. Quicksearch is where we are unifying our Orbis and Morris records to be searched in the same interface. I am responsible for many of the code changes for the setup, ingest and interface functionality. I am also working on the Kissinger project where I am responsible for the discovery of Kissinger material. I’m also one of the original contributors to our Blacklight based digital ‘Findit’ interface where I was responsible for the creation of the MODS formatted XML document retrieving data from the Ladybird database. I also was responsible for the object discovery in the interface and I continue to do ongoing work on enhancement.

Anju Meenattoor, Programmer Analyst
anju.meenattoor@yale.edu
I have been working in IT for 8 years focusing mainly on web development and C#.Net applications. I started my career at Yale in January 2014 and am current working on Dr. Henry Kissinger project. Since January, I have been involved in developing applications for importing Kissinger MODS files, automate Kissinger digital file import into ladybird, Manual QC tool for checking Kissinger digital files and Ladybird maintenance.

Tracy MacMath, User Interface Programmer
tracy.macmath@yale.edu
I’m the newest member of the Digital Library Programming team. As a User Interface Programmer, I’ll be working primarily on our implementation of Hydra, Blacklight, Ladybird and other Hydra-related applications we adopt in the future (such as Avalon). Before coming to Yale, I was a User Experience Producer for the Marketing group at Gartner in Stamford. I received a Master of Science in Interactive Communications from Quinnipiac University, and an undergraduate degree in music (drums and percussion).

FindIt, QuickSearch Security Design Review Completed

"data.path Ryoji.Ikeda - 4" by r2hox is licensed under CC BY-SA 2.0
“data.path Ryoji.Ikeda – 4” by r2hox is licensed under CC BY-SA 2.0

Yale University Library FindIt and QuickSearch services have completed a Security Design Review (SDR) by the Information Security Office of Yale ITS.  These systems use the Hydra repository solution as the underlying technology stack.  The SDR process is used to provide recommendations for building, improving, or reengineering services to meet University policies, industry best practices, laws, and regulation requirements.  Thanks to Bob Rice for evaluating and implementing the recommendations and Tom Castiello and Marcus Aden from the Information Security Office for their insight and participation.