Thanks Hay! I think you got off track. Yes the need is to search and find attractions or locations themselves, but only those that formally or informally support a particular set of human activities. Knowing which ones have/do not have support is the need for the new proposed property "activity". I.E. it is currently hard to find locations or attractions with a SPARQL query that asks "give me locations or attractions that support 'boating' as an activity"... or formally "give me locations or attractions that have a "boat ramp".
The focus is really activities, to support better filtering and finding attractions or locations themselves that have direct managed support (I.E. formal) or have a widely held popular view (I.E. informal) of supporting a particular human activity. Search engines and other consumers typically have to connect the dots themselves with machine learning, SEO, and metadata inspection of travel or tourist sites. If you notice, *Wikivoyage also doesn't have a property yet that supports this need*. It is something that you often see listed in a vistor centre or travel guide quite often. We also want to help lessen the burden of publishers/consumers and in particular, make it easier to search for and consume known human activities across attractions or locations. It is sometimes commonly called "things to do", but that is extremely broad and not what the focus is here, but I only gave as an example. The focus really is "human activities <https://www.wikidata.org/wiki/Q61788060>" (for a KG definition see https://www.google.com/search?kgmid=/g/1q6j8vb9r) The need to be able to express that an attraction or location has the formal/informal capacity ("boating") or simply has the natural ability ("birdwatching") to support a particular human activity. And this is only concerning "human activities <https://www.wikidata.org/wiki/Q61788060>" and not any non-human activities. Furthermore, "shopping" or "eating" is a common "human activity" given at any particular attraction or location, but are SO COMMON and uninteresting that I wouldn't bother and in fact disallow that value on any attraction. Concerning "foodie" attractions, we already have common classes ("restaurant|bar|cafe|etc") to deal with filtering those kinds of locations. I don't think it would be hard to replicate with a new property, since many "human activities" are already known in the recreation and entertainment domains (which is the primary initial focus). Most could also be deduced later on through Wikifunctions and Lexeme abstraction (which I have partially done through experimentation). I hope this clarifies further, if not let me know! Thad https://www.linkedin.com/in/thadguidry/ https://calendly.com/thadguidry/ On Sat, Jan 1, 2022 at 2:15 PM Hay (Husky) <hus...@gmail.com> wrote: > Hey Thad, > an 'activity' or 'activities' property would seem a bit broad to be > me, and hard to properly define. Compared to the 'things to do' > results on the search engines you mention, this would be very hard to > replicate with a regular property on Wikidata. What is the criteria > for a 'popular thing to do'? Number of yearly visitors? How many > tourist guides include the attraction? And does this include > restaurants as well? Parks? Something like 'boating' is very different > from 'The Louvre'. I think this will be very much up for debate and > Wikidata is not a proper platform for those discussions. > > Fortunately we already have two other solutions that i think are a > much better fit for the problems mentioned. You can already do a > SPARQL query to find all attractions for a certain place, and even > sort by criteria like number of visitors or sitelinks. And for more > exhaustive lists Wikivoyage is a great project, and that can also > connect to Wikidata (see > > https://www.wikidata.org/wiki/Wikidata:Wikivoyage/Resources#Properties_for_listings > ) > > Kind regards, > -- Hay > >
_______________________________________________ Wikidata mailing list -- wikidata@lists.wikimedia.org To unsubscribe send an email to wikidata-le...@lists.wikimedia.org
