Shortcut: WD:PP/PLACE

Wikidata:Property proposal/Place

From Wikidata
Jump to: navigation, search

Property proposal: Generic Authority control Person Organization
Creative work Place Sports Sister projects
Transportation Natural science Lexeme

See also[edit]

This page is for the proposal of new properties.

Before proposing a property

  1. Check if the property already exists by looking at Wikidata:List of properties (manual list) and Special:ListProperties.
  2. Check if the property was previously proposed or is on the pending list.
  3. Check if you can give a similar label and definition as an existing Wikipedia infobox parameter, or if it can be matched to an infobox, to or from which data can be transferred automatically.
  4. Select the right datatype for the property.
  5. Start writing the documentation based on the preload form below and add it in the appropriate section.

Creating the property

  1. Once consensus is reached, change status=ready on the template, to attract the attention of a property creator.
  2. Creation can be done 1 week after the proposal, by a property creator or an administrator.
  3. See steps when creating properties.

On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2018/05.

No label[edit]

NRHP criteria[edit]

   Under discussion
Description criterion/criteria cited when a place is inscribed on the National Register of Historic Places
Represents Criteria for Evaluation (Q47035098)
Data type Item
Template parameter Could be used in en:Template:Infobox NRHP; not presently part of infobox
Domain place listed on the National Register of Historic Places (Q19558910)
Allowed values A (Q47035155), B (Q47035235), C (Q47035253), D (Q47035331)
Source General
Specific at "Applicable Criteria"
NRHP nomination: Baruh-Zell House (Q47135969) at PDF p. 8, upper left
Planned use Begin adding manually as a qualifier to the statement heritage designation (P1435):place listed on the National Register of Historic Places (Q19558910); ca. 52K items with that statement already exist
See also World Heritage criteria (P2614), criterion used (P1013)

The National Register of Historic Places (Q3719) in the United States consists of nearly 100K separate inscribed places; somewhat over half of those entities currently have items in Wikidata, with a continuous addition of more as expands its coverage of inscribed places. At present, the 50K+ existing items have a heritage designation (P1435) statement and/or a NRHP reference number (P649) statement and possibly a start time (P580) qualifier to give the place's inscription date. No properties exist to add further dimension to the inscription process by capturing data related to the scope, reasoning, or categorization the inscription within the National Register, although such data is readily available from numerous sources.

The proposed property is inspired by and modeled after World Heritage criteria (P2614), and is intended to be used exclusively as a qualifier to the statement heritage designation (P1435):place listed on the National Register of Historic Places (Q19558910). It would enrich Wikidata's coverage of the National Register by capturing the defined criteria officially cited in the inscription of a place on the register. By extension, the criteria provide a very broad characterization of the nature of a place's historic significance: related to a person who occupied a house (criterion B), for example, or a building's architectural importance (criterion C). — Ipoellet (talk) 22:41, 10 January 2018 (UTC)

  • Symbol support vote.svg Support Seem a good idea. We should probably check if the property could be used by other country so we don't have to create this kind of property for each country. --Fralambert (talk) 00:57, 11 January 2018 (UTC)
Perhaps repurpose World Heritage criteria (P2614) as "heritage criteria" rather than its current World Heritage-specific scope? Using the property only as a qualifier to heritage designation (P1435) would make clear to the casual browser which specific defined set of criteria is being cited. The problem I see with that is that World Heritage criteria (P2614) is presently used more in freestanding statements than in qualifiers. — Ipoellet (talk) 01:32, 11 January 2018 (UTC)
A freestanding property work just fine, I you see the use of World Heritage criteria (P2614) in frwiki (in the infobox of fr:Parc national Wood Buffalo). --Fralambert (talk) 02:41, 11 January 2018 (UTC)
  • Symbol support vote.svg Support David (talk) 07:40, 11 January 2018 (UTC)
  • OH, I forgot

Fralambert (talk) (Canada and United States)
Alicia Fagerving (WMSE) (talk) Yarl ✉️️  Spinster 💬 10:54, 6 March 2017 (UTC) Beat Estermann (talk) 09:49, 19 March 2017 (UTC) PKM (talk) Susanna Ånäs (Susannaanas) (talk) 05:57, 14 May 2017 (UTC) Acka47 (talk) 13:38, 29 June 2017 (UTC) --Carlojoseph14 (talk) 15:13, 30 June 2017 (UTC) Ainali (talk) 09:25, 17 August 2017 (UTC) VIGNERON (talk)
Pictogram voting comment.svg Notified participants of WikiProject Built heritage and Thierry Caro Roseohioresident

Pictogram voting comment.svg Notified participants of WikiProject United States. --Fralambert (talk) 01:50, 12 January 2018 (UTC)

  1. Copy all current labels to aliases
  2. Change labels as follows: en and en-gb -> "heritage criteria"; es -> "criterios de patrimonio"; fr -> "critère du patrimoine"; ast -> "criterios de patrimoniu"; ca -> "criteris de patrimoni"; pt -> "critérios do patrimônio"; delete all others (23) unless someone else can provide a translation
  3. Change descriptions as follows: en and en-gb -> "formal selection criteria in official heritage register programs"; es -> "criterios formales de selección en los programas oficiales de registro del patrimonio"; fr -> "critères formels de sélection dans les inventaires officiels du patrimoine"; delete all others (26) unless someone else can provide a translation
  4. Delete statement issued by (P2378):United Nations Educational, Scientific and Cultural Organization (Q7809)
  5. Add statement subject item of this property (P1629):Criteria for Evaluation (Q47035098) (World Heritage and NRHP are the only heritage programs I am especially familiar with - others could easily be added here) Delete statement subject item of this property (P1629):selection criteria for World Heritage (Q22809610) (per ArthurPSmith's suggestion below)
  6. Delete statements at Wikidata usage instructions (P2559)
  7. Add a Wikidata property example (P1855) from the NRHP
  8. Delete the statement at source website for the property (P1896)
  9. Add this discussion at property proposal discussion (P3254)?
  10. At property constraint (P2302):one-of constraint (Q21510859), add qualifications item of property constraint (P2305):A (Q47035155), B (Q47035235), C (Q47035253), D (Q47035331) (this qualification would be expanded for the future addition of other heritage programs)
  11. At property constraint (P2302):item requires statement constraint (Q21503247), add qualification item of property constraint (P2305):place listed on the National Register of Historic Places (Q19558910) (this qualification would be expanded for the future addition of other heritage programs)
  12. Add constraint used as qualifier constraint (Q21510863) with qualification constraint status (P2316):mandatory constraint (Q21502408) (NOTE: This change would go against existing consensus#P2614 as a qualifier of P1435 (in the WHS context only) that World Heritage criteria (P2614) may be used in either qualifiers or standalone statements at the editor's discretion.)
I have posted a note at Property talk:P2614 that this discussion is happening. Should I go ahead and make the changes above? — Ipoellet (talk) 18:35, 18 January 2018 (UTC)
@Ipoellet: this plan looks good to me. I'm not sure how the constraint changes you propose would work, so somebody better versed in that area might want to comment there. Also we don't normally have more than one value for "subject item of this property" - it might be better to just delete that rather than have two which could be confusing. I'm not sure on this. When you feel you are ready and people have had time to comment (give it a few days here I guess, I see you've linked this from the talk page on P2614) you should make these changes and also change the status field in the property proposal template above to "withdrawn", which will automatically remove it from various lists. ArthurPSmith (talk) 20:32, 18 January 2018 (UTC)
@ArthurPSmith: Thx for both perspective and guidance. — Ipoellet (talk) 20:50, 18 January 2018 (UTC)
Isn't the usage we're talking about here out of scope for that property? criterion used (P1013) is about Wikidata-specific criterion (Q27949687), while the WHS and NRHP criteria we're trying to capture are entities external to Wikidata. — Ipoellet (talk) 23:08, 20 January 2018 (UTC)
  • I began making the changes to World Heritage criteria (P2614) as discussed above. Those changes were immediately reverted by Jura1, presumably because that user did not feel her/his comments were adequately addressed in this discussion. I had taken Jura1's comments as a tentative suggestion, not as a statement of opposition to the discussed course of action; thus, I thought consensus had been reached. I regret the miscommunication.
I do not agree with Jura1 that the proposed usage (heritage selection criteria) is within the present scope of criterion used (P1013). Both the property page itself and the discussion linked by Jura1 make clear that the property is intended to capture the parameters within which a quantitative measurement is made, not to document a qualification "hurdle" crossed in assigning an entity a particular status - only the property's label fits the heritage criteria usage. I do not have an objection to modifying criterion used (P1013) to change its scope, but other users might and I feel World Heritage criteria (P2614) is a more natural fit.
We seem agreed in this discussion that NRHP criteria are a direct analog to World Heritage criteria, and are worth capturing in Wikidata. Given that, there seem to be three options:
  1. Create a new property for NRHP criteria as originally proposed
  2. Modify World Heritage criteria (P2614) to change its scope to accept NRHP criteria
  3. Modify criterion used (P1013) to change its scope to accept qualitative criteria such as heritage criteria, then collapse World Heritage criteria (P2614) into it
If I was wrong that we had arrived at #2 as a consensus, then how can this be done? — Ipoellet (talk) 17:55, 26 January 2018 (UTC)
  • I don't think we should rescope properties as widely as suggested here. I don't really have a preference between creating a new property that covers NRHP or just using the existing criterion used (P1013) which seems a perfect fit if you'd like to use it for any heritage criteria.
    --- Jura 18:07, 26 January 2018 (UTC)
  • Pictogram voting comment.svg Comment A bit of context not previously aired: The proposed property would correspond to OSM key nrhp:criteria. — Ipoellet (talk) 06:37, 19 February 2018 (UTC)

has amenity[edit]

   Under discussion
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)

The Taj Mahal Palace Hotel (Q19104)swimming pool (Q1501)

Gas Works Park (Q5526323)accessibility (Q555097)

Times Square – 42nd Street (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 wheelchair accessibility (P2846), has part (P527), has facility (P912), and has quality (P1552).


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

Blue Rasberry (talk) 13:39, 8 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 (P527), has facility (P912), and has quality (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 wheelchair 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

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

  • Pictogram voting comment.svg 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)

Church of Sweden ID[edit]

Data type External identifier
Domain parish of the Church of Sweden (Q615980)
Planned use Add in by hand until I learn how to automate the task
Number of IDs in source >3,500
Expected completeness eventually complete
Formatter URL$1


The Church of Sweden has a database with an entry for each diocese, and each pastorate in the diocese, and each church building (kyrke) in the pastorate. Wikidata has some entries for individual churches, but most articles are on the parish, and that article also has information on the church. I suggest that we add the link to the parish (församling) when we do not yet have an entry for the individual church building. We can always add the link to the church if someone decides to make an entry. We already have links to one Swedish code "Church of Sweden parish code" but that doesn't link to any searchable database. Church of Sweden ID links to a full history of each church. There are also pages for each pastorate that contains multiple churches and links to each diocese. This is similar to the Roman Catholic hierarchy database RAN (talk) 23:10, 2 March 2018 (UTC)


  • Symbol support vote.svg Support David (talk) 15:38, 3 March 2018 (UTC)
  • Symbol support vote.svg Support --Anvilaquarius (talk) 11:47, 17 March 2018 (UTC)
  • Symbol support vote.svg Support --Fralambert (talk) 03:17, 12 April 2018 (UTC)
  • Pictogram voting comment.svg Comment do we really want the URL datatype? − Pintoch (talk) 16:36, 13 April 2018 (UTC)
Change it to what you think is best. --RAN (talk) 04:32, 14 April 2018 (UTC)
I have changed it to external-idPintoch (talk) 10:33, 14 April 2018 (UTC)

@ديفيد عادل وهبة خليل 2, Fralambert, Richard Arthur Norton (1958- ), Pintoch, Anvilaquarius: ✓ Done: Church of Sweden ID (P5048). − Pintoch (talk) 22:37, 14 April 2018 (UTC)

accessed from[edit]

   Under discussion
Description place from which one accesses another most of the times
Represents no label (Q52139510)
Data type Item
Domain geographical object (Q618123)
Allowed values geographical object (Q618123)


This would be useful to document the contiguity between rooms in a famous building, for instance. Thierry Caro (talk) 00:21, 23 April 2018 (UTC)


  • Symbol oppose vote.svg Oppose I do not think it's a useful addition David (talk) 15:31, 23 April 2018 (UTC)

topographic map[edit]

   Ready Create
Description topographic map covering the said geographic object
Represents topographic map (Q216526)
Data type Item
Template parameter |topo= in en:Template:Infobox mountain, to begin with
Domain geographical object (Q618123)
Allowed values Instances of topographic map (Q216526)
Planned use no label (Q52421419), among others
See also relief location map (P1944)


This is much needed to improve our items about mountain (Q8502) or walking path (Q2143825), for example. The property is a basic one in many ontologies dealing with them. Note that for the moment we have almost no item on individual maps, even those from the most popular series. Thierry Caro (talk) 10:50, 1 May 2018 (UTC)


Koxinga (talk) Thierry Caro (talk) Pasleim (talk) Runner1928 (talk)

Pictogram voting comment.svg Notified participants of WikiProject Mountains. Thierry Caro (talk) 10:50, 1 May 2018 (UTC)

  • Symbol support vote.svg Support David (talk) 15:11, 1 May 2018 (UTC)
  • Pictogram voting question.svg Question Why not link to images directly? NMaia (talk) 12:37, 2 May 2018 (UTC)
    • Images of maps are covered through relief location map (P1944), for instance. This is about map editions and refers to the works of established editors, unlike the maps available on Commons. Thierry Caro (talk) 10:42, 3 May 2018 (UTC)

forest cover[edit]

   Under discussion
Description percentage of land area covered by forests or the forest canopy or open woodland. Use qualifiers "determination method" and "point in time" to state how and for which year it's computed.
Represents forest cover (Q49001692)
Data type Quantity
Allowed values >=0,<=100
Allowed units percentage (Q11229) (same as P2927)
Planned use import w:Forest cover by state in the United States
See also water as percent of area (P2927)


@Amadalvarez, Jey, Thayts, Thierry Caro, B.Zsolt:@Triggerhippie4, Cavaliere grande: this is similar to water as percent of area (P2927) you already used.
--- Jura 12:10, 6 May 2018 (UTC)


  • @Jura1: Conceptually, it's similar. To me, the difference is that water as percent of area (P2927) talks about a geographical characteristic (more or less stable), but this new property could by related with a set of country developement indicators as the World Bank (Q7164) handle in its opendata series, like this one: Amadalvarez (talk) 12:59, 6 May 2018 (UTC)
    • Let's say it's less clear-cut. I don't think it says much about Nevada's development, but the more sources are available, the better.
      --- Jura 13:05, 6 May 2018 (UTC)
  • Symbol support vote.svg Support David (talk) 14:45, 6 May 2018 (UTC)
  • Symbol oppose vote.svg Oppose Better to have a generic "Land use" property, qualified with a percentage or area (i.e. Land use=forest; percentage =89%; Land use=industry, percentage=5%, etc.). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:40, 6 May 2018 (UTC)
  • Symbol oppose vote.svg Oppose per Andy --Pasleim (talk) 21:29, 6 May 2018 (UTC)
  • Symbol oppose vote.svg Oppose I agree with Andy and Pasleim. However, Will "Land use" accepts physical/geographical criteria like water, desert or forest.. and economical/development values as industry, agriculture, residential, etc. ?. Or do we have two differents properties for this two kind of classification ?. In any case, the future of water as percent of area (P2927) is affected by the new "land use" property in order to avoid overlapping concepts. Thanks Amadalvarez (talk) 06:07, 8 May 2018 (UTC)
    • @Amadalvarez: do we have a sample where that approach actually works? I know you edit in the field, so I suppose your suggestion isn't just a theoretical one. Wikidata is somewhat limited by fact that qualifiers on qualifiers aren't possible and properties with multiple values are hard to aggregate.
      --- Jura 06:18, 8 May 2018 (UTC)
      • @Jura1: I don't work too much. I used water as percent of area (P2927) just in infoboxes and the manual parameters the infoboxes had since the beginning of the WPs were exactly this and no one else. So, I did not figure out any other value at that moment. However, cause of this proposal, I wonder if "% of forest would be the last proposal" or it will open a new world of classification, then I searched and found the above reference of worldbank. I don't bet to have a close list of values and, I understand, the Andy's proposal is an open list. However, any classification should have excluding values (among them) to avoid ambiguities or overlap, and must add 100% or less. Probably, someone needs to describe "the territori" (water, desert, forest, tundra, etc.) and it should not be mixed with an "economical point of view" ( industry, agriculture, residential, etc.), because it will most likely overlap with the other criteria because they may not be excluding concepts. I appologise to have a common sense (but theoretical) approach. Now, I found a good document showing that "land use classification" is not an easy simple matter. Sorry.Amadalvarez (talk) 17:35, 8 May 2018 (UTC)
        • @Amadalvarez: Thanks for your feedback. I thought I'd better ask you as you already added quantity properties and would have some practical experience with it. It does seem complicated to add more data about land, beyond simple ones like water or forest. As there doesn't seem to be any demand for the others and international organizations don't combine them either, maybe we should try to focus on the task at hand. If ever needed, a parent property could be added to the existing P2927 and this one. How should we go about it?
          --- Jura 05:54, 9 May 2018 (UTC)
          • @jura1: I like the Andy's proposal and my first comment just added some complexity seeing there are not a clear (and few) classifications method. So, in my opinion, we can approve this proposal "as is" hopping nobody else will ask for any other single and specific value, or else, suggest to the proponent change this proposal in the way Andy said (Land use). In fact, it means change to a "more open and versatile version" that covers perfectly the original needs manifested in the proposal. If David, Andy Mabbett, Pasleim and You agree with this second option, we can try to re-focus and vote again. Thanks, Amadalvarez (talk) 16:40, 9 May 2018 (UTC)
            • You could easily create several properties if ever needed. Properties can be subproperties of another one. The question is if there is any demand or practical use for the alternate proposal. I understand it might appear tempting, but Wikidata isn't exactly a table based database. Maybe there are working samples we could compare with.
              --- Jura 08:39, 13 May 2018 (UTC)
  • Pictogram voting comment.svg Comment Very good idea, but something like french "classes d'habitats" (see [1]) that is to say habitat (Q52105) would be better, talking about ecology, and perhaps "land use" as bove for human activity. --El Caro (talk) 11:16, 13 May 2018 (UTC)

Victorian Heritage Register ID[edit]

Description identifier in Victorian Heritage Register, Australia
Data type External identifier
Domain Victorian Heritage Register listing (Q28147634)
Allowed values H\d+
Planned use import monuments with this ID, part of Australian WLM preparations
Expected completeness eventually complete (Q21873974)
Formatter URL$1
See also Victorian Heritage Database ID (P3443)


Another ID for monuments in Victoria, Australia. Yarl 💭  10:36, 13 May 2018 (UTC)


  • Symbol support vote.svg Support David (talk) 13:55, 13 May 2018 (UTC)
  • Symbol support vote.svg Support – has worked well for other Australian states, and I intend to populate this property widely. --Canley (talk) 03:14, 15 May 2018 (UTC)
  • Symbol support vote.svg Support An uncontroversial benefit to WLM and to Wikidata generally. MartinPoulter (talk) 15:50, 15 May 2018 (UTC)
  • Symbol support vote.svg Support - Nickw25 (talk) 11:40, 20 May 2018 (UTC)

@ديفيد عادل وهبة خليل 2, Nickw25, Canley, MartinPoulter: ✓ Done: Victorian Heritage Register ID (P5177). − Pintoch (talk) 13:34, 20 May 2018 (UTC)

German school district[edit]

   Under discussion
Description German school district to which a settlement belongs
Represents no label (Q1669809)
Data type Item
Domain settlements
Example no label (Q53314947) → Wert no label (Q53527631), a qualifier of (P642) can be used to determine the school type primary school (Q9842), middle school (Q149566)
Planned use assign all settlements of Bavaria to their Schulsprengel


In moment I capture many data from the "Amtlichen Ortsverzeichnisse von Bayern" (f.e. Amtliches Ortsverzeichnis für Bayern (1973) (Q15717443), Amtliches Ortsverzeichnis für Bayern (1991) (Q15707237)) . I want to capture the data so completely than possible. Therefore this property is necessary. Balû (talk) 06:29, 15 May 2018 (UTC)


  • Symbol support vote.svg Support David (talk) 13:56, 15 May 2018 (UTC)
  • Symbol support vote.svg Support This might also be generalizable to other countries? In the US one "settlement" may have several school districts, but I think it would be ok to just list them (rather than worrying about the precise boundary lines). ArthurPSmith (talk) 17:53, 15 May 2018 (UTC)


   Under discussion
Description For any geographical location (below with the example of a fountain) I would like not just to have a still image, but a clickable street-view link.

Google doesn't appear to offer an API for this ( so we need to crowd-gather this. e.g. for fountain the below example would apply.

A URL to access a service that allows to visually navigate through a 3D environment in the proximity of the item
Data type URL
Example or more open (unfortunately not visible due to construction material)


At and any further use of this showcase framework (e.g. [public] toilets for handicapped, childrens playgrounds, park benches, ...) it can be helpful to be able to easily explore the surroundings of the object of interest.

It is not possible to query the Streetview Service semantically for visible items such as a fountain (nor to discover a fountain based on the approximate geographical coordinates), therefore this new property allows for a crowd data gathering of the best streetview URL for the item at hand. Also if more open services than the google service appear, this can also be used for such a service.  – The preceding unsigned comment was added by Ralfhauser (talk • contribs) at 06:42, April 27, 2018‎ (UTC).


property name

"StreetView" is strongly linked to a Google service. The generic term would be "Street-Level Imagery".

 > 'streetPanorama360navigatorUrl' is fine too - how would I rename the proposal ?


Must this property link specifically to a 360 panorama navigator on the web, or would a URL to any image-like content be ok?

 > I image-like content should rather be handled as image (P18) in Wikimedia
  • Symbol support vote.svg Support I like the idea of having the opportunity to link from a wikidata POI to a 360° Panorama View. Instead or additional to Street View one could eventually also use Mapillary. Marco Sieber (talk)
  • Symbol support vote.svg Support This feature would make Wikidata more useful to users looking to find out more about the spatial context of landmarks. Matthew (talk) 07:26, 17 May 2018 (UTC)
  • Symbol oppose vote.svg Oppose For the stated use-cases, coordinates suffice. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:52, 20 May 2018 (UTC)


Please visit Wikidata:WikiProject Space for more information. To notify participants use {{Ping project|Space}}