Re: Extension proposal for TouristAttraction class

I would also suggest to model the *role* of being a tourist attraction as either a single extra type and use MTEs, or define a property touristAttraction with a range of Boolean.

Being a tourist attraction is IMO a secondary and more volatile (aka non-rigid) category of being as compared to essential type of the respective thing.

Some things will be tourist attractions only temporarily, or for particular audiences (e.g. tourist from certain cultural spheres).

By using a single TouristAttraction type, we would also have a container for such meta-data, e.g. validFrom, validThrough, targetAudience etc.

Plus, we can apply it to any type in schema.org without hard-wiring which ones can be tourist attractions.

Martin


Note: Don't feel bad about shrinking the size of the contribution to schema.org. The less additional elements you need to cover your use-cases, the better is your modeling (as a general rule of thumb in this context).
 
-----------------------------------
martin hepp  http://www.heppnetz.de
mhepp@computer.org          @mfhepp




> On 05 Nov 2016, at 09:34, Richard Wallis <richard.wallis@dataliberate.com> wrote:
> 
> Hi Angelica,
> 
> My thoughts are on similar lines to Thad’s.
> 
> The proposal seems to be addressing three areas of concern:
>  • Identifying a Place - natural or man made - as a TouristAttraction
>   • As Thad suggests it would be a place that is famous in some way.  The difference say between a bagel shop and the bagel shop that sold the first New York Bagel.
>  • Providing the properties that would help the description of a Place that are applicable to a TouristAttraction.
>  • Increasing the number of specific Place Types and or properties to better describe them as Places that would be of interest to a tourist.
> Your student’s proposal conflates these three concerns together by creating specific subclasses of ArtificialCulturalAttraction and NaturalAttraction and then creating yet more subtypes of those.
>  
> As Thad references, we have within Schema.org the capability to use multiple Types when describing an entity (MTEs).  As we already have the http://schema.org/TouristAttraction type, it  is already possible to define any other type as a TouristAttraction.  To pick an extreme example you could potentially define a Person as a TouristAttraction:
> {
>    “@type”: [“Person”,”TouristAttraction”].
>    “description”: “Human statue, painted silver and dressed as the Statue of Liberty.  Can be found near Central Park most days”,
>    “address”: “Columbus Circle, New York, NY,”
> }
> As I say an extreme example but it demonstrates the principle. 
> 
> Using this approach, you would first describe the entity - Mountain, Museum, AmusementPark, City, Bridge, etc. - then you would additionally define it as a type TouristAttraction.  This would also relive the proposal from the general need of identifying new types in the vocabulary that may or may not be potential tourist attractions.
> 
> This brings me to the proposed ArtificialCulturalAttraction and NaturalAttraction types.  The Naturalness or artificialness of a Thing comes from what it is, not from what sort of tourist attraction it might be.  Mountains, rivers, etc. are natural,  buildings, bridges, amusement parks are in general not.  The proposal to add Beach, which I support by the way, should be on the grounds that it is a type of LandForm missing from the vocabulary in general, not that it is only a type that tourists would be interested in. I therefore believe that these proposed types are unnecessary.
> 
> As to desirable new properties for the existing TouristAttraction Type, I concur with the need to add a property to indicate free entrance.  Instead of creating a new property however, I would suggest that we reuse the already existing property isAccesibleForFree, used on CreativeWork and Event, adding to its domainIncludes and tweaking its description. I would also suggest that instead of only restricting its use to TouristAttractions, it is added to Place to provide broader benefit.
> 
> For other properties, being a subtype of Place provides many applicable ones anyway, such as review, openingHoursSpecification, etc.  One question I would consider is that tourist attractions are often grouped together - on a Tourist Trail for instance.  So should we consider creating a TouristRoute subtype of TouristAttraction then using containsPlace & containedInPlace to build the relationship between the route and individual attractions.
> 
> So in summary, I am suggesting that:
>  • we use MTE’s and the current TouristAttraction Type to indicate that something is a tourist attraction
>  • ArtificialCulturalAttraction and NaturalAttraction are unnecessary
>  • New types to describe things not currently in Schema (that are potential tourist attractions) should be proposed in a none tourist specific way.
>  • isAccesibleForFree should be extended to Place
>  • We should look at other tourist specific modelling such as TouristRoute.
> 
> If the proposal was reworked as I suggest, I don’t think it would necessarily warrant the creation, yet, of a tourism.schema.org extension and may just be a proposal for enhancing the core.
> 
> Thanks again for the value input from you and your student - maybe they would benefit from joining the conversation.
> 
> ~Richard.
> 
> 
> Richard Wallis
> Founder, Data Liberate
> http://dataliberate.com
> Linkedin: http://www.linkedin.com/in/richardwallis
> Twitter: @rjw
> 
> On 4 November 2016 at 21:52, Thad Guidry <thadguidry@gmail.com> wrote:
> 
> Right, I understand your reasons for addeding those extra Classes to TouristAttraction.  Even a Bathroom could be a TouristLocation if it is of some historic importance, or The Beatles touched it :)  But you probably don't want those subclasses, and if you do, its better to specify the special class with a prefix like "FamousBathroom".
> 
> I think being a bit more strict could help with a Tourists assumptions.  Those Tourists that are interested in Hair Salons or Haunted Ghost Tours will typically search for them directly.
> 
> Most search engines already are tuned for "things to do" or "attractions", etc.
> 
> Google Search "miami south beach florida things to do"
> 
> Lincoln Road is a long walkway of shops and considered a Tourist Attraction and a place to shop.
> 
> There are many shopping locations in South Beach, Miami, Florida... but only a few considered Tourist worthy of your time and hence considered Famous or a Tourist Attraction.
> 
> I would emphasis the term "Famous" and not something like "Popular" or otherwise to avoid confusion with local popularity.  So the ShoppingLocation Class could be renamed "FamousShoppingLocation".  Saying "TouristShoppingLocation" might give the feeling of a place like a souvenir shop or place to buy trinkets.  So I would avoid "Tourist" as well.
> 
> In my opinion, the class names that are long in example here but more accurate to reality would be FamousShoppingLocations , Famous"Historic"SportsActivityLocations, and FamousSpasResorts, etc.
> 
> Another sub layer for a TouristAttraction is the "Historic" aspect.  Anything could eventually be Historic and eventually become Popular and eventually a TouristLocation.  Since anything can be Historic...that might be something to better fit at a Property level and not a Class.  So I would work on that also in this extension.
> 
> I think "Famous" and "Historic" are the right mental models that your student is probably trying to classify.  So don't subclass all kinds of things, but instead just create parent classes of "FamousLocation" and "HistoricLocation"
> 
> -> Location -> FamousLocation -> HistoricLocation
> 
> And then any Thing can be additionally Typed (MTE - Multi Typed Entity)  as them.
> Since any Location can be classed as those, then what needs figuring out is not all those potential subclasses that "might be considered a TouristAttraction", but instead figure out what Properties need to be under FamousLocation and HistoricLocation.
> 
> I think that effort would be the most useful work for this extension proposal and Schema.org because we already have the http://schema.org/TouristAttraction class with some nice properties, but what properties are missing that might be useful ?  Find those out and you make a lot of other folks happy.
> 
> To get your student started...
> One property that I personally would enjoy seeing is something like "visitCost" or perhaps a Boolean like "freeVisit" Y/N because the only way to Cost something in Schema.org currently is to have it as an Offer.  Then is there something under http://schema.org/LandmarksOrHistoricalBuildings that is missing ?  Does LandmarksOrHistoricalBuildings cover everything visitable under a historic context ?  Great Wall of China is a landmark and historic.  Are there Things that are Historic and visitable that are NOT a landmark or building ?  Find that out.
> 
> 
> 
> On Fri, Nov 4, 2016 at 6:52 AM Angelica Lo Duca <angelica.loduca@iit.cnr.it> wrote:
> Dear Thad,
> thanks for your quick reply!
> 
> You're right, a HairSalon is generally considered as a famous place and not as a typical tourist attraction, but we think that in some cases, it can be possible that a person or a group of persons decide to move and stay overnight to another city (one of the conditions to talk about tourism) for the pleasure of visiting (another of essential conditions of tourism) a specific hair salon and, maybe, other attractions in the surroundings. It's for these reasons that we added these Classes to TouristAttraction.
> 
> However, if we wanted to be more strict, we should re-think about three classes: HealthAndBeautyBusiness, SportsActivityLocation and ShoppingLocation. In particular, we could remove completely the ShoppingLocation Class as a sub class of TouristAttraction and maintain only a few sub classes of HealthAndBeautyBusiness and SportsActivityLocation, such as DaySpa, ThermalBath, SkiResort, BowlingAlley.
> 
> What do you think?
> 
> Angelica
> 
>  Angelica Lo Duca, PhD
> Web Applications for the Future Internet Lab.
> Institute of Informatics and Telematics
> National Research Council
> Via Giuseppe Moruzzi,
> 56124 Pisa (Italy)
> 
> http://www.iit.cnr.it/angelica.loduca
> Tel. +39 050 315 8292
> Skype, Twitter, Github: alod83
> 
>> Il giorno 03/nov/2016, alle ore 17:57, Thad Guidry <thadguidry@gmail.com> ha scritto:
>> 
>> Nice,
>> 
>> But there are a few classes that seem to be outside the realm of a typical TouristAttraction.  Like HairSalon ?  I have yet to visit any famous Hair Salons.  I know some do exist, but I would consider them just a Famous Place, or Attraction.  Not something you would see in a guidebook or Travel agency magazine or itinerary.
>> 
>> It looks like this structure attempts to collect not just a typical TouristAttraction that a vacationing person or family might be interested in, but instead something more like classes that could be considered a "Famous Place" ?
>> 
>> The word Tourist means someone traveling to a place for pleasure.  Some of the listed classes would be marginally pleasurable for some people, but certainly still retain a Famous indication.
>> 
>> So I would lean to renaming to something like FamousAttraction or similar..or just Attraction.
>> Then again...anything Famous typically gets flocked by Tourists eventually. :)
>> 
>> 
>> On Thu, Nov 3, 2016 at 10:35 AM Angelica Lo Duca <angelica.loduca@iit.cnr.it> wrote:
>> Hi all,
>> one of my students, Elisabetta Triolo, is working on a proposal of a host extension for the TouristAttraction class of Schema.org.
>> She studied the structure of some important tourism platforms such as TripAdvisor, ParisInfo, Gogobot, and she tried to define what a tourist attraction is, by reading information and publications such as the Wikipedia definition, the Lorenzo Canova’s study of attractions, Lucia Varra’s article about tourist destination.
>> The whole extension has been published here. 
>> In addition, an owl version of the extension is available here and it’s possible to find an explanation of the project here.
>> 
>> It’s important for us to have feedback from the community, in order to improve the structure of the class and its subclasses, and, hopefully, add this as an host extension of the Schema.org project.
>> Thanks in advance for your attention,
>> Angelica
>> 
>> Angelica Lo Duca, PhD
>> Web Applications for the Future Internet Lab.
>> Institute of Informatics and Telematics
>> National Research Council
>> Via Giuseppe Moruzzi,
>> 56124 Pisa (Italy)
>> 
>> http://www.iit.cnr.it/angelica.loduca
>> Tel. +39 050 315 8292
>> Skype, Twitter, Github: alod83
>> 
> 
>

Received on Saturday, 5 November 2016 08:56:25 UTC