Generally no. But this isn’t one-to-one relationship. A work may appear in some editions of an ed. group and some of another (e.g. a short story in short story anthologies that wasn’t picked up in all editions). Editions may contain different prefaces which may be translated from different languages, or not be translated. These are just examples, but ed. groups and works are at different levels, it’s not possible to extrapolate the relationship like this. — Isn’t this overcomplicating? Or am I oversimplifying in thinking there would be an unintended consequence of adding this relationship?
To summarize:
- Work-level translation relationships are quite specific and mention the language and the translator.
- EdG-level translation relationships are general and mention only the language. Or do they? Maybe some EdG mix translated and non-translated parts?
OK, this makes sense. But do we need the EdG-level translation relationship? Couldn’t it be just calculated from the works which the EdG contains?
1 Like
The only language field stored in the edition group is the language of the name. I don’t think it’s important to note who may have translated that name. Translation of the content is already captured in the work entities.
Sorry for this entirely drive-by comment, but have we looked at the FRBR model?
FRBR descripton
FRBR (Functional Requirements for Bibliographic Records) is a conceptual model for organizing bibliographic information. According to FRBR, a book is represented in four layers, known as entities:
Work: The intellectual or artistic creation that is the product of an author's imagination or research. A work is a distinct intellectual or artistic creation, such as a novel, a play, or a musical composition. A work is identified by its title, author, and other attributes that distinguish it from other works.
Expression: The specific intellectual or artistic form that a work takes on. An expression is a particular realization or manifestation of a work, such as a translation, an edition, or a recording. An expression is identified by its language, format, and other attributes that distinguish it from other expressions of the same work.
Manifestation: The physical embodiment of an expression of a work. A manifestation is the actual item that a user can see or touch, such as a printed book, an audiobook, or an e-book. A manifestation is identified by its publisher, date of publication, and other physical attributes.
Item: The individual copy or instance of a manifestation. An item is a specific physical object, such as a specific copy of a book, that can be lent or borrowed. An item is identified by its barcode, call number, and other attributes that distinguish it from other copies of the same manifestation.
By distinguishing between these layers, FRBR allows for more accurate and precise cataloging and organization of bibliographic information, and enables users to easily locate the specific item or version of a work that they are interested in.
Is this Edition Group proposal at the Expression level? I’ve always thought FRBR looks interesting, but nobody seems to dare to really tackle it (LibraryThing, OpenLibrary, Wikidata, Inventaire, …). I’d love a database that is equipped to handle all those crazy Russian nesting-doll-type situations one encounters in the book world…
1 Like
I already agreed that my suggestion about the translator was wrong. OK, so no language either. This makes my question even more relevant. Do we really need such an EdG-to-EdG relationship? After all, the system could find out that this EdG contains works which are translations and display this information. What more would an EdG-to-EdG relationship say? Or would it only mean that the EdG’s name is a translation of another EdG’s name?
Each new relationship type allows saying something, but also makes the user experience more complex. We should avoid creating relationships which are already implied by higher-level relationships.
I don’t think so. Edition groups are not translations of other edition groups, they’re collections of editions, which may or may not contain translations of works grouped somewhere else.
The current proposal is to group like editions in the same language. The disambiguation guideline already states that the disambiguation field should indicate the language of the edition group if it has the same name of another edition group by the same author.
2 Likes
I too always thought it was interesting, and I took a crack at using it in an early iteration of my personal library management tool, like 15 years ago. It’s quite well thought-out, and logical, especially to an archivist, amateur or professional. That said, it is complex and if we were to consider it, probably not for this particular guideline. 
1 Like
@davitof, I wasn’t even suggesting it should include the language, my only point is to have a relationship to mark which ed. group is a translation and which is the original language, so these ed. groups could be grouped.
The ed. group doesn’t contain works, it contains editions. What you are suggesting would require an algorithm reading editions and works recursively, decide which are the main works to decide which editions are translations and to extrapolate that result to the ed. group level, which could then be used to group the ed. groups. This is far more complex, and given the load on the developers, will never happen. Nor would I suggest that solution, it’s just not worth it.
What @pbryan is saying is something different, that what I am suggesting is unnecessary, so no extrapolation or relationship is necessary.
Frankly, I feel like I’m defending a position that isn’t mine. I still think that, logically, different languages should be in the same ed. group. The relationship idea was to avoid the mess resulting from splitting one ed. group into possibly dozens of languages — which would make an author with a dozen novels (not rare) have hundreds of ed. groups for this dozen novels.
But there is no point extending this conversation into eternity. I don’t see anyone else sharing my worries, and I wouldn’t want the guideline progress being stuck on this point because of me.
What you are suggesting would require an algorithm reading editions and works recursively, decide which are the main works to decide which editions are translations and to extrapolate that result to the ed. group level, which could then be used to group the ed. groups. This is far more complex, and given the load on the developers, will never happen.
I am a database software developer, what you are describing is what I do for a living and this does not seem so complex to me, apart from “decide which are the main works” which could prove tricky. I agree it could take some time before it is implemented, so that in the meanwhile the EdGroup translation relationship would be useful. But there is a price to pay: this is data redundancy and it means that it will lead to data inconsistency.
avoid the mess resulting from splitting one ed. group into possibly dozens of languages — which would make an author with a dozen novels (not rare) have hundreds of ed. groups for this dozen novels.
This does not have to happen. One could imagine displaying only the EdGroups which aren’t flagged as translations; this would rely on your suggested translation relationship or on an automatically calculated value. Users could also choose to see only the EdGroups of their own language, which would make sense most of the time. Or even mix both, for example I read English and French, so I’d choose to see English EdGroups for English authors and the French EdGroups for all others. Now that I think of it, I’d even like to see the English Ed Group if no French Ed Group exists.
The question for me isn’t whether it can hypothetically be done. Given the number of developers working on BB and the speed at which it progresses, this just isn’t reasonable. There are a lot more simple and more important improvements to do that are taking very long. But if it misunderstood you, and you are actually offering your services as an experienced database software developer to implement and maintain this feature, I do support it.
In any case, this implementation would be something to discuss with the developers. It seems we have strayed from the purpose of this topic: style guidelines.
Maybe it’s time to wrap this up, @pbryan?
1 Like
I still have a bit of work to fill-in examples, which I’ll try to finish tonight. It sounds like the guideline, where it stands, has consensus. If I’ve missed something and anyone disagrees, please chime in.
2 Likes
Absolutely, @pbryan, I didn’t mean to rush you. I just realized the last few replies were going on tangent. You’re doing great work, please take all the time you need.
1 Like