Shortcut: WD:PP/PLACE

Wikidata:Property proposal/Place

From Wikidata
Jump to: navigation, search


Property proposal: Generic Authority control Person Organization
Event Creative work Term Space
Place Sports Sister projects
Economics Transportation Natural science Property metadata

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 2017/10.

Place[edit]

post town[edit]

   Under discussion
Description town part of the postal address, for example in the UK or Sweden
Represents post town (Q1968403)
Data type String
Template parameter postal_town in sv:Template:Geobox
Domain places and organisations
Example Örebro -> Gällersta (Q2563351)
Robot and gadget jobs you can probably harvest this from Wikipedia to some extent
See also postal code (P281)
Motivation

When I have designed templates on Wikipedia, I surprisingly discovered that this was missing. -- Innocent bystander (talk) 14:31, 21 August 2017 (UTC)

Discussion

I also add "organisations" as domain since I know that large organisations in Suomi/Finland has special designed "postal towns". For example "Varma" for Varma Mutual Pension Insurance Company (Q16916495) and "Skatt" (Swedish) or "Vero" (Finnish) for the Finnish national tax authority. -- Innocent bystander (talk) 14:31, 21 August 2017 (UTC)

I don't think the current description explains the meaning of the property adequately. I would also like more examples. ChristianKl (talk) 09:45, 23 August 2017 (UTC)
Well, I think you find all the examples you should need in the articles connected to post town (Q1968403) or post town (Q24700892), which were displayed here before somebody edited the page. -- Innocent bystander (talk) 20:10, 23 August 2017 (UTC)
An example: In sv:Hemsjö, Alingsås kommun you now see that postort = Alingsås is one of very few parts in the infobox that isn't supported by Wikidata. -- Innocent bystander (talk) 18:01, 24 August 2017 (UTC)

coordinate reference system[edit]

   Under discussion
Description coordinate (or spatial) reference system used to determine the coordinates of a location on Earth (default: WGS84) or some other globe
Represents spatial reference system (Q161779)
Data type Item
Domain coordinates on earth or any planet or natural satellite
Allowed values instances of spatial reference system (Q161779)
Example
Motivation

I thought we had a property for this for use a qualifier with coordinate location (P625), but it seems that we do not. Strictly speaking, coordinates - even on Earth - are meaningless without knowing the coordinates referencing system (CRS, also known as "spatial reference system" or "reference frame", see also geodetic reference system (Q1502887)) used - the usual one for coordinates on Earth is World Geodetic System 1984 (Q11902211) but one or more versions of each of International Terrestrial Reference System (Q74561), North American Datum (Q993433) and European Terrestrial Reference System 1989 (Q1378197) also exist, for example. The importance of specifying the reference system can be seen from [2], which gives several coordinates on the moon, and says "Differing results come from different models with different solutions. Currently, the lunar geoid is being redefined with Clementine data, so the location (latitude, longitude, and elevation) of everything will change again very soon. In short, we know where each of the [Lunar Modules] is located is relation to local landmarks; but assignment of latitude and longitudes to those locations is an evolving process.". Geo URI (Q5533943), for example, incudes a parameter for the CRS, see en:Geo URI scheme#Coordinate reference systems.

It may be assumed that, where not stated, the CRS for coordinates on Earth is WGS84, as that is used by most online mapping systems, GPS devices, and by the various WMF projects' mapping services. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:37, 9 January 2017 (UTC)

Discussion
  • Symbol oppose vote.svg Oppose redundant to existing qualifier for other property and unstructured when used in conjunction with P625.
    --- Jura 08:38, 10 January 2017 (UTC)
  • Pictogram voting comment.svg Comment This is a similar problem like with elevation above sea level (P2044) which is basically also meaningless without knowing the reference point. There it was decided to use determination method (P459) which seems to work quite well. --Pasleim (talk) 10:17, 10 January 2017 (UTC)
    • If we start adding values in P625 for places on Earth that are not using the default this just gets messy. I'm not sure why Pigs changed their mind on this. The earlier suggestion to use separate properties seems much more sensible.
      --- Jura 10:36, 10 January 2017 (UTC)

Happy to agree to this proposal. I understand that this will provide a link to an existing standard. Well done. Thanks, GerardM (talk) 14:22, 10 January 2017 (UTC)

I support the proposal and offer Washington Monument (Q178114) as an example. The most accurate value may not be stated in WGS84. The most desirable outcome would be to transform the coordinates into WGS84, or the nearly identical ITRF. The available qualifiers to specify that this was done, and how it was done, are sparse. The determination method property could be used to specify that a transformation was performed, and the proposed property could be used to state what coordinate system the value was transformed into. The untransformed value, of course, would be found in the referenced source. (An editor who won't be bothered referencing the source has no business transforming coordinates.) Jc3s5h (talk) 18:10, 10 January 2017 (UTC)

On further reflection, I think the user interface should be corrected to permit entry of the globe, and display whatever globe was chosen. Ideally editors would transform the value as necessary to ITRF or WGS84 and specify one of those as the globe, but if the editor didn't now how, they could specify whatever globe was used and leave it for a subsequent editor to do the transformation. It could also allow the entry of coordinates for features on other planets to be made through the user interface. Jc3s5h (talk) 18:29, 10 January 2017 (UTC)

Is there a Phabricator ticket for this proposed change to the interface? And an ETA for delivery? How does the later compare to the potential for having the proposed proerty in place in seven days or so? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:48, 10 January 2017 (UTC)
If the property is approved, what would your plan be to undo all the non-Earth globe fields that already exist, and remove globe from the data model (which, in the case of JSON, itself requires a Phabricator ticket)? Jc3s5h (talk) 22:09, 10 January 2017 (UTC)
I would do neither. For several globes, as well as Earth (e.g. Moon, Mars) there is more than one CRS. For each, we can assume or declare a default, but this proposal allows the specification of another. This proposal is not mutually exclusive with yours, and yours is not a reason not to do this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:14, 10 January 2017 (UTC)
I have created a Phabricator ticket in line with my response above, but it turns out there was already a Phabricator on the issue. Jc3s5h (talk) 22:30, 10 January 2017 (UTC) updated 11:48 11 January 2017 (UTC)
  • Pictogram voting comment.svg Comment, not sure if it should be a property or not… Embedding the coordinate system in the coordinnates, like it's done for the globe, would probably be better but as the globe is still not implemented in the interface right now (and it's causing several problems, like people adding earthly coordinate outside of Earth), I'm reluctant and hesitant. Cdlt, VIGNERON (talk) 10:58, 11 January 2017 (UTC)
  • Pictogram voting comment.svg Comment The more I think about it, the less happy I am with this proposal. For much of the 20th century, latitudes and longitudes in the UK were stated with reference to OSGB36 -- typically this gives a point on the ground about 100 to 150 metres away from where WGS84 would indicate. I am not at all happy with the thought of OSGB36 coordinates being used with P625, even when marked with a qualifier. I think we should maintain an insistence that all terrestial coordinates are converted to WGS84, so that this is the only scheme for terrestial coordinates that is acceptable as an argument for P625. Otherwise we are demanding that any use of P625 data must check the qualifiers and must be prepared to do coordinate conversions. As well as being a complete millstone, it's simply not realistic to expect this of data users. Most SPARQL searches don't even check qualifiers at all.
Instead I could see value in a qualifying the data with a qualifier "originally stated as" + a qualifier "original coordinate system", if we want to record how the data may have been originally presented in a given source. Jheald (talk) 21:56, 22 January 2017 (UTC)
  • Symbol support vote.svg Support This would help phab:T162331 a lot too. --Liuxinyu970226 (talk) 14:49, 11 May 2017 (UTC)
    • I object to taking such devices for map censorship (GCJ02 (Q29043602), BD09 (Q29043632)) seriously and making them acceptable for P625. These things are designed out of bad faith (creating drifts) and not numbered by ESGI; GCJ-02 in particular has the laughable error of using SK-42 ellipsoid for drifting WGS-84 input. They should be shot – rectified, I mean – on sight (um, input?). It's terrible to think about complicating queries for just these two bad things. --Artoria2e5 (talk) 18:08, 25 August 2017 (UTC)
  • Symbol oppose vote.svg Oppose Better to fix the bug Liuxinyu brought up on our end than to force others who use Wikidata to account for differing Earth geo-coordinates on their end. Mahir256 (talk) 20:49, 25 August 2017 (UTC)
    • Given that the proposal includes examples of lunar and Martian coordinates, your comment, and its basis in "differing Earth geo-coordinates", gives me concern that you may not have read it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:36, 26 August 2017 (UTC)
      • @Mahir256: This proposal per se is about easily inputting some older geodata not yet transformed to WGS84, not the terrible screw-ups Liu brought up. On another thought though, if this property is made to "rectify to WGS84 immediately by a patrolling bot", it may ease the workload on human users. Just don't keep data marked with it for long-term use… --Artoria2e5 (talk) 15:02, 26 August 2017 (UTC)
        • Good luck having a bot rectify lunar or Martian coordinates to WGS84. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:22, 26 August 2017 (UTC)
          • Apologies for misreading. Was looking at the OSGB36 comment. --Artoria2e5 (talk) 15:35, 26 August 2017 (UTC)
      • @Pigsonthewing: The general concern in the comment that I had was one of lack of standardization. You can replace Earth in that comment with any other celestial body; we should be assuming a standard coordinate system for each celestial body just as we do with WGS84 for Earth on Wikidata. (In fact, I'm sure the appropriate coordinate system can be readily assumed depending on the item in question.) There is no benefit to having multiple versions of the same coordinates for the Moon, or Mars, or any other such body (except in the random case where a location can't be expressed in one system but can in another), just as we don't need WGS84, GCJ-02, and BD-09 coordinates for locations on Earth in the same item. Instead there should be conversion tools for these as discussed (for Earth) in the ticket Liuxinyu linked to. Mahir256 (talk) 20:56, 26 August 2017 (UTC)
        • Who said anything about "multiple versions of the same coordinates"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:19, 26 August 2017 (UTC)
          • @Pigsonthewing: If this is intended for use [as] a qualifier with coordinate location (P625), it becomes conceivable for this property to become a separator (P4155) for coordinate location (P625)'s single value constraint (Q19474404). If you are not intending to modify that constraint to accommodate this property, then there should be some bot for converting non-standard coordinates (identified with this property as a qualifier) to standard ones—for non-Earth celestial bodies, such standards could be discussed separately—made ready before the property is established. (Perhaps I am way too fixated on Liuxinyu's rationale for supporting and Artoria's response to it.) Mahir256 (talk) 23:04, 26 August 2017 (UTC)

I've marked this as ready, on the basis that one objector has not responded to a request for clarification, and the other appears to heve misread this as being only about coordinates on Earth. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:46, 4 October 2017 (UTC)

  • Pictogram voting comment.svg Comment I think it's ready for being marked as not done.
    --- Jura 08:53, 9 October 2017 (UTC)
    • Noted that you have again failed to clarify your objection, as requested above, twice, on 10 January. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:14, 9 October 2017 (UTC)
      • I see 3 supporting (GerardM, Linuxinu970226, and Pigsonthewing), 4 opposed (Jura, Jc3s5h, and Mahin256) and one negative comment (Jheald). It doesn't seem ready to me. Jc3s5h (talk) 18:07, 9 October 2017 (UTC)
  • Symbol support vote.svg Support ~nmaia d 15:30, 12 October 2017 (UTC)
  • Pictogram voting comment.svg Comment I can see some use in documenting the coordinate reference system actually in use in wikidata for any particular celestial body, and I can see the confusion people fear above if multiple different ones are used for the same body. How about making this proposed property apply only to an astronomical object, not to any specific set of coordinates, to document the CRS that wikidata uses for that body? I think that would satisfy all sides here? ArthurPSmith (talk) 18:11, 12 October 2017 (UTC)

hydraulic head[edit]

   Under discussion
Description hydraulic head of a dam or hydroelectric power station
Represents hydraulic head (Q369743)
Data type Quantity
Template parameter |plant_hydraulic_head= in en:Template:Infobox dam
Domain hydroelectric power station (Q15911738), dam (Q12323)
Allowed units metre (Q11573), foot (Q3710)
Example Grand Coulee Dam (Q930391) → 380ft
Robot and gadget jobs probably
Motivation

(Add your motivation for this property here.) GZWDer (talk) 18:51, 17 January 2017 (UTC)

Discussion
  • Symbol support vote.svg Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:48, 17 January 2017 (UTC)
  • Symbol support vote.svg Support --Fralambert (talk) 23:27, 17 January 2017 (UTC)
  • BA candidate.svg Weak oppose What kind of determination method (P459) would need to exist to specify how the head was measured? Is it the "effective head" (factoring in losses)? In a hydroelectric dam, is the head determined to be the mid-height of the top of the penstock (Q1260995) minus the mid-height of the mill race (Q736691) outlet? Perhaps it's measured down to the top of the Draft tube (Q12050991)? Without this level of engineering specification, values of this property could mean many different things to different people. I agree in principle with the need for a property such as this one proposed, and will change my vote to one of support if further clarification is provided on the expected determination method (P459) which are proposed to be used as mandatory qualifiers to this property. Dhx1 (talk) 16:46, 8 February 2017 (UTC)
  • Symbol support vote.svg Support this property is needed, there is no other reasonable way to specify the hydraulic head. The determination method should be the standard one used for hydroelectric power stations, as reported by sources (as already used in the relevant infobox on Wikipedia). --Ita140188 (talk) 10:11, 8 August 2017 (UTC)

height above average terrain[edit]

   Under discussion
Description a measure of how high an antenna site is above the surrounding landscape
Represents height above average terrain (Q1295906)
Data type Number (not available yet)
Template parameter HAAT at en:Template:Infobox broadcast
Domain transmitter (Q190157)
Allowed units m
Example MISSING
Robot and gadget jobs From Wikipedia
Motivation

(Add your motivation for this property here.) GZWDer (talk) 18:12, 16 January 2017 (UTC)

Discussion
@GZWDer: What do you think about using height (P2048)? ChristianKl (talk) 14:17, 18 October 2017 (UTC)

delimits/marks out[edit]

   Under discussion
Description The element is on the border/limit of another.
Represents delimitation (Q27555163)
Data type Item
Domain geographic location (Q2221906)
Example
Motivation

This property could say that a mount, a mountain pass... is on the limit of a valley. For example,

< Pic de la Fossa del Gegant (Q3382408) View with Reasonator View with SQID > located on terrain feature (P706) View with SQID < Carança valley (Q28380499) View with Reasonator View with SQID >

is not satisfying (is the mountain part of the valley?) nor precise enough. You may want to know that an object lies just on the border of the valley, not in the middle. If many items had this property, a simple query on wikidata could create an approximate map of the shape of valley. El Caro (talk) 14:40, 18 January 2017 (UTC)

Discussion

designation[edit]

   Under discussion
Description less formal names, where "official name" is less appropriate
Data type Monolingual text
Domain place
Example Norra Visby (Q2061978):sv:Gustavsvik+Annelund
See also official name (P1448)
Motivation

When I work with småort (Q14839548) in Sweden. I use data from Statistics Sweden (SCB). SCB has never given these entities any real names. In the first report from 1990: Småorter 1990 (Q20087097) it is described that the official authorities who usually gives names to places never thought it was a good idea to set names to these entities. (SCB is not that authority.) Therefor SCB gave them "beteckningar", designations which are more of descriptions than real names. Those could look like "Gustavsvik+Annelund", "Uppsala:5", "Skärted + Sprängsviken + del av Nänsjö" or "Malnbaden (västra delen)". As you see, combinations of village names, municipality names, lake names, order number and such things as "parts of" or "northern part" can be found in these designations. This far, I have used official name (P1448) here, but it often looks very awkward, since they neither are "official" or real "names". As you can see in the latest SCB-report: Småorter 2015 (Q28048805), SCB have stopped adding these designations to these entities. We now have to find other sources to name these entities.

My first interest here are our småort (Q14839548), but I would not oppose this property to be used in other places. My use of P1448 can be relocated to a new property by a good botoperator. They all have the same group of source, and most of them has as (P794):Q14839548 as qualifier. -- Innocent bystander (talk) 20:10, 18 January 2017 (UTC)

Discussion
  • Comment: "Designation" can mean "heritage stats", in British English (and others?). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:24, 27 January 2017 (UTC)
    @Pigsonthewing: You can feel free to rename the proposal to something better in English. The Swedish word here is "beteckning", a word that can describe that a "name" is more of a serial number or description than a real name protected by the cultural heritage authorities. -- Innocent bystander (talk) 18:35, 27 January 2017 (UTC)
  • Pictogram voting comment.svg Options Maybe "name" or simply "quote" could work.
    --- Jura 07:33, 28 January 2017 (UTC)
    Place names (in Swedish, Finnish and a few other languages) are protected by the Swedish cultural heritage laws and authorities. These are not "names" in that sense. But it is definitely an option. -- Innocent bystander (talk) 11:48, 28 January 2017 (UTC)
    @Innocent bystander, Pigsonthewing, Jura1: would "designated name" work? Thryduulf (talk) 22:06, 14 April 2017 (UTC)
    @Thryduulf: I think it would! -- Innocent bystander (talk) 08:10, 15 April 2017 (UTC)

District[edit]

Texas' 30th Congressional District (1990 proposal)
   Under discussion
Represents constituency (Q192611)
Data type Item
Domain Administrative division
Example Thanjavur (Q41496) or Pattukkottai (Q7148673)
See also Again for assembly constituency too we need to add district in [3]

qualifier electoral district (P768); property located in the administrative territorial entity (P131)

Wikidata:Property proposal/french canton
Motivation

Currently we use property located in the administrative territorial entity (P131) but this often confusing. Should have seperate property to identify the place by its division. Thanks -- Mdmahir (talk) 09:11, 12 March 2017 (UTC)

Discussion
Symbol support vote.svg Support per Jura. Mahir256 (talk) 21:47, 19 June 2017 (UTC)
Pictogram voting comment.svg Comment I'm not sure this is really useful. Where I live (in New York State, USA) there are (at least) 6 separate "electoral districts" in play: the local party committee electoral district, the town council district, the county legislature district, the state legislature and state senate districts, and the federal congressional district. I believe there are also school, library, and fire department districts. These districts are not nested, their boundaries overlap - except I believe at the lowest "party committee district" level which do have uniform town, county, state, and federal representation across the local district. The local districts are very specific - people on one side of a street may be in one, while those on the other side in another. They may have holes in them (the one I live in contains a big hole for a separate local district for a gated community). And all of these districts may change over time - at least every ten years following a census. I don't even know what wikidata item you would attach a property like this to to have a reasonably accurate mapping of the reality of these districts - on a building-by-building basis? This doesn't seem realistic to include in wikidata at least as it is now structured. ArthurPSmith (talk) 18:50, 20 June 2017 (UTC)
I would imagine that if an elected body represents a given area, every 1st-level division of that area should have this property with values being the districts of that area. For example, Illinois (Q1204) -> Illinois's 1st congressional district (Q3401698) through Illinois's 26th congressional district (Q5999287) (qualified with start time (P580) and end time (P582) as appropriate), since the United States House of Representatives (Q11701) represents the entire United States. Champaign County (Q110187) -> (whatever state senate and house districts are part of that county), since the components of the Illinois General Assembly (Q1437547) represent the entire state of Illinois. Urbana (Q462184) -> (whatever county legislature districts/precincts are part of that city), for a similar reason.
As to the issue of borders, those should be resolved within the district items themselves, perhaps through links to KML files delineating those districts at appropriate points in time. Mahir256 (talk) 20:07, 20 June 2017 (UTC)
I don't see how this represents useful structured information. Having properties on the district (including say a KML file mapping its boundaries) would make more sense to me - located in the administrative territorial entity (P131) on the district for example would satisfy the relationship between Illinois and all of its congressional and other electoral districts and seems more useful than having this as an inverse property. ArthurPSmith (talk) 17:55, 21 June 2017 (UTC)

mean age[edit]

   Under discussion
Description mean age in a given place; qualify with P585
Represents no label (Q29975002)
Data type Number (not available yet)
Template parameter none
Domain countries, municipalities, settlements, ...
Allowed values 0-150
Allowed units year (Q577)
Example Prague (Q1085) → 42.0
Source various databases, eg. Czech Statistical Bureau
Planned use import values for all Czech municipalities
Motivation

I'd like to import values for average age in Czech municipalites. This is a blank spot in Wikidata; maybe similar properties such as median age or average age - men / average age - women should also be proposed Vojtěch Dostál (talk) 19:46, 18 May 2017 (UTC)

Discussion
Pictogram voting comment.svg Comment Hmm, I think it would be better to propose a property for demographic information (number of people of a given age) using the new "tabular data" format where the table is stored in Commons. We don't have a lot of tools for that yet (or any properties using it I think so far?) but in principle that would allow determination of average, median, or any other statistical property and this seems like a great test case for it. ArthurPSmith (talk) 17:49, 19 May 2017 (UTC)
Pictogram voting comment.svg Comment Interesting, but what if such detailed information is not available for our country? --Vojtěch Dostál (talk) 08:14, 20 May 2017 (UTC)
  • Symbol support vote.svg Support I think it's good to host this kind of data directly on Wikidata because that makes it easier to query it with SPARQL. ChristianKl (talk) 10:37, 21 May 2017 (UTC)
  • Pictogram voting question.svg Question Is this the mean or the median? Shouldn't that be clarified in the label? --Yair rand (talk) 23:50, 3 August 2017 (UTC)
    • @Yair rand: Okay, I renamed the property into "mean age" to prevent possible misunderstandings. It can have average age as alternative name. ChristianKl (talk) 15:30, 15 October 2017 (UTC)

fully subdivised into[edit]

   Under discussion
Description that location or object is fully subdivised into the parts given in qualifier
Data type MISSING
Domain places, physical objects
Allowed values places, physical objects
Example
Motivation 
The administrative division process is a known and studied problem (see for example this document in french - https://publications.polymtl.ca/832/1/2012_PierreDelaPoixdeFreminville.pdf ). Also administrative territorial entities can be quite complicated and there could be several kind of divisions that fully covers a division - electoral divisions can be different from other administrative divisions of the same territory. There may also be non administrative relevant divisions of a territory. This proposal can solve this by regrouping those into several statements. Under the same rationale that lead to disjoint union search and disjoint union of (P2738) View with SQID this allows to state that the list of divisions is complete. If that information is spread into multiple « has part » statement it’s more difficult to state that we know nothing has been forgotten (Maybe with
subject > has parts of the class (P2670) View with SQID < canton >
quantity (P1114) View with SQID < 7 >
…) author  TomT0m / talk page 15:39, 3 August 2017 (UTC)


Discussion
  • Why isn't this under Generic property proposals? - Brya (talk) 06:33, 5 August 2017 (UTC)
  • Pictogram voting comment.svg Comment I think the first usecase should currently be handled with contains administrative territorial entity (P150).
    --- Jura 13:24, 10 August 2017 (UTC)
  • Pictogram voting comment.svg Comment @TomT0m: 1. How exactly will you represent different groupings (electoral vs administrative)? Give a specific example. 2. "Fully" is a slippery thing. If a new subregion is created, or I delete one of the statements, does that make all the "fully" statements untrue? 3. Please be precise in your descriptions and examples! You use the P' template with non-existing props, Q' template with some strings where the result just doesn't parse reasonably, etc. Second time today I see a sloppy proposal from you, and this is just not like you, Tom! --Vladimir Alexiev (talk) 09:34, 3 October 2017 (UTC)

Mappy ID[edit]

   Done. Mappy place ID (P4388) (Talk and documentation)
Description identifier for place in Mappy
Represents Mappy (Q3287250)
Data type External identifier
Domain places
Allowed values [a-z0-9]{24}
Example Louvre (Q19675)54af8853e4b0a5972df8a3f2
External links Use in sister projects: [de][en][es][fr][it][ja][ko][nl][pl][pt][ru][sv][vi][zh][Wd][Ws].
Formatter URL https://fr.mappy.com/poi/$1
Motivation

It's like Google Maps CID (P3749) but the ID is in the URL. Tubezlob (🙋) 11:43, 14 August 2017 (UTC)

Discussion

Partially localted in the territorial entity[edit]

   Not done
Data type <item-invalid datatype (not in Module:i18n/datatype)
Template parameter (none directly but would help a lot with handling the location parameters of some infoboxes
Domain places
Allowed values administrative territorial entity (Q56061)
Example <La Mauricie National Park (Q1798539) partially localted in Saint-Roch-de-Mékinac (Q3463280)
See also territory overlaps (P3179)
Motivation

located in the administrative territorial entity (P131) is marked with located in the administrative territorial entity (P131)  transitive property (Q18647515), which makes pretty good sense for inference. When the item is itself an admninistrative entity this constraint implies that P131 means that "the whole item is located within this administrative entity". But when the item is not an administrative entity, the property is also used to mean "is partially located in the administrative entity". . For example La Mauricie National Park (Q1798539) has 3 located in the administrative territorial entity (P131), and it is not wholly contained in any of them. This is rather inconsistent and not inferrence-friendly. A simple fix would be this "partially located in administrative entity" property.

It would also help with slightly bizarre cases like Tours (Q288) that has located in the administrative territorial entity (P131) canton of Tours-Centre (Q913072) and canton of Tours-Est (Q743594) while canton of Tours-Centre (Q913072) and canton of Tours-Est (Q743594) are entirely within Tours (Q288). People apparently do it because they think of cantons as higher-level division that communes.

Zolo (talk) 09:01, 25 August 2017 (UTC)

Discussion
I have hundred of problems with that P131 is regarded as a transitive property (Q18647515). The property is 4 1/2 years old, and I still cannot see how it could be that. With that implication, you cannot use it at all in Q34. And I still cannot see how we in states that aren't federations like US and Germany can have a hierarchy between different types of administrative units. Our districts here are today the smallest of our administrative units, but their borders do not match with any other higher level of administrative division. They often do, but far far away from always.
My solution to this is that P131 should end being regarded as a transitive property. -- Innocent bystander (talk) 07:21, 27 August 2017 (UTC)
@Innocent bystander: the transitivity comes from the assumption that P131 means "entirely located in". Knowing that has lots of potential uses, for instance showing the location in template en:Template:Infobox Telescope (en:Five hundred meter Aperture Spherical Telescope).
There are many cases where an administrative division is entirely within a larger one, like France: commune->département->région, Italy: comune->province->region, China: town->prefecture->Province... But there are also many cases where it is not, so I think a second property would be a useful clarification. --Zolo (talk) 08:03, 27 August 2017 (UTC)
And is that true, also historically? When the Swedish communes were founded in the 1860's the parishes were intended to always be located totally inside a commune. But they were both changed independently, resulting in a big mess which the authorities had large ambitions to keep up with, but failed brutally. For many years Vetlanda City and Vetlanda rural municipality were both located inside Vetlanda parish.
The province of Blekinge and the county of Blekinge today exactly matches each other, but that has not always been true. -- Innocent bystander (talk) 08:25, 27 August 2017 (UTC)
The only solution I can see that helps us here is to add "all" types of administrative units in every item. Tour Eiffel should have not only P131:7e arrondissement, but every administrative entity that can be found in the area. Then we get rid of the problem that entities can overlap and the hierarchy is only partial. -- Innocent bystander (talk) 08:19, 31 August 2017 (UTC)
@Jura1: Oh, I had never seen territory overlaps (P3179) it seems exactly what I had proposed. I suppose this proposal can be retired. Now data have to be cleaned up. --Zolo (talk) 09:37, 31 August 2017 (UTC)
@Innocent bystander: in France, départements were from the start (1790) made subvided into communes, and régions have always been made of départements. Technically, some départements are no longer in régions and some places are no longer in any départements, but still a département cannot be in two different regions (some intermediate levels may be more messy. And the pre-1789 situation even more so.).
I think putting every administrative division in every item looks a bit confusing, and makes it harder to build simple Wikipédia templates. If we just call the P131 property, in a template it will show a long unsorted list. But it is true that in some cases, we will need to to just that, so the templates should probably be able to cope with it anyway. --Zolo (talk) 09:37, 31 August 2017 (UTC)
The templates I have designed for svwiki do just that. It looks for every item in P131 that has P31:Q127448 to find the communes, every item who has P31:Q193556 for the provinces and P31:Q21721343 to find the districts. The template do this at the same time as it avoidw claims with an "end date". To find the counties it first looks for P31:Q200547 in P131 and if there is none, it looks into the communes and lookup which county it is located in. It is also difficult to tell if provinces are located inside counties or if counties are located inside provinces. This source shows that some provinces are smaller than counties and some counties are smaller than provinces. I was born in Småland who has almost all of three counties inside it and smaller parts of two other counties. Now I live in Västernorrland county, who has all of Medelpad province inside it, and almost all of Ångermanland province.
Even if the districts almost always are much smaller than the communes, there are many places where the borders differs to some extent. That is because the borders of the districts were locked to how the parishes looked in 1999. The borders of the communes has changed since then, but the districts hasn't. It was decided that the borders of the districts never will change in the future. But the borders of the municipalities are changed whenever somebody finds a good reason.
Before 2000, Sweden also had another hierarchy, connected to the national Lutheran church. And the borders of the dioceses neither matched those of the provinces or those of the counties. Luckily we do not have to bother with that as a present administrative division. But they definitely were a historical administrative division of the nation. They still exists, but only inside the church. -- Innocent bystander (talk) 10:29, 31 August 2017 (UTC)
Actually, I also made a module in frwiki that looks for the right type of administrative division, but that looks for the located in the administrative territorial entity (P131) in the item in located in the administrative territorial entity (P131). Sadly, all wikis do not have this sort of template.--Zolo (talk) 12:57, 31 August 2017 (UTC)
Yes, my template also do that. It first look into the main item itself to see if there is any county or province there. If there is none, it looks for a commune in the P131 and go to that item to look for counties and provinces. It (in present time) works fine to find the right county, but it could potentially add wrong provinces for those villages who are located in communes that are located in more than one province. Therefor I today always put P131:province directly into the village-item. I do not have to do that when the commune is located in a single province, but I have no list of "single province communes" and that list could easily change, without telling us. The village of Läppe in the 90's became larger, making the communes of Vingåker and Örebro changing their borders to fit all of the village inside Vingåker. Suddenly the border between the communes and the provinces did not match each other any longer. The village was located in one single commune again, but was located in two provinces. -- Innocent bystander (talk) 08:06, 1 September 2017 (UTC)
@Zolo, Jura1: I see one option here. If this (proposed) property gets created, I could have use for it in Q34 (Sweden), no problem. But how about entities like Malmö (Q2211)? I do not know here and now when Malmö flooded the borders of Malmö commune, but at some point it did. In 2015 it suddenly flooded also the borders into a third commune. How do I best describe that this is no longer a single-commune-entity and instead becomes a two (or more) commune-entity? Then I suddenly have to switch from P131 to PXXXX, and P131 has to switch to county-level, since it is the smallest entity that enclose all of it? Note that the only simple relation we have in Q34 is between present day communes and present day counties. Not even the relation County/Province <-> Nation has always been simple, with disputed territories at the border of Norway. I am old enough to remember border disputes with Denmark, Finland and SSSR. (In the first two cases, uninhabited islands and in the third case fishing rights in the Baltic sea.) -- Innocent bystander (talk) 08:41, 4 September 2017 (UTC)

lodging on site[edit]

   Under discussion
Description hotels, campgrounds and other forms of lodging on a specific site
Represents lodging (Q5056668)
Data type Item
Domain Instances of subclasses of geographic location (Q2221906)
Example
Planned use French Template:Infobox mountain (Q5825897), to specify available mountain hut (Q182676), for instance
See also tourist office (P2872)
Motivation

This would enhance our coverage of tourism (Q49389). Thierry Caro (talk) 14:27, 28 August 2017 (UTC)

Discussion
  • Pictogram voting comment.svg Comment can't this be accomplished somehow via coordinate locations? Or is the intent to indicate businesses officially associated with a location, in which case why limit this to "lodging" (i.e. what about shops, restaurants, garages, rental car facilities at airports, etc)? ArthurPSmith (talk) 10:05, 29 August 2017 (UTC)
  • Of course it can certainly be done but I have the feeling that whatever, 'accomodation' is really a typical, widespread and thus direct property of tourist sites. Thierry Caro (talk) 16:42, 29 August 2017 (UTC)
I don't see why this can't be done with location (P276) and its variants? I don't see what the benefit of a dedicated property is. --Yair rand (talk) 01:01, 28 September 2017 (UTC)

gateway to this location[edit]

   Under discussion
Description location frequently used to access this destination
Data type Item
Template parameter |ville proche= in fr:Modèle:Infobox Aire protégée, for instance
Domain Instances of subclasses of location (Q17334923)
Allowed values Instances of subclasses of location (Q17334923)
Example
See also start point (P1427)
Motivation

Which other place gives you an access to this remote one? Which is the typical starting point for someone climbing till that summit (Q207326)? We probably should have this new property to easily document this. Thierry Caro (talk) 18:07, 8 September 2017 (UTC)

Discussion

Koxinga (talk) Thierry Caro (talk)

Pictogram voting comment.svg Notified participants of WikiProject Mountains. EdouardHue
VIGNERON
Thierry Caro
Paul Mackay
Pigsonthewing
Fralambert
Holger1959

Pictogram voting comment.svg Notified participants of WikiProject Protected areas. Thierry Caro (talk) 18:07, 8 September 2017 (UTC)

New York City Parks Monument ID[edit]

   Under discussion
Data type External identifier
Domain monument (Q4989906), sculpture (Q860861)
Allowed values [1-9]\d*
Example Columbus Circle (Q109968)299
Source https://www.nycgovparks.org/art-and-antiquities/permanent-art-and-monuments
External links Use in sister projects: [de][en][es][fr][it][ja][ko][nl][pl][pt][ru][sv][vi][zh][Wd][Ws].
Planned use use on existing monument items, create new ones
Formatter URL https://www.nycgovparks.org/art-and-antiquities/permanent-art-and-monuments/info?monId=$1
Motivation

For monuments and public art in the spaces administered by the New York City Department of Parks and Recreation (Q1894232); there are over 800 designated works, including about 250 sculptures.Pharos (talk) 20:17, 19 October 2017 (UTC)

Discussion
  • Symbol support vote.svg Support David (talk) 16:07, 20 October 2017 (UTC)