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. http://blog.jweinheimer.net/2012/09/cataloging-matters-no-16-catalogs.html 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 http://sites.google.com/site/opencatalogingrules/ Cataloging Matters Podcasts http://blog.jweinheimer.net/p/cataloging-matters-podcasts.html

Reply via email to