Wikidata talk:Property proposal/all

Authority control

Hi, is there a reason, why the proposal currently only contains GND and VIAF. Obviously, these are some of the most important and best maintained in wikipedia. However, there are others, already embedded in templates (Q3907614, e.g. en:Template:Authority control, de:Vorlage:Normdaten).

Properties could be: VIAF= LCCN= GND= SELIBR= ORCID= BNF= BPN= RID= BIBSYS= ULAN= NDL= ...

Shouldn't we transfer all of them to wikidata?

Greetings --Teilzeittroll (talk) 18:04, 3 February 2013 (UTC)

It's just the start. More to come see Wikidata:Infoboxes task force: Authority files used in Wikipedia. --Kolja21 (talk) 18:48, 3 February 2013 (UTC)

Archiving?

This page is already really hard to scan through; should we start archiving (and writing up our emerging policy as we go)? James F. (talk) 02:10, 5 February 2013 (UTC)

If we're going to archive, it's going to have to be with bots. I don't yet know how long discussions must last, but if they must last for a substantial period of time, I could imagine we may have to split this into several different pages by topic and/or data type.--Jasper Deng (talk) 02:24, 5 February 2013 (UTC)

Rules

We should define rules for a new property, like:

• Translation in English and at least two other languages
• Indicating the possible items
  • Checking the items (are the langlinks about the same subject?)
  • Marking the items or make a list (they might change)
• Consent of at least __ users
• ...

Possibly we will find some proposals in en:Wikipedia:Categorization. --Kolja21 (talk) 08:41, 5 February 2013 (UTC)

• Used in an info box or a template. --Kolja21 (talk) 09:17, 5 February 2013 (UTC)
• ...

Well, a minimum is that the property should be usable on a minimum of two articles, optimally five if not ten or more. As for requiring consensus, I would say you would need a 1-2-day discussion. Just my two cents.--Jasper Deng (talk) 08:58, 5 February 2013 (UTC)

BTW: If we need an item that is not created yet (and has no Wikipedia article), what should we do? I think we should create one for a currency (P38) or head of state (P35), but not for the uncle (P29). So we need a supplement like: Create item justified. --Kolja21 (talk) 09:15, 5 February 2013 (UTC)

is a

"is a" (Property:P31) is a very ambiguous property. Just think of a question like: "A person is a ..." and you will have dozens of answers, half of which directly leads to a lawsuit. Since there was no discussion about adding this property, let's talk about it now. --Kolja21 (talk) 08:54, 5 February 2013 (UTC)

I think the simplest thing to do is wait for InstanceOfSnak. --Zolo (talk) 08:56, 5 February 2013 (UTC)

+1. Sounds reasonable. --Kolja21 (talk) 08:58, 5 February 2013 (UTC)

Support. --Yair rand (talk) 09:00, 5 February 2013 (UTC)

That would certainly be a better way of expressing an is_a relationship, but even so, this relation should not be overused. Instead of saying that Marie Curie is a spouse, mother, child, woman, Nobel winner or chemist, it is much better to say that his spouse is Pierre Curie, her children are Irène Joliot-Curie and Ève Curie, her parents Wladyslaw Sklodoska and Bronislawa Sklodoska, her gender is female, she has won a Nobel prize, and her occupation was chemist. All the is_a relationships can be trivially inferred from these. So most of time is_a is a bad practice and just a sort of placeholder for a proper relationship; it would be good to have some guidance on when to use it. Any meaningful category system must be a DAG, which means that enwiki-style going wild with categories should be avoided. --Tgr (talk) 21:54, 5 February 2013 (UTC)

As the proposer of this property, "is a" is a typeof RDF relationship. I completely agree that there are some very wrong ways to use it - and yes, "<Marie Curie> is a <spouse>" is a perfect example of a stupid and valueless statement that we should not encourage. However, statements like "<London> is a <city>" are going to be pretty fundamental for creating our DAG. Implicit expansion ("<London> is the capital city of <the United Kingdom>" etc.) is nice but (a) can't cover everything we'd want to state, and (b) Wikidata doesn't support inherited attributes yet, so talking about implicit query relationships is rather moot. James F. (talk) 00:14, 6 February 2013 (UTC)

P.S. Also, there was lots of discussion about creating the property on IRC; sorry that it appears to have come from nothing. James F. (talk) 00:16, 6 February 2013 (UTC)

Similarly, Marie Curie is a person. France is a sovereign state. E. coli is a species. -- Ypnypn (talk) 01:48, 6 February 2013 (UTC)

 Oppose Can't see how to use it. ("Is a" man = sex; "is a" father, brother ...) Same like property "is in". --ThorstenX (talk) 12:36, 8 February 2013 (UTC)

•  Neutral - It's very generic. Goldfish "is a" species and it also "is a" Carassius. The sooner we get more specific properties in place, the less over-used "is a" will be. Can't live with it, but I don't think we can live without it either. - Soulkeeper (talk) 18:08, 8 February 2013 (UTC)

James F: my point was that before starting to use such a property, there should be some guideline created for it, otherwise it will be a mess. The use of such a property is nontrivial and depends a lot on what we expect from the software. E.g. do we really want to include all possible is_a relationships (Marie Curie is a woman, a human, an animal, a living being) just because inferences of the type "A is a B, B is a subclass of C, therefore A is a C" are not supported at the moment? --Tgr (talk) 14:22, 9 February 2013 (UTC)

Sure. To answer your question, no, because we expect the system to do inferences (but I agree that we need a policy document about what Properties to create and how to use them). James F. (talk) 23:27, 11 February 2013 (UTC)

I marked it for deletion. Please comment. --Yurik (talk) 08:07, 16 February 2013 (UTC)

Wikidata:Requests for deletions/Archive/2013/02/26#Property:P31 "is a" --Kolja21 (talk) 17:57, 17 February 2013 (UTC)

Commons media file

We have "Commons media file" (Property:P10), "image" (Property:P18), "audio" (Property:P51), and "portrait" (Property:P62). If the distinction is helpful, we should delete "Commons media file" and add "video". Portrait is imho a dub of image. If we keep "Commons media file", we should explain what this property is used for. --Kolja21 (talk) 09:08, 5 February 2013 (UTC)

Point to existing use elsewhere

I've got a suggestion, coming at this from someone who has worked on Semantic Web (both upper-case and lower-case) stuff for a few years: could we please point to existing usage outside of Wikimedia as well as in infoboxes? If we are trying to decide on properties, there are existing formats that have solved a lot of the issues we are likely to hit. We could avoid all the headaches by simply pointing to them.

In the microformats community, it's considered best practice to document how people are describing things in practice. See process. So for something like citations, we have a page listing examples and existing formats. This is ongoing for even some niche use cases like job listings or "looking for" fields on dating sites (e.g. signalling whether one is looking for a relationship, friendship, a one night stand etc.)

Compiling this kind of data on how people are using data in practice would improve the properties we come up with. In some cases, we'd be able to just duplicate the sensible design decisions others have made. In others, we'd be able to come up with a unified synthesis of the best parts of different representation formats while avoiding their problems. If we don't, we risk just creating properties willy-nilly based on our own limited perspectives and biases. (Wikipedia has a little problem with systemic bias, in case anyone hadn't heard. Heh.)

Thoughts? —Tom Morris (talk) 21:58, 5 February 2013 (UTC)

The most immediate purpose of Wikidata phase 2 is to serve Wikipedia, so that sounds unavoidable that we take inspiration from Wikipedia infoboxes, biases and all. But clearly, we should have a look to some other websites, maybe start by analyzing how potential data collaborators work ? --Zolo (talk) 07:59, 6 February 2013 (UTC)

Office held

Office held (Property:P39) is inconsistently defined (date unclear).

Compare: member of sports team (Property:P54)

subject is currently or formerly a member of the sports team object

Any proposals? --Kolja21 (talk) 23:29, 5 February 2013 (UTC)

This is what we will have with qualifiers. For now, we cannot usefully express the distinction (without having a huge mess to fix later). James F. (talk) 23:56, 5 February 2013 (UTC)

So should we delete this property? (If not we need a definition.) --Kolja21 (talk) 06:11, 6 February 2013 (UTC)

 Description amended (in English, at least) to clarify that it refers to previous offices as well. — PinkAmpers&^{(Je vous invite à me parler)} 06:20, 6 February 2013 (UTC)

Thanks! (I've added German.) --Kolja21 (talk) 06:54, 6 February 2013 (UTC)

child vs son/daughter

Why do we differentiate sex in the majority of cases (mother/father, aunt/uncle ...) but not with the "child" property? Surely the differentiation of "son"/"daughter" is useful. Espeso (talk) 02:46, 7 February 2013 (UTC)

Conversly, why do we split mother/father when we could just have parent and rely on the attached item's sex? James F. (talk) 04:26, 7 February 2013 (UTC)

Indeed. Espeso (talk) 04:39, 7 February 2013 (UTC)

I disagree. Mother and father are each individually exclusive properties (assuming they mean biological parent), and "child" is not. A person can have any number of children, but only one mother and one father. If a person has no children, they can be set as child : no value, and if a mother or father is not known, the item can be set as father : unknown value / mother : unknown value. This would not be possible if mother and father were changed to be non-gender-specific or if child were changed to be gender-specific. --Yair rand (talk) 05:32, 7 February 2013 (UTC)

That is a valid perspective that weighs the value of negative assertions highly. Using your definitions, these properties then allow us to say definitively that "Subject has zero children", but we can never say definitively that some number of listed children is "complete". Should we make decisions based on the ability to make a negative assertion, when many non-zero completeness assertions can't be made? (Without more properties.) That's an open question, and too subtle for now. Using your perspective, I find that properties "brother" and "sister" should be combined: like "child[ren]", they may have zero to many members. We also have "uncle" (I don't see "aunt" in the list) and presumably for the same reasons "uncle" and "aunt" should be combined (a rather unimportant property anyway). I'm not suggesting we need to go on like this but people need to have such discussions for a crowd-sourced data model to work (I think). Espeso (talk) 06:27, 7 February 2013 (UTC)

Should we add a "number of children" property to make sure the list of children is complete ?

Yes, brother / sister should certainly work the same way as children.

That we only have one father and one mother is clearly valid from a purely genetic perspective (if we leave out clones), but we should clarify what should be done for adoption. --Zolo (talk) 07:39, 7 February 2013 (UTC)

This relates to a suggestion I made yesterday to add half-brother etc. properties. I'm still familiarising myself with policies here, but if one of the goals is to build infobox data, then genealogically half-siblings (and step-siblings/children and adopted siblings/children) might be important to note and having to check if two siblings share both of the same parents seems overly complicated to me. Even more complicated to determine step-siblings when you have to check if two siblings share neither of the same parents but two of their parents are spouses. /Ch1902 (talk) 10:30, 7 February 2013 (UTC)

Think using qualifiers too. This option is not yet implemented but by considering qualifiers (options for one property) we can avoid to define for each case a specific property. With qualifiers we can consider adoption, biological child, gender, relationship,... Snipre (talk) 15:16, 7 February 2013 (UTC)

Proposition: define a property son/daughter and add a qualifier with 3 possibilities: adoption, biological child and step child. Snipre (talk) 15:41, 7 February 2013 (UTC)

This is the general problem of inverse properties. If Alice has father Bob, it should not be necessary to separately state that Bob has child Alice. Likewise if Avatar is directed by James Cameron, we should not need a statement that James Cameron directed Avatar. Can Phase 3 lists be used for this? If we only have a property for the parent, and the list of the parent's children is generated automatically with Phase 3 lists, then we don't need a property for child. Jefft0 (talk) 21:39, 7 February 2013 (UTC)

Map

There's a discussion at Property talk:P15 about what kinds of maps are meant to be used on this property. Del_♉sion23 (talk) 11:06, 7 February 2013 (UTC)

Splitting of this proposal

Somehow I feel I get lost on this page and its discussions. I suggest to start new pages für several topics. For example Wikidata:Property proposal Person, Wikidata:Property proposal Work, Wikidata:Property proposal Term and link this pages to this page.--Giftzwerg 88 (talk) 12:47, 9 February 2013 (UTC)

Please do not forget that for places the discussion is going on here.--Ymblanter (talk) 13:03, 9 February 2013 (UTC)

 Support. The new pages can have links to discussions made in other pages. --Paperoastro (talk) 11:05, 10 February 2013 (UTC)

 Support. I have created Wikidata:Items about people, trying to summerarize what we have and what we need to sort out on that topic. It makes up a large part of the items, and it would be nice to have guidelines rather soon so that it does not good in too many directions. --Zolo (talk) 13:16, 10 February 2013 (UTC)

The best is to create task force, for example "Task force person" then to have sub pages about accepted properties (list with description, rules of use, qualifiers,...), about properties proposal and one about references (ranking, links, potential references,...) 141.6.11.19 08:41, 11 February 2013 (UTC)

Should I rename Wikidata:Items about people Wikidata:People task force ? There is also Wikidata:Infoboxes task force/persons, but imho it is too soon to have something specific enough to be mapped onto Wikipedia's infoboxes. "Items about people" is more about general ideas and future guidelines. --Zolo (talk) 09:34, 11 February 2013 (UTC)

 Oppose - right now we're still working out what style of Proposals we are creating. Until we have a policy document on how we want Proposals to work, this risks having different styles and procedures in ones about people vs. ones about transport. Shouldn't we focus on that first, before creating a proposal? James F. (talk) 23:18, 11 February 2013 (UTC)

I don't see what harm we get if we just split this page. This is really unreadable now, it's way too long. --Stryn (talk) 07:39, 12 February 2013 (UTC)

I'd be much more in favour of renaming this "Requests for creating Properties" with a sub-page for each Property, and as well as the main full index specialised indeces for people who just care about those - e.g. "Requests for creating Properties/People" and "Requests for creating Properties/Astronomy" and ... James F. (talk) 19:29, 12 February 2013 (UTC)

 Oppose We should use the archive. BTW: Wikidata:Property proposal Person is understandable; Wikidata:Items about people mixes terminologies. --ThorstenX1 (talk) 09:25, 12 February 2013 (UTC)

•  Support, the traffic is becoming excessive, much bigger than on the Project Chat.--Ymblanter (talk) 02:35, 26 February 2013 (UTC)
•  Support site even to long for people with old computers. -- MichaelSchoenitzer (talk) 23:25, 10 March 2013 (UTC)

Astronomical objects

To better organize the work for the astronomic object, I suggest to create a new thread for astronomic terms in the Infoboxes task force/terms. In this place we could organize and discuss the useful information that we would want in Wikidata and then we could propose new property more easily. --Paperoastro (talk) 11:17, 10 February 2013 (UTC)

 Support.--Ysogo (talk) 14:07, 10 February 2013 (UTC)

Here I started to organize the informations for the astronomic objects. --Paperoastro (talk) 11:17, 12 February 2013 (UTC)

Tracking historic data

I already started a similar discussion here, but I think this place may be better for this. How do we track historic data, eg. former spouse, former occupation, etc.? -- Faux (talk) 01:00, 18 February 2013 (UTC)

In Wikidata there are no former spouses or football players. Later it will be possible to add further informations like "spouse 1" oder "spouse 1980-1982". --Kolja21 (talk) 01:13, 18 February 2013 (UTC)

So at the moment if you want to model eg the infobox of this article, you only can fill in the current spouse? -- Faux (talk) 01:19, 18 February 2013 (UTC)

At the moment there is no way an infobox can read the data. You can add both wifes, even if it looks strange. --Kolja21 (talk) 01:29, 18 February 2013 (UTC)

There is no property for this in Wikipedia infoboxes, but if two people died, obviously they are still presented as spouses in Wikipedia. Perhaps we can add some time interval qualifier or event qualifier in the future for this property. (Is that correct understanding of qualifiers can be used?) Or create a datatype including item and time interval for the relation.

It would be nice if we could import data from GEDCOM and other ancestral database standards. In these, every current and former spouse is presented as a spouse, with relation to events such as marrage, devorce, widowing, etc.Mange01 (talk) 17:46, 8 March 2013 (UTC)

I have the same problem with, for example, "GDP growth". I am adding at de:Wirtschaft Deutschlands "GDP groth" every three months the newest number and keep the last three numbers. I think, I will stop doing this after Wikidata Phase 2 is switched on at Wikipedia. --Goldzahn (talk) 03:29, 22 February 2013 (UTC)

Created some properties

I've created two of the properties suggested a couple of weeks ago in the Language section. I'm doing the various things specified for when you create a property, but it doesn't say what to do with the proposal on this page, so I've just add a line to each of them to say I've created the property and linked to it. It seems to me that the other two properties proposed should be moved to the Pending page as well, but presumably the proposals should be archived rather than just removed from this page. --ColinFine (talk) 23:13, 21 February 2013 (UTC)

Good work. In a few days we can move the properties done to Wikidata:Property proposal/Archive/2. --Kolja21 (talk) 00:17, 22 February 2013 (UTC)

Year/month/day of birth/death

I'm new here, but is there a reason why we don't have birth and death dates as properties for people? The Rambling Man (talk) 21:12, 26 February 2013 (UTC)

Yes -- the software does not yet allow a date to be entered as the value of a property. The property proposal for these dates has already been archived as approved, but we can't act on it yet. Espeso (talk) 21:26, 26 February 2013 (UTC)

Okay, thank you. I imagine, from a database perspective, we'd either need individual fields for year, month, day, or some kind of specialist field which has a "property" of a date. The Rambling Man (talk) 21:29, 26 February 2013 (UTC)

Yes, and we could even use date items as the values (e.g. January 28 and 1945) with the currently deployed software, but I think people prefer to wait until date values can be handled properly. The planned data model for these values is documented here: meta:Wikidata/Data model#Dates and times. --Avenue (talk) 21:47, 26 February 2013 (UTC)

The property type we're waiting for is called "DateTimeValue" or similar, which in theory can handle drastically different levels of precision in one value/property/field. A birth date in principle could be entered as anything from "100 BCE" to "23:50:15 UTC February 20, 2013", although how that displays in practice will be interesting to see. Avenue, using existing calendar-related items is a really scary hack I've seen mentioned a few times!; it would be hard to re-use data in that format, and it would require two properties (day-month and year) instead of one. Espeso (talk) 02:56, 27 February 2013 (UTC)

I'm not advocating the calendar items approach. I think it's better to wait. On the other hand, I don't think it'd be too terrible if it was only used until true dates were supported (and bots had a chance to convert the old values into the new format). --Avenue (talk) 03:08, 27 February 2013 (UTC)

Template:Infobox_university

Sorry if I'm being a idiot about this but do we really need to suggest and vote on these one by one? Take for example en:Template:Infobox_university. In addition to the standard management-type positions applicable elsewhere there are: chancellor, provost, vice_chancellor, rector, principal, and dean. These positions have been in the infobox for sometime and I believe they are fairly well-known. Then you have populations like: academic_staff, administrative_staff, students (broken down undergrad, postgrad and doctoral). Is there not a way to fast-track adopting properties for well-used infoboxes like this? I promise this is the last time I'll raise this. Shawn in Montreal (talk) 04:19, 27 February 2013 (UTC)

I agree that it would make sense for more property discussions to take place thematically, as long as people do not assume that every element of a wikipedia infobox is appropriate for and properly describable in Wikidata. Beyond that, I am showing up again to give you a link to Category:Infoboxes task force, a set of pages that is easy to miss, where there is some work on matching infoboxes to Wikidata. I have not participated in those at all and I don't know if they're active pages, or how or if they intend to bring their work to the property proposal page eventually... for your info. Espeso (talk) 06:53, 27 February 2013 (UTC)

Thanks. I'll keep an eye on it but there doesn't seem to be much going on at the organizations template group. Shawn in Montreal (talk) 13:55, 27 February 2013 (UTC)

Hi Shawn, we don't need to discuss every property in depth. Adding it to the property proposal and wait two days, helps finding the main translations and eliminate ambiguity. It's less work than the other way around: First adding the property and than discuss and rename it. --Kolja21 (talk) 02:06, 28 February 2013 (UTC)

Just do the things correctly first take more than one infobox to define the most interesting properties, for examples extract properties from en, de and fr infoboxes, match the properties which are present at least in 2 different infoboxes and propose them. EN:WP has good infoboxes but by doing a comparison work you can extract the best of each infobox. Just have a look at Wikidata: Chemistry task force/Properties. Snipre (talk) 08:32, 2 March 2013 (UTC)

What happened to the preload?

A while ago simple instructions in the beginning of the page gave people the following form, based on Wikidata:Property_proposal/Preload. Is there a decision to not use it any more?

Wikidata:Property proposal/Preload

Mange01 (talk) 10:16, 1 March 2013 (UTC)

Better use a table than text like for the list of created properties: you can save place. Snipre (talk) 10:28, 2 March 2013 (UTC)

and perhaps add qualifier as a column: this can help in the discussion. Snipre (talk) 10:29, 2 March 2013 (UTC)

Agree! But why was it removed in the first place? To much instructions? Can it be put back temporarily until we have a table format?

Do you mean a template similar to Template:List of properties/Row but column version, with some of the above fields? Good idea! The suggersted property should not be created until all fields of the template have values. Then the documntation is written. I suggestion for template is found below.

I put the Header back, but under the instructions instead of above (which however are way too long). Was that ok? The header was removed 22 February 2013 with the argument "Avoid the Header beacause addition of new property is done at the end of the page and don't respect the classification according to datatype". Mange01 (talk) 21:55, 3 March 2013 (UTC)

I deleted the introduction because the header has a button for porperty proposal. But the function adds the new property proposal at the end of the proposal list and does not respect the property classification. Snipre (talk) 12:57, 5 March 2013 (UTC)

Template for property documentation

This is a first suggestion for template according the above:

{{property documentation
|col
|ID = P199 
| Label = Is not a(n) 
| Description = is not member of
| Datatype = Item 
| Main type = Term 
| Linked_item_main_type = Term 
| Infobox_example = :en:template:chembox
| Infobox_parameter = 
| Category_example = 
| Source_example =
| Tool_checks = Mutually exclusive with property "Is a(n)". Only allowed for terms.
}}

A possiblity to to allow the user to skip the parameter names, and only enter the data - the table will show the appropriate row headers anyway. Example:

{{property documentation
| col
| P199 
| is not a(n) 
| is not member of
| Item 
| Term 
| Term 
| :en:template:chembox 
|  
|  
| 
| Mutually exclusive with property "Is a(n)". Only allowed for terms.
}}

Mange01 (talk) 03:34, 3 March 2013 (UTC)

Property:P172

English: I'm not sure that this property has a clear signification...
Français : Pas certain que cette propriété ait une signification bien claire...
--Gloumouth1 (talk) 16:02, 1 March 2013 (UTC)

I ran the Hebrew label and description through Google Translate. The label translated to "Nation", while the description translated to "Nation to which the subject of the". - Soulkeeper (talk) 16:05, 1 March 2013 (UTC)

Ok, but <Yasser Arafat> Nation <Arab people> was coded with this property, and I do not understand what it means... --Gloumouth1 (talk) 16:21, 1 March 2013 (UTC)

<half joke or perhaps big blunder or perhaps truth, not sure>It means that Palestine is not a nation.</half joke or perhaps big blunder or perhaps truth, not sure>. Good luck with this one ! Touriste (talk) 18:27, 1 March 2013 (UTC)

Wikidata:Requests for deletions#Property:P172. --Kolja21 (talk) 00:38, 2 March 2013 (UTC)

Import data from Freebase.com

Example entry: http://www.freebase.com/view/en/henry_ford vs http://www.wikidata.org/wiki/Q8768 . Freebase is under Creative Commons --92.202.79.87 12:20, 2 March 2013 (UTC)

We should only use reliable sources. --Kolja21 (talk) 17:21, 2 March 2013 (UTC)

I noticed that Freebase is built on DBpedia which is built on Wikipedia extracts... So we dont have to import our own data but simply check ours on wikipedia and include them here.  --92.202.88.19 08:36, 3 March 2013 (UTC)

Abolish property proposals

What is the exact reason for this proposal system? Its only extra bureaucracy system... why dont we create properties just like an ordinary item?--Kozuch (talk) 23:14, 3 March 2013 (UTC)

To not forget to harmonize with Wikipedia infobox parameter names. And to write the property documentation before the property creation. We have no written policies right now, so we should agree an each individual property to develop some kind of practice. Mistakes may call for bot jobs affecting thousands of articles, and we want to avoid that extra job.

Do you think the instructions are too detailed, or the preload, on the top of the project proposal page? Mange01 (talk) 00:23, 4 March 2013 (UTC)

Personal experience: at first I understood very little about this page, but then I found it very useful, because I would never have dared to create a property myself (not before reading more documentation, guidelines and past discussions), while proposing things here helped me understand. --Nemo 08:04, 4 March 2013 (UTC)

Well ok I understand there might be some legitimate reasons behind the process just for now, so maybe putting few reasoning points in the intro of the page would clear the situation for the average editor.--Kozuch (talk) 09:21, 4 March 2013 (UTC)

I have now tried to clarify the instructions, and made them shorter. (But also added a couple of fields to the Preload form.) I hope this was ok. Mange01 (talk) 15:51, 7 March 2013 (UTC)

Merge?

If Property:P186 (material used) may apply to buildings or products/works, then I wonder if Property:P193 ("main building contractor"... "responsible for construction of this structure or building") may not logically be merged with Property:P176 ("manufacturer"... "the main manufacturer (excluding sub-contracted manufacturers)"), as we've tried to do elsewhere with properties that work across a range of subject areas? What say you all? Shawn in Montreal (talk) 19:53, 4 March 2013 (UTC)

Hi Shawn, I don't think this a good idea. "Hauptauftragnehmer" (P193) is - at least in German - totally different form "Hersteller" (P176). You don't produce noodle soup the same way a contractor "produces" a building. --Kolja21 (talk) 20:03, 4 March 2013 (UTC)

Uncle/Aunt/Brother/Sister

This request concerns R7, R9, R29, and R139. These properties don't translate well - in East Asian languages clear distinction is made between older and younger brothers and sisters, and between paternal and maternal uncles and aunts, with no catch-all phrases which have the same scope as "Uncle", "Aunt", "Brother", or "Sister".

Therefore I'd like to propose the following:

• Delete R29 and R139 as "Uncle" and "Aunt" are indirect relationships through a parent. These can be deduced through "Mother"/"Father" + "Brother"/"Sister" (or what they will become if changed)
• Split R7 and R9 into "Older brother", "Younger brother", "Older sister" and "Younger sister", potentially with an additional "twin"/"triplet" property. Deryck Chan (talk) 10:40, 5 March 2013 (UTC)

Avoid creating new properties to match languages characteristics because occidental contributors won't use that distinction. Better put a better description for the property like "Older/younger brother" in one sentence. Snipre (talk) 11:18, 5 March 2013 (UTC)

That's a non-rationale. We haven't avoided matching properties with language characteristics; we've simply moulded the properties to European language characteristics. I concede that phrases to deal with catch all concepts, usually to deal with translated literature, have been coined and accepted in Chinese - 兄弟姊妹 ("older brother-younger brother-older sister-younger sister" = "sibling(s)"). (And why do we have "brother" and "sister" as two separate properties anyway, rather than just "sibling"?)

The more problematic part is "Uncle" and "Aunt" - in Cantonese there are 5 different words referring to different kinds of "uncle", and 6 different words referring to different kinds of "aunt". The scope of "Uncle" and "Aunt" is indirect, and so sprawled and somewhat imprecise that I don't think it's worth our time to have properties for them. Deryck Chan (talk) 20:03, 5 March 2013 (UTC)

I don't think we have reliable enough data to distinguish between older and younger siblings for many historic figures. We can presumably generate this information using birthdates in the target records if needed. (I would also be happy to merge them into a generic genderless "sibling" or "parent" or "grandparent" rule). Andrew Gray (talk) 10:01, 6 March 2013 (UTC)

Head of government

A head of regional government property proposal has been archived, as if rejected, with no action taken on the head of national government property -- despite the fact that all the oppose !votes were all predicated on the position that there should be but one "head of government" property for all levels. So I intend to change the label and description of Property:P46 back to its initial scope, head of government (changed without consensus) unless someone can offer a reason why we should not, that reflects a consensus rather than merely a personal opposition. Shawn in Montreal (talk) 18:12, 6 March 2013 (UTC)

Sorry, I did not follow the thread, but there is also P6: head of local governement. If we want to broaden the scope of a property, I would rather take this one, as it is already more fuzzy than head of national government. That said, I am not strongly against a merger. --Zolo (talk) 18:56, 6 March 2013 (UTC)

I support combining all three; this is a good example of needless duplication of concepts in properties (like "member of football team:", "member of baseball team:", etc., would be). How we go about combining them is another question -- manual edits to consolidate properties if there is consensus here, followed by proposing deletion? Or proposing deletion first? In the interim I also support Shawn's rename of "head of national government". Espeso (talk) 19:02, 6 March 2013 (UTC)

I do believe there is a clear consensus for one property for all levels, just as we have as single property for all legislative bodies, regardless of level. Shawn in Montreal (talk) 19:14, 6 March 2013 (UTC)

Three new properties of StringValue datatype

With StringValue now a permissible datatype, I have created P:P227, P:P229, and P:P230 per Wikidata:Property proposal/Pending#Awaiting StringValue datatype. — PinkAmpers&^{(Je vous invite à me parler)} 23:19, 6 March 2013 (UTC)

(I see that several others have been created, e.g P:P212, P:P213, P:P214.) — PinkAmpers&^{(Je vous invite à me parler)} 23:24, 6 March 2013 (UTC)

Great, but isn't it to early? Property:P227 shows for Wikipedia: GND 7545251-0. Without the link (7545251-0) the info remains unsatisfactory. Should this be later changed by bot (different datatype) or should the linking be left to the infoboxes? --Kolja21 (talk) 02:09, 7 March 2013 (UTC)

Good news. And dangerous stuff. I hope we are a little bit restrictive to this, because non-linkable multi-lingual text can not be auto-translated, but require a lot of manual work. Mono-lingual texts are to my understanding only useful for codes, for example library classification codes. If possible, it is a better option to try to extend the number allowed items - for example create one item for each allowed code, or each allowed value of a certain infobox parameter. (Provided that the allowed values are sourced.)

Mange01 (talk) 02:50, 7 March 2013 (UTC)

Since this is an important issue, I've left a note on Wikidata:Project chat#Phase 1 live ... --Kolja21 (talk) 03:08, 7 March 2013 (UTC)

At Wikidata:Project chat#Proposal: Allow string (and may be other future types) properties to be displayed with formatting defined by a template is a discussion about this topic. User Jeblad is a wikidata developer and maybe his proposal will be developed. He proposed a "property type that can be used together with the interwiki prefixes. Those should include viaf-identifiers. All the available entries for this project is found on Special:Interwiki, and for eample viaf can be accessed as viaf:71378383." Indeed, that would be the solution. --Goldzahn (talk) 13:39, 8 March 2013 (UTC)

Also archive at each property talk page

I have copied each approved proposal discussion from the archive 2 and 3 to the property talk page. Is it ok if we continue to do that for new properties? Should it be done when the property is created, or when the Wd:property proposal page is archived? (Is there a risk of continued discussion at the proposal page between (a) and (b) happens?) Mange01 (talk) 02:54, 7 March 2013 (UTC)

+1. Very good idea. The talk page of a property is the best place. --Kolja21 (talk) 03:03, 7 March 2013 (UTC)

 Support I like this solution! --Paperoastro (talk) 16:19, 7 March 2013 (UTC)

You duplicated the same parts of the archive across 5 or 6 talk pages for properties that were part of a series (e.g. at Property_talk:P202).

I reduced the amount of duplication, but I'd still rather cross-reference the section in the archive.

I think it's a good idea though to add a more detailed explanation of the property on the property's talk page (as you had been doing as well). Maybe we can even find a way to transclude that directly below the property. --  Docu  at 05:51, 8 March 2013 (UTC)

That would be great! I also have done first parts of archive 1, but I hope others will take care of copying discussions from the current property proposal page to the property discussion pages. It would be helpful if include all current fields from the WD:Property proposal/Preload form, and try to answer the fields.

The following might work: MediaWiki talk:Wb-datatype wb-value-row --  Docu  at 08:57, 9 March 2013 (UTC)

Instead of copying the entire discussion, why not place a link to the archive? This is the way i know from the "featured articles" on the Dutch Wikipedia (example, look at the top right). That way, if something is changed, you don't have to change it on every single talkpage too. Amphicoelias _(Talk) 11:10, 11 March 2013 (UTC)

• I'd archived a recent discussion here at Property_talk:P272, however, not in the archives. Shawn in Montreal (talk) 15:16, 11 March 2013 (UTC)

Documenting bot and gadget jobs, and inclusion code

I added the field Bot and gadget jobs: in the WD:Property proposal/Preload form. After it is copied to each property discussion page, I suggest that we use this field for:

• Suggestions for but jobs and gadgets, for example for consistency check with another property.
• A list of existing gadgets related to the property.
• Log book of ongoing or already carried out bot jobs for collecting data for this property.

Ok?

Of course, the format of the preload form may have to be extended in case theese lists grow.

In the future, when inclusion syntax is possible in the Wikipedias, I would also like to see documentation of in what infoboxes the property is inlcuded. For example in the Infobox: field, or in a new field. [[Or can such a list be compiled automatically, just like at commons, where you easily can see in which articles a certain file is used. Mange01 (talk) 10:28, 8 March 2013 (UTC)

Template for property proposals

I created User:Ricordisamoa/Property proposal. How about moving it to the main namespace and using it globally?

If supported, please let me move the page finally :)

Pros:

• internationalization/localization
• cleaner text
• automatically updated

A preview can be seen in my sandbox. --Ricordisamoa 00:53, 13 March 2013 (UTC)

I support this, but before using it we'll have to do more internationalization and documentation. -- MichaelSchoenitzer (talk) 02:01, 13 March 2013 (UTC)

Be bold! --Ricordisamoa 16:43, 13 March 2013 (UTC)

Splitting this page

This page is huge (90 pages) and growing. Since above discussion is quite old and the page became even larger now, I propose (again) to split it into several pages:

• Wikidata talk:Property proposal/Persons (persons)
• Wikidata talk:Property proposal/Organization (organizations)
• Wikidata talk:Property proposal/Creative work (works)
• Wikidata talk:Property proposal/Term (terms)
• Wikidata talk:Property proposal/Place (places)

and to let the rest and the unsorted ones on this page. -- MichaelSchoenitzer (talk) 02:13, 13 March 2013 (UTC)

 Support --Ricordisamoa 02:34, 13 March 2013 (UTC)

 Support For Books, we have at least 3 pages, it would be good to work on the same one. --Aubrey (talk) 08:01, 13 March 2013 (UTC)

 Support Would make it easier to keep track of just the proposals you're interested in too. Amphicoelias _(Talk) 14:55, 13 March 2013 (UTC)

 Comment Please use the same names for the sub pages as Wikidata:Infoboxes task force/persons etc. This helps with orientation. --Kolja21 (talk) 01:54, 14 March 2013 (UTC) -- Changed support to comment. --Kolja21 (talk) 04:43, 15 March 2013 (UTC)

 Oppose Why do you need new pages ? We have already

• Wikidata:Infoboxes task force/persons (persons)
• Wikidata:Infoboxes task force/organizations (organizations)
• Wikidata:Infoboxes task force/works (works)
• Wikidata:Infoboxes task force/terms (terms)
• Wikidata:Infoboxes task force/places (places)

Just used that pages after cleaning the mess which is not used now. Please don't create to many places where topics are discussed. Snipre (talk) 18:41, 14 March 2013 (UTC)

Because I don't know I the content there is still needed. If you're sure that not, delete them. -- MichaelSchoenitzer (talk) 12:26, 17 March 2013 (UTC)

• Wikidata:Infoboxes task force/terms (terms)  Done Just add new paragraphs or add the properties according to existing topics

For astronomy properties, see with user:Paperoastro, for biology properties see with ?, for chemistry see with user:Snipre. Snipre (talk) 12:54, 18 March 2013 (UTC)

• Wikidata:Infoboxes task force/events (events)  Done Just add new paragraphs Snipre (talk) 12:56, 18 March 2013 (UTC)
• Wikidata:Infoboxes task force/organizations (organizations)  Done Just add new paragraphs Snipre (talk) 13:08, 18 March 2013 (UTC)

@Snipre: You deleted the content and replaced it with "???". ??? --Kolja21 (talk) 14:42, 18 March 2013 (UTC)

Yes, I know, but as requested by MichaelSchoenitzer above what was uncessary is now deleted to let place for the transfer of the content from Property proposal. Somebody can say that I have a small conception of what was necessary on thoses pages but as very few persons where adding or improving those pages contrary to all modifications on Porperty proposal, I think we can use those pages for new things. Snipre (talk) 16:52, 18 March 2013 (UTC)

For a discussion on what to use Infobox task force for, and what to remove from it, see Wikidata talk:Infoboxes task force#Further clean-up and focus only on parameter mapping?. ( I suggest that it should only be used for infobox mapping. Many more infoboxes from several different Wikipedias shouild be mapped to properties. But we need more people to contribute to the mapping.)

Currently WD:Property proposal constits of ~250000 characters of wiki code. The download time is 25 seconds for me, allthough I have a fast connection. The largest Wikipedia list articles are at about 500000 characters, which is problematic. The best solution is if we can come to more decissions per day than number of new suggestions per day. Would hiding each section using template:hidden begin and template:hidden end be a good solution? I can accept block suggestions (many properties related to the same infobox), as long as all relevant fileds of the documentation is answered for the whole block. Mange01 (talk) 23:01, 18 March 2013 (UTC)

Mapping of infoboxes and proposal of properties can be done in the same table. I don't understand why we have to separate these tasks. Then the use of tables can reduce the size of the whole system offering a easier way to navigate on the page. And all discussions for properties have to go on the talk page with a link between the table on the main page and the associated paragraph on the talk page. Just one example on Wikidata:Task force Chemistry/Properties. With that organization we can follow discussion and creation of new proposals at the same time. I never understood why we had to split properties between pending, proposal and created pages. We can keep everything on the same page using a table and a status label to define the evolution of each property. Snipre (talk) 10:26, 19 March 2013 (UTC)

Properties in Physics: Units?

Hey!

I found some pending properties here: Wikidata:Property_proposal/Pending#Mass, Charge, Distance. I think we get major problems if we do not consider the units of the value of these properties and discuss how to implement units for physical properties

There are 3 possibilities in my opinion:

1. We propose many similar properties: For instance mass: For any mass unit we propose one porperty with a certain nomencalture like mass_kg, mass_u, mass_g, mass_me etc.
2. We only use one mass property given in the SI unit of mass: kg.
3. We use qualifiers to dictate the unit.

I would vote for 2 or 3. This would minimize the amount of data, because we dont save e.g. the mass of the electron in hundreds of units, but only in one. In the Wikipedia itslef we can use the computation techniques of the templates to obtain other units than the SI unit.--Svebert (talk) 21:57, 13 March 2013 (UTC)

3, indeed. --Ricordisamoa 22:02, 13 March 2013 (UTC)

2 and 3. --Paperoastro (talk) 22:11, 13 March 2013 (UTC)

if we use qualifiers to label the unit we certainly have to norm these qualifiers. Ohterwise any queries will be cumbersome in future. E.g. if we do not make any rules for the qualifiers we will find kg KG kilogram, kilograms, Kilograms, Kg, kilo, Kilo and whatever more. If we use qualifiers to denote the units we should stick to the SI abbreviations. Or is there a technical possibility to implement obligatory qualifiers with predefined values?--Svebert (talk) 22:36, 13 March 2013 (UTC)

I don't know how qualifiers will be implemented, but allowing only items as values might be a good solution. --Avenue (talk) 00:28, 14 March 2013 (UTC)

3, not 1 or 2. 1 is needlessly messy, and 2 would complicate the recording of values' precisions. --Avenue (talk) 00:28, 14 March 2013 (UTC)

Apparently it won't be anything of these 3 options. The units will be implemented in the value itself, see [1]--Svebert (talk) 08:28, 15 March 2013 (UTC)

Changing „Pending“ properties?

Next question:

There is the Wikidata:Property_proposal/Pending#Charge this should be changed to Electric charge. Also the unit has to be considerd. See section above.--Svebert (talk) 21:59, 13 March 2013 (UTC)

Not - as a property

What are thoughts about properties that establish the absence of a relationship? For example, some one may create a statement like "Barack Obama - born in - America" with some evidence and then later some one else may create a refuting statement "Barack Obama - not born in - America" that cites some other evidence. Allowing negations would allow for multiple viewpoints supported by different claims. I tend to think negations would be a bad thing in general, but I'd like to know what others thought about it and if there was any nascent policy on this class of properties. Genewiki123 (talk) 00:30, 14 March 2013 (UTC)

• Obama was not born in Afrika and not born in Paris. He is not Einstein and he is no Jew. I'm afraid all this would say more about the editor and his point of view, than about Obama. Beside: Having more than 400 or 500 properties about a person might not be suitable. --Kolja21 (talk) 01:49, 14 March 2013 (UTC)
• Being able to directly assert negative properties with Wikidata statements -- <subject> not <predicate> <object> -- is an important use case. The value of this feature is indicated by its inclusion in the recent OWL 2 W3C recommendation; see http://www.w3.org/TR/owl2-new-features/#F3:_NegativeObjectPropertyAssertion_and_NegativeDataPropertyAssertion. The example in the initial comment is relevant, too, as are examples like "Autism not caused by vaccines", etc. This feature would obviously be prone to abuse as noted above, but I don't think that's sufficient reason to not support it: many valuable properties are also prone to abuse, but they're widely used.

It's unclear whether qualifiers could be used for negation. If they are, then that answers the question. If not, then it would be nice if this feature had some support beyond being an entry in the Property namespace, but development on that probably isn't a priority. In that case I would support adding "not" properties (e.g. "not born in", "not caused by", etc.) on an as-needed basis. Emw (talk) 21:00, 17 March 2013 (UTC)

 Support. In other ontologies, the relation disjunct with occurs. Eg in GND. However, i.m.o. this should only be used for relating terms and categories to each other, since this is useful in machine interpretation, automatic inconsistency detection, etc. Mange01 (talk) 22:39, 18 March 2013 (UTC)

Subpage for refused

At the moment there are the first Properties which can be seen as refused. I suggest to create a subpage for collecting these. I suggest the following rules for moving a proposal to refused:

• At least 7 votes.
• Proposal is at least 14 days old.
• More than 50% against creation.
• No improvements are suggested.

What do you think? -- MichaelSchoenitzer (talk) 14:41, 19 March 2013 (UTC)

 Support --Ricordisamoa 17:44, 19 March 2013 (UTC)

 Comment At the moment, refused and old proposels are moved to the archive too. --Goldzahn (talk) 18:01, 19 March 2013 (UTC)

Split in subpages

Hi, folks! I've just split the "Wikidata:Property proposal" page into subpages. Good bye! --NaBUru38 (talk) 20:06, 19 March 2013 (UTC)

Ok, fine this has been finally done, after all those discussions. Now, it's time to update the header and make some thoughts, what about to do with the main page. I Propose to note include all subpages but instead use this page as a description about the process of property proposal and link the subpages. What do you think? -- MichaelSchoenitzer (talk) 21:01, 19 March 2013 (UTC)

It would be nice to have links to all sub pages at the top of the main page. Is it possible to generate this dynamically? --Faux (talk) 08:35, 22 March 2013 (UTC)

New task force for astronomic objects

I have prepared the Astronomy task force, following the example of Chemistry task force and the Molecular Biology task force. People that are interested in, are welcome! --Paperoastro (talk) 21:36, 19 March 2013 (UTC)

External ids

Do we really need a discussion before creating properties for external ID like authority control numbers. There is a huge number of them (think P:P303), and I do not see any harm in adding them, that will save time, and keep the discussion page more readable. --Zolo (talk) 08:08, 20 March 2013 (UTC)

I agree. External ID from trusted sources should be added by default (can we foresee any drawback?) --Aubrey (talk) 11:22, 20 March 2013 (UTC)

Maybe using a fast-forward-mode for them, for example it needs only one second agreement and only 5 days of waiting? -- MichaelSchoenitzer (talk) 12:31, 20 March 2013 (UTC)

I think that when documentation including infobox parameter (or source) is provided, you can feel free to create the parameters. Mange01 (talk) 12:32, 20 March 2013 (UTC)

I only see the risk of potential redundant properties. Since some existing properties might not be translated so far, it's hard to find them. If at least two people check it, we'll minimize this risk.--Faux (talk) 08:38, 22 March 2013 (UTC)

I have created "Joconde" (P:P347, as I am sure it did not exist, and it is widely used on fr.wikipedia and on Commons. --Zolo (talk) 15:03, 24 March 2013 (UTC)

Proposal: use GND main type (P107) classifications as initial classifications for P31

Wherever the main type (GND) property (P107) occurs with a value of person, place, organization or event, it's used to specify the class of an instance, albeit a high-level class. Given that, I think it would make sense to apply the instance of (P31) property with the same value, since doing so would allow items to start off with a basic classification which could later be refined with more specific classes of person, place, organization or event as appropriate. As has seemingly been established in the P107 talk page, that property has only one high level of specificity. This idea was previously outlined in Property_talk:P107#This_property_overlaps_with_.27instance_of.27_.28P31.29, but I thought I would bring it up for wider discussion here. Emw (talk) 20:40, 24 March 2013 (UTC)

In your plan, does refinement cause the addition of a second claim under "instance of" or that the "old" claim of the high level classification should be replaced completely? I would also keep in mind subclass of. --Izno (talk) 20:53, 24 March 2013 (UTC)

Refinement of 'instance of' would replace the old 'instance of' statement. The old 'instance of' claim would be deducible, since refinement (i.e. a narrower 'instance of' classification) would introduce a subclass of the previous 'instance of' value with something more specific.

As for the old P107 claim, I'm not sure whether it would make sense to keep. On the one hand, I think the P107 claim would make sense to keep since it's specific to the GND ontology. On the other hand, the P107 classification seems like it would be redundant with the 'instance of' classification by being equivalent (GND main type: person, instance of: person) or by deduction (GND main type: place, instance of: country -> subclass of place).

Regarding subclass of (P279), I think that would be applicable where P107 has the classification 'term'. But since 'term' conveys no more real meaning than "this item isn't one of the other GND types", I don't think it makes sense to adopt that GND classification. Where the GND main type is person, place, organization or event, though, I think 'instance of' applies rather than 'subclass of' in all cases. Emw (talk) 21:07, 24 March 2013 (UTC)

Are you proposing this be done automatically? If so, I'm concerned that it will sometimes produce nonsense because GND types do not match the common meaning of the items used for P107. For example, according to Wikidata:Infoboxes task force/persons a family (like the Medici family or Bach family) can have a GND type of "person", but we should not say that it is an instance of a person (i.e. an individual). --Avenue (talk) 14:10, 25 March 2013 (UTC)

Yes, I am proposing this be done automatically. I think the amount of nonsense that would be added is probably negligible. For example, while both Medici family and Bach family could have a GND main type of "person", neither actually does. The very small number of cases that do actually occur could likely be caught through simple tests like "don't apply 'instance of: person' if the item's sitelink contains the phrase 'house of', 'family' or 'dynasty'". Even then, if non-sensible GND main type values were to be carried over, they would be no less sensible than the values that already exist. However, the carry-overs could be made sensible and refined, unlike their GND counterparts. Emw (talk) 04:04, 26 March 2013 (UTC)

The Bach and Medici items don't have a GND statement yet, but "person" would apparently be the correct type. Tests based on link titles will not catch all families, as they are not all explicitly titled as such: e.g. Black McCains, Op den Graeff. But my point is not just about families. GND types are also a poor match for the items used in other ways (e.g. "place" includes buildings and city councils, "person" includes collective pseudonyms, and "event" does not include events like elections or natural disasters). I don't know enough about the GND to say how extensive these mismatches are (I'd have no interest in the GND if it wasn't for its peculiar overuse and misuse in Wikidata), but they do at least seem widespread enough to make me very uncomfortable about basing automatic edits on GND main types, including this proposed transference of GND types to "instance of" statements. At least if the nonsense is confined to GND main types, we can treat the statements using that property with appropriate caution. Copying the nonsense into "instance of" statements would pollute that property too, throwing unnecessary doubt over the many existing statements that use that property. --Avenue (talk) 12:55, 26 March 2013 (UTC)

This basically shows that the GND type "person" is essentially useless and misleading. This seems like a very good reason to completely ignore the GND. It's a strange, bizarre bit of librarian fetishism rather than a useful classification system. —Tom Morris (talk) 10:02, 26 March 2013 (UTC)

I've kind of come to the conclusion that P107 causes more grief than help... With the introduction of 'subclass of', 'instance of', and especially 'GND identifier', I think we could safely deprecate this property. This would safely allow us to only document items which have previously been documented there, restricting the scope in a good way, while also allowing us to break cleanly and easily from the apparent lunacy to me. --Izno (talk) 13:08, 26 March 2013 (UTC)

(edit conflict) As far as I understand, this proposal just means: use GND types Wikidata from de.wikipedia to initialize p31. I think it I can be ok for people, though it may be just as well, perhaps better , to use categories like de:Kategorie:Männer. For other types, GND main type is really vague, and we do not have that many Wikipedia articles with this info anyhow, so I think using categories will be more productive.--Zolo (talk) 13:14, 26 March 2013 (UTC)

If P107 was only used to store GND data from de.wikipedia, I would not have so many concerns about it, but that is far from true. I understand (from here) that there are about 230,000 Wikipedia articles with GND details, compared to about 830,000 Wikidata items using P107.[2] I would love to see "GND main type" deprecated in favour of the "GND identifier" property. I agree categories would generally be a better starting point for P31 than GND types, especially as they cover a much wider range of topics. --Avenue (talk) 13:40, 26 March 2013 (UTC)

I cannot find where all those GND statements in Wikidata come from. My guess is that they do not come from the German Library, and that they use words like "person" in a more usual sense. I would think that we can copy some current P27 to P31 if that is is convenient. Afterwards, I see no need for using this GND thing in P31. --Zolo (talk) 16:20, 27 March 2013 (UTC)

My guess is that the Wikidata useful tool is the main cause of P107's explosive growth. Emw (talk) 02:37, 28 March 2013 (UTC)

It also seems that user:Dexbot ias adding it, based on en.wiki [3]. --Zolo (talk) 10:06, 28 March 2013 (UTC)

 Oppose P107 is the most popular property because it has a clear function and a defined vocabulary. We had this discussion under various threats and I can't see any new arguments. --Kolja21 (talk) 01:12, 29 March 2013 (UTC)

Are you opposing this proposal? If so, how does what you wrote relate? Emw (talk) 02:30, 29 March 2013 (UTC)

We have this discussion at least twice a day. I've stopped answering on Property talk:P107 but it seems that doesn't help. --Kolja21 (talk) 02:56, 29 March 2013 (UTC)

P107 request for deletion discussion

Given the opinions folks expressed above, I figured I'd point out Wikidata:Requests_for_deletions#Property:P107. Emw (talk) 03:55, 29 March 2013 (UTC)

Suggesting several properties for hardware

Hey dear community,
I like to create some data objects that belong to hardware (like graphics cards or hard disks). For this, I'd like to suggest several properties like reading speed, writing speed, total bytes written, mean time between failure, memory cell type (SLC, TLC, QLC, ...), slot width, bus width, fill rate and some more.

Should a new discussion be opened for each individual property or would a discussion on a set of properties be more useful?

Thank you and greetings :), --PantheraLeo1359531 (talk) 11:28, 24 January 2022 (UTC)