Days of week and special/closing OpeningHoursSpecification

[betehess]

This is an actual proposal to tackle #245 and #921 (and possibly other issues). Please keep in mind that this is my first PR against Schema.org so I have probably missed a few things.

This adds 7 instances for each day of the week. References to GoodRelations in the docs and the examples should have been updated.

I tried to keep the current semantics as intact as possible. The "closing day" and "late night" use-cases are addressed by refining the definition of OpeningHoursSpecification. Special opening hours overriding typical opening hours are possible through the new specialOpeningHoursSpecification property.

A few remarks:

• I didn't find a way to order Enumeration Members in the produced HTML, so DayOfWeek members don't follow the natural order
• I don't understand how the JSON-LD context is managed so one example has an explicit "dayOfWeek": { "@type": "@id" } in its context while that should be the default

[betehess]

Another remark: I am not sure why but the range for openingHours is LocalBusiness while the range for openingHoursSpecification is Place. So specialOpeningHoursSpecification follows the same range as for openingHoursSpecification. If there is no objection, I could have all 3 properties having Place as their range.

[mfhepp]

Thanks for the proposal! However, I think the "opening hours" branch of schema.org is a non-trivial challenge and I suggest that we try to first work on a comprehensive solution to the pending challenges instead of an incremental approach with quick fixes, because quick fixed will likely constrain our redesign.

[betehess]

@mfhepp I understand the concern re: quick fixes.

I have tracked down the issues/use-cases around opening hours and found the following:

• late night hours OpeningHoursSpecification for a place that is open past midnight #534
• closing days Provide a way to specify a location is temporarily open/closed #819 Issue #819: Added openingHoursStatus and corresponding enumeration. #824 +1 ClosingDaysSpecification Type #372
• special opening hours schema.org has two ways to represent openingHours - need unified documentation and cornercase tweak #245
• syntax for openingHours wrt HTML5 Examples on openingHours should not use the 'time' element #143 schema.org has two ways to represent openingHours - need unified documentation and cornercase tweak #245
• day of the week instances Members of DayOfWeek should belong to the schema.org ontology #921 CategoryCode Proposal (formerly EnumerationValue Proposal) #894
• openingHours vs openingHoursSpecification schema.org has two ways to represent openingHours - need unified documentation and cornercase tweak #245 Meta bug for expressivity and syntax issues around opening/closing hours #186
• explicit opening day approach vs "typical/general opening hours, to allow for exceptions"

The reported usage statistics on the website say

• "Between 100,000 and 250,000 domains" for openingHours
• "Between 10,000 and 50,000 domains" for OpeningHoursSpecification
• "Between 1000 and 10,000 domains" for DayOfWeek

So I guess the questions are:

• do we really need a "redesign" here?
• what are the guidelines for revising and deprecating existing parts of the ontology?
  • what can be deprecated in the context of "opening hours"? Anything?
• is this very proposal addressing the issues identified at this time?
• who is working on a proposal?

[betehess]

Not sure what to do with that... Does anybody really care? I mean, there's been open issues around openingHours for quite some time now and all proposals have been shut down and abandoned. In the meantime, folks are shipping an implementation that is not aligned with the current state of the ontology, without really discussing with the community (or I don't know where conversations are happening).

So we have several options from here:

• we let those guys experiment on their own, we wait for them do be done, then people start deploying data, and we eventually fix the ontology to reflect what was done
• or we try to fix the issues now by working together, if possible by inviting the people actually shipping products to the party

In my opinion, Google's approach is simple, elegant, and answers most of the issues listed above. No surprise this PR mostly reflects that. The only difference is about DayOfWeek, which could be adapted to Google's approach by making it a http://schema.org/DataType and by updating the JSON-LD context so that Text will be correctly coerced to DayOfWeek. I am more than happy to continue working on the proposal but only if I have a sense that there is some interest. Otherwise, I'll just stick with Google's implementation and stop worrying about standardizing in Schema.org.

[danbri]

Nudging this thread. See also #245 and #921 comments.

@mfhepp - w.r.t. comprehensive solution, which issues would you seek to address beyond those identified by @betehess ?

Opening Hours are worth a bit of polish without overloading that task with defining an entirely general purpose scheduling mechanism. There may be other related usecases we can address later more comprehensively for other kinds of repeating schedule...

[danbri]

Reviewing this i.e. http://schema.org/Monday rdfs:label: Monday, rdfs:comment: The first day of the week.

... can we come up with a better description of "Monday"? It is not a strong convention to count from Monday = 1.

E.g. from http://www.timeanddate.com/calendar/days/

    Monday or Sunday first day of the week?
    The first day of the week varies all over the world. In most cultures, Sunday is regarded 
    as the first day of the week although many observe Monday as the first day of the week. 
    According to the Bible, the Sabbath or Saturday is the last day of the week which marks 
    Sunday as the first day of the week for many Jewish and Christian faiths, while many 
    countries regard Monday as the first day of the week.

    According to the international standard ISO 8601, Monday is the first day of the week 
    ending with Sunday as the seventh day of the week. Although this is the international 
    standard, countries such as the United States still have their calendars refer to 
    Sunday as the start of the seven-day week.

I quite like the way Wikipedia ground https://en.wikipedia.org/wiki/Monday - i.e. as being between Sunday and Tuesday. I would also like (in the machine-readable representation) to associate Monday with https://www.wikidata.org/wiki/Q105 and so on, both to build up our links with Wikidata and to get multilingual labels for all these items.

[betehess]

I quite like the way Wikipedia ground https://en.wikipedia.org/wiki/Monday

Very good remark. I have updated the PR accordingly.

I would also like (in the machine-readable representation) to associate Monday with https://www.wikidata.org/wiki/Q105 and so on

I have done something like that:

<span>Same as: <a property="schema:sameAs" href="http://www.wikidata.org/entity/Q105">Monday</a></span>

Is that the right approach?

[danbri]

re sameAs, we haven't made a mapping to wikidata URIs before, but that looks plausible. Perhaps better to use the https variant, though I'm not sure which they consider the most canonical URI. - i.e. https://www.wikidata.org/wiki/Q105

[betehess]

I'm not sure which they consider the most canonical URI.

That's the Concept URI (bottom left link of the Wikidata page), which gets redirected to the page URL when in a browser. Note the entity vs wiki in the path.

[danbri]

I meant http versus https versions of the entity URI

[betehess]

@danbri the entity URI really is the http version, even if the https one resolves.

The statement <https://www.wikidata.org/entity/Q105> ?p ?o won't match anything on https://query.wikidata.org.

[betehess]

That being said, I am still not happy with my PR because of https://github.com/schemaorg/schemaorg/pull/923/files#diff-473245f5cdaf7ff4e5dd3462e1a62bbcR180 . I still don't understand how/where I can modify the JSON-LD context :-/

[betehess]

@danbri @mfhepp I have rebased the PR, it's ready for another look.

Note that I still don't understand where the JSON-LD context for schema.org is managed so this is not part of the PR (yet?).

[jaygray0919]

Have the same concern. For our applications, it's important to know version changes. We don't use @vocab, but instead use the precise term in our @context. Therefore, also would like to know how JSON-LD context for schema.org is managed.

[danbri]

Re JSON-LD context, the trick we use currently is that properties that have a domainIncludes of URL (alongside potentially others) get treated as expecting "@id" from a JSON-LD perspective. That catches the common case of relative URI references, where you don't want a dangling "../news/more.html" text value to end up in the parsed output instead of a full URI. The context is entirely generated from the master schemas in data/ but the exact structure has been evolving as we figure things out. The most recent change (this week) #990 should be both harmless and useful: we just take care to associate all schema.org terms with the schema.org vocabulary explicitly, so that our context file can be mixed in alongside others without confusion. This came out of collaboration with GS1 towards http://gs1.org/voc/ and the issues were not apparent when the context file implementation was first put together.

[danbri]

I have merged this (thanks @betehess !) and made some modest tweaks to the description. Also carried over the public holiday type from GR.

What happened to the idea of specialClosingDay - should that be spec'd and added too?

[danbri]

Closing per http://webschemas.org/docs/releases.html#g923 (but ping re specialClosingDay)

[betehess]

Also carried over the public holiday type from GR.

@danbri I fail to understand how PublicHolidays actually works, and why it was even needed. I failed to find discussions asking for it to be added in here. It makes http://webschemas.org/DayOfWeek look really weird.

In practice, I am not sure a OpeningHoursSpecification will ever be able to be applied to all PublicHolidays, which are highly locale-dependent. A schema.org consumer would always lack that important information: which are the public holidays for the context in which PublicHolidays was used?

Maybe an example would help?

But until this is figured out, can we remove it from sdo-deimos? I don't think PublicHolidays was addressing any urgent use-case anyway.

[betehess]

What happened to the idea of specialClosingDay - should that be spec'd and added too?

This is already handled with the combination of OpeningHoursSpecification and specialOpeningHoursSpecification.

• http://webschemas.org/OpeningHoursSpecification says "The place is open if the opens property is specified, and closed otherwise."
• and http://webschemas.org/specialOpeningHoursSpecification lets you override typical hours

[danbri]

Ok, great, just wanted to make sure. If you've time to look over the changes that have been merged in, that would be great. Extra sanity checks are always useful!

[betehess]

@danbri I did (not just my contributions), and everything else looks good!

[danbri]

Thanks for checking!

Re PublicHolidays, indeed it seemed under-discussed, but on the basis that we are replacing a structure that has been in place since 2012 (http://blog.schema.org/2012/11/good-relations-and-schemaorg.html). I wanted to make the new schema.org URLs a drop-in replacement for the GoodRelations ones. If we want to deprecate that construction we can work out a design for doing so and make that clear in the /PublicHolidays documentation. But to just abruptly omit it without explanation would I think be even more confusing. I've filed an issue to track this at #1139