“In the FRBR-LRM model, the relationships are declared in a general, abstract way and thus enable implementers to include additional details in a consistent and coherent way by introducing additional types….” “The relationships between works, expressions, manifestations, items are the core of the model and can be considered mandatory. Other relationships are encouraged, since they enable exploration and discovery and are very important for users.” p. 43
- Comment
- Reblog
-
Subscribe
Subscribed
Already have a WordPress.com account? Log in now.
FRBR Open Comments 
Pingback: World-wide review of the FRBR-Library Reference Model, a consolidation of the FRBR, FRAD and FRSAD conceptual models | FRBR Open Comments
The relationships section includes information about cardinality: one-to-many, and many-to-many. There is, however, another aspect of cardinality that is not included here and that is whether the relationships are mandatory or optional.
Page 43 says: “The relationships between works, expressions, manifestations, items are the core of the model and can be considered mandatory.” However, I’m not sure what this means. Does it mean that every work must have an expression? That every expression must have a work?
I had understood that part of the motivation for FRBR was an efficiency that would arise from being able to share, for example, work information for those cataloging a new expression. That would mean that it must be possible to have information for a work that is not at that moment associated with an expression. And in terms of copy cataloging, it would seem to be quite logical that one would share a work-expression-manifestation unit to which a library then attaches item information.
At the same time, I cannot imagine the utility of having an expression with no relationship to a work – it simply would not be meaningful. Therefore, it seems to me that the cardinality of mandatory/optional between work->expression is different from the cardinality of mandatory/optional from expression->work.
That said, I think you could question whether cardinality needs to be specified at all in the LRM model. Since entities like work and expression are defined only in vague terms, to be implemented based on the specific needs and collections, it doesn’t seem to me to be wise to define cardinality relationships between the entities before they are defined in future applications. Depending on how a community defines work there might be a case where one expression has a relationship with more than one work, etc.
LikeLike
About the optionality (is that a word?) of ERM relationships: this does not apply to the whole relationship, but to individual relationship ends. So one relationship can have an optional and a mandatory end, or both optional or both mandatory. Example: a Work may have one or more expressions (0,1, n); an Expression must have one Work (1) (not saying that this is the case, just an example). There are various notations for this, none of which I see in this model.
Approximately: Work (1) ——- (0..n) Expression
LikeLike
There are 34 relationships defined in LRM. This is not a closed list: “Any additional relationships needed by a particular implementation can be defined as sub-types of the additional relationships defined in the model, or of the top relationship.” (p. 45)
However, I am bewildered by what seems to me a discrepancy between very general and very specific relationships in the list. The selection of relationships defined seems to me somewhat arbitrary and not really well balanced. I would prefer to have more relationships on a middle level of the hierarchy.
For example, sometimes we find very detailed relationships. Look at LRM-R26 (Manifestation – has reproduction/is reproduction of – Manifestation) and LRM-R27 (Manifestation – has alternate/has alternate – Manifestation). If we compare this to RDA, we find the element “Related Manifestation” (RDA 27.1) on the highest level. Then there is, in appendix J.4.2, “equivalent (manifestation)” with several sub-terms, among them “reproduced as (manifestation)/reproduction of (manifestation)” and “also issued as”. So, the RDA equivalents of LRM-R26 and R27 are on the third (!) hierarchical level. However, there is no general relationship defined between two manifestations in LRM (something like: Manifestation – is associated with/is associated with – Manifestation”. I think this is rather amazing for a model which claims: “In the FRBR-LRM model, the relationships are declared in a general, abstract way and thus enable implementers to include additional details in a consistent and coherent way by introducing additional types.” (p. 43).
Another example are the relationships between two agents. Again we find some rather specific relationships (e.g. Agent – is member of/has member – Collective Agent), but no general relationship between two agents. Therefore, if we want to express that person A is married to person B by using the relationships defined in LRM, we need to fall back on the most general relationship, FRBR-LRM1 (Res – is associated with/is associated with – Res), as there is no specific relationship which could be used. I would much prefer LRM to have, for every entity, a general relationship between two entities of the same kind, e.g. “Work to Work”, “Expression to Expression”, “Agent to Agent” a.s.o.
LikeLiked by 1 person
A second point which struck me when looking through the list of relationships: Why is there no whole/part relationship for Item? Whole/part relationships are defined for 7 out of 11 entities. I do understand that a whole/part relationship doesn’t make much sense for Person, which in turn means that it cannot be defined for the hiearchically superior entities Agent and Res. But I am at a loss why it wasn’t defined for Item.
LikeLike
Hi Heidrun,
I can imagine that some items might have parts not common for all items exemplifying a manifestation. For example, a library may decide to keep separately a set of maps included in a book and they need to indicate that this set is a part of that book, or an archive decided to divide an old and rare book in several parts to ensure its better preservation. However, I don’t think it’s a common practice. Did you mean something else by the whole/part relationship for Item?
LikeLike
I agree it may not be used very often in library practice. But RDA has whole/part relationships for “item”:
RDA J.5.4:
“contained in (item) A larger item of which the item is a discrete component. Reciprocal relationship: container of (item)
container of (item) An item that is a discrete component of a larger item. Reciprocal relationship: contained in (item)”
So I found it odd that they shouldn’t be there in LRM.
LikeLike
Only a small detail:
This example on p. 45 is rather odd:
“Person to time-span, e.g.: Emily Dickinson is associated with the time-span from 1830 (the year she was born) to 1886 (the year she died)”
Why should we use LRM-R1 “Res – is associated with/is associated with – Res” to express this? I would use LRM-R15 “Res – has has association with/is associated with – Time-span”.
LikeLiked by 1 person
Each relationship has a “forward” relationship and an inverse relationship (“has part” “is part of”). Creating two relationships for each concept is considered by some to create additional work for the implementer, even though some find stating the inverse relationships separately to be clearer. In reality how the inverse is implemented may vary for different technologies, some of which have a way to state that a relationship can be reversed without having to define a separate relationship. It seems that the LRM could define relationships and simply say that relationships are symmetrical unless stated otherwise. That allows implementations to handle the inverse in the best way for that particular technology. Those who wish to can add the “reverse name” to their implementation. (This comment assumes that relationship “names” are intended to be implemented as properties in a vocabulary. I don’t find this stated as such in the document; may have missed something.)
LikeLike
P. 43: “The relationships are declared on the class level. It is important to note that while relationships are
declared between entity types, in reality they are established and exist between instances.” In ERD modeling tehre are no entity types, only entities. Relationships are declared between Entities (hence the name Entity Relationship model). “Entity” in ERM/ERD means “class’, “type”‘. Also: relationships are declared between entities on a conceptual level, they can be instantiated as relationships between actual “things”or “objects”. It’s a matter of maintaining the correct terminology. In this case it is only confusing.
LikeLike
P. 43: “The relationships between works, expressions, manifestations, items are the core of the model and can be considered mandatory.”
What does this mean? “can be considered mandatory”: either they are or they are not mandatory. Then say so and avoid confusion: “..and are mandatory”. This comment of course does not say anything about the correctness of the mandatoryness of these relationships.
“Other relationships are encouraged, since they enable exploration and
discovery and are very important for users.”. Again: “encouraged”? What does this mean? Here we see a clear example of the mixup between conceptual level and logical/physical level. On the conceptual level relationships are possible or not, so they should be modeled explicitly. It does not mean that they will be there in reality or in a system.
What does “encourage” even mean? “Please implement these in your system/database”?
LikeLike
P. 44: “Relationships are declared in both directions, first from left to right (“forwards”), then right to left
(“backwards”).”
Left and right should be avoided, because it is not true. There is no left and right, and there is no consecutiveness either (“first – then”). It gives a false idea of priorities etc.
LikeLike
P. 60: “The final overview diagram, figure 5.6, shows all the relationships depicted in figures 5.1 through 5.5 along with all other relationships defined in the model.”
Just one or two minor comments: the Subject Relationship of Fig. 5.3 is absent in Overview Diagram.
The Overview Diagram does not show cardinality correctly. If the arrows are meant to identify multiplicity (1:n), then there are no n:n relationships at all.
Also the RES to Work relationship is not named (it should be a super/subclass one I guess, also “IsA”). And where are all the other {Entity} “IsA” RES relationships?
Actually this is a very incomplete ERD.
LikeLike
After closer reading I see that in the text on page 60 the incompleteness of the diagram is confirmed: not all relationships are depicted, cardinality is omitted, etc.
LikeLike
P. 43:
“The entity subclass/superclass relationship (IsA) can also be used in a path to restrict the domain or range entities in a relationship. The pair of relationships:
PERSON IsA AGENT +
AGENT ‘created’ WORK
imply the shortcut relationship:
PERSON ‘created’ WORK
This latter specific relationship can be implemented directly if it is considered desirable.”
In ERM the superclass-subclass link is not actually referred to as a relationship but as “inheritance”. Every relationship (and attribute) of the supertype implicitly also applies to the subtype. A subtype entity can also have relationships (and attributes) of its own, but only if they do not apply to the supertype entity. So on the conceptual level there is no such thing as a “shortcut relationship” that can be implemented if desirable.
In the physical model level it really depends on how the actual databases is implemented. Options can be separate database tables for each subtype, or one supertype table with a “category” (or “type”) field with values indicating the subtypes.
LikeLike
This example is backward. First, every Person is an Agent, but not every Agent is a Person. You can deduce from Person that the entity is an agent, but not from Agent that the entity is a Person. This should read:
PERSON is a AGENT
PERSON created WORK
= AGENT created WORK
LikeLike
This is part 5 of my personal response to the FRBR Review Group.
5. Attributes of Relationships
In the ER model used by the database world not only entities have attributes, but relationships may also have attributes. For example, when or where did a relationship take place is an attribute of the relationship, not the entities involved. I realize in the LRM time and place are entities, but I’m not sure that an entity can be used as an attribute of a relationship. But even if there is some way of doing that, there are other attributes of relationships: what kind of relationship is it? We’re currently using relationship designators to describe this: this is a “creator” relationship; this is a “derivative” relationship, this is a “sequential” relationship. I realize the original FRBR model also omitted attributes for relationships, but I believe their incorporation would make the model better and more flexible (and better explain how and why we’re using the relationship designators).
LikeLike