Friday, March 30, 2012

Re: [ACAT] New rule implementation

Posting to Autocat

On 29/03/2012 22:12, Kevin M Randall wrote:
<snip>
James Weinheimer wrote:
That is news to me. From everything I have seen, the data model is based on entities, and the entities are based on URIs. Entities in turn have specific attributes. This is how entity-relationship structures work. I have repeatedly tried to point out that in the traditional catalog, the purpose of the so-called work or expression was *only* for arranging the cards (or unit records, or manifestations, or editions, whatever you want to call it). Today, we would call that a "relationship", or as I prefer to think of it, as a "query". The traditional catalog had meaning due to the *arrangement* of the records that described individual resources. FRBR took a different route and began on completely different assumptions.
To say that the "purpose of the so-called work or expression was *only* for arranging the cards" is begging the question. Why do the cards need to be arranged? They need to be arranged in order to reflect the relationships between the works, expressions, and manifestations. Records in a database lack any specific arrangement, and are arranged on the fly in response to queries against the database. For that reason the explicit identification of WEMI in the metadata are even more critical, since the actual arrangement in the database has no inherent meaning. I don't understand at all how "FRBR took a different route and began on completely different assumptions." Different route from what? Different assumptions from what?
</snip>
The "different assumptions" means the assumptions are that the *users* want to be able to do the FRBR user tasks, which I will restrain myself from enumerating once again. The very action of creating entities according WEMI assumes that it will produce something of value to someone--otherwise, the entire task is absurd. It still remains to be demonstrated that the majority of the public, in the majority of their searches, wants WEMI so badly. And it also needs to be demonstrated that these same WEMI tasks cannot be done with the records and the systems that we have now. If this cannot be demonstrated, what I am maintaining is that there are many other much more fruitful avenues that we can choose to devote our scarce resources to make our records more valuable to the public.
<snip>
Improving metadata by retyping abbreviations is certainly a highly debatable point and puts the question to the RDA/FRBR mantra that they are not about display.
Please, enough with everyone using the abbreviations issue to argue against RDA. This is getting to be quite tiresome. The improvements to metadata that RDA calls for have to do primarily with identifying discrete elements, their attributes, and their relationships to other elements. Abbreviations, capitalization, punctuation, etc. are relatively minor issues in RDA, and unfortunately no matter how many times that gets stated in these forums, it never sinks in. And in regard to saying typed-out words vs. abbreviations is about display, that is wrong. It's about data content, not data display. Those *are* two different things.
</snip>
I agree: this is a very tiresome discussion about abbreviations. It will be far more tiresome for those poor souls who will have to change everything. But it is only one, only a *single one* of the many very tangible points that will demand significant resources that libraries do not have. It also illustrates how RDA wants to change things manually instead of using automated means and it also ignores the issue of the millions of records we already have. This is why I keep bringing it up.

And *of course,* the issue of abbreviations is about display. It cannot be about anything else. How could it possibly be about searching or access? So, it's about "data". Exactly what does this mean? If we were to change our formats to have special subfields for "ca." or "p." (that is, turning the actual number of pages into data) that might be one thing, (incidentally, to change our formats in this way would take a *very long* time) but it still needs to be demonstrated that this added complexity is actually worthwhile. For instance, we would need special fields for "paging" or "volumes" or "parts" or "columns" or--dare I say it: fascicles(!), including a myriad of other possibilities for different formats, each of which are enormous. While the complexity would rise enormously, what use would that be to the public? Or even to librarians themselves?

Various cataloging agencies handle these issues in all different kinds of ways. I have a certain amount of experience in this, and I know that other agencies do things in ways that ISBD/AACR2/RDA catalogers would consider completely bizarre. This is the reality of the totality of today's metadata universe.

I repeat, this discussion simply emphasizes that there is no valid business case for RDA. It seems as if many wish that we did not already have millions of records in our catalogs that are just as valuable to the public as those we create today. If we were starting from scratch, as in most businesses that can essentially ignore practically everything from 10 years ago, that would be one thing, but library catalogs are different. That is, unless we prefer to ignore the records that we already have. That would truly be the saddest consequence.

A couple of responses to other messages:
To Marc Truitt: I agree but will state that all we can look forward to is split bibliographic records among the library community, with unfortunate consequences for everyone. Realize that in the Semantic Web/Linked data universe, library records will be only the smallest fraction of what is available to the public. And that fraction will decrease in the future.

Unfortunately, this discussion should have taken place ten years ago or more. My own opinion is: better late than never, which is apparently what some would prefer.

And to Allen Mullen, Aaron's post, although sincere, is not a business case. Making an actual business case is a complex task, showing the various options (for there are always options), explaining each in detail from procedural to budgetary issues, and explaining why the one you choose is the best. As an example, the UK government has adopted what is called Prince2, which I have had some experience with, and the very first part  is coming up with the business case, so that it can be reviewed and everyone can see the advantages vs. disadvantages. The site is at http://www.prince-officialsite.com/.

In essence, it is the process of defining the problem to be solved, reasons why this particular problem is important to address over other problems, the various options for solution, the different benefits explained, and discussing the risks and costs of each option, and finally why the one you have chosen will have the best results. For instance, one solution may be "the best" in almost all ways, but you determine it will lead to bankruptcy, so you probably shouldn't choose it. How many people and organizations have chosen such an option anyway?

Even though it is called a "business" case, it could also be called something like practical problem solving. There are many ways to do a business case, but in all of them, the business case is one of the very first things that must be done--without it, nothing else can even begin, and this only makes sense.

To still be expecting a business case from RDA after all this time says a lot.

No comments:

Post a Comment