Re: Wrong model--entity relationship?
Karen Coyle said:
Could you explain how authority work records would take care of the FRBR
Group 1 entities? That might be a nifty solution if it could be made to
work. (There's nothing that says that the FRBR entities must be
expressed in the bibliographic record, at least not yet.)
Attempting to express them in the bibliographic record is exactly what
I wish to avoid. For a library which has one edition of a particular
work, all that relationship stuff is totally irrelevent. The major
reason multivers were impractical is that holdings differ from library
to library. There is no point in a library's bibliographic record
referring to editions it does not have.
Should some other version (translation or edition) of that work be
acquired, or a criticism of that work added to the collection, an
authority record composed of the 100/245 of the first edition would
allow it to be cited as either 6XX or 7XX. That's all our customers
want, although a monograph equivalent of 780/785, particularly for
legal and medial works, would be valued.
A majority of authors write only one work. A majority of works appear
in but one edition. KISS.
__ __ J. McRee (Mac) Elrod ([EMAIL PROTECTED])
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: Wrong model--entity relationship?
Martha Yee wrote: We need a model that recognizes that many works important to our users are identified by BOTH their authors and their titles. We need a model that recognizes that the author is more important as an attribute of a work than as an entity in its own right. Catalogs are bibliographical tools, not biographical tools. I'm trying to understand this concern, so let me give an explanation that makes sense to me, and you can tell me if I'm off the mark. The entities in a model like FRBR are just the things you are going to work with. For example, in AACR and MARC we have names; in the former they are headings (authors, added authors), in the latter the headings are coded into fields. What FRBR does is, in my reading, is that it extracts those things from the text of AACR and the MARC documentation, and calls them entities. FRBR is a nice schematic of what we already do. At least in terms of the Group 2 and Group 3 entities. (Group 1 is more problematic.) After you have defined your things then you create applications that use them. The applications support the nature of what you are trying to do. If you want to use the person thing only as an author related to a book, then your application should do that. Things should be able to be used in a variety of ways, depending on your need. Look at what OCLC is doing with WorldCat Identities. (http://orlabs.oclc.org/Identities/) This is a biographical view derived from bibliographic information. The things are the same, but the application is different. Entities should be defined at a very basic level; this is what makes it possible to use them in a variety of applications. We are still having a lot of trouble with FRBR Group 1 entities. This is a good example of what doesn't work when a standard is defined on paper rather than in a rigorous, testable way. Until we actually start trying to use FRBR in practice we have no way of testing it to see if the idea really works. FRBR is now almost ten years old and still hasn't really been tested. It is possible that some parts of it don't actually work. There are folks trying to express FRBR in RDF, and others working to express it as an object-oriented structure. Both seem to be running into problems (that I cannot claim to understand). I am uneasy about adopting FRBR as the basis for our metadata until it has been proven. I don't see an obvious mechanism of feedback that would result in adjustments to FRBR if it does turn out to need to be changed. Should we be treating it as gospel? No, at the moment it's a theory, but still just a theory. Think of what we risk if that theory is wrong. kc Martha M. Yee [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Sara Shatford Layne [EMAIL PROTECTED] -- --- Karen Coyle / Digital Library Consultant [EMAIL PROTECTED] http://www.kcoyle.net ph.: 510-540-7596 skype: kcoylenet fx.: 510-848-3913 mo.: 510-435-8234
Re: Wrong model--entity relationship?
Karen Coyle said:
The entities in a model like FRBR are just the things you are going
to work with. For example, in AACR and MARC we have names; in the
former they are headings (authors, added authors) ...
Such over simplification worries me, perhaps because models we have
seen of possible schema over simplify, e.g., calling Autobiography
the subject of an autobiography, when it is the genre; the name is
the subject, and was not given.
Personal Names do not just represent authors. They also represent
editors, translators, composers, artists, directors, actors, criminal
defendants, subjects, etc., etc., etc. And that's just personal
names. There are also corporate, government, ship, building, park,
and geographical names, to just begin an even longer list.
The makers of new wheels seem to assume a simplicity in the
bibliographical universe which does not in fact exist. I would like
to see a few etc.'s or e.g.'s scattered about in such statements
as the above.
On the larger question, it seems to a a few good work authority
records would take care of most of the needs expressed by FRBR. Let
multiver record concept rest in peace with a stake through its heart.
__ __ J. McRee (Mac) Elrod ([EMAIL PROTECTED])
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: Wrong model--entity relationship?
-Original Message- From: Resource Description and Access / Resource Description and Access [mailto:[EMAIL PROTECTED] On Behalf Of Karen Coyle Sent: July 3, 2007 11:11 AM To: RDA-L@INFOSERV.NLC-BNC.CA Subject: Re: [RDA-L] Wrong model--entity relationship? Martha Yee wrote: We need a model that recognizes that many works important to our users are identified by BOTH their authors and their titles. We need a model that recognizes that the author is more important as an attribute of a work than as an entity in its own right. Catalogs are bibliographical tools, not biographical tools. I'm trying to understand this concern, so let me give an explanation that makes sense to me, and you can tell me if I'm off the mark. The entities in a model like FRBR are just the things you are going to work with. For example, in AACR and MARC we have names; in the former they are headings (authors, added authors), in the latter the headings are coded into fields. What FRBR does is, in my reading, is that it extracts those things from the text of AACR and the MARC documentation, and calls them entities. FRBR is a nice schematic of what we already do. At least in terms of the Group 2 and Group 3 entities. (Group 1 is more problematic.) Just to add some thoughts about attributes and entities ... At first glance we can take the statements this work is by this author X and this box had this color brown as saying each object has some specific attribute that describes it. If there were many works and many boxes, we could have a spreadsheet of those objects, with attributes like color and author listed to the right. However, if the color brown was repeated many times and applied to more objects other than boxes in our database, then we have a many-to-many relationship. A more efficient database design would be to have a table of colors that include brown and a table of objects that include boxes and a third table that would combine them. In that case, brown is an entity with a relationship to another entity, not an attribute of that other entity. A table of just authors means that authors are entities that can have their own attributes (last name, first name, birth year, etc.). Authors then could be recycled for other types of relationships in the database-- the subject of a work for example, or the translator of an expression. The issues of linking, sorting, and display come out of that third table combining entities-- I think these are issues that are separate from the underlying database model. Brown or author X could be entered repeatedly and separately as an attribute, and the resulting displays and lists could look the same, but the underlying design would not be efficient. Quite frankly, most of the display problems I hear about have to do with AACR and MARC being written with catalog card output in mind. The multi-purpose fields like 245$a and 440$a are the worst culprits since their reasonable utility in sorting headings in a card catalog doesn't translate well to other environments. For example, in setting up our web-based OPAC, I was intrigued by using the authority controlled name-title headings as hyperlinks, but the 100+245 fields don't combine at all. That means I have a hyperlink to a work heading that brings together all related works across different indexes (subject, series, main/added uniform title entry) except for the work itself when there is only a 100+245 as the heading!!! I feel like paraphrasing Gertrude Stein here: in RDA or whatever comes out of this exercise, we need to say a work is a work is a work is a work, and have the headings and data align correctly to that simple declaration, and not have the current situation where a title might be the title of the work, except maybe on Tuesdays or in a different library. The issues of final display or final sort seem to be quite secondary to the issue of deciding on the tables or containers or correct boundaries for our defined entities. As a side note, I'm pleased with 7.6 in RDA which covers described entities. The means a subject relationship-- a 6XX MARC field, which is I think the first time an explicit rule covering subject relationships has appeared in the AACR-based cataloging rules. I think that captures the right way to think about entities, their attributes, and their relationships to each other. Thomas Brenndorfer, B.A, M.L.I.S. Guelph Public Library 100 Norfolk St. Guelph, ON N1H 4J6 (519) 824-6220 ext. 276 [EMAIL PROTECTED]
Re: Wrong model--entity relationship?
From an optimistic and possibly naive perspective, here's how I see our terms sorting out. Entities are conceptual things whose primary characteristic is their uniqueness within a given ontological domain. You can have multiple names for an entity, but not two entities which are truly the same thing within the same domain. Records are used to represent entities. They contain multiple attributes which collectively enable us to search for and identify the resources we're after. Attributes are expressions can be ascribed to entities. These attributes can be fairly simple, but they can also be complex expressions. Multiple attributes can be assigned to a single entity. For example, one could say, e.g., Work1 has title Title1 Work1 has variant title Title2 Work1 has RDA-controlled author/title uniform title access point Author1.Title1 Work1 has RDA-controlled author/title variant title access point Author1.Title2 (I think reassurance on this point is one of the things Martha and Sara are looking for.) Encoding can be used to identify attribute values by type and in other ways to assist indexing and data manipulation. Like entities, uniqueness counts--a good encoding system will not permit the truly same attribute value (same form, same source, same purpose, same rule base, etc.) to be encoded in different ways. Conversely, it's a bad idea to use a single encoding for data strings which appear identical but are NOT really the same--i.e., are used for different purposes, are to be manipulated in different ways, follow different rules or authorities. Therefore, I'd rather see two data separate data elements for title transcription and title indexing than clever encoding that tries to make one data string do both jobs. Display labels can be used to express the categories represented by encoding. In some cases, values from several distinct encoded elements may be combined under a single display label, for which the encoding system may or may not have a name. Many display labels can be used to express the same encoding. MARC21 6XXs can be labeled Subject, Subject/Genre, MARC 6XXs, etc. Labels are often selected at the local level, since choices about what to index and how to display MARC data can vary. They tend not to be standardized, and because they must be brief, they are rarely precise (pace Mac). Stephen At 10:11 AM 7/3/2007, you wrote: Martha Yee wrote: We need a model that recognizes that many works important to our users are identified by BOTH their authors and their titles. We need a model that recognizes that the author is more important as an attribute of a work than as an entity in its own right. Catalogs are bibliographical tools, not biographical tools. I'm trying to understand this concern, so let me give an explanation that makes sense to me, and you can tell me if I'm off the mark. The entities in a model like FRBR are just the things you are going to work with. For example, in AACR and MARC we have names; in the former they are headings (authors, added authors), in the latter the headings are coded into fields. What FRBR does is, in my reading, is that it extracts those things from the text of AACR and the MARC documentation, and calls them entities. FRBR is a nice schematic of what we already do. At least in terms of the Group 2 and Group 3 entities. (Group 1 is more problematic.) After you have defined your things then you create applications that use them. The applications support the nature of what you are trying to do. If you want to use the person thing only as an author related to a book, then your application should do that. Things should be able to be used in a variety of ways, depending on your need. Look at what OCLC is doing with WorldCat Identities. (http://orlabs.oclc.org/Identities/) This is a biographical view derived from bibliographic information. The things are the same, but the application is different. Entities should be defined at a very basic level; this is what makes it possible to use them in a variety of applications. We are still having a lot of trouble with FRBR Group 1 entities. This is a good example of what doesn't work when a standard is defined on paper rather than in a rigorous, testable way. Until we actually start trying to use FRBR in practice we have no way of testing it to see if the idea really works. FRBR is now almost ten years old and still hasn't really been tested. It is possible that some parts of it don't actually work. There are folks trying to express FRBR in RDF, and others working to express it as an object-oriented structure. Both seem to be running into problems (that I cannot claim to understand). I am uneasy about adopting FRBR as the basis for our metadata until it has been proven. I don't see an obvious mechanism of feedback that would result in adjustments to FRBR if it does turn out to need to be changed. Should we be treating it as gospel? No, at the moment it's a theory, but still
Wrong model--entity relationship?
When FRBR first came out, we approved, because it was the first time there had been an attempt to standardize the definitions of work and edition that we had been using for hundreds of years, and we thought these definitions would help us communicate more effectively with system design people. Martha has discussed elsewhere her concern about the fact that the FRBR model, as expressed in the tables at the back of FRBR, does not correspond to the definitions. All of the data elements that traditionally have been used to identify and describe an expression are mapped to manifestation. Thus, there is already some concern about whether the FRBR model really corresponds to the nature of our bibliographic data. Since this has been discussed elsewhere, it won't be discussed further in this posting, however. Now we are beginning to worry, however, that the use of the entity-relationship model in FRBR and FRAD, according to which both author and work are entities, precludes clearly modelling the fact that the main reason we are interested in authors in libraries is that they are a pathway to the discovery of works and a powerful tool for identifying and naming works and placing them into alphabetical arrays among many other works such that they can be recognized by users. We are beginning to fear that the FRBR model is carving into stone the model that underlies current ILS systems which are incapable of effectively identifying and collocating works using both author and title (formerly known as main entry). We are beginning to fear, in other words, that the entity-relationship model is the wrong model for our data. Can anyone on this list point us to working entity-relationship model applications accessible over the web in which we can see one entity being used in the user-readable string that identifies another entity in all displays (both lists and single record displays)? Can one entity (e.g., work) be searched using variant names of two entities (e.g., work and author)? We need a model that recognizes that many works important to our users are identified by BOTH their authors and their titles. We need a model that recognizes that the author is more important as an attribute of a work than as an entity in its own right. Catalogs are bibliographical tools, not biographical tools. Martha M. Yee [EMAIL PROTECTED] Sara Shatford Layne [EMAIL PROTECTED]
Re: Wrong model--entity relationship?
On Jul 2, 2007, at 4:37 PM, Martha Yee wrote: Can anyone on this list point us to working entity-relationship model applications accessible over the web in which we can see one entity being used in the user-readable string that identifies another entity in all displays (both lists and single record displays)? Can one entity (e.g., work) be searched using variant names of two entities (e.g., work and author)? As a software engineer with a computer science degree, I would stake anything I have to stake on the assurance that one entity being used in the user-readable string that identifies another entity is _quite_ an ordinary thing to do. But I'm having trouble coming up with good real-world examples. Perhaps partially because in real world examples we don't always know exactly what the underlying data model is, neccesarily. Perhaps because it's in fact such a common situation. I will look for a good example. But the (literally) textbook basic hypothetical example for teaching Entity-Relationship Modelling is Employees and Departments. Both are entities, each employee has one department, each department has many employees. (As a textbook starting example; of course it would also be possible to model a situation where each Employee can have 1 to N Departments). When developing such a 'hypothetical' example application for classes, I and many other students have made applications where listings of Employees show their Departments right next to the Employee name (in whatever screen formatting or composition the designer might want), and an Employee record detail page shows you the Department that Employee belongs to, and likewise a Department record detail page shows you all of it's Employees. This is quite a common situation. Works and Authors are no different, in regard to an Entity-Relational model being _quite_ capable of modelling this, and certainly allowing one entity to be used in the user-readable string that identifies another entity, for any related entities (so long as this relationship is modelled), on any screen at all. I personally indeed like very much the set-theoretical approach to the bibliographic entities that Martha Yee has promulgated. I do not think it is _one bit_ incompatible with the Entity-Relational model of FRBR. I do think the narrative of FRBR would benefit by explaining the set theoretical nature of the relationships, it would make it much easier to understand what they are for the new reader. But these set-theoretical relationships can still be modelled by an entity-relational model--in fact, in my opinion, that's exactly what the FRBR entity-relational model is modelling. Jonathan We need a model that recognizes that many works important to our users are identified by BOTH their authors and their titles. We need a model that recognizes that the author is more important as an attribute of a work than as an entity in its own right. Catalogs are bibliographical tools, not biographical tools. Martha M. Yee [EMAIL PROTECTED] Sara Shatford Layne [EMAIL PROTECTED]
