Wikidata:Property proposal/Book format

Book format

Originally proposed at Wikidata:Property proposal/Creative work

   Withdrawn

Description	Page size of a historical book, manuscript, or artwork on paper, based on folding sheets into leaves
Represents	book format (Q18602566)
Data type	Item
Domain	manuscript (Q87167), version, edition or translation (Q3331189) (includes prints & engravings), individual copy of a book (Q53731850), incunable (Q216665) possibly others
Allowed values	instance of (P31) book format (Q18602566)
Example 1	AM 738 4to (Q2061177)book formatquarto (Q2122442)
Example 2	First Folio (Q833645)book formatfolio (Q772267)
Example 3	Vide Howard on Prisons, page 82, Octavo edition (Q110075098)book formatoctavo (Q1307353)
Example 4	Nouvelles Histoires extraordinaires (Q27652233)book formatoctavo (Q1307353)
Planned use	required property for WikiProject Manuscripts (Q123078816)
See also	distribution format (P437)
Single-value constraint	no
Distinct-values constraint	no
Wikidata project	WikiProject Books (Q8487081), WikiProject Manuscripts (Q123078816)

Motivation

Required to properly document manuscripts and historical editions of books. This property is identified as a missing necessary property at Wikidata:WikiProject_Manuscripts.

Aliases should include "paper size", "page size","book size".

Note that some manuscript codexes contain multiple page sizes, so a single value constraint is not appropriate for those items.

If the name "Book Format" is too confusing, we could use "Bibliographic Format".

Equivalent properties:

• LoC vocabulary
• RDA termlist "bookFormat"

Different from: Schema.org bookFormat

 – The preceding unsigned comment was added by PKM (talk • contribs) at 23:34, December 13, 2023‎ (UTC).

Discussion

@AdamSeattle:

Angayubagia CRolker Epìdosis HHill Jahl de Vautban Jason Evans Jonathan Groß Lynn Ransom Marsupium MartinPoulter Mel22 Pmt PKM Toby Burrows Maxime

Notified participants of WikiProject Manuscripts

[also posted a note at WikiProject Books, too large to ping]

• On WikiProject:Books, one of the first decisions we made was to avoid using the word "book" because it has too many different and contradictory meanings. "Bibliographic" is also wrong because a bibliography is a list of books or citations, not a general book-describing term. "Format" is also wrong, since that refers specifically to the interior printed layout on the pages, and not to the size of pages. A better choice would be "codex size", if this property is to be used. A "codex" is specifically a bound format. But library databases use dimensions for this, and the Library of Congress has this listed under medium along with number of pages. --EncycloPetey (talk) 03:07, 14 December 2023 (UTC)
  • @EncycloPetey: "Codex size would be an excellent alias, but the property is also intended to apply to printed books and single-sheet prints. Would you be happy with "page size"? - PKM (talk) 22:30, 17 December 2023 (UTC)
    • "Page size" assumes that the object has pages, which will not work for written records on scrolls, tablets, stelae, or walls. As a specific example, Chinese and Japanese calligraphic works are often written on paper scrolls that are meant to be hung on the wall, not on pages. And the Mayan codices used in the Americas prior to the arrival of Europeans are folded, without separate pages. There is no single label that will be universally applicable. --EncycloPetey (talk) 22:38, 17 December 2023 (UTC)

      This property is not intended to aply to the exceptions you identify, as they are nit made of folded sheets of paper or parchment. - PKM (talk) 20:57, 18 December 2023 (UTC)

      • What then is the range of items this property applies to, and why are those items grouped together and not the others? --EncycloPetey (talk) 23:55, 19 December 2023 (UTC)

•  Comment Can you link to the discussion of this at Wikidata:WikiProject_Manuscripts? The only mention I found there seemed to suggest the label "manuscript form" - would that work here? ArthurPSmith (talk) 19:31, 15 December 2023 (UTC) @PKM:

  List of missing properties after “Material properties” at Wikidata:WikiProject Manuscripts/Data Model. It’s not a discussion. - PKM (talk) 09:35, 17 December 2023 (UTC)

• If I understand this proposal correctly, it refers to books in the form of a codex (as per EncycloPetey and PKM above). The term "format", as far as I know, only refers to specific sets of horizontal and vertical dimensions of the book blocks and the respective page size, so it would make sense to apply the property to singe-leaf artifacts as well. But I'm not sure if it should be applied to other book forms such as scrolls from the pre-codex era. Maybe the label book format should be reserved for a property denoting the more general format (like scroll (Q720106) or codex (Q213924)) of a book, and the specific formats like folio, quarto and so on could be stated with a different property labelled codex format. Jonathan Groß (talk) 19:00, 19 December 2023 (UTC)

  @EncycloPetey, ArthurPSmith: would you be happy with codex format for this property? - PKM (talk) 23:52, 19 December 2023 (UTC)

  Perhaps, but PKM has responded above to indicate that the label might not be suitable. I have asked why. --EncycloPetey (talk) 23:56, 19 December 2023 (UTC)

  Sorry, I missed your question. As indicated above, the domain for this property should be instance of one of these (or one of their subclasses): manuscript (Q87167), version, edition or translation (Q3331189) (includes prints & engravings), individual copy of a book (Q53731850), incunable (Q216665). There may be domain items I have not thought of that are described as quarto, octavo, 12mo, etc.

  I don't think anyone is pushing back on having the property; I think it is just a question of what we want to call it. It is most likely to be used for codices, so codex format makes sense, but there are important other items (Shakespeare's First Folio comes to mind). However, as long as we have a good description, good aliases, and usage instructions, any label we can agree on is fine by me, including page size.

I would suggest usage instructions like "use for traditional book and codex formats such as quarto, octavo, 12mo. For sizes as dimensions, use height, width, and thickness." - PKM (talk) 04:49, 21 December 2023 (UTC)

• @PKM: At the moment I think distribution format (P437) has tended to be used for this (and has "book format" as one of its aliases), viz query https://w.wiki/8eDN for counts and examples. Is there a problem with that, or any need for a new property, when what we have seems to work acceptably? Jheald (talk) 19:17, 27 December 2023 (UTC)

  Trust @Jheald to find data to get to the meat of the matter. I can live with this - @Jonathan Groß does this work for you? - PKM (talk) 22:55, 27 December 2023 (UTC)

  I think so, although I cannot claim to understand all the ramifications. I'm a bit removed from this at the moment. Happy holidays! Jonathan Groß (talk) 08:14, 28 December 2023 (UTC)

  @Jonathan Groß Same to you!

  @ArthurPSmith, @EncycloPetey, @Jheald, please note that the 1138 items with distribution format (P437) set to "octavo" (the highest number of uses) all have a constraint violation. If we assume that distribution format (P437) should be used for both "distribution format" and "book format", then we need to make massive constraint changes a constraint change at distribution format (P437). I am happy to withdraw this proposal if we can get consensus from the editors to have been maintaining P437 - I will ask. - PKM (talk) 23:38, 28 December 2023 (UTC)

  We could set values like "octavo" as subclasses of "codex" or "hardcover", of whatever is the base value. If we do that, we won't need a new property, just an extended tree of possible values. --EncycloPetey (talk) 23:42, 28 December 2023 (UTC)

  Posed question at Property_talk:P437#Use_for_"quarto,_octavo,_12mo",_etc.? and on Wikidata Telegram. - PKM (talk) 00:06, 29 December 2023 (UTC)

  I will refrain from voting since I don't do much editing in the book field, but since I was pinged, and generally speaking, I've come to quite like narrower properties that don't try to "be all things to all people". A book format property sounds like a good idea to me, and would probably help with creating better constraints? If the wise crowd in its wisdom swings the other way, I wouldn't object to sensible changes to the status quo of P437 either, I'm good either way :) Moebeus (talk) 00:16, 29 December 2023 (UTC)

  @PKM: I'm not sure why you say we would need to "make massive constraint changes at distribution format (P437)" ?

  We would just need to add book format (Q18602566) to the list of classes allowed under value-type constraint (Q21510865) at distribution format (P437) -- not such a stretch, when it already includes eg the analogous class film format (Q759853), container classes for various different types of digital format (archive file format (Q1351368), audio file format (Q682626), e-book file format (Q81986407) etc), and so on. Do the various different cases of book format (Q18602566) not seem more of the same sort of thing? Jheald (talk) 08:38, 29 December 2023 (UTC)

  I believe you are correct. I thought we would need to add a number of allowed types, but everything seems to rollup to "work" (eventually). My mistake.

  So yes, adding book format (Q18602566) to the list of classes allowed under value-type constraint (Q21510865) would seen to be sufficient.

  We should also add some equivalent property (P1628) to this property, but there aren't any at all now, so that's no big deal. PKM (talk) 22:04, 30 December 2023 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I'll allow a few more days for comments (what with the holiday weekend and all), and if we're in agreement I will withdraw this proposal and update the constraint on distribution format (P437). - PKM (talk) 22:09, 30 December 2023 (UTC)

Withdrawn. Added book format (Q18602566) to the list of classes allowed under value-type constraint (Q21510865) at distribution format (P437). Thanks, everyone, for your comments. - PKM (talk) 00:31, 5 January 2024 (UTC)