Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improvements to TouristAttraction #1459

Merged
merged 4 commits into from
May 19, 2017

Conversation

RichardWallis
Copy link
Contributor

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:

  • Add new property touristType to TouristAttraction "Attraction suitable for type(s) of tourist. eg. Children, visitors from a particular country, etc."

  • Extend the domain of availableLanguage to TouristAttraction. "A language someone may use with or at the item, service or place...."

  • Extend the domain of isAccessibleForFree to Place "A flag to signal that the item, event, place is accessible for free."

  • Add new property publicAccess to Place. "A flag to signal that the Place is accessible by public visitors."

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.

…amples file.

Extended domain of availableLanguage to TouristAttraction.
Extended domain of isAccessibleForFree to Place
Added property publicAccess to Place.
Tweaked typo in Tourism Group acknowledgement
@vholland
Copy link
Contributor

Is touristType different enough than the existing http://schema.org/audience property to warrant a new name?

@thadguidry
Copy link
Contributor

@RichardWallis Lets continue to try to use "Simple English" as much as possible.
To that end, please change "A flag to signal that" to "An indicator to signal that".

@sismotur
Copy link

Hi @vholland, many thanks for your comment. My name is Felipe Santi, co-chair with Richard Wallis of the W3C Tourism Structured Web Data Community Group.

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 An intended audience, i.e. a group for whom something was created.) would in my opinion be misleading, since touristType does not fit the definition, it is a different concept.

Hope this clarifies.
Kind regards,
Felipe

@thadguidry
Copy link
Contributor

@sismotur Its not misleading... its just that the definition of audience needs a bit of cleaning up.

+1 for reusing audience and expanding its definiton - An intended audience, group or type of people that some Thing is created for or meant to be attractive to.

@RichardWallis
Copy link
Contributor Author

@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.

@sismotur
Copy link

@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.

@thadguidry
Copy link
Contributor

@sismotur @RichardWallis It is hacking (changing) the definition and for VERY good reason.

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 ?
"geek" ... is that an audience or a touristType ?
"gamer" ...
"naturalist" ...
"Doctor" ...
"environmentalist"
"Trump supporters"
"thrill seeker"

See where I am getting at ?
You will make it very confusing for publishers to choose audience or touristType, because there is little to no difference once we fix the definition of audience.

@RichardWallis
Copy link
Contributor Author

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.

@thadguidry
Copy link
Contributor

thadguidry commented Dec 19, 2016

@RichardWallis

THING: Mount Everest
TYPE: touristAttraction
AUDIENCE: backpackers

THING: Les Miserables @ The MET New York
TYPE: Theatrical Play
AUDIENCE: general public

but your example on touristType does not describe an audience....

  "touristType": [
    "Wine tourism",
    "Cultural tourism"
  ],

Now that I actually looked at some of the examples, this is even worse...

"touristType": {
    "@type": "Audience",
    "audienceType" : "Memorial Tourism",

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 :)

@thadguidry
Copy link
Contributor

thadguidry commented Dec 19, 2016

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. :)

@RichardWallis
Copy link
Contributor Author

"audienceType" : "Memorial Tourism",
@thadguidry Yes you are right to highlight that - if we do drop back to using audience the examples would have to change to reflect the type of tourist of as against the form of tourism.

"Memorial Tourist", "Wine Tourist", etc.

... and yes to adding audience to Event - just because it is a sensible thing to do!

@RichardWallis
Copy link
Contributor Author

Reflecting on the comments it is clear that the sub-property relationship between touristType and audience is not as strong as initially proposed. Removed that link.

@danbri
Copy link
Contributor

danbri commented Mar 16, 2017

We didn't get this into 3.2 but it looks like solid work, I'll take care to get it reviewed for next release.

@danbri danbri merged commit a372637 into schemaorg:sdo-callisto May 19, 2017
@danbri
Copy link
Contributor

danbri commented May 19, 2017

Was there a tracking issue, or all github discussion is here?

@RichardWallis
Copy link
Contributor Author

All in this PR - previous discussion was external within the Tourism Structured Web Data Community Group

@danbri
Copy link
Contributor

danbri commented May 19, 2017

Would you mind tweaking this PR to target the 'master' branch? I merged into into the wrong one in error (now reverted).

@danbri
Copy link
Contributor

danbri commented May 19, 2017

Don't worry, I'll make a quick new PR. Easily done :)

@Dataliberate
Copy link
Contributor

Dataliberate commented May 19, 2017 via email

danbri added a commit that referenced this pull request May 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants