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

Richard,

Then what does a consumer do with information that a tourist site is NOT
publicly accessible ?  What traits are lacking on that tourist site when
its not publicly accessible ?  Why is a mountain not accessible to the
public, because there's a fence around it ?  What happened to all the
expedition hikers that book trips ?  Now I'm really confused without more
examples than a generic "mountain".

Devil's advocate,
-Thad
+ThadGuidry <https://www.google.com/+ThadGuidry>


On Wed, May 24, 2017 at 5:28 PM Richard Wallis <
richard.wallis@dataliberate.com> wrote:

> *publicAccess*
> In the context being proposed (tourist attractions), not being accessible
> to the public is very different to not being open.  Tourists visit
> buildings and look at spectacular views all the time.  A mountain may not
> be accessible to the public, but it would be open to view all the time.
> However the fact that it was also directly accessible, or not, is important
> information.
>
> To give some background, as you are aware this proposal comes from the Tourism
> Data <https://www.w3.org/community/tourismdata/> group, who have provided
> the many examples shown on the TouristAttraction
> <http://webschemas.org/TouristAttraction> page.  As you can see from
> those, it is intended to make use of MTE capability to indicate that
> anything can also be a TouristAttraction.
>
> One of the expected uses of this will be by tourist information and local
> administration organisations describing the benefits of visiting their
> locality.  This may well result in the description being provided by that
> organisation on their tourist site, not necessarily the owners of the
> business or building.  Equally many tourist attractions are landForms
> (mountains, lookout points, beaches, etc.) which maybe publicly viewable
> but not publicly owned or accessible.
>
> Within the group, publicAccess was initially proposed with a domain of
> TouristAttraction where this makes most sense and is not relevant to the
> place being public or not.  The proposal was extended to making the domain
> to include Place because it was felt that this would be both relevant and
> useful beyond tourism.  If the consensus it that this maybe problematic,
> the domain could be narrowed back to being TouristAttraction again.
>
> ~Richard
>
>
>
> Richard Wallis
> Founder, Data Liberate
> http://dataliberate.com
> Linkedin: http://www.linkedin.com/in/richardwallis
> Twitter: @rjw
>
> On 24 May 2017 at 20:48, R.V.Guha <guha@guha.com> wrote:
>
>> 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
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>>
>>>
>>
>