Ross Singer wrote:
So, thanks to the help of my coworkers, here's the RDA Elements schema
reformatted in an easier to read presentation:
http://morph.talis.com/?data-uri[]=http%3A%2F%2Frdvocab.info%2FElements.rdf&input=&output=exhibit&callback=
I have to say I feel like this schema is trying to both do way too
much and subsequently loses the resource specificity that RDF would be
providing.
Absolutely. I think there 's a real issue that NO technology folks were
involved in the creation of RDA. So this is "data" from a cataloger's
perspective, and from the perspective of guidance rules for creating
bibliographic data. I'm pretty sure that we can't create a viable data
record using the RDA data elements, and I hate the idea that the data
format, once again, is an afterthought rather than integral to the data
creation standard.
For one thing, it seems to reinvent a _lot_ of wheels. Why does it
define its own title property instead of using DC's?
Because they wanted their own definition. Everything in the RDA element
list has an RDA-specific meaning, which then makes it impossible to use
any existing data properties. But there's more: RDA was defining RDA
cataloging rules, not a schema or record format. Not only are there
multiple data elements where one could do, there are things that are
missing. For example, the FRBR "place" entity can ONLY be used as a
subject, so it really means "place as subject". There's no general
"place" element that could be used, for example, in place of
publication. The latter has no relationship to FRBR place. This is a
FRBR problem as much as an RDA problem, but again FRBR functions at a
conceptual level and doesn't really provide a schema that one can work with.
By using
properties like titleOfTheWork, dateOfWork and all of the properties
that are specifically about TheSeries there is tremendous duplication
of text. If Work was its own class, you would only need say that this
manifestation was an embodimentOf of it and reuse all of the
title-based properties for manifestation.
Exactly. This is what I've been saying (or trying to say) in relation to
the bibo discussion. You should be able to use whatever properties you
want with the FRBR classes, and not restrict data elements to a single
class. This is a big problem in RDA, but I can say that when it was
brought up to them (JSC) they strongly defended this choice and would
not budge. RDA, to JSC, has a specific relationship to FRBR, and if you
use a data element with a different FRBR class, then you are no longer
doing RDA.
What does property 'uri' mean?
Did you look at the rdf/xml? I'm wondering if it isn't the display
that's confusing.
I also can't figure out how people/institutions are modeled in this
schema, since none of the elements have ranges. Are they their own
resources? If so, what? The way it looks at a glance, they're
strings?
EVERYTHING is strings at the moment, with a very very few exceptions
(like some dates, I think). Some data elements CAN use a controlled
vocabulary, but I believe that all of those are a mixture of
uncontrolled and controlled strings. People and institutions are mainly
undefined because that is in the FRAD realm. And FRAD hasn't been
finalized. Also note that the JSC didn't feel it could do anything that
would be too incompatible with the 'legacy' -- that is, with all of our
AACR/MARC data.
It seems to me that very little work was done find preexisting
vocabularies to reuse and this schema still presents a very
'document-centric' or 'record-centric' view of data.
Absolutely. The catalogers are still creating a textual document, not
data. At best you can mark up the text, as we do with the MARC record. I
worry that we won't be able to mesh the cataloger's view with a data
view -- that the two are some how inherently opposed. I'd like to start
modeling a new data format but I can't imagine how we can bridge the gap
between the catalogers and the system view. I suppose a very clever
interface could hide the data view from the catalogers, but starting
from either AACR2 or RDA and trying to get there feels extremely
difficult. I guess my fear is that it will require compromises, and
those will be hard to negotiate.
kc
p.s. The RDA element analysis is at
http://www.collectionscanada.gc.ca/jsc/docs/5rda-elementanalysisrev2.pdf.
That was the input to the registry.
--
-----------------------------------
Karen Coyle / Digital Library Consultant
kco...@kcoyle.net http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
