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:Infoboxes task force 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 24.

To add a request, you should use this form:

=== {{TranslateThis
| 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
|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. ''e.g.'' {{Q|6999}} (astronomical object), {{Q|12136}} (disease), {{Q|11436}} (aircraft), and more generally {{Q|2221906}} (place), {{Q|43229}} (organization), {{Q|1656682}} (event), {{Q|386724}} (creative work), etc.  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...
|suggested values       = (deprecated)
|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            = ~~~
(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


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



Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: Notable intersections of a highway

Pictogram voting comment.svg Comment - Qualifier for location of intersection would be useful. We might have this already, I'm not sure. --Jakob (Scream about the things I've broken) 00:48, 8 October 2013 (UTC)

Symbol support vote.svg Support per nom. Joshbaumgartner (talk) 11:26, 12 October 2013 (UTC)
Pictogram voting comment.svg Comment When/where do you think this information would be used? Macadamia1472 (talk) 08:41, 13 October 2013 (UTC)
What is "notable"? --Rschen7754 19:29, 12 October 2013 (UTC)
Symbol oppose vote.svg Oppose until we have a definition of notable. --Rschen7754 21:53, 18 October 2013 (UTC)
Notable means it has its own item already. --Jakob (Scream about the things I've broken) 21:50, 22 October 2013 (UTC)
What would you do for something like w:en:Interstate 5 in California, however? --Rschen7754 21:57, 23 October 2013 (UTC)
@Rschen7754: I have not been watching this page, which is why it took me this long to get back. Items for pages like the one you mentioned would not use this property. --Jakob (Scream about the things I've broken) 17:11, 8 November 2013 (UTC)
Yeah, I can't support this until something more concrete is nailed down. --Rschen7754 18:14, 8 November 2013 (UTC)

Pictogram voting comment.svg Comment The information that interstate 80 intersect with interstate 81 somewhere on its 2500 miles seems useless for me. Do you not want to say where they intersect? The infobox in en:Interstate_80 shows major junctions with information where they intersect and the order might be important as well. Maybe, one could think of a property that a "place lies on/near the road" and/or a "road goes trough/nearby a place". An intersection between two roads would then be a place with two or more of these properties. --Zuphilip (talk) 12:45, 31 December 2013 (UTC)

    • Still oppose; where's the constraints? --Rschen7754 14:59, 3 January 2014 (UTC)
      • @Rschen7754: How about, must at the level of state highway or above? Not every little road that crosses a highway will be added. --Jakob (talk) 15:46, 13 May 2014 (UTC)
        • @Jakec: But what about w:en:California State Route 1? --Rschen7754 08:52, 18 June 2014 (UTC)
          • @Rschen7754: If your asking about concurrences, these could be tagged with a qualifier like instance of (P31) --> concurrence. --Jakob (talk) 09:27, 18 June 2014 (UTC)
            • @Jakec: have you noticed how many junctions would have to be included on such an item? --Rschen7754 10:03, 18 June 2014 (UTC)
              • @Rschen7754: Maybe 50-ish at most? I realized that national-level highways are more of a concern here, so perhaps they should only be linked to other national-level highways, not state-level highways (state-level highways can still be linked to national-level ones). --Jakob (talk) 16:44, 22 June 2014 (UTC)
  • Symbol support vote.svg Support. Clearly useful for roads. Seems reasonably constrained; I don't see any massive room for misuse, especially given the provisional definition of 'notable' above. Emw (talk) 02:20, 14 May 2014 (UTC)
  • BA candidate.svg Weak oppose. I think this might be going too far in the way of simply duplicating large amounts of OSM data. --Yair rand (talk) 02:11, 24 June 2014 (UTC)
    • This is the data used for creating a diagram of a highway so I think it's okay that it duplicates OSM data. Symbol support vote.svg Support Filceolaire (talk) 14:43, 29 June 2014 (UTC)

Jakob, Macadamia1472, Joshbaumgartner, Rs, Zuphilip, Emw, Yair rand, Filceolaire, regarding the limits. What do you think of calling this property "notable intersections" and only allowing as many values as are used by the infoboxes linked to the item?--Micru (talk) 09:06, 1 July 2014 (UTC)

Well, but on en.wikipedia there is a hard limit of 10 junctions, while on de.wikipedia they list every junction... --Rschen7754 10:04, 1 July 2014 (UTC)
Rschen7754, can you provide some examples of articles with a high number of junctions?--Micru (talk) 10:47, 1 July 2014 (UTC)
I already have above: w:en:California State Route 1, w:en:California State Route 99, w:en:California State Route 33, w:en:Interstate 5 in California... --Rschen7754 10:57, 1 July 2014 (UTC)
Rschen7754, I was referring to the junctions in the infobox. Those articles contain all the junctions, but in the infobox there are only major junctions. I'm seeing that dewiki is not listing them all either.--Micru (talk) 11:07, 1 July 2014 (UTC)
Compare w:de:California State Route 52 and w:en:California State Route 52. --Rschen7754 11:14, 1 July 2014 (UTC)
Rschen7754, what is the problem? Each wikipedia can use a different criteria for selecting their major junctions, it is just a matter of qualifying them with stated in (P248) or criterion used (P1013). Later on it is possible to filter them accordingly with a lua script.--Micru (talk) 11:22, 1 July 2014 (UTC)
@Rschen: Is your main objection that items could become overloaded with statements and become impossible to view without crashing browsers, or is it something else? --Jakob (talk) 00:11, 2 July 2014 (UTC)
Partially, and because of the years of work it would take to transfer data over here. Also, on the English Wikipedia I have seen dozens of editors revert warring over the tiniest details of a junction list. I don't want to transfer those edit wars over here. (Keep in mind that I've been working with road junction lists and road infoboxes since 2006). --Rschen7754 00:24, 2 July 2014 (UTC)

Want a buttload of junctions on a state-level highway? w:en:Kentucky Route 80#Major intersections. --NE2 (talk) 19:35, 1 July 2014 (UTC)

Symbol oppose vote.svg Oppose at this time, as the ins and outs are not determined, and the current proposal presents the possibility of hundreds of items being added for some routes, or the possibility of meddling with standards that differ between wikis. Now, on the other hand, if WikiData adds the option for arrays, I can see this allowing us to add data for complete junction tables (mileage, locations, intersections and exit numbers... everything but notes) to a single item. - Floydian (talk) 20:15, 1 July 2014 (UTC)

Symbol oppose vote.svg Oppose for now. Basically per Floydian. TCN7JM 20:21, 1 July 2014 (UTC)

Symbol oppose vote.svg Oppose, would likely contain indiscriminate amounts of data. —Scott5114 [EXACT CHANGE ONLY] 20:27, 1 July 2014 (UTC)

Pictogram voting question.svg Question, Rschen7754, was it really necessary to engage in canvassing? We are supposed to be a plural project that has to accommodate the wishes of several communities. If one community doesn't want to use certain data, nobody is forcing them to, they can just ignore it.--Micru (talk) 21:28, 1 July 2014 (UTC)

It was a neutral notification, because I was genuinely unsure if the solution would fit our needs. As the English Wikipedia has the most highway articles on Wikimedia, and the most organized road editor community, it made sense that their needs should be considered. Of course, you are welcome to ask for their thoughts as well. Remember, Wikidata is here to serve the needs of the projects, including the English Wikipedia. Also, keep in mind that two of the "canvassed" commenters are local admins here. --Rschen7754 23:03, 1 July 2014 (UTC)

Symbol oppose vote.svg Oppose at this time. The proposal needs to be refined significantly to be useful for Wikipedia articles. Imzadi 1979  01:54, 2 July 2014 (UTC)

Buildings and structures[edit]

number of parking spaces[edit]

Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: number of parking spaces at this place


Pictogram voting comment.svg Comment Does this relate to railway line in the sense of a portion of track within the network or does it mean a train service running on this portion? In german, "Eisenbahnstrecke" und "Eisenbahnlinie" are two different things. Ridership numbers, rolling stock and depot are typical info about a service, while electrification or gauge describe the track portion. There is no 1:1 relation between the two and it might be reasonable to treat them as a separate type of objects. --Rudolph Buch (talk) 10:56, 10 April 2013 (UTC)

infrastructure and service should be split. - Gonioul (talk) 16:10, 16 August 2013 (UTC)

Department or region of railway[edit]

Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: The railways in ex-USSR countries have some subdivisions (departmments or directions, in Russia replaced by regions) (Russian: отделение or регион, Ukrainian: дирекція or регіон). Each station is dependent to one of these subdivisions
Pictogram voting comment.svg Comment - I think it is typical for every country to have railway districts that differ from other subdivisions. You could change the property so it works for every country. Would something like "is in railway district"? The railway districts can be sorted using "subclass of". --Tobias1984 (talk) 15:45, 28 July 2013 (UTC)
Pictogram voting comment.svg Comment - I do not know about other countries, incl. Ukraine, but in Russia 99% of railways are administratively divided into 16 railway companies (e.g. en:Moscow Railway), which are subdivided into several departments or regions (e.g. ru:Московско-Курский регион Московской железной дороги). However, logistically railways form several "networks" (e.g. ru:Московский железнодорожный узел), which are subdivided into "directions", e.g. ru:Горьковское направление Московской железной дороги, parts of which may be administered by one department and parts by another, and these "directions" can possess several "branches" (e.g. ru:Железнодорожная ветка Кривандино — Рязановка). So the structure is no less complicated than with settlements, and I am at loss on how to name all this. YLSS (talk) 13:23, 11 November 2013 (UTC)
Symbol support vote.svg Support, it is needed for infoboxes. — Ivan A. Krestinin (talk) 16:44, 11 November 2013 (UTC)
Ahonc, Tobias1984, YLSS, Ivan A. Krestinin: Recently we had approved the property applies to jurisdiction (P1001), I think it could be used for this case too. If there are no concerns about using p1001 for this, I will close this proposal.--Micru (talk) 18:34, 25 November 2013 (UTC)
applies to jurisdiction (P1001) is inverse. — Ivan A. Krestinin (talk) 19:30, 25 November 2013 (UTC)
Ivan A. Krestinin: True, what about "contains jurisdiction"?--Micru (talk) 19:36, 25 November 2013 (UTC)
I personally wouldn't mix different trees of subdivision. A typical place belongs to a political district, postal district, voting district, police district, military district. Of course all of these could be but into one property with a qualifier asking for the "type of jurisdiction" - But I'm not sure that is the current paradigm, also because of the inability to do constraint violations within qualifiers at the moment. --Tobias1984 (talk) 15:10, 27 November 2013 (UTC)



Wikidata:List of properties • v · d · e
Status:    Not done
  • Description: Approximative diameter of the place. Necessary when displaying a map of the place, to determine the zoom level.
  • Data type: string (actually integer: number of meters)
  • Domain: Places (even rivers need a proper zoom level when shown on a map)
  • please specify allowed values
  • Example item and value: Q90(Paris):10000 Q64436(Arc de Triomphe):70
  • Format and edit filter validation: number
  • Proposed by: Nicolas1981 (talk) 06:32, 5 September 2013 (UTC)

Some Wikimedia projects show a map of each place, in particular the Wikivoyages (example, see the map in the infobox). The zoom level has to be specified manually, which is a pain to synchronize between all Wikimedia projects that use them. Wikidata is the obvious place to share this data. Maybe "diameter" is a better name than "scale". Scale can not be calculated from superficy, as some places with strange shapes require a large scale even though their superficy is small (example: rivers). Nicolas1981 (talk) 06:32, 5 September 2013 (UTC)

  • Symbol support vote.svg Support looks like well known parameter of coord template. But it is better make it part of geo-coord data type. Maybe better contact to developers? — Ivan A. Krestinin (talk) 20:11, 5 September 2013 (UTC)
The coordinates-datatypes contains latitude, longitude altitude precision and a globe-parameter today. m:Wikidata/Data model talks about a dimension-parameter who will describe the size of the object. Maybe we should ask how these parameters are supposed to be used! -- Lavallentalk(block) 06:53, 7 September 2013 (UTC)
Thanks for finding this! The "dimension" parameter in datatype_geocoords seems to be what we need: "rough diameter of the object in meter, used for selecting the scale of the map and for uncertainty of an area". Nicolas1981 (talk) 03:26, 9 September 2013 (UTC)
I Symbol oppose vote.svg weakly oppose this property as I believe it would be more logical to place the scale in the geocoords data type. Macadamia1472 (talk) 09:16, 16 October 2013 (UTC)
There is a proposal for a wikimaps Individual Engagement Grant where he talk about a WNES bounding box - i.e. specifying the 4 corners of a box around the item. I think it would be better to specify such a bounding box rather than a circle. Symbol oppose vote.svg Oppose Filceolaire (talk) 22:55, 25 November 2013 (UTC)
Scale is better than 4 points because 1. in can be extracted from Wikipedia articles, 2. scale is well known parameter, 3. it is hard to specify many points for human, visual editor is needed, 4. if visual editor will be available, then is better to specify full data (KML). — Ivan A. Krestinin (talk) 18:07, 27 November 2013 (UTC)
I might agree with this property if it were "approximate scale", and scale isn't quite the whole thing anyway. "approximate distance scale"?... --Izno (talk) 20:42, 3 February 2014 (UTC)
  • Symbol support vote.svg Support property, Symbol oppose vote.svg Oppose name:
    1. The property: Though simple diameter is a very general dimension, it is useful basic information to have when other data is not yet available. The diameter can immediately be used to create a rough enclosure for other items with coordinates, and provide a rough "zoom" level for maps (that doesn't depend on some previous editor's opinions of context map size). It is a rough measurement, though: If a property equivalent to minimum bounding rectangle (Q1134256) will be created, as Filceolaire (talkcontribslogs) implies, that would provide complimentary data that could be used instead, or in combination with, the property being proposed here.
    2. The name: This should probably be "diameter" or "geographic diameter". Perhaps the parameter should be "diameter (in meters)" or something, at least for now, so that it is clear what unit is mandatory, since quantity properties on Wikidata don't yet have a unit/dimension parameter. "Scale" is an imprecise word for this; the word "scale" implies a ratio that does not exist in databases. GeoHack is the service used by the coordinate templates on most wiki projects; the "dim:" GeoHack parameter has existed for quite some time. The "scale:" parameter is older in GeoHack, but is still used by some people; unfortunately, it has long been used to refer to each editor's own opinion about the size of the surrounding map, not the size of the item. (Its meaning has also changed over time: It was originally just the zoom parameter for Google Maps, if I remember correctly, and has now been retroactively given a calculation.) --Closeapple (talk) 07:38, 18 May 2014 (UTC)
I would add
  • 3. the datatype. It should be 'number with units (meters)' not string; but if it is going to take some time to get that then 'dimensionless number' could work in the meantime provided the property name is 'diameter of bounding circle (in meters)' or similar. Using 'number' means these can be compared and ranked.
This needs a another property for the Centre of the bounding circle - type geocoord - or a description specifying that the center of the bounding circle is the coordinates given by coordinate location (P625) or whatever.
We also need properties for 'Northernmost point', 'Southernmost point' etc. with type 'coordinate'. I will propose those later - gotta go shopping now. Filceolaire (talk) 13:44, 19 May 2014 (UTC)


Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: property for item that has the demonym as label. The main item linked should use the .. form as English language.

Make it easier to find and use them. For each language, the form used as label for items should be defined (e.g. singular masculine adjective). Additional items with qualifiers could be used to store alternate forms. --- Jura 11:44, 19 May 2014 (UTC)

Edited the above proposal. --- Jura 14:20, 19 May 2014 (UTC)
Symbol support vote.svg Support. Emw (talk) 19:03, 31 May 2014 (UTC)
Pictogram voting comment.svg Comment someone nuked the sample items, but I guess the proposal can be understood without them. --- Jura 07:48, 22 June 2014 (UTC)
Symbol oppose vote.svg Oppose Since "demonym items" seem not to fulfill the notability criteria, I don't think it is a good idea to create this property. Better to wait till there is Wiktionary support, and treat them as linguistic data.--Micru (talk) 08:05, 22 June 2014 (UTC)
The items would fulfill the notability criteria because they are linked to this property.
I don't see how Wiktionary support would be of any help, as it's structured by string sequence rather than meaning. @Micru: Maybe you could explain how this would work. --- Jura 08:12, 22 June 2014 (UTC)
With lexical data support we would link to the item containing all declinations and lexical forms. I strongly discourage this property. Instead I recommend of the following:
  • facet of (P1269) for existing items like American (Q4742863), understanding that these items are not meant to represent the word, but the concept of being of a certain place and how that concept came into existence.
  • a mono/multilingual string property for demonyms with appropriate qualifiers
--Micru (talk) 20:24, 23 June 2014 (UTC)
Wiktionary doesn't seem to be on the planning horizon, so we need to find another solution.
Obviously, we do need to be rigorous with the labels, otherwise automated use of the words isn't possible. Current infoboxes in Wikipedia just use one form, so it shouldn't be much of an issue to define a primary form for this either.
Some sort of a string property could work. If the above solution seems to complicated, we could just start with the existing string format and add qualifiers to define the language used. --- Jura 05:29, 29 June 2014 (UTC)
Jura, that seems more reasonable and the monolingual datatype is almost ready (no need to qualify with language). If there are articles about the demonym, they can be linked with the qualifier subject of (P805). With the datatype change I would support the proposal.--Micru (talk) 08:53, 29 June 2014 (UTC)
This property was already created and was later deleted: [2]. 08:34, 26 June 2014 (UTC)
It seem to have been defined in a different way, attempting to use existing items for Wikipedia articles. The infoboxes mentioned above generally don't use these. --- Jura 05:29, 29 June 2014 (UTC)
Symbol oppose vote oversat.svg Strong oppose. This is exclusively lexical data, and thus not (atm) at all within Wikidata's domain. --Yair rand (talk) 20:55, 1 July 2014 (UTC)
@Yair rand: Wouldn't {{Wait}} be a better template to use then? --Jakob (talk) 21:59, 1 July 2014 (UTC)
Since the suggested datatype is "Item", I'm not sure it would make sense to consider an eventual property targeting lexical data to be the same as the one proposed here. --Yair rand (talk) 02:56, 2 July 2014 (UTC)
Ahh...okay. I Symbol support vote.svg Support the general idea, but we need monolingual text, not an item. --Jakob (talk) 13:06, 2 July 2014 (UTC)

list of monuments[edit]

Wikidata:List of properties • v · d · e
Status:    Done
  • Description: link to the list of heritage monuments in the place/area.

To join articles about settlements and administrative units with local and regional lists of heritage monuments. ŠJů (talk) 17:26, 3 December 2013 (UTC)

Support, needed.--Ymblanter (talk) 18:56, 13 December 2013 (UTC)
{{S}}, yes, queries does not help when the lists are manually culled. -- Lavallen (talk) 20:01, 13 December 2013 (UTC)
Agree we need something like this, but now this proposal is a property voor just a "list of <topic A>", although there are many items with a list to be connected. Can we not make a general property "related list" and specify the list topic as a qualifier ("main topic" = monuments ? Michiel1972 (talk) 12:32, 17 December 2013 (UTC)
Sounds like a good idea.--Ymblanter (talk) 16:02, 17 December 2013 (UTC)
Lists already have a "list of" property—qualifying the property on the linked page is data duplication. --Izno (talk) 02:55, 31 January 2014 (UTC)
I think I would support a "related list" property, but it needs to have a smaller (or different, at least) domain than the somewhat-inverse "list of" property. "list of monuments" is too specific to support, so I would oppose that. --Izno (talk) 02:43, 31 January 2014 (UTC)
I do have a concern with a property like this or similar in that we should be working to eliminate linkage to list-type pages. Wikidata should fill the purpose that list pages currently serve... --Izno (talk) 02:58, 31 January 2014 (UTC)
Pictogram voting comment.svg Comment Recently there was a discussion de:Wikipedia_Diskussion:WikiProjekt_Denkmalpflege#Denkmalnummer_als_Normdatensatz about "authority control" for munuments: There are states with centralized registers but also some (like Nordrhine-Westfalia) which organize "their" monuments in a purely local manner (i.e. on the administrative level of communities). Thus for this state alone there are more than 300 official monument lists, each of them with some numbering scheme for the items contained. As I understand the proposal it is not about introducing a property to mark Wikidata items for "list of monuments" articles (we do have is a list of (P360) and architectural heritage monument (Q811165), heritage site (Q889487) as refinements of memorial (Q1187960), don't we?), but to link individual monuments with some kind of list (a geographical object cannot be "contained in" a list).
The discussion on de:WP did not yield clear results but some ideas how to model this situation, like
  • source the ordinary statement X instance of (P31) a memorial (Q1187960) by stated in (P248) plus a wikidata item representing the official list (example Denkmalliste der Stadt Bonn (Q15632243) introduced for experimenting with Friedrich-Wilhelm-Straße 14 (Q14544558)). Problem: Where to put the official monument number (source statements only allow page (P304) and the like)
  • Variant: Use approved by (P790) in conjunction with the wikidata item for the community as a qualifier, optionally sourced like above-.
  • use catalog code (P528), constraining the number with catalog (P972) and the official-list-item as above: (I checked the discussion pages and current usage and it turned out that P528 is not restricted to astronomical catalogues any more)
  • introduce some kind of datatype for "structured numbers" which would allow to use monument numbers in the same way as "classical" authority control (there are examples for this way - namely by utilizing a specific template - on de:WP monument-list articles)
All these approaches base - or at least can gain - from having Wikidata items for the relevant list as official work (not a "creative" work, sometimes a database only, sometimes "published" as a whole, sometimes it is only known that such a list exists by law but can only be queried by parties with demonstrable interest). For these official-list items I think a definitive wikidata property is needed which also can be used to make these items eligible as targets for catalog (P972).
Actually (for Germany) even the scattered lists in Nordrhine-Westfalia often have no direct equivalent in Wikipedia list-articles: The official lists still contain hundreds of monuments and even when they are replicated in full de:WP breaks them down to smaller geographical subdivisions. IMHO an important aspect to clear beforehand is to clarify / regulate the relation between items-for-official-monument-lists and items-for-list-of-monuments-articles
BTW a closely related recent proposal is Wikidata:Property_proposal/Unsorted#street_key_.28en.29_.2F_Stra.C3.9Fenschl.C3.BCssel_.28de.29_.E2.80.93_.28Merci_de_traduire_ceci_en_fran.C3.A7ais..29 by User:Leit: Local authorities also administer "their" streets in a way similar to monuments. (And monuments typically are located in or at streets and places and therefore monument items are linked to streed items). Another proposal was Wikidata:Property_proposal/Archive/16#Aktennummer_.28de.29_.E2.80.93_.28Merci_de_traduire_ceci_en_fran.C3.A7ais..29 coined for the situation in Bavaria but unfortunately nobody did understand it.
The discussion on de:WP also attracted users with knowledge about the WLM-Database on toolserver which is still actively synchronizing monument information between commons and (monument-list articles in) individual wikipedias. For that to work already a great deal of uniformity in the structure of the thousands of monument-list articles has been achieved and modelling in wikidata taking the WLM database as a starting point as it appears to be the intention of the current proposal may be not too bad a start. -- Gymel (talk) 14:03, 1 February 2014 (UTC)
Another Pictogram voting comment.svg Comment (for those like me who get the impression that my lengthy comment above may be too remotely related to the proposal). The list-of-monuments-in-place-x articles to my understanding are the place where actual data entry happens. These list articles aim to be a complete reproduction of the official monuments list for the relevant municipality (in Germany an instance of municipality of Germany (Q262166)), constrained to a suitable smaller area (town, part of town, village, ...). These list articles are built up from tables, each row representing a (and usually linking to) one individual monument. One list article may contain several tables, each one (in a section of its own?) referring to one village within the broader geographical area covered by the article. The WLM database now to my understanding for example uses data from templates within the list articles to properly align the commons categories for individual monuments within the categories of the appropriate place and municipality. Thus for individual objects the WLM databases contains a double "uplink" to place/area and municipality (a proposal above Wikidata:Property_proposal/Place#située_dans_(village/quartier/parc) tries to establish the relation between object and place, since is in the administrative territorial entity (P131) is reserved for municipality etc. where located on terrain feature (P706) might be restricted to purely geographical features, not "topographic" ones).
Now there is a relation between the items for individual monuments or villages, places, areas etc. to items for list-articles, namely "mentioned in wikipedia list" simply by determining the (at most one) list article of the list-of-monuments-kind which covers the item. The relation would be even more useful if anchor information could be exploited. If one - as the proposal does - only considers "places/areas" it is just the inverse of a propery assigning to each of the list-of articles the item for the place it is dealing with (which probably should be done by qualifiying is a list of (P360) by a geographic restriction to the place item).
However there is an important but absolutely non-trivial relation between objects, places, areas, villages and even municipalities to either the superordinate administrative unit which maintains the official list of monuments (examples: the state of bavaria for all places in bavaria, or the respective municipality for all places in Nordrhine-Westfalia) or - as described in the previous remark - to work-like items for the pertinent monuments list which in turn can be enriched with properties specifying the maintaining administrative unit ("publisher"), the legal regulation, published versions, online availability as a database and so on. But since these official lists are scattered into many list-type articles and their items (for reason, in logical and convincing way, but nevertheless not or not always reflecting structure and subdivisions of the respective official list) a property linking places with list-articles as proposed would only document convenience splitting decisions internal to some Wikipedia and would obfuscate the real need for linking with official monuments lists (or the administrative entities responsible for the monuments list of the area). -- Gymel (talk) 22:29, 1 February 2014 (UTC)
  • Symbol support vote.svg Support A bit odd, but there seem to be thousands of these lists. --- Jura 05:32, 29 June 2014 (UTC)
  • ŠJů, Lavallen, Ymblanter, Izno, Gymel, Jura: this property seems too specific, when there are many cases that require a similar solution. What do you think of calling it "inventory list" and qualify it with of (P642)? That way we could also have:
< Cygnus (Q8921) (View with Reasonator) > inventory list search < List of stars in Cygnus (Q1142708) (View with Reasonator) >
        of (P642) miga < star (Q523) (View with Reasonator) >
--Micru (talk) 08:35, 29 June 2014 (UTC)
Not too much: For interstellar objects we already have a solution with "catalogue". Oeuvre lists are published catalogues, some of them are influential and used as a reference. "Denkmallisten" on the other hand are official lists by some administrative body for the area it governs. Therefore they are not an arbitrary "list of something" but more - and similar to the examples you gave - like an catalogue. I fear howver, that "catalogue" does not properly reflect the official nature of the inventory (for that reason I would also abstain from using "inventory number" which is coined towards acutal possession of an item by some institution). -- Gymel (talk) 08:52, 29 June 2014 (UTC)
Gymel, catalog (P972) is not restricted to any domain, if it is an official list then that property should be enough. inventory number (P217) doesn't have a domain constraint either and you can use it for monuments and qualify it with p972. When proposed "inventory lists", I was thinking of user-compiled article lists.--Micru (talk) 10:23, 29 June 2014 (UTC)
@Micru: Sorry, there are some twists I have not been aware of at my earlier reply:
  1. Individual Objects get a property with the (catalogue or inventory or proposed[?] monument) number, qualified by the catalogue, inventory or official list item. I don't think it is finally settled yet which property would be most appropriate, IMHO much depends on what type of item will be the value of the qualifier: The governmental publication or database in the sense of a citation or wikipedia lists trying to mirror or transcribe (sections of) these official lists.
  2. The proposal here tries to tie a region or administrative (sub) area (e.g. municipality or parts of that like boroughs et c.) with items representing the official list of monuments located in that area. Again, one difficulty might arise by the fact that there is no clear idea wether these will be citation items or ones pertaining to list of ... articles. -- Gymel (talk) 11:03, 29 June 2014 (UTC)
@Gymel: For #1 "inventory number" or "catalog code" would do, with qualifier "catalog". For #2 I would create two separate properties, one that could be called "notable catalog" to link any item with their relevant catalog, and another one to link with related items that represent lists, which might be community-created in the form of wikipedia articles, but they are not specified by a single source.--Micru (talk) 11:57, 29 June 2014 (UTC)
For catalalogues like BWV or stellar objects I'm fine with notable or relevant catalogue, for inventories (of museum objects in possession or - like here - object lists governed by law or administrative orders) there is some kind of natural monopole: One institution is singled out and this institution administers the list and issues its (numbered) entries. Thus authoritative or official list (or inventory) would be more on the point. At this place however it becomes important what items are the values of the proposed property: The authoritative list itself (even if unpublished) or some surrogate, which of course states the official numbers and maybe more, but can never be more than an adaption of the list. -- Gymel (talk) 12:31, 29 June 2014 (UTC)
@Gymel: If we want a general property it is more useful to know which ones are the relevant catalogs than to know which ones are official. Besides that is an information that can be queried from the catalog itself (maintained by (P126):government X), so why to put that information in the property when it can be in the item?--Micru (talk) 09:16, 1 July 2014 (UTC)
Not sure that we want a genral property - the class "list of monuments" is broad enough and to my understanding a kind of authoritativeness is always implied (it's the list, not a list). As for "put that information in the property": Q1833021 (Q1833021) stands for a Wikipedia list article reflecting the official list and therefore most certainly is maintained by some unknown wikipedians and not by some government agency and also does not have main regulatory text (P92). I don't think we can discuss the proposal any further as long there is a blank for what the suggested values should or could be. In a sense Q1833021 (Q1833021) could be interpreted as an edition of the official list, but this would imply further hassle since the wikipedia articles connected to the items are the edition contrary to the usual supposition that they describe (are about or represent) it. -- Gymel (talk) 09:56, 1 July 2014 (UTC)
Gymel, if you want this property to link to an authoritative list, then let's call the property like that. It can be further qualified with of (P642) if needed to specify if it is about monuments, street art, parks or whatever.--Micru (talk) 08:49, 4 July 2014 (UTC)
Pictogram voting comment.svg Comment It would probably be possible to simulate this property with a few others, but is it really worth the work? If Wikidata turns out to work better, eventually these lists might not be needed anymore anyways. Identifying them with a separate property seems much easier. --- Jura 08:30, 5 July 2014 (UTC)

✓ Done Use in a generic way. If it is an "authoritative list" you can mark the list as "instance of:authoritative list" or any ad-hoc created item. Notification: @ŠJů, Ymblanter, Lavallen, Izno, Gymel, Jura1:.--Micru (talk) 13:35, 22 August 2014 (UTC)


Wikidata:List of properties • v · d · e
Status:    Not done
  • Description: Attribution of an object to a Gemarkung (highest cadastral district) in Germany

The main reason for proposing this property is that a Gemarkung neither is an instance of an administrative territorial entity (Q56061) (usually it used to be one before the municipality was incorporated into another one) nor a geographical object (Q618123). In many cases a Gemarkung is identical to the area of an existing municipality (usually if the municipality has the same area as 200 years ago) but probably in most cases a municipality consists of several Gemarkungen who are identical to all the former municipalities that have been incorporated into this new municipality. However, it is not possible to represent the Gemarkungen simply by stating the former administrative division (using is in the administrative territorial entity (P131) with start date (P580) and end date (P582)) as Gemarkungen have often been merged in the aftermath of a territorial reform especially a century or so ago (whereas in the case of the territorial reforms of the 1960s and 1970s they have rather not been merged).--Leit (talk) 12:11, 7 February 2014 (UTC) I forgot to mention that Gemarkungen exist (even under this name) over all of Germany which is rather unique as the administrative divisions are very fragmented in that country.--Leit (talk) 12:15, 7 February 2014 (UTC)

Leit you said that "it is not possible to represent the Gemarkungen simply by stating the former administrative division (using is in the administrative territorial entity (P131) with start date (P580) and end date (P582)) as Gemarkungen have often been merged in the aftermath of a territorial reform especially a century or so ago". The fact that they were merged a century ago just means that the "end date" is a century or so ago. That doesn't stop you using P131. Symbol oppose vote.svg Oppose. Filceolaire (talk) 10:05, 27 June 2014 (UTC)

motto description[edit]

Wikidata:List of properties • v · d · e
Status:    In progress

Similar to seal description (P418), but for linking to the description of a motto. The latter will be soon created as well, since the monolanguage datatype is about to be deployed. LaddΩ chat ;) 00:17, 16 August 2014 (UTC)

  • Symbol support vote.svg SupportAyack (talk) 08:18, 22 August 2014 (UTC)
  • Symbol oppose vote.svg Oppose motto (P1451) seems to be enough to me. If more info is needed then create generic qualifiers for 'translation' or 'quoted from'. Filceolaire (talk) 17:44, 27 August 2014 (UTC)

Pleiades URI[edit]

Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: The Pleiades URI for a place

Pleiades is "a community-built gazetteer and graph of ancient places" collecting more than 34,000 places of the Ancient world (mostly Greek-Roman but expanding to other regions and periods). Each place is given a unique URI. Resources available for each place include geographic locations, names and references. In some cases DBPedia/Wikipedia are linked as references, facilitating the semi-automated addition of data here. As of now an experimental alignment with GeoNames has been tried . Either the full URI or the numeric ID could be used as property value. As the author of this proposal I also disclose that I am a contributor and reviewer of Pleiades. Steko (talk) 13:35, 19 August 2014 (UTC)

For similar indices we have used the 'string' datatype to just store the code number rather than storing the full 'URI'. A little automagic is then used to turn this into a 'URI'. That way a change in the make-up of the URI can be accommodated without having to change every instance. Filceolaire (talk) 05:24, 28 August 2014 (UTC)

Administrative division[edit]

Municipality code of Brazil[edit]

Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: Brazilian municipality code (IBGE)

Das IBGE, Instituto Brasileiro de Geografia e Estatística (Q268072), hat sämtlichen municípios, vergleichbar unseren Gemeinden (Q3184121) als territoriale Verwaltungseinheit eines brasilianischen Bundesstaates, einen eindeutigen 7-stelligen Code vergeben, beginnend mit der 2-stelligen Bundesstaatnummer. Es handelt sich um 5.570 municípios.

Unter diesen Codierungen sind sämtliche statistische Angaben zu einer Gemeinde in den Datenbanken des IBGE abrufbar, diese Seiten werden mit den Ortsartikeln verlinkt. Die Verankerung (parameter) in den Infoboxen (in der de:WP zu brasilianischen Orten ist vorgesehen - neue erweiterte Infobox), ebenso wird sie bereits bei Ortsartikel in der pt:WP unsichtbar erfasst, aber wird z.B. in Q14407124 noch nicht angezeigt (dortiger Änderungsantrag in der pt:WP ist ebenfalls notwendig).

Vergleichbar sind: P771 Schweiz, P911 Südafrika, P964 Österreich. Do not confuse with (Q17294166) for Portugal.

Motivation? Like to bring some life into Wikidata:Country subdivision task force/Brazil, step one. Emeritus (talk) 01:11, 10 July 2014 (UTC)


distance from river mouth[edit]

Wikidata:List of properties • v · d · e
Status:    On hold

Qualifier for P974 statements on streams. --Jakob (talk) 20:04, 5 June 2014 (UTC)

Symbol support vote.svg Support --- Jura 07:38, 22 June 2014 (UTC)
Symbol support vote.svg Support: This could be used for other items, such an each item that is a sluice (Q2280652) (such as a lock (Q105731)), or is a bridge (Q12280). Is this always distance from the mouth end? --Closeapple (talk) 02:02, 23 June 2014 (UTC)
Symbol oppose vote.svg Oppose There is also "river kilometer", and I see no reason to have two independent properties for the same concept. Better to have one that represents both, and then display the wished unit.--Micru (talk) 06:51, 24 June 2014 (UTC) Symbol support vote.svg Support Better name! However it will have to wait because we don't have units yet...--Micru (talk) 14:17, 26 June 2014 (UTC)
  • @Micru: It sounds like you're just opposing the name. I've changed it. --Jakob (talk) 12:37, 24 June 2014 (UTC)

Time2wait.svg On hold To be moved to pending. Notification: Jakob, Jura, Closeapple.--Micru (talk) 08:55, 1 July 2014 (UTC)

Strahler number[edit]

Wikidata:List of properties • v · d · e
Status:    In progress
  • Description: See w:Strahler number. To summarize, a level 1 stream has no tributaries, a level 2 stream has only level 1 tributaries, a level 3 stream has level 2 tributaries, and so on. But in the example of the level 3 stream, it is only a level 3 stream above the confluence of two level two streams, which in turn, only apply to streams downstream of their first tributary. Hence the multiple values in the example bellow. coordinate location (P625) could possibly be used as a qualifier to indicate what parts of the stream have what Strahler number (an item won't work because the first tributary of any given stream is not always notable).
  • Symbol support vote.svg Support. Seems useful! Jakob, please provide a proper description. Emw (talk) 13:43, 7 June 2014 (UTC)
  • Symbol support vote.svg Support --Micru (talk) 19:16, 23 June 2014 (UTC)
  • Symbol oppose vote.svg Oppose: It seems quite subjective, though maybe there's something I'm missing here. Based on a reading of Strahler number, the number appears to be relative to whatever data set a person is working on at the time. Having one coordinate for the first headwater only establishes where one of the order 1 streams is. Wouldn't one have to make subjective decisions about every ditch feeding into every tributary of the system to decide where whether each contributing tributary's mouth has a particular Strahler number when it joins? --Closeapple (talk) 14:37, 2 July 2014 (UTC)
@Closeapple: If I am not mistaken, the Strahler number only considers (officially) named tributaries, so that would solve that issue. --Jakob (talk) 14:41, 2 July 2014 (UTC)
@Jakec: Who would determine that though? For example, in the U.S., USGS GNIS is continuously added to, and that's handled by a different group that the one that maintains the National Hydrography Database; one state agency might have names for things that it has determined through research, while another does not. (I'm thinking of maybe a conservation agency vs. the transportation/highway department that puts signs up for river bridges.) The chances of the Strahler number from one source for one flow correctly meshing into a tributary's Strahler number from another source seems very low — it might even change with new editions of a source. It almost seems more stable if it were numbered backwards: Counting the tributary level upwards from the lowest mouth would lead to a more stable order number; but maybe that defeats whatever purpose people would use the Strahler number for. (What would someone use this number from Wikidata for, anyway?) --Closeapple (talk) 15:49, 2 July 2014 (UTC)
We could use multiple values and set ranks for them. If we also have multiple Strahler numbers, that might make things a bit messy though, so perhaps this property should refer to the highest Strahler number (i.e. the one at the mouth). --Jakob (talk) 15:29, 3 July 2014 (UTC)

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

Wikidata:List of properties • v · d · e
Status:    In progress
  • Infobox 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)

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

Welsh listed building code[edit]

Wikidata:List of properties • v · d · e
Status:    In progress
  • Data type: String
  • Domain: listed buildings in Wales
  • Allowed values: unknown; looks like number-only
  • Suggested values: (deprecated)
  • Source: external reference, Wikipedia list article (either infobox or source)
  • Example item and value: example usage
  • Format and edit filter validation:  ?
  • Robot and gadget jobs: Will create items for Wiki Loves Monuments where necessary. Bot will fill in values.
  • Proposed by: Magnus Manske (talk)

This is part of Wiki Loves Monuments UK. This starts in a few days, so if we could prioritize this please... Magnus Manske (talk) 21:34, 27 August 2014 (UTC)