query-12132216f1710645bf1d1cdfca07ed54
Property season 08:18, 18 February 2018 (UTC)) talk (Queryzo, we should strongly think about an own property "season". (P361)part of /(P527)has part(s) (XYZ should also have the inverse statement, which is not suitable for seasons with a lot of episodes) and get clear with double episodes, which also are stated with massive inverse constraint violations to show which season an episode belongs to. To avoid (P361)part of etc., but we use (P2437)number of seasons , (P1811)list of episodes , (P179)part of the series We have Jerimee PaperHuman DaxServer BeLucky Fuzheado dseomn Keplersj Sriveenkat RealityBites Jakeob9000 Demadrend Haseeb Carlinmack Supaplex Ontogon Ranjithsiji Gnoeee Spinster Sidohayder Mathieu Kappler Rockpeterson M2k~dewiki, mostly focus on media historiography and works from the Global South Wallacegromit1 Sotiale 2le2im-bdc Trivialist ɲɤʂ CptViraj Antoine2711 T7Tris Wolverène Shisma Bodhisattwa U+1F350 Andreasmperu GardenerAmaryllis putnik Jobu0101 Mbch331 Rogi Danrok Queryzo Mushroom Ermanon LydiaPintscher ValterVB== Active users == participants of WikiProject Movies Notified 07:51, 25 February 2018 (UTC)) talk (Queryzo is not useful, this was mainly made for 1:n relations, where n is between 2 and 5. (P361)part of This is not the point, every episode can have an item, we do this per bot and hand, but: adding dozen of reverse relations to fullfill the constraints of 00:37, 25 February 2018 (UTC)) talk (Danrok: That's not necessarily a good reason. Why? Because we do not have items for each episode of The Bill. Until we do, then the problem doesn't exist. Which begs the question should we be creating an item for every TV episode ever made? If so, who will be doing all that work? Queryzo@ 19:34, 23 February 2018 (UTC)) talk (LydiaPintscherI've stumbled upon this too when cleaning up constraint violations. I think a separate property here makes sense. -- 22:07, 18 February 2018 (UTC)) talk (Queryzo, normal seasons have up to 22 episodes. This is no useful task and it is not good database modelling. (P527)has part(s) should have 104 items in (Q7717975)The Bill, series 5 This would mean, that f.e. 19:30, 18 February 2018 (UTC)) talk (DanrokCan you explain why you feel part of/has part "is not suitable for seasons with a lot of episodes"? 12:08, 18 February 2018 (UTC)) talk (EscuderoI don't know why we haven't yet that property. I totally agree, we need spececific properties for a better description. 21:47, 24 February 2018 (UTC)) talk (Queryzo. Wikidata:Property proposal/Creative work#Season: I now added LydiaPintscher, Danrok, Escudero@08:39, 5 March 2018 (UTC) Jura--- KrBot should do it in a couple of days. 08:30, 5 March 2018 (UTC)) talk (Queryzo: Could you do this? Pasleim to the new property. @(Q3464665)television series season with items of type (P179)part of the series / (P361)part of was created, we now should move all statements (P4908)season As 15:00, 7 March 2018 (UTC) Jura--- as well. (P577)publication date could be moved to (P1191)date of first performance has done most of it already. To fix these items, maybe Edgars2007Looks like 01:31, 8 March 2018 (UTC) Jura--- There are few indeed. The query for the single value constraint on the property talk page lists them. 20:34, 7 March 2018 (UTC)) talk (Kam Solusar were also erroneously moved. --(Q21664088)two-part episode , the statements indcating that those episodes are part of a (Q48668741)A Voice in the Wilderness: Part 2 and (Q48668572)A Voice in the Wilderness: Part 1 Though it seems not only those part-of statements regarding seasons were moved to season statements. In 12:37, 6 March 2018 (UTC)) talk (Infovarius (of the series itself)? --(P361)part of or (P179)part of the series And for seasons should we still use For the record, I used this query
Use at
- https://query.wikidata.org/sparql
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX wd: <http://www.wikidata.org/entity/>
select distinct ?item { ?item wdt:P31/wdt:P279* wd:Q21191270 .
?item wdt:P361 ?season .
?season wdt:P31 wd:Q3464665 .}
limit 10000