Wikidata:Property proposal/Archive/11

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Station type / Bahnanlagetyp / / Тип станции / Тип станції

   Not done

Description	type of railway stations: station, stop punct, crossing loop, block post etc.
Data type	Item
Template parameter	type
Domain	place
Allowed values	railway station (Q55488), passing loop (Q784159), overtaking station (Q4329090), railway junction (Q336764), block post (Q350114), railway stop (Q55678)
Example	Vyshneve (Q12089725) => railway station (Q55488), Rasava (Q12146989) => passing loop (Q784159), Tarasivka (Q12160031) => railway stop (Q55678), Potiivka (Q12142918) => railway junction (Q336764), Varshytsia (Q12087823) => block post (Q350114)
Source	station references
Proposed by	Ahonc (talk)

I write articles about railway stations in post-USSR countries. I can't say about whole world, but in post-USSR countries used such station types: railway station (Q55488), passing loop (Q784159), overtaking station (Q4329090), railway junction (Q336764), block post (Q350114), railway stop (Q55678). Maybe in other countries may be additional types.Ahonc (talk) 21:29, 16 May 2013 (UTC)

•  Support it's important property for post-USSR railways. --Base (talk) 13:07, 28 June 2013 (UTC)

 Weak opposeI have thought a bit. Why dont use instance of (P31) instead? --Base (talk) 17:55, 2 July 2013 (UTC)

 Not done --Nightwish62 (talk) 16:41, 29 July 2013 (UTC)

University details

   Not done

Description	For universities: number of students (undergrad/postgrad), staff, motto, president, etc.
Data type	String
Template parameter	en:Template:Infobox university
Domain	universities
Example	University of Illinois at Urbana–Champaign: students 42,606; Undergraduates 31,932; Postgraduates: 10,674; Motto: Learning and Labor; Established: 1867; Academic staff: 2,971; Admin. staff: 8,085
Source	en:Template:Infobox university

Discussion

We need lots of properties about universities, including string values for # of students (undergrad, postgrad), #of academic staff, # of admin staff, motto, website, mascot, president, date of founding, etc. Phoebe (talk) 18:50, 4 April 2013 (UTC)

Yeah, we need most (if not all) of these properties. Courcelles (talk) 20:03, 5 April 2013 (UTC)

Should I propose them individually for consensus or can we agree on a list? -- Phoebe (talk) 02:36, 6 April 2013 (UTC)

"Text" is not a datatype. I propose that we hold off on this until the "QuantityValue" datatype is available. FrigidNinja 00:30, 8 April 2013 (UTC)

Individually, or a small, clear list. Besides the type issue, some may already exist under a different name. Superm401 - Talk 17:34, 8 April 2013 (UTC)

Individually, like "students" (= total student count). --Kolja21 (talk) 19:37, 16 April 2013 (UTC)

A table is better Snipre (talk) 18:08, 18 April 2013 (UTC)

• Several of the proposed properties seem like they could be fulfilled by general-purpose properties. "Motto", "president", "staff" (presumably meaning "number of employees"), etc. all seem applicable well beyond the domain of universities. I think we should strive to use properties as generally as possible, to avoid the need for users to look up minutely different properties for each different subject or topic area. Emw (talk) 04:16, 25 April 2013 (UTC)

 Strong oppose we have to parcel information. --Tobias1984 (talk) 08:38, 27 July 2013 (UTC)

 Not done The proposal is against the concept of every database model, see w:Database_normalization --Nightwish62 (talk) 17:08, 29 July 2013 (UTC)

voice actor or voice dubber / Synchronsprecher / ...

   Done: voice actor (P725) (Talk and documentation)

Description	The person who dubbed a role in the TV. e.g. Japanese dubber US TV/Film, English dubber for Anime, etc
Data type	Item
Template parameter	Not in the info box but can be useful data
Domain	Movies
Example	see below
Proposed by	Napoleon.tan (talk)

Discussion

Item: Heroes

   Statement Starring: Ali Larter
       Qualifier Role: Niki Sanders
       Qualifier Role: Tracey Strauss
       Qualifier Voice Actor: Tamura Maki
           Sub Qualifier Language: Japanese Language -- not possible right now

Or

   Statement Starring: Ali Larter
       Qualifier Role: Niki Sanders
       Qualifier Role: Tracey Strauss
   Statement Voice Actor: Tamura Maki
       Qualifier Language: Japanese Language
       Qualifier Role: Niki Sanders
       Qualifier Role: Tracey Strauss

--Napoleon.tan (talk) 19:35, 29 April 2013 (UTC)

•  Support I'm not sure about dubbing to other languages (require qualifier on qualifier), but there are enough cases for original language when voice of other person was used, for example when playing actor/actress has strong accent. --EugeneZelenko (talk) 03:16, 30 April 2013 (UTC)

 Done --Nightwish62 (talk) 18:12, 29 July 2013 (UTC)

candidate

   Done: candidate (P726) (Talk and documentation)

Description	person or party listed as an option for office in an election
Data type	Item
Domain	individual elections
Example	w:en:United States Senate election in Arizona, 2012 candidate w:en:Jeff Flake, w:en:French legislative election, 2012 candidate w:en:Union for a Popular Movement
Robot and gadget jobs	allowed
Proposed by	Joshbaumgartner (talk) 05:10, 13 May 2013 (UTC)

 Info This property is for use with elections to indicate the competing parties (political parties or individuals). In cases where where votes are for lists of candidates and where seats are apportioned, the item should be the party or list instead of individual candidates. Joshbaumgartner (talk) 05:10, 13 May 2013 (UTC)

 Support --Nightwish62 (talk) 17:31, 6 July 2013 (UTC)

 Done --Nightwish62 (talk) 18:56, 29 July 2013 (UTC)

event (en) / specialità (it)

   Not done

Description	the event practiced from an athlete (for example "long jump" or "100 meters hurdles"
Data type	Item
Template parameter	"event" in en:template:Infobox athlete; "specialità" in it:template:Sportivo
Domain	person
Example	Q5444 => Q624482 OR Q164761 and Q211155
Proposed by	Yiyi .... (talk!) 10:07, 12 June 2013 (UTC)

Discussion

'event' is ambiguos as it also refers to competitions (though specialità seems fine). Rename to 'sport' or similar. Filceolaire (talk) 16:49, 12 June 2013 (UTC)

• This is similar to Wikidata:Property_proposal/Generic#Sport.--Kompakt (talk) 06:29, 13 June 2013 (UTC)

sport (P641) has been created in the meantime, so I think this can be archived.--Kompakt (talk) 10:10, 16 July 2013 (UTC)

 Not done --Tobias1984 (talk) 08:58, 30 July 2013 (UTC)

VAT identification number

   Not done

Description	A value added tax identification number or VAT identification number (VATIN) is an identifier used in many countries, including the countries of the European Union, for value added tax purposes.
Data type	String
Example 1	MISSING
Example 2	MISSING
Example 3	MISSING
Source	See [1].
Proposed by	Janjko (talk) 17:10, 14 March 2013 (UTC)

•  Comment - These are often used as unique identifications of businesses. Janjko (talk) 17:10, 14 March 2013 (UTC)
  •  Oppose, not relevant. --NaBUru38 (talk) 19:38, 27 March 2013 (UTC)

If there is one international number OK, else no because we will have country dependent parameters which can change very easily and this will be a problem for compagnies with different entities. Snipre (talk) 09:34, 2 April 2013 (UTC)

 Comment If the goal is to have a identifier for corporate entities, the Financial Stability Board has prepared the Global Legal Entity Identifier ( http://www.leiroc.org/ ) based on ISO 17442:2012 standard. This standard is being implemented during 2013 all around the world, it could be a good idea to wait for it. Pegua (talk) 15:22, 17 April 2013 (UTC)

 Comment if this is proposed as a standardized identification number issued by a recognized authority, it should be listed under authority control. Joshbaumgartner (talk) 10:28, 9 May 2013 (UTC)

 Not done --Tobias1984 (talk) 09:09, 30 July 2013 (UTC)

Europeana identifier

   Done: no label (P727) (Talk and documentation)

Description	Europeana.eu is an internet portal that acts as an interface to millions of books, paintings, films, museum objects and archival records that have been digitised throughout Europe. This id will be used to link with online resource available through that site. There is a test console for this kind of IDs.
Data type	String
Domain	published works
Example	Girl with a Pearl Earring (Q185372) <Europeana identifier> 92034/6BD59765E7734AA666431F3021063CA1E3A1D026
Proposed by	--Micru (talk) 00:47, 25 June 2013 (UTC)

Discussion

•  Support One of the biggest gouvernamental digital repositories of creative works.--Micru (talk) 00:46, 25 June 2013 (UTC)
•  Support --Чаховіч Уладзіслаў (talk) 12:39, 27 June 2013 (UTC)

Aubrey (talk) 09:08, 29 June 2013 (UTC)

•  Support Aubrey (talk) 09:08, 29 June 2013 (UTC)

 Done --Tobias1984 (talk) 10:22, 30 July 2013 (UTC)

Music genre / Gattung (Musik)

   Not done

Description	Music genre for artist, musical group, album, single
Data type	Item
Template parameter	Used e.g. in w:Template:Infobox musical artist
Example 1	MISSING
Example 2	MISSING
Example 3	MISSING
Proposed by	Stryn (talk) 09:37, 21 February 2013 (UTC)

Discussion

• Original title: Genre (P136)

 Support Work together with musicbrainz? Conny (talk) 09:39, 21 February 2013 (UTC).

 Support Danrok (talk) 20:14, 21 February 2013 (UTC)

 Comment my support is for music recordings' genres. It may not be needed for artists (persons) or groups. Danrok (talk) 03:25, 24 February 2013 (UTC)

There is already Property:P136 JAn Dudík (talk) 14:03, 22 February 2013 (UTC)

I don´t think so. In my view this property shouldn´t be used for persons, but for books or music. --Goldzahn (talk) 14:23, 22 February 2013 (UTC)

Why ? If you can give a genre for a album or single, why can't you do the same for persons ? Snipre (talk) 15:04, 22 February 2013 (UTC)

OK, both is possible. But if we would use P136 (literary genre = en:List of literary genres) for music too, the describtion of the property has to be changed. As you can see at en:Category:Genres by medium, there are "Television genres", "Film genres", "Video game genres" even "wrestling genres". Therefore, we could have a property "genre" for all of that or we create a property "music genre". --Goldzahn (talk) 06:19, 23 February 2013 (UTC)

( Support) If you are talking about the "genre" of a "person" literally, of course that makes no sense. But we are referring to the genre of a musician or musical group (jazz, alt rock...). The genre property of infoboxes for musical acts is notorious for having too many values and being unsourced, and drive-by editors like to add new ones all the time. It's a property that needs a stronger sourcing component. Espeso (talk) 20:05, 22 February 2013 (UTC)

I didn't realize this property had been created when I commented, as noted by JAn Dudík above. The discussion on scope should probably be moved to Property talk:P136, where it has already started. Espeso (talk) 07:10, 24 February 2013 (UTC)

 Oppose - Not Yet I think that this is something that should be handled outside of Wikidata until we've gotten sourcing down. Genre is constantly warred over by random IPs in English Wikipedia, and unless we can develop a very clear policy that involves sourcing (which would be premature until the sourcing suite is complete) I think that this is a mess we don't want on this project. Yet. Sven Manguard Wha? 17:11, 24 February 2013 (UTC)

Property 136 is changed to "genre". I think, therefore, this proposal is done. --Goldzahn (talk) 17:26, 24 February 2013 (UTC)

•  Support, rename to "artistic genre" --NaBUru38 (talk) 23:20, 25 February 2013 (UTC)
  • Ok, I'll accept that music gets a separate genre property, since it doesn't match genres in any other art forms. --NaBUru38 (talk) 19:42, 27 March 2013 (UTC)

 Support Since the "genre" here (for example: en:Hip hop music) is not the same kind of "genre" as in literature (for example "novel"). --Kolja21 (talk) 01:05, 2 March 2013 (UTC)

 Oppose change from broad "genre". The scope of the genre is defined by the type of item the property is attached to; thus "music genre" vs "literary genre" only subdivides properties for no benefit. There are at least n types of creative works that could be subdivided into "foo genre", and I don't see the point of doing so. Principle: don't store information about the item in the property name unless clearly necessary. Espeso (talk) 01:54, 2 March 2013 (UTC)

• "Novel" isn't a genre, it's a format just like short story, feature film and short film. Genres are action, romance, drama, comedy (for fiction), rock, folk, pop, electronic (music). --NaBUru38 (talk) 18:40, 8 March 2013 (UTC)

 Support for an own property "music genre" to be abble to distinguish is from other genre types. I don't like the idea of a generic genre property which contains a bunch of all sort of media. Consider this: If we start with separated genre properties we are still able to merge all to one overall property without problem. On the other side, splitting an generic genre property would take much of work. About the question if we should use this new music genre also for person/bands: no, for the same reasons as descripted above. So I even suggest to rename the property to 'album muic genre'. Naming it that clearly, noone would ever consider to use this property for a non-album item. --Nightwish62 (talk) 21:05, 23 March 2013 (UTC)

If we split all properties up, we would get thousands of properties. It would it make much work and many problems with items. I think we shouldn't do this, even if I would also sometimes like to split it up. But the rest of needed information could be get by other properties. --#Reaper (talk) 21:25, 30 April 2013 (UTC)

 Oppose I'm not convinced of the need for something more specific than Property:P136. It can be inferred from what the item is an instance of. If it's used on a book, it's a genre of a book. If it's used on a musical group, it's (one of) their genre(s). Superm401 - Talk 23:28, 7 April 2013 (UTC)

That's a very good idea! --NaBUru38 (talk) 18:49, 18 April 2013 (UTC)

 Support --Napoleon.tan (talk) 12:34, 30 April 2013 (UTC)

 Oppose as its the same as P:P136. --#Reaper (talk) 21:25, 30 April 2013 (UTC)

 Not done --Tobias1984 (talk) 10:31, 30 July 2013 (UTC)

premiere (date)

   Not done

Description	date of the premiere (of an opera, musical, film...)
Data type	Point in time
Domain	opera, musical, film...
Example 1	MISSING
Example 2	MISSING
Example 3	MISSING
Proposed by	Appo92 (talk) 15:16, 7 February 2013 (UTC)

Discussion

•  Support --Viscontino ^talk 10:19, 26 March 2013 (UTC)
•  Comment See my comments above regarding multiple types of premieres, which would require multiple dates, as well. Shawn in Montreal (talk) 15:48, 5 April 2013 (UTC)
•  Comment should have qualifiers for which country is the premiere and where was the premiere was created. --Napoleon.tan (talk) 12:37, 30 April 2013 (UTC)
•  Oppose the generic date property used as a qualifier to the premiere property will do this. We don't need a separate property. Filceolaire (talk) 17:35, 15 May 2013 (UTC)
•  Oppose See Wikidata:Property_proposal/Generic#Key_event. Danrok (talk) 13:05, 24 May 2013 (UTC)

 Not done --Tobias1984 (talk) 10:33, 30 July 2013 (UTC)

provenance event

   Not done

Description	provenance event
Data type	String
Domain	creative work
Allowed values	name-date-location
Example	http://commons.wikimedia.org/wiki/File:Frans_Hals_037.jpg
Source	http://commons.wikimedia.org/wiki/Category:Secretan_sale_1_July_1889
Robot and gadget jobs	Could be imported from Wikimedia commons ARTWORK template
Proposed by	Jane023 (talk) 12:40, 26 May 2013 (UTC)

 Comment I think that the simplest way to get the full ownership history is to use owned by (P127) with qualifiers. Something like like "owner: X; date: 1889; cause: Secretan sale". --Zolo (talk) 14:29, 26 May 2013 (UTC)

Good idea. I was thinking more of the various types of provenance events such as restorations, exhibitions (where a painting moves from city to city), as well as auctions, where people get to view them. Ownership is also very interesting and would be good to track separately. I suppose a separate proposal should be made for this. Actually, I was looking around and couldn't find the property proposals for other Commons artwork template fields, so I put this here, but things like "oil on canvas" vs "watercolour" or "oil on panel" should also be made for "medium". Jane023 (talk) 06:52, 27 May 2013 (UTC)

See Wikidata:Artworks task force :)

I think it would make sense to have a separate "exhibition" property (many museum databases have this). I am not so sure how to handle restorations and the like, but I guess it should be a general property that could be used for buildings and possibly other things. -Zolo (talk) 07:49, 27 May 2013 (UTC)

 Not done --Tobias1984 (talk) 10:44, 30 July 2013 (UTC)

GHS hazard statements

   Done: no label (P728) (Talk and documentation)

Description	GHS hazard statements + GHS EU hazard statements
Data type	String
Template parameter	fr:infobox chimie, en:chembox, de:Infobox Chemikalie
Domain	chemistry
Example	sodium azide (Q407577) = H300, H410, EUH032
Source	EU database
Proposed by	Snipre (talk) 22:10, 9 July 2013 (UTC)

Discussion:

•  Support --Tobias1984 (talk) 08:45, 19 July 2013 (UTC)
•  Support but H phrases and EUH phrases individually. They should not get merged. --Leyo 21:30, 28 July 2013 (UTC)

• Why ? We can easily do the difference using the values of the property based on a regexp extraction. H and EUH are quite easy to differentiate. Snipre (talk) 11:38, 29 July 2013 (UTC)

 Done --Tobias1984 (talk) 10:49, 30 July 2013 (UTC)

Road length under construction / Straßenlänge im Bau / longueur de la route en construction

• Description: length of the part road which is under construction / Länge des im Bau befindlichen Teils der Straße
• Datatype: number value
• Links:
• Infobox parameter example: w:de:Vorlage:Infobox hochrangige Straße (Baulänge)
• Comments: unit in kilometer per default --Daniel749 talk 09:21, 23 February 2013 (UTC)

 Oppose this is changing quite fast and won't be updated. Snipre (talk) 18:28, 18 April 2013 (UTC)

 Not done --Tobias1984 (talk) 13:20, 30 July 2013 (UTC)

Navigable / Schiffbarkeit / Navigation

• Description: which stretches of the river are navigable
• Datatype: string
• Allowed values: alphanumerical - length or a town?
• Use case: Parameter SCHIFFBAR in DE infobox

--Matthiasb (talk) 14:04, 7 March 2013 (UTC)

That should not be a string. I think it should be a boolean (true or false) and that if there are only parts that are navigale, it should be added through a qualifier (of either item or coordinate type). --Zolo (talk) 19:58, 22 April 2013 (UTC)

 Comment This should also take into account tides, seasonal ice and probably the size of the ship that can navigate it. --Tobias1984 (talk) 12:25, 26 April 2013 (UTC)

 Not done --Tobias1984 (talk) 13:23, 30 July 2013 (UTC)

Rolling Stock

• Description: The type of train series or model that are being used
• Datatype: Item
• Links:
• Infobox parameter:
• Value example: [[London Underground 1992 Stock|1992 Tube Stock]] 8 carriages per trainset
• Comments:

 Oppose almost always the parameter is assigned one item, and one free text string, as in the above example. It should be divided into two properties, one of type item, one numerical. Mange01 (talk) 21:29, 13 March 2013 (UTC)

 Comment this proposal is unclear. The example appears to be incomplete. Danrok (talk) 16:50, 2 July 2013 (UTC)

 Not done --Tobias1984 (talk) 13:24, 30 July 2013 (UTC)

Location / Lage /

• Description: the country(-ies) the river flows through.
• Datatype: Item
• Links: <Volga> country <Russia>
• Infobox parameter example: e.g. en:template:Infobox River location
• Domain: all countries / possibly all administrative units
• Comments: Property:P17 is already used de-facto, the question is whether we want continue using it or to create a dedicated property--Ymblanter (talk) 20:26, 21 March 2013 (UTC)

 Not done --Tobias1984 (talk) 13:26, 30 July 2013 (UTC)

Lakes / Seen / lacs

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

catchment_area

the area of catchment (in square kilometres) which includes the entire area of the w:drainage basin for that lake. This may include rivers and other lakes.

• Should this be a number or should it be a link to the catchment area item which will have the area? Nikola (talk) 04:30, 8 March 2013 (UTC)
• The area I think, the link should be in a property "drainage basin", and the same area should be available there. — Jeblad 15:51, 9 March 2013 (UTC)
• Currently it's just a number in the infobox. There isn't necessarily an item about the drainage basin, but the surface of the area is generally known. --  Docu  at 17:53, 9 March 2013 (UTC)

length

maximum length of the lake in km; the length of the lake at its longest dimension.

width

maximum width of the lake in km; perpendicular to the angle used to calculate length.

average_depth

Average depth of the lake in metres.

maximum_depth

Maximum depth of the lake in metres.

volume

total volume of the lake (cubic metres or cubic kilometres)
Sample value: 11.8 km³

residence_time

residence time of the lake water or lake retention time (generally in years). This is the mean time water spends in the lake.

shore_length

length of the shoreline in kilometres; this should not include values for waterways directly connected to the lake, and should reflect the shore at average surface area.

• This value is difficult as it imply some measure of granularity along the shore line. — Jeblad 15:49, 9 March 2013 (UTC)
• Agree. People still seem to like this property in infoboxes. --  Docu  at 17:53, 9 March 2013 (UTC)

islands_count

total number of islands in the lake

• Lua should be able to provide a count given a property, bu perhaps it would be impossible to list all islands in some cases. — Jeblad 15:46, 9 March 2013 (UTC)
  • What is "lua". --  Docu  at 17:53, 9 March 2013 (UTC)
    • See w:en:WP:LUA --Z 09:27, 18 March 2013 (UTC)
      • They don't necessarily all have items or names. en:Template:Infobox lake generally lists some (or links a list) and provides a number. --  Docu  at 08:55, 27 April 2013 (UTC)

island_names

names of islands in the lake

• These two should probably be grouped into one property "islands", "contains islands" and both data can be derived from there. Also, islands could use property "is in" or "is in lake". Nikola (talk) 04:30, 8 March 2013 (UTC)
• No grouping, use the properties be used to build the list. — Jeblad 15:46, 9 March 2013 (UTC)

cities

notable cities or settlements on or near the lakeshore.

caption_bathymetry

Text about the bathymetry (or other) image

also needed:

Shore length / Uferlänge / --Matthiasb (talk) 13:47, 7 March 2013 (UTC)

Shore length is already there. Nikola (talk) 04:30, 8 March 2013 (UTC)

 Not done --Tobias1984 (talk) 13:29, 30 July 2013 (UTC)

Basin countries

We have already Property:P205 for the lakes: All countries which contain the basin of the lake. I propose to extend it for rivers.--Ymblanter (talk) 20:28, 21 March 2013 (UTC)

 Comment I believe this should be handled on the talk page for P205, as it is not a proposal for a new property (at least not yet). Joshbaumgartner (talk) 07:26, 11 May 2013 (UTC)

Indeed, a good idea. I opened a thread there.--Ymblanter (talk) 19:36, 11 May 2013 (UTC)

 Not done --Tobias1984 (talk) 13:32, 30 July 2013 (UTC)

melting point (en) / schmelzpunkt (de)/ point de fusion (fr)/ punto de fusión (es)

   Not done

Description	The temperature at which a substance melts
Data type	Number (not available yet)
Template parameter	"melting point" in w:Template:Infobox element and w:Template:Chembox
Domain	term
Allowed values	numbers
Example	methane (Q37129)...-182 dichloroacetylene (Q14375558)...-50
Source	http://www.chemspider.com
Robot and gadget jobs	Bots would be helpful.
Proposed by	--Jakob (Scream about the things I've broken) 18:03, 30 July 2013 (UTC)

Discussion

 duplicate Wikidata:Property_proposal/Pending#Melting_point_.28en.29 --Tobias1984 (talk) 18:05, 30 July 2013 (UTC)

This property proposal will be deleted: duplicate Snipre (talk) 18:14, 30 July 2013 (UTC)

 Not done --Tobias1984 (talk) 18:23, 30 July 2013 (UTC)

Compton wavelength / Compton Wellenlänge /

   Not done

Description	Characteristic property of any elementary particle
Data type	Number (not available yet)
Template parameter	de:Vorlage:Infobox Teilchen
Domain	particles
Example 1	MISSING
Example 2	MISSING
Example 3	MISSING
Proposed by	Svebert (talk) 21:02, 15 March 2013 (UTC)

This can and imho should be calculated from the mass automatically. Lua can do this without problems. -- MichaelSchoenitzer (talk) 15:38, 21 March 2013 (UTC)

 Oppose if this is really a derived value. Base data should be claimed and derived values calculated client-side. Joshbaumgartner (talk) 06:51, 13 May 2013 (UTC)

This proposal will be deleted: without any new comment or modification this proposal will be deleted. Snipre (talk) 09:39, 29 July 2013 (UTC)

 Oppose - I think so too. This is ready for the archive. --Tobias1984 (talk) 10:03, 29 July 2013 (UTC)

double  Oppose. Of course you can calculate the compton wavelength but in fact it is a quantity which is and will be measured ([2], [3]). From measurement you can extract the mass, or plancks constant.

If I understand correctly the theory the compton wavelength is function of the mass and the diffusion angle. So you can have an infinity of values according to the diffusion angle. So without a clear definition or a standard for the diffusion angle (like for the refractive index in chemistry) this can't be a characteristic of a particule but a consequence of a more primary property. Snipre (talk) 20:55, 29 July 2013 (UTC)

 Not done --Tobias1984 (talk) 18:25, 31 July 2013 (UTC)

service entry

   Done: service entry (P729) (Talk and documentation)

Description	Date on which the aircraft entered operational service
Data type	Point in time
Template parameter	en:template:infobox aircraft (introduced)
Example	<General Dynamics F-16 Fighting Falcon> service entry <17 August 1978>
Proposed by	Joshbaumgartner (talk)

 Support - but we have to watch out where else this can or is already requested/pending creation. --Tobias1984 (talk) 14:01, 16 May 2013 (UTC)

 Comment I see the label in the infobox is introduced, perhaps that is a better label, and could be used for other terms? And with some qualifiers such as country? Danrok (talk) 15:58, 22 May 2013 (UTC)

 Done User:John F. Lewis

service retirement

   Done: service retirement (P730) (Talk and documentation)

Description	Date on which the aircraft retired from operational service
Data type	Point in time
Template parameter	en:template:infobox aircraft (retired)
Example	<Republic F-105 Thunderchief> service retirement <25 February 1984>
Proposed by	Joshbaumgartner (talk)

 Support - but we have to watch out where else this can or is already requested/pending creation. --Tobias1984 (talk) 14:01, 16 May 2013 (UTC)

 Comment What about retirement date which could then be used with other types of item? Danrok (talk) 15:59, 22 May 2013 (UTC)

 Done User:John F. Lewis

Litholex ID / Litholex Primärschlüssel

   Done: Litholex ID (P731) (Talk and documentation)

Description	the ID for every stratigraphic unit in Germany. Every geologic survey has one of these databases, so I will have to request many more of these properties.
Data type	String
Template parameter	not included in any infobox, but would be a good way of linking to the primary data
Domain	term
Example	Tristel Formation = "2008131" ([4])
Format and edit filter validation	I think all of the ids are 7 digit numbers.
Source	litholex page: [http://www.bgr.bund.de/DE/Themen/GG-Stratigraphie/LithoLex/litholex_node.html
Robot and gadget jobs	gather ids for existing stratigraphic unit items.
Proposed by	Tobias1984 (talk)

Discussion

•  Comment Rough idea of how many other databases, and can you show a couple of examples? Just to give a clearer picture of this.Danrok (talk) 16:04, 25 May 2013 (UTC)

I can only give you rough estimate on the number of databases. I think that every highly developed geologic survey has one. But not every country has its own geologic survey. I currently have 9 collected here. More examples:

• Erfurt Formation = "5000001"
• Arnstadt Formation = "5000005"
• Stuttgart Formation = "5000003"

--Tobias1984 (talk) 16:28, 25 May 2013 (UTC)

• It might help to look at an English version of such a database. The English one is very nice (http://www.bgs.ac.uk/Lexicon/). It uses text strings for the units: Old Red Sandstone is "ORS" (http://www.bgs.ac.uk/Lexicon/lexicon.cfm?pub=ORS). The USGS version is currently being redesigned, so there is no point in starting any crosslinking now (http://ngmdb.usgs.gov/Geolex/geolex_qs.html). --Tobias1984 (talk) 17:08, 25 May 2013 (UTC)

• I think it's time to go ahead with these three properties. Filceolaire (talk) 18:51, 31 July 2013 (UTC)

 Done --Tobias1984 (talk) 18:57, 31 July 2013 (UTC)

BGS Lexicon ID / BGS Lexikon Primärschlüssel

   Done: BGS Lexicon of Named Rock Units ID (P732) (Talk and documentation)

Description	the ID for every stratigraphic unit in England (United Kingdom) given by the British Geological Survey
Data type	String
Template parameter	not included in any infobox, but would be a good way of linking to the primary data
Domain	term
Example	Old Red Sandstone = "ORS" (source),Kellaways Formation = "KLB" (source), London clay = "LC" (source), Oxforc Clay Formation = "OXC" (source).
Format and edit filter validation	Most are 3 letter combinations.
Source	http://www.bgs.ac.uk/Lexicon/
Robot and gadget jobs	gather ids for existing stratigraphic unit items.
Proposed by	--Tobias1984 (talk) 16:29, 26 May 2013 (UTC)

Discussion

See Litholex ID above Filceolaire (talk) 18:48, 31 July 2013 (UTC)  Done --Tobias1984 (talk) 18:57, 31 July 2013 (UTC)

DINOloket

   Done: DINOloket ID (P733) (Talk and documentation)

Description	the ID for every stratigraphic unit in the Netherlands given by the Basisregistratie Ondergrond (BRO)
Data type	String
Template parameter	not included in any infobox, but would be a good way of linking to the primary data
Domain	term
Format and edit filter validation	Breda Formation (Q3266830) = "breda-formation-nuba", Middle North Sea Group (Q2481683) = "middle-north-sea-group-nm"
Source	http://www.dinoloket.nl/nomenclator
Proposed by	--Tobias1984 (talk) 09:29, 16 July 2013 (UTC)

Discussion

See Litholex ID above Filceolaire (talk) 18:49, 31 July 2013 (UTC)  Done --Tobias1984 (talk) 18:57, 31 July 2013 (UTC)

surname / Nachname / patronyme

Status:    Done

→ Property:P734

• Description: The surname or the last name of a person. This only applies to persons who have a last name. This provides a machine readable version of the label for person items. For example, George Washington will have item Q2550388 (Washington) as the value of this property.
• Datatype: Item
• Links:
• Domain: Person
• Comments: --Wylve (talk) 17:02, 18 February 2013 (UTC)

  But many names don't have an item in Wikidata ? --Eric-92 (talk) 18:43, 18 February 2013 (UTC)

  This is an issue for all properties, especially with relations properties (e.g. Person A has a child that doesn't have an article at any Wikipedia. There is no way to express that Person A has a child at this point on Wikidata). If possible, the value should contain a string, instead of an item, when the item is unavailable. However, I believe Wikidata doesn't support strings at the moment. --Wylve (talk) 07:42, 19 February 2013 (UTC)

  The disadvantage of using strings is, that even if the item will be created some time, many dead strings still will exist (without link to the new item). If we only support items, the item can be created even if no Wikipedia article exists and the first Wikipedia which creates the article then links the new item and all occurrences of this item are then linked to this Wikipedia item. --Faux (talk) 08:28, 19 February 2013 (UTC)

I like the idea of article-less labels and their implementation, but that may violate our notability guideline. --Wylve (talk) 15:59, 19 February 2013 (UTC)

Do we need properties like this? I think no. --Stryn (talk) 08:12, 19 February 2013 (UTC)

I think especially if a person has several names (surnames and first names), the title of the article itself only mentions some of them (e.g. w:Karl-Theodor_zu_Guttenberg) but the data exists, so I would say it can be stored in Wikidata. --Faux (talk) 08:22, 19 February 2013 (UTC)

•  Support -- if the goal is structured data, it's pretty hard not to support this. Have you ever seen a database that didn't distinguish between given and family names? I don't think it should be created as an Item type at this point. Espeso (talk) 16:12, 19 February 2013 (UTC)
•  Support If an item is missing we should create it. --ThorstenX1 (talk) 11:25, 20 February 2013 (UTC)

  No. Do we add every surnames here, even if there is not any articles? --Stryn (talk) 15:17, 20 February 2013 (UTC)

  @Stryn: There is currently a discussion going on at project chat about modifying the notability guideline to suit phase 2, which may allow the creation of article-less items. --Wylve (talk) 16:12, 20 February 2013 (UTC)

•  Comment: necessary for #Italian Wikipedia person data. --Nemo 08:59, 22 February 2013 (UTC)
•  Support the "last name" term should be avoided because that can be confusing outside the western hemisphere in places where the family name is the used as the first name. Danrok (talk) 14:55, 24 February 2013 (UTC)
• * I created this property as P152, but I asked for deletion later  Oppose --Goldzahn (talk) 07:00, 25 February 2013 (UTC)

Any reason why? --Wylve (talk) 11:40, 25 February 2013 (UTC)

I think, item is the wrong datatype. "George" in en:WP is translated to "Jordi" in ca:WP. "George Washington" in en:WP is called "George Washington" in ca:WP. You see, it is not the same. Names will not be translated in most languages. --Goldzahn (talk) 12:13, 25 February 2013 (UTC)

Yes you are right, that's why I advocated the use of either StringValue or article-less items for the value of this property. According to the revised notability guideline for Phase 2, the creation of article-less labels is accepted, but not for terms like names yet. --Wylve (talk) 16:38, 25 February 2013 (UTC)

A problem with StringValue is, that Names are written different in Japanese, Chinese, etc. I don´t understand meta:Wikidata/Data_model#Multilingual_texts, which Šlomo proposes. Maybe this is the right datatype. --Goldzahn (talk) 17:04, 25 February 2013 (UTC)

•  Support: I support having this property, but  Oppose not as the Item datatype. MultilingualTextValue seems more suitable since the use of personal names' translations/transliterations is different for particular names, languages and even persons and can't be simply linked to a Wikidata item dealing with name in general. --Šlomo (talk) 10:20, 25 February 2013 (UTC)
•  Support --NaBUru38 (talk) 23:06, 25 February 2013 (UTC)

 Oppose "Last name" would indeed confuse non-westerners. And on the other hand, not all westerners, neither historically nor in the present day, have a last name that is a "family name". I don't think we need this. - Ssolbergj (talk) 05:31, 27 February 2013 (UTC)

Yes, the name of this property has yet to reach a consensus (that's why it is currently called "surname" for now). However, unless I am mistaken, machines/bots will have no specific way of gathering the name of persons except for the label. There are a lot of templates on Wikipedia, Commons and Wikisource that have a name parameter, for the identification of artists, authors, translators, etc. --Wylve (talk) 08:25, 27 February 2013 (UTC)

•  Support --OldakQuill (talk) 23:50, 2 March 2013 (UTC)
•  Support I agree with the supports above. — ΛΧΣ²¹ 04:45, 26 March 2013 (UTC)
•  Oppose Better to have one property "Full name" including last and surname Snipre (talk) 09:31, 2 April 2013 (UTC)
•  Oppose First Name/Last Name has a cultural bias as mentioned above. Given Name/Surname often are a gross simplification: patronyms are mentioned below, but also think of additional western-style first names of chinese people, "matronymic" middle names in northern America (last name of mother considered part of first name), combined surnames in Spain, titles of nobility transformed into last names by act of law (Germany), medieval names with geographic attribution, tripartite african names (Togo?). And, when a person has several names or the name is notated in several scripts, not every combination of given names and surnames makes sense: You only can take one name at a time and decompose it according to the cultural context the name has been used in. Furthermore (consider chinese names or japanese names with a historical cut in the 1920s) you cannot reconstruct a name from its components since there is no universal rule governing which part is notated first. I see a certain demand for distinguishing the part of a name which can be used for sorting lists of names (there is also no global consensus), not only for actual sorting but for typographical distinction (letter-spacing in french) or inversion (last name, comma, first name like in western phone directories) but I don't see a clean solution for that. -- Gymel (talk) 15:28, 8 April 2013 (UTC)

   Comment – only apply where applicable. Littledogboy (talk) 23:21, 28 July 2013 (UTC)

•  Support I support having this property per Espeso, but  Oppose not as the Item datatype; String or MultilinguaText are better. --β₁₆ - (talk) 09:20, 24 April 2013 (UTC)
•  Comment Many surnames have Wikipedia articles. —★PοωερZ_talk 11:32, 8 May 2013 (UTC)
•  Support We need this. We already have pages for a lot of surnames and creating Wikidata pages for any missing surnames seems reasonable to me. Eventually we will need properties for other parts of names besides given name and surname (patronymics, titles, etc.) Filceolaire (talk) 19:05, 14 May 2013 (UTC)
•  Support --Odejea (talk) 13:14, 5 June 2013 (UTC)
•  Oppose. --Yair rand (talk) 00:45, 7 June 2013 (UTC)
•  Support – very useful for Wikipedias. Details can be changed later. Littledogboy (talk) 23:19, 28 July 2013 (UTC)
•  Support --Nightwish62 (talk) 19:47, 31 July 2013 (UTC)

 Done 13 support vs. 4 oppose. So the large majority is supporting this property. An RFC (Wikidata:Requests for comment/Personal names was started, but didn't get any conclusion in more than a month. Even worse, there was only 2 edits in the last 30 days! No reason to keep back this property longer, the proposal is pending since a half year. If someone disagree with this decision (and I'm sure someone will) feel free to start a request for Wikidata:Properties_for_deletion--Nightwish62 (talk) 19:47, 31 July 2013 (UTC)

given name / Vorname / prénom

   Done: given name (P735) (Talk and documentation)

Description	The given name or the first name of a person. This only applies to persons who have a first name. This provides a machine readable version of the label for person items. For example, George Washington will have item Q1985538 (George) as the value of this property.
Data type	Item
Domain	Person
Proposed by	--Wylve (talk) 17:02, 18 February 2013 (UTC)

Discussion

•  Comment see comments below at surname / Nachname / patronyme
•  Comment: necessary for #Italian Wikipedia person data. --Nemo 08:59, 22 February 2013 (UTC)
• I created this property as P153, but I asked for deletion later  Oppose --Goldzahn (talk) 07:00, 25 February 2013 (UTC)
•  Support: I support having this property, but  Oppose not as the Item datatype. MultilingualTextValue seems more suitable since the use of personal names' translations/transliterations is different for particular names, languages and even persons and can't be simply linked to a Wikidata item dealing with name in general. --Šlomo (talk) 10:22, 25 February 2013 (UTC)
•  Support --NaBUru38 (talk) 23:05, 25 February 2013 (UTC)
•  Comment: See: Property talk:P153. --Kolja21 (talk) 02:32, 26 February 2013 (UTC)
•  Support --OldakQuill (talk) 23:49, 2 March 2013 (UTC)
• I think the boundaries of where to use this property needs more clarification first. Do middle names count as "given names"? How about Burmese names, regnal names, changed names, mononyms, or Akan names? What about people who went by different names in different languages? --Yair rand (talk) 20:40, 18 March 2013 (UTC)

  Another point: Would Yoda's given name be "Yoda", and would we need an item for it? --Yair rand (talk) 21:31, 18 March 2013 (UTC)

  I am thinking of given names and family names given at birth. So this property would make more sense if renamed to "given name at birth". Middle names and mononyms should be included in a separate property. Burmese names should be considered a given name (e.g. "Aung San Suu Kyi" would be the value of this property in the item representing Aung San Suu Kyi). Changed names should be denoted using qualifiers, same goes with names in different languages. As for the example of Yoda, this property should be reserved for humans or other living things that bear name structures based on that of humans. I believe it is premature to create this property before considering a wide range of possibilities of how this property would be used. --Wylve (talk) 06:27, 27 March 2013 (UTC)

  Another issue: What about people who had different names in different languages? Or are just referred to as different things in different languages? Perhaps qualifiers could be used for this? --Yair rand (talk) 16:17, 17 April 2013 (UTC)

•  Support — ΛΧΣ²¹ 04:46, 26 March 2013 (UTC)
•  Support --★ → Airon 90 08:48, 31 March 2013 (UTC)
•  Oppose Better to have one property "Full name" including last and surname Snipre (talk) 09:31, 2 April 2013 (UTC)
•  Comment maybe the name can be split in "family name" as part of the name that is in common with other persons and "calling name" the part of the name used to get attention of a person. --FischX (talk) 17:31, 9 April 2013 (UTC)
•  Support I support having this property, but  Oppose not as the Item datatype; String or MultilinguaText are better. --β₁₆ - (talk) 09:17, 24 April 2013 (UTC)
•  Comment The property "birth name (P513)" was recently created. If a normal naming scheme is set up, it could probably replace P513 by using date qualifiers. --Yair rand (talk) 20:44, 12 May 2013 (UTC)

  Also relevant to names: P:P511 and P:P97. --Yair rand (talk) 22:27, 12 May 2013 (UTC)

•  Support --Odejea (talk) 13:14, 5 June 2013 (UTC)
•  Oppose, without a comprehensive plan on how to deal with names. It's a complicated topic, and we should probably have an RFC on it, and not throw the whole thing together bit by bit, causing loads of problems down the line. --Yair rand (talk) 00:44, 7 June 2013 (UTC)

Status report

• Support: 7
• Oppose: 3
• Oppose datatype: 3
• Call for RfC: 1
• Counting the votes that oppose the datatype it seams that this property can't be created at the moment. It looks like an RfC would be a good idea. --Tobias1984 (talk) 11:29, 13 June 2013 (UTC)
  • I've opened Wikidata:Requests for comment/Personal names. --Yair rand (talk) 01:34, 18 June 2013 (UTC)

 Done same reason as surname (see above) + the reason that surname exist and therefore it make sense that also given name exist :) --Nightwish62 (talk) 19:54, 31 July 2013 (UTC)

numeral system

   Not done

Description	numeral system of the item or property, mainly if not Arabic
Data type	Item
Example	۰۸۳۱ => Eastern Arabic numerals

Can be useful as property or qualifier. --  Docu  at 20:08, 2 May 2013 (UTC)

• Would you please give some concrete examples of items which could use this property in a claim, and some concrete examples of claims which could use this property in a qualifier? Thank you, Byrial (talk) 21:44, 2 May 2013 (UTC)
  • Local dialing code on Rasht (Q178373) (current version) would need the qualifier. --  Docu  at 05:23, 3 May 2013 (UTC)
    • I see no reason why that telephone area code should use Persian number symbols. I would prefer that it is stated as "0130" (instead of "۰۱۳۱"), then the Wikipedias can easily convert to the local way of presenting numbers (like Persian, Eastern Arabic, Devanagari, Tamil, Thai and so on). Any other examples? You said it can useful as property. How? Byrial (talk) 08:33, 3 May 2013 (UTC)
•  Oppose – Only given example given is telephone codes, and these should use the symbols 0-9 for digits which is used by most Wikipedias, and allow for easy conversion for those which use other symbols for digits. Byrial (talk) 22:13, 5 May 2013 (UTC)
  • If it's easy, would you do it for the P473 entries we get and provide conversion for fa_wiki? --  Docu  at 11:08, 19 May 2013 (UTC)
    • The conversion is only a few lines of Lua code, which I suppose that the Persian Wikipedia would want anyway to convert the numeric codes not written with Persian numbers. It actually would be much simpler for the Persian Wikipedia just to convert every telephone code from digits 0-9 than to check for a numeral system qualifier and adjust the conversion accordingly. Byrial (talk) 12:09, 19 May 2013 (UTC)
•  Oppose per Byrial. --Ricordisamoa 13:31, 4 June 2013 (UTC)
  • • •  Support I don't think Lua code can easily cope with conversations from Maya numerals (Q335109), Babylonian numerals (Q506274) or Roman numerals (Q38918) - the other examples listed in the proposal though I suppose we could use instance of (P31) instead as this is not going to be used that many times. Filceolaire (talk) 21:47, 6 June 2013 (UTC)
        • I don't know the details of all of these systems, but until now nobody gave any example for strings using them, so it is not actual. When I see an example I will investigate if I consider this qualifier useful for the example, but not before. Byrial (talk) 22:16, 18 June 2013 (UTC)
•  Comment First, I supposed that Wikidata is a multilingual project and by this presumption in my mind, proposed the property dialing code with number not string data type. Because I supposed Wikidata is a powerful conversion tool as it had already done it for items and properties. But now I can not believe that even there isn't a tool advised for converting dates into their Hijri calendar equivalents in Wikidata!--دوستدار ایران بزرگ (talk) 21:56, 9 June 2013 (UTC)

I'm pretty sure things like that can be the topic of an RfC. But currently there are just higher priority things the developers need to work on. Implementing a conversion shouldn't be to difficult. --Tobias1984 (talk) 09:19, 10 June 2013 (UTC)

 Not done --Nightwish62 (talk) 08:00, 1 August 2013 (UTC)

In list/Im List/En liste/в списке

   Not done

Description	list in which the order is given
Data type	Item
Template parameter	there is (in sequences templates)
Domain	properties next and previous
Allowed values	items with lists
Example	for ouverture dance next is allemande in list Baroque suite (the last item is not exact though)
Proposed by	Infovarius (talk) 09:45, 30 April 2013 (UTC)

• As the prescribed 2 properties are used in different areas (and this is normal), one item can be a member of different sequences. The qualifier helps to distinguish them. Infovarius (talk) 09:45, 30 April 2013 (UTC)
• I am confused. The example (Baroque) is not a list, and ouverture is not list of languages, so I have no clue what really is proposed. Byrial (talk) 15:21, 30 April 2013 (UTC)

  Sorry for copy-edit error: changed "items with languages" to "items with lists". "Baroque suite" contains a sequence of pieces. Infovarius (talk) 21:01, 30 April 2013 (UTC)

• I think this means: In the baroque suite the allemande is played just after the prelude. I think it is a valuable thing to have, but I am not sure about the implementation. Actually it seems to me that it is synonymous with "part of: Baroque suite, qualifier: preceded by: ouveture". --Zolo (talk) 18:34, 30 April 2013 (UTC)

• May be, the example with ouverture and allemande is not very good. I mean qualifier for "preceded by" - "in a sequence of". Infovarius (talk) 21:01, 30 April 2013 (UTC)

•  Support: the 'preceded by' and 'succeeded by' properties can easily be ambiguous. This property seems useful for resolving that. Emw (talk) 00:15, 1 May 2013 (UTC)

• If I understand correctly now, it is intended to use this way:
  • Ouverture have property succeeded by with the value allemande
    • Qualifier "in list" with value Barock suite
  • Bill Clinton have property preceded by with value Joe Purcell
    • Qualifier "in list" with value Governor of Arkansas
    • Qualifier "as of" with value "1979"
  • Bill Clinton have property succeeded by with value Frank White
    • Qualifier "in list" with value Governor of Arkansas
    • Qualifier "as of" with value "1981"
  • Bill Clinton have property preceded by with value Frank White
    • Qualifier "in list" with value Governor of Arkansas
    • Qualifier "as of" with value "1983"
  • Bill Clinton have property succeeded by with value Jim Tucker
    • Qualifier "in list" with value Governor of Arkansas
    • Qualifier "as of" with value "1992"
  • Bill Clinton have property preceded by with value George H. W. Bush
    • Qualifier "in list" with value President of the United States
  • Bill Clinton have property succeeded by with value George W. Bush
    • Qualifier "in list" with value President of the United States

If that is the case, I think there might be two problems:

1. It will be difficult to pair the uses of P155 and P156 (preceded by/succeded by)
2. You will have to repeat the list item unnecessarily for both P155 and P156

• Instead I propose this way to organize the information without the need of an "in list" qualifier:
  • Ouverture have property part of with value Barock suite
    • Qualifier succeeded by with the value allemande
  • Bill Clinton have property office held with value Governor of Arkansas
    • Qualifier preceded by with value Joe Purcell
    • Qualifier "from" with value "1979"
    • Qualifier "to" with value "1981"
    • Qualifier succeeded by with value Frank White
  • Bill Clinton have property office held with value Governor of Arkansas
    • Qualifier preceded by with value Frank White
    • Qualifier "from" with value "1983"
    • Qualifier "to" with value "1992"
    • Qualifier succeeded by with value Jim Tucker
  • Bill Clinton have property office held with value President of the United States
    • Qualifier preceded by with value George H. W. Bush
    • Qualifier succeeded by with value George W. Bush

Based on that, I will say  Oppose Byrial (talk) 05:28, 1 May 2013 (UTC)

• You are right. The second scheme looks good for me (too). Infovarius (talk) 10:34, 1 May 2013 (UTC)
• Byrial, why is it necessary to list the dates? That seems like redundant information; it could be deduced from each item in the list. I think it's best to keep claims free of such seemingly extraneous data. Emw (talk) 23:48, 1 May 2013 (UTC)

 Oppose for now, per Zolo and Byrial.

• Only it must be clear that the qualifier's "preceded by" means the main item is preceded, not the property's value. An error would be:
  • Bill Clinton have property office held with value President of the United States
    • Qualifier preceded by with value Governor of Arkansas
• It's also tempting to make "Firefox 3.6 succeeded by Firefox 4 in sequence Firefox release history", especially if somebody opposes "Firefox 3.6 is subclass of Firefox", or if it never becomes possible to link Firefox release history to it.

--AVRS (talk) 08:26, 1 May 2013 (UTC)

Something odd with your understanding of "preceded by"... Mine is the same as Byrial's. Infovarius (talk) 10:34, 1 May 2013 (UTC)

I don't see which part you are referring to. --AVRS (talk) 19:09, 1 May 2013 (UTC)

How can Bill Clinton be "preceded by" "Governor of Arkansas"? Infovarius (talk) 15:57, 2 May 2013 (UTC)

He cannot. AVRS wrote "An error would be: [example error]". Byrial (talk) 16:43, 2 May 2013 (UTC)

Oh, my misunderstanding. Sorry to AVRS, sorry to you. Infovarius (talk) 09:30, 4 May 2013 (UTC)

•  Oppose per Byrial. Snipre (talk) 15:47, 8 June 2013 (UTC)

 Not done --Nightwish62 (talk) 08:07, 1 August 2013 (UTC)

Cover artist (en)

   Done: cover art by (P736) (Talk and documentation)

Description	Name of person or team creating album (or single) cover artwork
Data type	Item
Template parameter	Proposed for en:template:infobox album; to be proposed en:template:infobox single
Domain	creative work/ released recording
Allowed values	person or organisation
Example	The Wall (Q151114) -> Gerald Scarfe (Q463132)
Format and edit filter validation	???
Robot and gadget jobs	???
Proposed by	Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:27, 26 June 2013 (UTC)

Discussion

• Could be text instead if item? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:30, 26 June 2013 (UTC)
•  Support. Also for the datatype item. There are many notable cover artists which have created several covers. If we like to query them, we need the item datatype. --Nightwish62 (talk) 18:52, 30 June 2013 (UTC)
•  Support - but it also has to work for other creative works e.g. book covers etc... --Tobias1984 (talk) 10:39, 30 July 2013 (UTC)

 Done --Nightwish62 (talk) 08:37, 1 August 2013 (UTC)

Episode list / Episodenliste / …

   Not done

Description	Wikipedia-article with the episode list from the television series.
Data type	Item
Template parameter	en:template:Infobox television list_episodes
Domain	articles of television series
Allowed values	Lists of television series episodes
Example	List of The X-Files episodes is an episode list of The X-Files
Source	en:template:Infobox television
Proposed by	CENNOXX (talk) 14:46, 6 April 2013 (UTC)

It would be good to have this connection. CENNOXX (talk) 14:43, 6 April 2013 (UTC)

 Oppose The functionality to generate lists automatically will be implemented in Phase 3 of Wikidata's development. Therefore, Wikipedia articles that are purely lists will become redundant. To be able to generate lists, we need to relate individual episodes to their respective series. Silver hr (talk) 00:52, 13 April 2013 (UTC)

It will be a long way to generated episodelists. With Discography, Property:P358, there is another item like this one.--CENNOXX (talk) 14:15, 13 April 2013 (UTC)

 Comment 1. The (current) description says that this item is meant specifically to link to a wikipedia article. But an episode list (or a discography) is something that make sense not only on wikipedia but also in the outside world, it is something meaningful as itself. If such a property is accepted, the description should be changed. 2.  Question In a TV serie episodes can (and as a matter of fact are often) regrouped by season. Should this property also apply to seasons ?. 3.  Question Is there (currently) something in wikidata to handle ordered list of items ?

 Support, in general but questions of user above (unsigned) are worth being discussed. -- MichaelSchoenitzer (talk) 16:49, 18 April 2013 (UTC)

Look like unsigned is TomT0m (talk) /o\. I have since this comment thought one or two answers : with qualifiers, it will be possible to define a rank (integer) property associated to the <serie> has episode <ep> statement ; and the other way around <ep> is episode of <serie>. It will be also be possible to use preceeded by and followed by properties, see Property talk:P179. TomT0m (talk) 18:58, 18 April 2013 (UTC)

 Oppose Wait for p3. Conny (talk) 14:47, 28 April 2013 (UTC).

 Support even after the phase 3 technology is in place we won't be able to generate episode lists automatically until every episode has it's own wikidata item. In the meantime we should link to the existing wikipedia episode lists. Filceolaire (talk) 11:32, 16 May 2013 (UTC)

You don't need the wikipedia article, you can just create the episode item in wikidata. Snipre (talk) 18:11, 8 June 2013 (UTC)

 Oppose Wait for p3. Snipre (talk) 18:11, 8 June 2013 (UTC)

The thing is: the episode list wikipedia articles exist. And as long as they exist, a connection between them would be senseful. Maybe the connection could be made with another property? for example is a list of (P360) or part of (P361)?--CENNOXX (talk) 19:08, 8 June 2013 (UTC)

 Oppose --Nightwish62 (talk) 08:43, 1 August 2013 (UTC)

 Not done --Nightwish62 (talk) 08:43, 1 August 2013 (UTC)

influenced by - influenced / beeinflusst von - beeinflusste / FRENCH / испытал влияние / OTHERS

   Done: influenced by (P737) (Talk and documentation)

Description	items that influenced the other item, or the other way around
Data type	Item
Template parameter	influences or influenced by e.g. on the en:template:infobox philosopher, but also others
Domain	various. Persons, ideas, music bands, artistic eras...
Allowed values	as above
Example	Heidegger =influenced by=> Aristotle
Proposed by	Denny (talk)

Discussion

There are several Infoboxes who use that in the Wikipedias, like Philosophers, Scientists, Artists, etc., see here. There was already a previous proposal that failed, but I would like to revive the discussion, especially since it has clear precedent and usage in the Wikipedias. This is also the kind of data that would be really interesting to collect in external use cases, but as said, it is already used in the Infoboxes, and that should be sufficient reason. --Denny (talk) 17:48, 12 May 2013 (UTC)

I think it's pretty subjective and not facts. Infovarius (talk) 16:54, 13 May 2013 (UTC)

A lot of things in Wikidata are (gender?). But there are 'influenced by' statements that are well supported in sources. --Denny (talk) 21:48, 16 May 2013 (UTC)

I find it a bit strange to have it in Wikipedia infovoxes, but given that it is there, I suppose it makes sense to move it to Wikidata, where, at least, it can be centrally discussed, and where it can be used to create fun graphs. -Zolo (talk) 07:05, 15 May 2013 (UTC)

•  Support Emw (talk) 14:57, 27 May 2013 (UTC)

 Done --Nightwish62 (talk) 10:17, 1 August 2013 (UTC)

Status:    Done

→ Property:P738

 Comment I spit this property into two properties (influenced by (P737) and P738 (P738)), since otherwise there is no way to know if an item has influenced or was influenced by the other item --Nightwish62 (talk) 10:41, 1 August 2013 (UTC)

For work (en) / Для работы (ru)

   Not done

Description	All needs property for this article inclused from Wikipedia and another sites, what mistakes, rewrite, see administrators, no conflicts with another articles in Wikipedia (different language, version) and Wikidata (for example, sex whithout person, father without child, book without author or ISBN). May be verify information: imported from Virtual International Authority File (Q54919) or English Wikipedia (Q328)?
Data type	String
Domain	term
Example	PM Press (Q177136) => Library of Congress authority ID (P244)
Format and edit filter validation	(sample: 7 digit number can be validated with edit filter Special:AbuseFilter/17)
Robot and gadget jobs	Check other properties for consistency, collect data, verify includes propertys, mark article in this property for longer works with artickle.)
Proposed by	Пробегающий (talk) 15:58, 29 June 2013 (UTC)

Discussion

Not clear. Please give a better explanation. Snipre (talk) 11:52, 2 July 2013 (UTC)

Лучше по-русски, а то непонятно. --AVRS (talk) 09:40, 3 July 2013 (UTC)

Спасибо! Мой английский мало кому понятен...(

Суть в следующем. Для каждой статьи в ВикиДанных проставляется это свойство. 1) Все необходимые свойства для данной статьи либо заполнены, либо не заполнены, если не заполнены, то хотелось бы видеть перечисление этих свойств (Дата рождения, профессия, страна, географические координаты,...). Если заполнены, то ОК. 2) Наличие ошибок в заполнении свойств. Есть отчёты по каждому свойству, но отследить весь комплекс ошибок по данной статье невозможно. Нестыковки есть, допустим, с VIAF, статьями в Википедии(ях), в разных языковых Википедиях возможны различные данные по данному свойству, по VIAF, LCCN, GND и другим сайтоисточниковым данным идентификаторы выдают данные из Википедий, а в них несовпадение с первоисточником. В VIAF тоже есть перенаправления и дубляжи информации. Хотелось бы это видеть и состыковывать данные. Допустим, в статье А в Викиданных сказано, что В является для него родственником, а в В этого не прописано. Хотелось бы иметь информацию об этом в А и(или) В. 3)И ещё. Есть в ВикиДанных выверенные свойства, например, Москва - столица Российской Федерации. Отметка о нежелательности изменять данное свойство в данной статье можно прописать в этом свойстве. Степень завершённости работы над статьёй, так сказать. Пример, в статье про 5-го или 6-го Президента США я совсем недавно нашёл, что это - female.))) 4) Можно в последствии указать в данном свойстве желательность цитирования элементов статьи в Википедиях и сам факт цитирования. 5) Если у человека, допустим, изменятся данные (дата смерти, место рождения) и это отобразится в источнике для Викиданных, то предусмотреть флаг необходимости или запрета синхронизации всех данных по определённому свойству. Все эти предложения хотелось бы уложить в предлагаемое Property, с возможной системой кодировки и возможностью получить развёрнутый комментарий по статье с соответствующими проблемами. Для ботов будет возможность устранить некоторые из проблем в автоматическом режиме. Если взять одну из проблемных статей Q35820, то по ней вылезает сразу много проблем. Кодировка, даты и места рождения и смерти, родственники, ... В предлагаемом свойстве можно забить значение, которое позволит либо не включать статью в отчёты ошибок, либо предоставит более чёткую систему описания нестыковок разночтений. Предлагаемое свойство прибавляет объём работы, но проведённая работа сэкономит время и силы и даст свой результат. И по свойствам в целом. Можно ли проиндексировать свойства внутри статей? А то сначала идёт, допустим, дата смерти, потом пол, потом указание, что это персона. Улучшит энциклопедичность статьи, поиск свойства в статье и устранение неточностей и ошибок. Предлагаю знающим английский язык лучше меня упорядочить описание в шаблоне предлагаемого свойства и прошу прощения за неудобства, полученные при чтении моего английского.--Пробегающий (talk) 09:09, 5 July 2013 (UTC)

If I correctly understand you want a property which gives an indication about the last changes of the whole item. For that kind of task better work offline with dumps of the database in order to perform data checks. From my opinion better avoid to mix data and database markers. We have already some tools which check the consistency of data and I think these kind of tool are a better solution than a simple indicator in an item. Snipre (talk) 11:20, 5 July 2013 (UTC)

Нет, я считаю, что надо подходить к проблеме комплексно. Не устранять отдельно взятую ошибку в массиве статей, а прорабатывать каждую статью на полноту и достоверность информации. Инструменты есть, которые показывают о наличии ошибки, но связь между массивом свойств в статье, а также связь с другими статьями не прослеживается чётко. При данном подходе можно решить сразу несколько проблем за одно обращение к статье и связать корректные данные со многими статьями в разных Википедиях.--Пробегающий (talk) 11:41, 5 July 2013 (UTC)

Не понимаю, что означает название свойства «Для работы». Указание источников постепенно реализуется; двусторонние свойства давно запланированы. Идёт ли речь о добавлении дополнительных метаданных в статьи Википедии, или только лишь об указании чего-то внутри Викиданных? --AVRS (talk) 16:09, 5 July 2013 (UTC)

I don't understand what the property name "For work" means. Specification of sources is being implemented (slowly), bi-directional properties are planned since long ago. Do you mean adding more metadata in Wikipedia articles, or only specifying something inside of Wikidata? --AVRS (talk) 16:09, 5 July 2013 (UTC)

Is there some kind of translation project for Wikimedia projects where english translators in a language could register and where somebody who cannot speak english but want to take part to discussions could make a SOS request ? TomT0m (talk) 11:44, 5 July 2013 (UTC)

 Not done --Nightwish62 (talk) 10:46, 1 August 2013 (UTC)

cartridge (ammunition)

   Done: ammunition (P739) (Talk and documentation)

Description	the ammunition a gun fires
Data type	Item
Template parameter	infobox weapon in all languages. e.g. english = cartridge
Domain	term
Allowed values	types of ammunition
Example	Heckler & Koch G3 = 7.62×51mm NATO
Robot and gadget jobs	gather data from infobox
Proposed by	Tobias1984 (talk)

•  Support Danrok (talk) 18:42, 26 May 2013 (UTC)

 Done --Nightwish62 (talk) 14:22, 1 August 2013 (UTC)

Formation location

   Done: location of formation (P740) (Talk and documentation)

Description	Location where a group or organization was formed
Data type	Item
Template parameter	Multiple, including foundation in en:Template:infobox company
Domain	Any group (company/organization/band/etc.)
Allowed values	Item (most specific location item that can be sourced)
Example	Birmingham Small Arms Company → Gun Quarter, The Beatles → Liverpool, England, etc.
Source	en:Template:infobox company, etc.
Proposed by	Superm401 - Talk

This is a broader alternative to the origin proposal above, intended for any organization/company/group. I propose the aliases formation place, place of formation, location of formation). Superm401 - Talk 17:29, 8 April 2013 (UTC)

•  Support --Viscontino (talk) 11:15, 19 April 2013 (UTC)
•  Support Danrok (talk) 01:07, 17 June 2013 (UTC)
•  Support --Micru (talk) 01:45, 8 July 2013 (UTC)

 Done --Nightwish62 (talk) 18:55, 1 August 2013 (UTC)

playing hand (en) / Spielhand (de)

   Done: playing hand (P741) (Talk and documentation)

Description	the hand(s) a tennis player uses for his strokes
Data type	Item
Template parameter	"plays" in en:template:Infobox tennis biography
Domain	tennis players
Allowed values	left-handed, right-handed, double-handed backhand, double-handed forehand
Example	Rafael Nadal (Q10132) => left-handedness (Q789447) + "double-handed backhand" (this item has yet to be created)
Proposed by	Kompakt (talk)

Discussion

There's already handedness (P552), but we need something more specific for tennis players. A few players are, e.g., right-handed but play with their left hand. In addition, we need to store whether the player uses a double-handed backhand or forehand.--Kompakt (talk) 12:54, 12 June 2013 (UTC)

•  Support. --Stryn (talk) 18:07, 12 June 2013 (UTC)
•  Support, and agree with user Kompakt! Edoderoo (talk) 07:38, 18 June 2013 (UTC)

 Done --Nightwish62 (talk) 19:17, 1 August 2013 (UTC)

Pseudonym / Pseudonym / Pseudonyme / (it) Pseudonimo / (es) Seudónimo

   Done: pseudonym (P742) (Talk and documentation)

Description	The pseudonym used by someone or by which this person is universally known.
Data type	monolingual-text string-invalid datatype (not in Module:i18n/datatype)
Domain	persons
Allowed values	type of linked items, restrictions on the values
Example	Antonio Arias Bernal, known as "El Brigadier"; Bud Spencer, pseudonym for Carlo Pedersoli; ...
Source	External reference, Wikipedia list article
Proposed by	Sannita - not just another it.wiki sysop 14:15, 23 March 2013 (UTC)

• •  Support --NaBUru38 (talk) 19:36, 27 March 2013 (UTC)
•  Support --Paperoastro (talk) 17:20, 28 March 2013 (UTC)

 Comment How is this different from "alias"? Silver hr (talk) 04:01, 31 March 2013 (UTC)

I assume you're referring to the field right under the "description" field. It is different in a sense: that "alias" field is "language-sensitive", that is aliases have to be repeated language by language, and in most cases are just a list of redirects from one Wikipedia. So, we may have one or two lingual versions of a Wikidata item that have that particular alias, but not all lingual versions we intend to have. Plus, many libraries databases have that particular field, so it may be interesting to import that field as well. --Sannita - not just another it.wiki sysop 09:17, 31 March 2013 (UTC)

Yes, that's what I was referring to. However, I'm still not quite sure I understand the advantage that this property would bring over using the alias field. Could you try to explain it with an example? Silver hr (talk) 23:30, 12 April 2013 (UTC)

Answer The advantage of a special pseudonym field over Alias is that you know that it is a pseudonym and no birth name, last name or nickname. --Pyfisch (talk) 16:12, 10 May 2013 (UTC)

From what I understand, the words "alias" and "pseudonym" mean the same thing: an alternate name by which one is known. A nickname is an informal example of that. And first and last names by themselves shouldn't be put as aliases anyway. So...I'd still like an example that illustrates the advantage of this property over the alias field :) Silver hr (talk) 01:32, 27 May 2013 (UTC)

•  Oppose there are several kinds of pseudonyms, e.g. when a group of people uses it (jointly, simultaneously or successively) for publication and the pseudonym in this case might well be a different entity. OTOH pseudonyms are only an instance of a broader class of names like artists names, real names, birth names, marriage names, religious names, former and later names and so on most of which bear the necessity for temporal and language qualification. Since this requires a complex data type anyway I'd prefer to see a rather universal "form of name" property which then can be further qualified as being of type "pseudonym" or whatever. -- Gymel (talk) 13:04, 8 April 2013 (UTC)

 Question What is the difference between monolingual-text and string? I think we can also use stings for that. --Pyfisch (talk) 16:12, 10 May 2013 (UTC)

"string" should do I think. I updated the proposal accordingly. --  Docu  at 07:59, 19 May 2013 (UTC)

•  Support --Odejea (talk) 13:14, 5 June 2013 (UTC)
•  Support Filceolaire (talk) 16:43, 13 June 2013 (UTC)

 Done --Nightwish62 (talk) 19:24, 1 August 2013 (UTC)

Translated into / ? / ? /? / OTHERS

   Not done

Description	languages the original book translated into.
Data type	Item
Template parameter	sometimes used instead of Translator as in example below.
Domain	books
Allowed values	name of the languages
Example	w:en:The Alchemist (novel), in infobox, shows translated into 56 languages, we can list them here.
Source	w:en:Template:Infobox book have translator but we can list multiple languages
Robot and gadget jobs	don't know

Would be possible to query like how many language it translated into? or is it available in French? etc. Nizil Shah (talk) 20:57, 4 April 2013 (UTC)

Discussion

• I'm not sure this is the best way to handle this. We might just want to have separate items for each translation. Occasionally there will be multiple translations into the same language, and there will need to be some way of referencing them separately. --Yair rand (talk) 11:08, 6 June 2013 (UTC)
•  Oppose I understand that some pedias are displaying this in their infoboxes, however it is something that could be generated automatically by counting the number of different languages of the linked editions. Probably there won't be all, but the number will keep updating as soon as more are being added.--Micru (talk) 18:24, 12 June 2013 (UTC)

 Not done it wasn't a easy one to make a decision. However, Micru is right with his statement: If we link editions, we can count/list the language into which a work was translated. Furthermore, it's heavy to write a source for "translated into". It would only be possible by name a edition with the specific language. So we can use editions directly to retrieve the translated languages. --Nightwish62 (talk) 21:30, 1 August 2013 (UTC)

Historic highway shield

   Not done

Description	Media files depicting shield designs formerly used on the highway.
Data type	Commons media file
Domain	Places (roads)
Example	For Q449994, File:US 23 Michigan 1926.svg, File:US 23 Michigan 1948.svg, File:US 23 (1961).svg
Proposed by	—Scott5114↗ [EXACT CHANGE ONLY]

Discussion

There is already an existing property (P14) that links the item to the present-day shield. This property would link to any and all older shield designs that are no longer used, as shown in the example. (The historic shields are not linked in P14 because P14 will be used to display shields in the infobox; historic shields shouldn't be displayed in that context.) —Scott5114↗ [EXACT CHANGE ONLY] 02:02, 29 April 2013 (UTC)

 Support would be helpful to have this separation. --Rschen7754 02:08, 29 April 2013 (UTC)

 Support --Daniel749 talk (RTF) 13:21, 29 April 2013 (UTC)

And why not use the qualifier to distinguish between old and present shields ? Snipre (talk) 14:20, 29 April 2013 (UTC)

Because the infobox won't be able to tell the difference between the two when it displays the shields. Historic shields are not supposed to be shown. --Rschen7754 19:11, 29 April 2013 (UTC)

No sufficient as reason: that is the same problem for political position or team membership. Qualifiers are used to sort data and extraction models in wikipedia have to use this data in order to define the more recent data for display. Snipre (talk) 19:31, 29 April 2013 (UTC)

I strongly disagree - there is nothing in the Wikibase syntax allowing for this, and we may also have multiple current shields that need to be displayed, so displaying the most recent one will not work. --Rschen7754 19:50, 29 April 2013 (UTC)

So as we refuse properties based on chronology we will refuse this one. Wikibase syntax is not able to manage search in list but lua can do this. If we want to avoid manual operations in the wikidata database each time a change occurs we have to use the capacity of programming languages. Snipre (talk) 20:57, 29 April 2013 (UTC)

"We will refuse?" We operate by consensus here, not by fiat. Furthermore, manual operations will have to take place regardless of what we do. --Rschen7754 21:05, 29 April 2013 (UTC)

Perhaps my words were not well chosen but if you speak about consensus please just have a look at the previous proposals: Wikidata:Property_proposal/Organization#First_incumbent_.2F_Premier_titulaire, Wikidata:Property_proposal/Organization#Last_incumbent_.2F_Dernier_titulaire, Wikidata:Property_proposal/Archive/5#was_a.28n.29_.2F_war_ein.28e.29_.2F_.C3.A9tait_un.28e.29, Wikidata:Property_proposal/Archive/3#Successor_.2F_Nachfolger_.2F_successeur, Wikidata:Property_proposal/Archive/3#Predecessor_.2F_Vorg.C3.A4nger_.2F_pr.C3.A9d.C3.A9cesseur, Wikidata:Property_proposal/Archive/1#Former_member_of_sports_team,... Snipre (talk) 22:07, 29 April 2013 (UTC)

And how are those similar to this? The relationship is quite different here (past icons versus past associations/items), wouldn't you agree? --Rschen7754 22:10, 29 April 2013 (UTC)

The principle is the same: no properties has to be time dependent. The main reason is simple: how do you want to list all shields (old ones and the present one) in one list ? With this proposal you will need 2 queries implying 2 properties and then you will need to merge results. Can you do that in Wikibase ? And for a database management it is better to avoid periodic modifications which can lead to errors and to avoid to classify data according to the way you want to display them. Snipre (talk) 08:41, 30 April 2013 (UTC)

But the thing is that we never want to list all the shields. Never ever ever. --Rschen7754 08:49, 30 April 2013 (UTC)

Also of note: the last time the U.S. highway shield was changed was in 1970 (39 years). Before that, it was 1961 (9 years), before that 1948 (13 years), and before that 1927 (21 years). This isn't going to be something that changes frequently. —Scott5114↗ [EXACT CHANGE ONLY] 23:36, 3 May 2013 (UTC)

@Rs Again you think as a data user and not as a data manager: you don't know what people want or will do with the data. The good solution is to have an unique format for each type of data which allows all possible requests or data use. Snipre (talk) 22:37, 8 May 2013 (UTC)

Uh no, I have written plenty of road articles on the English Wikipedia and know how the infoboxes work there. --Rschen7754 17:37, 9 May 2013 (UTC)

And I think that is the problem: you are thinking from an unique point of view which is the present road infobox in the english WP. That is only a particular example of data use. Again I propose you to think according to a new possible use of data: list. Why can't we add in each english article a new section presenting all shields (historical ones and present one) sorting by time ? The goal of wikidata in not only providing data for infobox but to generate lists too. Snipre (talk) 08:43, 11 May 2013 (UTC)

Because it would be the same in every article (over 200) and would take up space. That makes no sense. --Rschen7754 08:47, 11 May 2013 (UTC)

Furthermore, local policies on enwp prohibit such a thing (image galleries, which this would be, are to be moved to Commons whenever they are present. The responses to this request read as though you simply don't like this proposal for some undefined reason and are coming up with increasingly farfetched scenarios and principles to justify that. The "you don't know what people want to do with this data!" argument is pretty condescending—the reason I proposed this property is because I have some data I would like stored on Wikidata, and I know what uses it will have because it's already being used at enwp. If the property to hold it isn't made, the data doesn't have a place to go on Wikidata, so it stays on enwp, and other projects (including Wikidata itself) don't benefit from it. —Scott5114↗ [EXACT CHANGE ONLY] 09:04, 11 May 2013 (UTC)

So I am condenscending when I try to think about other applications of data from wikidata and you not when saying that as EN policy forbids that data use all wikipedias have to do the same ? If that data has to be use only in en:WP according to EN rules no need of wikidata for that just keep your data and don't share them. And if according to Rs there is no use of that data why do you want to put them on wikidata ? Please be consistent.

And I explain my reason: when you have a list of items which are time dependent, the best solution is to have one property and to use qualifier (start and end date of use) in order to sort them or to distinguish them. This solution was proposed several times for different type of properties and was always adopted without a need of long discussions like here. This solution allows larger possibilities (like sorting, gallery creation, answer to specific query like which shield was used in 1960,...) and I don't understand your focus on a limited solution just because you don't want to use that data in other applications. Snipre (talk) 09:39, 11 May 2013 (UTC)

"And I explain my reason: when you have a list of items which are time dependent, the best solution is to have one property and to use qualifier (start and end date of use) in order to sort them or to distinguish them."

No it's not: Template:Cn. Furthermore, do we really want to have temporal coalescing? I sure hope not, in my graduate database classes it's always awful.

"This solution was proposed several times for different type of properties and was always adopted without a need of long discussions like here."

Why, because nobody stood up for what is actually practical for the most common application of this data? Wikidata is to support Wikipedia, of which the English Wikipedia is the largest; we do not make the English Wikipedia bend to Wikidata's needs.

"This solution allows larger possibilities (like sorting, gallery creation, answer to specific query like which shield was used in 1960,...) and I don't understand your focus on a limited solution just because you don't want to use that data in other applications."

Because all those applications that you suggested have very little real-world applicability - I'm quite obsessed with roads and nobody's going to want the data that those queries produces - and even if they did, there are other ways to write the queries. In short, this is getting quite ridiculous. --Rschen7754 09:52, 11 May 2013 (UTC)

Yes, this nice example of POV-statement is quite ridiculous: "in my graduate database classes it's always awful", very good example of particular examples standing as universal rules; "what is actually practical for the most common application of this data", wikidata is not determined by the most common data use: wikidata aims for infoboxes, list or semantic use, it's an open project ; "Wikipedia, of which the English Wikipedia is the largest; we do not make the English Wikipedia bend to Wikidata's needs", no comment, but I like this demonstration of english cultural imperialism; "I'm quite obsessed", so better don't get involved in this discussion if you know that you can't be neutral; "nobody's going to want the data", just Cn.

And finally you don't answer the most critical question (according to your point of point, it's clear: how you will use this property in your infobox ? You didn't find any application for historical shields in the infobox or in the articles until now. Do you have other arguments ? Snipre (talk) 10:40, 11 May 2013 (UTC)

It is clear that we are not getting anywhere, so I will await further comments. --Rschen7754 10:47, 11 May 2013 (UTC)

 Oppose as Snipre. We don't need to have duplicate separate properties for current and historic highway shields when qualifiers can give the start and end date for each shield as they do for other properties - even if it means the query syntax is slightly more complicated. Filceolaire (talk) 12:28, 26 May 2013 (UTC)

 Not done starting it this way, we can every property twice (former and current). This is really something qualifiers was designed for. --Nightwish62 (talk) 21:42, 1 August 2013 (UTC)

sister province / Schwesterprovinze / регионы-побратимы

   Not done

Description	Something like Property:P190 (twin city)
Data type	String
Domain	place
Example	Jeju Province => Hainan_Province
Source	External reference, Wikipedia list article (either infobox or source)
Proposed by	Милан Јелисавчић (talk)

Discussion

Motivation. Милан Јелисавчић (talk) 15:08, 4 May 2013 (UTC)

 Oppose Extend the already created property twinned administrative body (P190). Snipre (talk) 11:55, 29 July 2013 (UTC)

 Oppose per Snipre. --Tobias1984 (talk) 13:15, 30 July 2013 (UTC)

 Not done twinned administrative body (P190) should be used --Nightwish62 (talk) 21:58, 1 August 2013 (UTC)

Is Fictional

   Not done

Description	states whether an item refers to something that exists in the real World or to some fictional thing
Data type	boolean-invalid datatype (not in Module:i18n/datatype)
Allowed values	True, False, perhaps a few others
Example	Brainy Smurf -> True

It seems to be the best way to indicate that an item (or in some cases, a claim) is fictional. See Wikidata:Project chat#Fictional_stuff.

The most obvious datatype would be "boolean" but we won't have it, and actually, having using the item datatype may have some benefits, like perhaps using dedicated items for "disputed", "probably", etc. --Zolo (talk) 06:44, 13 May 2013 (UTC)

• Honestly, I'd rather things only be called "fiction" if they're clearly actually fiction, not just something that certain/a few/all/most individuals think don't/didn't exist. Using "is fictional" to deal with religious characters/events, proposed future entities, genocide denial, historical disputes, previously expected events that didn't happen, disputed scientific theories, etc. wouldn't be a good idea IMO. --Yair rand (talk) 07:29, 13 May 2013 (UTC)

• I agree that "is hypothesis" should be distinct from "is fiction", but I am no sure for things like the historicity of Jesus. People think Jesus existed because he is described in the Gospels, but some people do not think he existed because they think the Gospels are fiction (ok, fiction may not the right word here). --Zolo (talk) 08:01, 13 May 2013 (UTC)

• (ec) The proposal doesn't specify a model about how the property is used, and we talked about several models in WD:PC#Fictional stuff. Should you for example have one statement for Sherlock Holmes saying that he is fictional, a other separate statements for saying instance of: person, sex: male, occupation: private detective etc. or should these clarifications about the fictional item (or some of them) be used as qualifiers in the is ficitional statement (or maybe in several is fictional statements). It would be preferable to have a solution for such things before everybody does it in different ways. Maybe an RFC would be appropiate? Byrial (talk) 07:36, 13 May 2013 (UTC)

• I thought it should be the same way as in other properties: if the Sherlock Holmes item is marked as fictional, there is no need to state that all statements about him are fictional, just as there is no need to state the every instance of human is an instance of primate. If the fictionality only conerns one statement, it should be a qualifier. --Zolo (talk) 08:01, 13 May 2013 (UTC)
  • I fear that statements about the fictional item's fictional properties this way might be mixed with factual properties (like: creator or author: Arthur Conan Doyle; first appearance: A Study in Scarlet. It might be particularly difficult to distinguish for items about stories within stories. Byrial (talk) 08:42, 13 May 2013 (UTC)

Example: Instead of both having "Necronomicon author: Abdul Alhazred" and "Necronomicon author: H. P. Lovecraft", I would prefer that the former was a qualifier for "is fictional". Byrial (talk) 09:11, 13 May 2013 (UTC)

I don't think H. P. Lovecraft ever go round to writing the Necronomicon so he isn't the author. His books, however, are the source for the various statements we will have about Q2802 including the statements that it is fictional and that the author is Abdul Alhazred (Whose own page will tell us he is fictional). Filceolaire (talk) 20:34, 13 May 2013 (UTC)

Another solution could be a more general "truth value" property taking values like "fiction", "myth", "conjecture" or "catholic church dogma". --Zolo (talk) 11:43, 13 May 2013 (UTC)

I think an "Is Biblical" property could be useful. Filceolaire (talk) 20:34, 13 May 2013 (UTC)

What do you mean by "Is Biblical". Would it be true for Ramses II because he appears in the Bible ? Rethinking about it, I actually think that a generic "truth value" would be better. --Zolo (talk) 20:58, 13 May 2013 (UTC)

@Zolo your "truth value" sounds intresting even though the name is strange ^^--Shisma (talk) 09:51, 14 May 2013 (UTC)

Maybe better "Behemoth (Q4759868) <from world of> The Master and Margarita (Q188538)" for every fictional object instead of "is fiction"? — Ivan A. Krestinin (talk) 13:18, 20 May 2013 (UTC)

How about fiction of: Item (creative work item)? The presence of this property in an item would indicate that the item is fictional, and provide more information, as in a connection to the work. Danrok (talk) 16:36, 20 May 2013 (UTC)

Not only creative work items as most ancient mythologies, legendary creatures and urban myths lack a foundational book (except for Iliad and Bible I guess); so Sleipnir fiction of: Norse mythology could work. —★PοωερZ_talk 16:46, 20 May 2013 (UTC)

In English, if there is no book (or similar) then it is not fiction. Perhaps this works differently in other languages? For mythology, it could be legend of, but perhaps these 2 can share one property. Danrok (talk) 16:54, 20 May 2013 (UTC)

German Wikipedia defines fiction as: "Fiction is the creation of a separate world through literature, film, painting or other forms of representation and the handling of such a world." which clearly includes legends and oral tradition. —★PοωερZ_talk 17:06, 20 May 2013 (UTC)

Are you sure it is clear? Mythology is not categorized under fiction within the category tree on German wikipedia, it's under religion, which seems wrong as well. Danrok (talk) 17:24, 20 May 2013 (UTC)

 Comment This property only apparently solve the problem, imho we need something that allow us to use queries without specify every time if an item is fictional or not. Imho Zolo has right: GND (P:P107) is not sufficient for our purpose. However it is not necessary to delete it: we need something else, an ontology for Wikidata, with few and appropriate rules. So, the creation of this property and the property is truth imho is not so useful. --Paperoastro (talk) 21:58, 27 May 2013 (UTC)

 CommentDo we have the right to decide what is true or false? Our task - to classify the object by its belonging to its space of existence (the biblical character - in the space of Religion, mythological - in mythology, philosophy - a philosophy, science - in Science). Let the user selects a space that he needs (Religion, Mythology, Science, Virtual, Real and so on) Fractaler (talk) 16:17, 28 May 2013 (UTC)

I like that idea Fractaler. We just have to ensure that queries don't cross over into other spaces. For example if somebody queries a list of wars, then the Trojan War or any of the religious-text-wars should not be listed. We just have to find a way to separate these spaces. --Tobias1984 (talk) 06:40, 29 May 2013 (UTC)

It is worth investigating, but that seems complicated. Fore example, there has been ton of scholarly discussion about the historicity of the Trojan War, but quite possibly it is so different from Homer's depiction that it deserves a separate item. --Zolo (talk) 06:54, 29 May 2013 (UTC)

I think so too. The "Trojan war" should be a subclass of mythological war, whereas the "Historic Trojan war" should be a subclass of war. I think if we RfC this we can come up with a really good system of handling this. --Tobias1984 (talk) 07:00, 29 May 2013 (UTC)

 Question Cannot instance of (P31) be used instead? For instance "instance of": fictional object, fictional war, religious statement, etc. I fear that that creating a property like this could lead to yet another controversy like with P107 (P107).--Micru (talk) 01:14, 8 July 2013 (UTC)

 Oppose as Micru: "Instance of" is better. --Nightwish62 (talk) 19:10, 8 July 2013 (UTC)

"fictional character", "fictional war", fictional insect", "fictional teapot"... That would be really endless. And even then we would need a way to say that a "fictional teapot" is like a teapot, except that it is fictional. An "is fictional instance" property would be better, but as said above, this property would not be only about instances. --Zolo (talk) 06:00, 9 July 2013 (UTC)

• 'fictional war' --> instance of: 'fictional event' and 'war'
• 'fictional insect' --> instance of 'fictional animal' and 'insect'
• 'fictional book' --> instance of 'fictional object' and 'book'

So we need perhaps 1-5 main 'fictional xxx' items, not more. --Nightwish62 (talk) 22:17, 13 July 2013 (UTC)

A short, predefined list of possible values, would be worse than P107 (P107) imo, as it would be even more arbitrary and unintuitive). If we use "instance of", we have to expect users to use more specific value, like fictional insect. And irrespective of that, I really do not see how it is better to have "instance of fictional animal" (it requires playing with several values instead of one). If we want to keep the number of possible values low, it seems all-round simpler to restrict it to just one ("fictional stuff") and that is what "is fictional" would do. Zolo (talk) 10:23, 14 July 2013 (UTC)

Maybe you are using the wrong metric to compare : the additional items induced by describing this item as a type of fictional sword versus the number of statements added to state that all of the instances are fictional stuffs. TomT0m (talk) 11:41, 15 July 2013 (UTC)

•  Oppose specific property, use Gondor is instance of fiction, Gondor is instance of kingdom. If a wikipedia has an article about "fictional kingdoms", the latter is instance of fiction and instance of kingdom, while Gondor then is instance of "fictional kingdom".  — Felix Reimann (talk) 10:20, 23 July 2013 (UTC)

  But a fictional world can have any rules! Having a profession of a magician in some silly world entails you can levitate, a wardrobe in Narnia is a subclass of teleport, death in a computer game means you can respawn, I dont't know.... look, in a fictional world a book can be written by its characters and the author does what they say... In a fictional world, there are fictional properties. But what's worse, there may be properties with names like our properties, but upside down. Littledogboy (talk) 10:46, 23 July 2013 (UTC)

True. However, while each fiction has its differences to real world, most of the properties remain the same. Harry Potters sex is male even if he is a magician, isn't it? And not "fictional male". All your examples show nothing which cannot be modeled with existing properties. And - moreover - a template for these properties won't fail in most cases. And only in the rare case if it does fail, we add a switch case for fiction or use another template which is created for that specific case (how it is done already today). Please give specific examples where you think this won't work.  — Felix Reimann (talk) 11:00, 23 July 2013 (UTC)

• Fictional Kingdoms would be a subclass of kingdom, definitely not an instance. I'm not sure it would be an instance of fiction as it is a universe or a part of a universe, not a book or a story by itself. I'm also very opposed to make the classification system dependant of whether or not there is a Wikipedia article about the concept or not, this would make things unstable if the article is created later and would not allow to model things the best we can, worse to make thins vague just to fit the Wikipedia structure. TomT0m (talk) 09:48, 24 July 2013 (UTC)

  Yes, Help:Basic membership properties is a great starting point, a must-read! Well, maybe we sort of need "main type : fictional item" and then normal props could be used? Littledogboy (talk) 10:18, 24 July 2013 (UTC)

•  Support for the original proposal. All fictional must be set aside. Redundancy (isfictional AND is a fictional war) is not such a problem. Is it? Littledogboy (talk) 18:32, 22 July 2013 (UTC)
•  Oppose Why a new property ? Why not : part of (P361):fiction (Q8253) ? This can be used for person, insect, war, items, ... without any restriction. Snipre (talk) 11:24, 23 July 2013 (UTC)
  • part of (P361) is used to form a relation between 2 instances. fiction (Q8253) is a class, not am instance, so part of (P361) is not appropriate. Use instance of (P31):fiction (Q8253) instead. instance of (P31) is used to form a relation between an instance and a class. Filceolaire (talk) 12:00, 23 July 2013 (UTC)
•  Oppose. Apparently the Binary datatype is not going to be created. Use instance of (P31):Fictional Character or Play or Movie or Novel or Story. Mark these classes as subclass of (P279):fiction (Q8253). Filceolaire (talk) 12:00, 23 July 2013 (UTC)

 Not done No consensus, redundant. Also it should be boolean not item data value. Changed as appropriate in archive. John F. Lewis (talk) 22:02, 1 August 2013 (UTC)
 Not done - No consensus, see above. John F. Lewis (talk) 22:04, 1 August 2013 (UTC)

Truth value

   Not done

Description	state to what extent an item is true
Data type	Item
Example	luminiferous aether (Q208702) -> disproved / Assumption of Mary (Q162691) -> Roman Catholic dogma (Q7361876) / Brainy Smurf (Q3475557) -> fictional

As an alternative to the above proposal. Not sure "truth value" is the best label possible, but you get the idea. "Instance of" could arguably be used in some cases, but not all imo. --Zolo (talk) 20:58, 13 May 2013 (UTC)

•  Support but the name should be changed --Shisma (talk) 12:50, 14 May 2013 (UTC)

Do I get it right?

Examples

Entity	Property	Value	Truth value
Sherlock Holmes	main type (GND)	Person	fictional
Vulcan	instance of	Planet	hypothetical
Zeus	main type (GND)	Person	myth

assuing that every claim by default is considered to be the Major consensus narrative. there could also be a value for claims of the various religions and the chinese governent for instance. --Shisma (talk)

Yes, I think that's it. That would sound interesting to use it for official positions by state or institutions, but I am not sure how exactly that should be done. Something like "instance of: Ennemy of the People, truth value: official USSR position". --Zolo (talk) 19:41, 14 May 2013 (UTC)

Except that I do not think we should use it with "main type": fictional people are not considered as people according to the real GND scheme (that's one of the way this property does not fit well in Wikidata). --Zolo (talk) 20:12, 14 May 2013 (UTC)

so you think that Sherlock Holmes and Zeus shouldn't be considered as as individuals? --Shisma (talk) 12:44, 17 May 2013 (UTC)

Actually, I think that Sherlokck Holmes should be "instance of person", and that this property should be set to "fictional" in a separate statement.

My mistake, apparently, fictional people are considered people in the GND - sort of, Sherlock Holmes is both "person" (p) and "Zweifelsfall" (szz). The problem is that the "GND type" is just supposed to say to which GND "main type" an item belongs, it is not really meant to provide in depth info about what the item really is, but just to state which main type the GND would ssign to it. The GND assigns the same main type to queen Victoria, Zeus, and the Grimm Brothers, and so this property should have the same value for this three cases. I think it is insane, but apart from deleting this property, which I support, there is not much that we can do. --Zolo (talk) 07:27, 18 May 2013 (UTC)

okay this discussion died :/ what happens now? --Shisma (talk) 09:58, 27 May 2013 (UTC)

It is an interesting idea but I think that it is not top-priority. This property probably deserves a RfC at some point, as it could potentially be applied to a few million items, and would probably cause the same amount of discussion as main-type=term does. --Tobias1984 (talk) 10:04, 27 May 2013 (UTC)

• Broadly  Support, but this will definitely need a lot of fine-tuning. There are some cases where it would be downright misleading to list a bunch of properties for someone and neglect to say that they're fictional. — PinkAmpers&^{(Je vous invite à me parler)} 14:58, 27 May 2013 (UTC)

 Comment Please see my comment to the discussion of the property is fictional. --Paperoastro (talk) 22:02, 27 May 2013 (UTC)

•  Support, agree with PinkAmpersand. --NaBUru38 (talk) 02:33, 30 May 2013 (UTC)
•  Oppose Definition of the truth is based on personal opinion and Wikidata can not deal with that. Wikidata doesn't have to judge of the truth of something orproviding a possible assessment of what is right or not. Snipre (talk) 15:38, 8 June 2013 (UTC)

• As stated above, "truth value" is not the right term, but I do not think that makes the property discussed above irrelevant. --Zolo (talk) 05:29, 9 June 2013 (UTC)

•  Oppose It is important to understand that the main type person (Q215627) does not claim the subject to be a human. This problem can be already solved using instance of (P31). For example, Mickey Mouse (Q11934) is an instance of (P31) fictional character (Q95074). I'd suggest that all humans should have the claim instance of (P31) human (Q5). Danrok (talk) 23:42, 8 June 2013 (UTC)

• Yes, I think main types should be left alone are they work so badly. In many cases P31 could indeed be used but, without this qualfier, things may be a bit complicated. Mickey Mouse is an instance of character and an instance of mouse (or an instance of fictional mouse ?). To be consistent we should say that Sherlock Holmes is an in instance of character + an instance of homo sapiens, otherwise, we would not be sure that he is not a fictional mouse.
• There are also cases where P31 do not appear to be relevant. For instance London: founded by (P112): Q994929 (truth value: myth). We could argue that given the source provided, it is obvious that it is a myth, but I do not think it is true (and at the very least, it is too complex for most readers and machines to infer by themselves). --Zolo (talk) 05:29, 9 June 2013 (UTC)

Brutus of Troy, and many others could be claimed to be part of folklore. Brutus of Troy (Q994929) Danrok (talk) 12:41, 9 June 2013 (UTC)

You mean that we can know that Brutus of Troy is not the real founder of London because we have somewhere part of (P361) folklore or instance of (P31) folkloric character ? That seems very complicated to achieve machine readability this way. For the reasons outlined above, I really think that we need something more specific, at least for fictional characters, and imo for some other cases. I am not sure this should be this property, but I am fairly sure the current property structure does not fit well for that. -Zolo (talk) 17:57, 9 June 2013 (UTC)

Snipre: Wikidata doesn't deal with truth. We deal with claims made in sources. If there is one source which claims Brutus of Troy (Q994929) is mythical and another source which says he is historical and a third which says his truth value is disputed then we just record all three of these statements. Filceolaire (talk) 21:37, 9 June 2013 (UTC)

•  Oppose per Danrok. Emw (talk) 15:47, 9 June 2013 (UTC)
•  Support provided permitted values are expanded to include include 'historic' and 'disputed'. Filceolaire (talk) 21:37, 9 June 2013 (UTC)

 Question Cannot instance of (P31) be used instead? For instance "instance of": fictional object, fictional war, religious statement, etc. I fear that that creating a property like this could lead to yet another controversy like with P107 (P107).--Micru (talk) 01:14, 8 July 2013 (UTC)

•  Oppose as Micru: "instance of" can by used. --Nightwish62 (talk) 19:12, 8 July 2013 (UTC)

 Not done No consensus, see above. John F. Lewis (talk) 22:04, 1 August 2013 (UTC)

Address / Adresse / Adresse

   Not done

Description	Address
Data type	string / Multilingual texts / item-invalid datatype (not in Module:i18n/datatype)
Template parameter	en:Template:Infobox building / fr:Modèle:Infobox Monument
Example 1	MISSING
Example 2	MISSING
Example 3	MISSING
Proposed by	Ayack (talk) 10:50, 4 February 2013 (UTC) (converted to property proposal on 13:23, 19 May 2013 (UTC), see comment below)

 Support --Чаховіч Уладзіслаў (talk) 15:49, 10 February 2013 (UTC)

unsure, especially about the data structure. We may not need to translate an address from German to Italian, but we need to translate it from Japanese to English. We could probably make use of the regular structure of an address (like Street, number of building, ZIP code), but it is place-dependent. See alsocommons:Template:Building address. --Zolo (talk) 10:02, 11 February 2013 (UTC)

 Question You mentioned multilingual texts as a datatype. Are addresses really translated? An address is something regional, I would say. --Faux (talk) 19:23, 18 February 2013 (UTC)

 Support The property itself --Faux (talk) 19:23, 18 February 2013 (UTC)

 Oppose We've got location & coordinates. --Kolja21 (talk) 17:43, 19 February 2013 (UTC)

From my experience with the current location features available (Google Maps, Open Street View, ...) not all coordinates can be mapped to the real address. Additionally not all parts of the world are mapped so far. --Faux (talk) 17:51, 20 February 2013 (UTC)

No, Google is not a good source, not for coordinates and not for addresses. I've detected many mistakes when I have looked into pages with geocords from Google. Swedish SPAR is an extremly good source, but it is not free or even public and it only cover Sweden. -- Lavallen (block) 18:02, 15 April 2013 (UTC)

 Comment I'd suggest "street name" only, at least to begin with. Streets have articles on WP. Can't be calculated using geo coords because a building may be on several streets, but usually only one street is used in the formal address. Danrok (talk) 18:05, 24 February 2013 (UTC)

 Comment in some cases structures are located in notable parks, plazas, squares and such. That could work, too. Shawn in Montreal (talk) 03:54, 1 March 2013 (UTC)

 Support as in normal addresses, describing road, number and location. There's P:P131 for the closest administrative unit. --NaBUru38 (talk) 20:34, 1 March 2013 (UTC)

•  Support. Not at all the same as the coordinates (which, however, should also be supplied, although via a different property).—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); March 8, 2013; 19:29 (UTC)
•  Support. Ayack (talk) 12:46, 29 March 2013 (UTC)
•  Support shouldn't this be a string type? --  Docu  at 17:31, 7 April 2013 (UTC)
  • I updated the above proposal accordingly and converted it to use Template:Property documentation. --  Docu  at 13:23, 19 May 2013 (UTC)
•  Support creation, but only if it's a multilingual datatype (so not a string). The reason I think this datatype should be multilingual is that in some cities street names are available in multiple languages. For example in Brussels most streets have a French and Dutch name. Multichill (talk) 11:55, 15 June 2013 (UTC)
•  Comment Right now, I'm about to create new items for Swiss cultural property of regional significance. However, I'm not able to add the street information, since this property still doesn't exist. It's really annoying, because it means, I either wait, or I must edit all items a second time later when the property exist.

So, we all agree that we need this property. There was only one oppose voting. But we aren't agree with the question which datatype it should have. Initially it was proposed to use multilingual datatype. Then it was changed to String. However, some here still think the multilingual datatype fits better. And it's really true: there are cities (e.g. Brussels) in which streets have more than one name. The problem is, that the multilingual datatype isn't on the horizon. Lydia told us that the next datatype is URL and the development for it could take up to August. There is no information in which order the other datatypes are develop so I think it take months still we've the multilingual datatype.

Normally I'm not a big fan of using 'wrong' datatype just because the right one doesn't yet exist. But I think it wouldn't be a big task to 'convert' the string datatype to the multilingual datatype later. I don't think there would be a conversion technic which would do this by a 'built-in' function on the Wikidata server side. But I think a bot/script could copy all values from one property to another.

Another solution could be, we split the address in street name and house number. For the street name we take the item datatype, and for the house number the string datatype. So we would have to create items for every street we'd like to use. I think this wouldn't be a problem since many streets have an item anyway. It even give us the possibility to query all (notable) buildings of a specific street (e.g. Wikipedia:Broadway_(New_York_City)#Buildings). This wouldn't be possible when using the string or multilingual datatype.

So, I think we should make a vote about the datatype.

String (available)

•  Oppose --Nightwish62 (talk) 09:24, 23 June 2013 (UTC)
•  Support but add qualifiers to show the street name, number and the administrative unit it is located in semantically as well as the address as a string. Filceolaire (talk) 12:16, 16 July 2013 (UTC)
•  Support --Pasleim (talk) 17:53, 28 July 2013 (UTC)

Multilingual (not yet available)

•  Oppose --Nightwish62 (talk) 09:24, 23 June 2013 (UTC)

Item & String (Split in street name and street number)

•  Support --Nightwish62 (talk) 09:24, 23 June 2013 (UTC)

Comments

• I didn't notice earlier that there was a proposal (see right below this one) already which is very similar to the third option here. --Nightwish62 (talk) 09:37, 23 June 2013 (UTC)

 Not done - meanwhile located on street (P669) and house number (P670) has been created, which are designed to use for address --Nightwish62 (talk) 22:10, 1 August 2013 (UTC)

Orbital elements / Орбитальные элементы

   Not done

Description	наклонение, период обращения, апоцентр, перицентр и т. д.
Data type	вопрос для обсуждения-invalid datatype (not in Module:i18n/datatype)
Template parameter	ru:Шаблон:Космический аппарат, ru:Шаблон:Космическая экспедиция параметры орбиты en:Template:Infobox spacecraft has 15 entries under Orbit data en:Template:Infobox_space_mission apogee, perigee, apolune, perilune, orbital period, orbital, orbital altitude, orbital inclination.
Domain	космические аппараты
Example 1	MISSING
Example 2	MISSING
Example 3	MISSING
Source	сайт NASA, launchlog, карточки в статьях, список запусков и т. д.
Robot and gadget jobs	Могу настроить бота на проверку значения свойства по какому-либо источнику, например, launchlog-у.
Proposed by	— Ivan A. Krestinin (talk) 19:20, 1 April 2013 (UTC)

Сложный вопрос, с одной стороны эти цифры напрашиваются в Викиданные, с другой - непонятно что указывать для маневрирующих аппаратов. Также под вопросом набор параметров, можно максимум (например, TLE), а можно ограничиться четырьмя основными (наклонение, период, апоцентр, перицентр). Также вместо создания новых свойств можно попытаться использовать то, что есть/будет для орбит планет. — Ivan A. Krestinin (talk) 19:20, 1 April 2013 (UTC)

English wikipedia has in en:Template:Infobox spacecraft orbit_reference, orbit_regime, semimajor_axis, eccentricity, orbit_inclination, orbit_altitude, apoapsis, periapsis, orbital_period, longitude, repeat_interval, orbits_daily, repetitivity, orbit_swath and orbit_crossing. No article uses all parameters but these are all numbers with different units, some are time, some are angles. One important thing is that these are a snapshot at a particular moment in time. The parameters vary - spacecraft drift, move etc. Secretlondon (talk) 13:52, 27 April 2013 (UTC)

We need to split these out. Longitude and orbit type are elsewhere here. Orbital eccentricity, Orbital period, Orbital inclination, Semi-major axis are in pending. Secretlondon (talk) 18:07, 27 April 2013 (UTC)

 Oppose This needs splitting up. I'd ideally like them to be qualified so that you cannot have a figure without giving a date when it was valid. Which do we need? apoapsis and periapsis - any more? Secretlondon (talk) 15:52, 28 April 2013 (UTC)

 Comment I've copied the Astronomy task force's list of orbital properties to Wikidata:Space task force. Do we need any more? Secretlondon (talk) 16:22, 28 April 2013 (UTC)

 Oppose--definitely should not have this list of data elements without a required qualifier for when these elements might continue to be valid. This will be a bit messy for anything in low-Earth orbit--although a bit easier for MEO, HEO, Heliocentric, Areocentric orbits, it still remains the case that ANY orbital elements are merely a snapshot at a given time (e.g., {{asof|yyyy|mm|dd}} template might be used to qualify the date at which the "snapshot" was taken (calculated, by some ostensibly reliable source). But none of these data elements are indefinitely "good data." The physics of the situation just don't work that way. Cheers. N2e (talk) 02:24, 10 June 2013 (UTC)

 Comment The astronomy project have defined a set, which we can use or not use. I agree things need qualifiers, but that doesn't mean they shouldn't exist. Secretlondon (talk) 19:29, 10 June 2013 (UTC)

 Not done --Tobias1984 (talk) 22:19, 1 August 2013 (UTC)

asteroid family (en) / семейство астероидов (ru)

   Done: asteroid family (P744) (Talk and documentation)

Description	population of asteroids that share similar proper orbital elements
Data type	Item
Template parameter	family of asteroids is indicated in the text of articles
Domain	asteroid items (main type - place)
Example	221 Eos (Q148187) => Eos family (Q2085085)
Source	asteroid family (Q249083)
Proposed by	--Art-top (talk) 21:30, 20 July 2013 (UTC)

Discussion

 Comment - Couldn't 221 Eos (Q148187) be an instance of Eos family (Q2085085)? --Tobias1984 (talk) 21:33, 20 July 2013 (UTC)

 Support - this property complete the "trio" of asteroid classifications with minor planet group (P196) and "asteroid class type". @Tobias1984: you are right, but in my opinion you have found a limit of a "pure" instance of classification: in fact 221 Eos (Q148187) can be also an instance of Amor asteroid (Q1048303) (classification used with property P196), and also an instance of T-type asteroid (Q2583884) (see the proposal above). So we have three parallel system of classifications! In my opinion only with three different property we can solve the situation (or instance of plus qualifiers? ;-) ) --Paperoastro (talk) 21:50, 20 July 2013 (UTC)

 Support — Ivan A. Krestinin (talk) 19:51, 21 July 2013 (UTC)

 Done --Tobias1984 (talk) 22:20, 1 August 2013 (UTC)

Short name

   Done: no label (P743) (Talk and documentation)

Description	In infoboxes, navboxes and others, the full names are sometimes not used on Wikipedia. We write "County: [[Adair County, Missouri|Adair]]" instead of "County: [[Adair County, Missouri|Adair County]]". We have in such cases to use something else than the label in the second part of the link, after the |. See: sv:Mall:Missouri for the use in a template.
Data type	String
Template parameter	any
Domain	any
Example	"Adair" for Adair County, Missouri. You have to add a qualifier for the language.
Robot and gadget jobs	possible
Proposed by	Lavallen (block)

Discussion

In some languages and in some subjects, it is not as simple, as only removing the "county"-part from the label. The name "Adair county" can in some languages have grammatical parts that isn't appropriate in the context. For example "Falu" as short for Falu kommun would give associations to paint and sausage, instead of "Falun", the capital of Falu kommun. Also statistical organisations uses the "short name" in their reports. Observe that I do not regard this as "important information" for Wikidata. Instead I propose it for convenience when using Wikidata to create templates on Wikipedia. -- Lavallen (block) 13:09, 22 May 2013 (UTC)

Hm, wouldn't this pretty much always be the same as the label? When would a longer name be appropriate for the label? Shouldn't "Adair" be the label for Q346925 anyway? --Yair rand (talk) 21:00, 22 May 2013 (UTC)

I think "Adair" is appropriate when you write "County: Adair", as in sv:Mall:Missouri, but not always otherwise. Sometimes is "Municipality: Vetlanda" not enough information since there is at least five municipalities with the name "Vetlanda": "Vetlanda kommun", "Vetlanda landskommun", "Vetlanda stad", "Vetlanda köping" and "Vetlanda municipalsamhälle" (no item yet). Add to that the statistical urban area of Vetlanda who several wp-projects cannot separate from the municipalities. "kommun/landskommun/stad/köping/municipalsamhälle" are a part of the name, and should not be removed from the label. It would be like only having Barack as label. Sometimes "Barack" is enough, but most often not. "Municipality: Vetlanda" is enough information as of 2013, but there has during 1887-1952 coexisted at least two municipalities with the name "Vetlanda".

This is not isolated to a dark place deep into the the history of Småland. I have seen the same thing when I have worked with Poland. Gmina Kamienna Góra and Miasto Kamienna Góra are both municipalties. They are not of the same kind of municipalities, but they coexist as neighbours today, and they have partly the same name. In contrast to the Swedish, the Polish habit is not to write "Miasto Kamienna Góra" in the label, so the label is there only "Kamienna Góra". But they have not that habit for the rural Gmina. -- Lavallen (block) 07:34, 23 May 2013 (UTC)

 Support - As I currently understand Wikidata we anyway need an "official name" property for most items because the labels of the Q-items do not support sources. --Tobias1984 (talk) 07:51, 23 May 2013 (UTC)

Yes, the municipality of Stockholm and some other today uses for themself another name than the official as a trademark. The label will therefor be a battlefield for editwars, but the short and official name will not change because of that. -- Lavallen (block) 08:32, 23 May 2013 (UTC)

proofread / Korrektur gelesen /

   Not done

Description	how many times a property has been proofread (used as qualifier for other properties)
Data type	Number (not available yet)
Domain	qualifier that can be used for all properties
Allowed values	integer >= 1
Example	For P:P107 => Q215627 in Q3903129: 1 (yes, I just confirmed that this item is about a person)
Robot and gadget jobs	A gadget for incrementing the number by 1 (and possibly checking that this user didn't increment it in the past) would be useful.
Proposed by	132.230.1.28

Discussion

Properties imported by bots should be considered like the OCRed texts in Wikisource: In most cases they are correct, but there will be errors. To really trust the data it must be proofread and verified by humans. Wikipedia communities could decide on the number of reviewers needed to trust the data enough to transclude it (e.g. they could only transclude data that has been proofread at least 2 times). 132.230.1.28 07:49, 24 May 2013 (UTC)

Maybe we can use badges for that. If an article is proofread 2 times it gets badge "proofread" for example. --Pyfisch (talk) 11:03, 26 May 2013 (UTC)

 Not done statements don't has necessary to be true (see [5]), therefore there is nothing to proofread. Instead that, we'll have a ranking system which make certain statements preferred over others --Nightwish62 (talk) 22:29, 1 August 2013 (UTC)

Key event

   Not done

Description	significant events associated with the subject, opening date, premiere date for a movie, in service (aircraft), production started (manufacturing), ship naming and launching, etc.
Data type	Item
Template parameter	many infoboxes have this type of information
Domain	all domains
Allowed values	item which describes the type of event, e.g. première (Q204854). We can just create suitable items if none exist.
Example	Friedland (Q4492725) key event ship launching (Q596643) date 4 March 1840 (note: we'd need a generic date property which could be used as a qualifier).
Source	various
Proposed by	Danrok (talk) 15:57, 23 May 2013 (UTC)

Discussion

•  Comment The idea is to avoid creating many date properties. Danrok (talk) 15:59, 23 May 2013 (UTC)

Can be used for people: birth date and death date. Danrok (talk) 16:01, 23 May 2013 (UTC)

•  Comment I like this event-based idea. Some of the advantages are imo
  • we save at least hundreds of "date of..."-properties that noone can keep track of; (have a look at Property_proposal/Place for an (incomplete) list just for buildings)
  • still date properties will always be missing in some areas, and people will then (miss)use other properties, so this is more precise;
  • hundreds of properties will make it especially difficult for beginners while this approach is very simple and intuitive;
  • it makes it possible to create an entire timeline of an item that includes all important events;
  • Further information can be added to the event, like the place, e.g. (This way making place of death and place of birth obsolete, btw). Again, we would save hundreds of properties (place of construction, place of premiere, place of launch, etc.) This is also more logical as place of birth and date of birth describe the same thing.

It would also have a great potential of application, like autogenerated timelines for topics like World War II or the exploration of North America. Combined with geo-coordinates, you could easily generate a map of all the places Mozart stayed at, or a map of Magellan's voyage.

At the same time, I'm not sure if the datamodel is ready. It seems some kind of a workaround, as the value actually is more of a criterion to further specify the property, and only the qualifiers contain the important data - a person's birth or death alone is not a valuable piece of information. In addition, at least some data would be redundant, e.g. if someone was coach of a football club, you would have to add this as an event as well as occupation (P106). And if you would indeed try to create a timeline of Magellan's voyage, you'd have to create new items like "did this" and "that happened", just in order to describe the events; certainly not a good solution. So we should think this through and find the the best way to implement it.--Kompakt (talk) 06:53, 27 May 2013 (UTC)

It won't be more simple: instead of looking for the correct property, contributors will have to look to find the appropriate item. Or you will need qualifiers and for that you will create properties. Snipre (talk) 12:25, 27 May 2013 (UTC)

You'd only need general qualifiers for "date" and "place". The items are already much more fine-grained than the properties are, and very probably ever will be. So if someone wants to enter the date of renovation for a building, he'd enter a new event, value "Renovation" and qualifier date = xx/yy/zzzz. It's as simple as that, no need to search through all properties to finally find something like "date of keel laying (can also be used as date of reparation, date of premiere, date of reelection, date of rediscovery.... and date of renovation)". I see the problem that we either create hundreds of "date-of" properties, or we create such monster properties that contain dates from lots of different topics that are completely unrelated to each other. Both options don't look very attractive, and even taken into consideration that you might achieve some sort of trade-off between the two in reality, I think it's still inferior to the proposed idea.--Kompakt (talk) 15:29, 27 May 2013 (UTC)

STOP before any creation: There are several proposal for buildings and for ships for the same topics. Please first merge all proposals and then once the proposals are discussed in details we can go to the creation.

• Wikidata:Property_proposal/Place#Key_dates_for_buildings:groundbreaking
• Wikidata:Property_proposal/Place#Key_dates_for_buildings:start_date
• Wikidata:Property_proposal/Place#Key_dates_for_buildings:completion_date
• Wikidata:Property_proposal/Place#Key_dates_for_buildings:opened_date
• Wikidata:Property_proposal/Place#Key_dates_for_buildings:inauguration_date
• Wikidata:Property_proposal/Place#Key_dates_for_buildings:renovation_date
• Wikidata:Property_proposal/Place#Key_dates_for_buildings:demolition_date
• Wikidata:Property_proposal/Place#Key_dates_for_buildings:destruction_date
• Wikidata:Property_proposal/Term#order_date
• Wikidata:Property_proposal/Term#launch_date
• Wikidata:Property_proposal/Term#keel_laid
• Wikidata:Property_proposal/Term#completion_date Snipre (talk) 08:06, 27 May 2013 (UTC)

•  Comment – My first thought on this was that it is a very nice database design to collect all events with one property, and to tie together time and place as qualifiers for the same claim. However on further thought, I am not sure that it is practical. To find e.g. the birthday of someone, you would have look though all recorded events for the person to find the birth event. Then you would have to look though all qualifiers for the event to find the date. That would be rather complicated and a lot of code for something you could have done much more easily with a separate birthdate property. Byrial (talk) 10:30, 27 May 2013 (UTC)

  If you have to create qualifiers for death and for birth beside the property key event you won't simplify the situation based on a date of death and date of birth. Snipre (talk) 12:28, 27 May 2013 (UTC)

  I think we have to treat two kinds of events separately here:

  • One is when the event's value is the same in every item. Like your example of a query for date of birth, where the event's value would be parturition (Q34581), and I don't think this would be much of a problem. Having a single property for date of birth, your query probably looks something like "give me the property_value from item x where property = dateOfBirthPropertyId". With the event property, it would look like "give me the qualifier_value from item x where property = eventPropertyId and property_value = 34581 and qualifier = dateQualifierId". It would be a query that includes a certain qualifier, yes, but that's hardly something out of the ordinary. We'll need these kind of queries either way, and probably more often than not. I don't know the exact query interface yet, but still: if this will be a complicated query, then many of the queries will be complicated.
  • The other one is when the event's value differs from items, and even within an item. Like the jobs of a person that we would normally put under occupation (P106). If you want to get the jobs of a person, and you have this under one single property, you can simply query that property. If you have it just generally under "events", it's not that simple to find the jobs; you'd probably have to go up the inheritance tree for each event until you find something like "instance-of profession". This would indeed make it complicated, and probably time-consuming.--Kompakt (talk) 15:30, 27 May 2013 (UTC)

  Please give a real example. So for a person we have claim based on item property Key event with value parturition (Q34581), then we will have a property date as qualifier with a date value. The constraint is to be sure that all contributors will use the same item for indicating the birth date because if one uses item Birth (Q2778160) instead of parturition (Q34581), your system is completly out. At the end you have less properties but you don't simplify your system because contributors need to know which item to use instead of which property. I have to say that I prefer property because looking for a correct property in a set of 2000 properties is simpler than looking for the correct item in a set of 10-20 millions items. Snipre (talk) 15:41, 27 May 2013 (UTC)

•  Comment This property wouldn't have to prevent the creation of other date properties like birth date. It is probably best that birth date and death date have their own properties. Danrok (talk) 19:26, 27 May 2013 (UTC)

---

•  Comment General discussion at Wikidata:Requests for comment/Time DataType Properties. —★PοωερZ_talk 13:04, 30 May 2013 (UTC)
•  Oppose, please see here. --Nightwish62 (talk) 17:33, 30 May 2013 (UTC)
  • Example for one of the events in the list above (renovation date), what if the roof was renovated 1955 and the entrance hall 1970? You can't add this information when you already use the qualifier for the date. --Nightwish62 (talk) 17:37, 30 May 2013 (UTC)

Those would be 2 key events, so you'd enter 2 instances of "renovation" as key events, with date qualifiers (start/end) and an "applies to part" qualifier indicating the roof, or whichever part it was. Danrok (talk) 17:46, 30 May 2013 (UTC)

You're right. --Nightwish62 (talk) 19:47, 30 May 2013 (UTC)

•  Support and  Comment I think we need both "key event of " and "key event". For the first one it will be like person <key event of> birth (with some qualifiers for date and place) . There will also be something like World War II (Q362) <key event> Attack on Pearl Harbor (Q52418) and World War II (Q362) <key event> invasion of Poland (Q150812)(with qualifier <key event of> start)--凡其_Fanchy 06:27, 3 June 2013 (UTC)
•  Weak support. I share Byrial's concerns, but there are so many types of events that other solutions seem to be worse. --Zolo
•  Info Unless there are strong objections or good alternative proposals, I will create this property in a few days. We really need to have something. --Zolo (talk) 10:29, 3 July 2013 (UTC)

  We already have something so before creating a new system for date structure we have to be sure that we will select this new system for all dates. In order to be coherent we have to use only one system and if you create this property we have to delete all current date properties. This is not a simple property, this is a new concept for dates structure. Be sure that the community agree to use this system and is ready to delete the current properties. Snipre (talk) 19:19, 3 July 2013 (UTC)

  "delete the current properties"? I really hope you mean transfer into the new system in some way, and not just delete existing date properties and their value? --Nightwish62 (talk) 20:40, 4 July 2013 (UTC)

• I still believe it's better to reserve qualifier for things we really need it. If we choice the key-event-concept we already use the qualifier in every statement. --Nightwish62 (talk) 20:55, 4 July 2013 (UTC)

  A statement can have multiple qualifiers, though. What do you mean by "we already use the qualifier in every statement"? --Yair rand (talk) 21:50, 4 July 2013 (UTC)

 Not done This may be a controversial or in fact, messed up decision so any admin is free to create this property but let me explain why I am not doing this even though there is 50% approval (which also, is low not consensus). The property is an item property meaning the value will be something like death and not the date of death, more appropriate time properties will be able to address the situation better and more direct. In addition to my knowledge there is no 'time' property thus making this redundant to itself. Finally, this is far far too ambiguous. John F. Lewis (talk) 22:30, 1 August 2013 (UTC)

Comment by Filceolaire added after the discussion closed: --Tobias1984 (talk) 21:53, 5 August 2013 (UTC)

•  Strong support. To respond to the comments from JFLewis above:
  • The only Oppose above is from Nightwish who follows it up with "you're right" which sounds like he is withdrawing the Oppose. How does no Oppose votes turn into 50% Oppose?
  • 'More direct' time (and location) properties means a special time (and location) property for every type of event. Hundreds of them. With users having to try and find the right one. This is not better.
  • There is a time property. It is point in time (P585).
  • No one else is finding this ambiguous.

Please create this property now. Filceolaire (talk) 20:32, 5 August 2013 (UTC)

I think I will create this property. I am afraid I do not understand the reasons given by John F Lewis. What does "redundant to itself" mean, and why is it ambiguous ? --Zolo (talk) 16:48, 12 August 2013 (UTC)

Unicode representation

   Not done

Description	Unicode character(s) representing the subject.
Data type	String
Template parameter	none that I know of; could be useful for templates, though
Domain	Any topic covered by a Unicode character (i.e. theoretically anything)
Example	Homosexuality → ⚣
Format and edit filter validation	could be checked to make sure values are only one character, I suppose
Proposed by	— PinkAmpers&(Je vous invite à me parler)

Discussion

This is not for items whose subjects are themselves symbols, which are covered under P:P487; rather, it's for cases where a Unicode symbol exists that can represent the subject. While I don't think this is used in any infoboxes, I think it could be quite helpful for some templates (e.g. en:Template:Unichar). Importantly, I propose the following two qualifiers:

— PinkAmpers&^{(Je vous invite à me parler)} 11:51, 27 May 2013 (UTC)

•  Comment Data for these could be extracted from existing Wikipedia redirects; enwiki has many such redirects, e.g. from U+1F489 to Feces. – The preceding unsigned comment was added by 75.142.59.82 (talk • contribs) at 00:42, 8 June 2013‎ (UTC).
  • It's not that simple. en:☼ is a redirect to en:Solar symbol while this property would affiliate it to en:Sun. —★PοωερZ_talk 00:35, 17 June 2013 (UTC)

Denomination

   Not done

Description	Denominationalism is the division of one religion into separate groups, sects, schools of thought or denominations. See Denominationalism.
Data type	Item
Template parameter	"denomination" in en:template:Infobox church
Domain	person, place, organization, event, creative work, term
Example	St Paul's Cathedral (Q173882) => Church of England (Q82708)
Source	External reference, Wikipedia list article (either infobox or source)
Proposed by	Danrok (talk)

Discussion

•  Oppose  Comment religion or worldview (P140) covers the same aspect.--Kompakt (talk) 06:39, 30 May 2013 (UTC)

Religion and denomination are not the same. The Church of England is a denomination, an organization, not a religion. Danrok (talk) 17:16, 30 May 2013 (UTC)

I see... still I'm not sure we need this property. If someone is a member of a religious organization, his religion is determined as well. People tend to enter the denomination for P140, see Margaret Thatcher (Q7416) or Elizabeth II (Q9682). Maybe it would be better to rename it to "denomination"? Another idea would be to use member of (P463). For buildings, the property seems to overlap with owned by (P127). I could be wrong.--Kompakt (talk) 06:51, 31 May 2013 (UTC)

No that won't work. This would be a generic property, not person specific. We need to be able to say that this church building is a Roman Catholic church, for example. So, "member of" is no good for that. Also, some items belong to a religion but not a specific denomination, the Bible is Christianity for example, as is Christmas, Easter, etc. These two things religion and denomination have been mixed up, in many wikipedia infoboxes, so I wouldn't use that as a basis for anything. It's like mixing up ethnicity with nationality. Danrok (talk) 09:14, 7 June 2013 (UTC)

 Not done No consensus plus it can be served by other properties. John F. Lewis (talk)