Property talk:P2257

From Wikidata
Jump to navigation Jump to search

Documentation

event interval
standard nominal interval between scheduled or regularly recurring events. Include unit of time, e.g. "year" (Q577). 1/(event frequency). time period of periodically occurring event
Representsrecurring entity (Q28314507)
Data typeQuantity
Domainrecurring event (Q15275719), sports league (Q623109), sports competition (Q13406554), award (Q618779), recurring sporting event (Q18608583), periodic phenomenon (Q47454914), light characteristic (Q1738955) or public transport itinerary (Q41103453)
Allowed valuespositive time values (note: this should be moved to the property statements)
Allowed unitsyear (Q577), month (Q5151), day (Q573), annum (Q1092296), quarter (Q1643308), week (Q23387), saeculum (Q4274161), minute (Q7727), bar (Q3240892), beat (Q654693), decade (Q39911), century (Q578), millennium (Q36507), calendar year (Q3186692), second (Q11574) or hour (Q25235)
Usage notesUse with unit of time, sample: year (Q577).
ExampleOlympic Games (Q5389) → 4 year
Gordon Bennett Cup in ballooning (Q1537962) → 2 year
Jersey Battle of Flowers (Q539642) → 1 year
Labour Force Survey (Q6467417) → 3 month
Tracking: usageCategory:Pages using Wikidata property P2257 (Q65079506)
See alsoduration (P2047), day in year for periodic occurrence (P837), publication interval (P2896)
Lists
Proposal discussionProposal discussion
Current uses
Total10,403
Main statement10,31499.1% of uses
Qualifier880.8% of uses
Reference1<0.1% of uses
[create Create a translatable help page (preferably in English) for this property to be included here]
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2257#Type Q15275719, Q623109, Q13406554, Q618779, Q18608583, Q47454914, Q1738955, Q41103453, SPARQL
No bounds: values can't have any bounds (e.g. 1 not 1±0) (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2257#No Bounds, SPARQL
Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2257#Entity types
Scope is as main value (Q54828448): the property must be used by specified way only (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2257#Scope, SPARQL

Discussion[edit]

How to deal with complex event frequencies?[edit]

Examples:

  1. a recurring event is held annually, but every fourth year there is regularly no edition
  2. a recurring event is held annually, but there have been some irregular exceptions in the past
  3. a recurring event is held annually for 100 years, with a break of 10 years in between
  4. ( …feel free to add other “complex” examples here… )

It is clear that we cannot capture all events and their exceptions with a single property. It would be nice, however, to have some guidelines for complex issues at hand here. Any ideas for the cases listed above? —MisterSynergy (talk) 17:09, 3 November 2015 (UTC)[reply]

This is intended to represent the standard nominal interval, so case 2 could be handled by either ignoring them as exceptions to the standard - e.g. the Winter Olympics had one instance of a 2 year interval as an exception to the standard 4 year interval; or by using start time (P580) as a qualifier.
For case three if you mean e.g. annually from 1900 to 2000 except no instances between 1940 and 1950, then I'd suggest using start time (P580) and end time (P582) as qualifiers for the earlier period and start time (P580) for the beginning of the second period. If you mean something different you'll need to try explaining again.
Case 1, I don't know what to suggest off the top of my head. Maybe we need some "except" or "does not apply to" properties as qualifiers? Perhaps event interval (P2257) → 1 year (Q577) qualifier "except" "olympic year" or for leap year (Q19828): event interval (P2257) → 10 year (Q577) qualifier "except" "century year" or census in the United Kingdom (Q5058981): event interval (P2257) qualifier "except" 1931 (Q18782). Thryduulf (talk: local | en.wp | en.wikt) 22:01, 3 November 2015 (UTC)[reply]
Thanks for your input. I think adding qualifiers start time (P580) and end time (P582) in conjunction with this one is a good idea in general (and in particular in case of exceptions like #3). This would also work when the cycle was changed e.g. from regular four-year to regularly annual cycle for some reason. However, since events are regularly held irregularly, we cannot expect perfect precision here… Any other ideas anyone? —MisterSynergy (talk) 06:21, 4 November 2015 (UTC)[reply]

Use for awards[edit]

Can we use this property for awards too? Label and constraints adjustments are needed then. Sjoerd de Bruin (talk) 08:59, 12 October 2016 (UTC)[reply]

Yes, I'd say that awards should be able to use this. I'm not sure where the "location" and "country" constraints came from, as they weren't in the proposal and have lots of violations so I'm tempted to just get rid of them. Most of the violations of the recurring event constraint are probably solvable by making a few more items subclasses of recurring event (e.g. festival). What do you propose for awards? Thryduulf (talk) 16:48, 13 October 2016 (UTC)[reply]
We just need to change the constraints and maybe the labels. I would like to have more input though. Sjoerd de Bruin (talk) 10:14, 27 October 2016 (UTC)[reply]

Remove country and location constraints[edit]

I suggest to remove the country and location constraint entirely. As the given exception Olympic Games (Q5389) indicates, there are recurring events that are held somewhere else with each edition, and it is not clever to list all of those cases in the constraint exceptions. There is also no need to enforce presence of such claims via contraints on unrelated properties. —MisterSynergy (talk) 06:00, 3 August 2017 (UTC)[reply]

  • I'm adding the property to a couple of items. Let's see how it goes. I do think reoccurring events would generally have a country/location and we should make sure it's defined. Obviously, it needn't be mandatory.
    --- Jura 06:10, 3 August 2017 (UTC)[reply]
  • I'm jumping into this conversation a few months later... I support removing these as mandatory constraints. There are far too many events that don't have a consistent location or sometimes even a consistent country. There are already 7 exceptions listed for both of these properties, but in reality there are far far more than that—it's not realistic to list them all. Just look at en:Category:World championships by sport... there are dozens or hundreds of pages in that category's sub-categories, and the majority of them are recurring events with no set location or country. –IagoQnsi (talk) 21:03, 30 March 2018 (UTC)[reply]
  • I strongly support removing country and location as constraint. It is not acceptable to add too many and infinite exceptions. --Neo-Jay (talk) 12:11, 6 May 2018 (UTC)[reply]
  • +1 for removal; these constraints make no sense. In no way is “something recurrent” intrinsically connected to “having a defined location and country”. --Mormegil (talk) 13:56, 11 July 2018 (UTC)[reply]
  • Another vote in favour of removing these constraints - I'm not even sure where they come from as they weren't in the property proposal or the discussion that approved it, and there isn't any discussion on this page about adding them. There are probably an equal number of recurring events that don't have a set location as those that do. Thryduulf (talk) 00:50, 27 November 2018 (UTC)[reply]
  • I've removed the constraints. Jc86035 (talk) 15:08, 29 November 2018 (UTC)[reply]

New qualifier[edit]

Please comment at Wikidata:Property proposal/modulo.
--- Jura 10:22, 15 February 2018 (UTC)[reply]

frequency or period?[edit]

@Jura1: If you look at the sample usage it is a period (Q2642727). If something occurs every 1st of February, 1*year is the period, a special time interval defining how often something occurs. It is not equal to frequency (Q11652) = 1/year = 317 μHz, and it is not equal to phase (Q185553) = 2*pi*1/12 with respect to the beginning of the year.--Debenben (talk) 14:25, 24 May 2020 (UTC)[reply]

@Jura1: No, sense#1 and sense#3 is kind of the same. Both these frequencies have the dimension 1/time. And sorry I miscalculated the time above, 1/year = 31.7 nHz.--Debenben (talk) 14:38, 24 May 2020 (UTC)[reply]
Of the samples for #1 reads "frequency of bus service has been improved from 15 to 12 minutes". I think this matches the use of P2257. --- Jura 14:43, 24 May 2020 (UTC)[reply]
No. The frequency improved from one bus every 15 minutes to one every 12 minutes. frequency = number of busses per time = rate of occurrence. 15 and 12 minutes is the time period = 1/(event frequency).--Debenben (talk) 15:00, 24 May 2020 (UTC)[reply]
The sample usage is simply wrong, it should be corrected.--Debenben (talk) 15:04, 24 May 2020 (UTC)[reply]
Maybe like this: The frequency of bus service increased because time between services decreased from 15 to 12 minutes.--Debenben (talk) 15:23, 24 May 2020 (UTC)[reply]
according to use (and examples) this property is about period. And many labels have such wording. So en-label (and fr too) should be adjusted to avoid ambiguity. --Infovarius (talk) 19:39, 25 May 2020 (UTC)[reply]
I changed a lot of labels to make this property a period. The Wiktionary example sentence also changed after I inquired about it here: https://en.wiktionary.org/wiki/Wiktionary:Tea_room/2020/May#frequency --Debenben (talk) 18:12, 29 May 2020 (UTC)[reply]
Well I understand the problem you have raised here, but the new labels are a poorly executed attempt to fix the issue. Can you please undo and sort out proper labels without a pseudo-physical "1 over frequency" notation? —MisterSynergy (talk) 18:17, 29 May 2020 (UTC)[reply]
In my opinion a poorly worded label is better than a wrong one and it might be helpful to keep something like "inverse frequency" as an alias to keep people from adding frequency as an alias again. German, English and French are the languages I speak reasonably well and for those I cannot think of a better wording right now.--Debenben (talk) 18:32, 29 May 2020 (UTC)[reply]
Even with the physically incorrect labels, users seem to understand the meaning of the property pretty well. Wikidata:Database_reports/Constraint_violations/P2257#"Units"_violations is not overly populated, and frequency units are not used at all. —MisterSynergy (talk) 19:04, 29 May 2020 (UTC)[reply]
It seems that the general contributor isn't really mislead by the name even if it has been deleted from the dictionary (oddly, something that seems possible at Wiktionary .. go figure).
Maybe a better label could be "interval". In any case, the past label should be preserved as alias. If the description isn't thought to make it sufficiently what it's about, please help improve that. --- Jura 09:27, 1 June 2020 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Property_talk:P2257&oldid=2105208110"