Wikidata

Wikidata:Property proposal/Archive/11

< Wikidata:Property proposal‎ | Archive
Latest comment: 10 years ago by Zolo in topic Key event
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

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

Latest comment: 10 years ago4 comments3 people in discussion
   Not done
Descriptiontype of railway stations: station, stop punct, crossing loop, block post etc.
Data typeItem
Template parametertype
Domainplace
Allowed valuesrailway station (Q55488), passing loop (Q784159), overtaking station (Q4329090), junction (Q336764), block post (Q350114), railway stop (Q55678)
ExampleVyshneve (Q12089725) => railway station (Q55488), Rasava (Q12146989) => passing loop (Q784159), Tarasivka (Q12160031) => railway stop (Q55678), Potiivka (Q12142918) => junction (Q336764), Varshytsia (Q12087823) => block post (Q350114)
Sourcestation references
Proposed byAhonc (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), junction (Q336764), block post (Q350114), railway stop (Q55678). Maybe in other countries may be additional types.Ahonc (talk) 21:29, 16 May 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

Latest comment: 10 years ago10 comments9 people in discussion
   Not done
DescriptionFor universities: number of students (undergrad/postgrad), staff, motto, president, etc.
Data typeString
Template parameteren:Template:Infobox university
Domainuniversities
ExampleUniversity 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
Sourceen: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 / ...

Latest comment: 10 years ago3 comments3 people in discussion
   Done: voice actor (P725) (Talk and documentation)
DescriptionThe person who dubbed a role in the TV. e.g. Japanese dubber US TV/Film, English dubber for Anime, etc
Data typeItem
Template parameterNot in the info box but can be useful data
DomainMovies
Examplesee below
Proposed byNapoleon.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

Latest comment: 10 years ago4 comments2 people in discussion
   Done: candidate (P726) (Talk and documentation)
Descriptionperson or party listed as an option for office in an election
Data typeItem
Domainindividual elections
Examplew: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 jobsallowed
Proposed byJoshbaumgartner (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)

Latest comment: 10 years ago5 comments4 people in discussion
   Not done
Descriptionthe event practiced from an athlete (for example "long jump" or "100 meters hurdles"
Data typeItem
Template parameter"event" in en:template:Infobox athlete; "specialità" in it:template:Sportivo
Domainperson
ExampleQ5444 => Q624482 OR Q164761 and Q211155
Proposed byYiyi .... (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)
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

Latest comment: 10 years ago7 comments6 people in discussion
   Not done
DescriptionA 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 typeString
Example 1MISSING
Example 2MISSING
Example 3MISSING
SourceSee [1].
Proposed byJanjko (talk) 17:10, 14 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

Latest comment: 10 years ago6 comments4 people in discussion
   Done: no label (P727) (Talk and documentation)
DescriptionEuropeana.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 typeString
Domainpublished works
ExampleGirl with a Pearl Earring (Q185372) <Europeana identifier> 92034/6BD59765E7734AA666431F3021063CA1E3A1D026
Proposed by--Micru (talk) 00:47, 25 June 2013 (UTC)
Discussion

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

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

Music genre / Gattung (Musik)

Latest comment: 10 years ago24 comments15 people in discussion
   Not done
DescriptionMusic genre for artist, musical group, album, single
Data typeItem
Template parameterUsed e.g. in w:Template:Infobox musical artist
Example 1MISSING
Example 2MISSING
Example 3MISSING
Proposed byStryn (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 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)

Latest comment: 10 years ago7 comments7 people in discussion
   Not done
Descriptiondate of the premiere (of an opera, musical, film...)
Data typePoint in time
Domainopera, musical, film...
Example 1MISSING
Example 2MISSING
Example 3MISSING
Proposed byAppo92 (talk) 15:16, 7 February 2013 (UTC)
Discussion

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

provenance event

Latest comment: 10 years ago5 comments3 people in discussion
   Not done
Descriptionprovenance event
Data typeString
Domaincreative work
Allowed valuesname-date-location
Examplehttp://commons.wikimedia.org/wiki/File:Frans_Hals_037.jpg
Sourcehttp://commons.wikimedia.org/wiki/Category:Secretan_sale_1_July_1889
Robot and gadget jobsCould be imported from Wikimedia commons ARTWORK template
Proposed byJane023 (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

Latest comment: 10 years ago5 comments3 people in discussion
   Done: no label (P728) (Talk and documentation)
DescriptionGHS hazard statements + GHS EU hazard statements
Data typeString
Template parameterfr:infobox chimie, en:chembox, de:Infobox Chemikalie
Domainchemistry
Examplesodium azide (Q407577) = H300, H410, EUH032
SourceEU database
Proposed bySnipre (talk) 22:10, 9 July 2013 (UTC)
Discussion:
  • 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

Latest comment: 10 years ago3 comments3 people in discussion
  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

Latest comment: 10 years ago4 comments3 people in discussion
  • 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

Latest comment: 10 years ago3 comments3 people in discussion
  • 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 /

Latest comment: 10 years ago2 comments2 people in discussion

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

Lakes / Seen / lacs

Latest comment: 10 years ago15 comments6 people in discussion

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.
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.
islands_count
total number of islands in the lake
island_names
names of islands in the lake
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

Latest comment: 10 years ago4 comments3 people in discussion

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)

Latest comment: 10 years ago4 comments3 people in discussion
   Not done
DescriptionThe temperature at which a substance melts
Data typeNumber (not available yet)
Template parameter"melting point" in w:Template:Infobox element and w:Template:Chembox
Domainterm
Allowed valuesnumbers
Examplemethane (Q37129)...-182 dichloroacetylene (Q14375558)...-50
Sourcehttp://www.chemspider.com
Robot and gadget jobsBots 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 /

Latest comment: 10 years ago7 comments5 people in discussion
   Not done
DescriptionCharacteristic property of any elementary particle
Data typeNumber (not available yet)
Template parameterde:Vorlage:Infobox Teilchen
Domainparticles
Example 1MISSING
Example 2MISSING
Example 3MISSING
Proposed bySvebert (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

Latest comment: 10 years ago2 comments2 people in discussion
DescriptionDate on which the aircraft entered operational service
Data typePoint in time
Template parameteren:template:infobox aircraft (introduced)
Example<General Dynamics F-16 Fighting Falcon> service entry <17 August 1978>
Proposed byJoshbaumgartner (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

Latest comment: 10 years ago2 comments2 people in discussion
DescriptionDate on which the aircraft retired from operational service
Data typePoint in time
Template parameteren:template:infobox aircraft (retired)
Example<Republic F-105 Thunderchief> service retirement <25 February 1984>
Proposed byJoshbaumgartner (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

Latest comment: 10 years ago5 comments3 people in discussion
   Done: Litholex ID (P731) (Talk and documentation)
Descriptionthe 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 typeString
Template parameternot included in any infobox, but would be a good way of linking to the primary data
Domainterm
ExampleTristel Formation = "2008131" ([4])
Format and edit filter validationI think all of the ids are 7 digit numbers.
Sourcelitholex page: [http://www.bgr.bund.de/DE/Themen/GG-Stratigraphie/LithoLex/litholex_node.html
Robot and gadget jobsgather ids for existing stratigraphic unit items.
Proposed byTobias1984 (talk)
Discussion
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:
--Tobias1984 (talk) 16:28, 25 May 2013 (UTC)

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

BGS Lexicon ID / BGS Lexikon Primärschlüssel

Latest comment: 10 years ago2 comments2 people in discussion
Descriptionthe ID for every stratigraphic unit in England (United Kingdom) given by the British Geological Survey
Data typeString
Template parameternot included in any infobox, but would be a good way of linking to the primary data
Domainterm
ExampleOld Red Sandstone = "ORS" (source),Kellaways Formation = "KLB" (source), London clay = "LC" (source), Oxforc Clay Formation = "OXC" (source).
Format and edit filter validationMost are 3 letter combinations.
Sourcehttp://www.bgs.ac.uk/Lexicon/
Robot and gadget jobsgather 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

Latest comment: 10 years ago2 comments2 people in discussion
   Done: DINOloket ID (P733) (Talk and documentation)
Descriptionthe ID for every stratigraphic unit in the Netherlands given by the Basisregistratie Ondergrond (BRO)
Data typeString
Template parameternot included in any infobox, but would be a good way of linking to the primary data
Domainterm
Format and edit filter validationBreda Formation (Q3266830) = "breda-formation-nuba", Middle North Sea Group (Q2481683) = "middle-north-sea-group-nm"
Sourcehttp://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

Latest comment: 10 years ago35 comments23 people in discussion

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)
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. — ΛΧΣ21 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. --β16 - (talk) 09:20, 24 April 2013 (UTC)
  •   Comment Many surnames have Wikipedia articles. —★PοωερZtalk 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

Latest comment: 10 years ago23 comments16 people in discussion
   Done: given name (P735) (Talk and documentation)
DescriptionThe 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 typeItem
DomainPerson
Proposed by--Wylve (talk) 17:02, 18 February 2013 (UTC)
Discussion
Status report


  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

Latest comment: 10 years ago13 comments7 people in discussion
   Not done
Descriptionnumeral system of the item or property, mainly if not Arabic
Data typeItem
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)
  •   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/в списке

Latest comment: 10 years ago18 comments7 people in discussion
   Not done
Descriptionlist in which the order is given
Data typeItem
Template parameterthere is (in sequences templates)
Domainproperties next and previous
Allowed valuesitems with lists
Examplefor ouverture dance next is allemande in list Baroque suite (the last item is not exact though)
Proposed byInfovarius (talk) 09:45, 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)
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
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.
--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)


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

Cover artist (en)

Latest comment: 10 years ago5 comments3 people in discussion
   Done: cover art by (P736) (Talk and documentation)
DescriptionName of person or team creating album (or single) cover artwork
Data typeItem
Template parameterProposed for en:template:infobox album; to be proposed en:template:infobox single
Domaincreative work/ released recording
Allowed valuesperson or organisation
ExampleThe Wall (Q151114) -> Gerald Scarfe (Q463132)
Format and edit filter validation???
Robot and gadget jobs???
Proposed byAndy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:27, 26 June 2013 (UTC)
Discussion


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

Episode list / Episodenliste / …

Latest comment: 10 years ago13 comments8 people in discussion
   Not done
DescriptionWikipedia-article with the episode list from the television series.
Data typeItem
Template parameteren:template:Infobox television list_episodes
Domainarticles of television series
Allowed valuesLists of television series episodes
ExampleList of The X-Files episodes is an episode list of The X-Files
Sourceen:template:Infobox television
Proposed byCENNOXX (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

Latest comment: 10 years ago7 comments5 people in discussion
Descriptionitems that influenced the other item, or the other way around
Data typeItem
Template parameterinfluences or influenced by e.g. on the en:template:infobox philosopher, but also others
Domainvarious. Persons, ideas, music bands, artistic eras...
Allowed valuesas above
ExampleHeidegger =influenced by=> Aristotle
Proposed byDenny (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)


  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)

Latest comment: 10 years ago10 comments5 people in discussion
   Not done
DescriptionAll 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 typeString
Domainterm
ExamplePM 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 jobsCheck 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)

Latest comment: 10 years ago2 comments2 people in discussion
   Done: ammunition (P739) (Talk and documentation)
Descriptionthe ammunition a gun fires
Data typeItem
Template parameterinfobox weapon in all languages. e.g. english = cartridge
Domainterm
Allowed valuestypes of ammunition
ExampleHeckler & Koch G3 = 7.62×51mm NATO
Robot and gadget jobsgather data from infobox
Proposed byTobias1984 (talk)


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

Formation location

Latest comment: 10 years ago5 comments5 people in discussion
DescriptionLocation where a group or organization was formed
Data typeItem
Template parameterMultiple, including foundation in en:Template:infobox company
DomainAny group (company/organization/band/etc.)
Allowed valuesItem (most specific location item that can be sourced)
ExampleBirmingham Small Arms Company → Gun Quarter, The Beatles → Liverpool, England, etc.
Sourceen:Template:infobox company, etc.
Proposed bySuperm401 - 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)


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

playing hand (en) / Spielhand (de)

Latest comment: 10 years ago4 comments4 people in discussion
   Done: playing hand (P741) (Talk and documentation)
Descriptionthe hand(s) a tennis player uses for his strokes
Data typeItem
Template parameter"plays" in en:template:Infobox tennis biography
Domaintennis players
Allowed valuesleft-handed, right-handed, double-handed backhand, double-handed forehand
ExampleRafael Nadal (Q10132) => left-handedness (Q789447) + "double-handed backhand" (this item has yet to be created)
Proposed byKompakt (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)


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

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

Latest comment: 10 years ago14 comments10 people in discussion
   Done: pseudonym (P742) (Talk and documentation)
DescriptionThe pseudonym used by someone or by which this person is universally known.
Data typemonolingual-text string-invalid datatype (not in Module:i18n/datatype)
Domainpersons
Allowed valuestype of linked items, restrictions on the values
ExampleAntonio Arias Bernal, known as "El Brigadier"; Bud Spencer, pseudonym for Carlo Pedersoli; ...
SourceExternal reference, Wikipedia list article
Proposed bySannita - not just another it.wiki sysop 14:15, 23 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)


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

Translated into / ? / ? /? / OTHERS

Latest comment: 10 years ago4 comments4 people in discussion
   Not done
Descriptionlanguages the original book translated into.
Data typeItem
Template parametersometimes used instead of Translator as in example below.
Domainbooks
Allowed valuesname of the languages
Examplew:en:The Alchemist (novel), in infobox, shows translated into 56 languages, we can list them here.
Sourcew:en:Template:Infobox book have translator but we can list multiple languages
Robot and gadget jobsdon'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

Latest comment: 10 years ago25 comments6 people in discussion
   Not done
DescriptionMedia files depicting shield designs formerly used on the highway.
Data typeCommons media file
DomainPlaces (roads)
ExampleFor 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 / регионы-побратимы

Latest comment: 10 years ago4 comments4 people in discussion
   Not done
DescriptionSomething like Property:P190 (twin city)
Data typeString
Domainplace
ExampleJeju Province => Hainan_Province
SourceExternal 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

Latest comment: 10 years ago40 comments18 people in discussion
   Not done
Descriptionstates whether an item refers to something that exists in the real World or to some fictional thing
Data typeboolean-invalid datatype (not in Module:i18n/datatype)
Allowed valuesTrue, False, perhaps a few others
ExampleBrainy 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)
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οωερZtalk 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οωερZtalk 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)

  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

Latest comment: 10 years ago23 comments13 people in discussion
   Not done
Descriptionstate to what extent an item is true
Data typeItem
Exampleluminiferous 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)

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)
  Comment Please see my comment to the discussion of the property is fictional. --Paperoastro (talk) 22:02, 27 May 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)
  • 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)
  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)


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

Address / Adresse / Adresse

Latest comment: 10 years ago22 comments14 people in discussion
   Not done
DescriptionAddress
Data typestring / Multilingual texts / item-invalid datatype (not in Module:i18n/datatype)
Template parameteren:Template:Infobox building / fr:Modèle:Infobox Monument
Example 1MISSING
Example 2MISSING
Example 3MISSING
Proposed byAyack (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)
  •   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)
Multilingual (not yet available)
Item & String (Split in street name and street number)
Comments

  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 / Орбитальные элементы

Latest comment: 10 years ago9 comments4 people in discussion
   Not done
Descriptionнаклонение, период обращения, апоцентр, перицентр и т. д.
Data typeвопрос для обсуждения-invalid datatype (not in Module:i18n/datatype)
Template parameterru:Шаблон:Космический аппарат, ru:Шаблон:Космическая экспедиция параметры орбиты
Domainкосмические аппараты
Example 1MISSING
Example 2MISSING
Example 3MISSING
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)

Latest comment: 10 years ago5 comments4 people in discussion
Descriptionpopulation of asteroids that share similar proper orbital elements
Data typeItem
Template parameterfamily of asteroids is indicated in the text of articles
Domainasteroid items (main type - place)
Example221 Eos (Q148187) => Eos family (Q2085085)
Sourceasteroid 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

Latest comment: 10 years ago5 comments3 people in discussion
   Done: no label (P743) (Talk and documentation)
DescriptionIn 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 typeString
Template parameterany
Domainany
Example"Adair" for Adair County, Missouri. You have to add a qualifier for the language.
Robot and gadget jobspossible
Proposed byLavallen (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 /

Latest comment: 10 years ago3 comments3 people in discussion
   Not done
Descriptionhow many times a property has been proofread (used as qualifier for other properties)
Data typeNumber (not available yet)
Domainqualifier that can be used for all properties
Allowed valuesinteger >= 1
ExampleFor P:P107 => Q215627 in Q3903129: 1 (yes, I just confirmed that this item is about a person)
Robot and gadget jobsA gadget for incrementing the number by 1 (and possibly checking that this user didn't increment it in the past) would be useful.
Proposed by132.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

Latest comment: 10 years ago27 comments12 people in discussion
   Not done
Descriptionsignificant events associated with the subject, opening date, premiere date for a movie, in service (aircraft), production started (manufacturing), ship naming and launching, etc.
Data typeItem
Template parametermany infoboxes have this type of information
Domainall domains
Allowed valuesitem which describes the type of event, e.g. première (Q204854). We can just create suitable items if none exist.
ExampleFriedland (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).
Sourcevarious
Proposed byDanrok (talk) 15:57, 23 May 2013 (UTC)
Discussion
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.
  •   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)
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

Latest comment: 10 years ago3 comments3 people in discussion
   Not done
DescriptionUnicode character(s) representing the subject.
Data typeString
Template parameternone that I know of; could be useful for templates, though
DomainAny topic covered by a Unicode character (i.e. theoretically anything)
ExampleHomosexuality → ⚣
Format and edit filter validationcould 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:

Unicode hex value
   Not done
Descriptionqualifier for Unicode representation
Data typeString
Allowed valuesshould be formatted just as a hex value, not as U+0000 or &#x0000;
ExampleHomosexuality → ⚣ → 26A3
Proposed by — PinkAmpers&(Je vous invite à me parler)
Unicode decimal value
   Not done
Descriptionqualifier for Unicode representation
Data typeString
Allowed valuesshould be formatted just as a decimal value, not as U+0000 or &#0000;
ExampleHomosexuality → ⚣ → 9891
Proposed by — PinkAmpers&(Je vous invite à me parler)

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

Denomination

Latest comment: 10 years ago4 comments2 people in discussion
   Not done
DescriptionDenominationalism is the division of one religion into separate groups, sects, schools of thought or denominations. See Denominationalism.
Data typeItem
Template parameter"denomination" in en:template:Infobox church
Domainperson, place, organization, event, creative work, term
ExampleSt Paul's Cathedral (Q173882) => Church of England (Q82708)
SourceExternal reference, Wikipedia list article (either infobox or source)
Proposed byDanrok (talk)
Discussion
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)

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/Archive/11&oldid=598958393"