The Tourism Structured Web Data Community Group

The mission of this group is to discuss and prepare proposals, examples, and best practice guidance for the sharing, via the web, structured data descriptions of resources associated with the tourism industry.
Initial focus will be on extending Schema.org schemas for the improved representation of tourism related information markup and sharing. The group will seek consensus around, and support for, proposal(s) to be made to the Schema.org community.

Note: Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.

A proposal has been submitted to the Schema.org community for the creation of two new Types — TouristDestination & TouristTrip

TouristDestination A tourist destination. In principle any Place can be a TouristDestination from a City, Region or Country to an AmusementPark or Hotel. This Type can be used on its own to describe a general TourstDestination, or be used as an additionalType to add tourist relevant properties to any other Place. A TouristDestination is defined as a Place that contains, or is colocated with, one or more TourstAttractions, often linked by a similar theme or interest to particular a touristType. The UNWTO defines Destination (main destination of a tourism trip) as the place visited that is central to the decision to take the trip.

TouristTrip A tourist trip – a created itinerary of visits to one or more places of interest (TouristAttraction/TouristDestination) often linked by a similar theme, geographic area, or interest to a particular touristType. The UNWTO defines tourism trip as the Trip taken by visitors

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.

Before taking some days off this holiday season, I would like to introduce some steps that we propose to initiate the group activity for 2016. Perhaps the term roadmap is adequate for this purpose.

Please consider the content as an individual contribution from Sismotur to start the debate, kindly please do not take this as an attempt to impose any methodology to this group, we are just trying to help.

Besides, Richard and I suggest to kick off the group activity in 2016 with a first (and if possible simple) example to improve schema.org. We think this would be good to provide traction and get the group to work around a specific subject.

Finally, please accept my apologies for any mistakes in the text, English is not my mother language.

All the best for the holiday season and 2016.

Kind regards,
Felipe

Roadmap proposal

1. Do a diagnostic of the existing vocabulary

The first thing we propose to do is to review schema.org as a whole in order to identify major improvement areas to the vocabulary.

I will use a real example for this, the Beach class, which is an important place for many tourism destinations. This class is a child of Civil Structure and has no properties of its own. As a result, the only way to describe it is to use the following properties:
– from CivicStructure: openingHours,
– from Place: address, photo, review…
– from Thing: name, url, description, image…

In our humble opinion, openingHours is of limited interest for a beach (at least in our home country, Spain, where most beaches are public).
We think this class could potentially benefit from:
(a) being a child of TouristAttraction (class without properties too!), from which it could inherit properties relevant to tourists,
(b) adding properties to describe things such as the sand type (white, volcanic…), the setting (urban, natural), the type (quiet, nudist, lively, ideal for surfing…).
These properties are found in Tenerife’s website, http://www.webtenerife.co.uk/places-interest/beaches/Please do not take this as a concrete proposal, but just an example to illustrate the point.

2. Establish a framework to adapt the class tree

Based on the result of the diagnostic, analyze the existing schema.org global class tree and propose improvements to it.

propose modifications to the class tree (in particular adding relationships between classes), e.g. make Beach be a child of TouristAttraction.

As a result, we should get a clear picture of the transition between the existing class tree and an improved tree which is better suited for Tourism.

3. Model individual classes to match tourism industry needs

For each class identified as relevant for Tourism in step 2, analyze its properties and decide whether these need to be amended (i.e. add, modify, remove properties).
The gist of this work is to do here concrete proposals to schema.org involving class properties.

This is a work that can be made parallel for final classes (i.e. those with no children) if we all decide to make subgroups specialized in a particular domain (e.g. oenological tourism, sport tourism, cultural tourism… (*)). On the other hand, serializing the work is another valid option.

Furthermore, we could gather advice from experts to ensure each class gets the necessary properties for industry players having a stake on it. In that respect, we could bring tourism destinations specialized in the domain under analysis to the discussion table (e.g. subject matter experts from Canary Islands and Baleares tourism boards when analyzing the class Beach). This would allow us to take into account the tourism destination point of view, and make class properties relevant for the industry.(*) These tourism categories are loosely taken from the current French national tourism plan.

We are a small company of consultants in the tourism industry focused on helping tourist destinations and services to market themselves. For that purpose we have recently built a web platform <http://www.inventrip.com>, which makes heavy use of tourism categories to describe places the tourists can visit or things they can do.

We would like to migrate the existing categories in our platform to schema.org classes, however that would require extending classes (e.g. TouristAttraction) to cover up more detailed use cases frequent in the tourism industry.

It was clear from the following messages that there was interest in discussing enhancement and possible extension to the Schema.org vocabulary to help with the structured markup of tourism related information. Also there was interest in sharing best practice in the ways to this. Hence this group.

Tourism covers broad areas of markup interest, from locations and transport to hotels and disability access etc. Schema.org is also very broad. So it is hoped that much of what is required is already available, or being proposed – there is a hotels extension already in the proposal stage. The enhancements needed may well be minimal, and much of the work of this group will be around identifying use cases and capturing best practice to satisfy them.

We will have a wiki soon to capture such work in. In the meantime, please don’t hold back with suggestions, and potential use cases for us to engage with.

The mission of this group is to discuss and prepare proposals, examples, and best practice guidance for the sharing, via the web, structured data descriptions of resources associated with the tourism industry.

Initial focus will be on extending Schema.org schemas for the improved representation of tourism related information markup and sharing. The group will seek consensus around, and support for, proposal(s) to be made to the Schema.org community.

This is a community initiative. This group was originally proposed on 2015-12-08 by Richard Wallis. The following people supported its creation: Richard Wallis, Raphaël Troncy, Felipe Santi, Christopher Regan, Vicki Holland. W3C’s hosting of this group does not imply endorsement of the activities.