Wikidata

Wikidata:Property proposal/Archive/2

< Wikidata:Property proposal‎ | Archive
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Generic / Allgemein / Général

legal status

  • Description: administrative status
  • Datatype:' Item
  • Domain:
  • Infobox parameter example:
  • Comments: I think it should encompass things like (California) is a US State. Or (Baker & McKenzie) is a Swiss Verein, but I am not sure about how the property should be called. I hear that lawyers can be rather fussy on this kind of things ! --Zolo (talk) 14:26, 6 February 2013 (UTC)
  • Hmm, I'm uncomfortable with including entire states in the domain here. I'd hope we'd develop separate properties specifically for governments and their administrative subdivisions (states, counties, cities, etc), and I don't see legal status adding much beyond what those properties would imply. I wouldn't object to this property if it's restricted to other organisations (companies, associations, political parties, charities, etc), although some of those might also be better covered by more specific properties. --Avenue (talk) 13:01, 9 February 2013 (UTC)
  • I am fine with having a specific property for administrative division. I do not see any benefit compared to a general-purpose property but we can always merge them later on. --Zolo (talk) 12:53, 10 February 2013 (UTC)
  Oppose Ambiguous. If I read "legal status" I think about married or not. --Kolja21 (talk) 19:46, 19 February 2013 (UTC)
  Neutral We really need a better name, but the idea is good. --Faux (talk) 17:56, 20 February 2013 (UTC)
  Oppose, if the new property type of administrative division covers this--which it seems to. I just made an edit to your example, California, to show that P132 is making the statement you appear to be asking for. Espeso (talk) 19:57, 22 February 2013 (UTC)

Authority control / Normdaten / Autorité

Person / Person / Personne

aunt / Tante / tant

  • Description: speaks for itself, "the subject has the object as their aunt (paternal or maternal)"
  • Datatype: Item
  • Links:
  • Domain: Person
  • Comments: quite why we have uncle already but not aunt is a mystery to me....! The Rambling Man (talk) 11:33, 23 February 2013 (UTC)
  • I agree that we're inconsistent as to where you should have one property and where you should have two, but clearly there's no sense in having one but not having its logical correlate. That would be like, instead of having "grandparent" and "father" and "mother", having only "grandmother" and "father". — PinkAmpers&(Je vous invite à me parler) 16:16, 23 February 2013 (UTC)
    Sure, but my point is that you could have just renamed the property from "uncle" to "uncle or aunt". Are renames forbidden by the software? I've linked this discussion from the project chat linked above, I hope we'll get more ideas. --Nemo 21:39, 23 February 2013 (UTC)
  • I'm also interested if "grandchild" should be there since we have "grandparent". Are these links one way only (doubt it, since we have "mother" and "child" etc, so why don't we have "grandchild"? The Rambling Man (talk) 18:14, 24 February 2013 (UTC)

teacher/Lehrer

  • Description: A person refered as object's teacher in the field where object became notable
  • Datatype: Item
  • Links:
  • Domain: Person
  • Comments:

Šlomo (talk) 22:20, 7 February 2013 (UTC)

  • Oppose Teacher is way too generic imo. Choosing one or two educator/mentors who had a particular impact on a notable person is too arbitrary and subjective for a datatype, imo. Shawn in Montreal (talk) 20:04, 21 February 2013 (UTC)
  • oppose As Shawn. Too arbitrary. It could mean: Some centuries ago someone who taught a handful of university students in his own home and influenced them extremely (as their only multiplicator of knowledge). 19th century: Someone who taught a larger class, his name was used by former students as a reference when travelling Europe ("worked in XY’s lab"), used in the same way in contemporary obituaries ("student of the famous XY …"). Today: Took a class. Famous teacher never knew me by name. –– What it should mean can't be put in raw data. --Polarlys (talk) 01:48, 24 February 2013 (UTC)
  •   Neutral. I don't see this property being a problem if its object is a notable person, and it is determined to be relevant to the subject's career. But those considerations are hard to fit into Wikidata. On that note, see also property proposal "influences", where similar arguments can be made. I have to suggest though, if not "teacher", we should have more specific properties like "academic advisor" (  Support). because that is very specific, and obviously a noteworthy fact that has the potential to expose interesting relationships within structured data. Espeso (talk) 02:23, 24 February 2013 (UTC)
  •   Oppose needs original research in many cases. Somehow the first teacher in life is more important than the last.--Giftzwerg 88 (talk) 18:39, 24 February 2013 (UTC)
  •   Oppose ditto. - Ssolbergj (talk) 02:57, 26 February 2013 (UTC)
  Not done Consensus against this at this time. Sven Manguard Wha? 04:53, 26 February 2013 (UTC)

pupil / Schüler / ...

  • Description: A person refered as object's pupil or student in the field where object became notable
  • Datatype: Item
  • Links:
  • Domain: Person
  • Comments:

Šlomo (talk) 22:20, 7 February 2013 (UTC)

oppose, see "teacher" --Polarlys (talk) 01:49, 24 February 2013 (UTC)
  Oppose, see teacher--Giftzwerg 88 (talk) 18:44, 24 February 2013 (UTC)
  Oppose, see teacher - Ssolbergj (talk) 03:15, 27 February 2013 (UTC)

killed by / / tueur

Status:    Done

→ Property:P157

  Support --Viscontino talk 17:04, 14 February 2013 (UTC)
Changed english version to 'assassinated by' for accuracy reasons. Sven Manguard Wha? 18:50, 18 February 2013 (UTC)

influences

  • Description: influences
  • Datatype: item
  • Source: ?
  • Domain: Person
  • Infobox parameter: w:en:Template:Infobox_scientist / influences
  • Comments: the property "influenced" could be inferred from this one.
    • This is a nebulous concept and it has never suited infoboxes/structured data that well. There are often debates about it on Wikipedia. I don't think Wikidata is the place to try and pull apart who influenced who (although it can certainly be sourced in many cases). I tend toward   Oppose... Espeso (talk) 02:16, 24 February 2013 (UTC)
    •   Oppose requires lots of original research. Can you tell who of all your teachers, parents, relatives, trainers, coaches, friends, colleges has influenced you or hasn´t? Everybody you talk with and everything you see or hear influences day by day.--Giftzwerg 88 (talk) 18:50, 24 February 2013 (UTC)
    •   Oppose this is perhaps not suitable in infoboxes. - Ssolbergj (talk) 03:00, 26 February 2013 (UTC)
  Not done Consensus against this at this time. Sven Manguard Wha? 04:53, 26 February 2013 (UTC)

Educated at (Alumni of)

→ Property:P69

  • Description: Institution at which subject was educated
  • Datatype: Item
  • Links:
  • Domain: Person
  • Infobox parameter example: en:Template:Infobox person (|education=, |alma_mater= )
  • Comments: "education" on enwiki is freetext (eg/ "University of Foo, Data Studies, 1973"), alma_mater seems to be restricted to the most recent institution. We probably want something comparable to enwiki's "Alumni of X" categories, with multiple entries each listing a single institution. Andrew Gray (talk) 13:19, 26 February 2013 (UTC)
Should Alma matter be renamed to Alumni of, or do we definitely need the two properties? Danrok (talk) 17:35, 26 February 2013 (UTC)
I didn't even notice we actually had that one! Ooops. (I think I just checked the first two). There's no need for a second property; enwiki is being a little strange here :-). I've added the alternate headings to Property:P69. Andrew Gray (talk) 18:57, 26 February 2013 (UTC)
  Comment I think this can be archived (already exists). Danrok (talk) 14:08, 27 February 2013 (UTC)

Awards / Auszeichnungen / Prix

Status:    Done

→ Property:P166

First suggestion: "Awards won (nominated for) / ... / Prix ( Nominations )"
  • Description: A collection of the awards that person is/was nominated for and has won. Especially for actors and actresses but also for Nobel Prize laureates, Olympic medalists etc. Notable awards
  • Datatype: ItemValue but also with some metadata to track whether they were nominated, won, second round etc.
  • Links: Many Wikipedia articles, IMDB, Nobel Prize website, Olympics website
  • Infobox parameter example: en:Template:Infobox person (awards)
  • Comments: Implementation difficult due to need to track the award date (or make one Item for each year), award status i.e nominated. Further difficulty arises due to the fact that for this data to be displayed properly is would need to generate a table. At least we would only have to do it once for all languages Macadamia1472 (talk) 06:58, 4 February 2013 (UTC)
  Oppose only Awards and prices won are of value.
  Comment would be good, but I don't know how we can implement it, maybe not yet possible. --Stryn (talk) 10:51, 6 February 2013 (UTC)
  Comment While award nominations can be worth recording in some cases, I think it'd be simpler to use a separate property for them. --Avenue(talk) 13:12, 9 February 2013 (UTC)
  Support Used by en:Template:Infobox person (awards). --ThorstenX1 (talk) 06:24, 10 February 2013 (UTC)
  Comment I think we could have two items one which is only nominated (not won) and another one which is actually won. --Sk!d (talk) 00:44, 17 February 2013 (UTC)
  Comment Can we use the same property for awards assigned to particular work (esp. movie)?--Šlomo (talk) 23:00, 17 February 2013 (UTC)
  Support two separate properties (nominated, won). --Faux (talk) 19:17, 18 February 2013 (UTC)
  Comment I've change the title to "awards". --ThorstenX1 (talk) 11:22, 20 February 2013 (UTC)
  Support Supporting for actual awards received. "Nominated for" could potentially be another property. Danrok (talk) 16:48, 25 February 2013 (UTC)

Place of burial

Place of burial
place of burial, e.g. cemetery
Type: item
  Oppose This already exists, as said. Danrok (talk) 20:12, 1 March 2013 (UTC)
But isn't Property:P119 to be used if you're buried in a different location (i.e. city) than the place of death? Whereas this one appears to be for all cemeteries of burial, period? Shawn in Montreal (talk) 20:32, 1 March 2013 (UTC)
  Oppose We can discuss how to use P119, but a dub is useless. --Kolja21 (talk) 00:49, 2 March 2013 (UTC)
This is an important one to clear up, I think, talk page is Property_talk:P119. Danrok (talk) 01:01, 2 March 2013 (UTC)

doctoral student / Doktorand / ...

→ Property:P184 → Property:P185

  • Description: Doctoral student(s) of a professor
  • Datatype: Item
  • Links:
  • Domain: Person
  • Infobox parameter example: en:Template:Infobox scientist
  • Comments: See: pupil
  Support Danrok (talk) 03:04, 26 February 2013 (UTC)
  Support. I think we need doctoral advisor as well - and if we have to choose just one of the two, I would rather have doctoral advisor, as it is probably easier to manage: some people have many students but few have that many advisors, plus it is easier to find in their CVs. --Zolo (talk) 09:57, 2 March 2013 (UTC)
  Done: P:P184 and P:P185. --Zolo (talk) 15:05, 3 March 2013 (UTC)

Organization / Organisation / Organisation

Status:    Done

→ Property:P154

Many logos of the companies are not a free images (images what are in Commons). But otherwise I think this is good to have. --Stryn (talk) 08:32, 19 February 2013 (UTC)
  Support At present it is possible to state the logo by using the image property, but a specific logo property would be better. Anyone using the data can then assume that logo images are protected. Danrok (talk) 03:11, 22 February 2013 (UTC)
Protected? What do you mean? --Nemo 12:56, 22 February 2013 (UTC)
  Comment Many logos (trademarks) are protected by IP laws, and have specific controls on how they can be used. Danrok (talk) 15:04, 24 February 2013 (UTC)
  Comment logos are also used for other things like brands. Danrok (talk) 03:16, 22 February 2013 (UTC)
We will have links to commons for a portrait of a person, so the same solution applies here.--Giftzwerg 88 (talk) 18:56, 24 February 2013 (UTC)

Key Personnel

  • Description: Important staff/related people to an Organisation.
  • Datatype: Item
  • Links:
  • Infobox parameter example:
  • Comments: Reedy (talk) 02:09, 5 February 2013 (UTC)
    • It's too generic, and would bring heated debates about who is key and who isn't. I'd prefer more precise and neutral properties: "was executive", "was designer", "was PR", etc. --NaBUru38 (talk) 21:31, 8 February 2013 (UTC)
      • I agree, but most of these more specific ones will lead to debates also. For example, in enWP, we normally include only the chief executive officer in the infobox or lists within the article, unless it is a famous organization. And not all the roles needed can be predicted in advance. DGG (talk) 16:08, 15 February 2013 (UTC)

Oppose. If the person is notable then their employment details can be added to their own page. If any then only top officers of the company should get a mention here - Chairman and CEO - and these two can have properties. Filceolaire (talk) 22:52, 24 February 2013 (UTC)

college of

  Support Better name: affiliations (like infobox). --Kolja21 (talk) 19:59, 19 February 2013 (UTC)
  Support Danrok (talk) 15:33, 25 February 2013 (UTC)
  Support, agree with Kolja21 that it could get another name to better reflect other educational organizations. --NaBUru38 (talk) 23:13, 25 February 2013 (UTC)
  Done Created as Property:P160 using affiliations label as per infobox label. Danrok (talk) 13:51, 27 February 2013 (UTC)

Headquarters / Siège social

Status:    Done

→ Property:P159

  • Description: Location of an organization's head office
  • Datatype: Item
  • Source: Official website or reliable third party sources
  • Domain: Organizations
  • Infobox parameter: en:template:Infobox organization: headquarters
  • Comments:
  Comment Why domain: Cities? Danrok (talk) 15:52, 24 February 2013 (UTC)
Simply because that's how I see it used at en:template:Infobox organization, and it's the most precise and simple geographical location for a headquarters building, from what I can see...? Shawn in Montreal (talk) 19:10, 24 February 2013 (UTC)
Should it not be domain: Organizations? Valid values could be any admin unit, cities, towns, etc. Danrok (talk) 15:37, 25 February 2013 (UTC)
I'm sorry, it's just my lack of familiarity with WD terms, here. Yes, of course. Changed. Shawn in Montreal (talk) 15:39, 25 February 2013 (UTC)
  Support Danrok (talk) 19:47, 25 February 2013 (UTC)
  Support', the item should be the most precise location available. --NaBUru38 (talk) 23:16, 25 February 2013 (UTC)

Please see: Property_talk:P159#Suggested_improvement Bennylin (talk) 11:47, 28 March 2013 (UTC)

CEO

Status:    Done

→ Property:P169

  Done as Property:P169 CEO as described here: Chief executive officer. Danrok (talk) 23:52, 28 February 2013 (UTC)

National Carrier of

  Comment Does it have to exist in an infobox? Danrok (talk) 15:40, 25 February 2013 (UTC)

Focus Cities

head of / / chef de

  • Description: for an office or position, the entity of which it is the head
  • Datatype: item
  • Links:
  • Domain: offices and political posts (EXPLICITLY NOT individuals)
  • Infobox parameter example:
  • Comments: I'm not sure if this is the right section for this, but I couldn't really think of anything else. This wouldn't be used on individuals (so neverBarack Obama - head of: United States federal government), but rather on posts themselves (so President of the United States - head of: United States federal government). It could also be used for groups, e.g. Wikimedia Foundation Board of Trustees - head of: Wikimedia Foundation.— PinkAmpers&(Je vous invite à me parler) 23:58, 5 February 2013 (UTC)

Event / Ereignis / Évènement

Elections / Wahlen / Élections

Type of election / / Type d'élection

Status:    Done

→ Property:P173

  • Description: Kind of election: presidential, parliamentary, legislative, regional, referendum...
  • Datatype: Item
  • Links:
  • Domain: elections
  • Infobox parameter example:
  • Comments: --Kokoo (talk) 12:18, 26 February 2013 (UTC)

  Support Danrok (talk) 04:21, 27 February 2013 (UTC)

  Done created here Property:P173. Danrok (talk) 10:31, 1 March 2013 (UTC)

Work / Werk / Œuvre

Producer

Status:    Done

→ Property:P162

  Support. --Stryn (talk) 07:46, 25 February 2013 (UTC)
  Support --NaBUru38 (talk) 23:22, 25 February 2013 (UTC)

  Support Seems simple enough. Danrok (talk) 03:47, 27 February 2013 (UTC)

  Support But film producers and album producers are different enough to not have a single producer item, right? Shawn in Montreal (talk) 04:28, 27 February 2013 (UTC)
  Comment I suspect they could share the same property. They're not so different. But there is a fair difference between an executive producer (business side), and a producer (creative side). Danrok (talk) 04:37, 27 February 2013 (UTC)
Yes, for sure, and we may need exec producer for films and such, too. But upon consideration, George Martin, producer of The Beatles, performed a function nothing like a movie producer. So I think I'm probably off base on that. Shawn in Montreal (talk) 04:42, 27 February 2013 (UTC)
  Done Added here Property:P162. Danrok (talk) 15:15, 27 February 2013 (UTC)

Depicted event

Status:    Done

→ Property:P180

Could it also be depicted subject to cover events, persons, places? Danrok (talk) 14:51, 27 February 2013 (UTC)
  Support "depicted subject", too restrictive a field may not be very concenient here. By the way, it is also used by the Cultural Objects Name Authority, that is "™", but I do not think there can be any copyright on such a basic thing. --Zolo (talk) 09:36, 28 February 2013 (UTC)
I think will be good idea to have separate properties for events, persons and places. --EugeneZelenko (talk) 14:42, 28 February 2013 (UTC)
The value of the property should be another Wikidata item, and as such should have a type that should allow client websites to know whether it is a person, event or place. I do not think, it would be very useful to have separate properties on Wikidata. In some cases, it may indeed be a bit more readable, but it would also make it a bit more difficult to use for data contributors. --Zolo (talk) 19:38, 28 February 2013 (UTC)
Why not just "depicts"? "Last Supper" also depicts Jesus, disciples (and, technically, food and a table). --Magnus Manske (talk) 09:40, 1 March 2013 (UTC)
Right, clean and simple, though it is hard to unambiguously translate that into French :)--09:56, 1 March 2013 (UTC)
  Done, as "depicts" (P:P180)

Material used

Status:    Done

→ Property:P186

  • Description: material used like "oil painting" or "marble"
  • Datatype: Item
  • Links:
  • Domain: Creative work
  • Comments: could probably also be used for buildings (wood, concrete...)
  Done, P:P186 --Zolo (talk) 15:05, 3 March 2013 (UTC)

Series / Serie / Série

Status:    Done

→ Property:P179

  • Description: The series of which this piece is a member.
  • Datatype: Item
  • Links:
  • Domain: Creative work
  • Infobox Parameter Example: w:en:Template:Infobox_book
  • Comments: For example, The Lion, the Witch, and the Wardrobe is a part of the The Chronicles of Narnia series. We already have a succeeded by and preceeded by property for creative works, but a series property will make it easier to directly connect more than three works. It also matches the infoboxes used by books and a variety of other creative works on Wikipedia.

--Bravefoot (talk) 19:39, 27 February 2013 (UTC)

  Support Danrok (talk) 22:31, 27 February 2013 (UTC)
  Done, as P:P179, with a rather convoluted description to be as precise as possible. --Zolo

Discovery place

Status:    Done

→ Property:P189

  • Description: place where the item was discovered
  • Datatype: Item
  • Links:
  • Domain: archeological artefacts, possibly also fossiles, gems, and various other things
  • Comments:
  Done --Zolo (talk) 10:37, 5 March 2013 (UTC)

Film / Film / Film

"Preceded by" (P155) and "Followed by" (P156)

→ Property:P155 → Property:P156

Not convinced: better add the number of the serie and the name of the serie. Snipre (talk) 18:31, 7 February 2013 (UTC)
Its not only for numbering series but to make series navigate easily and to make people know of series as in above example.--Nizil Shah (talk) 20:14, 8 February 2013 (UTC)
I like it, it would be much simpler to find prequel and sequel with a direct link. A number in the series might also be good. SilkyShark (talk) 07:52, 8 February 2013 (UTC)
Bear in mind that series order is not always simple - LibraryThing implemented a similar system, and had major disputes over the "right order" for some series ("this is the seventh book, but it's set before all the others"; "yes, but you should read book five first", etc). Andrew Gray (talk) 12:26, 11 February 2013 (UTC)
Numbering also presupposed a Hollywood style "Name of Movie II" titling. I work more on the documentary side at En Wiki and there are series of films in which no so such titling is used. So I would support the preceded by and followed by proposal. Shawn in Montreal (talk) 19:54, 21 February 2013 (UTC)
  Support Per my comment above. Shawn in Montreal (talk) 06:02, 24 February 2013 (UTC)
  Support Needs to be clear exactly what is meant (I'm assuming publication date order). Danrok (talk) 14:47, 24 February 2013 (UTC)
Where there is a dispute as to what follows what then this property can appear twice with suitable Qualifiers. Filceolaire (talk) 23:26, 24 February 2013 (UTC)
Someone added "precedido por" (Property:P155), but the property has not been used yet. --Kolja21 (talk) 01:35, 26 February 2013 (UTC)
There is also Property:P156: "seguido por". I'm not sure if these properties are meant for works or for persons. --Kolja21 (talk) 02:10, 26 February 2013 (UTC)
These properties are for work and not for people, help simplify the search for successors and predecessors of movies, TV series and books Lucasdj98talk 13:51, 26 February 2013 (UTC)

Starring

Status:    Done

→ Property:P161

  Support - Ssolbergj (talk) 03:33, 27 February 2013 (UTC)   Support Yup. A key credit already in film infoboxes. Shawn in Montreal (talk) 04:33, 27 February 2013 (UTC)

  Done It's here Property:P161. Danrok (talk) 14:17, 27 February 2013 (UTC)

Adaptation

  Oppose For an adaption we can use the property "based on" (P144). @Shawn: Why this should be the opposite? --Kolja21 (talk) 00:58, 3 March 2013 (UTC)

Music

Album by -> performer/musical artist (P175)

Status:    Done

→ Property:P175

  Support of course. --Stryn (talk) 15:16, 20 February 2013 (UTC)
  Support Conny (talk) 09:40, 21 February 2013 (UTC).
  Comment How to handle compilations by various artists? Danrok (talk) 03:24, 22 February 2013 (UTC)
Statements allow you to add multiple items, if applicable. The Anonymouse (talk | contribs) 05:30, 22 February 2013 (UTC)
  Support Danrok (talk) 19:34, 24 February 2013 (UTC)

  Done There is consensus to create this property. I have done so at Property:P175 and further discussion on the correct name should take place on the talk page of the property. (I think "performer" is good, or "musical artist/artist (music)") It will not affect how we are using the property--to attach the performing artist (individual or group) to an album or related recording. Espeso (talk) 02:02, 2 March 2013 (UTC)

Term / Sachbegriff / Terme

Tropical cyclone name / Hurrikans / ...

  • Description: Name of tropical cyclone
  • Datatype: Item
  • Links: Q186358, Q186388
  • Domain: Tropical cyclones / hurricanes / typhoons / cyclones
  • Infobox parameter example:
  • Comments: This seems a bit specific  – The preceding unsigned comment was added by [[User:|?]] ([[User talk:|talk]] • contribs).
    • I think what is meant is something along the lines of 'notable storms'. Say the five or so storms with articles. That would make a tremendous amount of sense. We've got a ton of hurricane and typhoon seasons. I would   Support it if that were the case. SvenManguard Wha? 03:53, 7 February 2013 (UTC)
    • I don't see why we need a special property for this - how about a generic name property? The thing is a storm and has a name, but saying it has a storm-name seems kind of pointless to me. -- Duesentrieb (talk) 13:40, 8 February 2013 (UTC)

Manufacturer / Hersteller / ... (P176)

Status:    Done

→ Property:P176

  Done for use with the main manufacturer only, see Property:P176. Danrok (talk) 15:16, 2 March 2013 (UTC)

Developer / Entwickler / ... (P178)

Status:    Done

→ Property:P178

  • Description: the person or organisation which developed this product.
  • Datatype: Item
  • Links:
  • Infobox parameter example: en:template:Infobox web browser
  • Comments:
  Support --Kolja21 (talk) 01:42, 2 March 2013 (UTC)
  Support Danrok (talk) 15:17, 2 March 2013 (UTC)
  Question would this be synonymous with "inventor," then? Shawn in Montreal (talk) 17:34, 2 March 2013 (UTC)
Could be, depends on the use in the infobox. --Kolja21 (talk) 02:15, 3 March 2013 (UTC)
  Done --Kolja21 (talk) 02:15, 3 March 2013 (UTC)

Astronomical objects

Orbit / / orbite autour de

  • Description: it is the opposite of the previous properties (natural satellite and Planets): it indicates that the item orbits the "property item"; e.g. Jupiter orbits the Sun.
  • Datatype: Item
  • Links:
  • Infobox parameter example: en:template:Infobox planet satellite_of
  • Comments:
In my opinion this property can be useful. --Paperoastro (talk) 20:04, 7 February 2013 (UTC)
Support but would be more useful if we could specify the orbit more specifically as well (eccentricity, semimajor axis, ...). So Moon orbits Earth, Earthorbits Sun, etc. ? πr2 (t • c) 16:37, 9 February 2013 (UTC)
Exactly! My idea is to have a property for every orbit parameter (some have been proposed), but also an indication around which the body orbits. It can be useful for natural satellites, but also fosmall>A380r extrasolar planets that have their item. --Paperoastro (talk) 00:33, 10 February 2013 (UTC)
Does Charon orbit Pluto? "Because Charon is so large, it does not actually orbit around Pluto. Rather, the two bodies actually orbit around a common center of gravity somewhere between them."[1]. Also, would we say two stars in a binary system orbit each other or some barycenter? πr2 (t • c) 00:09, 18 February 2013 (UTC)
You are right, my proposal is a simplification too much bigger. Probably is better to have a property satellite of, planet of and companion star (of). --Paperoastro (talk) 19:41, 18 February 2013 (UTC)

  Not done: there is not enough consensus. --Paperoastro (talk) 15:14, 5 March 2013 (UTC)

Period

  • Description The orbital period of a gravitationally bound object, can apply to any regular periodic phenomena.
  • Datatype: Number (units=time)
  • Links:
  • Domain: Any regular periodic phenomena (e.g. orbital period of planet/star in multiple star system/moon/satellite)
  • Infobox parameter example:
  • Comments: MER-C (talk) 13:52, 8 February 2013 (UTC)


Biology / Biologie / Biologie

next higher Taxon

Status:    Done

→ Property:P171

  Done - I went ahead and created it. Property:P171. - Soulkeeper (talk) 09:51, 1 March 2013 (UTC)

Endemic to

Status:    Done

→ Property:P183

Range map

Status:    Done

→ Property:P181

Chemistry / Chemie / Chimie

phase of matter / Aggregatzustand / phase
A better name will be appreciate because we can add hundreds of statements with that property. There is already another proposition about description of chemical at room temperature, see Wikidata:Chemistry task force/Properties Snipre (talk) 09:08, 21 February 2013 (UTC)

Ships

ship builder / Schiffsbauer (Werft) / ...

Status:    Done

→ Property:P198

  • Name (without any prefix, with date of completion)
  • Builder
    • description: Shipyard
    • type: String
  Comment I think builder could be type item. Danrok (talk) 17:21, 1 March 2013 (UTC)
  Done as an item type here Property:P198. Danrok (talk) 02:49, 5 March 2013 (UTC)

Place

Generic

Is in / Ist in / Est a

Status:    Done

→ Property:P131

"Is in": Consensus against this (see: Wikidata:Property proposal/Archive/1). Probably it will work with a more specific title. --Kolja21 (talk) 23:39, 15 February 2013 (UTC)

I provided a newer link which summarized a long discussion.--Ymblanter (talk) 23:48, 15 February 2013 (UTC)
Not that I care much about the title.--Ymblanter (talk) 23:48, 15 February 2013 (UTC)
I propose using the word "located at" instead of "is in"? This will make the property more clearly used in geographical claims only? I mean if we use a generic "is in" it can be used for non-geo claims. For example "Damian Lewis" is in "Homeland" or "Japan" is in "APEC". This is of course for the english language nuiance. I am not sure for the French or German. The same as what Kolja21 said (see: Wikidata:Property proposal/Archive/1#is_in) --Napoleon.tan (talk) -- 02:33 February 16, 2013 (UTC)
I also propose to change the other "Location" property name to "located at coordinate" --Napoleon.tan (talk) -- 02:45 February 16, 2013 (UTC)
Located in administrative unit of?--Ymblanter (talk) 08:05, 16 February 2013 (UTC)
A few other titles were suggested in the Project chat discussion:
  • "administrative division of"
  • "Is in (administrative unit)"
  • "in administrative area"
I hope I haven't missed any. Either of the last two seem okay to me. "located at" seems to imply too precise a location to me, e.g. coordinates or street address, and "is in" alone is too vague. "administrative division of" reads poorly to me, and seems to imply that the property can only be applied to administrative divisions, not to other places like towns, hills, historic sites, etc. --Avenue (talk) 16:05, 16 February 2013 (UTC)
From what I understand in the Project chat (Variant 4) this property would be a single property that will contain the all the item where the place is located. For example, the Liberty_Bell article would have several properties "located at" item United_States, item Pennsylvania, item Philadelphia, the string text "Liberty Bell Center". So the data type must allow both Item and Text. I think placing administrative division in the property name would be restricting (Ymblanter suggestion) --Napoleon.tan (talk)
No, subject and object have to be administrative units. As yet, it has not been decided if multiple levels should be entered or just the next higher one. --Sixsi6ma (talk) 19:00, 17 February 2013 (UTC)
No, they do not both have to be administrative units, unless we choose to restrict the property in that way. One of the types of subject item listed in this proposal is "town", and at least where I live, towns are typically not administrative units. See e.g. w:Taupo, which explains that this town is administered by the w:Taupo District Council, and whose infobox lists the district and region containing the town. (And don't be led astray by the fact that the German Wikipedia article on Taupo covers both the town and the district.) How do you think we should handle the administrative units listed in that infobox, if this property is not allowed to apply to towns that are not themselves administrative units? --Avenue (talk) 20:55, 17 February 2013 (UTC)
I think towns are ok, but for instance "painting A is in museum B" would not be ok and requires further discussion.--Ymblanter (talk) 07:39, 18 February 2013 (UTC)
I think we can limit it to Items where Property:P107 has the value Q618123 if I understand the Property 107 correct. --Sk!d (talk) 12:11, 19 February 2013 (UTC)
Sounds for me like a reasonable restriction. One more thing: If an item (e.g. street) runs through several geographical features, should only one (the biggest) be mentioned or shall we mention all of them (in a reasonable granularity)? I opt for the second one. E.g. if you describe a highway in the U.S., it would be nice to mention all states it runs through, otherwise almost every highway would have the value "Unites States", which is not that useful. If you describe a smaller street (sorry, I don't know the street system in the U.S. that much), the next deeper geographical features (counties?) should be used. --Faux (talk) 17:45, 20 February 2013 (UTC)
  •   Comment While we are discussing the name of the property for which consensus is to create, user add propeties which are not supposed to be there, like Amsterdam now got the property of Property:P12 (province) which should not be there. I guess if we wait for couple more weeks it would be rather difficult to revert.--Ymblanter (talk) 17:32, 19 February 2013 (UTC)
Adding a property is easy, it's the clean up that take time. We have already 10 "Country: subdivisions". "Administrative division" sounds o.k. (if this term includes countries). There are two basic question: What is German and French translation of the property? What answers should be allowed? --Kolja21 (talk) 18:39, 19 February 2013 (UTC)
I have created Property:P131. I have no strong opinion on the name, and I dont mean to shortcut discussion on implementation details, but I just wanted to prevent the spread of discouraged properties like Property:P34. --Zolo (talk) 08:24, 21 February 2013 (UTC)
Thanks. Should we discuss the name on the property talk page? I can move this discussion there.--Ymblanter (talk) 08:25, 21 February 2013 (UTC)
Good idea, this page is really too long. --Zolo (talk) 08:58, 21 February 2013 (UTC)
Moved to the talk page, can be now archived here.--Ymblanter (talk) 10:14, 21 February 2013 (UTC)

Province / Provinz / Province (P12)

  • Description: This a Geographic territorial unit, Like State.
  • Datatype: Item
  • Links: Q34876
  • Domain: Cities, Villages and so on.
We should first complete the discussion--Ymblanter (talk) 21:18, 7 February 2013 (UTC)
deprecated --Kolja21 (talk) 20:40, 22 February 2013 (UTC)

Level 1 subdivision / Rangstufe 1 / division administrative de niveau 1

  • Description: States (US, Mexico, etc.), provinces (Canada), Land (Germany), canton (Suisse), région (France),...
  • Datatype: Item
  • Links:
  • Infobox parameter example:
  • Comments: Rschen7754 04:55, 2 February 2013 (UTC)
Depending on the size of the country, "level 1" subdivisions will have vastly divergent size and political power. More importantly, it is not always clear what a "level" means. For instance, counties of Massachusetts or Regions of England may count as a level, but maybe not, as they have real attributions. And a "district" would be "level 2" in Shanghai, while it would be "level 3" in a Chinese Province, even if its administrative status is exactly the same. Is there any real use in this "level" thing ? I am afraid it will pretty quickly make things rather messy.--Zolo (talk) 07:42, 3 February 2013 (UTC)
What would you propose, then? (This was originally under the roads section, but got moved). --Rschen7754 07:46, 3 February 2013 (UTC)
I do not think we need to rank levels, a "subdivision" property sounds just fine.
California:
  • Administraive status: US State
  • Part of: United Sates
  • Subdivisions: Orange County, Marin County etc. I do not need we need the subdivision of each county here, it should be enough to have it in the specific county page.--Zolo (talk) 08:05, 3 February 2013 (UTC)
+1 with Zolo. His proposal looks good. Tpt (talk) 08:20, 3 February 2013 (UTC)
That may work fine for a state, but what about for a road (which this proposal was originally part of)? --Rschen7754 08:24, 3 February 2013 (UTC)
I think we can use the lowest available level, as that would be the most precise, and would lose no information. Admittedly, it may be easier to understand at first glance if we have info about higher level subdivisions. There will hopefully be ways to make it appear in Wikipedia infoboxes using some kind of simple inferrence, but I think we can live without that on Wikidata (it's just a few clicks away). Beside, in some cases, larger subdivisions may be provided in other properties. For instance "Florida State Road A1A. Maintained by: State of Florida". --Zolo (talk) 08:37, 3 February 2013 (UTC)
There actually won't be - see [2]. --Rschen7754 08:45, 3 February 2013 (UTC)
I do not see a problem. Every locality is always included into the hierarchy of administrative division. For instance, Verkhnyaya Toyma, Russia is in Russia (country), Arkhangelsk Oblast (level 1), Verkhnetoyemsky District (level 2), Verkhnetoyemsky Selsoviet (Level 3). It does not matter that, for instance, Kotlas, Russia, only has one level - it belongs to Russia (country), Arkhangelsk Oblast (level 1), and there are no further subdivisions. To make these levels as one, three or fivce lines, is a technical matter. I believe in English Wikipedia in the settlement templates we have the unlimited number of possible levels.--Ymblanter (talk) 10:48, 3 February 2013 (UTC)
+1 Lydia said it will come. I think there is enough to do in the time between. If we change this later this would only bring us unnecessary work. If we have a clear hierarchy with subdivision and unification of geographical borders e.g. Earth <> Continent <> Country <> .... <> which always link back to each other, we could do many things with it later. E.g. the query "In this country search every city and give me the population" would work, wikidata could search every subdivision until the subdivision is marked as a City or there is no subdivision left and return the population of every city. --Sk!d (talk) 11:04, 3 February 2013 (UTC)
I think this might be far more complicated than you think it is. Are Washington DC, Iraqi Kurdistan, Puerto Rico, Taiwan Province, Hong Kong, Aegean Region, 9th Circuit, England, and Zanzibar "first-level subdivisions"? What about places that have 14 of one type of unit and 20 of a smaller type, without the first type being divided into the smaller types at all? What about places that have serious distinctions between types of things it could be first divided into? Many/most places can't just divide cleanly like this. --Yair rand (talk) 06:06, 4 February 2013 (UTC)
Yes, not every place has such a clean hierarchy. To give an example I know well, New Zealand divides into 16 regions and 67 territorial authorities(TAs), but TAs are not cleanly nested within regions. Seven TAs are split between two or more regions, and one TA lies outside any region. (Then there are several islands for which the Minister is the TA, and several more islands that are outside any TA.) And while those are the main local administrative bodies, some issues are dealt with by other bodies (e.g. District Health Boards) that divide the country differently. Also cities are defined separately for statistical purposes, so their populations cannot usually be derived from those for administrative bodies. I'm sure other countries will have similar or worse complexities. --Avenue(talk) 14:36, 4 February 2013 (UTC)
  • Now we predictably got a problem because we have the property State and the property Province, though they actually mean the same. Should we also create new properties to describe the same thing in different countries, such as Federal Land (Germany), Canton (Switzerland), Oblast, Krai, Republic (Russia), or try to unify this level by merging State and Province and giving them an appropriate description?--Ymblanter (talk) 21:03, 4 February 2013 (UTC)
  • Yes, using different divisions for each country seems clearest. Tier 1 administrative divisions are not the same thing across countries. For example, a region in New Zealand is not really the same as a state or province in a federation like the USA or Canada, as it has much more limited functions and powers. And many countries have exceptions to the main divisions (e.g. Washington DC, American Samoa, New Caledonia, Isle of Man, Norfolk Island), whose status would differ between countries, so we'll need some country-specific governance properties anyway. Perhaps ideas like "level 1 administrative division" would be better stored as statements about each country's general forms of administrative division (e.g. U.S. states), not the specific areas themselves (e.g. California).
By the way, how should we handle defunct administrative divisions? I'm thinking of things like NZ's former provinces. --Avenue (talk) 23:41, 4 February 2013 (UTC)

I propose to delete this property and change it to subdevision and (maybe) unification. e.g. look at Q10557 and Q2749. There are so many redundant information. This is not good for a database. If something change e.g. Some how Germany might not be longer part of Eurasia we would have to change this in every ~100k Items about German cities. I know this is not a realistic example but I hope if shows the problem. If we change this we would also solve the problem with different kind of depth for sub national territories in different Countries. The problem Avenue mentioned above could be solved by adding multiple items as a subdevision/unification. And we could create Country specific properties like Ymblanter mentioned to translate them correct. At the end I would hope we get a clear tree from earth to every little place on Wikidata. --Sk!d (talk) 23:29, 4 February 2013 (UTC)

It could be a better solution. Otherwise we should logically accept types of subdivisions * "locational events" of them (I mean we should have things like "district of birth). What bothers me is that many infoboxes have things like 'birthplace: Milan, Lombardy, Italy', and apparently it will be quite some time before the software can do it by itself if we just have "Milan" in Wikidata. --Zolo (talk) 08:18, 5 February 2013 (UTC)
    • I think that we should decide which levels are 1, which are 2, which are 3, etc, and use this system. I don't mind that California is considerably larger than Treinta y Tres. --NaBUru38 (talk) 21:41, 8 February 2013 (UTC)
    • It seems okay as far as it goes, but quite incomplete compared to our scope. It is for boundaries, not properties, but that probably doesn't matter too much. Historical boundaries don't seem to be covered. I don't see any specialised administrative body boundaries either (e.g. health boards). --Avenue(talk) 04:21, 12 February 2013 (UTC)

Seems like there are three systems under discussion, the explicit system for each country, the level system (1-10) and the subdevision/part of system. I would suggest to have a vote on these systems to find a solution soon. --Faux (talk) 21:00, 19 February 2013 (UTC)

We already had one: Wikidata:Project chat#Administrative divisions again - hopefully, last topic--Ymblanter (talk) 21:41, 19 February 2013 (UTC)
Ah, good. Quite complicated to find all the relevant information on all the separate pages... ;) --Faux (talk) 21:47, 19 February 2013 (UTC)

Level 2 subdivision / Rangstufe 2 / division administrative de niveau 2

  • Description: The counties (most US states), parishes (Louisiana), regions (British Columbia), distric (Suisse), département (France), etc.
  • Datatype: Item
  • Links:
  • Infobox parameter example:
  • Comments: Rschen7754 04:55, 2 February 2013 (UTC)

Level 3 subdivision / Rangstufe 3 / division administrative de niveau 3

  • Description: Same idea as the above.
  • Datatype: Item
  • Links:
  • Infobox parameter example:
  • Comments:

Subdivisions (P150

Status:    Done

→ Property:P150

  • Description: direct subdivision of an administrative division (may also be relevant for other kinds of items)
  • Datatype: Item
  • Links:
  • Infobox parameter example:
  • Comments:
As an alternative to the properties proposed above.
To keep things clean, it should only contain direct subdivisions, not subdivisions of subdivisions. I would also suggest a stricter requirement: set of the subdivisions of an item is a partition of the item. That would provide better consistency, which may be useful for bots and other tools. That would also mean that incorporated cities of Orange County should not be considered subdivisions of Orange County, as it would leave out the unincorporated territory that is not part of any subdivision. --Zolo (talk) 11:49, 3 February 2013 (UTC)
Okay, that sounds good. --Rschen7754 21:10, 3 February 2013 (UTC)

official seal image

Status:    Done

→ Property:P158

  • Description: Official seal
  • Datatype: Commons media file
  • links: Q162919
  • Domain: Countries, states, cities, possibly organizations.
  Support as proposer. We already have one for the coat of arms, so should have one for the seals (note that some jurisdictions have both a coat of arms and a quite different seal, so they shouldn't be merged). – Philosopher Let us reason together.20:29, 10 February 2013 (UTC)
  Support Danrok (talk) 00:38, 25 February 2013 (UTC)
  Support but omit "official". - Ssolbergj (talk) 03:07, 26 February 2013 (UTC)

Flag description / Fahnebeschreibung / Description du drapeau

Status:    Done

→ Property:P163

  Comment Can you be more specific on how and where this would be used? Danrok (talk) 00:44, 25 February 2013 (UTC)
See w:en:Template:Infobox country and its usage. Links to flag articles are created implicitly there. --EugeneZelenko (talk) 02:01, 25 February 2013 (UTC)
  Support JAn Dudík (talk) 08:06, 25 February 2013 (UTC)

  Done Property:P163. en.wikipedia has almost 1000 articles that begin with "Flag of". Espeso (talk) 16:31, 27 February 2013 (UTC)

City / Stadt / Ville

Twin cities

Status:    Done

→ Property:P190

  Support Applies to cities, towns, and other divisions. Danrok (talk) 01:29, 28 February 2013 (UTC)
  Support Espeso (talk) 18:54, 1 March 2013 (UTC)
  Support Del♉sion23 (talk) 00:13, 2 March 2013 (UTC)

  Done Property:P190 -- --  Docu  at 19:20, 3 March 2013 (UTC)

Buildings and structures / Gebäude/ bâtiments

Type / Gebäudeart / Type

Status:    Done

→ Property:P168

  Support --Чаховіч Уладзіслаў (talk) 15:49, 10 February 2013 (UTC)
  Support A list of types which could be used here: List of building types Danrok (talk) 18:01, 24 February 2013 (UTC)
  Done, given consensus: Property:P168, please help with the description. --Zolo (talk) 20:00, 28 February 2013 (UTC)

Replaced by

Status:    Done

→ Property:P167

  • Description: Buildings are demolished and replaced by new buildings (or other entities, e.g. a park).
  • Datatype: Item
  • Links:
  • Infobox parameter example:
  • Comments: Use to specify the structure(s) which replaced this one. Example: Southwark Towers, in London, was replaced by The Shard. Danrok (talk) 20:09, 24 February 2013 (UTC)

  Done no objections, so added here Property:P167. Danrok (talk) 16:35, 28 February 2013 (UTC)

Owner

Status:    Done

→ Property:P165

Yes, of course many things have owners. A "parent organisation" is the owner its subsidiaries . I'd suggest getting owner in place, and in use for one or two types of things to begin with, then open it up to other types. Danrok (talk) 22:02, 26 February 2013 (UTC)
  Support for use here and elsewhere... Shawn in Montreal (talk) 22:09, 26 February 2013 (UTC)
  Done It's here Property:P165, and can be used for organisations, and pretty much anything which has a legal owner. Danrok (talk) 02:24, 28 February 2013 (UTC)

Crosses

Status:    Done

→ Property:P177

  Done as Property:P177. Danrok (talk) 17:57, 2 March 2013 (UTC)

Main contractor

Status:    Done

→ Property:P193

  • Description: The main building contractor for this building or structure.
  • Datatype: Item
  • Links: See The Shard
  • Infobox parameter example: Infobox building | main_contractor=
  • Comments: Seems simple enough. Danrok (talk) 17:11, 28 February 2013 (UTC)

  Support standard item in building infoboxes. Shawn in Montreal (talk) 19:47, 28 February 2013 (UTC)

  Done as Property:P193. Danrok (talk) 15:30, 4 March 2013 (UTC)

Lakes

From w:Template:Infobox_lake#Parameters. --Docu (talk) 11:57, 1 March 2013 (UTC)

inflow
major inflow sources — rivers, aquifers, glacial runoff, etc.
Some terms may not be place names, e.g. none
  Support Danrok (talk) 22:47, 3 March 2013 (UTC)
  Done Property:P200. -- --  Docu  at 01:24, 6 March 2013 (UTC)
outflow
outflow waterway names.
If evaporation or seepage are notable outflows, they may be included.
Some terms may not be place names, e.g. evaporation
  Support outflows, such as river items. Danrok (talk) 22:47, 3 March 2013 (UTC)
  Done Property:P201. -- --  Docu  at 01:24, 6 March 2013 (UTC)
lake type
type of lake. If it's a reservoir, add "reservoir".
For typologies, see w:Wikipedia_talk:WikiProject_Lakes#Lake_types and w:Lake#Types_of_lakes
Samples values with wikimarkup (only one or a few may apply): periglacial, subglacial, artificial reservoir, endorheic, meromictic, oxbow, rift lake, underground, w:crater lake, intermittent, former lake, shrunken lake; w:oligotrophic, w:mesotropic, eutrophic, w:hypertrophic</nowiki>
  Done Property:P202. -- --  Docu  at 01:24, 6 March 2013 (UTC)
basin_countries
which countries have drainage to/from or border the lake. To conform a standard, this should include all countries that are directly involved with the lake's ecology; this would include inflows, outflows, or physically contact the lake.
Countries are listed in unwikified form, without flags. For Antarctica, use "(Antarctica)".
  Done Property:P205. -- --  Docu  at 01:24, 6 March 2013 (UTC)
located on lake
(for places) lakes the city/village, etc. is located on.
  Done Property:P206. -- --  Docu  at 01:24, 6 March 2013 (UTC)
image_bathymetry
bathymetry_image.png (or other image, avoid maps showing only the location of the lake)
  Done Property:P207. -- --  Docu  at 01:24, 6 March 2013 (UTC)

Train Station / /

previous station adjacent station

Status:    Done

→ Property:P197

how do we handle instance where a train station is part of several lines? There would be several next station and previous station?User:Napoleon.tan
how do we decide which direction would be next and which one would be previous? The northern one? The southern one?User:Napoleon.tan
In Italy the convention is from North to South and from West to East. I don't know if in other countries there are similar conventions.--Incola(talk) 20:15, 11 February 2013 (UTC)
In Korea, There has train Kilometer mark. So We can use km mark in each line or north/west is prevous station.--DangSunM (T · C) 03:02, 13 February 2013 (UTC)
Also in Italy there is a km mark (it follows the North/West convention). We could identify the previous station using the km mark, since it's a very general propriety. --Incola (talk) 08:50, 13 February 2013 (UTC)
Whereas the notion of previous and subsequent stations can be indeed confusing it is solved on English Wikipedia (and I guess on other projects as well) just by choosing a particular direction for every railway line and following it consistently. Indeed, for lines originating from the centers of large agglomerations the natural choice of this direction is from the center, but it does not have to be.--Ymblanter (talk) 08:58, 13 February 2013 (UTC)
Easy solutions: 1) don't use "next station", use "adjacent station" and list all the adjacent stations. 2) use qualifiers to specify direction (towards [end station on one direction] and which line it's one. So we'd get
- "Park Street <adjacent station> Chinatown" with a qualifier "orange line, toward Forest Hills"
- "Park Street <adjacent station> State" with a qualifier "orange line, toward Oak Grove"
- "Park Street <adjacent station> Boylston" with a qualifier "green line (E branch), toward Heath Street"
...etc. Sven Manguard Wha? 06:26, 18 February 2013 (UTC)
  Support Sven Manguard's suggestion. --ColinFine (talk) 09:41, 22 February 2013 (UTC)
  Support --Sakoppi (talk) 06:26, 24 February 2013 (UTC)
  Support as per "adjacent stations". Danrok (talk) 15:23, 26 February 2013 (UTC)
  Support --NaBUru38 (talk) 20:35, 1 March 2013 (UTC)
  Done here as Property:P197. Danrok (talk) 00:08, 5 March 2013 (UTC)

Government, governance, and administration

head of regional government

  • Description: head of government of an administrative division, e.g. an American governor
  • Datatype: item
  • Links:
  • Domain: states, provinces and territories of federalized countries
  • Infobox parameter example:
  • Comments: In the spirit of "head of state" and "head of municipal government". In theory we could use this for everything in between.— PinkAmpers&(Je vous invite à me parler) 22:45, 5 February 2013 (UTC)
  • With the possible exception of a few borderline circumstances (e.g. the mayors of the counties of Hawaii), no. I believe that mayors would generally fall under the purview of Property:P6, head of municipal government. The problem we're running into here and in several other cases is that "country" and "municipality" are two relatively well-defined terms, while basically anything in between is not. I think a catch-all property like this could handle the vast majority of subdivisions, though it's possible there will be a few complexities requiring some additional properties. But for the time being, I think this should sort things out fairly nicely. — PinkAmpers&(Je vous invite à me parler) 12:06, 7 February 2013 (UTC)
  •   Comment: I said support because the decision that P46 was "head of national government" seemed to be a fait accompli. If we can have a single "head of government" property for all levels, that would be even better, to my mind. - Htonl (talk) 20:38, 4 March 2013 (UTC)
  •   Comment There shouldn't be a gap, imo. I'm still not convinced that the executive branches of different levels of government need different properties. We've spent a great deal of time creating single properties that can be applied to a diverse cross-section of areas, so are we making an exception for heads of governments? Shawn in Montreal (talk) 15:01, 4 March 2013 (UTC)
  •   Oppose Also, I see that we now have one single property (Property:P194) for all legislative bodies, as suggested directly below. How can we have one such property for all legislative bodies but three for executive branch leaders? A city council is no more or less different from a national legislature than a mayor is from a national government leader, surely. Shawn in Montreal (talk) 17:34, 4 March 2013 (UTC)
  •   Oppose per Shawn in Montreal, and my general principle that storing information about an item in the property name is not often useful. "Head of government" is scoped automatically by the item it is attached to. Espeso (talk) 19:20, 4 March 2013 (UTC)

representative body legislative body (P194)

Status:    Done

→ Property:P194

I created Property:P194. SPQRobin (talk) 17:32, 4 March 2013 (UTC)
What infoboxes uses this property? What should it be called in German and French? Why it's created and used already but not listed in Wikidata:List of properties? --Kolja21 (talk) 19:48, 4 March 2013 (UTC)
Eh, "legislature" in e.g. w:en:Template:Infobox country (obviously), and there's a w:en:Template:Infobox legislature for the body itself. And I wasn't too sure what the name should be, so I was even less sure about the German and French name; it's been added meanwhile on Property:P194 (and don't expect anyone to know the right words in German and French). About Wikidata:List of properties, I am not sure where I should add it (and I have only started using it just now). SPQRobin (talk) 20:08, 4 March 2013 (UTC)
Well I couldn't find "representative" in w:en:Template:Infobox country (they use "legislative") and I had no idea where to put this property. With the new name it fits. --Kolja21 (talk) 04:43, 5 March 2013 (UTC)
  Support Danrok (talk) 23:53, 4 March 2013 (UTC)
  Support Nice open-ended property that works across all levels of government -- including those that aren't necessarily representative democracies, I'd imagine. Shawn in Montreal (talk) 21:02, 5 March 2013 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/Archive/2&oldid=1921565264"