This was written 2 years ago about this topic:
This might be a better explanation for what I mean:
A BB edition is NOT the same as a book edition.
Many of the editions I added look like the example in the linked thread.
[first known] release date: 1983
Annotations:
Confirmed editions [editions that are just reprints]:
3. edition: 1983
5. edition 1986
So the publishing date for this BB edition is not just 1983
We can do it this way, but it’s far from perfect I think
Here is another example:
I added the first edition from 1986 a long time ago.
I recently had the ninth edition from 1996 in my hands. The only difference between the two editions was the font on the cover.
That didn’t seem to be enough for a new BB edition.
So this BB edition has a start point 1986 and a preliminary end point 1996.
It seems to me that the description of the release date as a period of time (1986-1996+?) is more correct than a point in time (1986).
But is the 1986 edition discontinued from selling after the 1996 one was released? I don’t think a font change would make the 1986 edition obsolete. I don’t know exactly in this case but I know of examples where there are multiple editions of the same book co-existing in the market.
Also I don’t quite understand the difference between book edition and BB edition. What makes one book qualify as a NEW BB EDITION?
Of course. They printed 20000 Books of the first edition (The 200 in the printer’s key). When they had been sold out they printed the 2. edition and so on (technically these editions are all reprints)
Any change to the content, ids, credits or graphics leads to the creation of a new BB edition (we haven’t defined this exactly yet).
Yes, but the books weren’t destroyed, they still exist. They didn’t become unreleased. Reading your previous posts, I think maybe there’s a bit of confusion. Do you maybe mean we should accept multiple release dates (like in MB)? This makes more sense to me.
I actually think in 99% of cases there should be a single release date, but an exception would be a company publishing the exact same book in different countries at slightly different times (e.g. a German company publishing the same book [from the same printing] in Germany and Austria a couple of days apart).
We don’t currently have a field for reprints, but we should and these should definitely allow for multiple values, as there can be dozens of reprints.
I would say these should definitely be different editions. Any difference in the artwork should a separate edition. This is similar to what has been decided for MB.
Well, yes that’s in fact what I’m trying to do here 
The release date is the date for the first printing, but doesn’t cover the date of the reprints.
I thought we could just do this by setting a start date for the first printing and and an end date for the last reprint.
Of course, we can also solve this with a multi value field for reprints. That would be more precise.
And the fact that we Germans don’t use the term “reprint” in our books but only “edition” is our problem - we have to deal with that on our own
Yes, that is certainly what it will come down to.
Nice to see there isn’t as much disagreement as it seemed.
I understand what you’re trying to do, but this would really work better with multiple dates. Otherwise, all dates but the last would be lost. And, besides, we don’t generally know the date of the last reprint, just the one we currently have (often not even that). Especially with MB’s precedence, I think it just makes more sense to allow multiple dates.
Germans sure are very particular about an awful lot of things, aren’t they? But eventually we should have documentation pages for each language/country. We have that in MB, and with books this kind of thing is probably more common.
I actually misread you as saying “The only difference between the two editions was the font and the cover” — I thought you were saying the artwork was different. I still think it should be a different edition, but it’s not as obvious…
Ok. So I guess we decide on adding start and end dates to editions. What relationship exactly is it in BB can you let me know it’s name?
There is no relationship, at least currently. And I think in the end we agree this would be better defined with multiple dates, not start/end dates. It seems we got a bit off the track.
No, we decided against adding two dates to the editions. We will solve the problem with the reprint dates in a different way
Cool for now I have added begin/end date attributes to other relationships and made a PR at Add begin date and end date attribute to relationship by aabbi15 · Pull Request #1073 · metabrainz/bookbrainz-site · GitHub
Kindly check it out and list if you think something is missing or if something that should not be there is. I have listed the names of relationships to help you out as well.
I’m late to the party but I think the discussion was fruitful and most of the points I had in mind were said.
@blackteadarkmatter could you please point me to a good example or two of a release with multiple release dates in MB?
One thing I wonder is if it would be helpful to have the printer’s key for example or other identifiable reprint information attached to a particular release date.
For @aabbi15 on the technical side: I’m not certain yet, but we might need two different attribute types: single date and date range.
That being said you might be able to describe both in the same way with extended ISO 8601 format dates: ISO 8601 - Wikipedia
Something for you to investigate: can we use a single attribute type (“date”) but somehow mark whether it is a punctual date or a range? (we will need to know that for the UI part)
I don’t know if these are good examples, but this, this, or this are examples. I feel this is probably very rare for books, but it’s possible, so it’s a good idea if it is supported. And for reprints there are definitely multiple dates, so it’s a good to model if we want to support this.
Define “other identifiable reprint information”… In most cases the only useful information on the printer’s key the printing number. E.g. if you have a book with the printer’s key “17 16 15 14 13 12”, you know there are at least 12 printings to this edition because that’s the one you have. Sometimes it also has the year of the printing which is useful information. I also feel the printer’s key is mostly used in English books, I couldn’t find it on any non-English book I have at hand, and very recent English books also sometimes don’t have it (maybe due to differences in printing technology?) In any case, it’s not universal.
I guess the info various a lot from country to country and from publisher to publisher.
Sometimes there’s only the example @blackteadarkmatter mentioned: 12 11 10 9
meaning in Germany: This is the 9nth edition (can be the 5th reprint of the 4th edition or the 9th reprint of the 1st edition (that is not recognizable).
Sometimes they are combined with the year: 86 87 88 04 03 02 (means 2. edition from 1986).
But sometimes we also have information about the amount of printed books:
a) the example of my post above (used by only one publisher): 100/85/xy/2 (meaning 10000 printed books for the 2nd edition in 1985.
b) A range like : 7. edition May 1967: 12th - 17th thousand
c) The total amount of printed books so far.
The amount of printed books is interesting data but I’m not really sure how to add this correctly to the BB editions.
Yes, I suppose my main point was that printer’s keys aren’t universal (not used everywhere and don’t follow a fixed format), so I don’t see them as useful to “attach” to an edition the same way you attach a TOC to an MB release.
Of course, once we are able to add images to editions, the whole front matter (including the printer’s key) should be scanned and added to the edition. It can be a useful source of information, but it’s not really an ID.
Ok so instead of adding two different attributes we add an ISO 8601 format named just date?
Just remembered another relationship where this would be useful, “manufactured”. I think this relationship is problematic, it should be split (printed, typeset, bound), because different companies can be responsible for different parts of the process and different countries have different ways of presenting this information. But in any case, it can be dated.
@aabbi15 I thought about the idea of using a single date attribute to represent both single dates and date ranges, but in the end I’m not sure we can.
One way or another, we would need a way to restrict a relationship attribute to a single date for a punctual event, and I can’t think of a good way to do that easily and foolproof other than having two separate attribute types (punctual date // start & end dates).
You’ve looked at the code more recently than I did; do you see a good way to do that?
Now the question remains: for date ranges, is there an advantage to store a single date range string vs. separate start and end dates.
I have never tried storing a date range in Postgres using the native date type, so that would need investigating: if we need to store an ISO8601 string as opposed to the native SQL date type, how does that compare?
I have never tried storing a date range in Postgres using the native date type, so that would need investigating: if we need to store an ISO8601 string as opposed to the native SQL date type, how does that compare?
how about, rather than using a string or a native datatype in sql we use a composite datatype something like
CREATE TYPE DateRange AS (
start_date DATE,
end_date DATE
);
then we dont have to use a string and we store date range like
event_id event_name event_date
1 Concert (2024-04-15, 2024-04-17)
2 Conference (2024-05-20, 2024-05-22)