Members of DayOfWeek should belong to the schema.org ontology

[betehess]

For some reason, it's still relying on http://purl.org/goodrelations/v1#.

Would the following snippet something we want to support?

"openingHoursSpecification": [
  {
    "@type":"OpeningHoursSpecification",
    "dayOfWeek": [
      "Monday",
      "Tuesday",
      "Wednesday",
      "Thursday",
      "Friday",
      "Saturday"
    ],
    "opens":"09:00",
    "closes":"21:00"
  }
]

[mfhepp]

The pattern is supported.
When we integrated GoodRelations into schema.org, we decided to leave the enumerated values in their original namespace. IMO, they work fine as they are and are properly listed in http://schema.org/DayOfWeek.

I would rather not include all enumerations from GR into schema.org; it just expands the size of the vocabulary.

[betehess]

The pattern is supported.

What do you mean? We can use Text instead of GoogleRelations' URIs?
It's really not clear to me which values are actually accepted/acceptable when I look at the documentation.

[mfhepp]

No, you should use GoodRelations URIs.
But even if we added the enumeration to schema.org, you would have to use the full URLs, afaik.

[Aaranged]

FWIW Google's initially-released specifications for use of this property on their Local Business overview page specified the expected value as text, and provided an example which reflected this.

I say "intially-released" as the page, which initially returned a 404 from the link that appeared in the Google Developers Structured Data site, is now again returning a 404, so the screenshot displayed below is derived from the Internet Archive copy of Dec. 3, 2015. It, of course, remains to be seen whether they'll used the plain text enumerations as pictured when they reactivate the pages or modify this to use the GR URIs.

[betehess]

@Aaranged Google's Local Business is actually what triggered this issue :-) (and that's where the snippet was coming from)

Note that we could improve the situation a little bit by adding "dayOfWeek": {"@type": "@id"} in the JSON-LD context. And as GoodRelations is already defined there as a prefix, we would then be able to say "gr:Monday". In RDFa, gr is a predefined prefix so it would be the same.

That being said, I am not sure I like this approach. My background is RDF and I personally don't mind using several ontologies at the same time. But the appeal in Schema.org is that we do not need to do that. So I would prefer not relying on external ontologies for important things.

I would rather not include all enumerations from GR into schema.org; it just expands the size of the vocabulary.

In practice, as soon as Schema.org links to GoodRelations, people have to consider the union of the two ontologies.

In any case, I expect OpeningHoursSpecification/DayOfWeek to be a widely used feature so simplicity will be important for adoption. So my proposal is to add the 7 days as instances in Schema.org itself.

[Aaranged]

So my proposal is to add the 7 days as instances in Schema.org itself.

+1. I don't think this is an enumeration that's going to get out of hand, as I doubt we'll see a week ever consisting of more than these seven days. :)

Failing this, a) usage of DayOfWeek should be supported with an example; b) documentation on enumerations should be added to schema.org documentation.

IMO b) should be pursued regardless of what's done with this specific enumeration. Adding enumerations is anything but intuitive, and better documentation would assist webmasters in providing better markup. Confusing matters further is that the blog post on external enumerations is linked from the documention page. This might lead one to believe this is general information on how to use enumerations while its subject matter is, of course, how to use enumerations when they don't exist in the schema.org core.

[danbri]

I would support adding Monday/Tuesday/Wednesday/Thursday/Friday into schema.org. These are common and useful concepts. Doesn't mean we would need to bring in all the other GR enumerations.

At this stage I can only offer anecdata, but it feels like webmasters often mess up with the idea of enumerated property values being URLs, and we'll often see "True" or "true" in published data instead of the URL http://schema.org/True. One possible cleanup rule that schema.org consumers might need could be: "if a string value, e.g. "True" is unexpected and found where an enumeration is expected, and if the string exactly matches a term from within that enumeration, then fix it to the appropriate URL".

So if you find an http://schema.org/isAccessibleForFree property and its value is "foo", you don't know what to do with it. But if you find "True", then normalizing it to be the URL http://schema.org/True would seem reasonable. We could do this more easily for days of the week if they were internally enumerated within the site.

Whether we really want to get into writing down such hacks is another matter, however I will note the precedent in http://schema.org/docs/datamodel.html which already sets and expectation that consumers will figure out how to accept 'strings' where 'things' ought really to be provided:

The site currently says:

• While we would like all the markup we get to follow the schema, in practice, we expect a lot of data that does not.
• We expect schema.org properties to be used with new types.
• We also expect that often, where we expect a property value of type Person, Place, Organization or some other subClassOf Thing, we will get a text string.
• In the spirit of "some data is better than none", we will accept this markup and do the best we can.

For non-enumerable things like Country, Person etc it is not obviously clear how to take a string and get an URL; for enumerated things like True, False we could choose to be more explicit.

[betehess]

it feels like webmasters often mess up with the idea of enumerated property values being URLs

That's also my experience.

One possible cleanup rule that schema.org consumers might need could be: "if a string value, e.g. "True" is unexpected and found where an enumeration is expected, and if the string exactly matches a term from within that enumeration, then fix it to the appropriate URL".

Let's look at https://developers.google.com/structured-data/local-businesses/. The documentation says that dayOfWeek expects a Text while Schema.org would expect a URL in some enumeration somewhere. Now, let's say that another search engine wants to support LocalBusiness too. Should they go with Text as well to achieve better interop because of Google's implementation? What if they want to only support URLs are defined in Schema.org?

If Google really wants to promote the use of Text for dayOfWeek, we could at least define DayOfWeek as an RDF datatype. I am not against that. As somebody who wants to ship structured data, I would prefer to work against the standards, not a specific implementation.

[danbri]

Picking this up again, ...

I propose 1.) we add 'Monday' through 'Sunday' as enumerations into schema.org. 2.) that schema.org documents (in datamodel.html or some other way) a standard way for the long URIs of its enumerated values to be written instead as simple strings based on the last part of the URI.

[betehess]

Picking this up again, ...

Thanks :-) It's hard to have an idea of priorities around here...

I propose 1.) we add 'Monday' through 'Sunday' as enumerations into schema.org. 2.) that schema.org documents (in datamodel.html or some other way) a standard way for the long URIs of its enumerated values to be written instead as simple strings based on the last part of the URI.

What do we actually gain by having days as URIs? Especially if you say that we should use simple String instead. It seems to me that datatypes already do that job very well e.g. schema:Boolean. That way, tools (e.g. checkers) don't need separate logic.

So my proposal is to fully embrace the use of well-defined strings by

• making schema:DayOfWeek of type schema:DataType and an RDF datatype
• the range of accepted values would be "Monday", "Tuesday", etc.
• the JSON-LD context would use type coercion e.g. dayOfWeek: { "@type": "schema:DayOfWeek" }

That is basically standardizing Google's own implementation for dayOfWeek and making the JSON-LD examples valid wrt schema.org.

[danbri]

@betehess - re priorities, as with all consensus-oriented collaborative projects it is easier to discuss rough goals than to successfully predict exact timelines. Historically all changes to the site have been by consensus of the full steering group based on public discussion and debate. We usually lose some momentum around vacation periods but http://schema.org/docs/releases.html should give a rough feel for the typical pace.

As for progress on a particular topic, that depends on someone championing an issue - as you're doing here. When you put together your analysis late last year I added it to the issue tracking our next release - #911 (these are findable via #1). How much of that we manage to cover depends on how much agreement we can achieve here. I'll respond to the technical points separately.

[vickitardif]

My experience is similar to @betehess's; while namespaces make sense to folks with RDF backgrounds, many authors get confused. For clarity, we should add the days of the week values to schema.org. (I am not advocating adding all of GoodRelations. To @mfhepp's point, that is a lot of new vocabulary.)

I am not sure there is much to be gained by creating a datatype. At the end of the day, even with well-defined values, authors will confuse them, so automated tools need to be somewhat liberal in understanding "Monday", "monday", "MONday", and "http://schema.org/Monday" are the same thing.

[akuckartz]

It would be great if accessing http://schema.org/Monday results in a skos:Concept which includes translations.