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

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