Re: Schema.org v3.3 release candidate for review

Found some easier to see use cases that Vicki is mentioning...

http://www.library.northwestern.edu/visit/hours/index.html

http://www.fnal.gov/pub/visiting/hours/

Places that have listed business operating hours (useful I guess with
corollary in Job Descriptions "our work time is 7am -10pm, but the front
doors open at 9am to the public)...along with public access hours.

+1 Maybe Joey has the best solution of all...just a new publicOpeningHours
 ...but the problem is that currently openingHours is actually considered
the publicOpeningHours ... so maybe we should say that in its
description...and create a new operatingHours (which doesn't have to be
limited to a place or business but ANY Thing.  This might even be useful
for devices later to note when they are ON or operational for signaling,
IoT, LPWAN, etc.

Thoughts on a new operatingHours and then just re-phrasing openingHours to
note that it's the hours open to the public ?

-Thad
+ThadGuidry <https://www.google.com/+ThadGuidry>


On Wed, May 24, 2017 at 1:46 PM Joey Gartin <joey@webdrvn.com> wrote:

> Can it be addressed similarly to how openingHours is addressed?
>  openPublicHours?  This is used on both LocalBusiness and CivicStructure
> objects.
>
> Joey Gartin
> Marketing Engineer
> joey@webdrvn.com
> (530) 276-8131 mobile
> <https://webdrvn.com/>
>
> On Wed, May 24, 2017 at 10:29 AM, Richard Wallis <rjw@dataliberate.com>
> wrote:
>
>> And how does one say it is not a public place?
>>
>> ~Richard
>>
>>
>> On 24 May 2017, at 18:35, Vicki Tardif Holland <vtardif@google.com>
>> wrote:
>>
>> In this case, having a property to flag if a Place is accessible by
>>> public visitors covers more ground than a Type AND is easier for publishers.
>>
>>
>> I don't follow. If they use multiple types, they can say it is a public
>> place and a park.
>>
>> And a boolean does not allow places like King's Chapel in Boston, which
>> is often publicly accessible, but not during church services.
>>
>> - Vicki
>>
>>
>> On Wed, May 24, 2017 at 10:19 AM, Thad Guidry <thadguidry@gmail.com>
>> wrote:
>>
>>> I did some digging and scenarios of True and False on this new
>>> publicAccess property on Place across some atypical Places.
>>> In the case of a boolean for "publicAccess" ...
>>>
>>> We have Park under CivicStructure but that's not always the case...Not
>>> all Parks are actually publicly accessible or even public, some are
>>> actually private but still name themselves a park.  Example of a famous one
>>> in New York City: https://www.google.com/search?q=gramercy+park+new+york
>>>
>>> In this case, having a property to flag if a Place is accessible by
>>> public visitors covers more ground than a Type AND is easier for publishers.
>>>
>>> Backtracking and agreeing with Martin and Richard on this particular
>>> property of publicAccess.
>>>
>>> -Thad
>>>
>>> On Wed, May 24, 2017 at 6:34 AM Martin Hepp <mfhepp@gmail.com> wrote:
>>>
>>>> I might miss the point, but I have a few concerns:
>>>>
>>>> 1. Substituting Boolean properties by types will work only if we have
>>>> full support for multi-typed entities in the major search engines. As soon
>>>> as there are adverse effects of making an entity multi-typed, we cannot
>>>> substitute a Boolean property by a new type.
>>>>
>>>> 2. Also, Boolean properties, like faceted classifications, allow us to
>>>> classify an object along multiple dimensions. As soon as we have a subclass
>>>> hierarchy, using types can quickly create at least confusion but often
>>>> inconsistencies.
>>>>
>>>> 3. From a theoretical perspective, qualitative properties and even
>>>> quantitative properties can also create a secondary type system.
>>>>
>>>> So in a nutshell, I think Boolean properties have their right if we
>>>> want to add a distinction or categorial information without messing with
>>>> the type hierarchy of the main type.
>>>>
>>>> Martin
>>>> -----------------------------------
>>>> martin hepp  http://www.heppnetz.de
>>>> mhepp@computer.org          @mfhepp
>>>>
>>>>
>>>>
>>>>
>>>> > On 24 May 2017, at 13:24, Richard Wallis <
>>>> richard.wallis@dataliberate.com> wrote:
>>>> >
>>>> > In most cases I agree with you.
>>>> >
>>>> > However in this case the boolean property was proposed to enable not
>>>> only the definition that a Place is open for publicAccess, but also a Place
>>>> is not open for publicAccess.
>>>> >
>>>> > This came from the enhancements to TouristAttraction proposals where
>>>> many places may well be still of interest regardless of if public access is
>>>> available or not; whilst that accessibility is still useful information.
>>>> Following the logic of defining a PublicPlace, would lead in this case to
>>>> creating a NonPublicPlace type to enable that capability which I believe is
>>>> even more clunky than the proposed boolean.
>>>> >
>>>> > ~Richard.
>>>> >
>>>> >
>>>> >
>>>> > Richard Wallis
>>>> > Founder, Data Liberate
>>>> > http://dataliberate.com
>>>> > Linkedin: http://www.linkedin.com/in/richardwallis
>>>> > Twitter: @rjw
>>>> >
>>>> > On 22 May 2017 at 19:05, R.V.Guha <guha@guha.com> wrote:
>>>> > I agree. I prefer types
>>>> >
>>>> > On May 22, 2017 10:55 AM, "Vicki Tardif Holland" <vtardif@google.com>
>>>> wrote:
>>>> > We should figure out a principled approach to boolean properties. I
>>>> am not a fan of them as they create a secondary type system (publicAccess
>>>> could also be PublicPlace), but because they are not actually types, you
>>>> cannot add properties to them. For example, you cannot say when the public
>>>> access hours are if they differ from other hours.
>>>> >
>>>> > With that said, it is probably not worth holding up the release.
>>>> Otherwise, LGTM.
>>>> >
>>>> > - Vicki
>>>> >
>>>> > On Mon, May 22, 2017 at 1:20 PM, Dan Brickley <danbri@google.com>
>>>> wrote:
>>>> >
>>>> >
>>>> > On 22 May 2017 at 18:11, Chaals is Charles McCathie Nevile <
>>>> chaals@yandex-team.ru> wrote:
>>>> > I already  made some comments on HowTo.
>>>> >
>>>> > Thanks - sensible tweaks, we should fold those in.
>>>> >
>>>> > I'm not enamoured of filling up on reverse properties - as far as I
>>>> can tell they are only for microdata, and I'm not sure why people couldn't
>>>> just use RDFa Lite instead, if microdata isn't serving their purposes -
>>>> which I suspect for many interesting cases it doesn't.
>>>> >
>>>> > There is some ongoing discussion of that here -
>>>> https://github.com/schemaorg/schemaorg/issues/1156 - and an agreement
>>>> to revisit the reverse properties before any move from Pending into a named
>>>> extension area (or the core).
>>>> >
>>>> > Otherwise, LGTM, please go ahead.
>>>> >
>>>> > Thanks!
>>>> >
>>>> > cheers
>>>> >
>>>> >
>>>> >
>>>> > On 22/05/17 18:06, Dan Brickley wrote:
>>>> > Dear Schema.org Community Group, Steering Group,
>>>> >
>>>> > Based on our consensus discussions here and in Github, here is a
>>>> > proposal for a new Schema.org release, version 3.3:
>>>> >
>>>> > http://webschemas.org/docs/releases.html#v3.3
>>>> >
>>>> > I'd like to aim at publishing this around June 5th. Bugs, mistakes,
>>>> > typos, modeling and example improvements and other detailed review
>>>> > comments are welcome here or in the issue tracker at
>>>> > https://github.com/schemaorg/schemaorg/issues/1569
>>>> >
>>>> > cheers,
>>>> >
>>>> > Dan
>>>> >
>>>> > ps. as usual there are a few pieces of the release that will be put
>>>> together
>>>> > at the end (anything involving exact release dates, dated snapshots
>>>> etc.).
>>>> >
>>>> > --
>>>> > Charles McCathie Nevile   -   standards   -   Yandex
>>>> > chaals@yandex-team.ru - Find more at http://yandex.com
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>
>