Property talk:P304

Active discussions


page number of source referenced for statement
Descriptionpage number of source referenced for statement. May be a range of pages. To be used in the "sources" field.
Representspage (Q1069725)
Data typeString
Domainany statement of any item (note: this should be moved to the property statements)
Allowed values^(([A-Z]|[1-9])\d*((-|–|—)([A-Z]|[1-9])\d*)?|[A-Za-z]*(\d [A-Za-z]*)?|[\w-]{1,9})$ (digits, or letters only, or alpha digits alpha. Ranges: digits-digits)
Example12 ; XII ; A2ii ; 16-17 (note: this information should be moved to a property statement; use property Wikidata property example (P1855), Wikidata property example for properties (P2271), Wikidata property example for lexemes (P5192), Wikidata property example for forms (P5193) or Wikidata property example for senses (P5977))
See alsonumber of pages (P1104), section, verse, paragraph, or clause (P958), chapter (P792), volume (P478), issue (P433), measure number (P7141), folio(s) (P7416), file page (P7668)
Proposal discussionProposal discussion
Current uses
Main statement34,036,02898.9% of uses
Qualifier308,8800.9% of uses
Reference66,8210.2% of uses
[create Create a translatable help page (preferably in English) for this property to be included here]
  Format “(([A-Z]|[1-9])\d*((-|–|—)([A-Z]|[1-9])\d*)?|[A-Za-z]*(\d [A-Za-z]*)?|[\w-]{1,9}): value must be formatted using this pattern (PCRE syntax). (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P304#Format, SPARQL, SPARQL (new)

Why stringEdit

This property is defined as string because different ways can be used to define page number like A-1 or an interval of pages like 1234-1256. Snipre (talk) 20:06, 20 March 2013 (UTC)

Claim vs statement in descriptionEdit

A reference is used in a statement, it is not available in a claim. Because of this I changed the description to use "statement" and not "claim" as it was before. If this "page" will be used as a general property it should not name either claim or statement. Jeblad (talk) 15:22, 7 June 2013 (UTC)

Article IDs in electronic-only journalsEdit

The page concept does not always fit with electronic-only publications, and a common way around that is to assign article IDs to individual articles, rather than start and end pages. In bibliographic contexts, article IDs are typically entered in what otherwise is the "page" field. Should we follow this pattern or clearly distinguish between the two? For an example article, see doi:10.1371/journal.pcbi.1002727, for which I just started A Future Vision for PLOS Computational Biology (Q19370790). Its page ID is e1002727, which does not fit with the current constraints on allowable strings for P304. --Daniel Mietchen (talk) 04:02, 2 March 2015 (UTC)

Hi Daniel, I think we should propose a new property for this case. --Succu (talk) 08:00, 2 March 2015 (UTC)
No, the concept is the same, a new property will just be more confusing for people creating once an item about an article. We have an exception, this is not a problem to manage with the constraints system. The question is more to know is this exception is specific to the current journal or if they are more format problems with others journals. If yes, we have to see if we can modify the constraints. Snipre (talk) 16:24, 2 March 2015 (UTC)
If you have to cite a certain page within an article of an issue you'll need both a page and the article id. --Succu (talk) 16:43, 2 March 2015 (UTC)
I mulled this over a bit more and think now that a new property for article ID is the best way to go. --Daniel Mietchen (talk) 20:46, 11 May 2015 (UTC)
I proposed it. --Daniel Mietchen (talk) 04:07, 2 August 2015 (UTC)

Which dash?Edit

The format constraint prescribes the use of a en dash for page ranges whereas the example uses a hyphen as many use cases do which produce constraint violations. For English enwiki states that both variants are used, enwiki itself uses an en dash. It could be useful to use one variant here to simplify data reuse. Possibly a hyphen is easier to input for most people? --Marsupium (talk) 11:50, 28 July 2015 (UTC)

  extended --- Jura 12:55, 26 November 2015 (UTC)
Would it not make more sense to set the constraint to only allow en dash then have a bot patrol the reports and change correct any hyphens/m dash? This is how e.g. underscores in P18 filenames are barked. /Lokal Profil (talk) 19:50, 1 August 2018 (UTC)

Non-source useEdit

Numerous users have been using this property for claims (as opposed to sources/references). Examples: Q15097304, Q14624399, Q14624838, Q21003828. What do these statements mean, and should the property be used in this manner?

(Also, was some automated tool involved here? The series of edits look similar enough that I thought it was a bot at first, until I saw the different user names...)

--Yair rand (talk) 13:06, 13 October 2015 (UTC)

Well, Q15097304 is a source, there is no sitelinks there. It looks like it describes as an article "The crystal structure of argentojarosite, AgFe₃(SO₄)₂(OH)₆" which has been published in page 921–928 in "The Canadian Mineralogist". If there is a sentence in page 923 which confirms the statement, you may add that in the source if you like. -- Innocent bystander (talk) 13:55, 13 October 2015 (UTC)

Split into start and end page?Edit

Many uses of the property actually give a range of pages, e.g. "921–928" in The crystal structure of argentojarosite, AgFe₃(SO₄)₂(OH)₆ (Q15097304). Wouldn't it be better to split that somehow into "starting page" and "end page", either by suitable qualifiers to page(s) (P304) or by dedicated properties? Some sources (particularly on paper) actually may have multiple start and end pages (e.g. Some Thoughts About Publishing Results in Our Field [Publication Activities] (Q24090833) currently states "22-41", even though the article is less than 1.5 pages long — it had just been printed in part on p. 22 and 41), and this would be easy to model with such a split, as would be cases where start and end page are identical, for which P304 works best. --Daniel Mietchen (talk) 20:36, 18 May 2016 (UTC)

I am not sure that is a good idea. If you have the statement: "page:9-16, 47-93" that would make "startpage:9, 47" and "endpage:16, 93" and that is tricky to put together correctly. It could be interpreted as "9-93, 47-16" and that would be wrong. A software maybe can interpret numbers like 9 and 47 correctly, but I am not as sure with page numbers like "CIV v". -- Innocent bystander (talk) 06:59, 19 May 2016 (UTC)
@Daniel Mietchen, Innocent bystander: not sure but it sound like a good idea to me. Right now the constraint accept two forms : 921-928, 921–928 (see #Which dash? above) ; that can be confusing too. A clear property would more explicit. For the « 9-16, 47-93 », wouldn't a simple solution to put it two times : « startpage:9 endpage:16 » and « startpage:47 endpage:93 » ?
BTW, there is a lot of strange constraint violations on Wikidata:Database reports/Constraint violations/P304. Daniel, you seems to be responsible for at least parts of them, could you explain and maybe change/adapt the constraint? For instance Q21147030#P304 is quite confusing. Cdlt, VIGNERON (talk) 12:21, 27 May 2016 (UTC)
RE:VIGNERON: The order of two claims is not a failsafe way to add things here (at least not yet). -- Innocent bystander (talk) 12:24, 27 May 2016 (UTC)
True; but separate them is a failsafe to avoid confusion like "9-93, 47-16" interpretation. Does the order really matter? Isn't this order obvious? Cdlt, VIGNERON (talk) 12:31, 27 May 2016 (UTC)
Yes, it is obvious as long as it is a human who reads and as long as numbers who are easy to read for a computer is used. It's all the strange exceptions I am worried about. The constraints report probably has found many of them. -- Innocent bystander (talk) 12:37, 27 May 2016 (UTC)
@VIGNERON, Innocent bystander: I think we should avoid things like "startpage:9, 47" and "endpage:16, 93" and go for « startpage:9 » « endpage:16 » and « startpage:47 » « endpage:93 » (etc.) instead.
As for adapting the constraint violations, I see the need, but I am not comfortable enough with Perl Compatible Regular Expressions (Q125267) to fix the constraints myself. Would be happy to learn more about that, though, since there are other properties where there is a similar misfit between the constraints and the actual values. --Daniel Mietchen (talk) 18:26, 27 May 2016 (UTC)
@Daniel Mietchen: What happens if you try to add « startpage:9 » « endpage:16 » and « startpage:47 » « endpage:93 » to an item or the source-part of a claim? From what I know, it is not techinically possible. I would love such a solution, but I do not think it works. -- Innocent bystander (talk) 19:47, 27 May 2016 (UTC)
@Innocent bystander: Not sure I get your question. I think right now, nothing happens, i.e. such edits cannot be saved. In case you are talking about
« startpage:9 endpage:16 » and « startpage:47 endpage:93 »
« startpage:9 » « endpage:16 » and « startpage:47 » « endpage:93 »
I can imagine it both ways but am not aware of a technical way to implement the former (i.e. bundling the start and end page of a given blob of text), which is why I wrote the latter. --Daniel Mietchen (talk) 21:27, 27 May 2016 (UTC)
@VIGNERON: I made some edits to the constraints — review/ comment appreciated. --Daniel Mietchen (talk) 21:30, 27 May 2016 (UTC)
What about articles spanning multiple issue (P433)? --Succu (talk) 21:28, 27 May 2016 (UTC)
How common is/ was that? Got an example? Perhaps we could treat them as if these were separate articles? --Daniel Mietchen (talk) 21:45, 27 May 2016 (UTC)
I have never heard of such a thing in a scientific paper, but I can imagine other kinds of articles published in other kinds of media having such problems. I know that we have handled such articles on sv.Wikisource. The article in question was published as a serial fiction (Q1347298) in a 19th century newspaper. On Wikisource, the different parts were by convinience merged together in one article. -- Innocent bystander (talk) 04:07, 28 May 2016 (UTC)
The Water-Babies, A Fairy Tale for a Land Baby (Q14914646) is an example for serial fiction (Q1347298). In older publications like Allgemeine Gartenzeitung (Q5669289) it was a common praxis. --Succu (talk) 07:49, 28 May 2016 (UTC)
@Succu: How would a reference to this text look like in Wikipedia? -- Innocent bystander (talk) 13:25, 28 May 2016 (UTC)
See de:Die Wasserkinder#Erstveröffentlichung (It's my approach). --Succu (talk) 21:01, 28 May 2016 (UTC)
Thanks! I would probably have done the same. And the corresponding to that here would probably be to put it in 8 different items or 8 different references. -- Innocent bystander (talk) 06:16, 29 May 2016 (UTC)

Constraint violation for use on version, edition, or translation (Q3331189) able to be coded?Edit

Where this property is used on items that are set for P31 -> Q3331189 would it possible for this to be marked as a violation, as it would be expected that we would be using number of pages (P1104). Thanks.  — billinghurst sDrewth 04:54, 18 August 2017 (UTC)

@billinghurst: let's try, I added the constraint, there is 100 violations and most seems not to be confusion with number of pages (P1104). For instance Q19127415 seems to be correct (or at the very least not a confusion with number of pages (P1104)). Should we keep this constraint or not? Cdlt, VIGNERON (talk) 16:24, 31 January 2019 (UTC)

existing constraint variation requiredEdit

Hi. Looking at some of the current variations, we have articles that are split ie. a run of pages, a gap, then another page or run, eg. Perspectives in disease prevention and health promotion fatal occupational injuries - Texas, 1982 (Q26342600). Would it be possible to look to vary the constraint to adapt to that variation? Thanks.  — billinghurst sDrewth 05:05, 18 August 2017 (UTC)

I agree. The current regex is too restrictive and doesn't allow for common situations when a story or article is split into two sections in the same issue, e.g. Alice Munro's The Bear Came Over the Mountain (Q60664117), published in the New Yorker on pages "110–121, 124–127" -- LesserJerome (talk) 17:19, 18 January 2019 (UTC)

@billinghurst, LesserJerome, Harej, Daniel Mietchen: we can change and expand the regex but we should list all the value we want and don't want. For instance, yesterday I changed the constraint to allow "67, 69" (because it could be non-consecutive pages), is it ok? The current regex format allows 3 type of hyphens (-, – and —) which is quite open but in the same time it doesn't allow to put spaces on each side of these hyphens, which is quite closed… So 10-13, 10–13 and 10—13 are allowed but not 10 - 13. Is it really what we want? (personally, I would only allow 10-13, and put a conversion script for all others formats but I'm open to discussion). The [A-Z] feel strange too, if this is for roman numeral is should be limited to [IVXLCDM]. Cdlt, VIGNERON (talk) 17:23, 31 January 2019 (UTC)

VIGNERONI'm satisfied with the allowance of commas, and I think that is a good idea to normalize hyphens/dashes with a conversion script. For roman numerals, perhaps [iIvVxXlLdCcDmM] to allow for numerals that appear in lowercase as well? Case might not be an incredibly important to capture, but this would at least allow for some variation. Thanks for your help! LesserJerome (talk) 17:39, 31 January 2019 (UTC)
Pretty much agree, we need PAGE/PAGERANGE(, repeat)?(, repeat)? and maybe another repeat. Agree about limited subset of lower case roman numerals, though hesitate as I only have experience in western European books, not certain what early eastern European books did. That said, I had had a later thought that if it was too hard to cover the range in one set, we can just utilise multiple number sets, but that forces the inhalation and tying together to happen at the using site, and that could be problematic.  — billinghurst sDrewth 22:08, 31 January 2019 (UTC)

warning about page(s) for version, edition or translationEdit

I am getting a warning because apparently, if it is a version it does not have page numbers?--RaboKarbakian (talk) 17:13, 2 February 2019 (UTC)

@RaboKarbakian: see two discussions above. This constraint is pobrably a false good idea. Too many false-positive, we should probably remove it. @Billinghurst: what do you think? Cdlt, VIGNERON (talk) 16:24, 5 February 2019 (UTC)
@RaboKarbakian: constraint removed by @Hsarrazin:. Cdlt, VIGNERON (talk) 09:11, 13 February 2019 (UTC)
Hello ! Sorry for not checking before removing it... :)
I did not know about this discussion, but this constraint was, for me, an obvious error, since I have thousands of items about editions of short stories, poems, etc, published in periodicals, or in anthologies...(link with published in larger work (P1433) - how could i catalog them without page(s) (P304) ?
don't know if it is feasible to link the use of this property on editions with the simultaneous use of published in larger work (P1433)... what do you think @Billinghurst, VIGNERON: --Hsarrazin (talk) 09:17, 13 February 2019 (UTC)
No problem, and honestly as soon as I added this constraint I had doubts (cf. the previous discussion above). Cheers, VIGNERON (talk) 09:33, 13 February 2019 (UTC)

Locations in e-booksEdit

For e-books that don’t have the “real page number” feature, do we use this property for the “location” in references? - PKM (talk) 03:51, 29 March 2019 (UTC)


I dont understand the item Description. My native language is Czech, I also speak English, but I dont understand it in neighter language. Could we rephrase it?--Juandev (talk) 18:59, 25 April 2019 (UTC)

Hyphenated page numbersEdit

How should we enter the range when page numbers have hyphens? Consider the chapters in Metallogenesis and Tectonics of Northeast Asia (Q57842373). As Chapter 1, Introduction (Q63249120) has pages 1-1 through 1-36. I think pages(2) 1-1-1-36 would be very confusing, so maybe an em dash somewhere would be better? Trilotat (talk) 13:27, 27 September 2019 (UTC)

Format regular expression warning on "roman-roman" numberingEdit

Looking at Q69168855 there is a warning for the page numbering in the form "ix-xix". Pretty certain that this has worked previously without a warning.  — billinghurst sDrewth 22:54, 29 September 2019 (UTC)

  Done @billinghurst: RegEx changed, no more warning —Eihel (talk) 09:46, 4 December 2019 (UTC)

Page vs folioEdit

There is a discussion about P304 vs folio(s) (P7416) at Topic:Vc0m1yeldangkxl4. You're all welcome to come and contribute your opinions. Deryck Chan (talk) 13:10, 2 December 2019 (UTC)


אני צריך בבקשה שבביטוי הריגולטי - יוסיפו אותיות א-ת אלפבית עברי בעברית, כי יש הרבה שימוש בעמודים מסומן באותיות עברית בספרים בעברית. אבגד (talk) 02:25, 20 April 2020 (UTC)

Return to "P304" page.