Wikidata:Property proposal/Archive/20

   Done: approximation algorithm (P1171) (Talk and documentation)

Description	put English description for property here, e.g. same as in the infobox documentation
Data type	Item
Domain	number, maybe other mathematical or physical objects ...
Allowed values	algorithms which computes number or an approximation of the subject type
Example	Pi ( ⟨ pi (Q167)      ⟩ P approximed by Search ⟨ Q2448949 ⟩
Format and edit filter validation	(sample: 7 digit number can be validated with edit filter Special:AbuseFilter/17)
Proposed by	TomT0m (talk)

Discussion

the relation exists. TomT0m (talk) 23:20, 11 February 2014 (UTC)

@TomT0m: Mind to specify an example? -Succu (talk) 22:30, 15 February 2014 (UTC)

@Succu: If you ask politely why not. TomT0m (talk) 22:34, 15 February 2014 (UTC)

Thank you. --Succu (talk) 11:07, 16 February 2014 (UTC)

  Support --Zolo (talk) 18:57, 16 February 2014 (UTC)

  Support --Micru (talk) 18:12, 20 February 2014 (UTC)

  Support. Note that for physical constant often is more correct to speak of "method of measurement" (see here for example). --Paperoastro (talk) 15:53, 22 February 2014 (UTC)

@Paperoastro:: for physical constants, I think we should use determination method or standard (P459) instead. --Zolo (talk) 16:22, 22 February 2014 (UTC)

Good! --Paperoastro (talk) 21:38, 23 February 2014 (UTC)

• @TomT0m, Zolo, Micru, Paperoastro:   Done --Jakob (talk) 21:40, 24 February 2014 (UTC)

Discussion

  Support. I guess "decimal value or decimal approximation" would be a more correct label but that sure sounds nerdish. About the number of digits, I think we should give as many as possible (depending on the number of digits allowed or the minimum value allower for the precision parameter. Note that we can diistinguish between decimal values and decimal approximation depending on the whether the precision is set to 0 or not. --Zolo (talk) 18:22, 10 February 2014 (UTC)

  Support, we can have several approximation, the precision value will give the interval in which the constant is. I think we can also have an aproximation algorithm or formula property to give the way to calculate the approximations or the formulas that gives the values of the numbers. TomT0m (talk) 18:42, 10 February 2014 (UTC)

@TomT0m: not sure how we should do approximation algorithm. It seems difficult to do it directly in Wikidata. It would have to be a string, but length is limited to 400 chars and we would need to clearly define the syntax we need to use beforehand. One possible solution: pi (Q167): newproperty:numerical value computable through: Leibniz formula for π (Q306467). And then Leibinz formula could be defined on an external page. We could link to the external page using described at URL (P973) or a new, more restrictive, property. We could even ensure that some external pages are machine readable by requiring it to be in code and add a qualifier to specify the language. --Zolo (talk) 19:35, 11 February 2014 (UTC)

Zolo I meant with item datatype, we got algorithm articles on Wikipedia. TomT0m (talk) 19:47, 11 February 2014 (UTC)

Gauss–Legendre algorithm (Q2448949) for Special:ItemByTitle/fr/Pi, as an example. TomT0m (talk) 19:57, 11 February 2014 (UTC)

Yes, I think we agree thehn ;). --Zolo (talk) 21:01, 11 February 2014 (UTC)

Dear Tobias1984 mind to explian your proposal further? pi and e are.... --Succu (talk) 22:10, 15 February 2014 (UTC)

@Succu: I don't quite understand what you mean. Pi is just the regular Kreiszahl. Do you mean the Euler-Number with "e"? --Tobias1984 (talk) 22:47, 15 February 2014 (UTC)

I think mathematical constant (Q186509) has a special meaning and the property should rather be called numeric value . --Succu (talk) 14:43, 16 February 2014 (UTC)

@Succu: - Thanks, that sounds a lot better. --Tobias1984 (talk) 18:11, 16 February 2014 (UTC)

  Support in this last version. Very useful also for physical constants, as gravitational constant (Q18373) or speed of light in vacuum (Q2111), where there is no problem for the precision. --Paperoastro (talk) 15:44, 22 February 2014 (UTC)

  Support. Do we need a different property to use where the value has units eg the speed of light? Can a property have dimensionless numbers and numbers with dimensions? Filceolaire (talk) 20:53, 24 February 2014 (UTC)

Discussion

Rodovid is a free online family tree portal. As of 2014, Rodovid had over 800,000 total records for individuals and families across all languages, including over 290,000 in Ukrainian and Russian, making it the second largest free genealogy service online, and the largest in any language other than English. --Lockal (talk) 12:11, 27 January 2014 (UTC)

  Support. --putnik 15:43, 30 January 2014 (UTC)

  Support -- Vlsergey (talk) 11:30, 12 February 2014 (UTC)

Discussion

We have at least 766 entries of MEPs in Wikidata already and we are going to clean them up next week, adding (hopefully) much more information. Some of that information comes directly from the MEP Directory of the European Parliament, which acts as a authoritative source. Having a link to the entry in that directory would therefore make sense. There is already a use-case to re-use these entries from Wikidata in the MEP templates in de:wp. Manuel Schneider^(bla) 17:36, 1 February 2014 (UTC)

• Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:34, 5 February 2014 (UTC)

Discussion

  Oppose. Terrible name. I am pretty sure there were people living around Williamsport before 1769; they just weren't white. Why do we need anything different from 'start date' - that seems good enough for every other town. Filceolaire (talk) 21:28, 24 February 2014 (UTC)

•   Not done Withdrawn. --Jakob (talk) 21:47, 24 February 2014 (UTC)

Discussion

•   Support as nominator

This property could be used similar to architect, where a painter decorated a building or main part of it - Oursana

If we have a "painter" property we would need to use it for simple paintings as well (if we have a "painter" property it would be odd not to use it on Mona Lisa). And it means that we would need to deal with potentially many properties (painter, sculptor...) while in most cases, creator (P170) alone is clear enough. I would prefer to use p170 with qualifiers (either part of (P361) or a new "role" qualifier), as suggested in this model that Marsupium has pointed to in Wikidata_talk:WikiProject Visual arts/Item_structure#Creator option problem. --Zolo (talk) 09:22, 5 December 2013 (UTC)

Zolo, your first link is a dead link. And it has nothing to do with your example of Mona Lisa. I mean cases where the painter is not creator (P170). I was inspired by architect (P84) which is also inconsistent to what you wrote above. I had in mind Tornabuoni Chapel (Q2593098) and we need to add Domenico Ghirlandaio (Q191423). I did not dare to use creator (P170), because he is not creator (P170) from the chapel but from the frescos. I do not see how to solve it with your suggestions. Or shall use creator (P170) for Domenico Ghirlandaio (Q191423)? --Oursana (talk) 22:59, 5 December 2013 (UTC)

  Oppose I think this is a very bad idea, sorry ;), but it is not a nice solution to make a painter property refer to things inside a building in opposite to creator (P170) which would only be used referring to the item itself. We should solve that problem by ignoring the problem and add the very general creator (P170) to Tornabuoni Chapel (Q2593098) (I think it is enough general to do it and we can add qualifiers as Zolo pointed out) or create an item xyz for the frescos and state: <xyz> creator (P170) <Domenico Ghirlandaio (Q191423)>. <xyz> isLocatedIn (I don't know which property Tornabuoni Chapel (Q2593098). I agree with Zolo that we should not create a painter property without adding it to the Mona Lisa.

Apart from that the {{Property proposal}} should perhaps be filled with English text to facilitate non-German-speaking users to contribute. And anyway the multilingual text does not seem to be appropriate. Finally Wikidata:Property proposal/Place seems to be the false property proposal page. --Marsupium (talk) 17:43, 6 December 2013 (UTC)

Sloppy copy-paste sorry the link is fixed, and I meant applies to part, aspect, or form (P518) not part of (P361) What I meant with qualifiers was something like:

• Tornabuoni Chapel (Q2593098): creator (P170) Domenico Ghirlandaio (Q191423) qualifier: applies to part, aspect, or form (P518): fresco painting (Q134194)

or

• Tornabuoni Chapel (Q2593098): creator (P170) Domenico Ghirlandaio (Q191423) qualifier: 'role': painter (Q1028181)

I know it is different from Mona Lisa, but if we have a "painter" property it would be strange no to use it every time the creator is the painter (we use 'architect' every time the creator is the arhitect).

The text in German is here because it is automatically added by the property-proposal pre filled form (I think we should try to enhance it but that is probably not the best place to talk about it ;). --Zolo (talk) 18:34, 6 December 2013 (UTC)

  Comment A similar property exists for books: illustrator (P110). --Zuphilip (talk) 19:01, 6 December 2013 (UTC)

@Zolo: I can agree with this but I also do not see the need for architect (P84), also there creator (P170) with qualifier would be sufficient.

  Oppose. This is what the proposed Wikidata:Property_proposal/Generic#specifically qualifier is for. For use where one person did the inks and another was the colorist and a third did the text (a common arrangement for US comics). All are creators with the qualifier detailing which role they had in the creation. Filceolaire (talk) 01:03, 14 December 2013 (UTC)

This is the wrong example for my purpose. The Tornabuoni Chapel is most famous for the fresco done only by Domenico Ghirlandaio.--Oursana (talk) 11:07, 14 December 2013 (UTC)

OK, we should perhaps find a way to state that, the part a chapel is famous for, I am not sure, perhaps. But this additional property is surely not a clean way to do so. Can we close the discussion, Oursana? (Can I unwatch the page? ;)) Regards, --Marsupium (talk) 18:25, 30 December 2013 (UTC)

@ Marsupium: Yes, we can close the discussion, perhaps I will ask you again, when I try to express this. --Oursana (talk) 23:44, 5 January 2014 (UTC)

  Oppose We have to separate the paintings from the building. And link the painting to the building with the property "part of": if different painters worked on the paintings the above solution is a nightmare. Building and painting as well specific parts of the building need different items. It is the only solution if we want to be able to add more data about the painting like style, date of renovation or destruction. Snipre (talk) 19:02, 30 December 2013 (UTC)

•   Not done Consensus is against creation, proposal is stale. Closing. --Jakob (talk) 21:54, 24 February 2014 (UTC)

Discussion

• Basic property. To be used together with the date via publication date (P577)/point in time (P585) or better. Raoli (talk) 02:52, 27 December 2013 (UTC)

  Hm, interesting proposal. This would be number of visitors total, throughout the entity's existence? And what would the scope include? Stadiums, geographic areas, parks, events? This wouldn't become used for number of tourists who came to a particular country, would it? --Yair rand (talk) 01:34, 31 December 2013 (UTC)

  For museums, attraction, place the number of visitors change every year. The scope include the "year" refers to the number of visitors. It doesn't refer to the stadiums or geographic areas, but can also refer to parks and events. And yes, this property "wouldn't become used for number of tourists who came to a particular country", of course. (For this I would use the property called "tourists".) — Raoli (talk) 19:52, 1 January 2014 (UTC)

•   Support This is an important property to measure the importance of a museum. The figures are often given in WP-articles. I changed the wording (numbers by year) according to the discussion.--Oursana (talk) 22:57, 5 January 2014 (UTC)
• How are the years entered? As a qualifyer? Which? The source information in your examples should follow for example Help:Sources#Web_page --Zuphilip (talk) 13:21, 6 January 2014 (UTC)

  With the qualifiers publication date (P577) / point in time (P585) as written here Help:Sources#Web page. Raoli (talk) 20:13, 6 January 2014 (UTC)

I could imagine one example for one statement in the following form:

Silesian Museum (Q651366) ==> 85.810

with qualifyer

point in time (P585) = 2012

and source

reference URL (P854) = http://www.szm.cz/media/docs/vyrocni-zprava-2012-opr.-525bd27e4d234.pdf

P357 (P357) = "SLEZSKÉ ZEMSKÉ MUZEUM VÝROČNÍ ZPRÁVA 2012"

original language of film or TV show (P364) = Czech (Q9056)

retrieved (P813) = 06.01.2014

page(s) (P304) = 41

--Zuphilip (talk) 21:32, 6 January 2014 (UTC)

Yes, it should be used in this way. But I would leave in the url field "#page=". Raoli (talk) 12:34, 7 January 2014 (UTC)

  Support. This seems like it would be a useful property, and the example above is a good use of qualifiers. Emw (talk) 04:35, 10 January 2014 (UTC)

  Support -- Yiyi .... (talk!) 22:19, 10 January 2014 (UTC)

  Oppose We need a more general property not only for number of visitors for building but for transportation (see above). Snipre (talk) 13:41, 15 January 2014 (UTC)

Excuse me, but this property is not for transportation. Transportation? I don't see the link destination you've quoted. Raoli (talk) 16:59, 15 January 2014 (UTC)

@Raoli: Corrected copy-paste error: visitor per year (museum) or number of users per year (railway line) are the same concept so is it possible to find an unique property for both uses instead of creating two differents properties with the same concept but using different definition ? Something like attendance. In french we have one word which can be applied in the two cited cases: "fréquentation" Snipre (talk) 18:59, 15 January 2014 (UTC)

@Snipre: Yes, it's not a problem for me, it seems a good idea en-"attendance", fr-"fréquentation", it-"frequentazione", but I would add "per year", eg: en-"attendance per year", fr-"fréquentation par année", it-"frequentazione per anno" or en-"yearly attendance", fr-"fréquentation annuelle", it-"frequentazione annua". Raoli (talk) 22:43, 16 January 2014 (UTC)

@Snipre: So, could you review your opinion now? Raoli (talk) 22:49, 16 January 2014 (UTC)

@Snipre: Eh.. the unit is for both properties "number / time" (with SI measure en:Hertz) but this does not mean that we have to merge these two properties. Moreover, the transportation property is "per day" and this property was proposed "per year". How would you merge that? I guess that the number of people who ride the said line in a year is an enormous number. Moreover, what would it mean to take the maximum for this merged property? This will be the most visited museum or transportation road; is this somehow meaningful? Is "visiting a museum" and "using a transportation line" a related concept? --Zuphilip (talk) 08:48, 17 January 2014 (UTC)

  Support --Konggaru (talk) 08:12, 4 February 2014 (UTC)

• @Raoli, Yair rand, Oursana, Snipre, Yiyi, Zuphilip:   Done, there is consensus to create. --Jakob (talk) 22:06, 24 February 2014 (UTC)

Discussion

The municipality-/county-codes for Sweden are only valid from 1952. The pre-1952-division in municipalities/cities/market towns/municipalsamhällen/municipalköpingar/hundreds/tingslag/counties has been asigned a 7-digit-code by scientists at Uppsala University. This code is used in papers about Swedish history, and this code can in the future help us use the information in such publications. -- Lavallen (talk) 09:31, 13 December 2013 (UTC)

Support, if it is used I see no reason not to have the property--Ymblanter (talk) 20:15, 13 December 2013 (UTC)

  Support --Tobias1984 (talk) 07:15, 13 January 2014 (UTC)

• @Lavallen, Ymblanter, Tobias1984:   Done --Jakob (talk) 21:58, 24 February 2014 (UTC)

Discussion

  Support This property is intended to narrow the scope of general properties instead of having to create specific qualifiers. This proposal was prompted by the discussion: "Instance of" as qualifier?, since it seems too much to stretch membership properties to be used as qualifiers. --Micru (talk) 09:41, 26 November 2013 (UTC)

Could you kindly provide an example? Pikolas (talk) 01:50, 27 November 2013 (UTC)

Example added. Filceolaire (talk) 00:44, 14 December 2013 (UTC)

  Support Filceolaire (talk) 00:44, 14 December 2013 (UTC)

  Oppose. I agree that 'instance of' should not be used as a qualifier, but I question the need for such a qualifier in the first place. More specifically, I am concerned that this property will encourage poor separation of concerns in properties. In particular, the "Chelsea Manning (Q298423) sex or gender (P21):female (Q6581072), => gender identity (Q48264)" example seems problematic; more on that here. Also, please put more explicit information in the examples; it's inconvenient to trace down the background on the mentioned properties. Emw (talk) 15:48, 15 December 2013 (UTC)

Emw; I think we need qualifiers for some properties and this property would help us effectively separate concerns without needing a million specific properties. Filceolaire (talk) 16:28, 26 December 2013 (UTC)

Filceolaire, I agree that we need qualifiers in general, but I think this particular qualifier has a few issues:

• It would not be in line with Semantic Web standards

The proposal indicates this qualifier would be a mechanism to create subproperties. Subproperties are properties. Subproperties are defined in OWL and RDFS by making a statement in the property definition like we do with 'domain' etc., not in statements in property usages in items.

Qualifiers, as far as I can tell, are already outside the scope of the web standards (Did I miss something?) Subproperties are in the semantic standards but are not supported by wikidata. The day that wikidata starts supporting subproperties (and searching accross a property plus it's subproperties simultaneously) I will support replacing all of these 'specifically' subproperties with specialised properties where we can use the subproperty mechanism to search accross all of these at the same time. Filceolaire (talk) 00:42, 30 December 2013 (UTC)

Filceolaire, qualifiers are not officially supported in W3C standards, but they have been given some thought: see Defining N-ary Relations on the Semantic Web. On the other hand, subproperties have been officially supported in Semantic Web standards, including those for queries, and reasoning engines as rdfs:subPropertyOf for almost a decade.

The fact that subproperties are defined in Semantic Web standards is in itself a very strong reason to structure them as closely as possible to those standards on Wikidata. rdf:type and rdfs:subClassOf are defined in Semantic Web standards but not in Wikibase, yet we structure them as closely as possible to those standards in P31 and P279 -- debates on those properties revolve around their semantics as defined in the standards.

W3C standards define a subproperty as a property of a property, not a property of a property instance. In other words, anyone wanting to use a subproperty would use it as a parameter of Px as we define them in property documentation templates -- not as a qualifier of an instance of Px as used in a statement. We have established practices for modeling these property parameters in Template:Property_documentation. Emw (talk) 02:00, 3 January 2014 (UTC)

• It would make constraints and semantic reasoning difficult or impossible

This point is closely related to the one above. By departing from Semantic Web standards, we also make it more difficult or impossible to deal with constraints. For example, if we say "Moulay Ali Cherif relative: Al Hassan Addakhil, type of kinship: ancestor" (example taken from Property_talk:P1039), then how do we ensure that the 'ancestor' subproperty of 'relative' fulfills constraints? (And why not just use 'ancestor'?) Even if we can express constraints this way in Wikidata's in-house constraint handling system, how would we represent these constraints in OWL when subproperties are defined in qualifiers? Emw (talk) 17:06, 28 December 2013 (UTC)

For the specific example you gave here: 'ancestor' is a subclass of 'relative'. That's what the constraint should check for. when we have implemented queries we can look again at whether this structure is, or is not, a problem. Filceolaire (talk) 00:42, 30 December 2013 (UTC)

Reinventing the wheels of the Semantic Web is perilous. A protocol to verify subproperties based on corresponding class definitions is a neat idea, but it ignores conventions ubiquitous in the rest of the world. Subproperty semantics and entailment as defined in RDF model theory and SPARQL have well-known computational properties and a large toolchain to support inference and querying. Adopting W3C conventions will let us build up support for subproperties above and outside Wikibase now -- as we do reasonably successfully for constraints, queries and class hierarchies -- while also being as closely compatible with the rest of the Semantic Web as possible. Emw (talk) 02:00, 3 January 2014 (UTC)

• It would be a way to create new properties without community review

Since subproperties are properties, this qualifier would be a way to create properties without input from other Wikidata editors. Having a formal property proposal helps ensure new properties are well-defined, not redundant with existing properties, known to relevant interest groups, etc.

This one isn't a bug; it's a feature. Our property approval process is quite time consuming. Being able to create specialist subProperties, without having to go through that process, is, I believe, a good thing. We already have a number of other mechanisms for doing this e.g. the 'significant event (P793)' property. Filceolaire (talk) 00:42, 30 December 2013 (UTC)

Then let's set up a streamlined process for creating subproperties the right way. I don't think anyone contests the fact that properties like significant event (P793) are innovative solutions, but my concern here is that they are not nearly as robust as solutions from W3C standards, and will have a long-term effect of making Wikidata an insular project in the Semantic Web -- or further fragment the Semantic Web. The further we drift from those standards, the harder it will be to import and export to other Semantic Web projects, and take advantage of the edge-cases solved and compelling tools built for such projects. If bureaucratic slowness is preventing useful properties and causing us to implement non-standard workaround solution, then let's cut red tape so we can hew closely to standard solutions. Emw (talk) 02:00, 3 January 2014 (UTC)

Feel free to comment above and indent responses below the relevant point. Emw (talk) 17:06, 28 December 2013 (UTC)

Looks like valid objections to me. -- Lavallen (talk) 18:41, 28 December 2013 (UTC)

Remember that even if this property is not created then these informal sub-properties will still continue to be created. They just won't use this specialist property; they will use 'instance of' and other properties instead. Filceolaire (talk) 00:46, 30 December 2013 (UTC)

The semantics of instance of (P31) are those of rdf:type. Thus, using P31 to define subproperties is incorrect. Emw (talk) 03:19, 3 January 2014 (UTC)

  Question With the current updates from the sex or gender discussion, is it worth revisiting this property for use instead of instance of (P31) for, for example, specifying that a particular 'sex or gender' statement is specifically about gender identity (Q48264)? Since there seems to be agreement above that using instance of (P31) is inappropriate. Klortho (talk) 16:37, 11 January 2014 (UTC)

I vote   Oppose in favor of using instance of (P31) for exactly this use case. I do not see any disadvantage for P31 if it is also used as a qualifier narrowing the type of statements. Please also see all the Requests for Property Deletions where most "type of" properties where deleted in favor for P31. Consequently, P31 should also be used if a qualifier is needed to specify the type of the claim. Nearly everyone knows this property and knows how to use it.  — Felix Reimann (talk) 21:46, 28 January 2014 (UTC)

  Not done Consensus not reached.--Micru (talk) 17:34, 3 March 2014 (UTC)

 

This property would let us state that two classes are disjoint. It would have the semantics of owl:disjointWith. It is closely related to proposed enhancements for property parameters currently being discussed.

Disjointness is inherited. For example, if plant (Q756) disjoint with animal (Q729) and mammal (Q7377) subclass of (P279) animal (Q729), then mammal (Q7377) disjoint with plant (Q756). And, because David Bowie (Q5383) instance of (P31) human (Q5) and human (Q5) 'disjoint with' plant (Q756), we know David Bowie (Q5383) instance of (P31) plant (Q756) is incorrect.

Disjointness is how the Semantic Web knows that David Bowie is not a plant. "But", you might say, "David Bowie is a human, and human is not declared as a subclass of plant, so we already know he is not a plant." Surprisingly, that is not the case. This is because the Semantic Web operates on the open world assumption (OWA), which is described nicely here. Disjointness in the Semantic Web is also explained well here and in slides 5-7 here. Emw (talk) 14:33, 4 January 2014 (UTC)

  Support, to enhance the possibilities of consistency checks and errors catching, especially with high level classes. TomT0m (talk) 16:15, 4 January 2014 (UTC)

First: it's a bad example. Second: How does this property supports us providing useful data for infoboxes? --Succu (talk) 18:45, 4 January 2014 (UTC)

Hi Succu, to understand better what is as sake here see hte Wikimedia grant by Markus Kroetsch, one of the maker of this project here. Wikidata is an ecosystem for which infoboxes are only a part of the truth. TomT0m (talk) 19:04, 4 January 2014 (UTC)

I know Markus, I know his grant - but you did not answer my question. --Succu (talk) 19:10, 4 January 2014 (UTC)

OK, then the answer is "it's not supposed to add any data in infoboxes". It's just another way to express constraints (like) such as one of, domain, range ...

Question: Both plant (Q756) and animal (Q729) are organism (Q7239). David Bowie (Q5383) is a organism (Q7239) is valid to. So why should I regard plant (Q756) and animal (Q729) as disjoint. --Succu (talk) 19:17, 4 January 2014 (UTC)

Because the organism class itself is not constrained. This statement just says, if it's a plant, it's not an animal, and converse. It does not say that if it's a plant it's not an organism. TomT0m (talk) 19:24, 4 January 2014 (UTC)

So what is necessary to be him not a bacteria (Q10876) or mineral (Q7946)? --Succu (talk) 20:05, 4 January 2014 (UTC)

To every instances of organism, it is enough to state that, as plant is a subclass of organisms, that (living) organisms are disjoint with minerals. For bacteria, we should look a bit closer to the subclass relationships beetween them. Any idea you could have ? TomT0m (talk) 13:18, 5 January 2014 (UTC)

  Support. This would be very useful for inferencing, and seems like a no-brainer. Klortho (talk) 19:39, 4 January 2014 (UTC)

Klortho, if this is a „no-brainer“ then how will you source such claims? --Succu (talk) 20:40, 4 January 2014 (UTC)

Well, I don't think opinions on talk pages have the same sourcing requirements as articles (or items), but I take your point that "no brainer" is an overstatement. From my perspective, it seems like an obvious choice to add because it's a pretty fundamental part of the OWL standard, and very useful for machine inferencing. You asked about infoboxes before, but keep in mind that that's just one of the use-cases for Wikidata, and a human-oriented one. While it is obvious to humans that "plant" and "animal" are disjoint, a machine couldn't make that assumption by itself. Statements using this property would be helpful to support queries using negation, like (a bit contrived) "list all the non-animal things that are native to Maryland". Klortho (talk) 01:42, 6 January 2014 (UTC)

  Comment this property can be useful as you told, but for big hierarchies could be difficult manage this: if I understand correctly, every item of a hierarchy should has statements of this property with the other items of the hierarchy itself. Is not complicated? --Paperoastro (talk) 15:03, 5 January 2014 (UTC)

How to use it is probably an open question, but I don't think it's a good reason not to have this property. We will figure out how to use it properly, and having a systematic rule to add it every time it is possible to do this might not be a good idea, maybe we could have a put it when somebody has identified a concrete problem that actually occurs policy, or when it's useful for some tool for some reason,I don't know. TomT0m (talk) 15:22, 5 January 2014 (UTC)

I don't think this is right: "every item of a hierarchy should has statements of this property with the other items of the hierarchy itself". The example User:Emw gave is a good one. "plant" and "animal" are part of a large, complex hierarchy, but you gain a lot even if all you do is to add one statement that they are disjoint sets. Then you know that every subclass of plant is also disjoint with animals (and every subclass of animals), and that any instance of plant, or any instance of any subclass of plant, is not an instance of (any subclass of) animal. And so a machine could deduce that a rose is not a cat, or (reiterating the example above) that David Bowie is not a plant. If more "disjoint" statement were added, at other levels of the hierarchy, of course that would be helpful, but not necessary. Klortho (talk) 01:31, 6 January 2014 (UTC)

That's true if we have a real tree, with disjoint leaves and in which each class at the same level are also disjoint. It's not the general case though. Maybe it would be easier to manage with an nary equivalent, owl all disjoint classes, with the list of disjoint subclasses as a qualifier of the statement in their parent leave. Or some higher level way to tag all classes of a whole tree as a hierarchy with these properties, with an item for the hierarchy itself. TomT0m (talk) 11:47, 6 January 2014 (UTC)

EDIT: Actually I was looking for DisjointUnion which is stronger and better in the case we know every subclasses of some hierarchy : Not only the subclasses are all disjoint, but the union of the listed subclasses is their parent class in the tree. TomT0m (talk) 19:05, 6 January 2014 (UTC)

I think we should to be aware of the implications and discuss them first. So I have a question. Assumig a family (Q35409) with five genus (Q34740) G1, G2, G3, G4, G5: how do I express they are disjoint to each other? --Succu (talk) 14:22, 6 January 2014 (UTC)

Did not see your comment, but my answer above is a good answer to your question, you say the class corresponding to your family is the disjoint union of the G1, G2, G3, G4, G5 classes. With the bonus that every instances of your genre is an instance of exactly one of the G1 ... G5 classes, no more, no less. TomT0m (talk) 19:09, 6 January 2014 (UTC)

TomT0m, so we need another property DisjointUnion? I'm I right that this property needs to know all affected genra? --Succu (talk) 20:54, 8 January 2014 (UTC)

Absolutely. If we are not complete about the gena, we should use AllDisjointWith (that's 3 properties), who just says that no individual is an instance of two of any G1...G5 pairs. TomT0m (talk) 21:30, 8 January 2014 (UTC)

Instances of taxa are rare. Recently some authors regarded some species of the formerly of AllDisjointWith genus Aloe (Q127134) as disjoint and established the new genera Aloidendron (Q13539278) and Aloiampelos (Q13539282). So how will we reflect this? --Succu (talk) 22:14, 8 January 2014 (UTC)

I see this as a separate discussion, that doesn't really address the usefulness (or not) of the "disjoint with" property. Whether or not an AllDisjointWith or DisjointUnion property gets defined in the future, this simple binary disjoint with property would still be useful, wouldn't it? Klortho (talk) 14:03, 9 January 2014 (UTC)

Klortho, taxa currently constitute about one tenth of wikidata items. Thats why I think the right place to discuss this matter is here. --Succu (talk) 20:36, 11 January 2014 (UTC)

No answer. So I'm forced to vote:   Oppose --Succu (talk) 22:35, 14 January 2014 (UTC)

Mmm, is there a assume good Faith on Wikidata ? You treat the deprecated belieth as the rest of the deprecated statement: you mark them deprecated, that's all, no difference. See User_talk:Emw#modallogic for a more extensive answer. TomT0m (talk) 00:20, 15 January 2014 (UTC)

User:Succu wrote, "Assuming a family (Q35409) with five genus (Q34740) G1, G2, G3, G4, G5: how do I express they are disjoint to each other?". With 10 statements: G1 → disjoint with → G2; G1 → disjoint with → G3; G1 → disjoint with → G4; G1 → disjoint with → G5; G2 → disjoint with → G3; G2 → disjoint with → G4; G2 → disjoint with → G5; G3 → disjoint with → G4; G3 → disjoint with → G5; G4 → disjoint with → G5. Since disjoint with is reciprocal, presumably the other ten could be inferred (automatically). Klortho (talk) 02:52, 15 January 2014 (UTC)

@Klortho: No, we would need an order of n² statements, the realation is not transitive as an equivalence relation. If <Bob> is not <Jessy> and <Jessy> is not <Bob>, we can't deduce that <Bob> is not <Bob>. This is true for an equality relation (an equivalence relation, symmetric, transitive and reflexive), not for a not equal relationship. That's why the n-ary AllDisjointWith property is interesting in such cases (we could express the list of arguments with qualifiers instead of like OWL does with a list of statements). TomT0m (talk) 12:05, 15 January 2014 (UTC)

Yes, that's right: order of n². Here, n=5. The number of statements is the (n-1)th triangle number. The 4th triangle number = 10. I didn't say transitive, I said "reciprocal", by which I meant (using your terminology) "symmetric". If <Bob> is not <Jessy>, then <Jessy> is not <Bob>. I agree that an n-ary AllDisjointWith property would be useful, but the point I'm trying to make is that the statements can be done with a single "disjoint with" property. And the broader point, in answer to User:Succu, is that this "disjoint with" property is useful, whether or not an n-ary AllDisjointWith property is ever implemented. 130.14.9.92 18:13, 15 January 2014 (UTC)

OK, lets us assume that genus Aloe (Q127134) consist of 500 accepted species (the actual number is a little bit higher). Than we need 124,750 statements. Assuming further a single new species is described. To make clear this species is destinct from all the others we have to add 500 more statements. A lot of statements to make clear what is clear by taxonomic defenition. --Succu (talk) 18:41, 15 January 2014 (UTC)

/o\ Sorry I totally read something that is not what you wrote, too fast or did not sleep enough /o\ TomT0m (talk) 18:44, 15 January 2014 (UTC)

Sorry to beat this dead horse, User:Succu, but I guess I still don't see why the fact that this property is not powerful enough to handle that use case means that we shouldn't have it at all. OWL has both a binary, and a (kludgy) n-ary relation. I think there are lots of cases of binary disjointedness where this would be helpful. Klortho (talk) 08:13, 16 January 2014 (UTC)

My use case (Q613417) is clearly specifed. But I think we should discuss this matter again later. Currently there is no rdf/owl-interface a reasoner could catch and make use of it. --Succu (talk) 19:58, 16 January 2014 (UTC)

  Support for TomT0m. --Paperoastro (talk) 15:50, 5 January 2014 (UTC)

  Oppose If you put one constraint based on that kind of relation this will be endless: a plant is not an animal, not a tool, not a machine, not a mineral,.... To be consistant we have to put all "not a ..." or create a new set of rules that will be difficult to apply. If the structure of "instance of" and "subclass of" is well done, you can define all the definitions which can be applied to an item by recursion and by definition all the rest can't be applied to your item. If you choose to define item with what they are and what they aren't, you have to cover all cases. If you choose to define the items only by what they are, by reasoning you can assume what they are not. Snipre (talk) 23:00, 6 January 2014 (UTC)

That's wrong, read the discussion. We have efficient solutions to manage that, see the discussion above. Plus the close world hypothesis you advocate for is probably not a good idea in a very open database like this one. I don't think for example we can deduce that James Bond car is not red because we know nothing about its color in the database. TomT0m (talk) 23:31, 6 January 2014 (UTC)

Comment: My initial impression of "disjoint with" is that it should only be used to say that two classes which share the same parent class should be linked. In other words, two species which share a genus might have the statement, whereas a genus in one family as opposed to a genus in a second family (with both families in the same order). What would have the disjoint with statement in this latter case would be the two family statements; then it is implied, as disjoint with is an inheritable statement, that the two genus are disjoint with each other.

At that case then, you can say that living thing is disjoint with non-living thing, and thus you never need to make the statement organism disjoint with machine, because there are no machines (currently) that we call machines that are both living and non-living.

Since we're on that topic then, would we actually say that living thing and non-living thing are disjoint if we know of the existence of cyborgs (or at least can imagine such an idea), for example? Or of certain organic and non-organic systems which are harvested to create energy such as an algae solar pool? How does disjointedness interact with qualifiers, such as a ship being first termed a destroyer and then later in its life a battleship? How does it interact, as is common in biology (and I'm sure elsewhere), that certain taxa are organized and re-organized and sometimes end up in two disjoint groups? --Izno (talk) 00:14, 7 January 2014 (UTC)

"How does disjointedness interact with qualifiers, such as a ship being first termed a destroyer and then later in its life a battleship?"

Being an instance of two disjoint classes at the same time would make Wikidata inconsistent. If a ship was a destroyer and later transformed into a battleship, then I do not see that as inconsistent. This suggests that when reasoning with disjointness, we need to account for temporal qualifiers in rdf:type. Perhaps we could do this by ranking P31 claims so that the most current claim is ranked higher than P31 claims that are no longer valid. Emw (talk) 12:17, 7 January 2014 (UTC)

We also have to take into account sources in some way then; example, some sources will express that item A is of type B according to sources D, E, and F, while item A is of type C according to sources G and H, where types B and C are disjoint. Real world example: there is a ship (class?) in the Swedish Navy which according to the Swedish Navy is classified as a patrol boat, while other navies and sources consider it to be a frigate. Ranking may be one solution to this, but there will be other cases where there is no highest-ranked type but instead two or more types ranked of the same highest level (i.e. "preferred" in Wikidata). What then? This is the same type of question I levied about taxa, I suppose, but ships are another convenient one to pick on. :) --Izno (talk) 20:30, 7 January 2014 (UTC)

I don't understand why this would be an issue peculiar to this property. Isn't it true that you can always have contradictory statements in Wikidata, each of which have different sources? Klortho (talk) 03:37, 10 January 2014 (UTC)

Absolutely. I'm just asking what "disjoint with" means on a particular item's page when that's the case. --Izno (talk) 17:01, 11 January 2014 (UTC)

•   Oppose Would bloat items. hydrogen (Q556) is disjoint with helium (Q560), lithium (Q568), beryllium (Q569), boron (Q618), etc. --Jakob (talk) 23:50, 15 February 2014 (UTC)

  AllDisjointWith would solve this problem

  Oppose. All species are disjoint with other species and the same for other taxon ranks so this property is no additional info in those case. I might reconsider if you can come up with an example where this property would actually be useful. Filceolaire (talk) 20:48, 24 February 2014 (UTC)

Template:Filceolaire This information is good both for inferencing and for consistency checks (therefore). It's no information added because you know those classes are disjoint, but a machine whould not know it unless we tell him. It would for example be not a problem that a pig is noted as both a pig and a plant. If we want that a machine and a reasoner catch this, we will have to inform it, give him a hint. This is the goal of this property, as an item can with no problem be an instance of several classes. TomT0m (talk) 16:35, 26 February 2014 (UTC)

  Not done Lack of consensus.--Micru (talk) 17:37, 3 March 2014 (UTC)

Discussion

Motivation. 77.56.53.183 16:41, 21 February 2014 (UTC)

Oppose. This already exists. Use language of work or name (P407) as a 'qualifier' field or search for P:language to see other language properties. Filceolaire (talk) 19:15, 24 February 2014 (UTC)

  Oppose in agreement with Filceolaire Casper Tinan (talk) 19:37, 24 February 2014 (UTC)

Makes sense. I have tried it out: Q71385 Is that what you mean? 77.56.53.183 16:24, 27 February 2014 (UTC)

It is the other away round. Main property : IPA transcription (P898). Qualifier : language of work or name (P407). I have modified Pidgin (Q71385) accordingly.Casper Tinan (talk) 16:38, 27 February 2014 (UTC)

I see :-) Thanks for your help. 77.56.53.183 16:41, 27 February 2014 (UTC)

•   Not done Withdrawn, duplicate. --Jakob (talk) 20:54, 27 February 2014 (UTC)

Discussion

In adding an example road sign (Q15830845), I noted the apparent absence of a general Property for "Related item", the Wikidata equivalent of a See Also. Sfan00 IMG (talk) 19:04, 27 February 2014 (UTC)

  Oppose There is no sense in this, if the item is associated there is probably a more specific property or path that links them. Reasonator does that already more or less when displaying related images. TomT0m (talk) 20:35, 27 February 2014 (UTC)

Ideally what's needed for the specific instance is a Related Sign property, but I felt that was too specfic. Sfan00 IMG (talk) 21:44, 27 February 2014 (UTC)

Speaking of Road signs, can we start the process for adding about 10 new propeties? 21:44, 27 February 2014 (UTC)

  Not done Lack of support.--Micru (talk) 17:40, 3 March 2014 (UTC)

Discussion

Yiyi .... (talk!) 13:14, 25 November 2013 (UTC)

•   Support--Micru (talk) 10:18, 29 November 2013 (UTC)
•   Comment why is this proposed property needed when we have award received (P166). e.g. Justin Zook (Q6318298). See Wikidata talk:Sport results task force#Medals. 'sports title held' is a more precise description, however if the award is a subclass of sports award (Q15254946) then we know it is a sports title. Are there sports titles which are not an award? John Vandenberg (talk) 13:24, 29 November 2013 (UTC)

I don't know in English, but in Italian we have onorificenza (that is an award conferred to a notable personality following his career or merits; for example, in sports there is Star to sports merit (Q3972928)) and "titolo sportivo" (that is gained as a result of a sporting competition). For example, Pietro Mennea (Q5444) has the "onorificenza" Commander of the Order of Merit of the Italian Republic (Q14539729) and won the title ("titolo sportivo") of Olympic champion in 200 meters. I think they are different things. -- Yiyi .... (talk!) 15:50, 29 November 2013 (UTC)

It sounds like onorificenza is still an award; who confers it? In Australia we have the Australian Sports Medal (Q1649458) which sounds similar, and you can see on Kevin Coombs (Q6396063). John Vandenberg (talk) 17:00, 29 November 2013 (UTC)

It's given by Italian National Olympic Committee (Q1114833). But, I repeat: I think they are different things, because a medal is given for ONE competition, while a "onorificenza" is an award given following a long carrer (like Pritzker Architecture Prize (Q133160) or Knight of the Legion of Honour (Q10855271)). -- Yiyi .... (talk!) 19:33, 29 November 2013 (UTC)

Sounds like something lost in translation. I suppose in English it would be the difference between "award" and "honour", though. An award would be a medal for winning a competition, but an honour would be a medal of service (Q3042865) or an appointment to the Order of Canada. Ajraddatz (Talk) 05:05, 3 December 2013 (UTC)

'award received' refers to any instance of (a subclass of) award (Q618779). I think the Australian equivalent in Medal of the Order of Australia (Q9682417) or Australian Sports Medal (Q1649458), both of which are a Australian honours system (Q3721675). Or maybe it is more like Sport Australia Hall of Fame (Q15271575). e.g. Louise Sauvage (Q432941) has received of these awards, and more. John Vandenberg (talk) 09:00, 3 December 2013 (UTC)

@Ajraddatz, exactly! I mean just that, but my English would not let me :( -- Yiyi .... (talk!) 12:55, 3 December 2013 (UTC)

So, this discussion seems a little firm: could we create this property? -- Yiyi .... (talk!) 10:52, 21 December 2013 (UTC)

• I have mentioned this discussion at Wikidata:Project chat#Decoration and constraints. John Vandenberg (talk) 08:49, 30 December 2013 (UTC)
•   Oppose Imho, it is redundant with award received (P166) and therefore not needed. Casper Tinan (talk) 09:03, 5 February 2014 (UTC)

  Not done Yiyi, Ajraddatz, John Vandenberg, Casper Tinan: Unclear support. Re-open discussion if needed in the context of a sport task force, considering the whole set of properties needed for sport related items.--Micru (talk) 21:46, 4 March 2014 (UTC)

P21 has been labeled 'sex' since February and has always listed restrictions in its description that indicate it concerns the biological sex of the subject. The property is used in almost a million items. Properties like mother (P25) and father (P22) have constraints based on the value of P21.

However, P21 doesn't handle the distinction between sex and gender well, making P21 statements about transgender people like Chelsea Manning (Q298423) complicated. One solution that has been proposed is to rename P21 from 'sex' to 'sex or gender' (which may likely end up being 'gender or sex'). A separate proposal would create separate properties for 'sex' and 'gender'. This proposal is intended as a wider review for the latter.

Both ideas have gotten support at different times from mostly non-overlapping audiences, including Sj, Shii, Maximilianklein, Bluerasberry, 朝彦, Jaredzimmerman_(WMF), Emw, Tobias1984, Ajraddatz, Avenue, Zolo, Arctic.gnome and Bever.

The proposed property includes both gender identity and gender expression (Q15404978). Human Rights Campaign defines gender expression as: "External manifestation of one’s gender identity, usually expressed through masculine, feminine or gender-variant behavior, clothing, haircut, voice or body characteristics. Typically, transgender people seek to make their gender expression match their gender identity, rather than their birth-assigned sex."

To avoid having redundant 'sex' and 'gender' claims in almost all Wikidata items about people, this property would not be applied for cisgender individuals. This omission would also apply to the alternative proposal. Here's a comparison:

Option A (this proposal):

• Chelsea Manning (Q298423)

sex (P21) male (Q6581097)

gender (Px) female (Q15304678)

• Alexei Nikolaevich, Tsarevich of Russia (Q154045)

sex (P21) male (Q6581097)

Option B (the proposal discussed here):

• Chelsea Manning (Q298423)

gender or sex (P21) male (Q6581097) specifically biological sex (Q290)

gender or sex (P21) female (Q15304678) specifically gender identity (Q48264)

• Alexei Nikolaevich, Tsarevich of Russia (Q154045)

gender or sex (P21) male (Q6581097)

Both of these approaches have advantages and disadvantages. Discussion of that is linked from the points listed here. In brief, Option A accepts the possibility of occasional false positive claims about a person's sex to preserve constraints for properties like 'mother' and 'father' that assume biological sex, and to keep a clean separation of concerns between what everyone seems to agree are separate properties. Option B ensures that we will have less-than-occasional false positive claims about a person's sex, but it weakens inferences we can make with properties like 'mother' and 'father', and does away with a clean separation of concerns.

While they differ significantly, both options acknowledge that we need a better way to structure data for transgender people. If this proposal doesn't get sufficient support, then we would go with Option B. I just wanted a final, wider community review of this alternative before we make a significant change to one of Wikidata's most popular properties. Emw (talk) 05:51, 23 December 2013 (UTC)

•   Oppose When you consider the fall out of ending the use of the "GND attribute", I hate to see another big change that does not come to a working conclusion. An alternate way of dealing with a "Chelsey Manning" case is to use qualifiers where a date is used to indicate such a change. Having another attribute to indicate a changed gender is imo not really useful. Being a father or mother is the indication of functioning sexuality. On a similar note, a eunuch is not really male either; he never reached puberty and therefore never became a functioning male. It is never considered in these discussions but we deal with them in Wikidata. Thanks, GerardM (talk) 09:59, 23 December 2013 (UTC)

Gerard, a matter of contention in Property_talk:P21#Transgender_.2F_Cisgender_changes is whether being a father or mother entails the sex of a subject. Emw (talk) 14:53, 25 December 2013 (UTC)ere

There is a difference between being a parent and being a father or a mother. Parent indicates a role re upbringing of a child. Father / mother are typically the parents of a child. At the time of conception these people were sexually active and effective at that. As to this whole transgender issue what is the problem with using qualifiers to indicate this? GerardM (talk) 17:21, 25 December 2013 (UTC)

•   Oppose For most people we have no way of knowing whether their biological sex matches their gender expression and we never will know this. See the lengthy discussion at Property_talk:P21#Transgender_.2F_Cisgender_changes. Having a combined property accurately reflects this ambiguity. Where we do have more info this can be expressed using qualifiers. Filceolaire (talk) 12:07, 23 December 2013 (UTC)
•   Oppose for now. I think this one needs to be an RFC where we map out all variations and ensure we have a well documented structure. At present I prefer option B, as these are tightly entwined properties and if a person has undergone changes to either, the details and history of those changes are best kept in a single property. For most cases, a single value without qualifiers is sufficient. That means someone trying to use the data can request a single property and all qualifiers; if the result is a single item, use it; if there are qualifiers or multiple results, the reuser knows 'its complicated'. If we split sex and gender, all reusers need to request two properties and compare them to determine whether 'its simple' or 'its complicated'. The reality is if there are two properties, many reusers will only look at one, and will display the wrong result. FWIW, this may not be the politically correct method of encoding this data, and it doesnt encode all variations, but medical condition (P1050) => gender dysphoria (Q1049021) or transsexualism (Q190965) or true hermaphroditism (Q7847568) and significant event (P793) => gender-affirming surgery (Q1053501) (with a date qualifier, and maybe a sex qualifier?) is one way to accurately record some important data items. See w:Gender identity disorder , http://www.genderpsychology.org/transsexual/icd_10.html , etc. John Vandenberg (talk) 17:01, 23 December 2013 (UTC)

John, I hadn't considered it that way, but I think your scenario could actually be seen as a disadvantage of Option B. It implies that users will need to include a nested query whenever they want to ensure they are dealing with statements only about sex or only about gender. And unless we decide to make the sex or gender statement preferred, having both properties in one multi-property seems like it would require users to add boilerplate code to all queries involving P21 in order to ensure they get a single statement value. That seems like it would raise the barrier to entry for querying demographic information in Wikidata.

Also, how do you figure that having biological sex and gender expression in two different properties means users are more likely to display the wrong result? Can you give an example of a wrong result you're thinking of?

How would constraints for properties like 'mother', 'father', 'brother' and 'sister' be handled with Option B? Do we have any examples of constraints based on qualifiers? Does OWL support constraints based on qualifiers? We have favorable answers for all of these with Option A, but I don't think we do with Option B. Emw (talk) 03:27, 24 December 2013 (UTC)

Most re-users don't want to make statements about only sex or only gender. Mostly they want to have one value: male, female, or 'its complicated'. The data re-user may drill into the 'its complicated' subset if it is significant within their dataset. An example of displaying the wrong result: If a person is sex: male and gender: female, if the data re-user only looks at 'sex', they will group them into the male bucket.

sex assignment is a "fact" in most cases - only parts of the world where there are poor birth records is it debatable what sex was assigned at birth, and for most people there is no debate as they and everyone else happily accepts their sex assignment at birth. For gender identity, it is complicated. The taxonomy of gender is in flux in science. The acceptance of gender complexity varies greatly across cultures. Re-users who do want to make accurate demographic queries will be defining their own buckets, with granularity and composition determined by their own needs, country definitions, or cultural biases. They need to check the qualifiers and the sources of each statement in order to associate trust-levels with those statements. Anyone doing serious demography will replace : gender=female (source: imported from Wikipedia) with gender=unknown. The year that sex/gender changes occur is also very significant (child vs adult), and each country can have its own age brackets to differentiate child-sexuality-adjustment vs adult disorders. Some re-users will only be interested in gender when a sex change has occurred. etc.

I don't understand the problem with mother & father. In Option B, a parent may have 'sex/gender' => ('male' [qualified],'female' [qualified]), in which case the constraint on father and mother will both work. It isnt possible to accurately constrain mother & father on sex or gender. Like sex/gender, mother and father are both state defined (birth assigned) roles and fluid personal-choice roles not constrained by sex or gender or by time. In humans, a biological male may expresses as female but behave as a father or be listed as a father on adoption papers because the country doesnt recognise them as female. But then the state recognises them as a female or they undergo a sex change, and they wish to be known as the mother. But maybe the child is old enough to reject the parents wish to be referred to as the mother. John Vandenberg (talk) 05:07, 24 December 2013 (UTC)

I think that's a reasonable position, though I disagree with a few points. For example, if a user is querying only sex and thus ends up grouping into the male bucket a person sexed male and gendered female, then I don't see how we can say that is necessarily wrong. If we're talking about a biographical infobox on English Wikipedia, then of course it is wrong in the sense that it would be a major editorial error of omission. But I don't see that as a realistic scenario. If biographical infoboxes on Wikipedia are interested in sex, then gender is almost certainly also relevant. So the main consumers of Wikidata would include both properties in their display. Option B requires users to do reasoning about two properties within the results of one property, which seems like it would be at least as complex as doing so within the results of two properties.

Your points about the complex definition of 'mother' and 'father' are worth considering when talking about constraints, as these properties are often used in introductions to the topic. See OWL 2 Primer: Complex Classes. For example, is a transgender (note: not transsexual) man a mother or a father, or both? If it's both, then we cannot say that 'mother' and 'father' are disjoint, etc. Emw (talk) 14:41, 24 December 2013 (UTC)

• I fail to understand what is being proposed here. Like John, I would want to see this completely mapped before I committed to something. I would help make a proposal to map this if pinged and if I knew where to comment and what was needed. Blue Rasberry (talk) 02:36, 24 December 2013 (UTC)
•   Comment I think representing sex and gender in separate properties would be better, but when the responses above are combined with the comments in Property_talk:P21#Summary, I think the responses above indicate there is consensus to represent sex and gender in one property. Kudos to Jared and Filceolaire for initiating that proposal and laying out the rationale, and thanks to John for the cogent replies above. I withdraw this proposal. Emw (talk) 14:41, 24 December 2013 (UTC)
•   Support Is it too late for this? I was afraid of that -- I saw this proposal two days ago, but didn't have time to catch up on all the discussions. Even though User:Emw withdraws it, can I re-open it? To me, it seems pretty obvious that option A above is the right way to go, and I'm not convinced by any of the other arguments above. I think if you go with Option B, it will do irreparable harm to the whole platform. Please let me know where the latest discussions are on this topic, and what the currently open proposals are, and I will write my rationales there. I would certainly like to see Option A, as Emw has outlined above, continue to be in the running. Klortho (talk) 08:30, 25 December 2013 (UTC)

Klortho, the proposal for Option A is available at Property_talk:P21#Updated_proposal. Relevant discussion of the issue is available in that section and its parent section. Emw (talk) 14:53, 25 December 2013 (UTC)

  Not done As per comments.--Micru (talk) 21:40, 4 March 2014 (UTC)

Discussion

Motivation. The idea is to separate circumstances from the medical cause (cause of death (P509)), to provide more structured data. See the talk here: Property_talk:P509. In modern times the cause of death normally has a specific meaning, and is determined by a medical examiner, e.g. the coroner. So, let's not mix-up these two things. Danrok (talk) 17:25, 5 February 2014 (UTC)

  Support --Tobias1984 (talk) 18:56, 5 February 2014 (UTC)

  Support — TintoMeches, 20:09, 5 February 2014 (UTC)

  Comment. I encourage users interested in this kind of data to read Documenting Death -- The Certificate and the US Standard Death Certificate. For even more detail, see the CDC's Physicians' Handbook on Medical Certification of Death. More detail on "manner of death", which I think would be a better label for this property, is available on pages 42 and 43 of that CDC document.

"Homicide" and "automobile accident" are widely reported as "cause of death" by organizations like the CDC (here) and WHO (here). As seen on the US Standard Death Certificate, though, they are slightly different concepts: "homicide" and "accident" would be specified as the "manner of death", whereas some disease or health problem (ideally, something with an ICD-10 code) would be specified as a "cause of death".

The death certificate of Michael Jackson (certificate, amendment) is informative here. It provides fields for "manner of death" (field 119 in certificate, filled in as "homicide" in amendment) and "how injury occurred" (field 124 in certificate, filled in as "intravenous injection by another" in amendment). It also shows "acute propofol intoxication" as the most immediate cause of death (field 107A, the closest match for our cause of death (P509) property) and "benzodiazepine effect" as "other significant conditions contributing to death but not resulting in the underlying cause" (field 112).

As a matter of modeling, I would capture this information in properties, not qualifiers, because qualifiers will not be queryable in the foreseeable future. Just order the properties in the UI so they're clustered together, like we do for 'place of death' and 'date of death', etc. I would support this property if it were relabeled "manner of death" and the documentation updated to indicate that it should have values limited to "natural", "accident", "suicide", "homicide", "pending investigation" or "could not be determined". Emw (talk) 05:13, 6 February 2014 (UTC)

  Comment I see that the WHO are using the label Specified external causes of death rather than just cause of death, on this page here: Availability and quality of cause-of-death data for estimating the global burden of injuries. I think that Specified external causes of death is essentially the same as circumstances of death (circum- being similar to external). So, perhaps we should rename cause of death (P509) to internal cause of death, and call this new one external cause of death? Both of these terms seem to be in common use, one example here: Alcohol Prohibition and Infant Mortality (first paragraph). Danrok (talk) 01:01, 7 February 2014 (UTC)

Danrok, the WHO paper we're looking at here, Availability and quality of cause-of-death data for estimating the global burden of injuries, only considers external causes of death. That paper is narrowly focused and has about 20 citations. The landmark WHO publication The Global Burden of Disease: 2004 Update, cited over 2700 times since 2008, has some analysis on deaths by "external cause of death" (Figure 25, page 49), but it doesn't use the term as categorically different than "cause of death". The Depew paper you note is marked as a draft; it has no citations. None of these papers indicate that dichotomizing "cause of death" into "external cause of death" and "internal cause of death" is common in controlled vocabularies.

Google Scholar gives a rough basis for comparison:

• "external causes of death": 2,180 results
• "circumstances of death": 7,170 results
• "manner of death": 14,000 results

The last phrasing, "manner of death", also has the significant benefit of appearing in a major controlled vocabulary, the US Standard Death Certificate. Manner of death includes external causes of death -- i.e., accident, suicide, homicide -- they're just high-level. Page 43 of the CDC Physicians' Handbook notes "Deaths not due to external causes should be identified as 'Natural'." The difference between "manner of death" and "cause of death" is specificity: the former has 4 broad classes (plus 2 for uncertain causes) and the latter gets a precise value. The death certificate of Paul Walker, an American actor, is a good example of where an external cause of death is listed as both the cause of death and manner of death, at different granularities: the cause was "combined effects of traumatic and thermal injuries" and the manner was "accident". With the rubric from the external causes WHO table, the cause of death would likely be captured in controlled vocabulary as an unintentional car injury (with a code somewhere in the ICD-10 range V40-V49) and fire (a code in X00–X19). The manner of death would be the broad cause accident (Q171558).

So all external causes of death are still causes of death. I don't think relabeling our "cause of death" property (P509) "internal cause of death" would be a good idea. "Cause of death" is a fundamental and universally recognized property in demography. It should be used to capture an underlying cause of death, using items linked to ICD-10 codes. If we want another related property similar to cause of death (P509), then I think structuring it only the lines of manner of death, which would include "natural cause", would be best. Based on the prevalence of the term in relevant literature shown above and its usage by a major health organization, I would label that property "manner of death", with alias "circumstances of death". Emw (talk) 13:47, 7 February 2014 (UTC)

OK, I'm happy to go with "manner of death". Danrok (talk) 14:00, 7 February 2014 (UTC)

I haven't found the official vocabulary yet, but in German "Todesumstände" might be pretty close. --Tobias1984 (talk) 16:45, 7 February 2014 (UTC)

• Danrok, Tobias1984, others, I have updated the proposal documentation per above. Please indicate your support or opposition. Emw (talk) 00:32, 14 February 2014 (UTC)

Is the allowed values list a complete list, or can there be others? Danrok (talk) 03:43, 14 February 2014 (UTC)

  Support Danrok (talk) 20:21, 18 February 2014 (UTC)

• @Danrok, Emw, Tobias1984, TintoMeches:   Done --Jakob (talk) 01:07, 28 February 2014 (UTC)

Discussion

  Comment This has been suggested as Ivan says that we cannot have upper stages in launch vehicle as they are very different in Russian. They are also different in English, but both languages use them together eg Proton/Briz-M. Secretlondon (talk) 19:34, 10 June 2013 (UTC)

  Comment Have the problems with this proposal been resolved? --Tobias1984 (talk) 13:02, 30 July 2013 (UTC)

Ivan A. Krestinin, Secretlondon, Tobias1984, what do you think of using powered by (P516) with qualifier P992 (P992) => booster (Q741745) or space tug (Q1958838)?--Micru (talk) 11:50, 24 November 2013 (UTC)

Currently I would prefer your solution, possibly with using "instance of" as the qualifier. --Tobias1984 (talk) 17:53, 24 November 2013 (UTC)

I do not think that P516 is applicable for this case. This usage is equals to Benedict XVI (Q2494) <powered by (P516)> Mercedes-Benz M-Class (Q849935). — Ivan A. Krestinin (talk) 07:53, 25 November 2013 (UTC)

But then it would be just easier to request a property for "launch configuration" and add all the data of the launch, and not only the upper stage. It would even be possible to use time and height qualifiers to reconstruct the whole launch. The term upper stage could be avoided by just giving the stages consecutive numbers. --Tobias1984 (talk) 14:00, 25 November 2013 (UTC)

You propose group some subset of properties. But currently we have no such functionality. Somewhere I seen request for some grouping elements, but it does not implemented now. No need to avoid this missing using qualifiers. Qualifiers was developed for another purposes. Now about upper stages: maybe you are confused by English name of this device. In English it has "stage" word in name. This confuses with rocket stages. But this is not part of rocket, this is separate device. It start its work after separation from rocket. It is developed and produced by different organizations. For example Russian upper stage Fregat (Q1453740) can be used with Ukrainian Zenit (Q1748964) rocket. — Ivan A. Krestinin (talk) 19:03, 25 November 2013 (UTC)

Ivan A. Krestinin: If you check the usage of p516 you will see that it is a common use. If you want a specific property for rockets, then "launch configuration" can be used.--Micru (talk) 18:51, 25 November 2013 (UTC)

Is Benedict XVI (Q2494) <powered by (P516)> Mercedes-Benz M-Class (Q849935) correct claim? — Ivan A. Krestinin (talk) 19:05, 25 November 2013 (UTC)

Tobias1984, I think Ivan is right that the English name (upper stage booster) is misleading, because it is not part of the "launch configuration". A more appropriate name would be "payload deliverer" or "space tug" (reference), since it is the vehicle that once all the stages are gone, sets the payload into the right orbit (see this video by the end).--Micru (talk) 19:30, 25 November 2013 (UTC)

  Not done Lack of support, lack of use cases.--Micru (talk) 17:48, 3 March 2014 (UTC)

Why "lack of use cases"? It is needed for Template:Infobox spacecraft (Q6050248), Template:Infobox space telescope (Q6149570), Template:Infobox communications satellite (Q13965330). — Ivan A. Krestinin (talk) 19:20, 3 March 2014 (UTC)

@Ivan A. Krestinin: Which parameter of the infobox would represent this property? I couldn't find any equivalent in the languages I speak, if you could point to some examples it would be great.--Micru (talk) 19:31, 3 March 2014 (UTC)

Please see en:Türksat 4A, parameter "Rocket" contains two values: "Proton-M" (this is "ракета-носитель", rough translation is "rocket for payload deployment") and "Briz-M" (this is "разгонный блок", rough translation is "upper stage"). Another sample: en:Kosmos 2466, it was deployed by same launch vehicle "Proton-M", but another upper stage "DM-2". More example: en:Kosmos 2479, "Proton-K" and "DM-2". — Ivan A. Krestinin (talk) 19:48, 3 March 2014 (UTC)

  Done User:Ivan A. Krestinin, thanks for your examples, I have created the property.--Micru (talk) 09:47, 4 March 2014 (UTC)

Great thank. This was very long discussion. — Ivan A. Krestinin (talk) 17:03, 4 March 2014 (UTC)

Discussion

•   Comment do you intend the scientific instrumentation? This property can be useful also for terrestrial telescopes. --Paperoastro (talk) 00:19, 20 December 2013 (UTC)

• Yes. It could even work for laboratory equipment: electron microprobe (Q911272) == X-ray detector (Q8041571) (or the precise x-ray detector used). --Tobias1984 (talk) 08:51, 20 December 2013 (UTC)

•   Support this property could have a large range of application. --Paperoastro (talk) 16:55, 20 December 2013 (UTC)
•   Comment how about using the has part(s) (P527) property? Danrok (talk) 21:37, 20 January 2014 (UTC)
•   Support Filceolaire (talk) 21:46, 24 February 2014 (UTC)

  Done Tobias1984, Paperoastro, Danrok, Filceolaire => carries scientific instrument (P1202).--Micru (talk) 20:38, 4 March 2014 (UTC)

Discussion

•   Support --Paperoastro (talk) 16:56, 20 December 2013 (UTC)
•   Support Danrok (talk) 21:35, 20 January 2014 (UTC)
• @Tobias1984, Paperoastro, Danrok:   Done --Jakob (talk) 21:32, 24 February 2014 (UTC)

Discussion

As you know we already have property ISO 639-2 code (P219). But ISO 639-2 contains not a single value for each language, but pair of values (ISO 639-2/T and ISO 639-2/B). For most languages codes are the same, but for 20 they are different. Single value requirement was removed for ISO 639-2 code (P219). This is inconvenient in cases when it is necessary to use ISO code as a key. I propose to rename the existing parameter to ISO 639-2/T and create a separate property for ISO 639-2/B. --putnik 23:53, 15 December 2013 (UTC)

  Not done Not enough support.--Micru (talk) 22:10, 4 March 2014 (UTC)

Discussion

GOST 7.75-97 describes two language codes: literal and numeric. We already have property GOST 7.75–97 code (P278) for literal one. I suggest to add another one for numeric. --putnik 23:53, 15 December 2013 (UTC)

  Not done Not enough support.--Micru (talk) 22:11, 4 March 2014 (UTC)

Discussion

Motivation. Oursana (talk) 13:03, 21 January 2014 (UTC)

Could you please add an example that uses local items in the example? (Example: Universe (Q1) "surface" Earth (Q2), showing the claim made on page Q1 has the value Q2.) Google Translate isn't being very helpful with your proposal. --Izno (talk) 03:13, 31 January 2014 (UTC)

I tried to. I had to correct a small error in the template/description, just see above, and do not know where to state that generally.--Oursana (talk) 23:18, 2 February 2014 (UTC)

How we would normally write it would be Curtius Museum (Q2304164) instance of (P31) art museum (Q207694), but since we do not have the property created yet and it wouldn't be of the item datatype, what we would say is Curtius Museum (Q2304164) "surface" 8,163 m^2.

That said, I think this may be a duplicate proposal, since I would expect that someone has proposed an "area" property already. I can't find the list of properties which are approved but haven't been created yet due to lacking the correct datatype (number with units). --Izno (talk) 20:47, 3 February 2014 (UTC)

exactly Wikidata:Property proposal/Pending/2#Area. I am curious how we use square metre (Q25343) with it. ; see Wikidata:Requests for comment/Dimensions and units for the quantity datatype#Area

•   Done --Oursana (talk) 23:27, 3 February 2014 (UTC)

  Oppose. use proposed property 'Area' instead. Filceolaire (talk) 21:43, 24 February 2014 (UTC)

  Strong oppose wrong datatype --Pasleim (talk) 14:27, 25 February 2014 (UTC)

  Not done As per comments.--Micru (talk) 17:33, 3 March 2014 (UTC)

Discussion

•   Support as nominator. This code is needed to assign population data to each municipality and province in Spain. It's bestowed by Instituto Nacional de Estadística and amply used in es-Wikipedia to automatize changes in population data.Totemkin (talk) 14:29, 22 February 2014 (UTC)

  Not done @Totemkin: There is already INE municipality code (P772).--Micru (talk) 17:30, 3 March 2014 (UTC)

Ups. I swear by God I didn't notice!! Maybe it wasn't imported to Wikidata from infoboxes in Spanish Wikipedia because it's generally splitted there into "cod_provincia" (2 digits) and "cod_municipio" (3 digits), instead of field "cod_ine" (5 digits). I'm sorry, my sincere apologies. It won't happen again, I'll try to check properties before a request. Thanks, @Micru:.--Totemkin (talk) 16:01, 4 March 2014 (UTC)

Discussion

Motivation. GZWDer (talk) 09:20, 23 November 2013 (UTC)

  Oppose. We should have a more general qualifier that can be used with many different properties. See 'Wikidata:Property_proposal/Generic#specifically. Filceolaire (talk) 00:55, 14 December 2013 (UTC)

•   Not done No consensus, no further discussion in the past 3 months. --Jakob (talk) 19:01, 3 March 2014 (UTC)

Discussion

Даст возможность указывать ссылки на бассейны рек из их карточек. See ru:Категория:Категории бассейнов рек по алфавиту. Мастер теней (master of shadows) 20:48, 1 February 2014 (UTC)

  Support — Ivan A. Krestinin (talk) 18:25, 3 February 2014 (UTC)

  Question Why not just say Danube (Q1653) => topic's main category (P910) => Category:Danube basin (Q6718182)? --Tobias1984 (talk) 18:34, 3 February 2014 (UTC)

River category (Category:Danube (Q8363128)) is more general set than river basin category (Category:Danube basin (Q6718182)). — Ivan A. Krestinin (talk) 18:52, 3 February 2014 (UTC)

  Support--Kosun (talk) 11:16, 4 February 2014 (UTC)

  Support--LEhAN (talk) 20:53, 4 February 2014 (UTC)

  Oppose @Ivan A. Krestinin: Why not use Danube (Q1653) <a property for river water basin> <a new item for Danube basin> topic's main category (P910) Category:Danube basin (Q6718182)? see the proposal below.--GZWDer (talk) 11:19, 21 February 2014 (UTC)

GZWDer's proposal below sounds good! -- Lavallen (talk) 11:50, 21 February 2014 (UTC)

  Question Can this data be queried in infobox? — Ivan A. Krestinin (talk)

@Ivan A. Krestinin: You mean, GZWDers proposal below? - Yes, but not today, there is a critical bug missing for that. -- Lavallen (talk) 17:05, 25 February 2014 (UTC)

As I see this critical bug exists for very long time and there is no planes to fix it in observing time... So we need live with it. Additionally GZWDers proposal causes creation of huge number of items without sitelinks. As I see many users dislike such items. — Ivan A. Krestinin (talk) 19:59, 25 February 2014 (UTC)

•   Done There seems to be consensus to create this. --Jakob (talk) 19:06, 3 March 2014 (UTC)

Discussion

  Comment This is different from connecting line (P81). connecting line (P81) is desired to be set as the physical line which runs through the station. There are cases (in Japan, for example), where many different services may run under the "offical name" of the same line. For example, the aforementioned Chūō Line (Rapid) (Q1191297) is a part of Chūō Main Line (Q1078110), the official name of the physical track. Its local counterpart, Chūō-Sōbu Line (Q1091295) is also under the same physical track. --Wanderer28 (talk) 13:42, 17 February 2014 (UTC)

  Support --Konggaru (talk) 16:21, 17 February 2014 (UTC)

  Comment (More notes) For an explanation to a possible uncertainty arising from why "所属路線" (which means "belonging line") in ja:template:駅情報 (Station info), the Japanese Wikipedia, as far as I know, does not explicitly state the connecting service and line unless there is a discrepancy between the names of the two. Usually in their infobox there will be a small note describing the official name of the line. -- Wanderer28 (talk) 05:59, 18 February 2014 (UTC)

  Support For new build metros the line/route/track and the service are the same but if it runs over legacy track then they are not. Pretty much all long distance services run over multiple routes, even new build ones - the Paris London Eurostar runs over HS1 and Channel Tunnel and TGV Nord for example. Filceolaire (talk) 22:05, 24 February 2014 (UTC)

• @Wanderer28, 콩가루, Filceolaire:   Done --Jakob (talk) 14:15, 25 February 2014 (UTC)

  Support Per 'jetspecs' infobox. Joshbaumgartner (talk) 02:07, 3 October 2013 (UTC)

  Oppose as string. Data is not structured enough in this example. Why not:

• has oil system = dry sump (Q779325)

• pressure = 275.8 kPa

--Tobias1984 (talk) 14:13, 25 November 2013 (UTC)

  Not done wrong data type. Danrok (talk) 16:03, 5 February 2014 (UTC)

Discussion

Motivation. GZWDer (talk) 11:20, 19 January 2014 (UTC)

  Comment Basically, this can be done with based on (P144). --Rezonansowy (talk) 21:59, 20 January 2014 (UTC)

  Not done As per comments.--Micru (talk) 17:16, 3 March 2014 (UTC)

Discussion

International identifier. Infovarius (talk) 13:05, 20 January 2014 (UTC)

  Support Pretty useful. --Rezonansowy (talk) 22:00, 20 January 2014 (UTC)

  Comment Are there any other numbering systems for other composers? Danrok (talk) 13:17, 30 January 2014 (UTC)

Sure, see w:Catalogues of classical compositions. --Rezonansowy (talk) 13:42, 31 January 2014 (UTC)

  Oppose we have a more generic mechanism with catalog code (P528) and catalog (P972) subproperty : see Requiem (Q207875). Xmlizer (talk) 21:30, 5 February 2014 (UTC)

  Comment @Xmlizer: I think SCN (P377), Freebase ID (P646) or SWB editions (P1044) are catalogs as well and have theirs own properties, so catalog code (P528) is confusing to me. --Rezonansowy (talk) 10:17, 7 February 2014 (UTC)

  Oppose as Xmlizer. Filceolaire (talk) 05:00, 25 February 2014 (UTC)

  Not done Use catalog code (P528) with qualifier catalog (P972)=>Bach-Werke-Verzeichnis (Q214203) instead.--Micru (talk) 17:13, 3 March 2014 (UTC)

Discussion

Motivation. GZWDer (talk) 15:46, 1 December 2013 (UTC)

•   Support John Vandenberg (talk) 14:01, 23 December 2013 (UTC)
•   Support --Konggaru (talk) 04:28, 19 January 2014 (UTC)
•   Support per above --Rezonansowy (talk) 15:24, 19 January 2014 (UTC)
•   Support. Emw (talk) 03:59, 20 January 2014 (UTC)
•   Support לערי ריינהארט (talk) 09:23, 18 February 2014 (UTC)
• @GZWDer, John Vandenberg, 콩가루, Rezonansowy, Emw, לערי ריינהארט:   Done --Jakob (talk) 13:42, 25 February 2014 (UTC)

Discussion

Motivation. GZWDer (talk) 15:46, 1 December 2013 (UTC)

•   Support John Vandenberg (talk) 14:01, 23 December 2013 (UTC)
•   Support. Emw (talk) 04:00, 20 January 2014 (UTC)
•   Support. Helder.wiki (talk) 15:33, 22 January 2014 (UTC)
•   Support לערי ריינהארט (talk) 09:22, 18 February 2014 (UTC)
• @GZWDer, John Vandenberg, Emw, Helder.wiki, לערי ריינהארט:   Done --Jakob (talk) 13:47, 25 February 2014 (UTC)

Discussion 1

•   Comment I think the name "supported file formats" could be more clear.--Micru (talk) 10:16, 5 December 2013 (UTC)
  • Well, I've called it the same as Q186157, besides it's better to use this, because for example programming languages not support just has theirs own file extensions. --Rezonansowy (talk) 14:21, 6 December 2013 (UTC)
• We need qualifier to indicate input vs output formats. Also we should have an item for every file format, so string shouldnt be an acceptable value. John Vandenberg (talk) 15:13, 6 December 2013 (UTC)

  Comment - I would prefer to split this into "readable file format" and "writable file format". As indicated by the example we will need qualifiers that say which version of the program supports which formats. --Tobias1984 (talk) 16:10, 10 December 2013 (UTC)

Spilted the request.--GZWDer (talk) 12:16, 26 December 2013 (UTC)

•   Not done --Tobias1984 (talk) 17:25, 18 January 2014 (UTC)

Discussion2

• Reopen with other rationale. Now we have writable and readable file format but what about its own file format, which isn't only a property for software but also for programming languages. The appropriate description would be: "Subject's own file format". Besides statements (like in Adobe Photoshop (Q129793)) will be usually duplicated, so what about merge these properties to Supported file format? Or, we can use writable and readable file format properties only if they're appropriate (e.g. software can only read file format) --Rezonansowy (talk) 19:14, 18 January 2014 (UTC)
  • @Tobias1984: I have changed the request. Now this is for file extensions of a file format. that is JPEG (Q2195)=>.jpg, .jpeg, .jpe, .jif, .jfif, .jfi --GZWDer (talk) 04:01, 19 January 2014 (UTC)

  Support Good idea. I think we should store the file extension. --Tobias1984 (talk) 14:14, 19 January 2014 (UTC)

@Tobias1984: Should it be item or string?--GZWDer (talk) 03:47, 20 January 2014 (UTC)

  Support. This 'file extension' property would be useful, in addition to the newly-created 'readable file format' and 'writable file format'. I think its datatype should be 'string'. Emw (talk) 03:56, 20 January 2014 (UTC)

@Emw: If it's a string, should it be started with "."?--GZWDer (talk) 03:59, 20 January 2014 (UTC)

GZWDer, no -- I think we can do without the '.' character. It adds no information. It should be easy to add in the client if a '.' is helpful for presentation, but I don't think it's helpful to have in Wikidata. Emw (talk) 04:13, 20 January 2014 (UTC)

IMO should be item, because writable and readable file format has item statements, example: Adobe Photoshop (Q129793). All extensions could have its own item, just create it. --Rezonansowy (talk) 21:55, 20 January 2014 (UTC)

  Comment the correct term would be native file format. Danrok (talk) 15:10, 24 January 2014 (UTC)

Rather no, this is about supported file formats of item to reduce duplicates in writable and readable file format statements. Maybe in next request. --Rezonansowy (talk) 18:02, 24 January 2014 (UTC)

You are contradicting what you have said above, which was "Subject's own file format". What are you proposing here exactly? Danrok (talk) 01:08, 27 January 2014 (UTC)

That's only one option and it is too much that one request handles three different ideas, but this could be spitted to a separate request. --Rezonansowy (talk) 09:01, 28 January 2014 (UTC)

As this proposal stands, it is not possible to create it. The proposal is for data type "item / string" which is two types, and not possible. Danrok (talk) 11:44, 31 January 2014 (UTC)

I've changed my request, now it's item (see my comment above). --Rezonansowy (talk) 13:44, 31 January 2014 (UTC)

@Rezonansowy: Items would only make sense if we need to translate them and/or they have to hold statements of their own. Are file extensions for example translated into Cyrillic (e.g. jpg)? --Tobias1984 (talk) 18:36, 4 February 2014 (UTC)

Not quite, see JPEG (Q2195) - every Cyrillic wiki use original abbreviation, but look at the mlwiki entry, it has been transliterated. I don't see any major complications with it. --Rezonansowy (talk) 21:38, 4 February 2014 (UTC)

  Comment I updated this request to include both properties. Please comment! --Rezonansowy (talk) 18:49, 21 February 2014 (UTC)

@Danrok, GZWDer, Tobias1984: Could you review my updated request? --Rezonansowy (talk) 10:15, 22 February 2014 (UTC)

@Rezonansowy: I'm a little confused now. The discussion talks about "file extension" and about "Subject's own file format". Can you update the box with a clear description. If this is still about the file extension I think we should go with string-datatype. --Tobias1984 (talk) 13:03, 22 February 2014 (UTC)

  Done @Rezonansowy: Creating this as a string for now. If translation becomes an issue we can make changes. --Tobias1984 (talk) 10:45, 26 February 2014 (UTC)

Discussion

Motivation. Bigbossfarin (talk) 20:08, 9 February 2014 (UTC)

  Support Could also be used for broadcasting: radio drama (Q2635894) etc. --Kolja21 (talk) 06:28, 16 February 2014 (UTC)

  Support לערי ריינהארט (talk) 07:25, 24 February 2014 (UTC)

• @Bigbossfarin, Kolja21, לערי ריינהארט:   Done --Jakob (talk) 13:51, 25 February 2014 (UTC)

I'm a little late but it seems pretty similar to the equivalent property for first book publication. TomT0m (talk) 17:21, 3 March 2014 (UTC)

Discussion

This is especially needed for academic journals, and is essentially genre (P136) for academic output that is not artistic. It could be used for any education or research relationships. magazines also have a specialty, or subject area. I could not find a more generic property which fulfills this need; apologies if it exists and I didnt find it. main subject (P921) might be sufficient, however its description ('main topic of creative work') doesnt feel right for a publishing venue and also doesnt feel right for 'papers' which consist of little more than data or a proof (i.e. not creative). I would be happy with a very generic 'subject topic' property. John Vandenberg (talk) 12:46, 28 February 2014 (UTC)

  Comment Imho main subject (P921) fits. If we have books and journals about experimental physics (Q18366) we can use P31 for the query: "Please list every known journal about this subject." --Kolja21 (talk) 15:16, 28 February 2014 (UTC)

  Not done John Vandenberg, Kolja21: Use main subject (P921) instead (added alias "discipline").--Micru (talk) 20:26, 4 March 2014 (UTC)

Discussion

Motivation: A method is needed to indicate if imported data or any source has been checked by a user to avoid repeated efforts and convey data quality. The datatype would be string, linking to the userpage with MediaWiki:Gadget-AuthorityControl.js as usual. Micru (talk) 15:26, 28 November 2013 (UTC)

  Support Great idea, but I don't know if the name of the user is needed. Why not call it "checked" (without "by"). Substantial is the checked sign and a date. (What today is correct might be wrong tomorrow.)

Example:   Done, 28 November 2013

--Kolja21 (talk) 17:16, 28 November 2013 (UTC)

  Support May be two variants. 1) Checked. With the possibility of discussion or options. Information removal is possible in principle. 2) Strict verification. Information verified by a competent independent expert or obtained from several independent sources, this fact is recorded by the user from a limited number of people in Wikidata, any change or removal is not subject to change in certain circumstances. Signature, date and sign the protection of the user. All discussions only through this user.--Пробегающий (talk) 18:04, 28 November 2013 (UTC)

  Oppose Useless unless a script modified this new parameter when someone changes the value: en:WP manages this feature by a bot which analyses modifications. A good sourcing is the only good solution and instead of a new property the use of stated in (P248) and retrieved (P813) is good enough to ensure a verification. Snipre (talk) 18:31, 28 November 2013 (UTC)

Here we are talking about is that the information is read and coincides with the source. She checked up more is not necessary. Bot should not destroy the verified information.--Пробегающий (talk) 18:51, 28 November 2013 (UTC)

  Oppose, as this is a true misuse of qualifiers. We should instead wait for an implementation of FlaggedRevs: bots will import and humans will check. --Ricordisamoa 00:47, 5 December 2013 (UTC)

  Comment string 'Micru' may have a trust value to insiders, but it doesnt to an average Wikidata data consumer. Also we should design systems that mean it doesnt matter who added a piece of data-our processes should provide quality rather than the names of the people adding the data. If a responsibility/trust statement is going to have any meaning, it needs to link to an item that has properties that describe how responsible/trustable the person is (e.g. admin, trillions of edits). I think Wikidata will need to add a 'Wikimedia user' class eventually, and there are notable people that have website account on (P553) on Wikipedia, but it needs to be carefully planned.
I think it is more feasible to add a new source rather than qualify the 'imported from' statement. Maybe, a user who has verified a bot-created property can add a 'stated in <source>' or 'part of <database>' source, or a new 'exists in <database>' clause? They might also remove the 'imported from' clause as it has been replaced by a better/human checked statement. John Vandenberg (talk) 12:05, 5 December 2013 (UTC)

+1 The best way to say that a source is verified is to add the source data and to delete the 'imported from' property. Snipre (talk) 18:49, 5 December 2013 (UTC)

here is a good example of a bot stating the specific source dataset that was used. John Vandenberg (talk) 03:11, 6 December 2013 (UTC)

  Not done Lack of consensus.--Micru (talk) 17:51, 3 March 2014 (UTC)

Discussion

Reverse of topic's main Wikimedia portal (P1151), on the pattern of topic's main category (P910) and category's main topic (P301). Erasmo Barresi (talk) 17:10, 27 February 2014 (UTC)

  Support This would be useful to link things together. - AdamBMorgan (talk) 00:04, 4 March 2014 (UTC)

Support --Izno (talk) 00:19, 4 March 2014 (UTC)

  Support To keep consistency.--Micru (talk) 20:17, 4 March 2014 (UTC)

  Done Erasmo Barresi, AdamBMorgan, Izno => Wikimedia portal's main topic (P1204) --Micru (talk) 18:15, 7 March 2014 (UTC)

Discussion

*   Support --Filceolaire (talk) 20:51, 24 August 2013 (UTC)

*   SupportMcnabber091 (talk) 00:17, 25 August 2013 (UTC)

•   Question is this supposed to be item-datatype? Expenditure is a number so this is a qualifier that links to the country? --Tobias1984 (talk) 06:34, 26 August 2013 (UTC)

Yes. This should be 'Item' datatype if this is a qualifier that links to the 'department' line item in Expenditure so you can get the "Expenditure by department" parameter. Filceolaire (talk) 14:31, 26 August 2013 (UTC)

  Comment please try to find a more explicit label. --  Docu  at 19:27, 6 September 2013 (UTC)

With the change from "department" to "Fiscal expenditure by department" by 24.17.163.20, this is resolved. --  Docu  at 03:47, 11 September 2013 (UTC)

• I don't understand how this could be used. Could someone provide an example? --Yair rand (talk) 03:58, 15 October 2013 (UTC)

I agree, an example is needed. This proposal makes no sense. Type is item, allowed values is number. --Danrok (talk) 20:45, 16 October 2013 (UTC)

  Oppose I agree it makes no sense as a qualifier, or otherwise. I have a (maybe dumb) question: why don't any of these property proposals that list infobox parameters link to the actual infobox? This one gives infobox param "Expenditure by department", but, in what infobox? How is anyone supposed to find it? Isn't checking the infobox(es) an important part of evaluating these properties? Unless, I'm missing something, I'd suggest that the link should be a prerequisite for acceptance (if there is an infobox parameter, that is) since it will become a part of the documentation. Klortho (talk) 02:07, 27 January 2014 (UTC)

  Oppose. --Yair rand (talk) 23:48, 4 February 2014 (UTC)

  Oppose --Pasleim (talk) 14:06, 25 February 2014 (UTC)

This property would be used in the Global Economic Map project in this table: http://en.wikipedia.org/wiki/User:Mcnabber091/Economy_of_the_United_States#Fiscal_Budget . Mcnabber091 (talk) 09:45, 2 March 2014 (UTC)

• @Mcnabber091, Filceolaire, Pasleim, Yair rand, Klortho, Danrok:   Not done, SNOW. --Jakob (talk) 17:38, 28 February 2014 (UTC)

Discussion

  Support Data type is here now. Sounds like something we should have. Are you going to use it as fraction of 100 (100, 50, 1) or as a fraction of one (1, 0.5, 0.01)? --Tobias1984 (talk) 10:52, 31 January 2014 (UTC)

  Support --Goldzahn (talk) 23:16, 4 February 2014 (UTC)

• Is this actually necessary? The description says that this is just number of employed persons divided by the size of the labor force, and wouldn't both of those be already relevant data? This sounds like the population density issue. --Yair rand (talk) 23:47, 4 February 2014 (UTC)

  Yes, but the numbers are not always published that way. If a source tells "5% unemployment" we cannot construct the number of unemployed and work force. -- Lavallen (talk) 06:42, 23 February 2014 (UTC)

  So, would you recommend not having a property for number of employed persons? Or just including redundant data? --Yair rand (talk) 13:26, 23 February 2014 (UTC)

  I say that this maybe isn't a number that can always be derived from two other. If a report tells that the unemployment in Foo state is 6%. What should we type here if we do not know the number of "unemployed"? In Sweden one of the systems for counting these numbers is that somebody call 1000 persons and ask if they have worked anything in the last 30 days. If 900 answer yes, then the unemployment is 10%. This does not tell anything about how many they are.

  Another way is to look for how many is registered in the unemployment-bureau and compare with the number of persons in the range of 16-65 years. Then is it possible to derive this number. (Both this methods have serious drawbacks of course, and the politicians tends to choose the method that gives them the best support for their ideas.) -- Lavallen (talk) 14:03, 23 February 2014 (UTC)

  Okay, so in certain cases one can't have the data on the unemployment rate entirely as the number unemployed and the size of the workforce. Are there any cases where one can't derive the number unemployed from the related statistics on unemployment rate and size of the workforce? --Yair rand (talk) 14:18, 23 February 2014 (UTC)

  It's up to the definition of "unemployed". You may have worked one single hour the last month and are therefor not counted as unemployed, but you maybe are still registrered at the unemployment-bureau. And you maybe are a student, occupied 10 hours a day at school, but you are maybe still registrered, because you want an extrajob or a job as soon as the school ends. And you maybe are seriously handicaped, so handicaped that you cannot visit the bureau and not even answer the phone when the Statistics call to ask if you have worked. Or you maybe worked, but for peanuts, since the municipality refuses go give you social aid if you do not do some charity-work. -- Lavallen (talk) 16:00, 23 February 2014 (UTC)

What you told about Sweden is the same as is used by en:International Labour Organization#Labour statistics (ILO). For example, de:Wirtschaft Deutschlands has the unemployment rate (Arbeitslosenquote) provided by the national statistics organisation (destatis) for january 2014, december 2013 and the number from ILO for december 2013. The en:Wikipedia uses the data from Eurostat. I don´t know if Eurostat has the same numebers as the national statistics organisations. fr:Wikipedia has no source and the data is from december 2012. Another possible datasource is the The World factbook. The CIA publishes data about the unemployment rate too, for example for Albania the latest data is 13% (2012 estimated) source. Therefore, we would need two qualifiers for this property: P585 (point in time) and P143 (imported from). --Goldzahn (talk) 00:24, 24 February 2014 (UTC)

I don't think we should use "imported from". IMO, we should have the organization providing the data using stated in (P248) and the definition used using criterion used (P1013) (we would need an item about the definition like "unemployed person according to ILO definition". For France, the most commonly used figure seems to be "person registered by Pôle-Emply, category:A", and for some reason, these data are usually provided by the INSEE, not directly by Pôle-Emploi. --Zolo (talk) 11:19, 24 February 2014 (UTC)

What do you think about the qualifiers used in Q8085? --Goldzahn (talk) 21:09, 28 February 2014 (UTC)

I have tweaked it a bit as Eurostat seemed to mean to things: that data were provided by Eurostat, and that is used Eurostat criteria. Apart from this, I think the unemployment rate should be between 0 and 1, not 1 and 100, and also that this sort of data should go to Austria (Q40), not economy of Austria (Q8085), even though that makes very long items. I see both logical and practical reasons for this. This is the unemployment rate of Austria, not the "unemployment rate of the economy of Austria" and we need to be able to find data about the unemployment rate of some place by directly querying the related item. If the unemployment rate about a small city is in the city-item, the unemployment rate of Austria in "economy of Austria" and the unemployment rate of the US in "US labor market", it is going to be hard to follow. --Zolo (talk) 04:31, 1 March 2014 (UTC)

I don´t know if it is alreay possible, but meta:Wikidata/Notes/Inclusion_syntax#Properties_of_different_items says, that it should be possile (someday?) to access a property of a different item. And, for example, en, de, fr Wikipedia article Austria doesn´t tell the unemployment rate. Another problem that I see: The Eurostat source has the data of 28 states. Is it possible to copy all this data from this first item to all the other items and change in a second step what is different? Because I would like to input all this data, but with as little effort as possible. PS: Could we link to this item on the discussion page of P1198 as an example how to use this property?--Goldzahn (talk) 05:16, 1 March 2014 (UTC)

Accessing other items is not yet possible. But when that will be possible, it will be simpler and more intuitive to access data from the Austria item in an article about the economy of Austria than the other way round. We also have data about the unemployment rate of many cities, but it would not make much sense to create an "economy of city X" item just for storing economic data that can be stored in the main item. Storing everything in the main item is more consistent and more predictable.

I do not think anyone has yet developped any tool for copying a whole statement from one item to the next. Economic data are big and need to be peridocally updated. A bot would certainly be useful, and given that they are usually available in a machine-readable format, that should be doable (unless we want to find copyright issues). --Zolo (talk) 05:48, 1 March 2014 (UTC)

Wikidata:Project_chat#unemployment_rate_of_state_X --Goldzahn (talk) 11:30, 3 March 2014 (UTC)

Zolo, I don´t mind anymore if you move the data to the state-items. --Goldzahn (talk) 12:19, 5 March 2014 (UTC)

• @Mcnabber091, Zolo, Tobias1984, Goldzahn, Lavallen, Yair rand:   Done --Jakob (talk) 17:47, 28 February 2014 (UTC)

Discussion

Needed to distinguish different shares of ownership.

I think proportion (P1107) is fine for this. That said, if we want to provide this kind of info in a really rigorous way, that is going to be a lot of work. We would need to determine exactly how we count (options, preferred stocks etc.) We can use several definitions in the same item, but that will make things real complicated. We also need to determine whether we count indirect participation. If X owns 20% of Y through its wholly-owned subsidiary Z, I think we should have "Y: owner: Z" but not "Y: owner X" so that percentages do not add up to more than 100%. But this sort of data is not always publically available. --Zolo (talk) 09:43, 24 February 2014 (UTC)

Different kinds of stocks makes it complicated, yes. It's common practice in Swedish newspapers to tell two numbers: 1. How large share of the capital. 2. How large share of the votes in the annual assembly. Golden shares do not exist here, so I do not know how that would affect. -- Lavallen (talk) 10:57, 24 February 2014 (UTC)

proportion (P1107) seems usable! But it is almost impossible to found, as it is not listed at any list of properties.

In some case (preferred stocks, multiple stock classes) in can be complicated, but having a little inaccurate proportion (P1107) is still much better than current nothing (without qualifier). This sort of date is publically available for most of the public companies. --Jklamo (talk) 12:53, 24 February 2014 (UTC)

  Not done As per comments.--Micru (talk) 22:07, 4 March 2014 (UTC)

Discussion

Prevalence is a useful parameter in epidemiology. It shows the importance of a particular disease. It may be used to compare different diseases in a population and/or different populations with one disease. Pavel Dušek (talk) 23:14, 3 December 2013 (UTC)

  Support. This property would clearly be useful for data on diseases. Thanks Pavel. Emw (talk) 01:05, 6 January 2014 (UTC)

I hope it is okay if I ping

  Notified participants of WikiProject Medicine Klortho (talk) 03:44, 10 January 2014 (UTC)

  Comment I'm currently too uncertain about the numeric datatype to give an opinion about this. Hopefully the datatype will be released in a few weeks. --Tobias1984 (talk) 07:23, 10 January 2014 (UTC)

•   Support This sounds awesome if datasets exist which report numbers in this way. I know nothing about this kind of epidemiology reporting but it seems sensible. I support this being created, but I suppose that I should ask for a link to a dataset or research paper which presents this kind of data. Having a link to this data would prove that this is a value which already has a history of use. Blue Rasberry (talk) 02:28, 11 January 2014 (UTC)
• Daniel Mietchen, John Vandenberg, Klortho, others, please support or oppose. If noone raises a concern, then I will create it this property in a few days. Emw (talk) 05:52, 1 February 2014 (UTC)
• Support. The constraint should be number between 0 and 1, and I think this is a generic property (essentially it is probability (Q9492), not strictly medicine, natural science or even science, which IMO should be accompanied with a 'population' qualifier to an item that defines the population. In chemistry, one example use is isotopes; e.g. what is the prevalence of carbon-14 (Q840660) in a population of carbon (Q623) obtained from <process>? Compounds, etc also have prevalence relationships recorded by earth/environmental scientists. In pure mathematics, there is mathematical analysis (Q7754), which there is empirical prevalence data before there is a theory to define it. e.g. how frequently does a specific random number generator produce a prime? Even regarding epidemiology, which has such wildly different accuracy rates, the population and study method would need to be defined by many qualifiers if the 'population' isnt an item with its own properties. e.g. We also need to be concerned about multiple species having a relationship with a disease, and different types of relationships: e.g. Disease carrier (Q5282118). e.g. Does malaria (Q12156) => 0.000123 qualified to the UK mean prevalence among humans in the UK .. or rats or sparrows, etc? What method was used to create the sample population from the target population? (is it citizens only?) There is also the relationship between Anopheles (Q158597) and Plasmodium (Q130948) can also be a use of a prevalence property: what percentage of the mozzies in a defined area are carrying the parasite..? @Bluerasberry:, NGOs like Cancer Council and disability organisations have this type of data for their respective domain. I expect Centers for Disease Control and Prevention (Q583725) will have large stockpiles of this data. Australian Bureau of Statistics (Q123347) definitely keeps statistics for diseases of national interest. John Vandenberg (talk) 09:09, 1 February 2014 (UTC)

I would support, but as usual I would like the documentation / examples nailed down a little better. I don't understand the examples "country (Q6256) => United Kingdom (Q145)" or "population => male infants". What are "country" and "population" supposed to be? Qualifiers need properties in those positions, right? If these examples aren't realistic, then they should be dropped from the template. Klortho (talk) 03:37, 2 February 2014 (UTC)

•   Neutral I agree that we need a way to express prevalence at some point, especially now that the number type is available. I echo Klortho's and John Vandenberg's concerns, though, and think we need to specify things a bit better. Haven't dug deeper than doing some brief searches for prevalence or incidence rate (e.g. here), so won't vote either way at this point. --Daniel Mietchen (talk) 22:01, 3 February 2014 (UTC)
• @Pavel Dušek, Pavel Dušek, Klortho, John Vandenberg, Emw, Bluerasberry:   Done --Jakob (talk) 22:00, 25 February 2014 (UTC)

Discussion

Motivation. GZWDer (talk) 05:46, 16 February 2014 (UTC)

  Comment Sounds interesting: Where can we look up this number? Is it used by an infobox? --Kolja21 (talk) 05:57, 16 February 2014 (UTC)

here is probably the place.--GZWDer (talk) 14:36, 17 February 2014 (UTC)

  Support but needs a better name. Is there an enWP article or a wikidata Qitem about this code? what is it called? 'Periodical' may be better than 'Serial' as it has fewer other meanings. Filceolaire (talk) 05:31, 25 February 2014 (UTC)

  Support What is the suffix /R /TS /TN etc mean? John Vandenberg (talk) 07:20, 6 March 2014 (UTC)

• @GZWDer, Kolja21, Filceolaire, John Vandenberg:   Done --Jakob (talk) 22:33, 11 March 2014 (UTC)

  Support Simple link used in the specs infobox. Not sure if these should be two different properties. Joshbaumgartner (talk) 07:02, 2 October 2013 (UTC)

  Support--Micru (talk) 22:20, 4 March 2014 (UTC)

• @Joshbaumgartner, Micru:   Done --Jakob (talk) 22:40, 11 March 2014 (UTC)

  Support Simple link used in the specs infobox. Joshbaumgartner (talk) 07:02, 2 October 2013 (UTC)

  Support --Tobias1984 (talk) 14:15, 25 November 2013 (UTC)

  Comment What about just using has part(s) (P527)? Danrok (talk) 21:56, 12 January 2014 (UTC)

  Support in my language, using P527 in this case is not proper use. --Konggaru (talk) 09:18, 28 January 2014 (UTC)

  Support --Micru (talk) 22:19, 4 March 2014 (UTC)

• @Joshbaumgartner, Tobias1984, Danrok, 콩가루, Micru:   Done --Jakob (talk) 23:45, 11 March 2014 (UTC)

Discussion

• astronomers use also another quantity to measure the apparent brightness: the flux measured in Jansky or in Watt/meter^2/Hertz. Between apparent magnitude and flux there is a precise relation (see this table for example). Is it better to create another property, or is sufficient this? --Paperoastro (talk) 21:13, 7 February 2013 (UTC)

• Magnitudes are used pretty much exclusively in the optical and near infrared passbands. MER-C (talk) 13:08, 8 February 2013 (UTC)
• yes, but in radio astronomy and in far infrared, X-ray and gamma-ray passbands, fluxes are more commons. For these quantities is it better another property? --Paperoastro (talk) 14:36, 8 February 2013 (UTC)

• Yes. MER-C (talk) 12:51, 9 February 2013 (UTC)

•   Done --Paperoastro (talk) 22:31, 23 March 2014 (UTC)

  Support Per 'jetspecs' infobox. Joshbaumgartner (talk) 02:07, 3 October 2013 (UTC)

  Support --Tobias1984 (talk) 14:16, 25 November 2013 (UTC)

  Support --Micru (talk) 22:18, 4 March 2014 (UTC)

• @Joshbaumgartner, Tobias1984, Micru:   Done --Jakob (talk) 21:54, 25 March 2014 (UTC)

Discussion

•   Comment This could be a very interesting property, but I'd like to be sure to understand the meaning. In the Template:Infobox spaceflight, in the section Main telescope, there is the parameter telescope_wavelength. Do you intend this with this property? --Paperoastro (talk) 00:16, 20 December 2013 (UTC)

• I think this should be just the property for sending and receiving information. But we should also draft a request for "telescope wavelength". We could also generalize it to any scientific instrumentation. A medical x-ray machine for example detects x-rays. But x-ray machines probably are hooked up to a computer today, so they don't need a property for sending and receiving signals. On the other hand this property can also be used for cell phones, radios, antennas etc... --Tobias1984 (talk) 08:39, 20 December 2013 (UTC)

•   Support I understood. Thank you for the explanation! --Paperoastro (talk) 16:50, 20 December 2013 (UTC)

  Comment So, this would be received signal, i.e. generally the communications uplink band? Danrok (talk) 12:10, 25 January 2014 (UTC)

Yes that is a better name for the property. In case of satellites it would be the uplink band. But maybe we can expand the domain of the property to other machinery, where it could serve a different purpose. --Tobias1984 (talk) 12:37, 25 January 2014 (UTC)

  Support Danrok (talk) 14:12, 26 January 2014 (UTC)

I am thinking this should be band rather than signal. I think the general structure is spectrum > band > frequency > channel. We may want to have properties for frequency and channel, at a later date. Danrok (talk) 14:26, 26 January 2014 (UTC)

  Support Filceolaire (talk) 21:47, 24 February 2014 (UTC)

• @Filceolaire, Danrok, Tobias1984, Paperoastro:   Done --Jakob (talk) 22:10, 25 February 2014 (UTC)

Discussion

Motivation. GZWDer (talk) 16:16, 2 December 2013 (UTC)

I think you have confused China with Taiwan. See above NCL request = authority control number of the National Central Library (Q618340) (NCL). --84.155.105.127 16:12, 3 December 2013 (UTC)

Should be NLC.--GZWDer (talk) 05:04, 4 December 2013 (UTC)

  Support but please provide more information. I've added an example but it doesn't work with your source link. --Kolja21 (talk) 23:36, 4 December 2013 (UTC)

  Comment I've added more info. The catalog only shows the NLC number. No idea where I can find the NLC_URL. --Kolja21 (talk) 17:00, 10 March 2014 (UTC)

Discussion

Motivation. GZWDer (talk) 12:34, 26 December 2013 (UTC)

  Support. Emw (talk) 04:25, 3 January 2014 (UTC)

  Support - AdamBMorgan (talk) 00:22, 20 March 2014 (UTC)

• @GZWDer, Emw, AdamBMorgan:   Done --Jakob (talk) 14:03, 25 March 2014 (UTC)

Discussion

Motivation. GZWDer (talk) 12:34, 26 December 2013 (UTC)

  Support. Emw (talk) 04:25, 3 January 2014 (UTC)

  Support - AdamBMorgan (talk) 00:22, 20 March 2014 (UTC)

@GZWDer, Emw, AdamBMorgan:   Done --Jakob (talk) 13:59, 25 March 2014 (UTC)