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.
1 Like
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.
3 Likes
@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)