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

I have some small tweaks to make based on feedback to
https://github.com/schemaorg/schemaorg/issues/1525 but I'm aiming at within
the next week.

Dan



On 28 June 2017 at 15:45, Thomas Francart <thomas.francart@sparna.fr> wrote:

> Hello
>
> May I inquire when v3.3 will be released ? the initial planned date (june
> 5th) is far behind us and I don't see any blocking issue here.
> I would like to be able to point people to the Legislation class in the
> pending section.
>
> Best Regards
> Thomas
>
>
> 2017-05-26 23:47 GMT+02:00 Richard Wallis <rjw@dataliberate.com>:
>
>> 1. In v3.3 http://webschemas.org/isAccessibleForFree is expanded to be
>> available on Place.
>>
>> ~Richard
>>
>>
>> On 26 May 2017, at 21:23, Thad Guidry <thadguidry@gmail.com> wrote:
>>
>> 2 issues / requests that came up in offline mailing list discussions with
>> some state and government officials regarding Tourist Sites and their
>> lecture to me about "publicly open" does not always mean FREE...after
>> review of v3.3 with them for fit and fitness against their datasets.
>>
>> Fees for access and parking ... for publicly open http://schema.org/Place
>> and http://schema.org/TouristAttraction
>>
>> Example:
>> http://geo.wa.gov/datasets/33da1934eccf470f9ad5f30d6836c3c7_
>> 7?geometry=-129.223%2C46.076%2C-115.347%2C48.315&mapSize=
>> map-normal&uiTab=table&orderByFields=Access_Fee+ASC&filterByExtent=true
>>
>> 1. For access fee, Looks like the access fee can be had by the usage of
>> http://schema.org/isAccessibleForFree
>> But the range needs to be expanded to Place perhaps, so that
>> http://schema.org/TouristAttraction can take advantage of it ?
>>
>> 2. For parking fee, it does not appear we have something already ?
>>
>> -Thad
>> +ThadGuidry <https://www.google.com/+ThadGuidry>
>>
>> On Thu, May 25, 2017 at 12:22 PM Marijane White <whimar@ohsu.edu> wrote:
>>
>>> I realize that specialOpeningHoursSpecification is intended for things
>>> like holidays, but could it also be applied to this use case?  Or perhaps
>>> hoursAvailable, if public access could be modeled as a Service?  The
>>> downside is that it forces the use of the OpeningHoursSpecification instead
>>> of the more lightweight openingHours property.
>>>
>>>
>>>
>>> *Marijane White, MSLIS*
>>>
>>> Ontologist Research Associate
>>>
>>> Ontology Development Group
>>>
>>> Oregon Health & Science University Library
>>>
>>>
>>>
>>>
>>>
>>> *From: *Joey Gartin <joey@webdrvn.com>
>>> *Date: *Wednesday, May 24, 2017 at 11:46 AM
>>> *To: *Richard Wallis <rjw@dataliberate.com>
>>> *Cc: *Vicki Tardif Holland <vtardif@google.com>, Thad Guidry <
>>> thadguidry@gmail.com>, Martin Hepp <mfhepp@gmail.com>, Richard Wallis <
>>> richard.wallis@dataliberate.com>, "R.V.Guha" <guha@guha.com>, Nicolas
>>> Torzec <torzecn@yahoo-inc.com>, "schema.org Mailing List" <
>>> public-schemaorg@w3.org>, Stéphane Corlosquet <scorlosquet@gmail.com>,
>>> Dan Brickley <danbri@google.com>, Charles McCathie Nevile <
>>> chaals@yandex-team.ru>, Tom Marsh <tmarsh@exchange.microsoft.com>
>>> *Subject: *Re: Schema.org v3.3 release candidate for review
>>> *Resent-From: *<public-schemaorg@w3.org>
>>> *Resent-Date: *Wednesday, May 24, 2017 at 4:09 PM
>>>
>>>
>>>
>>> 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 <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
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>>
>>>
>>
>
>
> --
>
> *Thomas Francart* -* SPARNA*
> Web de *données* | Architecture de l'*information* | Accès aux
> *connaissances*
> blog : blog.sparna.fr, site : sparna.fr, linkedin : fr.linkedin.com/in/
> thomasfrancart
> tel :  +33 (0)6.71.11.25.97 <+33%206%2071%2011%2025%2097>, skype :
> francartthomas
>