- From: Dan Brickley <danbri@google.com>
- Date: Thu, 25 May 2017 17:15:12 +0100
- To: Richard Wallis <richard.wallis@dataliberate.com>
- Cc: Thad Guidry <thadguidry@gmail.com>, Hans Polak <info@polak.es>, "schema.org Mailing List" <public-schemaorg@w3.org>
- Message-ID: <CAK-qy=6uk8vthXzRKHbihZZX4bn857Qb0_ERddnznCt+9XCOGg@mail.gmail.com>
Sticking with boolean for now makes sense to me, although I do think there is useful work to do later making a more usable boolean structure. Richard or Thad, can you drop the specific changes into https://github.com/schemaorg/schemaorg/issues/1569 ? I'd recommend avoiding the word "accessible" for now, until we get a better story around physical/place accessibility. On 25 May 2017 at 15:56, Richard Wallis <richard.wallis@dataliberate.com> wrote: > Hi Thad, > > I am supportive of your proposed amendment to the description of the *publicAccess > *property*, *and appreciate your view on why it makes sense in this > context. > > I have discussed it with Felipe in the Tourism group and he is of the same > opinion. > > ~Richard. > > > > Richard Wallis > Founder, Data Liberate > http://dataliberate.com > Linkedin: http://www.linkedin.com/in/richardwallis > Twitter: @rjw > > On 25 May 2017 at 15:01, Thad Guidry <thadguidry@gmail.com> wrote: > >> Thanks Richard & Felipe, >> >> Finally a well explained reason that I am OK with having just a boolean >> and not a Type. >> " If I wanted as a traveler to visit the Cave of Altamira, I would be >> happy to find it in a search engine, learn that it is closed, and that I >> can visit instead its replica and interpretation centre." >> >> It sounds like Felipe is trying to say that the word "accessible" also >> means "open" to him and the Tourist industry. >> >> If the intent was to equate the 2 notions of "accessible" and >> "open"...Perhaps an addendum to the description of the property >> "publicAccess" would be to say also that ... >> >> "A flag to signal that the Place is accessible *or open *to public >> visitors. *If this property is omitted there is no assumed default >> boolean value*" >> >> As always, it seems the descriptions we choose can make or break proper >> usage and why I am always so adamant about giving our descriptions more >> context. >> >> But regardless, I feel strongly now (with a better description on the >> property) that a boolean can work just fine and there is no need for a new >> Type. >> >> -Thad >> +ThadGuidry <https://www.google.com/+ThadGuidry> >> > >
Received on Thursday, 25 May 2017 16:16:15 UTC