Wikidata:Property proposal/Place

From Wikidata
Jump to: navigation, search
Shortcut: WD:PP/PLACE



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:AllPages.
  2. Check if the property is already pending or has been rejected.
  3. Check if you can give it similar label and definition as an existing Wikipedia infobox parameter, or if it can be matched to an infobox, to or from which data automatically can be transferred. See WD:WikiProject Infoboxes for suggestions.
  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. Creation can be done after 1 week by a property creator or an administrator.
  2. See steps when creating properties.

Add a request

This page is archived, currently at Archive 28.

To add a request, you should use this form:

=== {{TranslateThis | anchor = en
| en = PROPERTY NAME IN ENGLISH
| de = <!-- PROPERTY NAME IN German (optional) -->
| fr = <!-- PROPERTY NAME IN French (optional) -->
<!-- |xx = property names in some other languages -->
}} ===
{{Property documentation
|status                 = <!--leave this empty-->
|description            = {{TranslateThis
  | en = put English description for property here, e.g. same as in the infobox documentation
  }}
|subject item           = Qnnnnnnn <!-- item corresponding to the concept represented by the property, if applicable; example: item ORCID (Q51044) for property ORCID (P496) --> 
|infobox parameter      = put Wikipedia infobox parameters here, if existing; ex: "population" in [[:en:template:infobox settlement]]
|datatype               = put datatype here (item, string, media, coordinate, monolingual text, multilingual text, time, URL, number)
|domain                 = types of items that may bear this property; preferably use Q templates, as specialized as possible, or text. Special values (having specialized validation schemes): Persons, Taxons
|allowed values         = type of linked items (Q template or text), list or range of allowed values, string pattern...
|source                 = external reference, Wikipedia list article (either infobox or source)
|example                = sample items that would use that property, with proposed values; example: {{Q|1}} => {{Q|2}}
|filter                 = (sample: 7 digit number can be validated with edit filter [[Special:AbuseFilter/17]])
|robot and gadget jobs  = Should or are bots or gadgets doing any task with this? (Checking other properties for consistency, collecting data, etc.)
|proposed by            = ~~~
}}
;{{int:Talk}}
(Add your motivation for this property here.) ~~~~

For a list of infobox parameters, you might want to use table format:

{{List of properties/Header}}

{{List of properties/Row|id=
|title          = audio
|type           = media
|qualifier      =
|description    = Commons sound file
|example-subject= Q187 <!-- Il Canto degli Italiani -->
|example-object = Inno di Mameli instrumental.ogg
}}

</table>

For blank forms, see Property documentation and List of properties/Row


General[edit]

Administrative division[edit]

Stream[edit]

watershed area[edit]

Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: The area of a stream's watershed
  • Template parameter: "watershed" in w:template:infobox river
  • Data type: number with unit
  • Domain: rivers
  • Allowed values: numbers with unit of area
  • Source: various, there is no one centralized dataset for all the world's streams
  • Example item and value: Heberly Run (Q17544815) --> 6.42 [unit:square miles]
  • Proposed by: --Jakob (talk)
Discussion

One of the most important properties of streams and rivers. Different from the proposed area property because this is the area of the watershed, not the stream itself. --Jakob (talk) 14:34, 30 August 2014 (UTC)

Wait until the 'number with dimension' datatype is created so areas can be compared and converted to different units. Filceolaire (talk) 21:25, 31 October 2014 (UTC)

Other[edit]

borders a region, country, landscape, place[edit]

Wikidata:List of properties • v · d · e
Status:    In progress
  • Template parameter: Hier den Infobox-Parameter einfügen, falls es einen gibt. Beispiel: "Bevölkerung" (population) in en:template:infobox settlement
  • Data type: Item
  • Domain: body of water (Q15324)
  • Allowed values: region, country, landscape, place items
  • Source: Externe Referenzen, Listenartikel in der Wikipedia (entweder Infobox oder Quelle)
  • Example item and value: Beispiel: Tyrrhenian Sea (Q38882) <borders  Campania (Q1438)]
  • Format and edit filter validation: (Beispiel: eine siebenstellige Zahl kann mit dem Missbrauchsfilter 17 überprüft werden)
  • Robot and gadget jobs: Führen Bots oder Helferlein irgendwelche Tätigkeiten mit dieser Eigenschaft aus oder sollten sie solche Tätigkeiten ausführen? (etwa in dem sie andere Eigenschaften auf Konsistenz überprüfen, Daten sammeln etc.)
  • Proposed by: Oursana (talk)
Discussion

Motivation. Oursana (talk) 10:30, 23 July 2014 (UTC)

Isn't it a duplicate of shares border with (P47) ? --Pasleim (talk) 17:52, 26 October 2014 (UTC)
I think shares border with (P47) is only used with similar items, see talk. Otherwise we would also not have needed basin country (P205); located next to body of water (P206). This property we need and I propose is very similar to basin country (P205) but not for a state but for any geographic entity.--Oursana (talk) 22:51, 27 October 2014 (UTC)

Vice-county[edit]

Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: The Watsonian (British Isles, except Ireland) or Praeger (Ireland) Vice-county in which the place is located, for the purposes of biological recording.
Discussion

Note: I've been using located in the administrative territorial entity (P131), but that's a kludge, and Vice-counties are not used for administrative purposes. Not to be copnfused with traditional or modern administrative counties (which often have the same names). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:19, 4 September 2014 (UTC)

Pictogram voting comment.svg Comment @Pigsonthewing: I am not sure your proposition seem different of located in place (P1134). --Fralambert (talk) 19:47, 7 September 2014 (UTC)

WMS-address[edit]

Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: Address of basic WMS/WMTS/WCS/WFS services of a administrative regions. Use qualifiers to specify if service includes a type of information (e.g. just the roads, or water bodies, etc...)
  • Template parameter:  ?
  • Data type: URL
  • Domain: Add this property to administrative regions. The rank is not important just that they provide a WMS service.
  • Allowed values: URLs should be copy-pastable into any GIS program and readily connect to the service.
  • Source: Source is website that lists the address.
  • Example item and value: Austria (Q40) = "http://gisgba.geologie.ac.at/ArcGIS/services/karten_image/is_md_gk50/ImageServer/WMSServer?" + Qualifier to say that it is only a geologic map with at most a 1:50000 scale.
  • Format and edit filter validation: If possible
  • Robot and gadget jobs: Search the web for WMS adresses if possible.
  • Proposed by: -Tobias1984 (talk) 16:51, 27 September 2014 (UTC)
Discussion

Spatial length[edit]

Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: Spatial extent for the object along the main axis, what is most commonly referred to as its length.
  • Represents: length (Q36253)
  • Template parameter: "length" in w:en:template:infobox lake
  • Data type: Number
  • Domain: Any object with spatial extent
  • Allowed values: All positive one-dimensional values with a length unit
  • Example item and value: The length of lake Mjøsa (Q212209)
  • Robot and gadget jobs: Bots would collect this from both articles in Wikipedia and use external datasets
  • Proposed by: Jeblad (talk)
Discussion

This is a spatial extent for an object, not to be confused with a length along a path. Also called maximum length some places. Other proposals include the discussion at Wikidata:Property_proposal/Pending/2#length and Wikidata:Requests for comment/Dimensions and units for the quantity datatype#Length 2. I believe it is a difference between a spatial objects length along the main axis and some length. The later would use a qualifier. An alternate name could be length extent, or even spatial length extent. Jeblad (talk) 20:16, 26 October 2014 (UTC)

@Jeblad: In the development plan we have a geo-shape datatype (Wikidata:Development_plan#Geo-shape_datatype). I think it would be best to wait for that datatype. We could then either create this property or see if we can fill the database with high resolution shapes and then calculate values like: area, longest / shortest axis, northernmost point etc... -Tobias1984 (talk) 20:45, 26 October 2014 (UTC)
If the shape is known, then it should be no problem to infer this value, but having an extent of an object does not imply having a shape of the same object. Jeblad (talk) 20:53, 26 October 2014 (UTC)
I think it also depends on the resolution our geo-shapes will have. The calculated length of a lake especially with low-resolution polygons might be in conflict with what our sources say. So we probably need a property like this to input official survey data. -Tobias1984 (talk) 21:01, 26 October 2014 (UTC)
This is often referred to as one dimension i an spatial extent, where the extent itself is either an instance of a class or a typed blank node. Because we probably want to describe this in a simple way we should keep the description "flat". We could use the qualifiers to describe all the values for an "extent", but then we would have nothing for the main snak. Or, we could set it to "no value". That would be weird. Jeblad (talk) 21:16, 26 October 2014 (UTC)
Note that #Spatial extent is an alternate and more general solution. Jeblad (talk) 01:40, 30 October 2014 (UTC)
Wait until we have number with dimension datatype. Filceolaire (talk) 21:10, 31 October 2014 (UTC)

Spatial width[edit]

Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: Spatial extent for the object along the secondary axis, what is most commonly referred to as its width.
  • Represents: length (Q36253)
  • Template parameter: "width" in w:en:template:infobox lake
  • Data type: Number
  • Domain: Any object with spatial extent
  • Allowed values: All positive one-dimensional values with a length unit
  • Example item and value: The width of the lake Mjøsa (Q212209)
  • Robot and gadget jobs: Bots would collect this from both articles in Wikipedia and use external datasets
  • Proposed by: Jeblad (talk)
Discussion

This is a spatial extent for an object. Also called maximum width some places. Other proposals include the discussion at Wikidata:Property_proposal/Pending/2#length and Wikidata:Requests for comment/Dimensions and units for the quantity datatype#Length. I believe it is a difference between a spatial objects length across the main axis (length across the secondary) and some width. The later would use a qualifier. An alternate name could be width extent, or even spatial width extent. Jeblad (talk) 20:37, 26 October 2014 (UTC)

Note that #Spatial extent is an alternate and more general solution. Jeblad (talk) 01:41, 30 October 2014 (UTC)

Spatial height[edit]

Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: Spatial extent for the object along the ternary axis, in positive direction, what is most commonly referred to as its height.
  • Represents: height (Q208826)
  • Template parameter: "elevation" in w:en:template:infobox mountain (Note that "elevation" is interpreted as grade/slope in some languages.)
  • Data type: Number
  • Domain: Any object with spatial extent
  • Allowed values: All positive one-dimensional values with a length unit
  • Example item and value: The height of a mountain Glittertind (Q397876)
  • Robot and gadget jobs: Bots would collect this from both articles in Wikipedia and use external datasets
  • Proposed by: Jeblad (talk)
Discussion

This is a spatial extent for an object. Also called maximum height some places. Other proposals include the discussion at Wikidata:Property_proposal/Pending/2#Height_.2F_depth_over_sea_level and Wikidata:Requests for comment/Dimensions and units for the quantity datatype#Length 2. I believe it is a difference between a spatial objects height and some generic height. The later would use a qualifier. The hight is of the object itself unless referred to a reference point by a qualifier, and the reference point is using WGS84 unless the whole statement has a qualifier that changes the reference system. An alternate name could be height extent, or even spatial height extent. Jeblad (talk) 20:43, 26 October 2014 (UTC)

Note that #Spatial extent is an alternate and more general solution. Jeblad (talk) 01:41, 30 October 2014 (UTC)

Spatial extent[edit]

Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: Spatial extent for the object along some axis, in positive direction perpendicular from a reference plane, what is most commonly referred to as its maximum width in some direction.
  • Represents: height (Q208826)
  • Template parameter: for example "elevation" in w:en:template:infobox mountain above the geoid WGS84 (Note that "elevation" is interpreted as grade/slope in some languages.)
  • Data type: Number
  • Domain: Any object with spatial extent
  • Allowed values: All positive one-dimensional values with a length unit
  • Example item and value: The height of a mountain Glittertind (Q397876)
  • Robot and gadget jobs: Bots would collect this from both articles in Wikipedia and use external datasets
  • Proposed by: Jeblad (talk)
Discussion

This is a spatial extent for an object in some direction, going perpendicular on a plane, and unless otherwise specified it is the maximum length in any direction.

  • A qualifier instance of (height (Q208826) is this right?) would take whats given as subject item above and will specify what the extent measure. (For example the height of a mountain.)
  • A qualifier geoid (perhaps better called datum) which gives the interpretation of the items referenced, that is a height is according to the instance of. Default is WGS84 (World Geodetic System 1984 (Q215848)).
  • A qualifier reference item which would be interpreted according to the instance of and geoid if that is given. The measured length is by extension to the surface of this item. Could be an extended plane.
  • A qualifier extent coordinate system to specify the local coordinate system. Default is spherical coordinate system (Q203218).
  • A qualifier azimuth or orientation according to the instance of and geoide. Defaults to "unknown".
  • A qualifier inclination or polar angle according to the instance of and geoide. Defaults to "unknown".

Tried to reformulate the spatial extents to be a single generic one. It seems that there is a problem whether the system is a local one when the reference system point back to itself or the geoid is undefined, or it is a global one references something else. One way around could be to drop geoid and only use reference item and infer geoid from this item. The item lives within some other system or is self referencing. No reference item would be interpreted as a self reference.

Note that if the azimuth and/or inclination is set wrong the measurement axis my never touch the surface of the reference item. Jeblad (talk) 01:38, 30 October 2014 (UTC)

Wait until we have the 'number with dimension' datatype, though I am really not clear how this is used and whether it would be better using a collection of specific properties such as 'Base' for mountains. Filceolaire (talk) 20:59, 31 October 2014 (UTC)
Filceolaire can you point me to wherever a discussion about a 'number with dimension' datatype is going on? Getting a quantity datatype right is difficult, but rather easy compared to a dimension datatype. To make an example, a length dimension can exist and within that dimension there can be two length measures that can not be compared. Most of the time this situation arise because of lost knowledge about how base units relates, or becase there is (or was) conflicting definitions. My favorite example is the length measure "coffestops", see also m:Wikidata/Notes/Values. Another nice one is that "there are 4 stone throws (w:no:Steinkast) on one arrow shot (w:no:Pilskudd)", that is old Norse length measures. There is also "vika sjóvar" which is the distance you row a boat in two hours, which is calculated to be 11 112 meter on Wikipedia. :D In effect you have subdimensions within a dimension, but note that subdimensions in this case does not imply subclasses you can cast to a common baseclass (length is an abstract property and you can't cast a coffestop to a base class). Anyhow, I think it is better to create usable solutions and reprocess existing properties later when someone create the perfect solution. Jeblad (talk) 15:32, 5 November 2014 (UTC)
See Wikidata:Requests_for_comment/Dimensions_and_units_for_the_quantity_datatype. Filceolaire (talk) 19:08, 5 November 2014 (UTC)
I saw that page, didn't realize it was a proposed as an implementation. As it stands it is probably not a solution, in fact I think it will make it really hard to solve some real-world problems.
Perhaps I should try to make a better explanation. That page describe the preferred units to use, it does not describe the role the measurement have. A property (predicate) describes the role a specific value (object) has in relation to an item (subject). An extent is such a property, and that will use a length measurement, possibly with units according to the given page. It is possible to use a length as a property, but then you must add qualifiers to say that this is in fact an extent. I think it is better to say what you measure with the property itself, and then add refinements to that, otherwise you need qualifiers about qualifiers (statements about reified statements about reified statements). An extent can have an orientation, but a length does not have one. It might not even be a measurement in a straight line. Jeblad (talk) 19:43, 5 November 2014 (UTC)
In this case instance-of seems to be right as this would be a statement about a height, that is a height measurement. Usually it is wrong to use instance-of as a qualifier, that is rdf:type about a statement. Jeblad (talk) 02:32, 23 November 2014 (UTC)
Pictogram voting comment.svg Comment. Jeblad, Filceolaire, how about using first-class properties like height (or spatial height) when applicable, and this property for more complex spatial extents? This approach works well for our kinship properties, where we have first-class properties like mother, father, brother, sister and child for basic relations, and relative with a type of kinship qualifier for more distant relations. Emw (talk) 01:11, 9 December 2014 (UTC)
Emw There are 75 properties using this data type listed on Wikidata:Property_proposal/Pending/2 which have been approved and are waiting, pending the creation of this datatype. Check there and see if the property you are proposing is already approved. Filceolaire (talk) 23:25, 17 December 2014 (UTC)

near[edit]

Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: to describe when something is commonly known to be located in the general area of something else, but without known specificity (synonyms are 'nearby', 'in the vicinity of' or perhaps 'close to'). Many historical events are only recorded at this level of detail e.g. "[person] was born in the outskirts of Paris"
    Not to be used when more precise location is known.
Discussion

Sorry if I've not filled out the template correctly... it's the first time I've tried. This issue came up during the GLAMwiki Hackathon this week where I was being taught how to use Wikidata. I was working on the Léon_Pourtau entry (since it's a biography that I wrote on en.wp recently it was a good one to practice with) and even as a group none of us could come up with a "correct" way of inputting the "place of death" field. "Atlantic ocean" is too vague, and "sable island" is incorrect. It was suggested I come here to propose the option I thought of during the event to see what others thought of it. Wittylama (talk) 17:55, 20 November 2014 (UTC)

  • Symbol support vote.svg Support. Cool idea. However, given that qualifiers will not be queryable for the foreseeable future, let's avoid making statements that require examining a qualifier to be correct. For example, if a person were born "around" but not actually in Paris, then state something like "Alice place of birth Greater Paris". In other words, since I can't think of a good example of how this property would used to indicate "nearby", "close to" or "in the vicinity of" but not "located in" or "part of", I'd recommend restricting usage of this property to how Wittylama does in the 'Example' field above.
We should also strive for precision where easily possible. E.g., with Léon Pourtau having died in the Atlantic Ocean near the Sable Island, Canada, we can say "place of death North Atlantic", rather than just "Atlantic Ocean". (The "near" qualifier still obviously helps in that case.) These are just nitpicks. A "near" qualifier seems clearly useful. Emw (talk) 14:01, 21 November 2014 (UTC)
  • Item: Offshore Sable island
  • Statement: Is near -> Sable Island
  • Statement 2: Part of -> e.g. North Atlantic
  • Item: Léon_Pourtau
  • Statement: Place of death -> Offshore Sable island
This would not require the usage of any qualifiers in my opinion. --Tobias1984 (talk) 18:08, 21 November 2014 (UTC)
Tobias1984, I agree. Wittylama, what do you think? Emw (talk) 13:48, 8 December 2014 (UTC)
Thanks for making such a considered response to my suggestion Tobias1984 & Emw! I agree that this would solve the issue of this specific article, and I defer to you greater wikidata-expertise in the matter. However, I do worry that this solution requires the creation of a new item that feels very... hackish. It seems to be an intellectual workaround to the specific issue, and one that does not scale....I assume that it's not good practice to simply create wikidata Q items every time we want to indicate that something happened near another existing geographically-marked Q item. For example, I imagine that every article about a shipwreck should ideally have a fact added which indicates where the shipwreck occurred - and in all (?) cases, shipwrecks happen either ON a specific rock, or NEAR a geographical feature. Do we expect to create a Q item for "offshore <harbour>" for every port in the world or "offshore <peninsula>, since every harbour or peninsula in the world has had shipwrecks NEAR it [and this is just limiting myself to discussing shipwrecks...]?
By the way Emw - great presentation! Wittylama (talk) 18:48, 16 December 2014 (UTC)
Wittylama, fair point. (And thanks for the kind words.) I am inclined to simply create this interesting property and hash out best practices on its Talk page, as implementers get a feel for what works for this. Tobias1984, what do you say? Do you support the creation of this property or do you think more discussion would help? Emw (talk) 03:05, 18 December 2014 (UTC)

Point of interest[edit]

Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: Spatial location related to another location (e.g. a city) that might be of interest (e.g. a tourist attraction)
Discussion

When Googling for certain places, in the 'knowledge graph' box a list of 'points of interest' appears (see example), this sounds like a very valuable addition to Wikidata as well. A case could be made that this could be a combination of several different properties (e.g. monuments, parks, squares, etc.), but given that the types of POI's might be endless, and is very difficult to create ranking and filter such a list, i think a single property would be better. I thought about calling this 'touristic attraction', but 'point of interest' sounds a little bit more neutral. I could imagine this would be very useful for Wikivoyage as well. Husky (talk) 23:50, 20 December 2014 (UTC)

If there were just three POIs for Amsterdam, this might work. Otherwise, shouldn't this work the other way round: determine what are POI for your interest => select the ones that are located in Amsterdam. --- Jura 13:13, 21 December 2014 (UTC)