Wikidata:Property proposal/opening hours (v.3)

opening hoursEdit

opening timeEdit

Originally proposed at Wikidata:Property proposal/Generic

   Done: opening time (P8626) (Talk and documentation)
Descriptiontime when an establishment or attraction opens, qualifier for P3025
Data typeItem
Example 1See below
Example 2.
Example 3.

closing timeEdit

Originally proposed at Wikidata:Property proposal/Generic

   Done: closing time (P8627) (Talk and documentation)
Descriptiontime when an establishment or attraction closes, qualifier for P3025
Data typeItem
Example 1See below
Example 2.
Example 3.

MotivationEdit

Taking into account the previous proposals (here and here), I've adapted Thryduulf's suggestion to create a new attempt at getting this much-needed information on Wikidata.

Here are some theoretical examples:

WikiCafé, strangely only open twice a weekEdit
open days (P3025)
  Monday (Q105)
opening time 08:00 (Q55811455)
closing time 17:00 (Q55811883)
0 references
add reference
  Wednesday (Q128)
opening time 08:00 (Q55811455)
closing time 22:00 (Q55813122)
0 references
add reference


add value
Museum of Dead Wikidata ProposalsEdit
Eccentric Bazaar of Most Ancient and Mystical WikiFauna ArtifactsEdit
open days (P3025)
  first weekend of June (Q34321176)
opening time sunrise (Q193294)
closing time sunset (Q166564)
0 references
add reference
  sixth Monday in February (Q16324523)
opening time 00:00 (Q55812411)
closing time 11:30 (Q55811133) (lunch break)
0 references
add reference
  sixth Monday in February (Q16324523)
opening time 15:15 (Q55811726) (returning from lunch)
closing time 23:59 (Q55812369)
0 references
add reference


add value
ski resort Gaissau-Hintersee (Q2292227)Edit
open days (P3025)
  Monday (Q105)
opening time 9 AM (Q41618181)
closing time 16:00 (Q55812393)
opening period from December 15 (Q2383)
open period to March 15 (Q2403)
0 references
add reference


add value

The advantage of using item-datatypes is that you can use non-numeric concepts like sunrise and sunset. Overall I think this proposal is very good, and Wikivoyage in particular should benefit from it.

Pinging those involved in previous discussions: @T.seppelt, K7L, Thryduulf, ArthurPSmith, Jura1, Pigsonthewing, @Srittau, Izno, Syced, Lymantria. NMaia (talk) 02:40, 27 August 2020 (UTC)

DiscussionEdit

  •   Support Hours is a nice addition to the existing open days (P3025). I know it is obvious, but maybe mention that the hours are relative to the located in time zone (P421) value of the item itself or if none the first item that has one going up its located in the administrative territorial entity (P131) chain. Syced (talk) 05:12, 27 August 2020 (UTC)
  •   Support I like it, although there is not a direct compatibility with Wikivoyage. A translator for that needs to be coded --★ → Airon 90 07:17, 27 August 2020 (UTC)
  •   Support I'm here for the museum! Not an expert on the subject matter, but hopefully we can play nice with https://schema.org/openingHours and the schema.org opening hours specification ? Moebeus (talk) 08:56, 27 August 2020 (UTC)
    • It should be fairly simple to link the properties to opens and closes using equivalent property (P1628). NMaia (talk) 10:31, 27 August 2020 (UTC)
      •   Comment @NMaia: however what this does not allow is to model validFrom and validThrough, e.g. what if something is open from 8am-6pm from July 14th to September 8th? With this proposal we would have to have 365^2 items to model all possible combinations of days which is not really feasible. Maybe two more properties are needed for these edge cases ("open day" and "closing day"). This will often happen for seasonal outfits, such as Ski resorts. --Hannes Röst (talk) 16:09, 2 September 2020 (UTC)
  • As previously: Oppose all for now. We should hold an RfC on opening hours, examining case studies and prior art, before rushing to create properties. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:31, 27 August 2020 (UTC)
    • What rush? This has been sitting around for four years. If there was any interest in the community to have an RfC held, it would have been done already. This, on the other hand, is a workable solution. NMaia (talk) 11:58, 27 August 2020 (UTC)
      • The rush that involves another proposal, before an RfC. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:00, 27 August 2020 (UTC)
        • How is a property proposal not a "request for comments"? That's what we're doing here, this complaint smacks of needless bureaucracy. If you have specific prior art concerns then give us relevant links here. ArthurPSmith (talk) 17:27, 27 August 2020 (UTC)
          • No, its not an RfC, its a request for approval for a specific model. I've given examples of prior art - which this proposal ignores - in response to previous proposals for this property, to which I have referred above. If there is "needless bureaucracy", it is to keep expecting me to repeat them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:58, 20 September 2020 (UTC)
  •   Oppose This ignores timezones. I oppose the usage of such annoying seconds items – either a Wikibase support for time and timezones or no opening hours. And for the more irregular opening hours the proposal does not clarify when open days (P3025) overrides a prior closed on (P3026) qualifier, i.e. when is it open and when closed given opening hours in this format. And lastly is there a way to say that no opening hours for public holiday (Q1197685) were specified, similar to the PH unknown in OSM opening hours syntax? --CamelCaseNick (talk) 14:05, 27 August 2020 (UTC)
    •   Comment Wouldn't the timezone be implied to be the local one? I can't think of a situation where it would be something else. As for the seconds, I don't think any establishments actually have such precise hours, I was simply trying to show the flexibility of this system (but to avoid confusion, I'll amend the proposal). Regarding the unknown, if we editors don't know, what value is there in expressing it? It doesn't really help anyone. NMaia (talk) 16:49, 27 August 2020 (UTC)
    • Putting a timezone here would be a very bad idea. The item itself is already in a timezone, which is defined either in the item itself or in its located in the administrative territorial entity (P131) (recursive). Re-stating the timezone here would be a duplication of information, increase the burden of maintenance, and create vast amounts of stale data. Syced (talk) 04:45, 28 August 2020 (UTC)
  •   Support This looks fine to me, using items should allow any edge case to be handled. If we need to specify timezones for some reason, we can create items for times with timezones, that doesn't seem to be a fundamental issue here. ArthurPSmith (talk) 17:26, 27 August 2020 (UTC)
  • @RolandUnger: maybe you want to comment, given your earlier feedback --- Jura 09:47, 28 August 2020 (UTC)
  •   Support Sturm (talk) 13:02, 28 August 2020 (UTC)
  •   Support Robin van der Vliet (talk) (contribs) 18:11, 31 August 2020 (UTC)
  •   Weak support Opening times would be a great addition. This proposal seems reasonable proposal even if I'm not sure if all normal edge cases can be handled. --Haansn08 (talk) 09:30, 1 September 2020 (UTC)
  •   Weak support   Support and time zone can always be added with located in time zone (P421) for cases where its unclear (or items without a geographical location). I think this should cover 99% of the cases. However, what about seasonal outfits where the start/end of the season may vary (see comment above)? --Hannes Röst (talk) 16:09, 2 September 2020 (UTC)
  • @NMaia: this is your proposal right? Syced seems to have interpreted your comment as suggesting we need 3 real-world examples here. I suppose that might be a good idea rather than these fictional ones... would you mind? Otherwise I would have marked this as ready to create. ArthurPSmith (talk) 17:09, 3 September 2020 (UTC)
    • Can we wait a few days until compatibility with schema.org is discussed and a decision regarding seasonal opening/closing is reached? --Hannes Röst (talk) 19:30, 3 September 2020 (UTC)
    • @ArthurPSmith: Would one example be okay? These are really time-consuming to make and I think we all know they won't be much different. I'd rather spend that time adding the informations to the entries themselves. See below.
SOJO (Q28804296)
open days (P3025)
  Wednesday (Q128)
opening time 05:00 (Q55810695)
closing time 21:00 (Q55812716)
0 references
add reference
  Thursday (Q129)
opening time 05:00 (Q55810695)
closing time 21:00 (Q55812716)
0 references
add reference
  Friday (Q130)
opening time 05:00 (Q55810695)
closing time 21:00 (Q55812716)
0 references
add reference
  Saturday (Q131)
opening time 05:00 (Q55810695)
closing time 21:00 (Q55812716)
0 references
add reference
  Sunday (Q132)
opening time 05:00 (Q55810695)
closing time 21:00 (Q55812716)
0 references
add reference


add value

I've also addressed Röst's concern above. NMaia (talk) 10:30, 4 September 2020 (UTC)

  • The "returning from lunch" sample with the same qualifier twice might make it difficult to calculate if a place is open at a given time. --- Jura 20:04, 3 September 2020 (UTC)
  • @Jura1: In concrete terms, how could it be a problem? It seems easy enough to be parsed by a machine. NMaia (talk) 10:30, 4 September 2020 (UTC)
    • Can we see a query? --- Jura 10:36, 4 September 2020 (UTC)
      • I wouldn't know, sorry. Perhaps the good folks at WD:RAQ would know? NMaia (talk) 10:40, 4 September 2020 (UTC)
When in a single day there are several different interval at which the place is open, how about using time interval (Q186081) for each of these intervals? Jura, you have a lot of experience, do you think that would work? It would make SPARQL queries easy to write, I believe. When there is only one interval, I would suggest skipping the time interval (Q186081), though. Screenshot of my sandbox experiment on the right (using dates instead of hours but the idea is the same). Syced (talk) 15:30, 4 September 2020 (UTC)
Probably the lunch break example should be done like this to be machine parseable:
open days (P3025)
  first weekend of June (Q34321176)
opening time sunrise (Q193294)
closing time sunset (Q166564)
0 references
add reference
  sixth Monday in February (Q16324523)
opening time 00:00 (Q55812411)
closing time 11:30 (Q55811133) (lunch break)
0 references
add reference
  sixth Monday in February (Q16324523)
opening time 15:15 (Q55811726) (returning from lunch)
closing time 23:59 (Q55812369)
0 references
add reference


add value
what do you think? --Hannes Röst (talk) 21:59, 4 September 2020 (UTC)
Ah yes great idea, better than introducing time interval (Q186081), thanks a lot! It is also easier to query in SPARQL. NMaia, would you mind replacing in the proposal? Syced (talk) 00:48, 5 September 2020 (UTC)
@Hannes Röst, Syced: Done. NMaia (talk) 01:19, 5 September 2020 (UTC)

@NMaia, Syced, Airon90, Moebeus, Hannes Röst: @Pigsonthewing, ArthurPSmith, CamelCaseNick, Jura1, Sturm: @Robin van der Vliet, Haansn08:   Done opening time (P8626) and closing time (P8627) Pamputt (talk) 05:36, 21 September 2020 (UTC)