Quoting John Attig <jx...@psu.edu>:
John, thank you so much -- this is very helpful. Wonderful, even.
Access points are treated rather strangely in RDA. The access point
is not itself an element, but is a construct made up of other
elements, which contains instructions about what and when to include
various elements in an access point.
That actually makes sense from a data design point of view. It means
that compound "things" can be built up of simple "things", and that
means that you have flexibility in what you can build. (read:
tinker-toys, or, for the younger set, Legos)
In our discussions of the question of how to treat access points,
the JSC was advised that there were certain structural complexities
that we should not attempt to build into the RDA element set, but
should rely on the encoding to bring together the various elements
into the access point construct.
Here I want to point out that there can be a useful difference between
your data elements, data model and your instance data. Your data
elements can be atomistic, your data model can allow building of
various "molecules" from the atoms, and your instance data can make
use of the whole in many different ways.
In MARC, we are accustomed to using subfields to encode the specific
data elements and fields to wrap them up into an ordered construct.
Similarly, in XML, one would expect to use some sort of "wrapper" to
enclose all the elements that make up the access point. In order to
do this, I suspect that one needs to treat the access point
construct as if it were an element, even if the RDA element set does
not treat it as such.
I could also imagine that happening in an application layer. Without
any change in the underlying data there could be different
interpretations -- I usually call them "views" -- of the data. [Your
last para states this very well; see below] But the key thing is that
by not having the individual elements bound into the RDA complex
elements you have freed the "sub-elements" from that structure, and
they can be used in various ways if desired. In a situation where the
only way to express "date of expression" is in an access point, you
have restricted that data element (which may be of interest for other
reasons) to that one situation.
The more I look at RDA as elements the more I admire the separation of
data content from record structure. This gives us many more
possibilities for system developers.
Beyond these technical issues, this discussion raises questions
about the way in which access points are constructed and used.
a) The instructions on what to include in an access point represents
our collective experience of what is important for uniquely
identifying a given entity. There seems to be some value in
gathering all these elements together for indexing and display as an
aggregation of identifying information.
Yes, and that should be possible.
b) While it is true that the individual elements are sufficient for
finding relevant resources and don't need to be aggregated in a
precoordinated way in order to work, I would argue that finding,
identifying, and selecting relevant resources is sometimes best
supported by browsing an alphabetical list of access points that are
constructed in a way that reveals the structure of the things being
browsed. Examples might be an alphabetical display of hierarchical
entities such as corporate bodies, or an organized sequence of
headings representing works and expressions. We may not NEED access
points, but they can sure be helpful on occasion.
I think this becomes a system efficiency question rather than a
"meaning" question. At what point do systems need to manage these
strings for the most efficient use? Is it easier to create them
automatically in case they are needed, storing the data in multiple
places? Or will there be a reason to bring this data together "on the
fly"?
I don't think we need to answer that at this point, but I would like
to suggest that it would be ideal to begin to develop "use cases." Use
cases state a situation (user is looking for xyz), and what you would
like the outcome to be (user gets/sees/is asked for...). There amy be
more than one way to do this. You have included a use case here in
suggesting an alphabetical display. There are undoubtedly search and
find use cases related to this information (user wants bookX but only
in Spanish), etc. Since a system should attempt to satisfy a variety
of use cases, this would help me (and maybe other systems
developers/thinkers) to understand the range of services we want to
get out of this data.
In essence, the data as input should not be considered to be the same
as the strings that the user will see. It was so, often, in MARC, but
that was kind of a throw-back to the card days. Today one designs user
interfaces and services BEFORE defining the data structure. The atoms
of RDA will hopefully be easier to work with in systems than the
pre-coordinated display strings of MARC, but we still need to define
the services we wish our data to support.
d) While many of us are skeptical of the ability of algorithms to
create such structured access points automatically, it is certainly
worth the attempt.
This might be a good place to start in terms of use cases -- what can
be done to fulfill user needs that structured access points fulfill
today?
If there could be a clear set of objectives for the exercise,
algorithms might in fact be possible, bringing together relevant
elements and arranging them in a significant order to form the
access points. Even better, it might be possible to (i) offer
different options for sequencing the elements -- sorting first by
language or by format, for example -- and/or (ii) work in real time
to formulate the best way of sequencing a given result set.
Catalogers tend to resist giving up their hand-crafted headings, but
that tends to be because they are not offered attractive
alternatives. What I suggested above seems to be such an attractive
alternative.
Yes, this is great. It really expresses the possibilities.
kc
John Attig
Authority Control Librarian
Penn State University
jx...@psu.edu
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
