Page 159 - Building Digital Libraries

CHAPTER 6

the future. The PCDM was developed out of a number of conversations
between developers from the Samvera (then Hydra) project and developers
from the Islandora project. As these two projects developed, many began to
question the need for highly customized data models for representing digital
library, or more specific, digital repository, content. Within the early Fedora
community, data modeling of content was one of the primary activities that
repository owners and developers would need to complete, and the local
nature of these models made compatibility between various Fedora reposi-
tories difficult to achieve. The goal, in creating the PCDM, was to create a
shared data model that could be implemented at the repository level. This
would enable repositories to have, at least in a limited sense, a basic level
of compatibility. This would mean that potentially, an organization could
more easily move between different repository software, because the use of
a common data model would ease the migration process between systems.
An image in one system would be able to be recognized as an image in
another system, which would also allow for the development of a shared
set of properties and methods.
Presently, the PCDM data model is in active development and is in
constant flux. It is currently used by the members of the Samvera project to
model data into Fedora 4.x, and it is being implemented by the Islandora
community. However, outside of these two groups, there appears to be
little interest in this standard . . . but it’s hard to gauge if this will change.
The promise of a common data model between repository platforms is a
powerful one. If the Samvera and Islandora communities can demonstrate
that data interoperability can be achieved through the utilization of the
PCDM data structure, we believe that its use will increase. If it does not, then
this may remain primarily a data structure used within these two specific
projects, but it could serve as a template for other projects or organizations
developing their own data models. It’s really hard to say today.

Semantic Web

What becomes very apparent when one starts working with digital reposi-
tories and their content is the wide range of metadata choices that one
must choose from. This chapter merely discusses the most widely utilized
general metadata frameworks, but other frameworks like FGDC (Federal
Geographic Data Committee) for GIS data, VRC (Visual Resource Core)
for visual items, EAD (Encoded Archival Description) for finding aids,
MADS (Metadata Authority Description Schema) for authority data, ONIX
for publishers’ data, and so on all provide specialized metadata forms that a
digital library program may find it needs to integrate within its digital and
metadata architecture. In the past, the need to select the correct metadata
format was incredibly important, since the decision could potentially limit
the ability to fully represent diverse types of objects or formats within
one’s system. In some ways, I think this is why many organizations utilized
multiple digital repositories within their infrastructures. It wouldn’t be

144