Wikidata

Wikidata:Property proposal/Archive/6

< Wikidata:Property proposal | Archive
Latest comment: 11 years ago by Hahc21


Review score

   Done: review score (P444) (Talk and documentation)
Descriptionreview score received by a creative work
Data typeString
Template parameterw:Template:Video_game_reviews for games, other methods and templates for films, books, albums, etc.
Domainitems about videogames, films, albums, books, etc.
Allowed valuesusually numbers from 0.0 to 10, 0 to 100, or letters from A+ to F- (depends on the type of creative work, and score issuer)
ExampleSinistar: Unleashed <review score> 80/100
Sourcew:Template:Video_game_reviews for games, other methods and templates for films, books, etc.
Proposed by— ΛΧΣ21

This property is needed to add the review scores received by games, films, books, albums, and other types of media. It can only work if used along with the property below, score issuer, as a qualifier of this property. Therefore, both properties are needed for this to work. — ΛΧΣ21 00:02, 14 April 2013 (UTC)

Discussion


Score issuer, issuer, reviewer

Descriptionthe issuer of a review score (also known as the reviewer)
Data typeItem
Template parameterw:Template:Video_game_reviews for games, other methods and templates for films, books, etc.
Domainitems about videogames, films, albums, books, etc.
ExampleSee example below
Sourcew:Template:Video_game_reviews for games, w:Template:Album ratings for albums, other methods and templates for films, books, etc.
Proposed by— ΛΧΣ21

This property is designed as to aid the property above, review score, to identify the source, or issuer, of an specific score. An example:

80 / 100
qualifier <score issuer> PC Zone
9.0 / 10
qualifier <score issuer> Game Informer
qualifier <score issuer> GameSpot

This way we can add several qualifiers identifying all the issuers who gave the same score to a work. A working example is here. As qualifiers will go live next week, this can be put in use immediately after it's approved, if approved. — ΛΧΣ21 00:02, 14 April 2013 (UTC)

Discussion


Launch site / Стартовая площадка

   Done: no label (P448) (Talk and documentation)
Descriptionстартовая площадка
Data typeItem
Template parameterru:Шаблон:Космический аппарат, ru:Шаблон:Космическая экспедиция Стартовая площадка
Domainкосмические аппараты
Allowed valuesстартовые площадки (можно сформировать список)
ExampleКассини-Гюйгенс запущен с площадки Куру, ELA3
Sourceсайт NASA, launchlog, карточки в статьях, список запусков и т. д.
Robot and gadget jobsМогу настроить бота на проверку значения свойства по какому-либо источнику, например, launchlog-у.
Proposed by— Ivan A. Krestinin (talk) 19:20, 1 April 2013 (UTC)

original network / Sender der Erstausstrahlung / …

DescriptionWhat television network(s) the television show was originally aired on. This does not include later re-runs or additional syndication.
Data typeItem
Template parameteren:template:infobox television channel (infobox alias network)
Domaininstances of television program (or its descendants)
Allowed valuesinstances of television network
ExampleThe Simpsons => Fox Broadcasting Company
Sourceen:template:infobox television
Proposed bySuperm401 - Talk

The infobox parameter combines channel and network, but television channel (Q2001305) is not as well-defined. Different people and regions use it differently; see en:Television_channel#Other_meanings. So I propose a property just for TV networks, for now. Superm401 - Talk 00:12, 8 April 2013 (UTC)

  Support we definitely need this information.--CENNOXX (talk) 10:05, 8 April 2013 (UTC)
  Support --Romero (talk) 23:49, 12 April 2013 (UTC)
  Support -- MichaelSchoenitzer (talk) 16:50, 18 April 2013 (UTC)
  Weak oppose I think just "network" with a qualifier like "as" and value "original" is better. This way all networks are together in one statement and the original network can be retrieved by qualifier. Otherwise we've "original networks" and "networks" which also didn't have to be together on the item site. --Nightwish62 (talk) 10:30, 19 April 2013 (UTC)

Astronauts / Космонавты : Missions / Миссии

Descriptionмиссии
Data typeItem
Template parameterru:Шаблон:Космонавт миссия
Domainкосмонавты
Allowed valuesпилотируемые космические аппараты
ExampleПонтис, Маркус, миссии: Союз ТМА-8
SourceКарточки в статьях и т. д.
Proposed by— Ivan A. Krestinin (talk) 19:20, 1 April 2013 (UTC)

Inscriptions

   Done: no label (P438) (Talk and documentation)
Descriptiontext written on an object. Widely used in Commons and in various museum databases. Inscriptions exceeding length limits should probably be storedsomewhere esle, perhaps in Wikisource.
Data typeString
Template parameterCommons:Template:Artwork
Domainall sorts of artworks and other material objects
ExampleLiberty Leading the People => Eug. Delacroix 1830
Proposed byZolo
Yes. I think we need to add qualifiers - in my example "instance of signature", and something like "instance of date". I am wondering about longer inscriptions that exceed the length limit like those on the Rosetta Stone. Should it link to a page in Wikisource ? --Zolo (talk) 07:27, 18 April 2013 (UTC)
  Done, as P:P438 --Zolo (talk) 11:37, 19 April 2013 (UTC)


presenter / Moderator / presentatore / ...

   Done: presenter (P371) (Talk and documentation)
Descriptionhost, narrator, or person, that otherwise takes the main role in presenting a radio or television programme
Data typeItem
Template parameteren:Template:Infobox radio show
Discussion
  Support --Kolja21 (talk) 02:23, 26 February 2013 (UTC)
  Comment Needs to be clarified. I don't think that "narrated by" is the same as "presented by", these are two different roles. Danrok (talk) 03:45, 27 February 2013 (UTC)
Are there programs where with both presenters and narrators? --NaBUru38 (talk) 19:38, 19 March 2013 (UTC)
Perhaps not, but "narrator" is a role used extensively in non-fiction film (and in some cases, fiction, I suppose) even where there is no on-camera presentation. I'd prefer to have two properties, for that reason. Shawn in Montreal (talk) 21:33, 30 March 2013 (UTC)
  Support in some form. Danrok (talk) 17:18, 28 February 2013 (UTC)
  Support --NaBUru38 (talk) 19:38, 19 March 2013 (UTC)
  Support --Viscontino talk 10:24, 26 March 2013 (UTC)
  Support --Nightwish62 (talk) 14:11, 30 March 2013 (UTC)

musical score by / musique de film par / ...

   Not done
DescriptionThe name of the film's music composer
Data typeItem
Template parameteren:Template:Infobox film
Domainfilms and similar productions
Example 1MISSING
Example 2MISSING
Example 3MISSING
SourceWikipedia templates
  • Comments: Another standard item at the film infobox, where it is listed just as "music". I had considered suggesting it as Composer to intentionally share the property with other uses of term, even the composer of a classic symphony an individual song is not quite the same as a film score composer, I'd say. What the preference, people? (sorry I cannot figure out why I cannot view, edit or remove the subsequent fields, directly below; odd.) Shawn in Montreal (talk) 21:18, 30 March 2013 (UTC)
  Oppose I lean towards reusing composer (P86). It's more alike than different. Superm401 - Talk 02:38, 4 April 2013 (UTC)
If I see a consensus here I'll happily change the description of Property:P86 accordingly. Shawn in Montreal (talk) 19:00, 5 April 2013 (UTC)
I think too reusing of composer (P86) is a good idea.--CENNOXX (talk) 22:50, 13 April 2013 (UTC)
WITHDRAWN in favour of simply using the composer property. Shawn in Montreal (talk) 19:58, 14 April 2013 (UTC)

Industry

   Done: industry (P452) (Talk and documentation)
DescriptionIndustry of company
Data typeItem
Template parameteren:template:infobox company industry
DomainCompanies (e.g. Q783794, but there may be others).
Allowed valuesindustries or fields
ExampleRed Hat → software
Source industry
Robot and gadget jobsShould be able to import from English Wikipedia
Proposed bySuperm401 - Talk

Should be useful and a straightforward infobox mapping. Superm401 - Talk 17:29, 8 April 2013 (UTC)

I broadened the values a little since not every valid industry may be an actual instance of industry. Superm401 - Talk 17:37, 8 April 2013 (UTC)


Main use

Status:    Done

→ Property:P366

  Question So how would we say The Shard is being "used," as distinct from its structure type? Shawn in Montreal (talk) 21:00, 5 March 2013 (UTC)

Structure type should probably be "skyscraper", while "use" would be "offices" or "residential". I am not sure about the words that should be used (see below), but you get the idea. --Zolo (talk) 16:43, 23 March 2013 (UTC)

  Question The suggested values (offices, residential, mixed) do currently not have items. Should this be a multi-lingual text instead, or should these items be created? . Mange01 (talk) 20:54, 13 March 2013 (UTC)

I dont think "mixed" should be used, we should rather have several values in this case (like, residential, office), as it is easier to make things more precise. I prefer the item type, as it is easier to standardize / translate, but I do not know exactly which one should be used

  Comment Resembles two parameters of en:Template:Infobox religious building:

    • status ("the building's current ecclesiastical or organizational status or the last previous ecclesiastical or organizational status the building held, if currently unused. i.e. oratory, basilica, cathedral, monastry, temple, most holy site")
    • functional_status ("the current function or usage of the building. i.e. active, abandoned, preserved, museum") In practice, other values exist in the infoboxes, for example "main building of X parish".

Mange01 (talk) 20:37, 13 March 2013 (UTC)

I think "status" is similar to this proposal, and that we should use qualifiers for "functional status". If the building used to be an oratory but is now a museum, we should have main use: oratory (+ date qualifier); museum (+date qualifier). --Zolo (talk) 16:43, 23 March 2013 (UTC)
  Done, as "use" (P:P366). --Zolo (talk) 13:53, 28 March 2013 (UTC)


DescriptionLink to Emporis database
Data typeString
Template parameter used in references for infoboxes
Domainbuldings in related areas
Proposed byZolo


Structurae ID

DescriptionLink to Structurae database
Data typeString
Template parameter used in references for infoboxes
Domainbuldings in related areas
Proposed byZolo

Foundational text

Descriptiontext that gave rise to an organization
Data typeItem
Domainorganizations, administrative units possibly others
Allowed valueslegal documents
ExampleFederal Reserve -> Federal Reserve Act, see also most current uses of Property:P92.
Robot and gadget jobsShould or are bots or gadgets doing any task with this? (Check other properties for consistency, collect data, etc.)
Proposed byZolo (talk)

P:P92 was created a while ago to experiment with references. It turns out that it has been used quite often to mean "text that created the institution", and I think that it is something useful to have. Alternatively, we could probably broaden the creator property, but that might make things a bit ambiguous. Zolo (talk) 20:28, 18 April 2013 (UTC)

IMO number

DescriptionInternational Maritime Organization (IMO) number is a unique identifier for ships and for registered ship management companies.
Data typeString
Domainships
SourceIMO number
As used in infoboxes for ships/vessels.Danrok (talk) 22:37, 19 March 2013 (UTC)
  Support I have found en:Category:IMO Number with more than 1000 entries. --Goldzahn (talk) 22:00, 22 March 2013 (UTC)
  Support --Nightwish62 (talk) 19:44, 30 March 2013 (UTC)
  Oppose as long the purposed datatype is String. If changed to number I'll support it (again). --Nightwish62 (talk) 15:20, 31 March 2013 (UTC)
  Support. It should definitely be a string. The IMO number is an identifier, not a quantity, it should not have a variance, and it should not be converted for languages that do not use arabic numbers. --Zolo (talk) 12:11, 5 April 2013 (UTC)
  Support as string (per Zolo, and like all Authority Control codes). I'll create it in 24h if there aren't further objections. --Ricordisamoa 15:27, 13 April 2013 (UTC)
  Comment, sorry, but either the letters 'IMO' are component of the value we like to store, or not. If it is, take string. If it's not, take integer. Everything else is wrong. There is no discussion about the identifier as whole is a string value, but we do only store the digit part, therefore integer. --Nightwish62 (talk) 09:53, 19 April 2013 (UTC)
  Comment But if it is stored as a "value" it will get "tranlated" into other number format used in other languages. See for examples at numberr 12 that not all languages use this number format. The IMO number on the other hand does not seem to be "translated" on any of the pictures I could find. That would mean that string is more appropriate. --Tobias1984 (talk) 10:00, 19 April 2013 (UTC)
  Comment Hooray. This is not a problem of the situation, it's a problem of the implementation. I don't know, but perhaps there should be a flag which indicates a integer to be translated or not. With this reasoning we couldn't use integer for 90% of all cases where it would make sense. Please be honest: The reason why everyone cries for string datatype is just because integer isn't available at moment and people like to getting starting use this property. No reason to use a wrong data type for me. As you said, the IMO is never translated. Meaning the right part did always have just numbers, meaning integer is right. --Nightwish62 (talk) 10:11, 19 April 2013 (UTC)
  Comment However, where is something mentioned about translation? Can't find something on this site, or at least it haven't quite decided yet. --Nightwish62 (talk) 10:16, 19 April 2013 (UTC)
It is not really a translation, it is displaying numbers in a different numbering system. I do not know whether that will be done by Wikibase or will be left the clients, but the more general point is that you clearly do not understand what dataypes mean. A string does not becomes a number just because you remove all chars that are not digits. String and number are different dataypes that support different operations. If something should behave like a string, then it should be a string. --Zolo (talk) 10:34, 19 April 2013 (UTC)
Ok, is it just me who doesn't understand data types. I accept this. Do you know what? Start using it. I doesn't care about the quality of this property. --Nightwish62 (talk) 13:36, 19 April 2013 (UTC)

IMO number

DescriptionSeven-digit number as designated by the International Maritime Organization
Data typeString
Template parameterw:Template:Infobox Ship Career, Ship identification=
DomainAny ships with a known IMO number
Allowed values^\d{7}$
ExampleMV Sorrento (9261853)
Source[1] (unofficial; no database available on IMO site)
Proposed byHurricanefan24 (talk) 17:58, 10 April 2013 (UTC)
Already proposed here... --Ricordisamoa 16:02, 13 April 2013 (UTC)

next (previous) element / /

There are already: prev and next. Infovarius (talk) 09:01, 28 March 2013 (UTC)
I'm agree with Infovarius: imho is better to generalize prev and next. An example of the use of these properties "outside" the work type of items is in the item 102 Miriam. --Paperoastro (talk) 15:41, 28 March 2013 (UTC)

Method

Descriptionindication of the method used in order to obtain the value or to format a value
Data typeString
Domainchemistry, physic, biology,....
Examplemethod of determination for autoinflamation temperature (close cup or open cup), method used to write a chemical formula (Hill, inorganic, organic),...
Proposed bySnipre (talk) 12:55, 20 April 2013 (UTC)
First, this proposal seems like it might be better as two proposals. The description says "indication of the method used in order to obtain the value or to format a value". The first part, "method used in order to obtain the value" lists as an example value the conditions under which a property of a physical object (autoignition temperature) is measured. The second part concerns how to format a given value. These are really two different things, each of which should be considered as its own well-defined qualifier.
Second, the 'domain' field should be more specific. The 'domain' of qualifiers should indicate as precisely as possible the type of claims the qualifier can be validly applied to. For example, in this proposal, there would be two domains: A) any claim about an empirical property of a physical object, and B) any value that requires special formatting (or can take on a special formatting). Emw (talk) 14:07, 20 April 2013 (UTC)
  Comment – shouldn't datatype be the item for used method (and formating moved to another qualifier pr. Emw) -- Byrial (talk) 20:23, 20 April 2013 (UTC)
  Support as item datatype.--Šlomo (talk) 07:45, 21 April 2013 (UTC)
Support "method" with item datatype, but I would prefer a more explicit label, perhaps "determination method". Oppose including format in this property but I guess a "notation system" property would make sense. --Zolo (talk) 11:56, 22 April 2013 (UTC)

said to be the same as

Descriptionthis item is said to be the same as that item, but the statement is disputed
Data typeItem
Template parameterNot applicable
DomainItem
Example-
  • Abstract:
Item A <said to be same as> Item B (source 1)
Item A <said to be same as> Item C (source 2)
Where Item B and Item C are not equal, or disjoint.
  • Concrete:
Maidilibala <said to be same as> Uskhal Khan Tögüs Temür (source: [2])
Maidilibala <said to be same as> Elbeg Nigülesügchi Khan (source: [3])
(See explanation below.)
Proposed byStevenliuyi (talk) 19:31, 14 March 2013 (UTC)

I encountered a problem when adding relationship statements to Genghis Khan's family members. The following example is based on a real case, though I changed a little bit so it's easier to understand: There are three ancient documents, the first written in Mongolian, the second in Chinese, and the third in Persian. The three documents respectively record there persons, named A, B, and C. The problem is that modern scholars have interpreted these documents differently. Some scholars think A is B's son while B and C are the same person; some scholars think B is C's brother while A and B are the same person; and others have some other interpretations. I am proposing this "same as" property so we can record all these interpretations in wikidata (I think sources are important and necessary if we use this property). --Stevenliuyi (talk) 19:31, 14 March 2013 (UTC)

  Support   Comment: This property seems useful! That said, I think the current Description and Domain values, and possibly also the label, should be adjusted.
The Description would be closer to the cited purpose of the property if it emphasized that the 'A is the same as B' assertion being made is disputed. Of course, if there is no dispute that two items are the same, then one would simply be made an alias of the other and the redundant item would be deleted. Perhaps something like then 'A is said to be the same as B' would help avoid confusion. I'm not sure of the best wording, but I think the current phrasing is too brief. Similarly, I think labeling this property something like 'said to be the same as' would be better than labeling it 'same as', since it would be more accurate and emphasize that the statement is essentially invalid without a source.
And, as noted in the Domain value, this property could be generalized to other domains. Such cases are easy to imagine: this organism is said to be the same as that organism by some source, this ill-defined disease is said to be the same as that disease by some source, etc. So I think the Domain value should be changed to 'All', or some synonym of the same. Emw (talk) 16:55, 17 March 2013 (UTC)
  Suggestion What about naming this property related to or strongly related to? Since Emw already mentioned, if A and B are really the same, why are there separate items? I understand, that in some situations (like the one described by Stevenliuyi) there are separate Wikipedia articles which describe the same thing in different ways, but as far I understand this also should not happen and the related Wikipedia pages should be merged. --Faux (talk) 08:26, 22 March 2013 (UTC)
I think the proposal is for something different than just strong relatedness. The difference is twofold. The example suggests a need to support disputed assertions that A and B are equivalent. I don't think the titles 'related to' or 'strongly related to' would capture those two defining features of this property. Would 'said to be the same as' work? Emw (talk) 02:40, 23 March 2013 (UTC)
I think "said to be the same as" is better. My original proposal "same as" is likely to cause confusion, and "strongly related to" is not really the same as my proposal. --Stevenliuyi (talk) 09:22, 23 March 2013 (UTC)
Stevenliuyi, I've gone ahead and changed the label, description and domain to reflect that, as well as the proposal's generic nature. If that doesn't match your understanding, please feel free to revert my edits. Emw (talk) 15:40, 24 March 2013 (UTC)
I still thing the title is not ideal. What does said to be mean? Is it mistakenly said, but not actually true? Was it said in the past, but not anymore? Might some people say it's the same, but it's not confirmed? --Faux (talk) 22:10, 26 March 2013 (UTC)
The phrase "said to be" isn't the most explicit possible label, but I think it might be among the most succinct and intuitive. When paired with the description "this item is said to be the same as that item, but the statement is disputed", I think the meaning is clear. Do you disagree? If so, what would you suggest as more appropriate title? Emw (talk) 01:56, 27 March 2013 (UTC)
Right now I am a little bit confused in which situations this property should be used. Should the property show a "possible equality" or a "proven equality"? In the latter case I totally agree with your title proposal and your statement, but as far I understood the original property proposal, the property should show that two items are per se the same and there is no doubt about the equality of the two items. --Faux (talk) 13:21, 27 March 2013 (UTC)
  Oppose wikidata is not doing some reconciliation of data. If there are different opposite statements in literature just mention the data and source. So if a source says that X is the unique son of Y and another that X is the brother of Y, put both statements with sources. Snipre (talk) 02:29, 29 March 2013 (UTC) Snipre (talk) 17:00, 18 April 2013 (UTC)
Sorry but that's not what I mean. The problem is not the opposite statements and conflicts between sources. The problem is that sometimes the source would say "X is the same as Y". --Stevenliuyi (talk) 02:38, 29 March 2013 (UTC)
  Example: OK, here is a concrete example, and I think it's easier to understand. There is a man named Maidilibala, who is a son of Mongol Emperor Biligtü Khan Ayushiridara, described by an ancient Chinese book (History of Ming). Some references (like this one) argue that Maidilibara is the same person as Mongol Emperor Uskhal Khan Tögüs Temür. And there are other references (like this one) argue that Maidilibara is the same person as Elbeg Nigülesügchi Khan, another Mongol Emperor. --Stevenliuyi (talk) 20:37, 30 March 2013 (UTC)
Great, thank you. I've added a simplified example in the documentation template based on that. Emw (talk) 20:54, 30 March 2013 (UTC)
  Support The example clears any doubts I had. Don't see how else that kind of information could be stated. Silver hr (talk) 03:15, 31 March 2013 (UTC)
  Question – is this only intended for current knowledge about the items, or also for past disputes about equalness which are now resolved? If, to use the example above, historicans or archaeologists somehow tomorrow find out that Maidilibala equals Uskhal Khan Tögüs Temür, and items Q7158737 and Q8937 are merged, should the merged item still use this property to item Q9171? And to itself? Byrial (talk) 18:27, 20 April 2013 (UTC)
  Support I suppose that when the sameness it really obvious, there should just be one item, but whether the sameness is dominant hypothesis, obsolete speculation or fringe weirdoness should be stated using qualfiers. If there is no opposition to it, I will create it (actually I was just about to propose it when I saw this proposal). --Zolo (talk) 16:51, 22 April 2013 (UTC)

Partner / Partner / partenaire

Status:    Done

→ Property:P451

  • Description: A partner of the subject (i.e. someone with whom the subject was closely related but not married, as befits today's modern "partnership" as opposed to marriage trend).
  • Datatype: MultilingualTextValue Item
  • Links:
  • Domain: Person
  • Comments: pretty much most "modern" (i.e. post 1970s) BLPs show "partner" and this can often include children born out of wedlock, civil partnerships etc. It would be remiss of this project to preclude those partners and, where applicable, their children, from being recorded here. The Rambling Man (talk) 19:06, 27 February 2013 (UTC)
  •   Support There are many notable (infobox-worthy) relationships that, for legal, social, or personal reasons, never resulted in marriages. The current president of France and mayor of New York City are both in high-profile domestic partnerships, and I agree we would be remiss not to include these. One thing though... shouldn't the datatype just be "item"? — PinkAmpers&(Je vous invite à me parler) 09:07, 28 February 2013 (UTC)
  •   Support as seen in infobox person | partner= Danrok (talk) 20:06, 28 February 2013 (UTC)
  • Question: why distinguish this from spouse at all? There's no big value in the distinction, which also has varying meaning/requirements across countries and is therefore very confusing in a global project such as Wikidata. P26 could just be renamed (in English) "spouse or partner" or even "partner"; many languages won't even have a distinction, I guess. --Nemo 09:39, 1 March 2013 (UTC)
  • Shouldn't the be called "couple / pareja", and apply to all kinds of relationships, both official and non-official, public or hidden? --NaBUru38 (talk) 20:39, 1 March 2013 (UTC)
    I think significant other is another possible label. Couple doesn't catch all, some people have more than one partner at a time. Danrok (talk) 00:05, 3 March 2013 (UTC)
    I think that's fine for the English label to be used as source, but it's a USA-only term so the translations would not be exact equivalents and would mostly fall under partner translations anyway. Any reason why this name can't be applied directly to the existing P26, broadening its usage? --Nemo 07:33, 5 March 2013 (UTC)
      Oppose It's not common nor widely spread nor informally or formally accepted in our country and in our abroad cultural domain. Doostdar (talk) 18:02, 7 March 2013 (UTC)
    Your language edition can always decide not to import data related to this parameter.--Ymblanter (talk) 18:06, 7 March 2013 (UTC)
    Good solution, thanks. Doostdar (talk) 18:17, 7 March 2013 (UTC)
    "Partner" is more anbiguous than "couple", that's why I proposed it. Anyway, my point was to include all kinds of partnerships in the property. --NaBUru38 (talk) 18:34, 8 March 2013 (UTC)
  • Would this replace P:P26, or be used sometimes alongside it, or be used only in cases where P:P26 would be incorrect to use? --Yair rand (talk) 00:21, 20 March 2013 (UTC)
  •   Support I guess this can't be used for someone having a lover alongside being married? Is this used only if the partnership is publicly shown? Janjko (talk) 09:42, 21 March 2013 (UTC)
  •   Support Yes, this will be useful. — ΛΧΣ21 04:44, 26 March 2013 (UTC)
  •   Support but needs to be distinguished from partnership agreements for professional work (architects/engineeers/accountants etc.). Filceolaire (talk) 06:23, 6 April 2013 (UTC)

  Done - Property:P451, please continue discussions about the names on discussionpage of the Property. -- MichaelSchoenitzer (talk) 20:33, 21 April 2013 (UTC)


opposite of / antonym / противоположно / malo de

   Done: opposite of (P461) (Talk and documentation)
Descriptionitem that is the opposite of this item
Data typeItem
Domainabstract terms
Allowed valuessimilar (probably bidirectional)
Exampleblack ←→ white, war ←→ peace, proprietary software ←→ free software, winter ←→ summer
Robot and gadget jobsthe property is supposedly bidirectional
Proposed byAVRS (talk)

When an opposite of an item exists, it is usually mentioned in the article, and is sometimes necessary to define the item. AVRS (talk) 15:59, 9 April 2013 (UTC)

  Support --Tobias1984 (talk) 06:28, 20 April 2013 (UTC)

color (item) / de:Farbe / fr:couleur / цвета /

   Done: color (P462) (Talk and documentation)
Descriptionadd color information to data sets
Data typeItem
Proposed by--  Docu  at 16:59, 15 April 2013 (UTC)
  Support Sounds useful. Might be a good thing for flags: Flag of France could be assigned red, white and blue. Or the Honeybee could be filled in with black and yellow. --Tobias1984 (talk) 21:04, 15 April 2013 (UTC)
  Comment Would be also useful for the colors of minerals. --Tobias1984 (talk) 08:50, 17 April 2013 (UTC)
  Comment Should propably also accept strings or allow qualifiers to allow things like dark red, light red, etc... which don't all have their own item. --Tobias1984 (talk) 09:15, 18 April 2013 (UTC)
  Comment How to express colors as "Light yellow color with a pink or greenish tint"? (Taken from natroxalate description in http://rruff.info/rruff_1.0/uploads/AM82_430.pdf) --Sbisolo (talk) 08:50, 19 April 2013 (UTC)
  Comment I have had a few discussions about this property. Some people would like the property to allow gradients. So instead of a single color a color range is assigned to an item. If an item has the color "brown" and "red" then the search should include colors in between those two colors. I'm not sure if that is technically possible. Another suggestion is that the colors should allow for subdivisions. An item with the color = azure-blue should be included in a search for blue. Same goes for all other names of blue. --Tobias1984 (talk) 08:54, 19 April 2013 (UTC)
This are interesting points, but I think some of this should be done through properties for items about colors rather than the property "color" of other items. --  Docu  at 09:18, 21 April 2013 (UTC)


Member of

Status:    Done

→ Property:P463

  • Description: a generic property stating that the item is/was a member of some group/set person is or was a voluntary member of a specific organization of people. This property must not be used for ethnic or social groups
  • Datatype: Item
  • Domain: People
  • Infobox parameter
  • Comments:   Support as proposer. This property would function in multiple contexts; a person was a member of a musical group, society, club, and so on. It would take care of numerous infobox properties without requiring over-specificity (see discussion of "member of learned society" on this page--as opposed to "member of unlearned society" or what? :-). Espeso (talk) 15:28, 8 March 2013 (UTC)
  Support Danrok (talk) 15:57, 8 March 2013 (UTC).
  •   Oppose - I prefer more specific properties. --NaBUru38 (talk) 18:46, 8 March 2013 (UTC)
    Why? "A <person> was a member of <musical group, society, artist's collective ...>". That is explanatory. As for disambiguation with related concepts, we have "employee of", and no one speaks of being a "member" of where you're employed, so I don't see a problem. We also have properties for more formal positions within groups such as political parties. But you can be a member of a political party and many other things without having some formal position within the group, and we need a way to express these relations generally, not with a bunch of super-specific properties. Qualifiers will also help with this property. Espeso (talk) 19:23, 8 March 2013 (UTC)
    As I said, I prefer more specific properties: member of an artistic group, member of an academic society, member of a political organization, member and a sports team, etc. Generic properties will be useless when we start querying. --NaBUru38 (talk) 19:08, 19 March 2013 (UTC)
Generic properties will not be useless for querying. If you want to find members of all artistic groups, your query would look like: "x member of y and y instance of artistic group". Silver hr (talk) 03:00, 31 March 2013 (UTC)
  •   Oppose, as this property is redundant with part of (P361, see Help:Basic membership properties).   Question   Support   Comment The 'Description' and the 'Domain' above disagree. The description speaks in terms of sets without specifying a domain -- if this is really "a generic property stating that the item is/was a member of some group/set", then I think "element of" would be a much better label. If the description were closer to something like "the person is or was a member of some group", then I think "member of" would be OK. Emw (talk) 03:35, 9 March 2013 (UTC)
  • I know, but this seems like semantic quibbling, and I don't support the notion that a property must have some limited, defined domain that restricts its use forever to what the property proposal said. In other words, if another user finds a rational new use case for "member of" that has nothing to do with people, great! (What if "Coal Miners of America", a hypothetical organization, was a member of "Miners of America"? What would that change here?) I will however strike the original description that was written as generically as possible and limit it to people. Espeso (talk) 04:29, 9 March 2013 (UTC)
  • Your comments are always considered Emw and I appreciate that. We need more of it. Please see the slight change in wording again, now that you have supported, to ensure you still support. It is only more clear yet, I hope. Espeso (talk) 22:01, 9 March 2013 (UTC)
  • How would this property be different than has part (P361), other than being domain-specific? I think it's best to use generic properties unless there's an exceptional reason not to. Emw (talk) 03:38, 4 April 2013 (UTC)
That's what I was thinking as well. On the one hand, this would be "part of" for humans, therefore redundant. But on the other hand, how else could we reflect the fact that people or groups of people are called "members" when considered as parts of groups? Silver hr (talk) 23:13, 12 April 2013 (UTC)
I think having 'member of' as an alias of part of suffices. What are your thoughts? Emw (talk) 02:18, 23 April 2013 (UTC)
I think Lavallen's example below ('Denmark is a "part of" Europe, but it is not a "member of" Europe') shows that they don't have identical semantics, which alias would imply. It seems to me that "member of" is a subproperty of "intransitive/direct part of", however Wikidata doesn't support subproperties, and our current "part of" property is transitive anyway. Silver hr (talk) 13:23, 25 April 2013 (UTC)
  • Does Wikidata have a policy of maintaining a neutral point of view like Wikipedia does in WP:NPOV? Wikidata:NPOV is currently a red link, and I see no mention of such a policy or proposal in Wikidata:List_of_policies_and_guidelines. That said, and with the cavaet that I don't know what it means for a property to be POV, I see no difference in potential for abuse between this property and is a. Emw (talk) 13:34, 9 March 2013 (UTC)
  • This property description is getting a thorough examination! I have added the phrase "voluntary member of a specific organization of people" to stress that this is not about ethnicity or vague socially constructed groups ("conservatives", "African Americans"), etc. Does that help Kolja21? If not, do you have a suggestion for the wording? I have no desire for this property to be used as you suggest, because if that information should exist at all on Wikidata, I would not use such a simple/reductive term as "member of" for it. Espeso (talk) 22:01, 9 March 2013 (UTC)
  • @Espeso: This description would help, but we still would need to watch the use of this property very closely and check every single translation of the description. (Of course "is a" has the same problem. "Is a" politician, that started a war, a mass murderer? Can I call a person a defrauder if I cite a book or do I need a court order? In a Wikipedia article an editor can differentiate; in Wikidata not. As log as we have no sources, it's even worse.) --Kolja21 (talk) 05:55, 12 March 2013 (UTC)
  Support I added explicitly in the description, that this property must not be used for ethnic or social groups-Svebert (talk) 15:06, 14 March 2013 (UTC)
  •   Comment Do not create until infobox parameter is provided. Mange01 (talk) 08:33, 20 March 2013 (UTC)
  •   Support P31 (instance of), P279 (subclass of), and P361 (part of), which already exist, don't really cover generic relations at a more human level; you wouldn't say "James Bond is a part/subclass/instance of acting". Support under the condition that "employer" co-exists with this; you might be an employee at your company and member of a chamber group. Hurricanefan24 (talk) 11:24, 31 March 2013 (UTC)
  •   Support – seems useful as people are not parts of an orginisation (you can be member of several organisations, but something cannot be part of several different things at one point of time) -- Byrial (talk) 17:50, 20 April 2013 (UTC)
I'm not aware of any ontology (or even dictionary definition) that makes that distinction between 'part of' and 'member of'. The W3C recommendation for representing simple part-whole relations -- on which part of (P361) is based -- does not make that distinction. Given that, I still think 'member of' is fully captured by 'part of'. What do you think? Emw (talk) 01:26, 23 April 2013 (UTC)
Well, I don't think that "member of" is captured by any of the use cases in the W3C document. I will try to explain better what I think the difference between "part of" and "member of" is: If you have some class and two different instances of that class, then I don't think that something can be "part of" both of these instances at the same time as that would require that thing to be two different things. For example if you have two different cars, then one car engine cannot be part of both cars at the same time. But one person can be "member of" two different organisations at the same time. Byrial (talk) 07:18, 23 April 2013 (UTC)
  • Denmark is a "part of" Europe, but it is not a "member of" Europe, it just happens to be there. Denmark is a "member of" European Union, but not all of "Rigsfællesskabet" is a "part of" EU. -- Lavallen (block) 07:58, 23 April 2013 (UTC)
  •   Support "member of" in a very generic sense. I do not see the use of limiting it to people. I think the major difference with "part of" is that "part of" is transitive, while "member of" is not. --Zolo (talk) 06:54, 25 April 2013 (UTC)


member of / Mitglied von / член

   Not done
DescriptionMember of any other organization than political party or sports team, eg. "Member of Academy of Science"
Data typeItem
Domainperson
Exampleexample item and/or example value
Robot and gadget jobs<Desanka Maksimović> member of <Serbian Academy of Sciences and Arts>
Proposed byМилан Јелисавчић (talk)

  Oppose Redundant with member of. Silver hr (talk) 19:50, 26 April 2013 (UTC)

color / de:Farbe / fr:couleur / код цвета / OTHERS

Descriptionadd color information to data sets.
Data typeString
Template parameternone
Domain?
Allowed valuesonly #hex
ExampleQ372973 = aquarmarine = #7FFFD4 (see: en:Aquamarine_(color); also the geologic time scale has a color for every subdivision
Sourcevarious
Robot and gadget jobs?
Proposed byTobias1984 (talk)

Tobias1984 (talk) 08:42, 15 April 2013 (UTC)

  Support I'like a color range (HEX to HEX). --Chris.urs-o (talk) 17:29, 18 April 2013 (UTC)
Datatype should probably be string if you want w:Web_colors#Hex_triplet to be added. In this case, I'd call the property "color hex triplet". --  Docu  at 16:59, 15 April 2013 (UTC)
The problem is that the color usually doesn't have 'official' hex-code. Actually it usually has several possible codes, may be a range of them. Infovarius (talk) 17:45, 15 April 2013 (UTC)
  Comment Currently the template en:Template:Period color stores all the hex values for the colors used for the geologic time scales and many daughter templates. It might be a good idea to store these values centrally. Plus it would ensure that the colors would be the same across all language Wikis. --Tobias1984 (talk) 20:56, 15 April 2013 (UTC)
  Comment The color of minerals is a range (HEX code would be resolution enough), the streak color is a smaller range. --Chris.urs-o (talk) 15:16, 18 April 2013 (UTC)

Occupant

   Done: occupant (P466) (Talk and documentation)
Descriptionoccupant of a building
Data typeString
Domainoccupants of a building
ExampleLouvre Palace -> Louvre Museum
Proposed byZolo (talk) 16:04, 21 April 2013 (UTC)

Especially useful to differentiate the item about building from the one about eponymous organization, see Wikidata:Project_chat/Archive/2013/04#How_to_manage_statements_for_organisations_that_are_eponymous_to_a_location.3F. --Zolo (talk) 16:04, 21 April 2013 (UTC)

legislated by

DescriptionIndicates that an act or bill was passed by a legislature
Data typeItem
Template parameterE.g. parliament in Template:Infobox UK legislation, but more general
DomainInstances of statute, or descendants
Allowed valuesInstances of legislature, or descendants
ExampleBill of Rights 1689 -> Parliament of England
SourceTemplate:Infobox UK legislation (see above)
Proposed bySuperm401 - Talk

Allows specifying which bills or acts were passed by which legislative bodies. Often, this means it becomes law, but in multi-branch systems like the United States this is not true (it can be legislated by Congress but vetoed. Superm401 - Talk 23:57, 6 April 2013 (UTC)

  Support, seems useful. FrigidNinja 22:43, 7 April 2013 (UTC)
  Done as Property:P467 --Stevenliuyi (talk) 05:01, 27 April 2013 (UTC)

Featured Article / Exzellenter Artikel / article de qualité

   Not done
DescriptionWikipedia in which the article related to this item is feautured.
Data typeItem
Template parameteren:template:Link FA 1, de:template:Link FA 1, fr:template:Lien AdQ 1, ... (For a full list of Wikipedias with the the template see: en:template:Link FA#From another language edition)
DomainAll items with articles.
Allowed valuesWikipedia language version items.
Exampleen:Asteroid belt = Q2179 -> Q328
SourceWikipedia categories on various languages: Q4387444
Robot and gadget jobsA bot should import the item from the categories of all languages.
Proposed byPyfisch (talk)

I think, that not only sitelinks should be stored in Wikidata, also feautured articles should be here, because this is very similar to sitelinks. When this request passes I will ask for a property for good articles. Pyfisch (talk) 12:01, 14 April 2013 (UTC)

Withdrawn because of this planned feauture: Help:Sitelinks#Badges This would be much better than my proposal. --Pyfisch (talk) 06:47, 21 April 2013 (UTC)
  Not done--Stevenliuyi (talk) 05:19, 27 April 2013 (UTC)

main category in article

   Not done
Descriptionmain category of the item
Data typeItem
DomainSubject main type (person, organization, place, term, disambiguation)
Allowed valuesany other than a category
Example<Germany> main category in article <Category:Germany>
Sourceit would be paired to the existing property main article in category
Proposed byKokoo (talk) 12:10, 21 March 2013 (UTC)
  Support a natural reciprocal of Property:P301 but the title should be main article in category. It should be <Germany> is the main article in category <Category:Germany> and not <Germany> is the main category in article <Category:Germany> as currently proposed. Pichpich (talk) 13:54, 24 March 2013 (UTC)
  Oppose I don't think main article in category (P301) is a good idea, so I don't think this inverse property makes sense. Wikipedia categories are essentially hardcoded query results from Wikidata that group together items by a set of user-defined properties. I don't see a compelling reason to build up a vocabulary and toolset to encourage that pre-Wikidata classification model. Emw (talk) 19:36, 24 March 2013 (UTC)
  Oppose Categories are to dependent on Wikipedias definition. Better use only wikidata classification instead of importing conflicting notions. Snipre (talk) 02:23, 29 March 2013 (UTC)
  Oppose too hard to decide, too WP specific, and may be the case in one article on one wiki, but not the case on another wiki. Plus if it changes at a wiki, then becomes hard to catch up in WD.  — billinghurst sDrewth 03:51, 30 March 2013 (UTC)
  Comment Reciprocal properties should be generally joined (one property should display automatically in both affected items. --ŠJů (talk) 02:50, 31 March 2013 (UTC)
  Comment Item page should contain together sitelinks to articles as well as sitelinks to categories of the identic item (sitelink to corresponding category of Commons should be treated in the same way). Article <Germany> and category <Germany> is a good example (typical for individual subjects and abstract terms). For other types of main articles (types of relation between category and its main article), specific properties should exist. For countable subjects, the most typical relations are "Category:Subjects/Article:Subject" (Plural/singular) and "Category:Subjects/Article:List of subjects", may be both these types together. However, we can find some more special types of main articles. --ŠJů (talk) 02:50, 31 March 2013 (UTC)
  Oppose – I fail to see how this can be useful. It is highly Wikipedia specific, and what use it is for in the Wikipedias? -- Byrial (talk) 18:34, 20 April 2013 (UTC)


Eight Banner register

DescriptionManchu household register (Eight Banners) for people of the Qing Dynasty (qualifier can be used to identify how the person got the register, such as Banner raised)
Data typeItem
Template parameterzh:Template:明清人物信息框(旗籍), zh:Template:東亞男性歷史人物(旗籍), zh:Template:東亞女性歷史人物(旗籍)
Domainperson (Qing Dynasty)
Allowed valuesPlain Yellow Banner, Plain White Banner, etc
ExampleCao Xueqin - Plain White Banner
Robot and gadget jobsyes (can be imported from infoboxes mentioned above and categories such as zh:Category:满洲旗人, zh:Category:汉军旗人, etc.)
Proposed byStevenliuyi (talk)


Dialing code / پیش شماره

Descriptionthe code dedicated to subject city by the area communication network
Data typeNumber (not available yet)
Template parameterput infobox parameter here if existing, e.g. en:template: Infobox_Italian_comune area_code
Domaincities
Examplee.g. the dialing code for city of Milan is "02"
Proposed byدوستدار ایران بزرگ (talk) 17:34, 31 March 2013 (UTC)

  Support, but I wonder if it shouldn't be property type "string" instead of "number". --  Docu  at 08:00, 13 April 2013 (UTC)


calling code / internationale Vorwahl / indicatifs téléphoniques internationaux

Status:    Done

→ Property:P474

  Done: Property:P474. I tried to create an item version as well, but no items currently exist. en_wiki has redirects such as "+65", but no articles. Redirects can't be linked currently. --  Docu  at 05:35, 28 April 2013 (UTC)

dan/kyu rank

   Done: dan/kyu rank (P468) (Talk and documentation)
Descriptiondan/kyu system used in go, shogi, judo, kendo, wushu, etc.
Data typeItem
Template parametere.g. en:Template:Infobox go player, en:Template:Infobox martial artist
Domainperson
Allowed valuesnew items should be created, such as "9 dan (go)", "10 dan (judo)"
ExampleGo Seigen - 9 dan (go)
Robot and gadget jobscan be imported from infoboxes
Proposed byStevenliuyi (talk)
  Done as Property:P468. Based on above discussion, I think we also need a qualifier called "recognized by", especially for some players who have ranks recognized by different institutions. --Stevenliuyi (talk) 05:39, 27 April 2013 (UTC)

Languages

   Not done
Descriptionlanguages of a product (CD, software, ...)
Data typeItem
Template parameterit:template:Software
Domainsoftware
Allowed valueslanguages: italian language, english language, ...
Example 1MISSING
Example 2MISSING
Example 3MISSING
Sourceinfobox
Proposed by★ → Airon 90 10:49, 29 March 2013 (UTC)
Ok, I created this proposal because I need it for Software related task :)
You're right, I move it and reword it. --★ → Airon 90 15:19, 29 March 2013 (UTC)

en:Official language in / de:Amtssprache von / fr:Langue officielle de / ru:Официальный статус

   Not done
DescriptionState designated as the official language of this
Data typeItem
Template parameternation in en:Infobox language
DomainPlaces (countries and states)
Allowed valuesPlace names
ExampleRussian: Russia, Belarus, Kazakhstan, Kyrgyzstan, Transnistria, Abkhazia, South Ossetia, United Nations
SourceInfobox and/or en:List of official languages
Proposed byKahusi (talk)

Not Property:P37. Kahusi (talk) 15:46, 17 April 2013 (UTC)

Sorry but what is the difference with the use of property 37 ? It is just a question of definition of the query based on the same data. Snipre (talk) 15:59, 17 April 2013 (UTC)
Property:P37 is something like en:List of official languages by state. Example: "Luxembourg: French, German, Luxembourgish". --Kahusi (talk) 16:34, 17 April 2013 (UTC)
I don't see the difference... --Yair rand (talk) 16:43, 17 April 2013 (UTC)
@Kahusi What you want is to get a list of places using a specific language. This will be done in the third step of wikidata and will but done according to the data using property P37. If all place places are defined according to property P37, it is just a matter of defining a good query in order to get what you want. The system is able to analyze each country and if the official language according to P37 is Russian, the name of the country is put in a list and at the end you get the list with the data you want based on P37. Snipre (talk) 17:14, 17 April 2013 (UTC)
withdraw this suggestion if usage of P37:
  • "if a page is the name of a country, substitutes a language name for the value";
  • "else if a page is the language name, substitutes name of a country for the value".
I thought that I could use it for only the former. --Kahusi (talk) 03:14, 18 April 2013 (UTC)
  •   Oppose, the data can be derived~from P37. --NaBUru38 (talk) 18:59, 18 April 2013 (UTC)
  •   Oppose – It is too unnuanced to use countries and states as domain, as somewhere the officiel language can depend on much smaller administrative units. But if the domain was changed, then the list for each language would be too big to be practical. So better just derive from P37. (BTW how can UN be in the example? it is not a country or a state.) -- Byrial (talk) 19:49, 20 April 2013 (UTC)

Status:    Done

→ Property:P248

For lack of feedback elsewhere, I 'll propose the following properties to use in the "source" section (all of type "item):

  • stated in. The basic case (Polydore Vergil says Richard III was killed at Bosworth Field)
  • evidence gathered in. (some journal article shows why it is likely that Richard III was killed at Bosworth Field)
  • officially established in. (say: the Court recognizes that Richard III was killed at Bosworth Field, and that the widow deserves a compensation)

That may sound a bit crude and I am not sure that it can work in practice, nor that it should go in the source filed, but it may be interesting regarless.--Zolo (talk) 13:32, 7 February 2013 (UTC) I think I'll be bold and implement it, as it will be easy to transform it into something else if needed. --Zolo (talk) 15:18, 7 February 2013 (UTC)

Source related data: too difficult to manage in the present structure which based on relation between 2 items. Better wait for semantic query for that.Snipre (talk) 15:28, 7 February 2013 (UTC)
Qualifiers will allow to add things like page number, and perhaps quotes, but will it fundamentally change the way property are handled ? --Zolo(talk) 18:43, 7 February 2013 (UTC)
Unless there is more opposition to it, I will create a "stated in" property. We already have a "imported from" and it does not make sense to source bot-imports but not human additions. If we change the way we do in later on, we can still convert it. I would also propose my own "legally established suggestion. After all, something can be either "stated", "implied" or whatever in a law, and that is probably what makes more sense in a source. About the "official", "legal" etc. status of the source, I suppose readers and bots can understand that by themselves, and if a source is more "official" than another we will be able to assign it a higher "rank" once the relevant functionality is deployed. --Zolo (talk) 18:28, 1 March 2013 (UTC)
created P248: stated in , we really need something here... --Zolo (talk) 09:36, 8 March 2013 (UTC)

Palissy identifier / Palissy-Kennzeichnung / identifiant Palissy

   Done: Palissy ID (P481) (Talk and documentation)
Descriptionidentifier in the Palissy database (Q2886424) of French cultural heritage monuments
Data typeString
Domaincreative work
Allowed valuesinstance of Monument historique
ExamplePM75003689
Sourcehttp://www.culture.gouv.fr/public/mistral/palissy_fr?ACTION=NOUVEAU
Proposed byAyack (talk)
Discussion

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

<WD:PP>

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)

  Info Property:P303 --PigeonIP (talk) 06:33, 20 March 2013 (UTC)

</ WD:PP > link to last entry in WD:Poperty proposal --PigeonIP (talk) 06:33, 20 March 2013 (UTC)

en:IMA number / de:IMA-Nummer / fr:nombre IMA / RUSSIAN / es: número IMA / it:numero IMA

DescriptionNumber given out by the International Mineralogical Association to each 'recent' mineral
Data typeString
Template parameternot included in infobox
Domainmineral items
Allowed valuesno restrictions
ExampleAbelsonite = 1975-013
Sourcehttp://pubsites.uws.edu.au/ima-cnmnc/IMA_Master_List_(02-2013).pdf (4th column)
Robot and gadget jobsBot should add the information form the 4th column to all the items it can find on Wikidata by using the information from the first column.
Proposed byTobias1984 (talk)

Tobias1984 (talk) 09:19, 19 April 2013 (UTC)

  Support --Chris.urs-o (talk) 09:36, 19 April 2013 (UTC)
  Support --Sbisolo (talk) 09:49, 19 April 2013 (UTC)
  Support, but attention about the source above. 1) There are not only correct IMA-No., but also the year of the first description (like 1956 for Abernathyit), 2) it's not the last update of that list and incomplete. So only two part numbers are correct. -- Ra'ike (talk) 10:46, 19 April 2013 (UTC)
You are right: IMA-No doesn't exists for grandfathered minerals. --Sbisolo (talk) 08:04, 22 April 2013 (UTC)

archives at

   Done: archives at (P485) (Talk and documentation)
Descriptioninstitution with the subject's archives
Data typeItem
Domainpersons, organizations
Allowed valuesitems about institutions
ExampleJohann Sebastian Bach (Q1339) => Bach-Archiv Leipzig (Q798038)
Proposed by--  Docu  at 08:49, 25 April 2013 (UTC)

MeshID

DescriptionNLM catalogue codes for diseases
Data typeString
Template parameteren:Template:Infobox disease field MeshID
Domainmedical subjects, diseases, ...
Allowed valuestype of linked items,allowed values (if limited)
ExampleLupus: Mesh ID = D008180
Sourcehttp://www.nlm.nih.gov/
Proposed byOldakQuill (talk) 04:10, 7 March 2013 (UTC)
  Support Emw (talk) 02:09, 27 March 2013 (UTC)
  Support Kaligula (talk) 11:09, 21 April 2013 (UTC)
  Support --Tobias1984 (talk) 08:43, 1 May 2013 (UTC)

Unicode character / Unicodezeichen

DescriptionUnicode character of the item
Data typeString
Template parametertbd
DomainAll items that describes a symbol for which there exists a Unicode character
Allowed valuesUnicode symbol
ExampleQ18100: „€“, Q484140: „ſ“, Q1138573: „𝄊“, Q200674: „✝“
SourceUnicode specification
Proposed byFomafix (talk)

A lot of items describes a symbol which also exists in Unicode. The Unicode character is not depending on a language. Fomafix (talk) 11:01, 22 April 2013 (UTC)

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