Title (Goal)Transformation of (meta)data for certain types of resources
Primary Actor

Repository architect & implementer 

Scopearchitecture and access
LevelHigh
Story

As a repository manager, I want to define external services to dynamically transform the (meta)data of certain types of repository resources so

  • they can be harvested by other systems
  • a richer user experience can be offered by websites using these services

These definitions can be made and maintained by metadata specialists with knowledge of rdf and related standards, rather than developers.

Examples:

  1. Dynamic transformation of metadata formats, e.g MODS to Datacite
  2. Imagine a hierarchy of objects with model “geographical object”, each with point coordinates in rdf (wsg84) or maybe a kml datastream. A "geo" service for this object model has a method "kml representation of this object and all its child objects, recursively.”
  3. Imagine a setup where datasets, instuments, places etc. are stored as separate Fedora objects to facilitate reuse. A service for datasets can give a representation of the dataset within its context of instruments and places in xml or html. The latter can function as the dataset’s landing page.
  4. Transformation of data: image derivatives, excel to csv, netCDF to CDL, etc.

Remarks:

  1. In Fedora 3, disseminations provided by the Content Model Architecture support this use case.
  2. In many cases (especially with metadata), the transformations can be done with xslt.
  • No labels

4 Comments

  1. David Wilcox

    Thanks for submitting this use case, Egbert. It looks like you've focused on reimplemeting disseminators in Fedora 4, but I think it would be useful to take a step back and describe, in the style user stories, the requirements that need to be satisfied.

    For example, one user story might be:

    "As a repository manager, I want to define an external service to dynamically transform the metadata of certain types of repository resources so they can be harvested by other systems."

    Once we have a sense of the user requirements we can discuss the technical implementation details, but I think it is important to separate these details from the user stories themselves; otherwise we may prematurely box ourselves in with regard to implementation possibilities, and we may also end up building something without fully understanding the requirements it is meant to satisfy.

  2. Egbert Gramsbergen

    I took the step back and rewrote the story. Can I also change the title to relieve the Fedora 3 bias? The title is also in the url of the page.

    1. David Wilcox

      Thanks for rewriting your use case - please feel free to change the title to something more appropriate as well (I believe Confluence will suggest the new URL if someone follows the link to the old one).

      There is a related issue in JIRA for designing XSLT-based transformations in Fedora 4. Would the metadata transformations you have in mind be primarily accomplished via XSLT, or some other means?

      This might be a good topic for a future Fedora Tech call - please feel free to add it to the agenda if you are able to attend the call: 2015-02-05 - Fedora Tech Meeting.

  3. A. Soroka

    An extension of the transform module would accomplish this, I think. Perhaps the transform module could be separated from the core and enriched.

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.