Wikidata:Property proposal/has amenity

has amenity

Originally proposed at Wikidata:Property proposal/Place

   Not done

Description	a positive designed or designated feature of a location
Represents	amenity (Q867393) and hotel amenity (Q5912147)
Data type	Item
Domain	park (Q22698), hotel (Q27686), building (Q41176)
Allowed values	item
Allowed units	none
Example	Boeddeker Park (Q47487600) → basketball court (Q2341939) Taj Mahal Palace Hotel (Q19104) → swimming pool (Q1501) Gas Works Park (Q5526323) → accessibility (Q555097) Times Square–42nd Street/Port Authority Bus Terminal (Q11265) → unisex public toilet (Q24922) Central Park (Q160409) → The Ramble and Lake (Q3522417)
Planned use	items which are an instance of park (Q22698) for now, but all sorts of locations
See also	disabled accessibility (P2846), has part(s) (P527), has facility (P912), and has characteristic (P1552).

Motivation

A United States based organization named The Trust for Public Land (Q7770573) has a database of defining information and attributes for park (Q22698) spaces in the United States and beyond. I am proposing "has amenity" to list any positive feature of any park and more broadly any location in Wikidata. I think that "amenity" is the best general name for this concept but I wanted to talk through some senses of this concept for which I think this property could apply.

An "amenity" is a positive feature of a location which is a luxury beyond the expected norm of a location, like a jogging path in a park, a swimming pool in a hotel, or a seating court for people to congregate. The amenities enrich user experiences of a place, and might be a cause for going to a place, but themselves do not have unique names or their own individual character or Wikidata items.

A "public service feature" is a positive feature of a location which which makes it more accessible or comforting, but which itself is not a reason to visit. Examples include restrooms at parks, water fountains, information kiosks, or a parking lot.

An "mobility feature" is a property for locations describing available services or inbuilt positive design features which make a location more accessible for all kinds of people. Examples include an elevator at a subway station and wheelchair ramps at parks to serve people with limited mobility or features to serve people with vision or hearing challenges.

An "attraction" is a feature of a location which beyond an amenity is actually a draw for tourism. Tourist attracts will or can have their own named Wikidata items. Whereas a tourist is unlikely to travel to a particular foreign park for the sake of a "public service feature" like a restroom or an "amenity" like a jogging path, they might travel there to visit a monument which would be a named attraction. I am suggesting that the major difference between a general "amenity" and an amenity which is an "attraction" is that typical amenities have no unique name or Wikidata item while "attractions" do.

Prior art

• Commercial travel websites list amenities in their listings for hotels. See for example Tripadvisor (Q1770710) advertising that the Taj Hotel in Mumbai has a pool.
• The city of San Francisco reports on its website that Boeddeker Park has a basketball court. Many large cities have a "Department of Parks" or similar which shares this sort of information.
• Some parks departments have lists of public restrooms, such as the one from the NYC Parks Department.
• Seattle's Parks department has icons for some amenities uses text to report "meets the requirements of the Americans with Disabilities Act (ADA)", which I think merits featuring "accessibility" as an amenity.

Blue Rasberry (talk) 13:39, 8 February 2018 (UTC)

Discussion

•  Support David (talk) 15:19, 8 February 2018 (UTC)
•  Comment for Wikivoyage listings, at some point we created disabled accessibility (P2846).
  --- Jura 15:26, 8 February 2018 (UTC)
• Any reason not to use has part(s) (P527)? Also I'm loathe to see "accessibility" stated as an amenity, since it can mean very different things to, say, a wheelchair user and a blind person with a guide dog. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:13, 10 February 2018 (UTC)
•  Question How will this be different from has facility (P912)? --Pasleim (talk) 21:55, 10 February 2018 (UTC)
•  Question why not using the more generic has characteristic (P1552)? --Loominade (talk) 10:39, 21 February 2018 (UTC)

• @Bluerasberry: looks like this can be done with existing properties. What do you think? Do you want to withdraw this proposal?
  --- Jura 12:03, 25 February 2018 (UTC)

I would like to talk more. I just posted a "prior art" section. Blue Rasberry (talk) 16:26, 28 February 2018 (UTC)

@Jura1, Pigsonthewing, Loominade, Pasleim: Collectively you all suggested using more general existing properties including has part(s) (P527), has facility (P912), and has characteristic (P1552). The major reason why I think "amentity" merits its own property is because there is an established, popular precedent to designate "amenities" as its own class of data distinct from the other possible features to list. Owners of places routinely publish lists of place amenities in their own publications, and publishers including the most popular and familiar consumer websites and travel books also feature amenities as a data set distinct from other information. I am using examples from websites below, but this tradition of treating amenities as a class of data goes back decades in paper travel books which print amenities in list formats matched to locations. "Has part" and "Has quality" seem more general than the existing practice of designating amenities as their own class of data. "Has facility" could overlap in some places, such as for a restroom in a park but I am unsure about applying that to wifi access or multilingual staff. Does anyone have further thoughts about the extent to which other publications feature "amenity" as a type of location data, and the extent to which Wikidata can or should replicate the existing practice of sorting data in this way?

@Pigsonthewing, Jura1: You both pointed to the overlap with disabled accessibility (P2846). Can you comment on how Wikidata can sort all accessibility information? Suppose that Wikidata committed to list accessibility features. We have one for wheelchairs. Should we have separate properties to similarly describe whether a place can accommodate hearing or seeing disabilities? What about accommodation for people who require gender neutral restrooms? Larger people or people with movement challenges who need more room to move around, but for whom wheelchair accessibility is irrelevant? I could imagine either having a catch-all property for accessibility, or having individual accessibility properties, or using a higher level catch-all like "has amenity" to record these. Thoughts? Thanks. Blue Rasberry (talk) 16:26, 28 February 2018 (UTC)

Prior art in external publications

I want to share more context here to help with the conversation. There are many consumer-targeted database publications which describe amenities at places. I would like for Wikidata to develop equivalent infrastructure and be able to capture this data. Here are some examples of how this looks on other websites:

Yelp (Q2299611) - world's most popular and most developed publishing platform for places of local interest

• Cafe Allegro, a coffeehouse in Seattle
  • Parking Street
  • Bike Parking Yes
  • Outdoor Seating Yes
  • Wi-Fi Free
  • Gender Neutral Restrooms Yes

Metropolitan Museum of Art (Q160236)- most popular and best funded museum in the United States

• Accessibility features which this museum advertises on their own website
  • Wheelchairs
  • Service animals
  • Assistive Listening Devices
  • Real-Time Captioning
  • Sign Language Interpretation
  • Large Print
  • Audio Guide
  • Public Telephones

Tripadvisor (Q1770710), a popular website like yelp but more targeted to tourists

• Tripadvisor's posted amenities for Taj Mahal Palace Hotel (Q19104)

• • Pool
  • Room Service
  • Restaurant
  • Fitness Center with Gym / Workout Room
  • Free Internet
  • Free Parking
  • Spa
  • Bar/Lounge
  • Room Service
  • Business Center with Internet Access
  • Free Parking
  • Children Activities (Kid / Family Friendly)
  • Airport Transportation
  • Dry Cleaning
  • Meeting Rooms
  • Laundry Service
  • Concierge
  • Banquet Room
  • Multilingual Staff
  • Conference Facilities
  • Babysitting
  • Breakfast Available

Blue Rasberry (talk) 16:03, 28 February 2018 (UTC)

•  Comment This might be helpful for Wikivoyage, but if they don't actually use it and maintain it, I think it would create a lot of overhead here. I'd rather not create further Wikivoyage related properties if they aren't being used.
  --- Jura 08:22, 19 April 2018 (UTC)

@Jura1: Unfortunately I cannot promise use. I can say that en:Wikipedia:Wiknic is a recurring Wikipedia event with a picnic theme that includes editing content about parks. Also as I mentioned an organization called Trust for Public Land is considering sharing open data about parks in Wikimedia projects. They are participating in a Mozilla-coordinated hackathon for park data in May 2018 and I would like to model parks in Wikidata in advance of this event. I am not saying that the "has amenity" property is essential, but this kind of property seems to be the norm with Google, Yelp, OpenStreetMaps, and everything else as I mentioned above. I could model this with 3+ separate properties (wheelchair accessibility, has quality, has facility), or I could follow the norm in the industry and call all of these by one name. "Has amenity" would be general by Wikidata terms, being neither very specific nor overly general like "has quality". I hesitate to train anyone editing items for places to recognize distinctions between "qualities" and "facilities", like for example, in the case of public restrooms, wifi, or other amenities which could be either or both. Blue Rasberry (talk) 23:09, 19 April 2018 (UTC)

• marking as  Not done, the discussion has stalled without much support. Feel free to reopen if fresh interest arises − Pintoch (talk) 15:44, 20 June 2018 (UTC)