Quoting Weinheimer Jim <j.weinhei...@aur.edu>:
This discussion has shown me that the determination of attribute vs. entity is a highly subtle one, loaded with lots of "booby-traps" and false paths along the way.
It is a difficult distinction, and one that could lead down a lot of long and winding (and often not useful) philosophical paths. At some point, a decision must be made, and I would suggest that it be made in terms of desired functionality, not theoretical correctness. John Attig's statement that the treaty title is designed that way for alphabetical display is a kind of functionality, so it's one argument FOR the creation of treaty titles as defined in RDA. However, an argument AGAINST is that the functionality provided by authority control over names will be difficult if some names are embedded in titles, so we need to think hard about how we can create a structure that makes both authority control and sorting possible, if we want both functions. My point, however, is that you have to think about system functionality in the design of your data (and RDA is designing data, although there seem to be some attempts to deny that). There are things you can do on paper and in the human mind that are very very difficult to replicate in a computing environment. We've got huge problems of that nature with AACR2 and MARC, and it would be best to avoid them while we're creating something new.
Getting a competent understanding of this will require quite a bit of training and probably, a fair amount of consultation with colleagues to ensure everything is done correctly and accurately.
This choice about attribute and entity needs to be made in the data design, not at the point of cataloging, IMO. I'm trying to think of an exception to that, and can't come up with one... Where I think we *could* have choices, although it is not allowed within RDA, is in deciding on the attributes that are associated with an entity. As an example, some specialist communities would like to use attributes like "colour" in the Work entity, but RDA has it in Expression. Someone may want to add an attribute that RDA does not include. In terms of systems, this is not terribly difficult using registered elements and application profiles. Essentially, as long as the data elements are clearly defined they can be used in different relationships without losing their meaning. In the past, data was defined by the record; today we can define data that can be used in any number of different situations and different records. This gives us a freedom we didn't have before.
Sorry, I'm preaching again. I probably should get some fresh air. kc -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
