Jump to content

Wikidata:Property proposal/Place

Shortcut: WD:PP/PLACE
From Wikidata



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

See also

[edit]

This page is for the proposal of new properties.

Before proposing a property

  1. Search if the property already exists.
  2. Search if the property has already been proposed.
  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. Read Wikidata:Creating a property proposal for guidelines you should follow when proposing new property.
  6. Start writing the documentation based on the preload form below by editing the two templates at the top of the page to add proposal details.

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 creation of the proposal, by a property creator or an administrator.
  3. See property creation policy.


Filial church

[edit]

Park

[edit]

Hierarchy of administrative territorial entities

[edit]

Divided into cadastral areas

[edit]
   Under discussion
DescriptionList of cadastral areas of municipality
Representscadastral municipality (Q253326)
Data typeItem
Domainitem
Example 1Boršov nad Vltavou (Q894336): Boršov nad Vltavou (Q110319826), Zahorčice u Vrábče (Q110319775) (more parts than CA)
Example 2Dívčice (Q645185): Dívčice (Q110390726) (only one CA, five parts)
Example 3Míšov (Q741186): Míšov (Q110186490), Míšov v Brdech (Q110186492) (more CA's than parts)
Allowed valuescadastral municipality (Q253326)
Planned useUse on Wikipedia
See alsoassociated cadastral district (P10254), contains the administrative territorial entity (P150), contains settlement (P1383)

Motivation

[edit]

Municipalities in some countries are divided to administrative parts and cadastral areas (CA). Sometimes are these diivisions equal, but sometimes not. There exists contains the administrative territorial entity (P150) for first type, and its opposite located in the administrative territorial entity (P131). Now we need opposite for associated cadastral district (P10254).

Example: Municipality Boršov nad Vltavou (Q894336) have two cadastral areas and four parts:

But there are also municipalities with many parts and only one CA, municipalities, where most parts are equals with CA, but in some CA exists more parts or municipalities, where is CA without settlement on it - this is why is not good to use contains settlement (P1383)

There is also possibility to use located in the administrative territorial entity (P131) with qualifiers, but this would make many queries and templates more complicated. There are situations, when municipality Foo have part Foo and CA Foo, but on CA Foo is also part Bar

As you can see, there is too much confusing Foos

On cs.wiki there is template {{Části obce}}, which lists for every municipality its parts using located in the administrative territorial entity (P131) and contains settlement (P1383). But CA are now connected with its municipality only by backlinks and cannot be listed with this template.

So i think, the best solution is to create new property for this

Notified participants of WikiProject Czech Republic @Maincomb, Emu, Arbnos, MasterRus21thCentury:JAn Dudík (talk) 09:36, 8 February 2022 (UTC)[reply]

Discussion

[edit]
I just modified Boršov nad Vltavou (Q894336), because associated cadastral district (P10254) can be used in both directions. Is this what you need? Second, the template cs:Šablona:Části obce mentioned above does not exist. --Maincomb (talk) 17:03, 8 February 2022 (UTC)[reply]
@Maincomb: Correct link is cs:template:Části české obce. I'll think about your usage, I'm afraid, these should be some issues with it. JAn Dudík (talk) 19:54, 8 February 2022 (UTC)[reply]

Second discussion

[edit]

Reopening this request since it turns out (see Property_talk:P10254#(Mis)use_for_Austria?) that using associated cadastral district (P10254) in two completely different (opposite even) ways is far from ideal. JAn Dudík, Sapfan, Daniel Baránek, Maincomb, Zelenymuzik, Vojtěch Dostál, MasterRus21thCentury, ArthurPSmith, Herzi Pinki --Emu (talk) 07:19, 4 July 2025 (UTC)[reply]

Discussion

[edit]

Street

[edit]

Body of water

[edit]

Geographic location

[edit]

waymark id

[edit]
   Under discussion
Descriptionunique identifier assigned to a waymark by Waymarking
Representswaymark code (Q131302871)
Data typeExternal identifier
Example 1Califaro Tank House (Q131302837)→wm3V8B
Example 2Gropers Bush Public Library (Q73575126)→wm72WT
Example 3Four Freedoms Monument (Q642848)→wm9KAM
Example 4Birth of Mary parish church (Q2082637)→wm15WN8
Allowed valueswm[A-Z\d]{1,5}
External linksUse in sister projects: [ar] • [az] • [bn] • [de] • [en] • [es] • [fa] • [fr] • [he] • [hi] • [it] • [ja] • [ka] • [kn] • [ko] • [ml] • [mr] • [nl] • [pl] • [pt] • [ro] • [ru] • [sv] • [te] • [tr] • [ur] • [vi] • [zh] • [commons] • [species] • [wd] • [en.wikt] • [fr.wikt].
Number of IDs in source1177409 (date : 2025-02-12 ref)
Expected completenesseventually complete (Q21873974)
Formatter URLhttps://www.waymarking.com/waymarks/$1
Applicable "stated in"-valueWaymarking (Q465630)
Single-value constraintyes
Distinct-values constraintyes
Wikidata projectWikiProject Geocaching (Q21830041)

Motivation

[edit]

These codes are displayed prominently in the contents and URL of each Waymarking entry. Some Waymarking categories demonstrate notability. – Minh Nguyễn 💬 09:21, 22 November 2024 (UTC)[reply]

Discussion

[edit]

‎Archaeological Cadastre (Greece) map ID

[edit]
   Under discussion
Descriptionidentifier in the Archaeological Cadastre of the National Archive of Monuments (Greece)
RepresentsArchaeological Cadastre (Q131569092)
Data typeExternal identifier
Example 1Temple of Apollo in Delphi (Q10751359) → Monument&id=161857
Example 2Kerameikos (Q630974) → Space&id=166637
Example 3Monemvasia (Q654616) → Historical&id=165060
Example 4Delphi Archaeological Museum (Q636928) → Museum&id=87369
Example 5Ithaca (Q187471) → Natural&id=168098
Sourcehttps://www.arxaiologikoktimatologio.gov.gr/en
Number of IDs in source17,000 immovable monument (Greece) (Q131574095), 3,100 listed archaeological site, Greece (Q29048715), 420 historical site (Greece) (Q131573702), 220 museum (Q33506), ? Landscape of Special Natural Beauty (Q131596951)
Expected completenesseventually complete (Q21873974) / always incomplete (Q21873886) (the protection zone (Q131574369) may never be linked to a wikidata item)
Formatter URLhttps://www.arxaiologikoktimatologio.gov.gr/search-data-map/?type=$1

Motivation

[edit]

Not only geographic data, but this also attests to the heritage designation status of, and provides an identifier for, >20,000 Greek immovable cultural goods; thank you, Maculosae tegmine lyncis (talk) 18:44, 27 December 2024 (UTC)[reply]

Discussion

[edit]

The Church of Agia Sofia (Q68490039) at Monemvasia (Q654616) has the map search address https://www.arxaiologikoktimatologio.gov.gr/el/search-data-map/?type=Monument&id=162754; if you click on the folder icon, you are directed to the data page https://www.arxaiologikoktimatologio.gov.gr/el/monuments_info?id=162754&type=Monument; the id is the same (162754); is the one identifier sufficient? Thanks, Maculosae tegmine lyncis (talk) 20:17, 27 December 2024 (UTC)[reply]

I checked to see if "https://www.arxaiologikoktimatologio.gov.gr/el/monuments_info?id=" would be sufficient for the URL format, but unfortunately it doesn't cover the "Museum" type. That's sad as this URL format would be better choice for linking to the actual data rather than having to do two clicks on the map to view them in a separate page (as clicking on the URL only zooms the map on that location highlighting the item).
Also, this online catalogue of the monuments (which acts as a replacement of "odysseus.culture.gr" especially after the outage it occurred to it last year) contains some location issues. Most of them not severe, but there are occasions which the location is totally unrelated. One severe occasion is Church of Saint Charalampus, Argos (Q112481362) which arxaiologikoktimatologio points at a location where another church of the same name exists but is unrelated with the one it describes (about 500m away).
In general, I'm pretty fine with this proposal. It's something that is needed now that we have this more modern digital list of cultural heritage (more modern than odysseus.culture.gr I mean, even though arxaiologikoktimatologio.gov.gr seems to contain much less description than the other).--Jimkats (talk) 22:09, 29 December 2024 (UTC)[reply]
Thank you; I have added Wikidata:Property proposal/Archaeological Cadastre (Greece) info ID, for the information pages (the museums don't have one), Maculosae tegmine lyncis (talk) 22:19, 4 January 2025 (UTC)[reply]

A good idea. The Cadastre's publically facing website is designed currently to be an almost useless partial representation of the underlying database, with the intent legal/bureaucratic rather than educational/scientific. Coordinates are indeed sometimes off and you don't get an answer when you offer a correction. Many entries are for zones of protection around an archaeological site, rather than for the site itself. Many ancient sites are missing because never formally declared as protected. Still, it's important. There is a scrape of the map view made by a friend as a Google Doc, some 6200 items, but I haven't tried to analyze what is missing. I tried using the coordinates in QGIS to join it to the nearest WikiLovesMonuments item in Greece. Where the distance was small I eyeballed them, and if the match was good (though it often wasn't) I added the Cadastre URL as reference URL (P854) where heritage designation (P1435) is listed archaeological site, Greece (Q29048715) or protected building in Greece (Q29048696). e.g. St. Paul's Anglican Church, Athens (Q12872955). Those should be easy to extract and reuse once the new property is approved. Someone better at GIS should repeat the process, and there are plenty of new WD items to create. JBradyK (ToposText) (talk) 07:17, 6 January 2025 (UTC)[reply]

I'm afraid it is—I believe this is currently the best public offering through the National Archive of Monuments (Q131567296), Maculosae tegmine lyncis (talk) 22:42, 6 January 2025 (UTC)[reply]

‎trove.scot ID

[edit]
   Under discussion
Descriptionidentifier for heritage sites in Scotland
Representstrove.scot (Q134474889)
Data typeExternal identifier
Example 1Edinburgh Castle (Q212065) –> place/52068
Example 2HMS Royal Oak (Q620472) –> place/102373
Example 3Stone of Scone (Q756442) –> object/6132
Example 4brigantine (Q189418) –> thesaurus/3/501851
Allowed values[a-z]+\/\d+
Number of IDs in source1 million items, constraint is how many Scotish heritage objects we have
Formatter URLhttps://www.trove.scot/$1
URL match pattern^https?:\/\/www\.trove\.scot\/([a-z]+\/\d+)
CountryUnited Kingdom

Motivation

[edit]

Canmore (Q5032525) is being retired in June 2025 (see https://www.historicenvironment.scot/about-us/news/retiral-of-hes-web-services), so we need to replace Canmore ID (P718) with a new property, as the new system has broader scope. The system seems to have sections place/object/archive/image/decision/thesaurus, so it seems preferable to include the section name in the ID rather than have multiple IDS. I have contacted them to check that the Canmore ID (P718) formatter https://canmore.org.uk/site/XXXXX (https://canmore.org.uk/site/52068 for Edinburgh Castle) maps exactly to https://www.trove.scot/place/XXXXX (eg https://www.trove.scot/place/52068 for the castle), so we can move the 100000 items there across automatically.

I also propose abandoning the properties Canmore maritime-type ID (P7906), Canmore object-type ID (P7907) and Canmore monument-type ID (P7922) and merging their paltry results (6 in each case) into here. Vicarage (talk) 09:08, 16 May 2025 (UTC)[reply]

Discussion

[edit]

@YULdigitalpreservation, ArthurPSmith, Andrew Gray, 99of9, Jheald: as interested in Canmore stuff in the past.

Not sure the URL match pattern or allowed values are correct yet. Vicarage (talk) 08:50, 16 May 2025 (UTC)[reply]

 Support Useful resource. Can someone check if it is always the case that the ID from Canmore will point to a place/site and not object pages etc? If this is the case then it might be possible to automatically populate new claims. By the way, those other Canmore properties link to dictionary entries not objects. Infrastruktur (talk) 09:49, 16 May 2025 (UTC)[reply]

They say
I’m Alex Duthie, the Continuous Improvement Manager for trove.scot.
Thank you for your recent enquiry regarding links to the Canmore website. You are correct that we have consciously set up the trove.scot URLs to mirror the Canmore URL structure, when it comes to ‘Place’ records.
As per my response on Wednesday, we are implementing re-directs for Canmore, meaning that Canmore URLs will continue to work, redirecting users to the equivalent trove.scot page.
These will be in place in time for the retiral of the Canmore website on the 24th June. Vicarage (talk) 18:38, 23 May 2025 (UTC)[reply]
  • Comment @Vicarage: Since the new service is supposed to be a drop-in replacement for the existing functionality, would it not make sense just to re-name and re-point the current existing properties to point to trove.scot when/if Canmore gets switched off.
(Therefore I guess  Oppose creation of the new properties, unless someone can suggest some compelling reason for them)
"Canmore ID" could be kept as an alternative name, & the former URL formatter kept as a deprecated (but retained) value. Jheald (talk) 22:02, 25 May 2025 (UTC)[reply]
PS: I trust people have seen this devastating thread on Bsky by User:Tagishsimon, formerly of this parish, about the utter inadequacy of search on the new trove.scot platform. Not fit for purpose, not even close. If you have a contact at HES, might be worth asking if they have seen it or have any thoughts/comments about it. On the face of it, no way the existing sites should be turned off unless this is addressed. Jheald (talk) 22:17, 25 May 2025 (UTC)[reply]
I have no influence at trove.scot. It does seem a shame that Tagishsimon was forced off wikidata, I always found him helpful. But we need to accept their plans, and can't expect Canmore to be reprieved. Vicarage (talk) 22:26, 25 May 2025 (UTC)[reply]
@Vicarage @Jheald hi folks - update from HES which could be relevant here, apologies if you're already aware. HES expect that the redirects from Canmore, Scran and the Portal to trove.scot to be indefinite. Those that were from the pre-canmore site (rcahms.gov.scot domains) had to be severed due to changes in the permissions for redirecting gov.uk domains, this is not anticipated to apply to .org.uk, .ac.uk and .scot.
Portal (portal.historicenvironment.scot) is likely to retired towards the end of the year, when this happens, entries for the records will redirect towards trove.scot. Eg: https://portal.historicenvironment.scot/apex/f?p=1505:300:::::VIEWTYPE,VIEWREF:designation,SM13798
will redirect to:
https://www.trove.scot/designation/SM13798 Sara Thomas (WMUK) (talk) 09:27, 17 June 2025 (UTC)[reply]
They seem to have broadened the scope a lot
trove.scot is a new platform bringing together our diverse collections in one convenient place. It combines information from our Historic Environment Portal, Canmore and our Property in Care Collections, as well as Scran which holds images and media from galleries, museums, libraries and archives across the country.
As of 24 June 2025 Canmore, Scran and ScotlandsPlaces will be switched off.
Later in the year we’re aiming to retire HLA (Scotland’s Historic Land Use) and Property in Care Collections.
Longer term we’ll also be looking at the Historic Environment Portal, PastMap, Dictionary of Scottish Architects and the Buildings at Risk Register.
Because of the big scope change and because the trove ids will need the word 'place actively in the link (Canmore had 'site' in the formatter text), it seemed cleaner not to reporpoise the property. I don't know anything about the other systems they plan to amalgamate, but we do have 3 feeble Canmore spin-off properties that should be folded in to this. Any user of Canmore IDs that hard wires their formatter will break as we change the entries. My site (https://warlike.info) creates them from the combination, but I don't know how many other sites use the Canmore property and will be affected. It seems standard practice to create new properties for complicated situations like this.
I expect trove will subsume Historic Environment Scotland ID (P709) soon, and Scottish Buildings at Risk ID (P11091) at some point. Perhaps this can all be folded into a renamed Canmore id, but I don't like the idea. Vicarage (talk) 22:22, 25 May 2025 (UTC)[reply]
I would prefer to keep the properties for the different bits of Trove separate.
It should be no problem to have the updated URL formatter use 'place' rather than 'site'.
People with sites that have hardwired the old URL formatter should be okay, because HES are promising not to break existing links, but to redirect them appropriately. Jheald (talk) 22:45, 25 May 2025 (UTC)[reply]
Trove already has 6 keywords I aware of, I think it would be a very bad idea to keep chasing them, especially for our entries that cross their boundaries. Having 4 Canmore ones was a bad idea, as 3 were stillborn. Vicarage (talk) 22:52, 25 May 2025 (UTC)[reply]
@Vicarage: I don't see any value in lumping together thesaurus entries in with places. They are very different types of data, with different structures to fill (eg the structure of broader concept (P4900) qualifiers for thesauruses), different techniques for matching, different constraints to maintain, and a meaningful usefulness in keeping different completion statistics. I'm sorry the Canmore thesaurus entries never quite got to the top of my personal to-do (along with some other thesauruses that I think it would be incredibly valuable to match). But I do think there is value in (a) keeping them as wiki-matching projects in their own right, and (b) keeping them, and other thesauruses, separate from non-thesaurus statements. Jheald (talk) 19:38, 27 May 2025 (UTC)[reply]
We have the problem that because you oppose the creation of the property as a whole, we will have no way of adding in any of the information trove.scot will add in the future on any subject (apart from ex-Canmore if we re-porpoise it), unless we create 6+++ properties for each facet of their database structure. I will oppose that idea in turn. Fundamentally, the question people want answered is "what does Canmore say about this subject", or "what does trove.scot say about this subject". Partitioning properties in our system based on the vagaries of their system makes no sense, as we have to map our ontologies to theirs.
Look at the 6 Internet Speculative Fiction Database (Q2629164) properties, or the 4 Three Decks (Q68966143) ones, where I still have to use described by source (P1343) because I want to refer to their dockyard entries. This is why I use described by source (P1343) for The Victorian Royal Navy (Q130385287), because I don't want to create a raft of properties for that site too. Broader is better. Vicarage (talk) 19:49, 27 May 2025 (UTC)[reply]
I've asked for others' opinion on Project chat. Vicarage (talk) 20:05, 27 May 2025 (UTC)[reply]
I strongly support multiple properties for different kinds of objects. See CofE archives catalogue ID (P9483), CofE archives name ID (P9485) and CofE archives place ID (P9491) for a similar approach. - PKM (talk) 18:55, 8 June 2025 (UTC)[reply]

‎Long Distance Walkers Association path ID

[edit]
   Under discussion
DescriptionExternal Identifier (URL slug) for a hiking route on The Long Distance Walkers Association website (United Kingdom only)
RepresentsLong Distance Walkers Association (Q6672515)
Data typeExternal identifier
Domainitem
Example 1Wales Coast Path (Q656280)→Wales+Coast+Path
Example 2Ulster Way (Q7880058)→Ulster+Way
Example 3Greenwich Meridian Trail (Q133847227)→Greenwich+Meridian+Trail
Sourcehttps://ldwa.org.uk/ldp/members/search_by_path.php
Number of IDs in sourceOver 1,600 with more created each year
Expected completenessalways incomplete (Q21873886)
Formatter URLhttps://ldwa.org.uk/ldp/members/show_path.php?path_name=$1
Robot and gadget jobsPotential for a bot to convert described at URL (P973) links that follow the formatter URL otherwise requires a human to match or create items
Applicable "stated in"-valueLong Distance Walkers Association (Q6672515)
Single-value constraintyes
Distinct-values constraintyes

Motivation

[edit]

The Long Distance Walkers Association (abbreviated as LDWA) has profiles on many hiking trails in the UK (not all of them are actually "long distance", eg "H.M.Stanley - Town Trail →[1]" which is 2 miles).

I've been adding the links as described at URL (P973) to prove notability (or rather existence) of trails found on OpenStreetMap, Wikipedia or Wikimedia Commons when creating or updating items here on Wikidata. Having an external identifier would be neater and allow a willing user (not me) to import missing routes (of which there are likely hundreds if not 1,000+). The outlink to the LDWA website is probably also something a data consumer would expect (they claim to have 10,000 members).

The formatter URL will need checking as I've noticed the website adds " menu_type=S& " after " show_path.php? " sometimes, although removing it does nothing and the URL slug (after the =) is unchanged.

Tæppa (talk) 22:09, 27 April 2025 (UTC)[reply]

Discussion

[edit]
Name updated. Jheald (talk) 11:36, 2 May 2025 (UTC)[reply]
  •  Support Our coverage of long-distance UK walking paths and cycle routes is currently poor. This would be a good step in the right direction. (And I think valuable to OSM too). If there are some items matched already, using 'described at URL' it 100% makes sense to move them to a dedicated documented property. Jheald (talk) 11:34, 2 May 2025 (UTC)[reply]

ScholarGPS country profile ID

[edit]
   Under discussion
Descriptionidentifier for a country profile on ScholarGPS
RepresentsScholarGPS (Q135840843)
Data typeExternal identifier
Domaincountry (Q6256)
Example 1Argentina (Q414) → AR
Example 2Bangladesh (Q902) → BD
Example 3Germany (Q183) → DE
Example 4Haiti (Q790) → HT
Example 5India (Q668) → IN
Example 6Japan (Q17) → JP
Example 7Mauritius (Q1027) → MU
Example 8Saudi Arabia (Q851) → SA
Example 9Zambia (Q953) → ZM
Allowed values[A-Z]{2}
Sourcehttps://scholargps.com/countries
Planned useadding to country items
Expected completenesseventually complete (Q21873974)
Formatter URLhttps://scholargps.com/countries/$1/
Applicable "stated in"-valueScholarGPS (Q135840843)

Motivation

[edit]

ScholarGPS (Q135840843) provides publication and citation histories for each country, identify leading scholars and highly cited publications from each country. AdamSeattle (talk) 18:10, 16 August 2025 (UTC)[reply]

Discussion

[edit]

Maptons ID

[edit]
   Under discussion
Descriptionidentifier for a place in maptons.com
Representsmaptons.com (Q134893865)
Data typeExternal identifier
Domaingeographic entity (Q27096213)
Example 1New York City (Q60)→6693
Example 2Athens (Q1524)→933
Example 3Kathmandu (Q3037)→4376
Applicable "stated in"-valuemaptons.com (Q134893865)

Motivation

[edit]

Maptons.com is a comprehensive website dedicated to exploring places. Its in-depth articles provide detailed insights into various locations. Some items on the site could be enhanced by incorporating this ID, which would link to another database, offering even more detailed content.

maptons.com documents the following elements:

- timezone;

- population;

- coordinates, geographic place and feature QwertyZ34 (talk) 00:35, 21 June 2025 (UTC)[reply]

Discussion

[edit]
Some viewers (like medias) probably don’t know how to run a query QwertyZ34 (talk) 18:51, 15 September 2025 (UTC)[reply]

Slekt og Data cemetery ID

[edit]
   Ready Create
Descriptionunique identification of cemetery in the Norwegian database of Slekt og Data
RepresentsCemeteries in Norway (Q59157408)
Data typeExternal identifier
Template parameterno:Mal:Autoritetsdata
Domaincemetery (Q39614)
Example 1Vår Frelsers gravlund (Q1069938)→https://www.slektogdata.no/gravminner/gravplass/4576e7fa-6ff0-436f-aa9a-5b9435284293
Example 2Solheim cemetery (Q12001828)→https://www.slektogdata.no/gravminner/gravplass/1a5b6141-45ce-4277-9ba1-4ff1772d6a17
Example 3Helsfyr gravlund (Q59491960)→https://www.slektogdata.no/gravminner/gravplass/af74bd53-c199-4dbe-a4e5-40736c611b53
Allowed values[0-9a-f]{8}\-[0-9a-f]{4}\-[0-9a-f]{4}\-[0-9a-f]{4}\-[0-9a-f]{12}
SourceSlekt og Data Finn Gravplass
Planned useIn infoboxes and authentications for cemeteries
Number of IDs in source4129
Formatter URLhttps://www.slektogdata.no/gravminner/gravplass/$1
See alsoSlekt og Data grave ID (P12936)

Motivation

[edit]

All Norwegian cemeteries are indexed in the database of Slekt og Data, and most graves are listed. The database is similar to Find-A-Grave, and the most complete for Norwegian graves.  – The preceding unsigned comment was added by Cavernia (talk • contribs) at 11:10, November 23, 2025 (UTC).

Discussion

[edit]

‎Place Names and Places of Nova Scotia ID

[edit]
   Under discussion
Descriptionidentifier for entry in Place Names and Places of Nova Scotia (1967)
RepresentsPlace Names and Places of Nova Scotia (Q136400110)
Issued byNova Scotia Archives and Records Management (Q7064104)
Data typeExternal identifier
Example 1Abercrombie (Q4666820) -> 1
Example 2Halifax (Q3246744) -> 272
Example 3Lake Micmac (Q6476909) -> 159
Planned useCitation templates
Number of IDs in source751
Expected completenesseventually complete (Q21873974)
Formatter URLhttps://archives.novascotia.ca/places/page/?ID=$1
Applicable "stated in"-valuePlace Names and Places of Nova Scotia (Q136400110)

Motivation

[edit]

About 2,300 locations in the Canadian province of Nova Scotia are listed in the 1967 book Place-Names and Places of Nova Scotia. It is considered to be an authoritative source on toponymy in the province, and is consulted regularly by researchers -- it was the second study exclusively devoted to the Nova Scotian place names, the first being released in 1922.

The Nova Scotia Archives hosts the full book on their website; each page has an ID number which has always remained fixed, but the URL structure has changed once before. I would like to create a property for this identifier that I can draw from for citations on English Wikipedia -- so far I've added citations to roughly 800 locations, but I would like to switch over to using a citation template which draws from Wikidata to facilitate easy maintenance in the future. Each ID may contain one or multiple entries, so while there are only 751 identifiers in total, they will apply to roughly 2,300 items.

This is my first attempt at a property request, and it has proven to be daunting task. Feedback is most welcome. Thanks, MediaKyle (talk) 22:22, 4 December 2025 (UTC)[reply]

Discussion

[edit]

Notified participants of WikiProject Canada

 Support --Fralambert (talk) 22:29, 4 December 2025 (UTC)[reply]
 Support Mahir256 (talk) 23:38, 4 December 2025 (UTC)[reply]
 Support —Dcflyer (talk) 06:09, 9 December 2025 (UTC)[reply]

Neighborhood

[edit]

Architectural structure

[edit]

Outer space

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

Classification of human settlements

[edit]

Other

[edit]

‎overnight stays

[edit]
   Under discussion
Descriptionnumber of tourists that stay overnight at a place per year
Data typeQuantity
Example 1Munich (Q1726) → 19,700,000
Example 2Bavaria (Q980) → 102,750,000,000
Example 3Germany (Q423030) → 496,000,000,000

Motivation

[edit]

This is a standard unit in the hospitality industry. See also the item Q3346212. Maybe it could also be expanded to cover medical facilities. --Bruno413 (talk) 10:46, 27 November 2025 (UTC)[reply]

Discussion

[edit]

Japanese court rank

[edit]
   Under discussion
DescriptionJapanese court rank of a person or a shrine
Representscourt rank in Japan (Q99196082)
Data typeItem
Example 1Ōyamato Shrine (Q245731)→Junior First Rank (Q11071121)
Example 2Suwa taisha (Q218813)→Junior Third Rank (Q11071123)
Example 3Kumano Hayatama Taisha (Q335618)→Junior Fifth Rank (Q11071125)
Example 4Agata Inukai no Michiyo (Q11582685)→Senior First Rank (Q11123258)
Example 5Abe no Komina (Q17191701)→Senior First Rank (Q11123258)
Example 6Iwakura Tomomi (Q428200)→Senior First Rank (Q11123258)
Allowed valuesUnranked (Q11504610)

Lesser Initial Rank (Q11464527) Greater Initial Rank (Q11433041) Junior Ninth Rank (Q11488719) Senior Ninth Rank (Q11545350) Junior Eighth Rank (Q11488720) Senior Eighth Rank (Q11545368) Junior Seventh Rank (Q11488718) Senior Seventh Rank (Q11545345) Junior Sixth Rank (Q14624983) Senior Sixth Rank (Q11545372) Junior Fifth Rank (Q11071125) Senior Fifth Rank (Q11123280) Fourth Rank (Q11419606) Junior Fourth Rank (Q11071127) Senior Fourth Rank (Q11123338) Third Rank (Q11354375) Junior Third Rank (Q11071123) Senior Third Rank (Q11123261) Second Rank (Q11371333) Junior Second Rank (Q11488721) Senior Second Rank (Q11123277) Junior First Rank (Q11071121)

Senior First Rank (Q11123258)
Planned useThere are many shrines that I already added these to using the instance of property. My plan is to simply move all of those into this property to unclutter the instances of thing. This is the case alongside many other shrine properties that I have added for instances of.

（既に多くの神社ではこれを記録するため属性のインスタンスを流用しています。対象をすべて当プロパティに移し、インスタンスを整理したいと考えます。神社プロパティのうち、インスタンス用に追加した他の多くのものも同様の措置を想定。）

For people I do not have an immediate plan of adding it for them. However it is well documented who has what rank on Japanese wikipedia and others can easily add it.

Motivation

[edit]

Having them as instance of is not good. They should be indicated with a property. (プロパティを設定すべきであり、インスタンスで示すのは正しくないため。)

Discussion

[edit]
  • The property as proposed is very specific. Is there are reason that a broader proposal that might work across multiple religions (or maybe building types) wouldn't work for this use-case? ChristianKl ❪✉❫ 09:27, 10 July 2025 (UTC)[reply]
    @ChristianKl I think the giving of court ranks to shrines is very Shinto specific. I could imagine it happening for Japanese Buddhist temples, or somehow being applied in Okinawa Korea and possibly China. But the impetus for this, as with the other proposals isn’t that there’s no way of representing Shinto Shrine rankings, but that so many shrines have half a dozen or so rankings from multiple ranking systems and it makes their entries very cumbersome.
    There’s Engishiki rankings, x-no-Miya rankings, court rankings (of which there is almost always multiple at different time periods), and modern system rankings, and the modern Beppyo ranking. And many prominent shrines have a ranking in all 5 of these systems. Immanuelle (talk) 09:50, 10 July 2025 (UTC)[reply]
    This rank for Shinto divinities is basically same with the court rank system in pre-modern Japan, while there is no property for court rank. I think a property for court rank (not limited to Japan) should be created, and we can use it for Shinto shrines too. Mzaki (talk) 02:25, 11 July 2025 (UTC)[reply]
    Sounds like a good way to create awful data modeling. Wikidata really ought to stop treating different religions as being interchangable Trade (talk) 15:22, 12 October 2025 (UTC)[reply]
    The following three proposals Wikidata:Property proposal/Engishiki Rank Wikidata:Property_proposal/Engishiki_Funding_Category Wikidata:Property_proposal/Divine_Rank are all pretty closely related and would ideally be all examined as a relative group. Immanuelle (talk) 06:20, 28 November 2025 (UTC)[reply]

Notified participants of WikiProject JapanImmanuelle (talk) 13:25, 10 July 2025 (UTC)[reply]

Anyone have more thoughts?Immanuelle (talk) 02:23, 12 October 2025 (UTC)[reply]
Notified participants of WikiProject Japan
Notified participants of WikiProject Religions
Melderick (talk) 21:33, 16 July 2021 (UTC) Jheald (talk) 15:29, 19 July 2021 (UTC) PKM (talk) 20:40, 19 July 2021 (UTC) pmt Pmt (talk) 13:47, 20 July 2021 (UTC) Hannes 24 (talk) 17:07, 8 February 2023 (UTC)[reply]
Notified participants of WikiProject Medieval Nobility
Immanuelle (talk) 20:33, 19 October 2025 (UTC)[reply]
  •  Support --Trade (talk) 15:22, 12 October 2025 (UTC)[reply]
  •  Question Is that super-rank or parent rank going to accomodate those other items or not? Mzaki's definision sounds good to me. Mzakiさんの案に賛成ですが、以下のすでにあるものとの整合・親子関係は？「Mzakiさん：日本限定でない宮廷の位階 court ranking をまず新設、それを流用できないか」。
See court rankings for:
  • (Category:日本の位階) Q9665982, site links:2
  • (Category:位階制度) Q9520387
  • Choson court (朝鮮王朝の位階) Q12616815
  • Ryūkyū court (琉球王朝の位階) Q15142314
  • Ranking in Japan (日本の位階) Q99196082
 Question side note: How do we note if the said shrine hasn't agreed on, after 1945, the given ranking regulated by Jinja Honcho aka Association of Shinto Shrines? How do I state such condition, or ignore? Cheers, --Omotecho (talk) 04:05, 28 October 2025 (UTC)[reply]
@Omotecho this only applies to pre-Meiji ranks, and only the court ranks. It does not include the Engishiki rankings related to offerings given, such as Shrine receiving Tsukinami-sai and Niiname-sai and Ainame-sai offerings (Q135009157) or Engishiki ranks such as Myōjin Taisha (Q9610964).
Pre-Meiji ranks are very chaotic so this is a problem, but this thing has exactly one system in question. Immanuelle (talk) 17:16, 3 November 2025 (UTC)[reply]
I organized this a bit more. The Pre-Meiji ranks are I believe much better organized ontologically now and this can proceed more easily. Immanuelle (talk) 05:22, 28 November 2025 (UTC)[reply]

With all due respect could you please avoid the unecessary capitalization in your proposal labels? It's a bit annoying to read --Trade (talk) 02:00, 30 November 2025 (UTC)[reply]

Will do in the future Immanuelle (talk) 19:48, 30 November 2025 (UTC)[reply]

What is the main obstacle to propery creation right now?Immanuelle (talk) 08:42, 2 December 2025 (UTC)[reply]

I added the allowed values Immanuelle (talk) 05:42, 3 December 2025 (UTC)[reply]
I also made the proposal more generic since this is not just about shrine ranks it is also about court ranks Immanuelle (talk) 07:57, 3 December 2025 (UTC)[reply]
Mass edit seems to have been rejected so we are representing this through P31 until the proposal finishes Immanuelle (talk) 19:51, 4 December 2025 (UTC)[reply]

‎Engishiki Rank

[edit]
   Under discussion
DescriptionRank of a Shinto shrine in the Engishiki Jinmyocho, a list of shrines published in 927.
Data typeItem
DomainShikinaisha (Q134917286)
Example 1Gokōnomiya Shrine (Q6540880)→Shikinai Shosha (Q134917287)
Example 2Uda Mikumari Shrine (Q3547711)→Shikinai Taisha (Q134917288)
Example 3Sumiyoshi Shrine (Q29682)→Myōjin Taisha (Q9610964)
Allowed valuesShikinai Shosha (Q134917287), Shikinai Taisha (Q134917288), Myōjin Taisha (Q9610964)
Planned useI have these rankings marked on many shrines already through the instance of property, and I will move all of them into this property if it is created
Single-value constraintyes

Motivation

[edit]

This will correspond to the rankings in the Engishiki Jinmyocho.

There are other proerties which would be treated separately

Discussion

[edit]

Might be worth including Shikigesha and Kokushi genzaisha although both are defined by their exclusion from the Engishiki JinmyochoImmanuelle (talk) 23:41, 4 July 2025 (UTC)[reply]

I don't know what the "Engishiki Jinmyocho" is. The English description should tell me what it is but currently doesn't. ChristianKl ❪✉❫ 09:26, 10 July 2025 (UTC)[reply]
@ChristianKl the Engishiki Jinmyocho is a section of the Engishiki, an ancient Japanese book, which contains the first comprehensive shrine catalog
It has multiple ways of ranking shrines. Based on the amount of offerings the court sent them and their size. And an addendum added a category of imperial shrines vs national shrines.
I don’t know the best way to represent the rankings because they are a bit strange in the ways they overlap. But I tried to explain it there. Immanuelle (talk) 09:53, 10 July 2025 (UTC)[reply]
Specifically there’s the following:
Shosha vs Taisha vs Myojin Taisha
Kanpeisha vs Kokuheisha
often combined with Shosha and Taisha but Myojin Taisha and regular Taisha are conflated into Kokuhei Taisha and Kanpei Taisha
Celebration category
this inconsistency comes from slightly different schemes and historical reasons. Immanuelle (talk) 09:58, 10 July 2025 (UTC)[reply]
I'm not just asking for you to explain it to me. I'm asking you to write a property description (in that field) that makes a reader understand what the concept is about. ChristianKl ❪✉❫ 14:14, 10 July 2025 (UTC)[reply]
@ChristianKl sorry did I manage to explain it properly? Immanuelle (talk) 10:06, 26 July 2025 (UTC)[reply]
Just for an update on the ranking. I am in the process of removing the intersection ones and funding is covered separately here in this proposal Wikidata:Property proposal/Engishiki Funding Category. Immanuelle (talk) 05:10, 28 November 2025 (UTC)[reply]
The following three proposals Wikidata:Property proposal/Engishiki Rank Wikidata:Property_proposal/Engishiki_Funding_Category Wikidata:Property_proposal/Divine_Rank are all pretty closely related and would ideally be all examined as a relative group. Immanuelle (talk) 06:20, 28 November 2025 (UTC)[reply]
What is the main obstacle to propery creation right now? Immanuelle (talk) 08:42, 2 December 2025 (UTC)[reply]

Notified participants of WikiProject JapanImmanuelle (talk) 13:25, 10 July 2025 (UTC)[reply]

Probably best thing will be to have the Kanpei/Kokuhei distinction made with a third Shikinaisha property. Immanuelle (talk) 22:03, 10 July 2025 (UTC)[reply]
Yes, as per discussion at Wikidata:Property proposal/Engishiki Funding Category I am firm on it. Calling something a Kanpei-sha (Q135206477) or any of these other combined ranks is ontologically very fraught. We should limit all of this to just Shikinai Shosha (Q134917287) and Shikinai Taisha (Q134917288) and Myōjin Taisha (Q9610964) and not try to do any combined rankings. They appear to be colloquial combinations of imprecise ranks, and using them at all on wikidata just adds to confusion. Immanuelle (talk) 04:21, 28 November 2025 (UTC)[reply]
The colloquial combinations function as actual ranks for ‎modern shrine ranking (P13723) but I believe we should seek to remove all of those ones for the Engishiki. It was a mistake on my part to add them. Immanuelle (talk) 04:23, 28 November 2025 (UTC)[reply]
Anyone have more thoughts?Immanuelle (talk) 02:23, 12 October 2025 (UTC)[reply]
@Trade does this one still have issues or is it more clear now? Immanuelle (talk) 05:19, 28 November 2025 (UTC)[reply]
 Comment You might change the English description to “ Rank of a Shnto shrine in the Engishiki Jinmyocho, a list of shrines published in 927” PKM (talk) 03:46, 3 December 2025 (UTC)[reply]
Done Immanuelle (talk) 04:22, 3 December 2025 (UTC)[reply]
 Comment I think you can make this proposal stronger by adding some of the optional statements (see Template:Property proposal). In particular, I would want to see “allowed values” with a list of the QIDs for all of the applicable rankings. I’d also like to see “applicable stated in value” = Engishiki Jinmyōchō (Q11064932). Also, can we restrict the “domain” to “instance of Shinto shrine (Q845945) or one of its subclasses" (or whatever is appeopriate). - PKM (talk) 04:14, 3 December 2025 (UTC)[reply]
@PKM is this better? Immanuelle (talk) 04:27, 3 December 2025 (UTC)[reply]
Much better, thank you!- PKM (talk) 18:56, 3 December 2025 (UTC)[reply]

‎type of Ritsuryō funding

[edit]
   Under discussion
Descriptiontype of funding received by a Shinto shrine in medieval Japan
RepresentsRitsuryō funding type (Q135009120)
Data typeItem
Example 1Sumiyoshi Shrine (Q29682)→Kokuhei-sha (Q135160342)
Example 2Samukawa Shrine (Q48744)→Kokuhei-sha (Q135160342)
Example 3Katori Jingū (Q372380)→Shrine receiving Tsukinami-sai and Niiname-sai offerings (Q135009132)
Example 4Sumiyoshi Taisha (Q705949)→Shrine receiving Tsukinami-sai and Niiname-sai and Ainame-sai offerings (Q135009157)
Example 5Ōyamato Shrine (Q245731)→Shrine receiving Tsukinami-sai and Niiname-sai and Ainame-sai offerings (Q135009157)
Example 6Niukawakami Shrine (Q246370)→Shrine receiving Tsukinami-sai and Niiname-sai offerings (Q135009132)
Example 7Makimotono Shrine (Q135039150)→Shrines receiving Hoe and Quiver (Q135009152)
Example 8Izumianashi Shrine (Q11554908)→Kanpei-sha (Q135160338)
Allowed valuesKokuhei-sha (Q135160342) Kanpei-sha (Q135160338) Shrines receiving Hoe and Quiver (Q135009152) Shrines receiving Hoe offering (Q135009205) Shrines receiving Quiver offering (Q135009221) Shrine receiving Tsukinami-sai and Niiname-sai offerings (Q135009132) Shrine receiving Tsukinami-sai and Niiname-sai and Ainame-sai offerings (Q135009157)
SourceKokugakuin University Shrine database (Q135159299)
Planned useApply this to the thousands of Shikinaisha which are currently categorized as instances of these rankings.
Single-value constraintyes

Motivation

[edit]

This alongside the ranking (Shikinai Shosha, Shikinai Taisha, Myojin Taisha) and the festival categorizations is one of the three rankings of the Engishiki. I proposed awkwardly combining it with the earlier ranking, but I think it is best done as its own thing. A user can use queries to determine if something is a Kanpei Taisha or a Kokuhei Shosha. They are not in the same kind of organization as in the modern system of ranked shinto shrines.

Discussion

[edit]

Probably needs a better nameImmanuelle (talk) 22:42, 10 July 2025 (UTC)[reply]

Main reason I want this as a separate property is because of the fact that every Shikinaisha has this value, and it is binary. Immanuelle (talk) 05:42, 12 July 2025 (UTC)[reply]
Just an update here, it is not binary. See the updated thing and discussion. Immanuelle (talk) 04:57, 28 November 2025 (UTC)[reply]
Anyone have more thoughts?Immanuelle (talk) 02:23, 12 October 2025 (UTC)[reply]
The following three proposals Wikidata:Property proposal/Engishiki Rank Wikidata:Property_proposal/Engishiki_Funding_Category Wikidata:Property_proposal/Divine_Rank are all pretty closely related and would ideally be all examined as a relative group. Immanuelle (talk) 06:20, 28 November 2025 (UTC)[reply]
What is the main obstacle to propery creation right now? Immanuelle (talk) 08:42, 2 December 2025 (UTC)[reply]

Is there a reason you named it "‎Kanpei or Kokuhei"? Why not just pink one name for the English version--Trade (talk) 04:10, 28 November 2025 (UTC)[reply]

@Trade the Japanese database in question called the property "官幣・国幣" so that is why I did the name originally. But since I did some changes with what the property is meant to represent, I decided on a new more descriptive name and tried to rename the proposal. Immanuelle (talk) 04:16, 28 November 2025 (UTC)[reply]
Would "type of Engishiki funding" be a better name? Trade (talk) 04:21, 28 November 2025 (UTC)[reply]
@Trade yes I think it would be. Alternatively something like type of Ritsuryo funding. Since this is not technically part of the Engishiki despite being in an Engishiki database. Immanuelle (talk) 04:26, 28 November 2025 (UTC)[reply]
I do not think I am actually supposed to move this page so I will avoid moving it, but changed the label Immanuelle (talk) 04:27, 28 November 2025 (UTC)[reply]

You still havent added a subclass to Shrine receiving Tsukinami-sai and Niiname-sai and Ainame-sai offerings (Q135009157)--Trade (talk) 04:48, 28 November 2025 (UTC)[reply]

Done. Immanuelle (talk) 04:58, 28 November 2025 (UTC)[reply]
Any more issues with this proposal? I hope that it is relatively clear now. Immanuelle (talk) 05:15, 28 November 2025 (UTC)[reply]
Sorry i meant Q135009120 Trade (talk) 08:20, 28 November 2025 (UTC)[reply]
Ritsuryō funding type (Q135009120) Immanuelle (talk) 08:22, 28 November 2025 (UTC)[reply]
Oh I am having some ontological confusion on this and how it should be structured. Immanuelle (talk) 08:22, 28 November 2025 (UTC)[reply]

Would it be possible to change the description to something more understandable for laymen? Ideally the description should be understandable for people unfamiliar with Shinto and Japan --Trade (talk) 13:02, 28 November 2025 (UTC)[reply]

@Trade done Immanuelle (talk) 09:35, 29 November 2025 (UTC)[reply]

Have you considered just using has characteristic (P1552) instead? Because sounds very much like just a quality --Trade (talk) 00:49, 30 November 2025 (UTC)[reply]

@TradeThe single value constraint is pretty significant here. It might be worth moving all of the properties to this and doing the same for a lot of the other P31 properties that I have been working with but I do not see this as a long-term solution. Immanuelle (talk) 01:44, 30 November 2025 (UTC)[reply]
What single value constraint? There is no constraint at Q29682#P1552 Trade (talk) 01:49, 30 November 2025 (UTC)[reply]
No I want a single value constraint for this category. Immanuelle (talk) 19:08, 30 November 2025 (UTC)[reply]

‎Source Shrine

[edit]
   Under discussion
DescriptionThe shrine that the gods of this shinto shrine came from through Bunrei and Kanjo
RepresentsBunrei (Q195793)
Data typeItem
DomainQ845945
Example 1Kasuga-taisha (Q714559)→Hiraoka Shrine (Q32422)
Example 2Usa Jingū (Q715632)→Daibu Hachimangū (Q11432652)
Example 3Sono & Kara Shrines (Q11422896)→Kangō Shrine (Q11565493)
Example 4Kōtai Jingū (Q11581011)→moto-Ise (Q11387775)
Example 5Toyōke Daijingū (Q11633343)→Hinumanai Shrine (Q11547467)
Planned useAdding many established shrine lineages.
神社の社格・系統を追記していく。

Motivation

[edit]

(Add your motivation for this property here and your signature)

(この項目の立項を支持する場合、動機と署名をここに記入願います。)

Discussion

[edit]

Is this going to be restricted to a single religion, in which case Shinto needs to be in the property name, or (hopefully) is it applicable to many religions, so we don't need to duplicate it. Vicarage (talk) 14:59, 28 July 2025 (UTC)[reply]

@Vicarage I think it could apply to other religions, but I am not sure which ones. Catholic Churches at one point had a relic chain of custody system afaik which was abolished with Vatican II, and I think Orthodox and Eastern Catholic churches still have it but I do not know how they work or where I would look up something like this.
So maybe it would be changed to something like "Source of Relics" Immanuelle (talk) 22:01, 29 July 2025 (UTC)[reply]
You seem to be connecting buildings with buildings, rather as mother house (P612) does for monasteries. Could that property be broadened for use as a shrine lineage, as "parent institution" with aliases "mother house" and "source shrine". A "Source of Relics" property would link movable objects with buildings, which seems too different. Vicarage (talk) 22:16, 29 July 2025 (UTC)[reply]
@Vicarage the issue with Shinto shrines here is that the source shrine is not always superior to the shrine in a hierarchy
For example with Kasuga-taisha (Q714559) and Hiraoka Shrine (Q32422) they are both prestigious, but Kasuga-taisha (Q714559) is one of the highest ranked shinto shrines and Hiraoka Shrine (Q32422) is comparably lower ranked.
Usa Jingū (Q715632) is sometimes considered the top ranked shrine but Daibu Hachimangū (Q11432652) is only notable because of the relationship with Usa Jingū (Q715632)
Actually all of the examples I provided have the shrine being higher ranked than its parent shrine. Although it is the norm that the parent shrine is higher ranked, I just looked up the property for famous shrines. Immanuelle (talk) 04:54, 30 July 2025 (UTC)[reply]
You've used the word 'parent', which doesn't imply superiority, same thing is true of monasteries, so it sounds like you could use the other property Vicarage (talk) 05:38, 30 July 2025 (UTC)[reply]
@Vicarage thoughts on just using mother house (P612) for this property and dropping the proposal? Immanuelle (talk) 07:01, 30 July 2025 (UTC)[reply]
I would. Ask on the Religion Project first. Vicarage (talk) 07:34, 30 July 2025 (UTC)[reply]
Notified participants of WikiProject Japan
Notified participants of WikiProject Religions
Immanuelle (talk) 20:30, 19 October 2025 (UTC)[reply]
Anyone have more thoughts?Immanuelle (talk) 02:23, 12 October 2025 (UTC)[reply]
I seem to remember you upsetting other people with shrine edits, eg https://www.wikidata.org/w/index.php?title=User_talk:Immanuelle&oldid=2391784643, so I'd like to hear their opinions before proceeding Vicarage (talk) 06:34, 12 October 2025 (UTC)[reply]
I would like to hear from them too. I apologize for poor communication Immanuelle (talk) 04:36, 14 October 2025 (UTC)[reply]
There were some ontology disagreements but they were confusing over the language barrier. I am not sure exactly what they object to in ontology. Immanuelle (talk) 20:17, 14 October 2025 (UTC)[reply]

Bunrei and Category:Sakaku (分霊とcat:社格)

[edit]

 Comment Either we could apply 分霊

For universality of 分霊 bunrei
(A) The geological/ontological definition

In Japanese context, bunshi (分祠) hits on both wikidata and National Diet Library Japan, an idiom to 分霊 bunrei.

Chinese concepts?
Two items:
  • Scholarly article, 2022, or "性别与祭祀——徽州男女分祠营造现象及其空间伦理意义" (zh), Art & Design (3):2022. "ja=ジェンダーと犠牲：恵州における男女別祠堂の現象とその空間倫理的意義"
  • Scholarly paper, 2004, or "唐代地方祠祀的分层与运作——以生祠与城隍神为中心" (zh), 历史研究 (2):2004. ""ja=唐代における地方祖先崇拝の階層化と運営：生きた祖先廟と都市神に焦点を当てて"
Hindi in Thailand?
In jawp, I read there was seeb a recent trend in Thai to dedicate small worship places to Q11389 (ブラフマー Brahmā), a Hindi deity; the jawp article tells the origin/starting epic to be the popularity of the エラーワンの祠 Erawan Shrine.(jawp article, &oldid=105715203)
For Shinto jinja

FYI, and just a sketchy ideas to put on the table the landscape, limited to shinto jinjas. Their ranking has been regulated as Category:社格 shakaku. My question as not being specialist on the field religions in general: would we refer to 神社本庁 (jinja honchō) for the lineage of 分霊 bunrei for each Shinto institute/building, as well as their Category:社格 shakaku?

Honestly, I feel confused when you contrast Christianism to Shintoism, latter a 多神教 polytheism (tashinkyō), while the said regulation above needs to be noted that the state government agency, jinja honchō has disputes against it from among those jinja who had lost their prominent ranking after 1946.

(B) Ranking in Japan, pre-1946

And in strict sense, afaik the context better consider that the pre-1868 categorizing/ranking system of Shakaku (社格) has been reformed till 1945. Jinja overseas counted 18, not included below.

  1. The sect of Category:伊勢神宮 (Ise jingu)
    1. Category:神宮125社 Category:125 Jungu, including: consisting of two (2) main jinja (Seigū=皇大神宮(Q11581011) and 豊受大神宮(Q11633343)) with 14 Betsugū (other major deities). Further categories:
  2. Category:官幣大社 Category:kampei taisha (61)
  3. Category:官幣中社 Category:kampei chūsha (22)
    1. Is that inherited as the kindai shakaku-seido"※" (ranking after 1946) ?
  4. Category:官幣小社 Category:kampei shōsha (5)
  5. Category:別格官幣社 Category:bekkaku kampei-sha (28)
  6. Category:国幣大社 Category:kokuhei taisha (6)
  7. Category:国幣中社 Category:kokuhei chūsha (47)
  8. Category:国幣小社 Category:kokuhei shōsha (39)
  • "※"w:en:Shakaku again went to different level with the Ranking after 1946 近代社格制度 (kindai shakaku-seido) when it lost its political influence to the Constitution/government.
    1. A recent revision #9 issued in August 2021.[2]
(C) Rankings, before 1868 in Japan
  • for Shinto, the lineage of a particular deity afaik suggests more of a political background/branding during Samurai era before 1868, but not necessarily to expand the geographic dominance/population of devotees of that deity. A jinka before 1868 was in several groups:
  • (C-1) like in the case of 白髭神社 Shirahige jinja,[3] authentic jinja still claim their legacy/bunrei (分霊) holding over 300 shrines as bunrei institutions, without indicating what jinja honchō regulates/defines.
  • (C-2) Tōshōgū actually is a jinja with shorter history, dedicated to Iyeyasu Tokugawa, the first Shogun of Edo period; a local samurai clan had appealed their loyalty to the Tokugawa domain, especially when they named a shrine as "location/domain name" + 東照宮 Tōshōgū. or Hōjō clan and its six yuisho daimyo clans serving to the Hōjō clan also had claimed their bond with the prominent political power.
samurai as kami and 分霊 bunrei
  • (D) whether we include such definition as: before 1868, any Shintoist person with higher social rank, or prominent samurai/kuge aristocrat, were enlisted as kami at their death, so that 分霊 in that setting indicated they had more than one burial place/奥都城 okutuki [4].

Thank you reading through a scattered note, cheers, --Omotecho (talk) 10:46, 23 October 2025 (UTC)[reply]

I am a bit confused about what you are trying to get at here. Can you explain it in a bit simpler and more concise terms? Immanuelle (talk) 17:12, 3 November 2025 (UTC)[reply]
@Omotecho do you have more to add as to whether this is a good or bad property to add? Immanuelle (talk) 05:21, 28 November 2025 (UTC)[reply]
As for this one. The amount of shrines with this documented is smaller than many of the other ones. But it is still a well documented thing. I would guess we would probably take a while to get into the hundreds unless there is some kind of parameter I have not discovered in a template on jawiki. Immanuelle (talk) 10:23, 28 November 2025 (UTC)[reply]

What is the main obstacle to propery creation right now?Immanuelle (talk) 08:43, 2 December 2025 (UTC)[reply]

‎Météo-France place ID

[edit]
   Under discussion
Descriptionidentifier of a Météo-France place (city, commune, region, etc.)
RepresentsMétéo-France (Q1810406)
Data typeExternal identifier
Example 1Nouvelle-Aquitaine (Q18678082) → nouvelle-aquitaine/9
Example 2Orléans (Q6548) → orleans/45000
Example 3Vitry-lès-Cluny (Q1625078) → vitry-les-cluny/71250
Example 4Robstown (Q1573527) → robstown/4723212
Example 5Daşoguz Region (Q487393) → dasoguz/601734
Formatter URLhttps://meteofrance.com/previsions-meteo-france/$1/$1 (for France) https://meteofrance.com/previsions-meteo-monde/$1/$1 (for any place outside France)

Motivation

[edit]

Different to Météo-France weather station ID (P11775), adding the Météo-France place ID property to Wikidata improves links to official weather data for France and other global locations, enhancing accuracy, data integration, and the usefulness of geographic and meteorological information. QwertyZ34 (talk)


Discussion

[edit]

Notified participants of WikiProject France QwertyZ34 (talk) 13:31, 15 September 2025 (UTC)[reply]

 Support see what has been done the same way for Canada: Wikidata:WikiProject Weather observations. Cheers, VIGNERON (talk) 13:56, 15 September 2025 (UTC)[reply]

  •  Support, bonne idée. Maxime 14:00, 15 September 2025 (UTC)[reply]
  •  Oppose conditional on commitment from the proposer to actually populate the property, we don't want it created with a handful of entries and then they move on. And I'd like the proposal fleshed out with number of entries, URL regexp patterns etc. The high ID numbers suggest this could be a very large data import which would need expertise in site scraping, and confirmation that the numbers weren't used from another 3rd party. For example 71250 for VITRY-LES-CLUNY looks like its postcode. I note that this is the 4th property proposal QwertyZ34 has discussed in as week.
I believe that for French places—like communes and cities—the numeric ID will be identical to their postal code; that makes things a little bit complicated: we could do 2 separate properties, one for French places and one for the rest of the world-e. g. Robstown (Q1573527) and Daşoguz Region (Q487393) has both "meteo-monde" in their URLS—the number of pages is unknown, perhaps ~100K—also, is there a limit about discussing properties proposals? QwertyZ34 (talk) 18:45, 15 September 2025 (UTC)[reply]

‎OpenStreetMap relation type

[edit]
   Under discussion
DescriptionOpenStreetMap relation type
AliasesOSM relation type
RepresentsOpenStreetMap relation type (Q136311450)
Issued byOpenStreetMap (Q936)
Data typeExternal identifier
Domainitem, property
Example 1headway (Q4383682)→route
Example 2chronology (Q67439188)→chronology
Example 3MultiLineString (Q111226201)→multilinestring
Example 4MultiPolygon (Q111226235)→multipolygon
Allowed values[-\.:_0-9A-Za-z]{0,60}
Sourcehttps://taginfo.openstreetmap.org/keys
Planned useimmediate usage for relation types wrongly stored in Property:P1282, filling in others where matches exist
Number of IDs in source774 https://taginfo.openstreetmap.org/sources/db
Formatter URLhttps://taginfo.openstreetmap.org/relations/$1
Applicable "stated in"-valueOpenStreetMap database (Q116859711)
Single-value constraintyes
Distinct-values constraintyes

Motivation

[edit]

The property:P1282 started as place to store Key: and Tag: (Wikidata:Property_proposal/Archive/22#P1282) but as of 2025-09-17 is used also to store OSM relation types:

  1. Q111226201 MultiLineString Relation:multilinestring
  2. Q111226235 MultiPolygon Relation:multipolygon
  3. Q4383682 headway Relation:route
  4. Q67439188 chronology Relation:chronology

A list of relations can be found at https://taginfo.openstreetmap.org/relations . Cf. https://wiki.openstreetmap.org/wiki/Category:Relation_descriptions https://wiki.openstreetmap.org/wiki/Category:Relations

OpenStreetMap related items and properties - names, sources, statistics (OSM: 2025-09-08 00:00:08 UTC, https://www.openstreetmap.org/stats/data_stats.html and 2025-09-08 00:59:15 UTC https://taginfo.openstreetmap.org/sources/db )
WD item WD property OSM
Item label Item ID Property label Property ID Property usage OSM documentation OSM statistics
OpenStreetMap numeric user ID Q116153645 OpenStreetMap numeric user ID P8754 9 972 927
OpenStreetMap username Q112660709
OpenStreetMap element Q114733246 https://wiki.openstreetmap.org/wiki/Elements
OpenStreetMap relation ID Q136310469 OpenStreetMap relation ID P402 466 646
https://w.wiki/FG$z 		https://wiki.openstreetmap.org/wiki/Relation 13 651 040
OpenStreetMap way ID Q136310529 OpenStreetMap way ID P10689 265 276
https://w.wiki/FG$v 		https://wiki.openstreetmap.org/wiki/Way 1 129 256 992
OpenStreetMap node ID Q122691880 OpenStreetMap node ID P11693 315 742
https://w.wiki/FH25 		https://wiki.openstreetmap.org/wiki/Node 10 130 285 826
OpenStreetMap key Q136162424 OpenStreetMap key P13786 816
https://w.wiki/FMaF 		https://wiki.openstreetmap.org/wiki/Key (redirect) 104 248
OpenStreetMap tag Q116869372 OpenStreetMap tag P1282 3715
https://w.wiki/FH29 		https://wiki.openstreetmap.org/wiki/Tags 3 648 079 162 (distinct 179 668 163)
OpenStreetMap Role https://wiki.openstreetmap.org/wiki/Category:Roles
OpenStreetMap relation type Q136311450 (OpenStreetMap relation type) (P...) https://wiki.openstreetmap.org/wiki/Category:Relation_descriptions https://taginfo.openstreetmap.org/relations 774

OSMan2025 (talk) 16:26, 17 September 2025 (UTC)[reply]

Discussion

[edit]
I think there's still a misunderstanding here. The examples that you provided refer to the same thing. type=street is the same as Relation:street. The osmwiki: just uses a different format for the page name. Taginfo has a different page for viewing extra statistics, but that doesn't make it a different thing in the data model. --Aebion (talk) 09:43, 18 September 2025 (UTC)[reply]
Thank you. I will convert any remaining Relation=XYZ to type=XYZ. OSMan2025 (talk) 12:51, 18 September 2025 (UTC)[reply]
OK, you did it already. I now just removed the "Tag:"-prefix for these. OSMan2025 (talk) 12:57, 18 September 2025 (UTC)[reply]
Thanks, sorry I missed your messages. I've also replied to Wikidata talk:OpenStreetMap#Role --Aebion (talk) 10:21, 25 September 2025 (UTC)[reply]
Unrelated comment: headway (Q4383682) is a bad example. It should never have had OpenStreetMap tag (P1282) set to type=route. I've now corrected headway (Q4383682) to have interval=*--Aebion (talk) 09:43, 18 September 2025 (UTC)[reply]

‎OpenStreetMap role

[edit]
   Under discussion
DescriptionOpenStreetMap role
AliasesOSM role
RepresentsOpenStreetMap role (Q136361499)
Issued byOpenStreetMap (Q936)
Data typeExternal identifier
Domainitem, property
Example 1capital city (Q5119)→admin_centre
Example 2administrative centre (Q1306755)→admin_centre
Example 3subarea (Q61427164)→subarea
Example 4map label (Q104642575)→label
Allowed values[-\.:_0-9A-Za-z]{0,60}
Sourceat least some at https://wiki.openstreetmap.org/wiki/Category:Roles
Formatter URLhttps://wiki.openstreetmap.org/wiki/Role:$1
Applicable "stated in"-valueOpenStreetMap database (Q116859711)
Single-value constraintyes
Distinct-values constraintyes

Motivation

[edit]

The property:P1282 started as place to store Key: and Tag: (Wikidata:Property_proposal/Archive/22#P1282) but as of 2025-09-17 was also used to store OSM role:

  1. Q5119 capital city Role:admin_centre
  2. Q1306755 administrative centre Role:admin_centre
  3. Q61427164 subarea Role:subarea
  4. Q104642575 map label Role:label

These claims have been removed from WD. Maybe it is worth to store these in a new property "OSM role". OSMan2025 (talk) 23:23, 23 September 2025 (UTC)[reply]

Data model:

  1. A member has no role https://osm.org/api/0.6/way/828837335
  2. The role is attached to the member(ship)-statement in the relation (e.g. ref="828837335" role="from" at https://osm.org/api/0.6/relation/12640116)

Examples:

1) Relation having type=restriction and restriction=no_u_turn:

  1. https://www.openstreetmap.org/relation/12640116
  2. https://osm.org/api/0.6/relation/12640116
<member type="way" ref="828837335" role="from"/>
<member type="node" ref="1106056850" role="via"/>
<member type="way" ref="154986825" role="to"/>
<tag k="restriction" v="no_u_turn"/>
<tag k="type" v="restriction"/>

2) Relation having type=associatedStreet

  1. https://www.openstreetmap.org/relation/9694397
  2. https://osm.org/api/0.6/relation/9694397
<member type="node" ref="3778156472" role="house"/>
<member type="node" ref="5137945359" role="house"/>
<member type="node" ref="2824827799" role="house"/>
<member type="node" ref="2824828249" role="house"/>
<member type="way" ref="757359118" role="street"/>
<member type="way" ref="738023850" role="street"/>
<member type="way" ref="1335961450" role="street"/>
<member type="way" ref="837943498" role="street"/>
...
<member type="way" ref="968737544" role="street"/>
<member type="way" ref="5669742" role="street"/>
<member type="way" ref="963551551" role="street"/>
<member type="way" ref="278053524" role="house"/>
...
<member type="way" ref="278053478" role="house"/>
<member type="way" ref="213924948" role="house"/>
<tag k="name" v="Broadway"/>
...
<tag k="type" v="associatedStreet"/>
<tag k="wikidata" v="Q11260"/>

OSMan2025 (talk) 23:29, 23 September 2025 (UTC)[reply]

Discussion

[edit]
  •  Comment pinging:
  • My vote: I need to think a bit more about it. How many roles exist? Can they be freely chosen like tags? OSMan2025 (talk) 23:22, 23 September 2025 (UTC)[reply]
    • @OSMan2025: Roles can indeed be added freely and arbitrarily just like tags. Some roles are approved by the community as part of a tagging scheme and are documented as part of a relation type, because the meaning can change depending on the relation type. The wiki has pages such as OpenStreetMap:Role:from in order to direct readers to the right relation type page, essentially a disambiguation page. Separately, Sophox (Q55840137) and OSM Wikibase apparently rely on a different article naming convention, “Relation:restriction=from”. This format is useful because the role is technically meaningless without the relation type as context. [5] There are over 28,000 distinct roles, though only 121 are used more than 1,000 times; the rest are just one-off experiments or typos, certainly nothing notable enough for Wikidata. [6] More relevantly, there are almost 31,000 distinct pairs of relation types and roles, of which only 203 occur more than 1,000 times. [7] – Minh Nguyễn 💬 19:41, 25 September 2025 (UTC)[reply]
      The qlever SPARQL is very helpful. So roles might be better written as type (of relation)/role (as member of the relation), e.g. waterway/tributary - 31,661 occurrences in qlever. But osmwiki:Role:waterway says, that one is to be avoided. waterway/spring
      3,196 - spring is a role? My eye is a role of my head? Or would it be partOf instead of role? Is a spring a part of a waterway? Or is there first the spring, then the waterway? Is the "contribution"(?) to a waterway by a spring different from that of a tributary? River Thames Q19686: WD doesn't mention a spring, https://www.openstreetmap.org/relation/2263653 has a member of technical type "node" (https://www.openstreetmap.org/node/11638985293), with role spring. The node is partOf the relation (role:spring) and a way (a river part) and the way is also partOf the relations (role:main stream). The spring item in WD Q124714 has OSM tag "natural=spring". Not sure what to do with the OSM role "spring". Can one paint a spring on the map? Does it have an extension (size?)?
      I need to think further. How much is a role in OSM a role as defined in BFO, http://purl.obolibrary.org/obo/BFO_0000023
      role (Q4897819)? OSMan2025 (talk) 04:47, 28 September 2025 (UTC)[reply]
      @OSMan2025: Honestly, you're probably the first person to ever make the connection between OSM roles and BFO roles. The OSM community historically has had only a handful of people who understand or appreciate formal semantics. Instead, we have factions who avoid relations at all costs or desperately turn to relations, depending on the subject, motivated by what's convenient for their day-to-day workflow inside their editor of choice. Against this backdrop, roles have sometimes been seen as a convenient dumping ground for information that's probably best tagged on the relation or the member element.
      In this particular instance, the role spring apparently came from this sketch that envisioned the waterway relation type as a "thematic" relation, grouping anything somehow related to the river. Few such relation types have been successful in OSM's history, the most notoriously unsuccessful being street/associatedStreet. I'm certain that the spring role is only of interest to mappers, if that: only 2.5% of waterway relations contain this role. [8] On the other hand, natural=spring is a real tag that appears more than 65 times as often and is actually used by OSM data consumers.
       – Minh Nguyễn 💬 05:41, 28 September 2025 (UTC)[reply]
      Best query further down, but leaving different tests here:
      ----
      1 https://qlever.cs.uni-freiburg.de/osm-planet/HENMLi - query to show DISTINCT types per role and the quantity of the DISTINCT types per role shows "Waiting for response..." for over a minute.
      ----
      2 https://qlever.cs.uni-freiburg.de/osm-planet/zEQ4RU - without DISTINCT results are returned ("Limited to 100 results; show all 2,604 results"). When trying to see all 2604, "Waiting for response..." was shown and I did only wait 30s, then stopped. Examples of those that have distinct types:
      #01 | classification, site, site, site
      = | route, route, site
      0 | site, street number, level map, ... , route
      different | destination sign, destination sign, route
      ----
      Maybe the queries can be re-written using a subquery and then are faster, but I am not good at this.
      ----
      3 https://qlever.cs.uni-freiburg.de/osm-planet/9N11a9 uses "HAVING (COUNT(?type) > 100)" results are returned ("Limited to 100 results; show all 376 results") and COUNT DISTINCT shows values, but ORDER BY these values goes into "Waiting for response..."
      ----
      4 https://qlever.cs.uni-freiburg.de/osm-planet/trLZMK uses "HAVING (COUNT(?type) > 1000)" --- "Waiting for response..."
      ----
      5 https://qlever.cs.uni-freiburg.de/osm-planet/OP7RaS GROUP_CONCAT also using DISTINCT - now results are presented fast, even when extended to all results
      1. outer | used on 123 types | 37,372,626 usages
      2. to and from | used on 70 types each
      3. 1 | used on 11 types -- shown at position 37, the first to consist of a digit | 420 usages
      4. wall | boundary, site, city walls, residential, level, route, multipolygon, building | 363 usages
      5. (empty) | on 6 types, position 93 | 6,480 usages
      ----
      6 https://qlever.cs.uni-freiburg.de/osm-planet/vLJFz6 - the above restricted to "HAVING (COUNT(?type) > 1000)", 120 results
      1. position 98 | tomb | person, site, dog | 4,530 usages
      2. position 111 | 东往西 | route, route master | 1,627
      ----
      Observation:
      1. "role" seems to be used partially for something else than a BFO role ("1" doesn't represent a BFO role, does it?).
      2. role (see role wall) can be on very different types, even including "non-real world type" "multipolygon"
      3. role can be labeled
        1. (empty), i.e. no label?
        2. non-ASCII
        3. ASCII numeral
        4. ASCII using noun
        5. ASCII using not a noun
      OSMan2025 (talk) 13:46, 30 September 2025 (UTC)[reply]
      The only real constraints on roles are the constraints that the very generic data model imposes. Otherwise, each tagging scheme (i.e., each relation type) has its own idea of what relation roles are for. Minh Nguyễn 💬 05:23, 10 October 2025 (UTC)[reply]
  •  Comment Is it necessary to include the "Role:" prefix if they all have it? It can just go in the URL formatter. -wd-Ryan (Talk/Edits) 17:04, 24 September 2025 (UTC)[reply]
    @Wd-Ryan: thanks for spotting, my mistake, prefix removed from examples in property-proposal-template. OSMan2025 (talk) 21:54, 24 September 2025 (UTC)[reply]

Petal Map Place ID

[edit]
   Under discussion
DescriptionPlace ID in Huawei's Petal Maps
RepresentsPetal Maps (Q109607411)
Data typeExternal identifier
Example 1Wangfujing station (Q843213) → [9]
Example 2Ghibli Museum (Q947907) → [10]
Example 3Denver International Airport (Q330015) → [11]
Allowed values[0-9]+
Formatter URLhttps://www.petalmaps.com/place/?placeId=$1

Motivation

[edit]

Used by Huawei's Petal Maps (Q109607411), system map app in HarmonyOS NEXT (Q123469520) and its Map Kit, similar to Apple's MapKit. Also included in their Huawei Mobile Services (Q86729107) on Android, alternative to Google's Google Mobile Services (Q5274113). --内存溢出的猫 (talk) 03:41, 25 November 2025 (UTC)[reply]

Discussion

[edit]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/Place&oldid=2439808640"