Wikidata talk:List of properties/Archive/2013/03

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Added without discussion

What is the proper procedure of moving items from the section "added without discussion" to other sections? For instance, anthem is heavily used in entries for countries, and whereas it might have been created without discussion, not it would be reasonable to move it to 'Place'. Should we have a vote for every item from this group anybody nominates?--Ymblanter (talk) 06:52, 7 February 2013 (UTC)

No need of vote: if after some days no comment was added to the property proposal we can assume that is no need of discussion and you can create the item. As I understand the "Added without discussion" this refers to property which was not proposed on the page Property proposal and created by contributor without any information. Snipre (talk) 09:57, 7 February 2013 (UTC)

Agreed - please, no votes about these, but discussion and consensus. James F. (talk) 16:56, 7 February 2013 (UTC)

On what page?--Ymblanter (talk) 17:04, 7 February 2013 (UTC)

At Wikidata:Property proposal which is linked from the top of this one? James F. (talk) 17:14, 7 February 2013 (UTC)

My concern is that silence on the property suggestion page is not consensus. There isn't much discussion occurring. And half the properties can't be implemented yet. Kind of an odd position to put the project in. Espeso (talk) 17:21, 7 February 2013 (UTC)

Yes, I agree that 'consensus' means more than just 'no-one said no'. We should probably refactor the Wikidata:Property proposal page so that there's a section for "coming but are awaiting a datatype" and "for review" - we should take these comments there, though. James F. (talk) 21:20, 7 February 2013 (UTC)

Well, it's a bit odd to request users to list them on Wikidata:Property proposal, but then not integrate them in the appropriate section of Wikidata:List of properties. Many fields already exist in thousands of infoboxes and there isn't really much to add. --  Docu  at 03:23, 9 March 2013 (UTC)

Fictional people

Simple question, should fictional people (ex Q838512) be assigned the standard person properties? Legoktm (talk) 16:21, 17 February 2013 (UTC)

Main type of item: type p: Persons (including pseudonyms), families, literary and mythical figures. The other properties: I don't know. --Kolja21 (talk) 17:51, 17 February 2013 (UTC)

I would think so. One alternative would be to create a duplicate set of properties strictly for fictional people, but I can't see much benefit in that. And some people are borderline - e.g. part historical, part mythological --Avenue (talk) 18:25, 17 February 2013 (UTC)

I think the way to deal with this would be to add a boolean type of some sort, basically "fiction" or "nonfiction". The usage of this type would positively indicate that an element is fictional, and nonpresence of this type would otherwise indicate that an element is not. That way we only need to add it to fictional items. Where a person/thing is kind of fictional, I think I would lean to not expressing it as being fictional. --Izno (talk) 00:57, 5 March 2013 (UTC)

More types

Shouldn't video games be added also to Works? Hm, and what about sport types (Terms?), board games (Works?) and other toys (Works?)? Where do they belong? --09:41, 25 February 2013 (UTC), Utar (talk)

I've been specifying video games as the main type: creative work. Danrok (talk) 17:37, 25 February 2013 (UTC)

Unfortunately software products are type s (terms). Please look Wikidata:Infoboxes task force/terms. Example: Super Mario 64. --Kolja21 (talk) 01:18, 26 February 2013 (UTC)

That can't be right. Software is considered as creative work by many laws, also the Creative Commons licence applies to software. Danrok (talk) 01:42, 26 February 2013 (UTC)

That's why there is the note: The terms "person", "place" etc. are meant to generalize. Please don't take them literally (Template:Entities). A family is not a single person as well. (We need a translation of Entitätencodierung: Vergaberichtlinien - Kurzliste.) --Kolja21 (talk) 02:02, 26 February 2013 (UTC)

OK, I'm happy to conform to that even if it's debatable. Which entity would this be according to that list? Guerrillero Heroico Danrok (talk) 02:31, 26 February 2013 (UTC)

Good question ;) A single photo? I would treat it like an art work = type wit (main type w). --Kolja21 (talk) 02:49, 26 February 2013 (UTC)

@Kolja21: So all software and sport types to Terms, you say, ok. What about those board games and other toys? Works? --Utar (talk) 08:59, 26 February 2013 (UTC), Utar (talk)

This doesn't make sense... Video games (software products) are not a term, they're works... That's a very strange choice. --Izno (talk) 01:13, 5 March 2013 (UTC)

I myself though that too, as you can see higher. But it seems someone said all software goes to terms. In this last edit you respond too I just ask Kolja21 to answer all my questions. --11:17, 5 March 2013 (UTC), Utar (talk)

Software and board games are type "s" (called "term", what is indeed not helpful in this two cases; probably for historical reasons I don't know of.) Sources: list, Schach/chess. --Kolja21 (talk) 23:06, 5 March 2013 (UTC)

We don't need to bind ourselves to that idea of what software and games are. (Software moreso than games, since something like chess is hard to categorize.) Is there some reason why you have used those links repeatedly? --Izno (talk) 23:17, 5 March 2013 (UTC)

P107 is showing the types from the en:Universal Authority File (GND), nothing more. (It's being used by authority templates and bots checking this info.) P107 is helpful, but the expectations of this property should not be too high. --Kolja21 (talk) 23:53, 5 March 2013 (UTC)

Still, my concern in labeling software and games as terms is that there are attributes in the "works" section which apply. Should we be faithful to the GND and only use properties which fall under terms...? It really still shouldn't matter that much. --Izno (talk) 01:28, 6 March 2013 (UTC)

They're terms, but if a property from the works section also fits a term, go ahead and use it. It doesn't benefit the project to avoid perfectly good properties just because of arbitrary GND types. If it fits, use it. Reach Out to the Truth (talk) 03:44, 9 March 2013 (UTC)

Un seul tableau / One unified table

Français: Bonjour, je suggère que toutes les propriétés soient présentées dans un tableau unique, un peu comme ça:

Catégorie  Titre             Id     Type  Description                                            Exemple
Person     lieu de naissance 19     Item  le lieu le plus précis (par ex. ville au lieu de pays) <Marie Curie> lieu de naissance <Varsovie>
Person     lieu de décès     20     Item  le lieu le plus précis (par ex. ville au lieu de pays) <John F. Kennedy> lieu de décès <Dallas>
...       ...                ...    ...   ...                                                      ...

Ainsi on aurait la possibilité de réordonner les lignes par id et voir quelles sont les propriétés qui ont été créées récemment.

---

English: I think that it would be better to have all the propoerties in one unified table, like this:

Kind     Title            Id   Datatype  Description                                            Example
Person   place of birth   19   Item      the most specific known (e.g. city instead of country) <Marie Curie> place of birth <Warsaw>
Person   place of death   20   Item      the most specific known (e.g. city instead of country) <John F. Kennedy> place of death <Dallas>
...      ...              ...  ...       ...                                                      ...

So we can sort rows by Id globally, and can for example know which are the properties that were created recently.
--Gloumouth1 (talk) 09:06, 26 February 2013 (UTC)

Perhaps a table list of all properties could be at the top or bottom of this project page? Just a case of copy/paste those which are already present. Danrok (talk) 17:06, 28 February 2013 (UTC)

I suggest that the the documentation (a row or column) is stored in the property subspace, and made visible both at the property talk page (see the example at property_talk:P10), and trancluded to this list. You can easily edit each row directly from the list anyway, by adding a clickable "e" or "+/-" sign to the right of each row.

If you merge everything into one huge table, you have to add a type of item/class/domain column. This allows that bots to check that only "allowed" (or relevant) properties are used for a certain type of item. The table should also include info on sources (where bots automatically can get the data), and corresponding Wikipedia infobox parameter name (where data can be included, making it possible for an "Import statement" gadget to collect data from Wikipedia. And then a row is not enough. A column would be better.

A related discussion is ongoing at Wikidata talk:Property proposal#What happened to the preload?. Mange01 (talk) 01:38, 5 March 2013 (UTC)

Country?

On Property_talk:P131 there is a discussion about marking Property:P17 country as deprecated in favor of Property:P131 located in administrative unit. As already mentioned there, I opt for marking P17 as deprecated, since keeping some other geographical definition system as P131 might lead to over administration (two properties needs to be maintained), data redundancy and inconsistency (eg. in case P131 mentions a different "country" than P17). What do others think about this topic? --Faux (talk) 18:15, 26 February 2013 (UTC)

I believe Property:P131 works better. For example, I live on an island which is not located within a country. See Jersey. Within some contexts Jersey is considered to be country, for some legal purposes, for example. Danrok (talk) 18:32, 26 February 2013 (UTC)

I'd support this. Unless I've misunderstood, locating something in the most precise administrative unit is a logical way to locate it within its country, anyway. Shawn in Montreal (talk) 19:01, 27 February 2013 (UTC)

Clearly P17 is a subset of P131, but it's a useful subset to maintain. Also, deletion proposals like that should go on the deletion requests page. James F. (talk) 17:55, 28 February 2013 (UTC)

I agree, both are needed and can serve different purposes. Danrok (talk) 18:01, 28 February 2013 (UTC)

Agree. I would even like to see that P131 (located in administrative unit) should be replaced by several properties (similar to en:template:settlement):

• is in first-order administrative division
• is in second-order administrative division
• is in third-order administrative division
• is in fourth-order administrative division

Mange01 (talk) 01:21, 5 March 2013 (UTC)

One argument against using such levels is that their definition is unclear in some situations. E.g. some cities in a state might be nested within counties, while larger ones are not, so cities could be second- or third-level divisions. And some administrative subdivisions overlap with others, or even coincide, making things even more unclear. For instance, New Zealand's Southern District Health Board (DHB) covers the Otago and Southland regions, so these regions could logically be regarded as a subdivision of the DHB. In contrast, some other NZ regions contain multiple DHBs. So are some DHBs first-level divisions, while others are not (and likewise for regions)? --Avenue (talk) 08:57, 9 March 2013 (UTC)

I'd keep the "country" property. It makes fairly easy to do a primary sort of "geographical features". --  Docu  at 06:20, 24 March 2013 (UTC)

Creator?

"X is an album by band Y". So, is Y the creator of X? Composer? Librettist? All of those? --Magnus Manske (talk) 09:05, 1 March 2013 (UTC)

I think it may be that an album is performed by a band? But, we don't have such a property right now. Danrok (talk) 09:21, 1 March 2013 (UTC)

A good term (for music) would be "performer". Unfortunately the English term "artist" (en:Infobox album) is the same as used in art (painters etc.). --Kolja21 (talk) 19:41, 1 March 2013 (UTC)

See also: Property talk:P170 (creator / artist). --Kolja21 (talk) 19:42, 1 March 2013 (UTC)

Please see Property:P175 for performers. We need a songwriter property. I asked on the talk page of the "composer" property if composer and songwriter could be combined (mixing of high/low music genres! oh no!), but have not had a reply. Espeso (talk) 19:28, 7 March 2013 (UTC)

Uncertain information

How is uncertain information going to be added to this database? For example, Ptolemy I Soter father Philip II of Macedon according to some historians, but Ptolemy I Soter father Lagus according to others. Albmont (talk) 19:04, 7 March 2013 (UTC)

Maybe with a meta:Wikidata/Notes/Data_model_primer#Qualifiers (Qualifier) At the moment, we don´t have that. --Goldzahn (talk) 19:20, 7 March 2013 (UTC)

Company ownership

Would this be a sensible choice for a new property? Or should it go under employer? We currently have no such property (though we do have the reciprocal property owned for organisations). I'm thinking of Roman Abramovich, who owns Chelsea F.C. -- and Millhouse Capital, for that matter. Now for the former of those I don't think it's particularly accurate to say he's employed by the club... The second it may be more realistic for, but I'm still not sure. Buttons to Push Buttons (talk) 15:46, 9 March 2013 (UTC)

Why not use "owner" Property:P127: owner of the subject? (See: Roman Abramovich.) --Kolja21 (talk) 03:34, 10 March 2013 (UTC)

Well, the example used suggests that it should be used the other way round: "<Chelsea Football Club> owner <Roman Abramovich>", as in you place it on the subject's page and specify the person who is the owner. Is doing it the other way round fine too, then? Buttons to Push Buttons (talk) 09:38, 10 March 2013 (UTC)

To clarify, on Abramovich's page he is the subject, naturally, and Chelsea/Millhouse do not own him, which is what is implied by use of P127. Buttons to Push Buttons (talk) 11:32, 10 March 2013 (UTC)

We also still need a property for the kind of ownership: private (including family owned), publicly traded, government-owned, collectives, etc. Shawn in Montreal (talk) 15:40, 10 March 2013 (UTC)

I think this should be the part of the qualifier. "Qualifier (future feature) is a part of the claim that says something about the specific claim, often in a descriptive way" (Wikidata:Glossary). --Kolja21 (talk) 21:27, 10 March 2013 (UTC)

Based on what I see here at meta:Wikidata/Notes/Data_model_primer#Qualifiers I think what I'm suggesting is a property, not a mere qualifier, but I'm sure the community will decide appropriately. Shawn in Montreal (talk) 21:34, 10 March 2013 (UTC)

Yes, probably we have to find a better solution. Let's wait till the essential functions of Wikidata work. (After all we are sitting in a plane, that flies, and now we are in the air we think about what kind of navigation and landing system we need.) --Kolja21 (talk) 21:42, 10 March 2013 (UTC)

@Buttons to Push Buttons: Your right about Abramovich. I think the software should add the reverse entry (spouse <-> spouse; company <-> owner; book <-> author); Freebase is doing this. --Kolja21 (talk) 21:35, 10 March 2013 (UTC)

Ownership is closely conected to the question what kind of company it is. Is it limited by shares, owned by shareholders. Is it Gesellschaft mit beschränkter Haftung. Is it privately owned by the manager, is it owned by a group of persons or by a holding. Ownership means something totally different in each case. Main question: will be the owner resonsible and pay with his own money for debts in case of bankruptcy of the company?--Giftzwerg 88 (talk) 23:19, 14 March 2013 (UTC)

Entity type of species

What "entity type" (P107) is a species (or genus, family,..)? "term"? --Magnus Manske (talk) 16:58, 12 March 2013 (UTC)

I don´t know, but I think we should create a new one. --Goldzahn (talk) 17:33, 12 March 2013 (UTC)

Term Snipre (talk) 18:39, 12 March 2013 (UTC)

Search for the species at http://viaf.org/. If it has a GND entry, use the main type from that. If it doesn't, why try to make one up?

So now we have three different answers! :-) Anyway, wouldn't Property talk:P107 be a better place to discuss this question? --Avenue (talk) 02:29, 13 March 2013 (UTC)

Hi Magnus, take a look at Wikidata:Infoboxes task force/terms: "All terms, including biology, chemistry, brands, software products, and historic events." --Kolja21 (talk) 03:08, 13 March 2013 (UTC)

is-a vs. entity-type vs. generalization

Could someone explain the difference of these three properties to me?

Why can't I exchange all three properties randomly?

• Marie Curie entity-type person // Marie Curie is-a person // Marie Curie generalization person
• Canada is-a sovereign state // Canada entity-type sovereign state // Canada generalization sovereign state
• tree generalization plant // tree is-a plant // tree entity-type plant

All above statements make perfect sense to me. Where is my error in reasoning?--Svebert (talk) 11:45, 14 March 2013 (UTC)

entity-type only allows a few types ("There are six main types of items: person, organization, event, work, term, or place = geographical feature (+ disambiguation); see: Wikidata:Infoboxes task force.), is-a doesn't have such a restriction. generalization is new and i have no clue where it differs from is-a. --Akkakk (talk) 13:05, 14 March 2013 (UTC)

hmm. ok, there are 6 + disambiguation root entities. But why connect them via a special “is-a” property? Where would be the problem to connect Marie Curie via “is-a“ to the root entity “Person“?--Svebert (talk) 13:13, 14 March 2013 (UTC)

Good question. There has been some recent discussion about this at Property talk:P107. People seem to have strong views on the subject. --Avenue (talk) 13:28, 14 March 2013 (UTC)

"is a" is not a specific property and can be used for all items and even used several times for the characterization of the same item. So calling the item data defined by "is a" in a infobox will require an important work of filtering in order to get the right information. By integrating an entity-type you can can reduce the number of items to analyze in order to get the correct item.

To give an example: if you have one big room with boxes filled with clothes and shoes or 2 rooms with in the first one boxes containing shoes only and the second room filled with boxes containing clothes, it will be easier to find a blue shirt in the 2nd case.

Entity-type is an arbitrary classification but allowing a reduction of data analysis when looking for a specific item. That's why a hierarchixal classification can provide a quicker answer if it's well defined. Snipre (talk) 18:32, 14 March 2013 (UTC)

Is this really the reason? I can't imagine that a factor of 6 does mean anything in todays computation times. If this would bring a factor of say 100 or more for completing a query -ok- but 6???

I have no idea how the database system works technically but i am pretty sure, that there are much more efficient ways implementing “fast“ queries.--Svebert (talk) 19:24, 14 March 2013 (UTC)

It is not the main reason because wikidata is a dual db used by machines and humans. Six branches are not an optimized classification for machines but this allows the definition of a good query because 6 definitions can easily be handled by humans (and not 20 or 30) reducing the computational work of the machines. Do you know how many servers are used by wikimedia to run wikipedians ? Then with wikidata we can multiply the number of query not only between personal computer and servers but between servers too. Just imagine the view of an article with the present system: one call to one server to get all the information. With wikidata you will have one call to wikipedia to display a list or an infobox plus the call to get the data. You just double the interactions for the same output. Snipre (talk) 19:57, 14 March 2013 (UTC)

The GND main types (P107) are used in the authority templates (Wikimedia Commons and German Wikipedia) in more than 200.000 articles. They have a controlled vocabulary. I think it would help, if they have their own items, since (for example) "type p" (P107) is called generalized "person", but it doesn't have to be one single person. There is a discussion on Wikidata talk:Notability#GND main types. --Kolja21 (talk) 04:10, 15 March 2013 (UTC)

Than this property must be renamed to GND-main-type. Now it does not reflect that the motivation of its existence is just the GND-template in the german wikipedia. I thought it is some kind of “root“ categorization.--Svebert (talk) 07:30, 15 March 2013 (UTC)

I changed the label to "main type (GND)" (diff), since it doesn't seem like there's any significant disagreement on that. Emw (talk) 20:10, 16 March 2013 (UTC)

GND entity type of a list

What should the GND entity type of a list be? Specifically, see this edit. I reverted it because that is not one of the 7 established GND types. --Izno (talk) 21:35, 18 March 2013 (UTC)

There is no such type, see Property talk:P107#More types. --Kolja21 (talk) 15:08, 19 March 2013 (UTC)

That was my impression. --Izno (talk) 16:59, 19 March 2013 (UTC)

Animals are persons too

Most properties under the Person part can be applied to animals and even plants. So the part can be named "Organisms, mainly people". Janjko (talk) 10:55, 20 March 2013 (UTC)

• The dog Laika was a person (or named individual), while dog is a term, of subclass organisms. I don't think we can change these definitions easily, since they are based on the GND ontology. See Template:main types. Instead I think the property domain should be based on subclasses that are related to what infobox the property is used in. Mange01 (talk) 11:51, 20 March 2013 (UTC)

• I think a better way to handle this case would to say that Laika was an instance of the class dog, and dog is a subclass of the species Canis lupus (through which it can be deduced that Laika is an organism). Calling Laika a person indicates that 'person' really means "any instance of an organism", which stretches the semantics of 'person' significantly beyond the conventional definition of that term. Emw (talk) 01:39, 21 March 2013 (UTC)

• I wouldn't worry too much about where things are listed. If the GND type is simply a loose definition which aligns with a particular ontology, it makes sense to ignore it where a property "needs" to be used under more than one set. See e.g. that many of the properties listed under "work" (genre, publisher, etc.) also apply to software programs and video games, which are under "term". --Izno (talk) 12:59, 20 March 2013 (UTC)

What´s this?

Special:Contributions/Dogatv. Spam? --Goldzahn (talk) 01:55, 22 March 2013 (UTC)

   User name: Dogatv
   User ID: 16466605
   Registered: 00:28, 22 March 2013 (110 minutes ago)
   Home wiki: www.wikidata.org
   Total editcount: 36
   Locked: no
   Hidden level: no

very strange .. 36 edits, all new pages in Property namespace. --  Docu  at 02:20, 22 March 2013 (UTC)

Noticed. --Ricordisamoa 02:24, 22 March 2013 (UTC)

 deleted and blocked by Moe Epsilon --Ricordisamoa 02:46, 22 March 2013 (UTC)

Merge Property:P92 and Property:P248

These two properties say the same thing: data is coming from one reference. Why do you need to do a difference between legal document and others ? Snipre (talk) 19:40, 23 March 2013 (UTC)

P92 indicates that it is a primary source, whereas most source are highly indirect. It also indicates that the claim has some sort of legal enforceabiliy, as (opposed to factualy accuracy). However I agree that the difference may not always be clear cut, and that a separate property may not be the best way to indicate this. I am fine with merging P92 into P248. It appears that P92 is also used in another way, as an indenpdent property meaning "foundational text, statute", for instance in Q1065. I think we should recreate a property for this, but I cannot think of any good name. --Zolo (talk) 20:32, 23 March 2013 (UTC)

Proposal regarding Property:P61

Please see this discussion; comments welcome. --Paperoastro (talk) 13:34, 25 March 2013 (UTC)

preceded and succeeded by on categories

Having these be used for categories doesn't make sense. The relation can be inferred by preceded/succeeded for the data items themselves in combination with "main article in category" e.g. 2012 preceded by 201, and Category:2012 main article 2012. --Izno (talk) 14:14, 26 March 2013 (UTC)

At least this may be useful for navigation on Wikidata items themselves. There are also similat navigation templates for Wikipedia categories. --EugeneZelenko (talk) 14:19, 26 March 2013 (UTC)

IMO, we should attempt to avoid managing the infrastructure of other projects where possible. Adding preceded/succeeded by to categories, templates, etc. does exactly what we shouldn't do. --Izno (talk) 14:22, 26 March 2013 (UTC)

It's useful for Wikidata itself, navigation templates for years related categories are much more complicated. --EugeneZelenko (talk) 14:32, 26 March 2013 (UTC)

Generalizing Property:P206

I think will be good idea to make this property more generic (located on instead of located on lake), so it could be applied to rivers, plains, etc. --EugeneZelenko (talk) 14:16, 26 March 2013 (UTC)

Coats of arms and seals

What is the difference between coat of arms image and seal image? They seem a duplicate to me. --NaBUru38 (talk) 21:13, 27 March 2013 (UTC)

Table of properties

Could we move the table of properties to the top right corner? And maybe we could shorten the Contentbox. For example, we could delete the second and third level and show only the first level. Maybe only for small chapters (2, 3, 5). At the moment we have about 200 properties. I guess, with more 1000 properties - next year - this list will be unusable. --Goldzahn (talk) 04:57, 28 March 2013 (UTC)