In one way, the XC project seems to have come up with a sensible and
pragmatic approach, perhaps the only one: in order to move forward,
they've created their own patchwork scheme, incorporating elements from
others where they exist. It's not meant to be theoretically rigorous,
it's meant to be ugly, and work. The XC Metadata Services Toolkit is a
platform for all kinds of transformation, and, crucially, exposes the
transformed metadata at each stage of transformation.
But as Karen points out, this is all about transformation for use, not
creation. The position XC is designed to occupy in the library workflow
means that metadata continues to be created in a legacy format, then
converted and served up on the fly. But what other choice is there, at
this point? Here's where my "thought experiment" comes in. Actually,
it's the situation I find myself in, so there's some self-interest
here--but I think it's a valid thought experiment, anyway.
You're the technical services / systems librarian at a very small art
research library (40k records). You can make virtually any decision you
like as to cataloging policy, and, within certain budget constraints, as
to systems choice and development. You're willing to roll up your
sleeves and do some coding, but you're not a seasoned programmer. The
size of your library means that you can spend some time massaging your
data, and there aren't any veteran catalogers to yell at you. Even a
suggestion as radical as abandoning LCSH for Getty vocabularies for
general collections encounters no opposition.
What sort of a system do you put together, in the next year or so? There
are things you'd like to do with your data which MARC, in its current
state, can't do (e.g., record the source or URI of a controlled
vocabulary term at the subfield level), and most existing tools are
built around MARC. You're free to do what you like with the data, but
library business processes must go on, in some fashion: serials need to
be checked in by support staff, books need to circulate.
Is XC's approach (legacy ILS* > Metadata harvest & transformation >
decoupled search interface) the only viable one in this scenario, or is
there another model? Or even variations on the same model?
*And I'm including the open-source ILSes under this rubric, because
they're not essentially different. Of course, an open-source ILS, unlike
a proprietary one, could be re-engineered around a new data format, but
that's probably beyond the abilities of our single librarian.
On 4/20/2010 3:46 PM, Karen Coyle wrote:
> The difference I see, though, between XC and some of the discussion
> here is that XC is about *use* of data not *creation* of data. In
> other words, XC is about taking metadata and transforming it. I still
> can't quite figure out the level of detail that is retained after the
> transformations, but all of the verbs are things like "harvest" and
> "transform", meaning that metadata has to already exist.
>
> The analysis that hasn't been done on library cataloging is: "what
> elements and coding are necessary for the desired system
> functionality?" We don't know what level of detail is useful, much
> less cost-effective. The cataloging rules (AACR2, RDA) address some
> functionality (e.g. designing headings for an alphabetical view), but
> ignore most of it (e.g. how to provide searchable values for dates;
> how to code serials numbering for check-in services). I'm fine with
> the system functionality analysis being a second step in the process,
> but it has to be a step, and it has to be part of the same process
> that produces cataloging rules, for two reasons: 1) the rules may have
> to make some compromises in order to have the desired system
> functionality 2) the same catalogers who will be creating the AACR2 or
> RDA cataloging data are the ones who are creating the data that will
> be used by systems, whether added on to the cataloging rules or
> included with them.
>
> I don't think we can go forward unless this step takes place, yet, as
> I've said before, we don't seem to have any organization or entity
> whose task this is. JSC isn't taking it on (and doesn't have the
> skills to); LC took it on for AACR/MARC, but seems unable to play that
> role today; the "publishers" of RDA are just that: publishers, not
> systems folks.
>
> kc
--
Cory Rockliff
Technical Services Librarian
Bard Graduate Center: Decorative Arts, Design History, Material Culture
18 West 86th Street
New York, NY 10024
T: (212) 501-3037
rockliff_at_bgc.bard.edu
---
[This E-mail scanned for viruses by Declude Virus]
Received on Wed Apr 21 2010 - 13:21:28 EDT