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

In the limit, how is this different from opening hours? At least
conceptually?

guha

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
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>>>
>