An informal group of interested library professionals opened a discussion in blog format to encourage comments and public discussion of the FRBR-LRM. Attached is a lightly edited transcript of that discussion.
Some of the comments here echo others that have been discussed on email lists or made public in other ways. This group, however, also provides some discussion of technical issues that we have not seen elsewhere.
Similar to other comments that we have seen there are criticisms of the choice to limit person to human beings. There are also discussions of the modeling of aggregates. Some of these will have also been included in the German Community Comments that you have received from the DNB.
The discussants were generally in support of eliminating the FRBR “group 3” entities and making subject a relationship rather than a thing. There was praise for increased openness and the encouragement of extension of the model. The concept of representative expressions got a positive comment, although there remains some concern about how this will be implemented.
Key discussions in this document address the following major points:
There appear to be many assumptions behind this document that are not shared with its audience, including the overall context of the model. For example, it isn’t possible to understand what “mandatory” means in a conceptual model; is this intended as a model for actual library systems?
As with FRBR, the user tasks are considered inadequate to express the complexity of user needs that a library catalog must attempt to satisfy. In addition, the term “tasks” has unfortunately implications in this context.
The document uses terminology that is not defined (such as “entity” “domain” “range” and “disjoint”, although there are many others), and that imply particular technologies that are not themselves addressed.
As defined, relationships seem to be an unexplained mixture of general relationships and specific ones.
The model fails to clarify the position of aggregate works, expressions, and manifestations
The document shows some misunderstanding the of entity-relation model and the purpose of a conceptual model within that context.
The document conflates conceptual modeling with physical modeling; these must be clearly separated for either to be coherent.
The document conflates bibliographic data and administrative data about the metadata.
Declaring entities as “disjoint” (or not) does not belong at the conceptual level but should be defined within applications if needed.
There was discussion of the relationship of nomen to the information technology concept of identifiers. No strong conclusion was reached except that the model must make clear the roles of “naming” and “identifying for machine actionab i lity”.
There are technical aspects of the relationships and the relationship diagrams that must be addressed, in particular relating to cardinality.
The treatment of relationships and their inverses is dependent on the technology employed and does not need definition in the conceptual model.
In an E-R model, sub-/super-class are special relationships because they imply inheritance. They should not be mixed with the entity-entity relationships.
Attributes should be assigned after the conceptual model is completed. This model should be more clear on the definitions of the entities and should allow “next step” models define the attributes based on those definitions.
In addition, questions are posed which community members would like to see addressed before a model is finalized:
What is the envisioned relationship with BIBFRAME and other bibliographic models being developed, both in the library community and in other communities with bibliographic data?
Is the FRBR-LRM intended to be descriptive of the bibliographic universe, or is it intended to be prescriptive of library data that describes library resources?
What is the motivation for the particular assignment of the attributes here? For example, work has one very general attribute, while expression has some format-specific attributes. It isn’t possible to understand this without knowing the thinking of the model designers.
-- Karen Coyle [log in to unmask] http://kcoyle.net m: +1-510-435-8234 skype: kcoylenet/+1-510-984-3600