Tag Archives: Fedora

Fedora Disseminators to Enable Accessible Repository Content

Posted on by
6

Calling all accessibility technology experts! What follows is a line of thinking about using characteristics of the FEDORA digital object repository to enable access to content through non-graphical interfaces. Thanks to Linda Newman from the University of Cincinnati and others on the Friday morning DRC Developers conference call for triggering this line of thinking.

In a recent post defining universal disseminators for every object in our repository (if the last dozen words didn’t make sense, please read the linked article and come back), I hinted at having an auditory derivative of each object, at least at the preview level. During today’s conference call, Linda asked if such a disseminator could be used to offer different access points for non-GUI users. Well, why not? Let’s look back at the “presentation” part of the disseminator label:

This is a preview of Fedora Disseminators to Enable Accessible Repository Content. Read the full post (537 words, 2:09 minutes estimated reading time)

Processing Raw Fedora Objects

Posted on by
3

Michael J. Giarlo wrote a very nice summary of my FEDORA trilogy (only three parts so far — I think there are more good things to say about FEDORA; and besides, I like Douglas Adams’ concept of what a trilogy should be), and added a piece that I hadn’t considered:

  1. Having one’s objects stored as XML on the filesystem also opens up opportunities to see how tools which act thereupon might be glued into the repository infrastructure. One such example might be for an XML-aware search engine (such as amberfish, Lucene, or Zebra). Since you’ve got low-level access to these files, it would be fairly simple to tack on a search & indexing system that is independent of your choice of repository.
This is a preview of Processing Raw Fedora Objects. Read the full post (352 words, 1:24 minutes estimated reading time)

Thinking about Our Fedora Disseminators

Posted on by
7

Another reason to consider the FEDORA digital object repository system, if having the ability to put all of your content in one place and reducing the complexity of digital preservation aren’t enough, is the capability to create and define behaviors that the content can perform. In the FEDORA world, these behaviors are called disseminators.

This is a preview of Thinking about Our Fedora Disseminators. Read the full post (1084 words, 4:20 minutes estimated reading time)

Fedora plus Sakai — a marriage made in heaven?

Posted on by
5
Note — there was a follow-up to this post.

What happens when you mix two Mellon-funded projects? Perhaps a nice bit of what they call synergy. The thinking goes something like this…

Sakai


“The Sakai Project is a community source software development effort to design, build and deploy a new Collaboration and Learning Environment (CLE) for higher education. … The Sakai Project’s primary goal is to deliver the Sakai application framework and associated CMS tools and components that are designed to work together. These components are for course management, and, as an augmentation of the original CMS model, they also support research collaboration. The software is being designed to be competitive with the best CMSs available.”1

This is a preview of Fedora plus Sakai — a marriage made in heaven?. Read the full post (482 words, 1:56 minutes estimated reading time)

Why Fedora? Because You Don’t Need Fedora

Posted on by
2

I’m often asked “Why is OhioLINK using FEDORA?”  (Just to eliminate any confusion at the start, I’m referring to the FEDORA Digital Object Repository, a project of Cornell’s computer science department and the University of Virginia Libraries, and not the Linux operating system distribution by Redhat.)  There are many reasons, but I was reminded of one recently while reading through the migration documentation for the 2.1.1 release that came out today.

In case of corruption or failure of the repository, the Fedora Rebuild utility can completely rebuild the repository by crawling the digital object XML source files that are stored on disk.

This is a preview of Why Fedora? Because You Don’t Need Fedora. Read the full post (466 words, 1:52 minutes estimated reading time)

Berkeley’s “bSpace Images” project

Posted on by
1

Word of this Fedora-based image collection tool comes from the Sakai Library & Repositiories discussion group [Sakai Collab account required].

Project Name & Description (Short)

bSpace Images Version 1.0
The initial version of bSpace Images will focus on personal collections and provide “baseline” functionality found in existing tools like Course Gallery, ARTstor, Luna Insight, Portfolio, and Spiro. Through a user centered design process, bSpace Images features will be driven by faculty observations and interviews. Unlike the other campus offerings, its interface design will be based on the faculty’s real needs.

This is a preview of Berkeley’s “bSpace Images” project. Read the full post (157 words, 38 seconds estimated reading time)

On the Need for a General Purpose Digital Object Repository

Posted on by
3

Digital objects — we’ve all got ‘em. Billions and billions of them. And we put them in individual content silos, stratified along such unhelpful lines as media type, owning entity, and other equally meaningless categories. At least meaningless to the end user. So, let’s ask ourselves: what is the job the user is trying to get done? And how can we structure our digital object repositories to help them out?

What is a Digital Object?

This is a preview of On the Need for a General Purpose Digital Object Repository. Read the full post (1537 words, 6:09 minutes estimated reading time)

Repositories Visualized

Posted on by
Reply

On 12/14/05 10:26 AM, Richard Green wrote on the sakai-library mailing list:
The RepoMman projectat the University of Hull, UK, is looking into the area
of workflow as related to an institutional repository. Hull sees a digital
repository as being a tool for its users, assisting them to develop a ‘piece
of work’ (a generic term intended to cover almost anything) from inception
to final form – supporting such things as development, collaboration and
versioning along the way. In other words, we see a repository as much more
than a container only for ‘finished’ digital objects. We are playing with
the acronym ‘AMP’ (access, management, preservation) to describe some of the
related functionality.

This is a preview of Repositories Visualized. Read the full post (473 words, 2 images, 1:54 minutes estimated reading time)