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

Monday (Q105)

edit

opening time

08:00 (Q55811455)

closing time

17:00 (Q55811883)

0 references

add reference

Wednesday (Q128)

edit

opening time

08:00 (Q55811455)

closing time

22:00 (Q55813122)

0 references

add reference

add value

Museum of Dead Wikidata Proposals[edit]

Monday to Friday (Q97120402)

edit

opening time

11:00 (Q55811097)

closing time

17:00 (Q55811883)

closed on (P3026)	Tuesday (Q127)
	public holiday (Q1197685)

0 references

add reference

add value

Eccentric Bazaar of Most Ancient and Mystical WikiFauna Artifacts[edit]

first weekend of June (Q34321176)

edit

opening time

sunrise (Q193294)

closing time

sunset (Q166564)

0 references

add reference

edit

opening time

00:00 (Q55812411)

closing time

11:30 (Q55811133) (lunch break)

0 references

add reference

edit

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]

Monday (Q105)

edit

opening time

closing time

opening period from

open period to

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)[reply]

Discussion[edit]

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)[reply]
Support I like it, although there is not a direct compatibility with Wikivoyage. A translator for that needs to be coded --★ → A ir on 90 07:17, 27 August 2020 (UTC)[reply]
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)[reply]
- 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)[reply]
  - 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)[reply]
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)[reply]
- 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)[reply]
  - The rush that involves another proposal, before an RfC. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:00, 27 August 2020 (UTC)[reply]
    - 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)[reply]
      - 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)[reply]
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)[reply]
- 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)[reply]
- 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)[reply]
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)[reply]
@RolandUnger: maybe you want to comment, given your earlier feedback --- Jura 09:47, 28 August 2020 (UTC)[reply]
Support Sturm (talk) 13:02, 28 August 2020 (UTC)[reply]
Support Robin van der Vliet (talk) (contribs) 18:11, 31 August 2020 (UTC)[reply]
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)[reply]
~~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)[reply]
- I think your proposal above sounds good but we might want to first make sure we actually have a use case for it within Wikidata. If we can find some 3 examples, I'm sold. NMaia (talk) 17:44, 2 September 2020 (UTC)[reply]
- If start/end of the season varies every year, then realistically should we expect Wikidata to contain the exact date? For very notable places like Eiffel Tower (Q243) we could include each year's opening/closing time. For the rest, we could include opening/closing for summer (Q1313) and winter (Q1311) (or more local items such as winter in Sweden (Q18061850) or wet season (Q3117517)). As the previous comment says, would you mind finding 3 real-world examples of seasonal outfits where the start/end of the season may vary? Then we can see how well the structure fits. Thanks! :-) Syced (talk) 03:05, 3 September 2020 (UTC)[reply]
  - These real world examples are easy to find as most ski resorts operate this way: for example Skigebiet Kahler Asten (Q16604141), ski resort Gaissau-Hintersee (Q2292227) (see https://www.skiresort.info/ski-resort/gaissau-hintersee/ which states "General season: mid December - mid March Opening times: 09:00 - 16:00 "), Ski resort Nauders (Q2292235), Ski Arlberg (Q21040821). Overall there are over 1200 instances of https://w.wiki/bE3 ski resort (Q130003) that are open seasonally (almost all of them). The same is true for fishing resorts that are open in the summer only and many other seasonal industries. I am not saying we need to solve this problem right now but I am saying that (i) this will come eventually and (ii) it makes us incompatible with https://schema.org/OpeningHoursSpecification which I think is the bigger issue. --Hannes Röst (talk) 19:30, 3 September 2020 (UTC)[reply]
    - @Hannes Röst: If this can't be solved using open period from (P3027) and open period to (P3028) I'd support new properties to handle it, if you propose them. I feel like this a discussion that goes beyond the scope of the current proposal, though. NMaia (talk) 10:30, 4 September 2020 (UTC)[reply]
    - @Hannes Röst: Focusing on the ski resort Gaissau-Hintersee (Q2292227) example, would that work? https://commons.wikimedia.org/wiki/File:Proposal_to_express_opening_times_of_Q2292227.png If not, would you mind expressing the hours with schema.org so that we can then try to translate them to Wikidata format? Thanks! Syced (talk) 15:28, 5 September 2020 (UTC)[reply]
      - @Syced, NMaia: yes I think that would work, thus we would map open period from (P3027) and open period to (P3028) to validFrom/validThrough and the new proposed properties to opens/closes while dayOfWeek will map to open days (P3025). Seems to work well, but it needs to be documented so that people use it correctly. --Hannes Röst (talk) 18:06, 6 September 2020 (UTC)[reply]
@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)[reply]
- 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)[reply]
- @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)

Wednesday (Q128)

edit

opening time

closing time

0 references

add reference

Thursday (Q129)

edit

opening time

closing time

0 references

add reference

Friday (Q130)

edit

opening time

closing time

0 references

add reference

Saturday (Q131)

edit

opening time

closing time

0 references

add reference

Sunday (Q132)

edit

opening time

closing time

0 references

add reference

add value

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

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)[reply]
@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)[reply]
- Can we see a query? --- Jura 10:36, 4 September 2020 (UTC)[reply]
  - I wouldn't know, sorry. Perhaps the good folks at WD:RAQ would know? NMaia (talk) 10:40, 4 September 2020 (UTC)[reply]

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)[reply]

Probably the lunch break example should be done like this to be machine parseable:

first weekend of June (Q34321176)

edit

opening time

sunrise (Q193294)

closing time

sunset (Q166564)

0 references

add reference

edit

opening time

00:00 (Q55812411)

closing time

11:30 (Q55811133) (lunch break)

0 references

add reference