Proposal #1 (follow up from previous post) [via The Tourism Structured Web Data Community Group]

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



----------

This post sent on The Tourism Structured Web Data Community Group



'Proposal #1 (follow up from previous post)'

https://www.w3.org/community/tourismdata/2016/12/06/proposal-1-follow-up-from-previous-post/



Learn more about the The Tourism Structured Web Data Community Group: 

https://www.w3.org/community/tourismdata

Received on Tuesday, 6 December 2016 16:10:48 UTC