Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Improvements to TouristAttraction #1459
Following previous discussions on mailing lists over the last couple of months this is a proposal from the W3C Tourism Structured Web Data Community Group, working with Angelica Lo Duca and Elisabetta Triolo, to increase the utility and usefulness of the TouristAttraction Type.
A working example, with many examples for several use-cases, can be found here: TouristAttraction.
By making use of Multi Type Entity (MTE) capabilities, it should be possible to identify any 'Thing' as a TouristAttraction, in addition to its default properties as a museum, mountain, dance festival, or whatever.
To aid that utility, this proposal makes the following additions:
Although the target type for this proposal is TouristAttraction, it was felt that applying isAccessibleForFree & publicAccess to Place would deliver further utility.
This proposal does not attempt to address individual enhancements to types that could be a TouristAttraction, for example a touristAuthority property, or a typeOfSand property being added to the Beach type. These may well be approached in later proposals after more thought and discussion.
Yes indeed I think that the touristType property is necessary to add, separately from the existing audience property. Based on our experience working in large tourism destinations like Barcelona, this information is key to describe touristic places.
Tourist destinations need to profile and differentiate themselves to cater for a certain type of tourist, e.g. a destination like Ribera del Duero wants to attract "culture and wine tourism" tourists. On the other hand, people that want to plan their trips by themselves do also want to look for places filtered by this type of criteria. You can take the Cemetery example in TouristAttraction to see how it makes sense to a certain type of public.
Mixing this with audience (defined as
Hope this clarifies.
@thadguidry I agree the 'a flag' wording is a bit odd, it is already part of the isAccessibleForFree description which I lazily copied into the publicAccess description. We should probably follow your suggestion for both.
@vholland there is obvious connection between audience and touristType as recognised by the sub-typing in the proposal. However I do believe that there is sufficient difference to justify a touristType (or possibly a visitorType) property.
In my view, audience is about targeting of a thing/event, as per the current description: a group for whom something was created Whereas touristType is more about the group or groups of people that may actively search out the type of attraction.
There are also situations where the Thing in it's own right will have a target audience (theatre, show, festival, religious venue, etc.) yet as a TouristAttraction have a different profile of visitors (around architecture, aesthetics, history, activities, etc.) A good example of this would be the Vatican for example.
@thadguidry thanks for your comment, you're right to point that the current definition of audience is not misleading, please let me re-express the argument again.
On top of the arguments just laid out by @RichardWallis, what I meant is that, in my opinion, I would not change the definition of Audience, since the word itself is not intended for that purpose. In my old English dictionary, the definition is "the people listening to or watching a performance, speech, television show, etc".
Therefore the suggestion to broaden it sounds to me a bit like hacking the word Audience to make it encompass more concepts than the ones the word is intended to, which can lead to confusion on both users writing schema.org and consumers of that information, who as Richard pointed, are a different profile of visitors and not a target audience of a performance or show.
We want consumers and publishers to be comfortable with Schema.org, no matter which side they are on. We cannot forgot the intention and mission of Schema.org, which is to help consumers ultimately "filter and find things easier" and in order to do that we have to give good vocabulary for publishers to "structure their data" to describe their Things such as TouristAttractions.
You can view this as the difference between A: "I'm looking for" and B: "I'm offering a" .. where both ultimately have the same Thing in the middle. Your stance is that A makes more sense (consumer side) and I am proposing that we stick to our Schema.org mission approach of helping web developers describe B.
As a web developer marking up my Tourist website, I come to Schema.org and see 2 types that might work for me to describe who the intended group of people my TouristAttraction is most useful or attractive to...
"history buff" ... is that an audience or a touristType ?
See where I am getting at ?
As a web developer marking up my tourist site, I would suggest that the answer to all your posed questions would be touristType, as that would be the property that would become available by choosing the TouristAttraction Type. (if the proposal stands as it is)
I believe that 'defining' a tourist type as such, explicitly differentiates between the types of groups of people we are discussing here, whereas just relying on audience may well introduce some confusion in those that would not see tourists as audience members.
However, it would be unfortunate to delay this useful proposal by intransigence on any side.
If the broad consensus is that the domain of audience should be extended to include TouristAttraction instead of creating the touristType sub-property, I am sure the group would accept that as a compromise. Subject however to getting the description of the audience property appropriately expanded.
The current, and proposed, description enhancements still retain the focus that something has been created with a group of people in mind. "some Thing is created for or meant to be attractive to". For a show, or event, etc,, or say children's furniture when used on a product, etc., this is perfectly valid.
In the area of tourism however, the intention is often on the part of the groups of tourists, not necessarily those describing or preparing the attraction.
The description we end up with needs to be broad enough to handle this breadth from the traditional theatre & TV program creative work point of view plus products and lodging businesses, yet still be appropriate from a tourism point of view to be useful to categorise a destination as being of interest to cruse-ship passengers, backpackers, military history enthusiasts, families of war cemetery residents, film location fans, nudist bathers, etc.,etc. Whilst still being suitable when describing things from a glacier or a mountain, to a building, a street festival, or a theme park.
THING: Mount Everest
THING: Les Miserables @ The MET New York
but your example on touristType does not describe an audience....
Now that I actually looked at some of the examples, this is even worse...
There is a difference between Tourism (INDUSTRY) and Tourist (PERSON) and Tour Type (WINE TOUR).
I don't want to be the one to choose the definition expansion of audience. Let @vholland handle that, she's much better than all of us at those things :)
Ugh... and Event doesn't even have audience .... so we stupidly created tons of SubTypes like http://schema.org/ChildrensEvent just to say its intended audience is for Children ? ugh... we're so bad. :) Lets stop creating subtypes just for the sake of it.... empty bucket types that are more useful as well thought out and planned for properties.
@RichardWallis Add audience to Event while we are at this, for heavens sake. :)
"Memorial Tourist", "Wine Tourist", etc.
... and yes to adding audience to Event - just because it is a sensible thing to do!
referenced this pull request
May 19, 2017
Went to do it to find you had already done it!…
On 19 May 2017 at 16:56, Dan Brickley ***@***.***> wrote: Would you mind tweaking this PR to target the 'master' branch? I merged into into the wrong one in error (now reverted). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1459 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHVdIF_lLTq6Ac83Qoa9f9MZ4kfypiWKks5r7bubgaJpZM4LPfK8> .