Wikidata:Property proposal/pdf page

file page

Originally proposed at Wikidata:Property proposal/Generic

   Done: file page (P7668) (Talk and documentation)

Description	property to indicate a page number of a pdf file or similar. The page number is sometimes different from the numbering of the text reproduced in the document. Should allow to link the page when combined with the file URL.
Data type	Quantity
Allowed values	positive integers
Allowed units	none
Example 1	Q75803176#P996 File:Emily Dickinson Poems (1890).djvu → 160
See also	page(s) (P304)

Motivation

It seems we lack this. Probably useful mostly on Commons where such files are stored. Please help complete the proposal/add samples/suggest the perfect property label (Add your motivation for this property here.) --- Jura 08:15, 12 October 2019 (UTC)

Discussion

•  Support Yes. This is something that would be useful. Jheald (talk) 12:15, 12 October 2019 (UTC)
•  Oppose David (talk) 17:14, 13 October 2019 (UTC)
  • @ديفيد عادل وهبة خليل 2: Why? Jheald (talk) 22:32, 13 October 2019 (UTC)
    • @Jheald: I don't see the need for another version of page(s) (P304) David (talk) 06:41, 15 October 2019 (UTC)
•  Comment I don't like that name. We also can use DjVu (Q334677) instead of Portable Document Format (Q42332). What if the support for OpenDocument (Q184473) is added in the future? I will support this property with a name like «page in digital document», or something like that. --Tinker Bell ★ ♥ 19:26, 13 October 2019 (UTC)
  • @Tinker Bell: I wouldn't mind changing the label to something different, but "page in digital document" might have the same problem as just using "page": one wont be sure users don't mean the printed page number. If we add "djvu page" as alias, would that be sufficient? --- Jura 12:05, 20 November 2019 (UTC)
•  Comment What's wrong with page(s) (P304)? Also it is very unclear what the purpose of this is, you haven't given any specific example. ArthurPSmith (talk) 18:17, 14 October 2019 (UTC)
  • @ArthurPSmith, ديفيد عادل وهبة خليل 2: It's very common for a digitised version of a work to have its own sequence numbers for each scan or frame of the digitised work, which is different from the original page number. So for example File:Plan of Dudley Castle (1897).jpg is taken from frame 458 of a particular digital version of The Castles of England (1897). But if we access the source here, we find that the printed page number in the original book was actually page 394. The Internet Archive does its best to identify the original page numbers of book pages it serves; but most other providers do not. Also each digital provider may have a different frame number for the same page, depending on eg how many blank pages at the start of the work they have shot and included in the file. This goes over to modern born-digital documents as well, where the page numbers may only start after the contents and the front matter, but the frames of the pdf are numbered sequentially from 1 for the front cover.

The existing property P304 (https://w.wiki/A8K times out) is typically used either as a reference or a qualifier, so it is not possible to qualify it to indicate whether it refers to a digital frame or a printed page number. So it would be genuinely useful to have this new property. Jheald (talk) 07:49, 15 October 2019 (UTC)

@Jheald: Ok, I see the distinction then, but how would this be applied in a wikidata context? It seems we have three things involved - the item that may be an image such as File:Plan of Dudley Castle (1897).jpg (but that's not an item?), the specific (PDF?) file it came from, which would be related by what property? And then this as a qualifier? ArthurPSmith (talk) 13:30, 15 October 2019 (UTC)

@ArthurPSmith: I would see it used in much the same way as page(s) (P304), but when the reference or the source is an electronic document for which one has a url, where one's metadata might or might not also give a printed page number. So I could see it being used as a qualifier on full work available at URL (P953) eg for a chapter from a book; similarly described at URL (P973); equally in references, alongside stated in (P248) = item for book etc, reference URL (P854) = url for digital copy, this property to indicate which frame of that digitisation. How to represent sources of images in SDC is still somewhat up in the air, but again one would expect something to identify the containing work, a url where it was available, and then this to indicate which frame of the digitisation. Jheald (talk) 13:50, 15 October 2019 (UTC)

•  Comment added a sample above. It would probably also be useful for Commons. --- Jura 12:05, 20 November 2019 (UTC)
  • @Hsarrazin: it seems to me that you frequently add such statements. --- Jura 12:09, 20 November 2019 (UTC)

• No, I do not add such statements. I add links to pdf/djvu files, but the pages statements I add are "page in the book", not "page in the file" info...
• However, @Jura1:, I think I see what you mean... this could be useful to directly point to the page of a file, when it is not used in wikisource... when using a wikisource file, as reference for a statement, we generally have to use reference URL (P854) and something like "https://en.wikisource.org/wiki/Page:Emily_Dickinson_Poems_(1890).djvu/160" - it would be better to be able to link to the page of the file, by giving its name and page...
• considering the name of the property, I would prefer a name such as "file page", to clearly indicate it is the page of the file, whatever the format (pdf, word, djvu, etc.)...

• @Hsarrazin: Good idea for the name. I think that should make it fairly clear. --- Jura 14:24, 20 November 2019 (UTC)

• @Jheald, Tinker Bell, Hsarrazin: Shall we move ahead with the updated label per Hsarrazin's suggestion? --- Jura 19:19, 21 November 2019 (UTC)

Works for me. The new name is an improvement. Jheald (talk) 20:29, 21 November 2019 (UTC)

I think it's ok. 16:16, 23 November 2019 (UTC)

•  Support  Oppose Uh… to summarize Jura: What you want is like what is found on Civilization V (Q2385)input device (P479)computer keyboard (Q250) and Civilization V (Q2385)input device (P479)mouse (Q7987) in the references for example? Just like page(s) (P304), your proposal will be accompanied by a .pdf document and proposed by a link. This link is registered by a contributor. By adding a page, the contributor gives the location of the information. Another contributor will find this same information by clicking on this link. So, whether it is a digital document or not, a pdf or not, the information is always located in the same way: a contributor will not enter the page number of a "paper" newspaper for example, then enter the link of the digital version. What I mean is that a page accompanies a support, whether for your proposal or for the property already existing. Doubt seems to me excluded. Enlighten me if I make a mistake. Because after pdf page, it will be necessary to make a property for each type of document. Tedious. —Eihel (talk) 00:51, 27 November 2019 (UTC)
  • Have a look at the sample. --- Jura 00:59, 27 November 2019 (UTC)
• Maybe once it created, we could ask the devs to take it in account for the image that is displayed (instead of the page 1 of the djvu file/pdf, etc.) --- Jura 09:25, 27 November 2019 (UTC)
• Hophophop! Quickly done @Jura1, Jheald, ArthurPSmith, Tinker Bell, Hsarrazin:. I think about it now that I started creating the prop (stupid as I am). I wanted to simply copy the other property P304 to make my life easier and I realize that pages can be counted in different ways. I'm not asking for the removal of P7668 following the compromise here (maybe String instead of Integer, so Quantity). I also inspected (a little) the other RegEx which seems complicated. We can include pages named i or ii and A1, A2, A3, etc. I think the other RegEx also counts pages/number of pages. etc. Those who want to deepen this question, return to the "drawing board", if I dare say. Also think (again) that the files will not necessarily be pdf or even djvu, so we can count the pages in many ways (not Adobe). Wait for comment. —Eihel (talk) 19:23, 3 December 2019 (UTC) ps. These are quick thoughts, so do not hold it against me. I was not interested in formats, page numbers, etc. It's just removing ready and stopping the construction of the property to take the "temperature of the community". Cordially. —Eihel (talk) 19:44, 3 December 2019 (UTC)

  An integer should work for both djvu and pdf. Are there some where it wouldn't work? --- Jura 19:38, 3 December 2019 (UTC)

  Which formats are allowed? (just pdf and djvu, or another file? For example, XML is allowed?) and according to these formats, what page notations are allowed? Otherwise, can there be simple pictures, taken somewhere else, so with a different notation? Again, I did not check anything, I was wondering: the other P304 is of the string type to allow different formats, this is where I tilted (maybe I'm asking too many questions and wasting your time). If it's a RegEx to replace, it's not important, but if it's a datatype, it's more boring Jura. —Eihel (talk) 20:02, 3 December 2019 (UTC)

  I think it's mostly relevant for file formats that can be hosted on Commons and have pages that could be specified. I'm not sure if the proposal misses out on any.

If the file is located elsewhere and the name specified with URL datatype, the anchor can be included directly. --- Jura 07:24, 4 December 2019 (UTC)

@Jura1, Jheald, ديفيد عادل وهبة خليل 2, ArthurPSmith, Tinker Bell, Hsarrazin:  Done file page (P7668) —Eihel (talk) 09:15, 4 December 2019 (UTC)