Wikidata

Wikidata:Property proposal/Archive/4

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

Generic / Allgemein / Général

list of

   Done: is a list of (P360) (Talk and documentation)
Descriptionproperty aims to identify the subject of lists and items providing interwikis to lists at Wikipedia
Data typeItem
Domaine.g. items with interwikis to (en) pages named "List of" etc.
Examplelist of popes "list of" pope
Proposed bySee Wikidata:Project_chat/Archive/2013/03#What_to_do_with_lists.3F

 – The preceding unsigned comment was added by Docu (talk • contribs) at 21:28, 24 March 2013 (UTC).

  Support I hope this can be applied to all lists, not just those with interwiki links titled "List of [...]". (E.g. Madonna videography, ISO 3166-1, w:Mark of the Year.) --Avenue (talk) 14:25, 26 March 2013 (UTC)
  Done Property:P360. --  Docu  at 04:04, 27 March 2013 (UTC)

part of / teil von / fr / Часть

Status:    Done

→ Property:P361

Infovarius (talk) 11:58, 13 March 2013 (UTC)

  Info not sure if this is redundant to P:P279 or not. Perhaps useful--Svebert (talk) 19:51, 15 March 2013 (UTC)
I just encountered two items which are suitable for the "part of" relation: Chinese New Year and East Asian New Year. Both P:P31 and P:P279 can't apply to this example because neither "Chinese New Year" nor "East Asian New Year" is a class. --Stevenliuyi (talk) 21:44, 15 March 2013 (UTC)
There is no article about East Asian New Year in any language I understand, so I can only guess: East Asian New Year is the class/group of all New Years in East Asia. Therefore Chinese New Year “is an-instance“ of Asian New Year, thus P:P31 should be used--Svebert (talk) 10:36, 16 March 2013 (UTC)
No, East Asian New Year isn't a class, just like you can't say "China is an instance of Asia". --Stevenliuyi (talk) 14:13, 16 March 2013 (UTC)
  Support The “China is an instance of Asia“ example is a very good to make your point. Now I think “Part of“ is a good property!--Svebert (talk) 15:23, 16 March 2013 (UTC)
By "part of" I don't mean "subclass of" which is for P31. See example in the form. Infovarius (talk) 13:43, 16 March 2013 (UTC)
  Support, though I would adjust some fields in this proposal:
  • Description: This item is a part of that item (this is a more intuitive and idiomatic way of saying "Part/Subset of something bigger, meronime".)
  • Domain: Everything ("subject main type and category" is an unnecessarily complex and slightly awkward way of saying "everything")
  • Source: W3C working draft document on representing whole-part relations in the Semantic Web (seems like a better source than miscellaneous categories and lists in Wikipedia).
  • Robot and gadget jobs: (The current proposal -- 'Consistency should be checked with proposed property, e.g. "whole thing of" (holonime).' -- seems unnecessary. Requiring these sorts of consistency checks would double the number of properties for each item on Wikidata. The validation seems like it would introduce very little benefit for significant cost.)
Whole-part relations are important for Wikidata to be able to represent. Emw (talk) 19:37, 16 March 2013 (UTC)
  Question How would this relate to other suggested or existing relations, such as is in, is in administrative unit, country, continent, divides into, member of, belongs to etc?
  Question If e.g. Microsoft Word is part of Microsoft Office (is this the way you want to use this property?), why can't I use subclass of? Please also see this discussion and the next section on that discussion page. --Faux (talk) 08:08, 22 March 2013 (UTC)
  • That's a good question. This W3C working draft is helpful reading that describes 'part of' and its potential uses in simple cases. The question of how software suites and their constituent programs could be described with part-whole relations seems slightly more complex. However, I think an example from anatomy shows how 'part of' would be different than subclass of and instance of in simple part-whole relations:
  • <heart> part of <vertebrate organism>
  • <dog> subclass of <vertebrate organism>
  • <Fido> instance of <dog>
Therefore, Fido has a heart. Emw (talk) 03:28, 23 March 2013 (UTC)
We will be able to do consequences, cool. Infovarius (talk) 20:21, 23 March 2013 (UTC)
I think this property has been discussed at length and we have a broad consensus now that we cannot simply use P279 or P31 to replace this property. So I will create it tomorrow if there is no further objection. Besides, I am aware that in some cases it is not very clear which property ("part of" or P279/P31) should be used, I think we could discuss these cases later, case by case. --Stevenliuyi (talk) 16:44, 26 March 2013 (UTC)
I understand that there are differences between instance of, subclass of, part of, etc. but the difference it not so clear for me. Could we start a new section in the list of properties which collects these generalizing/specializing properties with specific rules in which case which property has to be used? --Faux (talk) 22:05, 26 March 2013 (UTC)
  Done as P:P361. @Faux: I'm writing User:Stevenliuyi/Differences among ontology properties, hope it will make things clear --Stevenliuyi (talk) 15:56, 27 March 2013 (UTC)
Great! Definitely useful. We should consider to attach such a listing to all those properties. --Faux (talk) 21:55, 27 March 2013 (UTC)

Commonscat link

Status:    Done

→ Property:P373

See also Wikidata:Contact_the_development_team#Interwikis_on_Wiktionary_etc.

Commons category

DescriptionName of the Commons category containing files related to this item
Data typeString
Template parametercommons or commonscat in dozens of templates in many languages.
DomainNo restriction
Allowed valuesOnly existing Commons categories are allowed. The name is without the Category: prefix
ExampleFor Q569101 it would be Calosoma reticulatum
Sourcenl:Sjabloon:Taxobox
Robot and gadget jobsBots should be collecting this based on current template usage. If a category at Commons gets deleted and/or renamed, Wikidata should be updated. The commonscat.py Pywikipedia script should be updated.
Proposed byMultichill (talk) 20:44, 30 March 2013 (UTC)

This property is an intermediate step until we have full Commons support. When we get that we can just convert the data. Up until now Commons category links got updated the interwiki way: Decentral with a lot of efforts, see this page for some statistics. By putting this in a central place we are much more efficient and it doesn't really matter anymore what kind of templates some language Wikipedia use to represent the data. Multichill (talk) 20:44, 30 March 2013 (UTC)

seal description

Status:    Done

→ Property:P418

Authority control / Normdaten / Autorité

NDL Authorities / Nationale Parlamentsbibliothek (NDL) / Bibliothèque nationale de la Diète (NDL)

Descriptionde:Web NDL Authorities
Data typeString
Template parameterNDL
Exampleja:Template:Normdaten
Sourceid.ndl.go.jp/auth/ndlna/
  Support Kolja21 (talk) 13:23, 18 March 2013 (UTC)
  Support fryed-peach (talk) 07:33, 19 March 2013 (UTC)
  created as Property:P349 --Ricordisamoa 01:29, 25 March 2013 (UTC)

ICCU Authorities

Descriptionauthor names ICCU (Istituto Centrale per il Catalogo Unico, the Italian national bibliographic agency) authority control number
Data typeString
Template parameterauthority control
Domainpeople (authors/writers/musicians)
Allowed valuesthe eight-character fixed string in capital letters "IT\ICCU\" followed, without a space, by a three-character alphabetical or alphanumerical string in capital letters (e.g. "CFI" or "RAV" or others), followed (always), without a space, by the capital letter "V" followed (always), without a space, by the slash character "\" followed without a space by a six-number string (e.g. "017574‏")
Example<Francesco Petrarca> ICCU <IT\ICCU\CFIV\017574‏>
Sourcehttp://viaf.org/
Robot and gadget jobsto be found (we have few possibilities)
Proposed byPierfranco Minsenti 09:30, 30 March 2013 (UTC) (proposal modified by Aubrey (talk) 10:00, 30 March 2013 (UTC))

Hello, I propose to add this new property to the Authority control section: the Italian authority control number, that is the authority control number used by the records provided to VIAF by ICCU (Istituto Centrale per il Catalogo Unico), the Italian national bibliographic agency which is part of the Italian Ministry of Culture. The identifier code for these authority control numbers should be the same used in VIAF, that is: ICCU. This code can be found in records from the VIAF dataset and accompanies records provided by Italy. This code has the same function as other codes in VIAF which are used to identify the originating source, that is the national bibliographic agency which provided authority control records, such as for example the code BNF (which stands for the Bibliothèque Nationale de France), or the code NDL (which identifies Japan's National Diet Library). Since in the English Wikipedia (http://en.wikipedia.org) the Property proposal/Authority control already contains a few national codes identifying the originating source for authority control numbers, such as BNF, and these are derived from the VIAF dataset import, it seems justifiable to add even the Italian authority control number using the specific code used by the Italian national bibliographic agency as an identifier for their authority control numbers: the code ICCU. This code should provide a link to the VIAF specific page displaying the Italian record.


  Support but we shouldn't take VIAF as source, this would only produce low quality dubs. We can look up ICCU at www.sbn.it/opacsbn/opac/iccu/. --Kolja21 (talk) 01:51, 31 March 2013 (UTC)
  Strong support but considering Kolja21 advice. --Sannita - not just another it.wiki sysop 08:43, 31 March 2013 (UTC)
The VIAF has been indicated as the primary source because at the moment we cannot export any data directly from ICCU since they do not provide this service. Instead the full VIAF dataset also contains records provided from ICCU, so at this time we can have records from ICCU only through VIAF. Beside, the ICCU URL you refer to (http://www.sbn.it/opacsbn/opac/iccu/authority.jsp?db=solr_auth www.sbn.it/opacsbn/opac/iccu/), is only a search interface, useful for searching single author names' records one at a time. But we need a full export functionality of the whole ICCU dataset, which, as I said, is a thing not yet provided by ICCU, only by VIAF. Pierfranco Minsenti 15:21, 31 March 2013 (UTC)
  •   Support Hurricanefan24 (talk) 11:17, 31 March 2013 (UTC)
  •   Support As Pierfranco says, I think it's just a matter of interpretation to write in th espurce of the data ICCU or VIAF. The original source of the data is ICCU, of course. But they sent their data only at VIAF, and via VIAF we get them. Just decide what to put in the source (I would say ICCU, maybe with a note/reference/comment), and do it. Aubrey (talk) 19:11, 31 March 2013 (UTC)

  Done, Property:P396. Legoktm (talk) 19:57, 6 April 2013 (UTC)

NLA

Descriptionthe subject's NLA (National Library of Australia) authority control number
Data typeString
Template parameterauthority control
Domainpeople (authors/writers/musicians)
Allowed values\d{12}
Example<Andrew Barton Patterson> NLA <000035411562>
Sourcehttp://nla.gov.au/anbd.aut-an000035411562
Proposed by — billinghurst sDrewth 12:02, 25 March 2013 (UTC)

alternates are "Libraries Australia Authorities", though current exists in Commons:Template:Authority control as NLA; noting that VIAF refers to a url without the leading 0000, ie. http://nla.gov.au/anbd.aut-an35411562 (both work) (hope that I got this right)  — billinghurst sDrewth 12:02, 25 March 2013 (UTC)

  Support Hurricanefan24 (talk) 18:51, 28 March 2013 (UTC)
  Support Thanks for the link (that VIAF is not providing). --Kolja21 (talk) 17:42, 29 March 2013 (UTC)
  Comment, your example has only digits. Therefore I'm asking me if we shouldn't use the data type 'numbers'? However, not sure if this upcoming data type would cut of the leading zeros. I suggest to wait till data type number exist and how it works and then decide which data type we should use. --Nightwish62 (talk) 19:33, 30 March 2013 (UTC)

Person / Person / Personne

cause of death

  • Description: The chain of events -- diseases, injuries, or complications -- that directly caused death. Do not enter terminal events such as cardiac arrest, respiratory arrest, or ventricular fibrillation without showing the cause (i.e., etiology)
  • Datatype: item
  • Links:
  • Domain: people (and, in rare cases, other living things)
  • Infobox parameter example: yes, in English biography infoboxes
  • Comments: Sourcing is important here. I intend this to have a value related to a disease or an action (suicide, murder). Espeso (talk) 18:24, 21 February 2013 (UTC)
  • (reply) User:Emw just provided plenty of evidence that your assertion is not necessarily true. Nobody wants to pigeonhole the cause of death, but in many cases it is straightforward to document. Has anyone observed en:Category:Causes of death and en:Category:Deaths by cause (applied to individual biographies)? This category system wouldn't exist if the concerns about how to document it were well-founded. I understand that some causes of death are not suitable to the "item" type, but frankly, most are, and in more complicated cases the cause of death becomes too complicated to document on Wikidata anyway. Espeso (talk) 16:50, 14 March 2013 (UTC)
  • The interest of a DB is not to have a lot of details in a structure, but to offer a possibility to connect or to compare information. The cause of death is interesting for a person but we don't need a database for that, a simple text is enough. What is interesting for a database is the possibility to perform a connection. In case of cause of death that is possible only if we can group all causes in a small number of defined conditions and if everybody uses it in order to allow extraction of all persons having the same cause of death for example. Again if you connect 2 informations but this connection is not available in others cases, there is no interest for this connection in a db and the wikitext is suffisant. A db is not an collection of isolated tables but you have to link the tables together in order to allow the search of the same information in all tables meaning the need of the same classification and use of terms. Snipre (talk) 22:03, 16 March 2013 (UTC)
  • Wikidata is not merely a database, it is a project to structure all knowledge. This is a vital property that demographers, historians, public health professionals and much of the general public cares about. 'Cause of death' may have many possible values, but so can 'occupation', 'type' and many other immensely useful properties. Like those other important properties, the fact that this one would need to be stored as a VARCHAR instead of an ENUM in a database does not detract from its value as a piece of structured data. Emw (talk) 22:23, 16 March 2013 (UTC)

Indirect relations

  • Description: Proposed: "niece/nephew" aunt and uncle exist, "cousin", "grandchild" grandparent exists, "parent-in-law", "sibling-in-law", "child-in-law"
  • Datatype: Item
  • Domain: Person
  • Comments: It is interesting to document the relations between people. Indirect relations are harder to document on Wikidata because the "intermediate" people may not have entries, and may indeed not warrant entries. As such, the six properties above allow for more statements about relations to be made directly. In adding biographical data to entries on people, I have encountered the need to document these on many occasions. If you think I'm crazy to make this a single request, that's fine! I'm tired of extended debate on rather obvious/uncontroversial properties. If they're factual, give it a try and if they don't get used much, then we have our answer as to their value. None of the properties listed above are gender-specific, in line with preferred practice to date. Thanks, Espeso (talk) 16:43, 14 March 2013 (UTC)
  • As usual, loads of reasoning in the opposition votes and plain untruths. "The facts can be derived"? As I said, they're indirect relations. The intermediate items don't exist. Espeso (talk) 03:07, 20 March 2013 (UTC)
  •   Not done Espeso (talk) 03:42, 20 March 2013 (UTC)
  • strong   Support I see a need to have properties nephew, uncle and cousin in connection with cardinals and popes, because otherwise one cannot understand the relations.

We even have nepotism (Q161165) and list of cardinal-nephews (Q1644977). Many famous painters married sisters of famous painters. To document this we need brother-in-law, because the sisters have no entry.--Oursana (talk) 15:14, 31 January 2014 (UTC)

Military rank

Status:    Done

→ Property:P410

  Support --Goldzahn (talk) 10:30, 13 March 2013 (UTC)
  Comment I would think it would be best to wait until we have date qualifiers. That way, we should be able to create the whole biography (Colin Powell: Colonel in 1876? general in 1989...). --Zolo (talk) 10:33, 13 March 2013 (UTC)
Yes, it's a better way to do it. --Stevenliuyi (talk) 18:42, 14 March 2013 (UTC)

canonization status / / / stato di canonizzazione

Descriptiona person's canonization status
Data typeItem
Template parameternot known
Domainsaints, etc.
Allowed valuese.g. Canonization or Beatification
ExampleJohn Paul II → Beatification
Sourcewikipedia
Robot and gadget jobspossibly later
Proposed byRicordisamoa 08:23, 24 March 2013 (UTC)

voice type / / / tipo di voce (IT)

   Done: voice type (P412) (Talk and documentation)
Descriptionw:en:voice type of singer.
Data typeItem
DomainSingers. Mostly classical, but may be applicable to mass-culture ones.
Allowed valuesSee w:en:voice type .
ExampleEnrico Caruso voice type is tenor
Robot and gadget jobsdata is extractable from w:en:Category:Singers by voice type
Proposed byEugeneZelenko (talk) 03:01, 29 March 2013 (UTC)
  Support Superm401 - Talk 18:09, 8 April 2013 (UTC)
  Support --NaBUru38 (talk) 16:47, 11 April 2013 (UTC)

position (on team)

DescriptionWhat position the player plays (ex: defenceman, pitcher, goalie)
Data typeItem
Template parameterput infobox parameter here if existing, e.g. en:Template:Infobox ice hockey player position
Domainsportsperson
Allowed valuesany position
ExampleJoe Thornton <position> centre
SourceInfobox I guess
Robot and gadget jobsMy bot is ready to import this data for all hockey players.
Proposed byLegoktm (talk) 06:40, 1 April 2013 (UTC)

Organization / Organisation / Organisation

stock exchange

Status:    Done

→ Property:P414

  Support Danrok (talk) 20:21, 28 February 2013 (UTC)
Qualifer required: ticker symbol and stock exchange are a package. If there were two properties, one for each, and a company was listed on two or three markets, you wouldn't be able to determine from the data which symbol went with which market. As such ticker needs to be a qualifier of market, or vice versa. Espeso (talk) 03:59, 2 March 2013 (UTC)
  •   Wait until we have qualifiers before creating this property as "Item". Per above, this needs to be a qualifier of "ticker symbol", because the two are dependent, and "ticker symbol" has now been created. Espeso (talk) 06:45, 10 March 2013 (UTC)
The ticker is more a qualifier of the stock exchange than the contrary. Greenski (talk) 14:15, 8 April 2013 (UTC)

Event / Veranstaltung / Évènement

Creative work / Werk / Œuvre créative

Discography

Number of album
  Comment Can you explain more about this one? Should data type be integer? Danrok (talk) 01:55, 25 February 2013 (UTC)
What's the number of Live at Texas album by Linkin Park? Do live, best hits, remixed albums count? --NaBUru38 (talk) 23:23, 25 February 2013 (UTC)
If this proposal means it, then I have to oppose. Redundant property IMO. Is it used in it-wiki template? --Stryn (talk) 13:23, 26 February 2013 (UTC)

Type of object

  • Description: type of object (sculpture, painting, tombstone etc.)
  • Datatype: Item
  • Links:
  • Domain: Creative work
  • Infobox:
  • Comments: especially useful for archeological artefacts (we certainly need to tell somewhere that Q6004980 is a "kudurru"). But I am not sure about the scope. For instance, should "type of building" be included here. Sometimes boundaries between large "classes" of material objects can be fuzzy. --Zolo (talk) 10:37, 5 March 2013 (UTC)

  Oppose Why not use Is a(n)? Your list of allowed subject items includes "etc", so the software does not need this specific type to check that only allowed types are entered. Mange01 (talk) 02:27, 7 March 2013 (UTC)

  Comment The en:Template:Infobox artwork has a parameter "tpye" that is identical with the property "material" (Property:P186). --Kolja21 (talk) 04:11, 7 March 2013 (UTC)

Yes, the only infobox I see using this property is fr:Modèle:Infobox Artéfact archéologique. On the other hand, paintings and sculptures usually have separate infoboxes, which also provides some info about the type. Using the "is a" property is ok with me, but if we do not want to have "type of object", I think we should not have type of building either (I created that one because of the apparent consensus after 3 weeks). To keep things consisent I think we have 3 possible solutions:
  • create this property and leave the reste as is
  • create a new property that would merge type of object and the current "type of building" property
  • delete "type of building" and always use P:P31 --Zolo (talk) 22:02, 12 March 2013 (UTC)
I would use for type-of-object the is-a property, because the proposed property “type of object“ differs not enough from is-a and does not seem to be specialized enough. Whereas I think the “type of building” proeprty can be kept. It is way more specific than is-a. Nobody would use it for things like a sheep is-an animal (A sheep type-of-building is-an animal ;) ).
I see it like this: There are many properties which function as “this item belongs to the class of these items“ or “this item is an instance of that item“. The generic properties for these relations are is-a and generalized-by. But this does not mean that we must not have more specific properties with the same function.--Svebert (talk) 15:18, 15 March 2013 (UTC)
I believe that this is more general propose. See mine below: #PART OF / Часть. Infovarius (talk) 18:41, 15 March 2013 (UTC)

  Oppose This property is redundant with Property:P31 and Property:P279. Emw (talk) 23:23, 17 March 2013 (UTC)

software

operating system / Betriebssystem

Status:    Done

→ Property:P306

  • Description: operating system (OS) on which a software works
  • Infobox parameter: en:template:Infobox software: operating system.
  • Datatype: Item
  • Domain: don't know, Software
  • Allowed values:
  • Source: named infobox
  • Example item and value:
  • Robot and gadget jobs:
  • Comments:
--#Reaper (talk) 21:41, 12 March 2013 (UTC)
  Support -- MichaelSchoenitzer (talk) 22:29, 13 March 2013 (UTC)
  Support --NaBUru38 (talk) 19:41, 19 March 2013 (UTC)
  Support --Toru10 (talk) 18:39, 20 March 2013 (UTC)

  Done - Property:P306 -- MichaelSchoenitzer (talk) 15:51, 21 March 2013 (UTC)

License

Invalid topic given

   Under discussion
Data typeItem
Domainsoftware
Allowed valuesGPL, BSD etc
Example 1MISSING
Example 2MISSING
Example 3MISSING
Proposed byNashev (talk) 23:58, 23 March 2013 (UTC)

  Done Already exists! P275 -- MichaelSchoenitzer (talk) 16:15, 24 March 2013 (UTC)

Originallanguage / Originalsprache / Langue original

Status:    Done

→ Property:P364

  • Description: languages in with the book, movie, etc. was originally created
  • Datatype: Item
  • Links:
  • Domain: Creative work
  • Comments:
  Support MichaelSchoenitzer (talk) 00:23, 8 March 2013 (UTC)
  Support Janjko (talk) 15:58, 19 March 2013 (UTC)

  Done -- P364 -- MichaelSchoenitzer (talk) 00:28, 28 March 2013 (UTC)

Film

IMDb title, IMDb name / IMDb Rolle, IMDb Name / IMDb titre, IMDb nom

Status:    Done

→ Property:P345

  Support As a member of the Film WikiProject, I'm more familiar with the Wikipedia templates for title and person, and I imagine those would be the most needed. Shawn in Montreal (talk) 01:52, 17 March 2013 (UTC)

  • I'm confused: if a given Wikidata entry/Wikipedia article only treats one IMDB entity (movie, actor, etc), then we could have a single "IMDB identifier" property. Is my assumption correct (without getting into rare exceptions that prove the rule)? Espeso (talk) 01:56, 17 March 2013 (UTC)
There are different templates used to recognize different classes of IMDb ID codes: such as film titles or people's names. With these templates, one simply has to paste in the final digits of the URL in order to produce a link with the subject name. I think that these numbers may be reused in different classes of IMDb entries, meaning that we would need a range of properties. But that's just an assumption, not sure. --Shawn in Montreal (talk) 02:21, 17 March 2013 (UTC)
There is a prefix (tt, nm, ch.....) before the ID in IMDB URL. Can we also use these prefixes to distinguish different classes? --Stevenliuyi (talk) 02:33, 17 March 2013 (UTC)
Yes the prefix is hardcoded in those templates, but that doesn't mean it should be excluded from the identifier. The IMDB identifier, to the extent that there is one other than the URL string, includes those prefixes. Assuming again that one Wikidata entry is only about one IMDB item in general, the correct solution would be to make one property for "IMDB identifier" and pass the whole value to the Wikipedia template. Not a difficult adjustment on the Wikipedia side (requiring most simplistically an instruction to strip the leftmost two characters). I will not beat the drum of "don't format things to suit Wikipedia" any more, but it applies here. The prefixes are also informational and without them, you would likely have an ambiguous URL portion; that is "tt01000" and "nm01000" are very different things (obviously). Espeso (talk) 03:03, 17 March 2013 (UTC)

cinematography / Kamera / ...

DescriptionThe name of the cinematographer.
Data typeItem
Template parametercinematography at en:Template:Infobox television & en:Template:Infobox film, Kamera at de:Vorlage Infobox Film & de:Vorlage:Infobox Fernsehsendung
Domainfilms and similar productions
SourceWikipedia templates
CENNOXX (talk) 14:12, 20 March 2013 (UTC)
  Done Created the Property:P344 – cinematography. It shouldn't be a big issue, because of the similiar properties film director and screenwriter…--CENNOXX (talk) 14:09, 23 March 2013 (UTC)

radio format / Hörfunkformat / ...

   Done: radio format (P415) (Talk and documentation)
Descriptiondescribes the overall content broadcast on a radio station
Data typeItem
Template parameteren:Template:Infobox radio station
Discussion
  Support --Kolja21 (talk) 02:23, 26 February 2013 (UTC)
  Support Danrok (talk) 14:14, 27 February 2013 (UTC)
  Support, rename to "program format" to allow television and web programs use it too. --NaBUru38 (talk) 19:39, 19 March 2013 (UTC)
  Support I like NaBUru38's suggestion. --FelGru (talk) 21:10, 4 April 2013 (UTC)
I'm not sure I do. I'd support broadcast format for radio and TV stations/channels, but would individual programs not fall under the existing "genre" property? Shawn in Montreal (talk) 00:41, 5 April 2013 (UTC)
  Support original proposal for radio format;   Oppose an extension of this property into creative works such as TV programs until this idea is fully weighed with respect to the preexisting Property:P136. Shawn in Montreal (talk) 15:20, 5 April 2013 (UTC)

Term / Sachbegriff / Terme

Entrez Gene ID

Status:    Done

→ Property:P351

  Support As requestor. Andrew Su (talk) 16:18, 13 March 2013 (UTC)
  Support The problem with the proposals about Genes is, that they are strings with links. At the moment, I think, this is not possible. One developer wrote, that maybe this datatype will be developed, even it was not planed. If not, moving Wikipedia data into a Wikidata string and appending an external link within Wikipedia, is in my view a bad solution. We have the same problem with authority control data like ISSN, ISBN, OCLC, VIAF. --Goldzahn (talk) 20:35, 12 March 2013 (UTC)
Great point. I agree, as your other examples illustrate there's a bigger issue here than just with gene identifiers. Is there a better forum to raise this issue, since I doubt this comment thread will get broadly noticed by the right people? If so, I'm happy to lend my support/thoughts there. Regardless, I'm hoping we can move forward with these properties as strings and modify them when/if a better datatype is created... Cheers, Andrew Su (talk) 16:18, 13 March 2013 (UTC)
AuthorityControl.js can be extended to support this property, like many others ;) --Ricordisamoa 16:36, 13 March 2013 (UTC)
That doesn´t help showing Wikidata data in Wikipedia the right way. I´don´t know if it is possible to add something like this into a configuration page in Wikipedia. Maybe as a en:Wikipedia:Gadget#Default_gadgets (default gadget)? --Goldzahn (talk) 00:29, 14 March 2013 (UTC)
I proposed a property that would help for this. --Ricordisamoa 00:43, 14 March 2013 (UTC)
If we add all of them in AuthorityControl.js, it should be relatively easy to convert later on if a better format becomes available. As for Wikipedia infoboxes, I dont think it is such a problem, as we wont get rid of infobox templates anytime soon, the data may come from here, but the formatting will still have to be done on Wikipedia. Adding a link in the relevant infobox parameter should not be very difficult. --Zolo (talk) 08:58, 15 March 2013 (UTC)

  Done Property:P351

UniProt ID

Status:    Done

→ Property:P352

  Done Property:P352

Symbol

Status:    Done

→ Property:P353

  Done Property:P353

HGNC ID

Status:    Done

→ Property:P354

  Done Property:P354

Place / Geografikum / Lieu

Country / Land / Pays

ISO 3166-1

Status:    Done

→ Property:P297 → Property:P298 → Property:P299

  • Description: Country code of the International Organization for Standardization´´
  • Datatype: value
  • Links:
  • Infobox parameter example:
  • Comments: see w:en:ISO 3166-1
We have to decide wheter we're using ISO 3166-1-Alpha-2, ISO 3166-1-Alpha-3 or ISO 3166-1-Numeric. IW 17:36, 8 February 2013 (UTC)
I think we should create 3 property, one for each Fale (talk) 14:46, 10 February 2013 (UTC)
  Comment I agree with Fale. - Ssolbergj (talk) 03:55, 27 February 2013 (UTC)
Agree. I think we can also add ISO 3166-1 numeric. Though it is numeric, I think it is really a string as the number do not refer to any quantity. --Zolo (talk) 12:23, 7 March 2013 (UTC)

  Done P:P297 for ISO 3166-1 alpha-2 codes; P:P298 for ISO 3166-1 alpha-3 codes; P:P299 for ISO 3166-1 numeric codes. All are type string (even the numeric ones, as they don't hold any mathematical value, they are just strings that happen to consist of numbers). Jon Harald Søby (talk) 20:50, 18 March 2013 (UTC) (I have corrected the P-links --Monsieurbecker (talk) 12:29, 19 March 2013 (UTC))

ISO 3166-2

Status:    Done

→ Property:P300

  • Description: Country subdivision code of the International Organization for Standardization
  • Datatype: value monolingual string
  • Domain: Places (Administrative subdivision units).
  • Source:
  • Infobox parameter:
  • Example values: SE-Y or SE-22
  • Comments: see w:en:ISO 3166-2

Similar to country codes, these are codes for country subdivisions. Only textual codes exist. Nikola (talk) 13:58, 7 March 2013 (UTC)   Comment I changed datatype to "string". I support when a source or infobox parameter is provided. Mange01 (talk) 19:22, 13 March 2013 (UTC)

  Support I've been waiting for this for some time. Jon Harald Søby (talk) 14:16, 15 March 2013 (UTC)

  Done P:P300 for ISO 3166-2 codes. They should include country codes, as that is the standard. Jon Harald Søby (talk) 20:50, 18 March 2013 (UTC)

Astronomical objects

Object Name / Objekt Name / Nom de l'objet

I don't know if a "two StringValue" will be technically possible; in alternative we can use a sigle StringValue with the catalogue as a qualifier (or without qualifier for a common name). --Beta16 (talk) 09:53, 5 February 2013 (UTC)
It could be a good idea. --Paperoastro (talk) 21:24, 5 February 2013 (UTC)
It sounds more straightforward to make the name of simple string, and that catalogue a source. --Zolo (talk) 09:29, 6 February 2013 (UTC)
Interesting idea, but I have a doubt: is it possible use the value of a source in a query? --Paperoastro (talk) 22:27, 6 February 2013 (UTC)
I am pretty sure that it will, but I cannot find the page where it is mentionned. --Zolo (talk) 22:47, 6 February 2013 (UTC)
For me both solutions are valid: I have just changed the datatype to one string. --Paperoastro (talk) 11:31, 7 February 2013 (UTC)
  Comment I propose a new name of the property to remove possible confusion. If there isn't opposition, tomorrow I will create it --Paperoastro (talk) 23:50, 6 March 2013 (UTC)

Celestial coordinates / Astronomische Koordinaten / coordonnées célestes

  • Description: position of the object.
  • Datatype: a new datatype with two coordinates expressed in degrees (hours), minutes, and seconds and the epoch. Probably also a string with the type of coordinate system A qualifier could distinguish the type of the coordinate system.
  • Links: see for example this.
  • Infobox parameter example: en:template:Infobox galaxy ra, dec, epoch
  • Comments:
There will be a special datatype for coordinates. --Zolo (talk) 18:43, 7 February 2013 (UTC)
Very good! :) --Paperoastro (talk) 20:04, 7 February 2013 (UTC)
There are also coordinates for locations on earth. Please choose a label which makes it clear, which one is which.--Giftzwerg 88 (talk) 22:54, 7 February 2013 (UTC)
Done --Paperoastro (talk) 23:16, 7 February 2013 (UTC)
I de-templated your comment so that people wouldn't think that the property has already been created. Sven Manguard Wha? 17:21, 24 February 2013 (UTC)
  Support if this is plausible in Wikidata. πr2 (t • c) 16:37, 9 February 2013 (UTC)
  Support - Sarilho1 (talk) 11:45, 11 March 2013 (UTC)
  Support probably complicated, but definitely wanted.--Grondilu (talk) 11:31, 14 March 2013 (UTC)

Angular size

  • Description: The apparent size of large astronomic objects (e.g. galaxies, nebulae, clusters...).
  • Datatype: Usually angular size is expressed as major axis × minor axis. If this is not possible in Wikidata, two property could be created.
  • Links: see this as example
  • Domain: deep sky objects
  • Infobox parameter example: en:Template:Infobox galaxy size_v
  • Comments: --Paperoastro (talk) 18:18, 8 February 2013 (UTC)
  •   Oppose The apparent size of a galaxy (and some other objects) is strongly dependent on the sensitivity of the telescope used for observations and the integration time. The effective radius is a notoriously difficult quantity to measure. MER-C (talk) 13:36, 11 February 2013 (UTC)
    You are right, but usually Infoboxes report this information (see this example), even if the reference site (NED) has a disclaimer for this! In my opinion a well-defined value could be useful to have an idea of the size of the object for observations in the visible band. HyperLEDA-galaxy archive try to make a standard, using the diameter of the isophotal level 25 mag/arcsec; here there is the explanation (of course we could use the decimal value instead of logarithm). Could be a solution? --Paperoastro (talk) 11:44, 12 February 2013 (UTC)
    If there is a fixed surface brightness limit, then that's great. But one might start to wonder what the angular size is if the SB limit is X mag arcsec^-2, and then you're going to need (1) a large telescope and/or (2) a copy of galfit. MER-C (talk) 02:48, 19 February 2013 (UTC)
    galfit is a great tool to measure galaxy parameters, but there are many other methods to calculate the angular size: for example IRAF a has tool for isophotes. Many old catalogues, based on the plates of the POSS, reports the angular size of galaxies (see for example the UGC catalogue here). Also new catalogues, as the The SDSS Photometric Catalog report the isophotal diameters. --Paperoastro (talk) 12:00, 23 February 2013 (UTC)

  Not done --Paperoastro (talk) 21:49, 29 March 2013 (UTC)

Astronomic symbol / / / simbolo astronomico

Descriptionimage of the symbols that identify planets and some asteroids of the solar system
Data typeMedia-invalid datatype (not in Module:i18n/datatype)
Template parameteren:template:infobox planet symbol
Domainplanets of the solar system and some asteroids
Example<Jupiter> astronomic symbol <File:Jupiter symbol.svg>
Proposed byPaperoastro (talk) 23:04, 23 March 2013 (UTC)
  Support useful, we should create also a property for the Unicode equivalent (e.g. "♃") --Ricordisamoa 11:22, 27 March 2013 (UTC)
Since this property is needed, I'll create it soon if there aren't objections. --Ricordisamoa 07:13, 29 March 2013 (UTC)
  created as Property:P367. --Ricordisamoa 13:14, 29 March 2013 (UTC)

On astronomical body / /

Status:    Done

→ Property:P376

  Comment I suggest that this should be called "on astronomical body", and should be extended to also include geographical features on earth, for a generic approach. Rings are not on the body, so I suggest that "satellite of" should be used in that case instead. No simple infobox mapping exists, but this property is needed anyway. Mange01 (talk) 13:39, 23 March 2013 (UTC)

Good suggestions. I changed the name of the property: with this new name, it is straightforward including also geographical features on Earth! Concerning rings: "satellite of" can be appropriated, or, if my proposals above will be approved, would be used "parent body" (on the ring item) and "children body" (on the planet item). --Paperoastro (talk) 20:15, 23 March 2013 (UTC)

  Done P:P376 --Paperoastro (talk) 20:02, 31 March 2013 (UTC)

Parent body / /

Status:    Done

→ Property:P397

Do we have any solution for binary systems? I mean when there is a system of two (or more) objects of a similair size, where you normally not name them satellites of each other. ´This is not unusual in the Kuiper belt. -- Lavallen (block) 17:19, 20 March 2013 (UTC)
The solution I proposed for binary systems is to use for them the property companion of proposed below. --Paperoastro (talk) 08:44, 21 March 2013 (UTC)
  Comment Parent body is also used in meteoritics for the planet/planetesimal from which a meteorite originated. --Tobias1984 (talk) 13:34, 6 April 2013 (UTC)
I add in the "Infobox parameter example" the infobox parameters for meteor shower and meteorite infoboxes. --Paperoastro (talk) 19:58, 6 April 2013 (UTC)

  Done --Paperoastro (talk) 21:17, 6 April 2013 (UTC)

Children body / /

Status:    Done

→ Property:P398

  • Description: the opposite of the previous property: the minor body that "belongs" to the item. It is not a pysical properties, but a hierarchycal classification followed by astronomers.
  • Datatype: Item
  • Links: <Pluto> childern body <Charon>
  • Infobox parameter example: e.g. en:template:Infobox planet satellites
  • Domain: all astronomic bodies
  • Comments: see parent body proposal. --Paperoastro (talk) 17:42, 5 March 2013 (UTC)

  Done --Paperoastro (talk) 21:21, 6 April 2013 (UTC)

Companion of / /

Status:    Done

→ Property:P399

  • Description: two or more objects of the same type relating to each other, e.g. star systems, double star clusters, interacting galaxies...
  • Datatype: Item
  • Links: <h Persei> companion of <chi Persei>
  • Infobox parameter example:
  • Domain: potentially all astronomic bodies
  • Comments: see parent body proposal. --Paperoastro (talk) 17:42, 5 March 2013 (UTC)

  Comment If there is no opposition, I will create as soon as possible parent body, children body and companion of and I will put in cancellation natural satellite, planet, host galaxy. --Paperoastro (talk) 21:09, 31 March 2013 (UTC)

  Done --Paperoastro (talk) 21:24, 6 April 2013 (UTC)

City / town

Patron saint / / / Patrono

   Done: patron saint (P417) (Talk and documentation)
Descriptionthe patron saint of a town/city
Data typeItem
Template parametere.g. the "Patrono" parameter in it:Template:Divisione amministrativa
DomainPlace (towns and cities)
Allowed valuesall saints
ExampleNaples → Q315312
Sourceinfobox (see above)
Robot and gadget jobscould be imported from WP
Proposed byRicordisamoa 11:20, 27 March 2013 (UTC)

Unsorted

main article in category

Descriptionmain article in category
Data typeItem
Template parametersee w:en:Template:Cat main usage.
Domaincategories
ExampleQ183 is main article in category Q1410828
Robot and gadget jobsCould be automated, but human oversight will be good idea.

EugeneZelenko (talk) 13:55, 13 March 2013 (UTC)

mountain type / Bergtyp / types de montagnes

Invalid topic given

   Under discussion
Descriptiontype of mountain
Data typeItem
Template parameteren:Template:Infobox mountain: type
DomainPlace
Exampleen:Mauna Loa - Shield volcano
Sourceen:List of mountain types
  Done Property:P302 --Goldzahn (talk) 23:34, 19 March 2013 (UTC)

EE-number / EE-Nummer / EE-numéro /

DescriptionThe object is the identifier of breeds in the EE-List of the breeds of fancy pigeons / Objekt ist ein Bezeichner der EE-Liste der Rassetauben / l´objet est l´identificateur de la liste EE des races de pigeons
Data typeMonolingual text
Template parametereegroup
DomainTerm
ExampleQ5219796 - 0404 and Q824567 - 0411
Sourceen:Template:Infobox pigeon breed
You see at the left side of commons:Commons:List of Entente Européenne Pigeon Breeds the numbers, which should be stored as a string as a value to this property. See also en:List of pigeon breeds. And a new German template in in work, like the one in de:Berner Gugger. --Goldzahn (talk) 23:16, 17 March 2013 (UTC)
I´ve changed label and description. --Goldzahn (talk) 18:25, 18 March 2013 (UTC)

  Done Property:P303 --PigeonIP (talk) 06:30, 20 March 2013 (UTC)


Page

Status:    Done

→ Property:P304

What about publications that have different numbering systems in it? For example, some start off with I, II, III, IV, etc, on for quite a while, and then go on to 1, 2, 3, 4, etc. Also, some publications have things like page 23A, and such. --Yair rand (talk) 06:33, 4 February 2013 (UTC)
I've forgotten that issue. It's a real problem. We should maybe use the string datatype. Tpt (talk) 14:50, 4 February 2013 (UTC)
Do you know if it would be possible to allow both datatypes? I think it would be preferable to use a simple number (that could be, for example, automatically translated for languages with different numbering systems) where possible, but it also needs to have the option to have other forms. --Yair rand(talk) 01:17, 5 February 2013 (UTC)

DrTrigonBot (String) Value

→ Property:P368 → Property:P369

Descriptionany kind of values automatically updated in items
Data typeStringValue (later may be QuantityValue would be useful too)-invalid datatype (not in Module:i18n/datatype)
Template parameterany/generic
Domainany kind of values automatically updated in items
Allowed valuesany/generic
ExampleQ25344 currently I am using "inventory number" (Property:P217) instead
Sourceexternal (as given by the bot); URL & mail (formats include plain text, csv, zip, odt, xlsx, html, rss, ...)
Robot and gadget jobsBecause of Wikidata:Requests for permissions/Bot/DrTrigonBot
Proposed byDrTrigon (talk) 20:54, 22 March 2013 (UTC)

To be honest I am badly informed about wikidata, just to make that clear. I do think that I need a property to be created in order to store values, please confer Wikidata:Requests for permissions/Bot/DrTrigonBot and Wikidata talk:Infoboxes task force#Feasibility of DrTrigonBot/Subster to update Wikidata. Thanks for all your help and patience. Greetings --DrTrigon (talk) 20:54, 22 March 2013 (UTC)

Sorry. What do you need ? An property with a numeric datatype ? Or a property representing a numeric concept with a string as datatype ? If I take your example with swiss franc you want something like "currency division" to give the nominal value of each coin/note ( 0.05, 0.1, 0.2, 0.5, 1, 2, 5, 10, 20, 50, 100, 200, 1000)? Snipre (talk) 21:03, 22 March 2013 (UTC)
In fact I think a good thing would be a generic property (e.g. "DrTrigonBot Value" or even more generic "Bot Value") for the bot in cases when it has data to write for which no property was created yet - as it is the situation right now for a property "Currency Exchange Rate" (or similar) that is needed for swiss franc. This would allow the bot to already be tested or used without having the need to create always the suitable/correct property before being able to check if the bot works at all (in that specific situation), e.g. That would be a really good and useful/helpful thing! Thanks a lot for considering this and Greetings --DrTrigon (talk) 21:41, 22 March 2013 (UTC)
Just for a test you can see if there is a property in request for deletion using string as datatype or a property which not used in a lot of item or finally try on the demo version of wikidata. Snipre (talk) 22:05, 22 March 2013 (UTC)
Thats clear, currently I am using something else. Also the demo was already used to adopt the bot code. What I need is something permanent. In future and daily (usual) operation there will always be a case where you have to test, since the bot is freely configurable from here - by any user. --DrTrigon (talk) 22:36, 22 March 2013 (UTC)
I think testing bots should not be done on the productive Wikidata, except in the sandbox.--Faux (talk) 17:04, 23 March 2013 (UTC)
It is not testing bots, but testing setups - as on wikipedia itself you will always have situations were you have to change something, modify setup of data, configuration and so on... at least that is what holds for me. Then I have to disagree because testing of bots is needed, e.g. in order to fullfill the bot flag request a given number (e.g. 250) of test edits have to be done. And there will in future clearly be other situations - as soon wikidata will be used frequently... Greetings --DrTrigon (talk) 20:55, 23 March 2013 (UTC)
I mean ... it does not need to be something bot specific, what about general maintenance (for human users)? I would even more support such a property, that can be used if it is e.g. not clear yet what property to use, one has to be renamed, other name conflicts or anything else... --DrTrigon (talk) 20:59, 23 March 2013 (UTC)
Why not simply a sandbox property per datatype ? I do not see what harm can be done with that, as long as it is clear that it is a sandbox. --Zolo (talk) 21:29, 23 March 2013 (UTC)
Sounds good! (+1) Thanks for the idea! Greetings --DrTrigon (talk) 22:41, 23 March 2013 (UTC)
Do you plan using that sandbox property only on sandbox/test items, or also on production items? --Faux (talk) 12:12, 24 March 2013 (UTC)
I do not see anything wrong in using it other items. It will not look very good, and if we can avoid using it too massively, that is better, but raw Wikidata items do not look very good anyhow. The important thing is that it does not unintendedly get transcluded to Wikipedias and other clients. And as long as they do not query sandbox statements, I see no reason for that to happen. --Zolo (talk) 12:22, 24 March 2013 (UTC)
So... are we done here, or for what are we waiting? ;) If you agree I would step forwards and create following 3 properties:
  1. Label: Sandbox-CommonsMediaFile / Description: Sandbox property for value of type "Commons Media File" / Data type: Commons Media File
  2. Label: Sandbox-Item / Description: Sandbox property for value of type "Item" / Data type: Item
  3. Label: Sandbox-String / Description: Sandbox property for value of type "String" / Data type: String
any comments or thoughts on this? Thanks and Greetings --DrTrigon (talk) 10:52, 29 March 2013 (UTC)
Ok here we go:
  1. Sandbox-CommonsMediaFile (P368)
  2. Sandbox-Item (P369)
  3. Sandbox-String (P370)
so these can be considered done but I think it makes sence to propose the future ones too and set them to the pending page:
  • Label: Sandbox-Quantity / Description: Sandbox property for value of type "Quantity" / Data type: Quantity
  • (and all other data types to be introduced in future...)
Thanks for all your help! Greetings --DrTrigon (talk) 01:09, 30 March 2013 (UTC)
Added the proposals to the pending page. Greetings --DrTrigon (talk) 12:51, 30 March 2013 (UTC)

  Done

Taxon author

Status:    Done

→ Property:P405

  • Description: the author(s) of the first scientific description
  • Datatype: StringValue
  • Links:
  • Infobox parameter example:
  • Comments: datatype could be Item?
    Cannot be an Item because there are standardized author syntax like '(L.) Oken' where L. is the first author and Oken the author renaming Liné1 (talk) 08:05, 8 March 2013 (UTC)
  Support. Data type should be item. - Soulkeeper (talk) 17:47, 8 February 2013 (UTC)
  Support. This is a type of information that is commonly found in infoboxes and is therefore usefull or phase II. Amphicoelias (talk) 12:17, 7 March 2013 (UTC)
  Support. Taxon name means nothing without the Taxon author because there are case of duplicated Taxon name that can only be separated with the author.Liné1 (talk) 08:05, 8 March 2013 (UTC)
  Support Mandatory as there are duplicates Mirgolth (talk) 08:25, 8 March 2013 (UTC)
  Support. same. The real difficulty is to treat wikilinks, for which exact target name should differ on different wikis Hexasoft (talk) 08:51, 8 March 2013 (UTC)
  Support. MichaelSchoenitzer (talk) 15:33, 9 March 2013 (UTC)
  Support. --Salixen (talk) 15:10, 13 March 2013 (UTC)
  Comment Datatype should be item. Author acronyms can be implemented as an additional property of the biologists themselves. 23PowerZ (talk) 00:30, 6 April 2013 (UTC)
  Support Should be item. If I understand right, Liné1 is saying the syntax distinguishes between the author and subsequent renamers. If so, the right solution is to add another property for "taxon renamer". And if the abbreviation isn't trivial, 23PowerZ is right that can be its own property on the person's item. Superm401 - Talk 01:13, 6 April 2013 (UTC)
  •   Created with datatype set to items per most supporters. I understand the proposer's ideal behind using StringValue, but the community thinks this can be done with items. The property is here: Property:P405. — ΛΧΣ21 19:43, 7 April 2013 (UTC)

quantity symbol / Formelzeichen

DescriptionSymbol of a quantity (Q1401551)
Data typeString
Template parameterCan be mapped to de:Vorlage:Infobox Physikalische Größe: Formelzeichen.
Domainphysical quantitys (Q107715)
Allowed valuesUnicode symbol or sequence of symbols
Example“Q” and “q” for electric charge
SourceISO/IEC 80000
Proposed byFomafix (talk) 08:22, 22 March 2013 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/Archive/4&oldid=1659797707"