Property talk:P1545

Documentation

series ordinal
position of an item in its parent series (most frequently a 1-based index), generally to be used as a qualifier (different from "rank" defined as a class, and from "ranking" defined as a property for evaluating a quality).

Description

position of an item in its parent series (most frequently a 1-based index), generally to be used as a qualifier (different from "rank" defined as a class, and from "ranking" defined as a property for evaluating a quality).

Represents

ordinal number (Q191780)

Data type

String

Usage notes

Can be used for any logical series; values can include e.g. 6; 3.5; 1b; 3–6; C4. Should be used only for series where all elements have equal or similar value; use "ranking" (P1352) to indicate the rank (value/importance...) of elements requiring gradation.

Example

A (Q9659) → 1
B (Q9705) → 2

Tracking: usage

Category:Pages using Wikidata property P1545 (Q23909047)

Data type

Shouldn't this be a number? ----- Jura 16:59, 8 November 2014 (UTC)[reply]

It's possible that the original intent was to use '1st' or 'first', but I think it would make sense to change this to a number, yeah. — GPHemsley (talk) 16:00, 10 November 2014 (UTC)[reply]

Well, maybe for things like "1, 2, 3a, 3b, 4, 5" string datatype would be needed.

Maybe we just need to make Reasonator sort it. The series on https://tools.wmflabs.org/reasonator/?&q=18516851 isn't ideal. --- Jura 17:08, 10 November 2014 (UTC)[reply]

I think we should change to a number datatype. With the string datatype, it is impossible to use QuickStatements.--Casper Tinan (talk) 22:27, 7 January 2015 (UTC)[reply]

@Jura1, GPHemsley: I am considering proposing a change of datatype. Do you have any argument against it ? --Casper Tinan (talk) 21:13, 14 January 2015 (UTC)[reply]

I tried to use the constraint report to see how it's currently used, but these don't work for qualifiers. If there are uses like "3a, 3b" or "III", the number type wont work.

To use it in Quickstatements, adding quotes might be sufficient. --- Jura 22:10, 15 January 2015 (UTC)[reply]

No, it should stay as string. Sometimes item number has additions, like "2, 2¹, 2-V, etc.", as specified in source. -- Vlsergey (talk) 11:17, 5 August 2015 (UTC)[reply]

@Vlsergey: Then we should have a real ranking property. This is limiting the possibilities, the point of a ranking property is to be able to sort automatically, for a few edge cases which should not happen. author TomT0m / talk page 09:08, 16 August 2015 (UTC)[reply]

@TomT0m: It surely depends on use cases. In most of them automatic ordering can happen based in P1545. Anyway, let's consider an example. We have items with numbers "1, 2, 3, ..., 10000". A bit later item with number "2A" was added. Do you plan to update all items "3, 4, ..., 10000" with new rank? -- Vlsergey (talk) 09:33, 16 August 2015 (UTC)[reply]

@Vlsergey: A query engine trying to sort naturally strings will alphabetical ordering will give wrong results, which is bad. There is no problem, numbers can be ordered further into 2.5 for example. We should leave this property as an alias for the original label, by convention, but everything can be done with number datatype, including treating edge cases. For example

⟨ episode 1.a ⟩ part of (P361) ⟨ series ⟩
order Search ⟨ 1.1 ⟩
label ordering Search ⟨ 1.a ⟩

author TomT0m / talk page 09:44, 16 August 2015 (UTC)[reply]

@TomT0m: i see your point. Well, anyway, i need a field that has meaning "position of an item in its parent series", filled strictly according to sources, i.e. may include strings. Current field looks the best choice for that. Would you need strictly number field for some kind of ordering and database sorting -- this may need another field. Personally i believe it won't be needed -- database can transform strings into numbers. Also it will be hard to find sources in cases when value is not the same as current field. -- Vlsergey (talk) 12:25, 16 August 2015 (UTC)[reply]

@Vlsergey: I think your interpretation of the sourcing principle is out of common sense. What need to be source with a property that represante the order of a sequence of items is the ordering itself, the exact label is just a mean, not a goal by itself. If you lose the common sens. and the real objective, absurdities will rise which will make the datas way too difficult to use for bad reasons. It's possible to order strings of course but it's uselessly complex and is headheach and error prone for data consumers. Yes, database can tranform string into numbers, but when a "v" will show up in a string nothing guaranties it will be correctly interpreted. author TomT0m / talk page 12:37, 16 August 2015 (UTC)[reply]

It is not about "out of common sense", it's about "hey, what 1.125 means in order field and where did it come from"? If you want to have such problems out of nowhere -- feel free to have ~~them~~ new field. I will just abstain to use it in any possible way. 2. "but when a "v" will show up " -- when it shows up script should know from context what this sequence is about and how values can be transformed . -- Vlsergey (talk) 14:22, 16 August 2015 (UTC)[reply]

It's just a matter of pointing an help page when a question shows up, no big deal. «when it shows up script should know from context what this sequence is about and how values can be transformed> This makes the property not complete enough by itself to infer the ordering, which almost defeats the point of having a dedicated ordering property. At least followed by (P156) and follows (P155) do not need any domain knowledge. author TomT0m / talk page 14:30, 16 August 2015 (UTC)[reply]

@TomT0m: I don't believe that any property can be used without domain knowledge. You need "context" date to output places and you need "context" place to output dates. You need context language to print publication authors and "context" date to print journal title. And i don't believe that you will be able to use even number field without prior context knowledge. Well, right now it's offtopic. There is a property that should stay "string" or there should be a new property that will have name series ordinal (P1545) and have string as datatype. Any is okay with me. Since current property is string already I would suggest new one to have "number" type. -- Vlsergey (talk) 18:32, 16 August 2015 (UTC)[reply]

@Vlsergey: It's assumable that you can totally order anything that has a «series ordinal» property because it's precisely what a series is : something totally orderable :) So there is always a series of numbers (even if you choose rational numbers) can than be used to represent the order in a series. This then can be removed out of the needed domain knowledge needed. And that's exactly the same function a secondary order by alphabetical letter for in beetween elements is used for : divide 1 by 26 to have the analog increment in numbers for 1a 1b … . author TomT0m / talk page 10:28, 17 August 2015 (UTC)[reply]

most (all?) instances of two-part episode (Q21664088) have two consecutive Numbers as their ordinal (see The Menagerie). I thought of using 1 & 2 which does not seem very machine readable to me --Shisma (talk) 08:09, 10 February 2018 (UTC)[reply]

Difference from ranking (P1352)

Would be nice to document the difference in usage between series ordinal (P1545) and ranking (P1352). Federico Leva (BEIC) (talk) 14:16, 31 December 2015 (UTC)[reply]

Examples

Is there a special reason why the given examples can't be seen in the real data? --Jobu0101 (talk) 12:40, 30 January 2016 (UTC)[reply]

̈̽̈Maybe other samples illustrate them better. As this is mainly used as qualifier .. samples would work better on the template, than as statements on the property.
--- Jura 12:55, 30 January 2016 (UTC)[reply]

Differences in usage for television episodes

I've noticed there are a couple of different conventions in use for television series: for example with Game of Thrones (Q23572) the series ordinal (P1545) qualifier on a part of the series (P179) statement linking an episode to the series starts again at 1 at the beginning of each new season. You can see that with this query:

SELECT ?season ?seasonNumber ?episode ?episodeLabel ?episodeNumber WHERE {
  BIND(wd:Q23572 as ?series)
  ?episode wdt:P361 ?season ;
           p:P179 ?episodeSeriesStatement .
  ?season wdt:P31 wd:Q3464665 ;
          p:P179 ?seasonSeriesStatement ;
          wdt:P361 ?series .
  ?seasonSeriesStatement ps:P179 ?series ;
                         pq:P1545 ?seasonNumber .
  ?episodeSeriesStatement ps:P179 ?series ;
                          pq:P1545 ?episodeNumber .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
ORDER BY xsd:integer(?seasonNumber) xsd:integer(?episodeNumber)

Try it!

Whereas with Breaking Bad (Q1079), for example, the series ordinal (P1545) qualifier on a part of the series (P179) statement linking an episode to the series increments regardless of whether a new season has started (this is the same query but with a different item bound to ?series):

SELECT ?season ?seasonNumber ?episode ?episodeLabel ?episodeNumber WHERE {
  BIND(wd:Q1079 as ?series)
  ?episode wdt:P361 ?season ;
           p:P179 ?episodeSeriesStatement .
  ?season wdt:P31 wd:Q3464665 ;
          p:P179 ?seasonSeriesStatement ;
          wdt:P361 ?series .
  ?seasonSeriesStatement ps:P179 ?series ;
                         pq:P1545 ?seasonNumber .
  ?episodeSeriesStatement ps:P179 ?series ;
                          pq:P1545 ?episodeNumber .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
ORDER BY xsd:integer(?seasonNumber) xsd:integer(?episodeNumber)

Try it!

I'm guessing that the latter use is more correct, since the qualifier is on a relationship between the episode and the series, not season, and it would be weird if the same number could appear as a series ordinal on the part of the series (P179) for a particular series for multiple different episodes. Could someone possibly confirm if my assumption is right, and that most of the series ordinal (P1545) qualifiers on part of the series (P179) statements for Game of Thrones (Q23572) should be fixed? Mhl20 (talk) 16:06, 3 September 2017 (UTC)[reply]

I've noticed that The West Wing (Q3577037) is a useful comparison. Each episode of The West Wing (Q3577037) (e.g. Bad Moon Rising (Q4840385)) has two part of the series (P179) statements, one to the season and one to the series as a whole. The series ordinal (P1545) qualifier on the part of the series (P179) relating to the season starts at 1 at the start of each new season, as you'd expect, while the series ordinal (P1545) qualifier on the part of the series (P179) relating to the series as a whole continues incrementing across seasons. This supports what I thought about the use of series ordinal (P1545) for Game of Thrones (Q23572) being unhelpful - if one wants to represent the number within a season, that could be done as with The West Wing (Q3577037). Mhl20 (talk) 09:25, 3 November 2017 (UTC)[reply]

Wikidata:WikiProject_Movies/Properties#Episode has the general structure for TV episodes and Wikidata:WikiProject_Movies/Infobox a few episode lists. If the ordinal relates to the series, it would qualify the statement about the TV series. If it relates to the season, it would be on the season statement. the West Wing sample doesn't seem to match the model.
--- Jura 07:54, 5 November 2017 (UTC)[reply]

Thanks for those references... I think, checking carefully, that The West Wing does do this correctly according to what you've said and those documents, but I was expressing how it's modelled unclearly in my comment. This query, for example, returns what I'd expect based on that. Thanks for your help! Mhl20 (talk) 15:21, 3 February 2018 (UTC)[reply]

How to count Two-Part-Episodes?

How to count two-part-episodes? Example Encounter at Farpoint (Q3239271) has been broadcasted as a single pilot originally in the US. In other countries and re-runs it was split in two episodes:

They have different production numbers and in German, these two have different Titles and of course, separate broadcast dates. So should the next Episode (The Naked Now (Q3231807)) have a series ordinal (P1545) of 2 or 3? --Loominade (talk) 12:43, 6 February 2018 (UTC)[reply]

I'd follow whatever the producer uses. There was some discussion about two-part episodes at Wikidata_talk:WikiProject_Movies/Archive_1#two-part_episodes with @Queryzo, Máté:.
--- Jura 08:15, 10 February 2018 (UTC)[reply]

Production or Broadcasting order?

Past Prologue (Q3507056) is the 4th Episode of Star Trek: Deep Space Nine (Q108774) by its production order but the third according to broadcasting order. Netflix seems to orders it as 4th while everyone else thinks its the third. Now I really don't want to judge which order is correct. I'd rather like to express both. How can I do that? The broadcasting order might also defer by country.--Shisma (talk) 15:22, 24 March 2018 (UTC)[reply]

There is a dedicated field for the production code and for the date of (first) broadcast. If one wants to sort by either of these, it should be done easily. We wouldn't need P1545 for that.
If there is a published order of the episodes, I think that would be preferable.
See also: Talk:Q48497304.
--- Jura 17:48, 24 March 2018 (UTC)[reply]

Allowed values

@Moebeus: I had no idea that this property was supposed to be used for other strings. Should information about how to use this with e.g. double albums and vinyl albums be in a Wikidata usage instructions (P2559) statement? (I actually created a property proposal because I didn't think this was allowed with this property.) Jc86035 (talk) 18:17, 13 August 2018 (UTC)[reply]

I would like nothing more than a "tracknumber" qualifier property to use with tracklist, but until there is one i don't see any alternative to series ordinal (or I haven't found one). Putting something in a Wikidata usage instructions (P2559) statement sounds like a smart idea, I just haven't any experience using that myself (it seems to be in kind of a perpetual "beta" state?). Moebeus (talk) 18:27, 13 August 2018 (UTC)[reply]

@Moebeus: Maybe an instruction like "Use this property for any logical series; values can include e.g. 2a, 3–6, B4" would help. I think a separate "track number" property would also be useful, as then values could be formatted automatically to whatever convention is chosen. Jc86035 (talk) 20:02, 13 August 2018 (UTC)[reply]

@Jc86035: Sounds brilliant! Do you want me to do it, or are you taking care of it yourself? Moebeus (talk) 20:20, 13 August 2018 (UTC)[reply]

@Moebeus: Are you referring to the property proposal, or to the instruction? Jc86035 (talk) 04:16, 14 August 2018 (UTC)[reply]

@Jc86035: Sorry for being unclear; I was referring to the instruction. I'm not quite ready to make a property proposal just yet, not really familiar with the process. Moebeus (talk) 12:37, 14 August 2018 (UTC)[reply]

I've edited the instruction. Jc86035 (talk) 13:50, 14 August 2018 (UTC)[reply]

Last ordinal

Is it possible to use something to indicate a qualifier of 'last' for a series with a variable number of items, otherwise is there a different property that would be reasonable? Evolution and evolvability (talk) 02:47, 31 January 2019 (UTC)[reply]

@Evolution and evolvability: Maybe has characteristic (P1552) → last (Q30013662)? Jc86035 (talk) 09:02, 3 February 2019 (UTC)[reply]

Scope constraint

I've removed the scope constraint, since there are more than 18,000 violations, including some on relatively important items like Monday (Q105). Only allowing use as qualifiers also makes it impossible to indicate certain qualifiers, such as criterion used (P1013) on January (Q108). I've replaced it with a single value constraint. Jc86035 (talk) 09:54, 20 March 2019 (UTC)[reply]

@Dhx1: Yesterday, a constraint was introduced. But this now results in wrong warnings as it does not work on lexemes, see, e.g., alarmere (L311505). — Finn Årup Nielsen (fnielsen) (talk) 09:20, 2 September 2020 (UTC)[reply]

@Fnielsen: Fixed it by adding Wikibase lexeme (Q51885771) as an approved entity type this property can be used with. --Dhx1 (talk) 12:25, 2 September 2020 (UTC)[reply]

@Dhx1: Thanks! — Finn Årup Nielsen (fnielsen) (talk) 13:45, 2 September 2020 (UTC)[reply]

@Jc86035: It also results in errors for Monday (Q105) again. — Finn Årup Nielsen (fnielsen) (talk) 09:22, 2 September 2020 (UTC)[reply]

@Fnielsen, Jc86035: In the case of Monday (Q105), part of the series (P179) would be better to use, with series ordinal (P1545) as a qualifier. Otherwise it is not clear what series is Monday ordinal 1 of. It is possible to add "as main values" as another acceptable property scope constraint item but I can't think of a use case where this makes sense. Are there other examples you know of where series ordinal (P1545) as a main value makes sense? --Dhx1 (talk) 12:22, 2 September 2020 (UTC)[reply]

@Fnielsen, Jc86035: I've just had another look through a random sampling of uses of series ordinal (P1545) as a main value and I'm at 100% strike rate of errors. In most cases, there was a more appropriate property to be used: route number, product code, other type of identifier, etc. In other cases where a more appropriate property wouldn't apply--part of the series (P179) would be the better property to use (specifying the series) and then series ordinal (P1545) as a qualifier noting the position of the item in the series. --Dhx1 (talk) 12:42, 2 September 2020 (UTC)[reply]

Usage in refs

This property should be possible to use in refs, e.g. with literature that does not have page numbers but enumerated items. Messehochhaus (Q105713818) or Trakehner Straße 18 (Q105713817) for example (the architects' refs). This cited book also uses the numbers in the toc/register, so even a page number would not help finding the item. (there will be more examples like that, especially architectural guides). Just saying, I'll ignore the constraint warning for the moment because it's perfectly logical. Please ping me for an answer, thx--Elya (talk) 17:41, 28 February 2021 (UTC)[reply]

Clean up complete

After newest lovely pushing to clean up “my data-rubbish” (constrains were changed after I’d used it, without any discussion in advance with me) I’d cleaned up Bavarian monuments. So you should see in the next time approximately 150k less issues. Possibly a couple issues will stay but this is not on me and brought in by other users. In short, Bavarian cultural monuments are P:P1554 free now. @Ordercrazy, MisterSynergy, Jura1, Tacsipacsi: fyi. --Derzno (talk) 07:20, 4 February 2022 (UTC)[reply]

Property talk:P1545

Contents

Documentation

Data type

Difference from ranking (P1352)

Examples

Differences in usage for television episodes

How to count Two-Part-Episodes?

Production or Broadcasting order?

Allowed values

Last ordinal

Scope constraint

Usage in refs

Clean up complete

Navigation menu