On 12/7/2013 9:38 PM, Kevin M Randall wrote:
No, the FRBR model uses the language of entity-relationship models.
But that model is being used to illustrate the relationships of the
elements. It's a language for understanding the data. But the model
isn't talking at all about the structures of data storage. Not one
bit. That is not what it's concerned with! FRBR doesn't care if you
keep the subject information (name of the subject, etc.) in a single
record, not duplicated anywhere else, or copied in full into the
records for every work, expression, and manifestation it's related to.
That is irrelevant to what FRBR is talking about. FRBR isn't about
database efficiency; it's about knowing what the pieces of data are,
what they mean, and how they relate.
"FRBR isn't about database efficiency; it's about knowing what the
pieces of data are, what they mean, and how they relate."
I cannot agree with that statement since the reason for an
entity-relationship model is for building databases and primarily
relational databases, but for the moment, let us say that you are right
and that FRBR is bigger than that. Therefore, I gather you are focusing
on the relationships section in the FRBR data model because our current
records show very clearly what each piece of data is and what each means
(a uniform title, a series, a personal author, a topical subject, a
publisher, etc.) and FRBR changes nothing of that. I have already agreed
that adding the FRBR relationships, that is, the specific relationships
of "adaptation" or "summarization" or "complement" or "supplement" and
so on, and adding the relator codes, where someone is "editor" or
"director" or "actor" would provide something different from what we
have today. I have already mentioned this.
There are two major hurdles, as I have already noted. The first is
practical: the specific relationships are currently not in the "legacy
data". Please explain how are we supposed to include those relationships
in our legacy data because, as I demonstrated, the legacy data amounts
to *millions* of instances. That is an absolute fact that cannot be
denied. Are catalogers supposed to add that information to those
records? If so, please let us know how we are supposed to add the
relationship information to those millions of records. Many more people
than myself are very interested in how we can change millions of
records. How are catalogers supposed to do it manually? Or is someone
else going to do it? If so, who will do it and how?
Perhaps there is some kind of automated solution available that we do
not know about. If so, could you please provide us with details of some
projects or of work in progress? Costs are always a consideration. How
much will any of this cost? Or, are we simply supposed to ignore the
legacy data altogether? What happens then?
I suspect that the legacy data is considered to be relatively
unimportant to the FRBR/RDA community and that is why nobody wants to
discuss it. Unfortunately, it is quite the opposite for the public: the
legacy data is 99%+ of what is available to them in the library. If the
legacy data is to be ignored, or "put off for another day" shouldn't the
users be a part of such an important decision that would, as I have
discussed in my podcast on Consistency, where I mentioned that
"...implementing RDA and FRBR will actually /*reduce*/ access to the
materials in our collections" and then went on to explain how and why.
If users shouldn't be a part of such a decision, why should catalogers
be the only ones to decide?
The second hurdle is not so much a hurdle, but a problem: could you
demonstrate to us why adding the relationship information will make such
a fundamental difference to users so that they will return to our
catalogs? Are the relationships really what the public has been missing
and needing all this time? Where is the evidence for that? I have never
seen anything that suggests anything like that, but I confess I live far
away in Italy and have been out of the mainstream in many ways.
Nevertheless, I am willing to learn if sufficient evidence warrants it.
James Weinheimer weinheimer.ji...@gmail.com
First Thus http://catalogingmatters.blogspot.com/
First Thus Facebook Page https://www.facebook.com/FirstThus
Cooperative Cataloging Rules
Cataloging Matters Podcasts