Proposal #1 (follow up from previous post)
Dear All,
Following the proposal posted by Angelica Lo Duca and Elisabetta Triolo on November 3, Richard Wallis and I have had some interesting and constructive discussions with them about the way to move it forward.
As a result, we have reached a consensus around a minimum viable proposal to add value without adding too many things into the schema.org vocabulary.
Our goal is to fix some key issues identified in the past with the way tourist attractions are modeled today, and to provide a first set of examples for the Tourist Attraction class, from basic to complex, which are inexistent today. As such, the purpose is not solve every issue we have identified up to now; this will be hopefully done in forthcoming proposals 🙂
We invite you all to provide your comments or thoughts in this group’s mailing list. If no roadblocks are found, after one week we will submit a pull request to schema.org for incorporation into the Core Vocabulary.
Many thanks in advance for your feedback and help.
Kind regards,
Felipe
PROPOSAL #1
Our proposal is very simple and can be explained as follows:
1. Keep using the existing Multi-Type Entities mechanism available in schema.org as the best way to model tourist attractions, i.e. do not alter the class structure for the moment. Using this simple mechanism, anything can be expressed in schema.org as two or more classes, e.g. a famous winery that has become a tourist attraction on its own can have the types Winery and TouristAttraction (see the examples provided in the link below).
2. Add or alter some useful properties:
a) Add a property touristType to TouristAttraction (valid types are Audience or Text) to model the type of tourism the attraction is catering for, as well as the origin of the incoming tourists (see the example of a Cemetery).b) Add a property availableLanguage to TouristAttraction (valid types are Language or Text), used to model the languages available in the tourist attraction, e.g. the ones spoken during a guided visit, or written in the interpretative signage.
c) Add a property publicAccess (Boolean) to Place (the parent class of TouristAttraction) to signal that the place is accessible by public visitors. This criteria is important for tourist attractions, since many of them cannot be visited by the public.
d) Modify the property isAccessibleForFree used in Place (the parent class of TouristAttraction) to signal that the tourist attraction is accessible for free. Supersedes free.
All the details can be found in Richard’s GitHub fork (it will be used to build the PR for the main schema GitHub repository):
https://github.com/Dataliberate/schemaorg/tree/TouristAttraction1
Also, a working copy with the changes incorporated and nine examples covering the changes described before can be found here:
http://sdo-tourism.appspot.com/TouristAttraction
