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" (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" 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!