Hi all,
A couple of weeks ago Mary Larsgaard asked Misha, chair of the
DC datamodel WG, about the relation of the DC datamodel to
the datamodel for AACR2 produced by Tom Delsey. (see
http://www.nlc-bnc.ca/jsc/aacrdel.htm
Misha delegated this to me, so I took a look at Tom's excellent
work and wrote up a little thing that I sent to Mary and Misha.
Misha has suggested I forward that to this list, so here it is.
The usual disclaimers about being a dumb Okie apply.
Ron
About the relation of the DC datamodel WG to Tom Delsey's
logical structure of the AACR2...
Ah, homographs - gotta love 'em. The homograph in this
case is 'data model'. The DC datamodel is of a different
nature than Delsey's treatment of the AACR2, which in turn
is different than the data model developed in the IFLA
study on functional requirements for bibliographic
identifiers. These three form a spectrum. The IFLA work is
at one end, where they work up a theoretical model of
bibliographic items from the abstract notion of a "work" such
as Hamlet, which may have "expressions" such as a playscript
or a movie, which in turn have "manifestations" such as 324
pages of A4 in a cloth binding, or a VHS cassette. Finally,
there are "items" - individual copies of a manifestation.
Adding to this the notions of "person"s and "corporate bodies",
as well as concepts such as "event", "place", "object", and
"concept", they come up with a framework for a new
bibliographic record.
Delsey's work is in the middle of the spectrum. (Or maybe
about 3/4 of the way towards the IFLA model). Rather than
starting to make a first-principles model of bibliographic
description, he starts with an existing description (the
AACR2 rules) and derives the existance of underlying real-world
entities such as "Person", "corporate body", and concepts such
as "ownership" and "creation". He also derives 'real-world'
bibliographic constructs such as "document", "document part",
"content", "content part", "infixion", "class of materials", and
"physical carrier" that have a correspondance to the 4 levels
in the IFLA model (work, expression, manifestation, and item).
He then shows how existing AACR2 descriptors relate those
'real-world' entities. This makes it possible to spot
irregularities in the way AACR2 treats things. For example,
Delsey says:
The wording of rule 0.24 [from AACR2] implies that the form
of the physical carrier determines the class of materials to
which the item belongs. However, a detailed examination of how
each class of materials is defined [this examination is of
Delsey's model] indicates that while the form of the physical
carrier is in many cases the principal criterion for determining
the broad class of materials to which an item belongs, there are
in fact other criteria at play in defining the scope of those
classes.
The current work in the DC datamodle WG is at the far end of this
spectrum. Like Delsy, we take certain things as given (e.g. the 15
elements of the DC, the requirement for dealing with qualifiers,
some particular qualifiers such as those of the relations WG).
Unlike Delsy and IFLA, we have not tried to develop a consistent
model of 'real-world' entities and their relationships. Instead, we
have concentrated on something that has a consistent structure
when viewed as data. The use of the RDF data model is part of this,
the DC data model is based on directed labelled graphs. By looking
at a number of different graphs for expressing the information people
say that they want to use when making qualified DC descriptions, we
found a "template" (or sterotypical construct to use in the model)
that appears to accomodate the majority of those cases. The emphasis
is on having this regular structure that underlies different semantics
(such as saying that one Creator is an Illustrator while another is
the arc-welder). This emphasis on a common structure is due to the
assumption that not all DC clients will understand all possible
qualifiers, so there needs to be a common data structure underneath
that can be traversed, allowing complex descriptions to be simplifed
even when the code doing the simplification does not 'understand' all
the qualifications on the element. Another reason for the common data
structure is so that different syntaxes can be used to carry the info,
but if we know the syntax-specific rules, we can get to the common
data structure.
Regards,
Ron Daniel Jr.
DATAFUSION, Inc.
139 Townsend Street, Ste. 100
San Francisco, CA 94107
415.222.0100 fax 415.222.0150
[log in to unmask]
http://www.datafusion.net
|