Wikidata:Properties for deletion

From Wikidata
Jump to: navigation, search
Shortcut: WD:PFD

This is the properties for deletions page. To nominate a property for deletion, complete the following steps:

  • Place the {{Property for deletion}} template on the property talk page.
  • Open the discussion on this page under the "Requests" section below.
  • Notify the user who originally proposed the property and the property creator for it on their respective talk pages.
  • Validate the property isn't being used in other projects (using {{ExternalUse}}) and if it is leave a message in Village pump of the project project

Requests may be closed after 7 days, but may be extended if consensus is not reached. If the request is uncontroversial, for example "accidentally created with wrong datatype", please use the faster-moving requests for deletions instead.

Add a new request


On this page, old requests are archived. An overview of all archives can be found at this page's archive index. The current archive is located at Properties/1.

Edit



Requests[edit]

Please add a new request at the bottom of this section, using {{subst:Rfd|1=pagename|2=reason for deletion}}.


invalid ID (P132)[edit]


tennis doubles ranking (P1119)[edit]

(delete | history | links | logs | discussion)

Redundant with P1118.--Filceolaire (talk) 00:09, 19 April 2014 (UTC) Replace tennis singles ranking (P1118) and tennis doubles ranking (P1119) with a generic 'Ranking" property that can have the qualifier sport (P641) so it can be used for all sorts of sports that publish rankings. It can also be used as a qualifier in competitions and elections to record which participant (P710) was 1st, 2nd, 3rd etc.

In tennis, most players have two rankings simultaneously, one for single play, and one for double play. As far as I'm aware, for mixed-double there is no ranking, therefor that property has not been requested. I would support the creation of a new property "sports ranking" that might be useful in other sports, but for tennis we would need these two anyways. Edoderoo (talk) 22:50, 19 April 2014 (UTC)
There is probably as many ranking that there is sport organisations. I would propose to use a generic ranking properties with a qualifier to precise of which ranking we are referring to. TomT0m (talk) 09:42, 20 April 2014 (UTC)
@Edoderoo: You don't need two special properties for singles and doubles tennis. Just have Ranking (P????) with 2 values. One with qualifier sport (P641) = Singles tennis and the other sport (P641) = doubles tennis. Filceolaire (talk) 00:17, 25 April 2014 (UTC)
  • Pictogram voting question.svg Question I agree 100% with this deletion request, .. however ... as I understand it, Wikidata Client cant access qualifiers at the moment, so there is no way for infoboxes to differentiate between two values for the same property..? If so, I think Wikidata's duty to be useful for infoboxes means this deletion should be put on hold until Wikidata Client allows properly structured data. John Vandenberg (talk) 07:03, 25 April 2014 (UTC)
    Wikidata Client can access qualifiers, but it require support from Lua-modules. -- Innocent bystander (talk) (The user previously known as Lavallen) 15:11, 20 May 2014 (UTC)
  • Pictogram voting question.svg Question As ranks change, how would the history of both rankings be mixed in one property? --- Jura 15:29, 10 May 2014 (UTC)
Jura: Use sport (P641)=<singles tennis> and start time (P580) as qualifiers to note when a singles ranking was first achieved and end time (P582) when it changed. Similarly for doubles. This means a tennis player might have twenty values for this property, each with three qualifiers. Mark both the current values (singles and doubles) as 'preferred' Filceolaire (talk) 20:19, 30 May 2014 (UTC)
Though "singles tennis/doubles" is not a "sport or discipline" (btw those words means almost the same in Finnish), but "tennis" alone is. --Stryn (talk) 17:15, 23 June 2014 (UTC)
Symbol delete vote.svg Delete I started already a new property proposal for the generic property 'ranking' because in dewiki there's the wish that the rankings of table tennis players get stored in WD. --Pasleim (talk) 11:39, 30 May 2014 (UTC)
I see User:Pasleim's proposal has now been approved as ranking (P1352) so we should delete both tennis singles ranking (P1118) and tennis doubles ranking (P1119). Filceolaire (talk) 21:18, 13 June 2014 (UTC)
Symbol delete vote.svg Delete As a simpler solution is available. Snipre (talk) 08:08, 27 June 2014 (UTC)
Symbol delete vote.svg Delete We have a more generic property: ranking (P1352). Look at Eva Ódorová (Q5415215) for an example. And yes, we should delete also tennis singles ranking (P1118) --ValterVB (talk) 19:17, 25 September 2014 (UTC)
But in the item you linked, there's "sport: table tennis", then in tennis player items it would be "sport: singles tennis"? Also table tennis can be played as doubles (though I don't know if they have a ranking for doubles). Anyway, then we should create items for singles tennis and doubles tennis, if they don't exist yet. --Stryn (talk) 14:30, 26 September 2014 (UTC)
@Stryn: Already created: singles tennis (Q18123880) and doubles tennis (Q18123885). Example in Serena Williams (Q11459) --ValterVB (talk) 18:38, 26 September 2014 (UTC)
Nice, though still, singles tennis is not in w:list of sports (as sport (P641) is), but meh, I think I'm alone with my opinions here :-) --Stryn (talk) 19:08, 26 September 2014 (UTC)

Just came in my mind: how about ITF junior/senior/wheelchair rankings (from ITF website)? I think that we should add them also. If so, then we should keep this property. --Stryn (talk) 21:20, 9 December 2014 (UTC)

Symbol delete vote.svg Delete Use ranking (P1352) instead. --Casper Tinan (talk) 08:26, 17 December 2014 (UTC)
I tried to test it at Wikidata Sandbox Testing Testing 1 2 3 (Q4115189), but it doesn't look very good. Then, do we create items also (in addition of singles tennis (Q18123880) and doubles tennis (Q18123885)) to wheelchair tennis singles, wheelchair tennis doubles, ITF tennis juniors and ITF beach tennis? --Stryn (talk) 18:09, 21 December 2014 (UTC)

applies to jurisdiction (P1001)[edit]

(delete | history | links | logs | discussion)

Originally this property was supposed to mean that an item is under jurisdiction of an entity. Over time it took up other roles like an item applies to a certain jurisdiction and that an item contains certain jurisdictions. Currently it is a mess, so I propose to deprecate this property and create 3 more specific properties:

  • is in jurisdiction of
  • contains jurisdiction
  • applies to jurisdiction

Which are the current uses of p1001.--Micru (talk) 10:40, 7 July 2014 (UTC) No longer valid, see new deletion proposal below. --Micru (talk) 08:32, 10 July 2014 (UTC)

Pictogram voting question.svg Question @Micru: How is "in the jurisdiction of" different than located in the administrative territorial entity (P131)? And how is "contains jurisdiction" different than contains administrative territorial entity (P150)? --Closeapple (talk) 10:59, 7 July 2014 (UTC)
@Closeapple: So far I haven't seen any use of p131 other than to denote government-related entities. If other uses were acceptable, then I still think it is necessary to reboot p1001. It has too many inconsistent uses and the labels in other languages refer to different concepts.--Micru (talk) 11:08, 7 July 2014 (UTC)
@Micru:: If located in the administrative territorial entity (P131) is just for other administrative entities, I'm in trouble: I just added it to a bunch of other geographical items yesterday. I think located in the administrative territorial entity (P131) and contains administrative territorial entity (P150) would work (and are being used) for the first two replacements. --Closeapple (talk) 11:51, 7 July 2014 (UTC)
Symbol neutral vote.svg Neutral on deletion of P1001 specifically. (My only knowledge is about the suggested replacements.) --Closeapple (talk) 11:51, 7 July 2014 (UTC)
@Closeapple: alternatively all labels and descriptions from p1001 could be deleted so the users can translate the current label into other languages, with the hope that the wrong uses of this properties will be corrected over time.--Micru (talk) 08:06, 9 July 2014 (UTC)
Symbol oppose vote.svg Oppose deleting applies to jurisdiction (P1001) only to replace it with a new property which is also called 'applies to jurisdiction'. If the P1001 is being used where located in the administrative territorial entity (P131) or contains administrative territorial entity (P150) are more appropriate then ammend the description to make it clearer how it should be used and add some aliases to P131 and P150 so they show up in searches for 'jurisdiction'. If there is a real use case that isn't covered by these three existing properties then propose the creation of that additional property. Nothing you have said above justifies the deletion of P1001. Filceolaire (talk) 08:14, 10 July 2014 (UTC)
@Filceolaire: I think you are opposing the original deletion proposal, but that has changed (see below). The current proposal is to deprecate p1001 in favour of a generic "applies to" property (based on p:p518). Of course while p1001 is deprecated there would be time to move the statements either to "is in administrative territorial entity" or to "applies to".--Micru (talk) 08:32, 10 July 2014 (UTC)

New deletion proposal[edit]

Snipre suggested to delete this property and merge it with a more generic "applies to" (based on p:p518). I think it might be a good idea.--Micru (talk) 12:25, 9 July 2014 (UTC)

Symbol delete vote.svg Delete With merge with p:p518 in a general property "applies to". Snipre (talk) 12:41, 9 July 2014 (UTC)
I have no objection. - Brya (talk) 16:44, 9 July 2014 (UTC)
Pictogram voting question.svg Question: Is this a proposal to use applies to part (P518) in most cases, or to create a new property that is similar to P518? --Closeapple (talk) 12:39, 10 July 2014 (UTC)
@Closeapple: I have suggested to extend applies to part (P518) (See: Property_talk:P518#Generalizing_this_property), but I don't know yet if there is any objection.--Micru (talk) 13:16, 10 July 2014 (UTC)
Symbol keep vote.svg Keep I don't think applies to part (P518) can alter this... by Revicomplaint? at 10:34, 3 August 2014 (UTC)
  • Symbol oppose vote.svg Oppose. (Abstain on whether to keep or delete.) This property is problematic, but replacing it with a generic "applies to" leaves the meaning ambiguous, and might not work well in all languages. --Yair rand (talk) 20:51, 11 September 2014 (UTC)
  • Symbol oppose vote.svg Oppose. It could be renamed, but it's an important enough statistic that we should keep it. Also, Yair_rand is probably right that merging it with P:applies_to would create ambiguity in a number of languages. P:applies_to is a qualifier that means "this property is only valid in these contexts" whereas P:jurisdiction means "this item only has authority over that item". P:jurisdiction also isn't the same as P:in_administrative_entity; for example, High Court of Justice (Q1617747) is in England but it has jurisdiction over England and Wales while National Assembly for Wales (Q493517) is in Wales and only has jurisdiction over Wales. The jurisdiction property could possibly also have non-geography values; for example, a medical ethics review board only has jurisdiction over registered doctors and nurses. --Arctic.gnome (talk) 19:21, 12 September 2014 (UTC)
  • Symbol keep vote.svg Keep --DangSunM (talk) 02:13, 31 October 2014 (UTC)
  • Symbol keep vote.svg Keep as per Arctic.gnome above. Much as I would like a generic qualifier property like 'applies to' I think there is also a need for a specific property for jurisdiction. Filceolaire (talk) 22:41, 2 November 2014 (UTC)

number of platforms (P1103)[edit]


number of cylinders (P1100)[edit]


contains settlement (P1383)[edit]

The functionality of this property can be covered by the (already existing) has part (P527). For many Belgium and Dutch municipalities I used has part (P527) in the past to do the same as P1383 aims to do (list all villages within a municipality). So in my opinion this property was not needed. Michiel1972 (talk) 11:35, 15 August 2014 (UTC)

Symbol keep vote.svg Keep The settlements are not parts of the municipality. P1383 is similar to contains administrative territorial entity (P150), but P150 is restricted to administrative units. I propose to extend P150 to all settlements, not only administrative units. has part (P527) is not the right property. --JulesWinnfield-hu (talk) 13:01, 15 August 2014 (UTC)

I don't understand your comment 'settlements are not parts of the municipality'. In my opinion villages/hamlets are part of a municipality, so we can use P527 (has part (P527)). Michiel1972 (talk) 18:04, 17 August 2014 (UTC)
They are not parts. They don't form a municipality. The municipality is not a collection of settlements. The municipality is an administrative entity, settlements are geographical entities. The municipality administers the settlements. The settlements belong to the jurisdiction of the municipality. They are not parts. P150 is just good, if we lift the restriction. Otherwise P1383 should be used. I don't understand why P150 is restricted. It is the same relation. --JulesWinnfield-hu (talk) 19:58, 17 August 2014 (UTC)
contains administrative territorial entity (P150) is specifically for formal administrative entities. located in the administrative territorial entity (P131) looks like the inverse of invalid ID (P151) but can be used by informal settlements (or houses or whatever) that are located in the Administrative entity. I am happy to delete all the contains settlement (P1383) statements and replace them with located in the administrative territorial entity (P131) statements in the items for the settlements where they belong. Putting a bunch of P1383 statements in the item for the Administrative entity is IMHO the wrong way to do it.Filceolaire (talk) 23:57, 2 November 2014 (UTC)
contains settlement (P1383) just like contains administrative territorial entity (P150) is a property in many infoboxes. The only reason P150 can't be used is a constraint that restricts it only to administrative entities and excludes settlements that are not administrative entities. It just cuts off the last level in a hierarchy. The settlements of an administrative unit is an exact, legal fact, not among other whatevers. What property do you suggest to list them? --JulesWinnfield-hu (talk) 10:22, 3 November 2014 (UTC)
User:JulesWinnfield-hu excludes settlements that are not administrative entities - any example? Andrea Shan (talk) 04:29, 24 November 2014 (UTC)
Villages of a municipality. --JulesWinnfield-hu (talk) 10:31, 24 November 2014 (UTC)

Datatype change: (OBSOLETE) title (use P1476) (P357), quote (P387), subtitle (string) (P392), inscription (P438)[edit]

Should be replaced with monolingual-text type. GZWDer (talk) 09:50, 30 August 2014 (UTC)

The difference between a title and a subtitle is useful for books, articles, pamphlets, etc. --Dereckson (talk) 00:44, 1 September 2014 (UTC)
@Dereckson: the proposal was to change the datatype, not to merge the properties.
I think this should indeed be better, but, for inscriptions at least, I would rather wait until we know if we can add "no language" and "language undetermined" (see bugzilla:70205).--Zolo (talk) 10:57, 1 September 2014 (UTC)
Sounds reasonable, but we can probably create monolingual-text versions of these in the meantime, even if we can't delete the old ones yet. --Yair rand (talk) 21:43, 3 September 2014 (UTC)
Yes it may take some time to make the full conversion anyway, as we need to add the language value that for each statement, and many are probably not provided as qualfiers. Also, we should probably let the old properties coexist with the new for some time, so that clients can adapt their codes. --Zolo (talk) 13:13, 4 September 2014 (UTC)
Do each of these need property proposals? --Yair rand (talk) 05:01, 11 September 2014 (UTC)
I have made a proposal for a new title property at Wikidata:Property proposal/Creative work, but it would probably have been better to make one bulk proposal. --Zolo (talk) 10:30, 11 September 2014 (UTC)
Symbol support vote.svg Support --Kolja21 (talk) 16:23, 12 September 2014 (UTC)
Symbol oppose vote.svg Oppose against the change. We already have original language of this work (P364) and language of work (P407) to mark item language, enforcing language specification into every title is overcomplication. (existing of new property is not an argument -- to create new property we needed 3 people, not consensus). Also, there is still no answer what to do with artificial languages that can't be specified in drop-down list (but have appropriate q-IDs). Or what to do with titles like "cthulhu fhtagn" (no, that is not English). -- Vlsergey (talk) 10:32, 19 September 2014 (UTC)
@Vlsergey: This problem will be resolved if we can add language = uncoded languages (ISO 639-2 : "mis"), and use original language of this work (P364)/language of work (P407) as qualifier.--GZWDer (talk) 09:06, 21 September 2014 (UTC)
For me it still looks like creating problems instead of solving. Simple cases must be simple -- specify language once (in original language of this work (P364)/language of work (P407)) and use qualifiers in cases of different languages. Do not force user to specify languages several times. -- Vlsergey (talk) 09:12, 21 September 2014 (UTC)
Symbol oppose vote.svg Oppose @Vlsergey: You've convinced me. title (P1476) makes things indeed more complicated. --Kolja21 (talk) 12:40, 27 September 2014 (UTC)
@Vlsergey: You assume that title and subtitle are always in the same language than the text but this is not always the case. If you think about translations you have titles which are not translated (TV series or movies can keep the title in the original language even if the version is in another language). I find more disturbing the use of original language and language in the same item than having to enter several times the language. It is better to lose a little more time at the beginning to enter clear data than to spend more time in the future to understand the different ways to use original language and language by several thousands of contributors. The only reason to keep (OBSOLETE) title (use P1476) (P357) is if we don't have the possibility to select the proper language.
And if you have a look at Help:Sources the monolingual version of title and subtitle was already waited. I modified the recommendations of Help:Sources to use title (P1476) and without better opposition I will launch the move from (OBSOLETE) title (use P1476) (P357) to title (P1476) according to the rules edited in Help:Sources. We can't keep 2 properties for the same concept. Snipre (talk) 09:02, 30 September 2014 (UTC)
@Snipre: 1. no, i do not and never assumed that. But I assume (try to prove me wrong) that 99% of cases title and subtitle are in the same language. 2. Handling translations is different questions. I can hardly understand why you trying to keep data "clean" using new datatype and at the same time keeping data "dirty" by placing different subjects (original movie and translations) into the same entity. 3. One can always change it back, it is not an argument. 4. You must not start any operation until we have consensus, sorry. -- Vlsergey (talk) 13:32, 30 September 2014 (UTC)
@Vlsergey: The consensus for moving (OBSOLETE) title (use P1476) (P357) to title (P1476) exists from more than one year and was approved with the guideline for sourcing (see here). If we start to discuss again and again topics which were solved, we never take decisions. Title was ever one of the main reasons of the development of the monolingual datatype. According to the comment on Help:Sources this was planned and announced to everyone using that guideline. So if you want a consensus to delete (OBSOLETE) title (use P1476) (P357), I agree and I think we have to solve exceptions before to do that, but there is no need of consensus to move (OBSOLETE) title (use P1476) (P357) to title (P1476) because the consensus exists already.
You don't assume that 100% of the titles have the same language than the text but you assume only 99%. If you start to ask me to prove anything I can play childish and ask you to do the same. Here the question is not to know who has the longest d..k but to think and to propose solutions which can be applied to the maximum of cases in order to avoid exceptions which are a nightmare to solve and to be sure that all contributors will apply.
"Handling translations is different questions." No this is not a different question: again we need global solutions, for original work and their translations. Do you want to start a help page describing all different scenarios and how to solve them ? With the monolingual datatype we get ride of the difference original language and language and we don't have to start to work with qualifiers. Snipre (talk) 15:07, 30 September 2014 (UTC)
Another thing that may be worth noticing is that most Wikipedias seem to recommend putting foreign language string inside a Template:Lang (Q6610935). Now I am not sure it is tremendously useful, but it is so widely done that I suppose there are valid reasons for it. And this can be done much more simply, and more accurately, with monoligual text than with normal strings. -Zolo (talk) 14:28, 30 September 2014 (UTC)
The original language of the film Fack ju Göhte (Q15268063) is German. But what language is the title: Fack ju Göhte? German or wrong spelled English? And if the title is a name like "Anna"? The film might be French, the person whom the name belongs to English but the author has choose it because he thought of his Spanish girlfriend. --Kolja21 (talk) 16:03, 30 September 2014 (UTC)
There will be cases that are hard/impossible to determine. This is the reason behind bugzilla:70205. For titles like "Anna", I tend to think this should be considered to be in the same language as the original language of the movie, unless we have reasons to consider otherwise. --Zolo (talk) 07:41, 1 October 2014 (UTC)
@Kolja21. Very bad examples. Fack ju Göhte: Can't be wrong spelled English because English doesn't use "¨". "Anna": Can the string datatype solve that problem ? No, both string and monolingual datatypes fail to solve that problem. But you can apply the same reasoning to solve both cases: the language of the title is the same like the language of the original text/movie. Snipre (talk) 16:12, 1 October 2014 (UTC)
  • Symbol support vote.svg Support, particularly for quote. The String datatype should be used exclusively for non-lingual data. --Yair rand (talk) 15:32, 1 October 2014 (UTC)
    • Symbol support vote.svg Support, agree with Yair rand. The "no language", "language undetermined" and "uncoded language" possibilities should be added to the datatype, though.--Shlomo (talk) 11:19, 14 October 2014 (UTC)
  • Pictogram voting comment.svg Comment Can we just change these properties' data type from string to monolingual text? Is it technically possible? If so, we do not need to delete these properties. --Neo-Jay (talk) 04:10, 29 October 2014 (UTC)
it's technically not possible. --Pasleim (talk) 09:55, 29 October 2014 (UTC)
  • Symbol support vote.svg Support. as Yair above. Filceolaire (talk) 13:59, 9 November 2014 (UTC)
  • Pictogram voting comment.svg Comment As far as I understand, the main problem of switching from string to monolingual text is that we cannot omit the language when entering monolingual text. Thus, we will not be able to enter some special cases of titles, so we will either need two separate properties (which is not good) or to add special cases for the language part like "language undefined" or "no language". But if we have monolingual text with "no language", do we really need string data type at all?:) --DixonD (talk) 19:55, 23 November 2014 (UTC)
  • @DixonD: String is needed. for example ISBN-13 (P212) can not be in any languages.--GZWDer (talk) 12:15, 7 December 2014 (UTC)
    Well, String is essentially Monolingual text with "no language". Am I missing anything here? --DixonD (talk) 09:01, 8 December 2014 (UTC)
  • Symbol support vote.svg Support for quote at least; nonsensical to quote text without indicating language. -- LaddΩ chat ;) 16:03, 7 December 2014 (UTC)

Datatype change: short name (P743)[edit]

(delete | history | links | logs | discussion)

Change to monolingual text datatype.--Shlomo (talk) 06:18, 5 September 2014 (UTC)

Symbol support vote.svg Support. This feature is useless without language. --putnik 17:39, 6 September 2014 (UTC)
Not useless, e. g., United Kingdom is shortened UK language-independant, but a monolingual datatype would be more useful; Symbol support vote.svg Support --Akim Dubrow (talk) 17:55, 6 September 2014 (UTC)
United Kingdom of Great Britain and Northern Ireland is shortened to United Kingdom or Royaume Uni etc. Looks like multilingual datatype is required. Filceolaire (talk) 15:10, 19 December 2014 (UTC)
Symbol oppose vote.svg Oppose the language is usually obvious from context of parent property (if used as qualifier for full name like official name (P1448) or (OBSOLETE) title (use P1476) (P357)) or entity (check language of work (P407) of the entity). may be we just need to make this property "qualifier only". -- Vlsergey (talk) 14:28, 12 September 2014 (UTC)
Symbol support vote.svg Support That's correct.--دوستدار ایران بزرگ (talk) 17:34, 10 October 2014 (UTC)
I'm the "father" of this property and I agree that this datatype is not the best. But I am not sure "monolingual text" is the best option. I used this for example as "Stockholm" as short name for "Stockholm City" and "Stockholm Municipality". I am not sure monolingual Stockholm would be a good option in for example Portuguese or Finnish, since they use other names for this entity. Observe that I have never proposed that this property should be used for abbreviations like United Kingdom/UK, rather for when you write "Municipality: "[[Stockholm Municipalty|Stockholm]]" in templates. The use should then be something like [[<WD-sitelink>|<WD-prop 743>]] instead of [[<WD-sitelink>|<WD-label>]] in the code in our templates. This especially when the "short name" is not identical with the "label", something I experience problems with in the Swedish language. Look for example in sv:Template:Jönköpings län 1952 where you find two entities with the same short name "Vetlanda" but who has different official names "Vetlanda landskommun" and "Vetlanda stad". Add to that "Vetlanda köping", "Vetlanda municipalsamhälle", "Vetlanda kommun", "Vetlanda församling", "Vetlanda socken", "Vetlanda distrikt" and the urban area of "Vetlanda", and you see some of my problems. The long names here are the official (with maybe some exception) but the full official names are not always used our templates. -- Innocent bystander (talk) 11:58, 2 November 2014 (UTC)
Symbol delete vote.svg Delete in favor of datatype change. Having language of work (P407) for entities like NATO or the European Union doesn't make much sense, considering that they have multiple official languages. You can't correspond a short name to a specific language without using language of work (P407) as a qualifier for the short name. I don't see an advantage using this method over using monolingual datatype. —Wylve (talk) 15:50, 14 November 2014 (UTC)
  • Symbol support vote.svg Support changing the datatype of "short name" (P:P743) from string to monolingual string. --- Jura 13:28, 30 November 2014 (UTC)
Sounds like most of you talk about this property as an "abbreviation"-property. It was never proposed or intended as such! A mono-lingual datatype does not fit the purpose of the property. You need a multi-lingual datatype. -- Innocent bystander (talk) 09:56, 3 December 2014 (UTC)

docking port (P546)[edit]

(delete | history | links | logs | discussion) Discussion for the property creation

Existing since May 2013 but still not used.

Keep. Property talk:P546 defines clearly the notion, and indicates this is an infobox field.
The main goal is to note the docking port of spaceships. The example given during the discussion were Soyuz TMA-9 first docking port is the Zvedza ISS module. I've added it, so we have a working example.
A similar property is the home port. So we can describe regular traject from home port to docking port with these two properties. --Dereckson (talk) 09:59, 11 September 2014 (UTC)
See also spacecraft docking/undocking (P622), which is more used. So we have the date and the location. --Dereckson (talk) 17:42, 13 September 2014 (UTC)
  • Symbol delete vote.svg Delete "docking port" (P:P546): @Dereckson: unless there are at least 5 uses, I'd delete this. --- Jura 13:28, 30 November 2014 (UTC)

pseudonym (P742)[edit]


ship class (P289)[edit]

(delete | history | links | logs | discussion)

Redundant with instanceOf Property:P31.--Andrea Shan (talk) 18:42, 23 November 2014 (UTC)

Pictogram voting comment.svg Comment - This is as redundant as "lake type" and "mountain type". The item USS Ronald Reagan [1] has both "instance of = Nimitz-class aircraft carrier" AND "ship class = Nimitz-class aircraft carrier". Same duplication "Soviet aircraft carrier Admiral Gorshkov (Q359024)" with "Kiev-class aircraft carrier". Below are some numbers to show that currently the values are not consistent:
  • "claim[289]" - 912 items
  • "claim[31:(tree[11446][][279])]" - 28,323 items (instances of "ship" or one of its subclasses)
  • "claim[289] and claim[31:(tree[11446][][279])]" - 857 items - inconsistency, should be 912
  • "claim[289] and claim[31]" - 895 items - inconsistency, should be 912
  • "claim[289] and noclaim[31:(tree[11446][][279])]" - 55 items - inconsistency, should be zero
  • "claim[289] and noclaim[31:(tree[11446][][279])] and claim[31]" - 38 items - inconsistency, should be zero
By eliminating P289 the above inconsistencies will be eliminated too. Andrea Shan (talk) 18:48, 23 November 2014 (UTC)
@Danrok, Goldzahn, Laddo: --Tobias1984 (talk) 08:43, 24 November 2014 (UTC)
Here is the last discussion: Wikidata:Requests_for_deletions/Archive/2013/Properties/2#ship_class_.28P289.29 --Tobias1984 (talk) 08:46, 24 November 2014 (UTC)
Symbol delete vote.svg Delete. ship class is redundant with instance of (P31). Emw (talk) 13:47, 24 November 2014 (UTC)
Pictogram voting comment.svg Comment maybe those users that voted on lake type invalid ID (P202) (@Casper Tinan, Paperoastro, Laddo, Jakec, AmaryllisGardener: and on mountain type invalid ID (P302) @Izno, Nightwish62, 79.40.79.94, Filceolaire: can have a look here, since it is the same kind of redundancy, only instead of lakes and mountains, it is in the domain of ships. There also seems to be no other domain specific type redundancy for concrete physical entities/instances, no for cars (type of car), no for rivers (type of river), no for buildings (type of building). Andrea Shan (talk) 18:10, 24 November 2014 (UTC)
Symbol keep vote.svg Keep This one is not as clear as lake type. Ship class is a characteristic expected to be displayed in WP infoboxes; classes should be readily available from WD - I mean, not any type of ship, but specifically a class of ship. First, there are a set of specific constraints (see Property talk:P289); second, there are hundreds of classes of ship but not all ships belong to formally defined ship classes. As a result, a given ship may be instance of (P31) = something that is not a ship class... for example, currently
HMS Drottning Victoria (Q52905) <instance of (P31)  coastal defence ship (Q2304194) and ship class (P289)  Sverige class coastal defence ship (Q2976013)
while Sverige class coastal defence ship (Q2976013) <instance of (P31)  ship class (Q559026) and subclass of (P279)  coastal defence ship (Q2304194)
If we get rid of ship class (P289), you only get
HMS Drottning Victoria (Q52905) <instance of (P31)  Sverige class coastal defence ship (Q2976013)
it will be difficult for infoboxes to get the ship class because the infobox itself would have to ensure that instance of (P31) points to something that is an instance of (P31)  ship class (Q559026).
It might eventually be possible to replace that property with some on-the-fly query that would check if the target of P31 is a ship class (Q559026) and if so return it. Possible in some distant future... I'm not even sure that it will be feasible after Wikidata:Development_plan#Simple_queries gets deployed. -- LaddΩ chat ;) 01:13, 25 November 2014 (UTC)
Pictogram voting comment.svg Comment User:Laddo
  • that is a misuse of instanceOf. InstanceOf has to be as precise as it can, so I changed it to "Sverige class coastal defence ship". "Sverige class coastal defence ship" is a subclass of "coastal defence ship". ANY "Sverige class coastal defence ship" is ALSO A "coastal defence ship" - here it is even reflected in the English language title, the string "coastal defence ship" is also contained in "Sverige class coastal defence ship". String matching aside, the information that the ship is a "coastal defence ship" is found upwards in the classification tree. That is exactly the same for lakes, mountains, cars, air planes, ...
  • my fix to the item fixes your second point, "there are hundreds of classes of ship but not all ships belong to formally defined ship classes. As a result, a given ship may be instance of (P31) = something that is not a ship class... for example" now P31 gives a ship class. Andrea Shan (talk) 01:55, 25 November 2014 (UTC)
@Andrea Shan: I guess I wasn't clear enough. If the infobox wants to display the field "ship class" for Regina (Q1254588) <instance of (P31)  tugboat (Q191826), what does it display? How is it different from HMS Drottning Victoria (Q52905) <instance of (P31)  Sverige class coastal defence ship (Q2976013) ? Belonging to a ship class is very different from being a certain type of ship. These are two different concepts, assigned independently. Of course, all ships of a given class belong to the same type, but that will not help WP infoboxes figure out what to display in the field "ship class".
BTW I find it quite impolite that you elect to "fix" the item that I chose as an exemple. Not that I do not agree with your change, but I was using it as an example, you see?
-- LaddΩ chat ;) 02:21, 25 November 2014 (UTC)
@Laddo: An invalid example. Anyone could have fixed it. I find it impolite that you find it impolite if editors fix items. Regarding WP infoboxes figuring out what to display - at the Wikidata item I cannot find a value for a ship class for that ship. So, yes, if there is not value for X than WP infoboxes may have a hard time to figure out what to display - if they are unable to figure out to display no value for X as empty string or "unknown" or something similar. Andrea Shan (talk) 02:30, 25 November 2014 (UTC)
Pictogram voting comment.svg Comment The documentation contains an error, since USS Enterprise is not a watercraft. Also, the property name is misleading, since the property is applied to submarines, which are not classified as ships in Wikidata. So the valid another consistency test is, after some fixing: "claim[289] and noclaim[31:(tree[1229765][][279])]" returns four items [2], all are described as fictional spaceships/starships. Andrea Shan (talk) 02:55, 25 November 2014 (UTC)
Sorry, I don't get your point. In your example, the statement HMS Drottning Victoria (Q52905) <instance of (P31)  Sverige class coastal defence ship (Q2976013) is enough since Sverige class coastal defence ship (Q2976013)is a subclass of coastal defence ship (Q2304194). Can you give an other example in order to make things clearer ? Casper Tinan (talk) 18:07, 26 November 2014 (UTC)
I changed the example, even if it may be too much simple. I'm not expert on ship, but I followed this and the previous discussion and ontologically I'm right with the distinction between the two classifications as explained by Laddo. I have seen some items of ships and in most of the cases the statements of P31 and P289 are the same: the two hierarchies need to be fixed. In this situation it is obvious that someone ask the deletion of P289. --Paperoastro (talk) 21:54, 26 November 2014 (UTC)
There is no ontological difference between a "ship class" and a "ship type". A given instance of a ship like HMS Ven is indeed an instance of (P31) a ship class, e.g. Koster-class mine countermeasures vessel. That ship class is ontologically a subclass of (P279) another ship class, e.g. mine countermeasures vessel and so on up until ship (Q11446). "Ship class" and "ship type" are domain-specific versions of instance of (P31); they just indicate different ranks in ship taxonomy.
And like rank-specific 'type of' properties from biological taxonomy, this one should also be deleted. Consider this comment from the request for deletion of 'watercraft type':
Imaging deleting all taxonomical properties (like invalid ID (P71), invalid ID (P74), invalid ID (P77) etc) and using only instance of (P31). Such data model would be useless on other Wikimedia projects. invalid ID (P288) and ship class (P289) fulfills the same purpose for ships as invalid ID (P71), invalid ID (P74) do for animals
Note how P71 and the other properties there all have labels like "(OBSOLETE) family (P71)" or are deleted, except for P31. While I differ with WikiProject Taxonomy in certain basic aspects of their approach to classification, they were utterly correct in deprecating those biological analogs of "ship class".
This debate has already been settled. Use WikiProject Taxonomy's solution and apply an 'ontological rank' property to determine the desired subclasses of 'ship' to show in a given infobox. Fortunately, ships are a relatively small domain and ship class (P289) is not used on any Wikimedia client site per Property_talk:P289. Let's finish migrating the data away from this redundant 'type of' property, delete it, and use instance of (P31) as a generic solution for classifying this kind of thing, like the rest of the Semantic Web. Emw (talk) 04:33, 28 November 2014 (UTC)
I stand by my conviction that deleting such properties makes the use of Wikidata much more difficult to use as a source of data and therefore is contraproductive. /ℇsquilo 08:14, 28 November 2014 (UTC)
I also disagree with the statement There is no ontological difference between a "ship class" and a "ship type". HMS Ven (Q10515240) could be said to be a member of (P463) of Koster-class mine countermeasures vessel (Q10548373), but absolutly not instance of (P31). /ℇsquilo 10:13, 30 November 2014 (UTC)
Does User:Esquilo care to prove that there is no ship that is an instanceOf "Landsort-class mine countermeasures vessel"? That "Landsort-class mine countermeasures vessel" is a class of ships is already in the name. Is Are ship classes, classes without instances? What do they class then? Andrea Shan (talk) 15:41, 30 November 2014 (UTC)
Esquilo, when I say "there is no ontological difference between a 'ship class' and a 'ship type'", I mean more precisely that any given ship class or ship type is -- in the terms of ontology -- a class. They are merely different ranks in a ship taxonomy. Yes, a ship like HMS Ven may change its "ship class", but that does not entail that it is not an instance of a given "ship class" at any given time. Whether it is a good idea to use instance of here is a question on which reasonable people might disagree, but given that Koster-class mine countermeasures vessel is a subclass of mine countermeasures vessel, whether HMS Ven is an instance of Koster-class mine countermeasures vessel is not a matter of debate among people familiar with ontology.
Your assertion that "HMS Ven" could be said to be a member of "Koster-class mine countermeasures vessel" further indicates a lack of familiarity with basic membership properties. For example, "John Lennon instance of male" is correct but "John Lennon member of male" is not. Similarly, HMS Ven could be said to be a member of Swedish fleet (Q10685327), but to say "HMS Ven (Q10515240) member of (P463) Koster-class mine countermeasures vessel (Q10548373)" is an elementary mistake.
I encourage you to read http://www.w3.org/TR/owl2-primer/. It's an excellent introduction that might help clarify things better than I've done here. Emw (talk) 20:01, 30 November 2014 (UTC)
Pictogram voting comment.svg Comment In August User:Esquilo reduced the precision of the instanceOf value [3] to fit with his personal view, instead of the definition of that property. Andrea Shan (talk) 15:49, 30 November 2014 (UTC)
  • Symbol keep vote.svg Keep "ship class" (P:P289): A defined property seems more appropriate for this. Makes it easier to maintain as well. Things in P:P31 tend to be mixed up and not necessarily better maintained. --- Jura 13:28, 30 November 2014 (UTC)
    "A defined property seems more appropriate for this" - does User:Jura1 care to explain in how far rdf:Type is not a "defined property"? Does Jura1 care to consider that "Things in P:P31 tend to be mixed up and not necessarily better maintained." can be true along with "Things in P:P289 tend to be mixed up and not necessarily better maintained."? If one can insert the IDs of each property into a phrase, how can such a phrase be used to vote for one property? Andrea Shan (talk) 15:22, 30 November 2014 (UTC)
  • Pictogram voting comment.svg Comment Among millions of products that exist, and further millions of physical items made without human labor, "items" in subClass "ship" are deemed that special by four users, that they are the only items to get their own property for classification. Some even promote misuse of instanceOf. Andrea Shan (talk) 15:36, 30 November 2014 (UTC)
  • Redefine: A ship class (Nimitz, Dreadnought, Concordia, Flower, etc) is just a name that is used by humans to group individual ships of specific types (aircraft carrier, battleship, cruise ship, corvette, etc). A specific ship need not belong to any class but will always have a type. The foregoing being true, then I suggest that this property P289 is incorrectly defined because it combines class name and ship type into a single value when the two should be kept separate and only be combined at the point of use.
This last is important, not only because ships need not belong to defined classes, but also, because when used in final article form, the combination of ship class and type must be properly styled and, depending on use, hyphenated or not hyphenated. Ship classes named for a member of the class are italicized: Nimitz class when the compound term describes the class and: Nimitz-class aircraft carrier when the compound term describes the ship type. When a ship class is not named for a member of the class, the same hyphenation rules apply, but the class name is not italicized: Flower-class corvette. All of this is presentation detail which is not something that Wikidata should concern itself about.
If P289 is allowed to stand as is, users of the data, in order to provide correct presentation, must disassemble the property value to apply appropriate styling and hyphenation. P289 should be redefined to be just the class name. The ship's type should be provided by another property.
Trappist the monk (talk) 11:57, 4 December 2014 (UTC)
Pictogram voting comment.svg Comment If a ship has a class, then it's type can be derived from that class, since every class only has one type? Andrea Shan (talk) 10:43, 5 December 2014 (UTC)
Yes, but why force subscribing wikis into doing that derivation or extraction?
At enwiki, the meta thing commonly called a ship class is a construct built from one or more primitives:
  1. <class name>
  2. <class name> markup
  3. connective text <class> or <-class>
  4. <ship type>
  5. optional parenthetic <class name> disambiguator
  6. optional nationality <class name> disambiguator
  7. optional parenthetic <ship type> disambiguator
I can't speak for other wikis which may do things differently, but at enwiki, we already have the tools necessary to assemble and render a correctly formatted meta ship class for all of the above except those few that require the optional nationality disambiguation (British Porpoise-class submarine disambiguated from United States Porpoise-class submarine).
Don't make those tools obsolete by lumping all of these primitives into a single property.
Trappist the monk (talk) 16:08, 5 December 2014 (UTC)

(OBSOLETE) ship builder (P198)[edit]


Properties for events and their dates and locations[edit]

Similar to

this is a proposal to unify properties with the goal of

  1. increasing the ability to describe items,
  2. facilitating data access and presentation,
  3. increasing the availability of information in multiple languages
  4. reduce cultural bias.

All values stored by "Date of <event type>"-properties can be described using "Property:P793 significant event". As it seems all of the event types listed below, e.g. "date of birth" would qualify as significant. A qualifier links to the item that describes the type of event and another qualifier links to the item that describes location. If there is a specific item for that event, then this can be linked, and the qualifiers are left empty since date and location can be stored at the event dedicated item.

If all significant events are stored in that way, they could be easily sorted in chronological order, which could help User:Magnus Manske with the Reasonator and WMDE under User:Lydia Pintscher (WMDE) with the Wikidata:UI redesign.

Instead of translating labels and descriptions of items that are event types and also translating these for properties, the latter will not be needed anymore.

Also the current "date of birth" is culturally biased, see en:Bardo#Six bardos in Tibetan Buddhism and IIRC there are people that place the start of existence of a human at the day the parents thought about having (this) child.

Thanks a lot to User:Pasleim for maintaining Wikidata:Database reports/List of properties/all. This was a great help in collecting the properties.

Not included[edit]

Properties with data type = time, which are not proposed for deletion here:

Andrea Shan (talk) 09:05, 5 December 2014 (UTC)

I added P1317 floruit to those that could be deleted. Frank Robertson (talk) 14:07, 13 December 2014 (UTC)

List of event classes and related properties[edit]

These can all be described via significant event (P793). Many event types already use P793, see some listed at Property talk:P793#Rules.

Domain Event class Time
property
(generic)
Time
property
(specialized)
- number
Time
property
(specialized)
- English name
Time
property
(specialized)
- creator
Location
property
(generic)
Location
property
(specialized)
- number
Location
property
(specialized)
- English name
Location
property
(specialized)
- creator
Other
property
(generic)
Other
property
(specialized)
Person birth (Q3335327) point in time (P585) 569 time of birth User:Tpt location (P276) P19 place of birth
Person death (Q4) point in time (P585) 570 time of death User:Tpt location (P276) P20 place of death has cause (P828), has immediate cause (P1478) P509 cause of death, P1196 manner of death
Person burial (Q331055) point in time (P585) location (P276) P119 place of burial
foundation or creation point in time (P585) 571 time of foundation or creation User:John F. Lewis location (P276) P740 formation location/ place of foundation
Biology taxon name publication point in time (P585) 574 time of taxon name publication User:John F. Lewis
discovery (Q753297) point in time (P585) 575 time of discovery User:John F. Lewis
  • P65
  • P189
  • site of astronomical discovery
  • discovery place
dissolution (Q18603731) point in time (P585) 576 time of dissolution User:Delusion23
publication point in time (P585) 577 time of publication User:Snipre P291 place of publication
Aircraft maiden flight (Q1362364) point in time (P585) 606 time of first flight User:Joshbaumgartner start location? end location?
Spacecraft space launch (Q7572593) point in time (P585) 619 time of spacecraft launch User:Ivan A. Krestinin location (P276) P448 launch site
Space craft landing (Q844947) point in time (P585) 620 time of spacecraft landing User:Docu location (P276) P1158 landing site
Spacecraft spacecraft decay (Q18603851) point in time (P585) 621 time of spacecraft decay User:Docu
Spacecraft spacecraft docking/undocking point in time (P585) 622 time of spacecraft docking/undocking User:Docu
service entry point in time (P585) 729 time of service entry User:John F. Lewis
service retirement point in time (P585) 730 time of service retirement User:John F. Lewis
Person disappearance (Q18603733) point in time (P585) 746 time of disappearance User:Nightwish62
retrieval point in time (P585) 813 time of retrieval User:Ajraddatz
first performance point in time (P585) 1191 time of first performance User:Jakec
Person "flourishing" point in time (P585) or start time (P580) and end time (P582) 1317 floruit User:Jakec P937 work location
official opening point in time (P585) 1619 time of official opening User:Tobias1984 P542 officially opened by
Person baptism (Q35856) point in time (P585) 1636 time of baptism User:Ayack
Film filming point in time (P585) or start time (P580) and end time (P582) P915 filming location
Manufactured item assembly/production point in time (P585) or start time (P580) and end time (P582) location (P276) P1071 place made/assembly location, place built manufacturer
journey start location? P1427 journey origin/ starting place of this journey
Company/commune/country change of ownership (Q14903979) point in time (P585) 'from', 'to'
Company/commune/country change of name (Q14904150) point in time (P585) 'from', 'to'
Company/commune/country spin-off (Q15865002) point in time (P585)
Company/commune/country merge (Q17853087) point in time (P585)
Person amputation (Q477415) point in time (P585)
Person funeral (Q201676) point in time (P585) location (P276)
Person drafting P647 drafted by
Creative work première (Q204854)
Building/infrastructure/monument groundbreaking (Q1068633) point in time (P585)
Building/infrastructure/monument cornerstone (Q1133673) point in time (P585)
Building/infrastructure/monument construction (Q385378) start time (P580), end time (P582)
Building/infrastructure/monument topping out (Q1075723) point in time (P585)
Building/infrastructure/monument inauguration (Q1417098) and/or dedication (Q1762010) and/or consecration (Q125375) point in time (P585)
Building/infrastructure/monument opening (Q15051339) point in time (P585)
Building/infrastructure/monument renovation (Q2144402) start time (P580), end time (P582)
Building/infrastructure/monument closure (Q14954904) point in time (P585)
Building/infrastructure/monument demolition (Q331483) point in time (P585)
Building/infrastructure/monument reopening (Q16571590) point in time (P585)
Building/infrastructure/monument relocation (Q2918584) point in time (P585) start location?, end location?
Building/infrastructure/monument destruction (Q17781833) start time (P580), end time (P582) has cause (P828) cause of destruction (P770) this qualifier is important for accidental destruction not for planned demolition.
Car/plane/Computer/item presentation (Q604733) point in time (P585) location (P276)
Car/plane/Computer/item production (Q739302) (see Production or distribution ?) start time (P580), end time (P582) location (P276)
Ship order (Q566889) point in time (P585)
Ship keel laying (Q14592615) point in time (P585)
Ship ship naming and launching (Q596643) point in time (P585)
Ship shipbuilding (Q474200) end time (P582)
Ship ship commissioning (Q14475832) point in time (P585)
Ship destruction (Q17781833) start time (P580), end time (P582) location (P276) has cause (P828) cause of destruction (P770) is important for accidental destruction, not for planned demolition.
Ship ship decommissioning (Q7497952) point in time (P585) location (P276)
Ship retirement (Q946865) point in time (P585) location (P276)
Ship ship disposal (Q7497950) point in time (P585)
Ship scuttling (Q1786766) point in time (P585)
Ship ship breaking (Q336332) start time (P580), end time (P582) location (P276)
Wealth donating P1028 donated by
oathing P543 oath made by
lighting a torch P545 torch lit by
Person nominating for an award P1411 nominated for
Geography claiming a territory P1336 territory claimed by
Something using something P1535 used by
Theory proving P1318 proved by
Person ordination of a bishop/consecration P1598 consecrator
Manufactured item printing P872 printed by
Statement disputing a statement P1310 disputed by
Question solving a question P1136 solved by
Statue ... unveiling P1656 unveiled by
Person education (Q8434) location (P276) 69 educated at P1066 student of

Discussion[edit]

Pictogram voting comment.svg Comment @Andrea Shan: With this system, how would you specify the type of relation between the item and the event ? For instance, a birth is a significant event for both the mother and the newborn. How would I know who is who ? How would I be able to query this information ? Will a query about women born in 1950 also return the list of women that gave birth that year ? --Casper Tinan (talk) 10:13, 5 December 2014 (UTC)

Good point, I hoped there would be a solution and maybe there is: At Q320, a woman, has several significant events with item "childbirth (Q34581)". So the event as seen from the child could use "birth", or an extra item is created for that. Alternatively one could use "role=mother" on the mother page and "role=child" on the child page, then there is also no more need for defining the natural mother in another property. Andrea Shan (talk) 10:40, 5 December 2014 (UTC)
Your first proposal implies having two items to describe a single event. It is strictly impractical. The second one would work provided we are able to query qualifiers, which would not be the case before a long time. Casper Tinan (talk) 12:55, 5 December 2014 (UTC)
Casper Tinan The first proposal is already in use. Mothers don't use "birth". One can use "birth" on the child item and the date would be, when the item is born. If "birth" is used on the mother site, then in her role as a child. Andrea Shan (talk) 13:03, 5 December 2014 (UTC)
@Andrea Shan:I was making the assumption that significant event (P793) would be used to link items to instances of events, as it is suggested in the property's label, rather than to classes of events. With the current practice, you have to enter twice the information (date, location) about the birth and if there is an error, you have to correct the two statements, which are not directly linked. And it is worse with events with more participants such as a rugby union international match, which may be the first international match of some players, the last for some others and the largest victory of the winning team. Casper Tinan (talk) 18:53, 5 December 2014 (UTC)
  • Symbol keep vote.svg Keep: now that we can added statements to properties, the mapping can be added there and the above properties kept.
Besides, qualifiers can't be queried in the near and distant future. Thus the way to go should be make specific properties rather than to attempt to use a single property for everything. --- Jura 11:58, 5 December 2014 (UTC)
You seem to ignore
  • the translation issue
  • that with keeping some event-type-specific properties, and at the same time keeping "significant event" there are two systems, by adopting the proposal there would only be one
  • the maintenance issue, creating an unknown number of event specific properties, each as date and as location.
  • the expressiveness issue and cultural bias issue - normal users cannot create designated properties and if they don't think that something like "significant event" exists, because on many pages the specific properties are used, then they may feel uncomfortable.
If qualifiers "can't be queried" then it would not be possible they are displayed. Maybe you mean via API. Then this should be fixed ASAP. Andrea Shan (talk) 12:14, 5 December 2014 (UTC)
@Andrea Shan: Developer said «Querying for sources or qualifiers not to be done». I don't know the reason (technical feasibility or resource). --ValterVB (talk) 20:15, 5 December 2014 (UTC)
For the other points mentioned by Andrea, it seems that I might as well ignore them as they can apply also to the solution proposed by Andrea. An exception might be a "Translation issue", as I don't understand what that may be in this context. --- Jura 07:37, 6 December 2014 (UTC)
@ValterVB. Qualifies can be queried in the current API: we can use the qualifiers to filter data. So for the step 2 of wikidata developement, for the infoboxes or text query, there is no problem. The problem of the development is to define a tool for the query of lists. So if it is possible to query for one person its birth date stored with significant event (P793), it is not forseen to do the same to extract a list of all persons born in 1980 for example. There is no technical difficulty but only a two steps process to develop because filtering with qualifiers implies first to get a list of items corresponding to a certain parameter (all person item with a birth date value) and then to filter again that list with a second parameter (all person item with a birth date equals to 1980). Snipre (talk) 11:53, 6 December 2014 (UTC)
Of course, I was referring to the creation of lists. For single item no problem, we already use on it.wiki with Lua. Sorry for misunderstanding and thanks for the explanation --ValterVB (talk) 12:49, 6 December 2014 (UTC)
Pictogram voting comment.svg Comment We can't add source to qualifier. So if I have a source for "date of birth" and a different source for "place of birth", how we can manage? Another example is "start date" and "end date" for "marriage". --ValterVB (talk) 08:48, 14 December 2014 (UTC)
That means all statements in qualifiers are without source? Could that be a severe shortcoming of the software? One could create two claims for birth, the first with a date and the related sources, the second with the place and the related sources. Currently if there are differing claims for time (T1, T2) and location (L1, L2) the claims are spread and hard to connect. Maybe in reality all sources either claim T1+L2 or T2+L1 are correct. Either he died at 9:05 in the entrance of the building or 9:15 in his room. Aren't there also different kinds of death, clinical death (clinical death (Q1989450)), brain death (brain death (Q223867)), legal death? So, would one create date of clinical death, date of brain death, date of legal death and location of clinical death, location of brain death, location of legal death? And another set for "cause" ... cause of clinical death, cause of ... It seems specialized time of/date of properties simply don't scale. Frank Robertson (talk) 12:10, 14 December 2014 (UTC)
Wikidata statement.svg
Yes, you can add source to the claim but you can't add source to the qualifier. I don't think is possible to change. @Lydia Pintscher (WMDE): --ValterVB (talk) 15:20, 14 December 2014 (UTC)

P19 and P20 on Einstein page with claims about location of the location:

91.9.127.22 15:57, 22 December 2014 (UTC)

@ValterVB, Jura1, Andrea Shan: The new query tool integrates qualifiers in the search. See the documentation here. This is available in the last weekly summary. Snipre (talk) 17:00, 22 December 2014 (UTC)
This isn't for the same functions. --- Jura 18:32, 23 December 2014 (UTC)
Jura Sorry I don't understand your remark: we don't need the same function, who was asking that ? The only question is can we query value using qualifiers and the answer is yes. We don't have the same functions for time or coordinates values and this is not a problem.. Snipre (talk) 13:34, 25 December 2014 (UTC)
Symbol keep vote.svg Keep I can change my opinion when we will can add source to qualifiers. --ValterVB (talk) 19:34, 23 December 2014 (UTC)
ValterVB You don't need to be able to add sources to qualifiers: you can add several statements for the same event like birth with each time a different qualifier and the corresponding source. Snipre (talk) 13:28, 25 December 2014 (UTC)
ValterVB By the way how can you describe several marriages with the current system (2 marriages with two different persons at different dates and different locations) ? Only the qualifiers system can solve this problem. Snipre (talk) 13:28, 25 December 2014 (UTC)
@Snipre: Like in Elizabeth Taylor (Q34851). See at spouse (P26) I can add a source for every spouse. --ValterVB (talk) 17:11, 25 December 2014 (UTC)
@ValterVB: So why can't you do the same with significant event property ? The spouse property is similar to significant event and use qualifiers to provide more information and sources. And how do you specifiy the marriage locations for all these marriages ? Snipre (talk) 20:40, 25 December 2014 (UTC)
Pictogram voting comment.svg Comment In that radical generality of the proposal Wikidata does need almost no properties at all: Just one for each datatype and compounds of it (like (time interval X place one X place two) for "events"), anything else is dealt with by qualifiers derived from Q-items. Also part of the discussion here is about the feasibility (and desirability) of a dedicated event data type: It would keep places and dates closer together for the price of loosing the ability to hold qualifiers for the "atomic" constituents (like source statements). For many existing properties then it is open to discussion whether they are two singular events involved at the start rsp. end of an interval (like birth/death, vernissage/finissage) or rather one event (life, exhibition): Seems to depend on the point of view but for the sake of the data model one should stick to one of the possibilities... -- Gymel (talk) 10:09, 24 December 2014 (UTC)
Gymel you don't understand the problem of the event items: event can be defined by time, location, persons, actions,... All these characteristics have to be linked together. So if this can be done by the event name like for birth which occurs only once, in case of marriage this system can't work. You can have different marriages with different marriage locations. Only statements with qualifiers can handle these cases so we have to focus on this system. Then can we work with two systems one using qualifiers and the second using several properties ? No so best is to work with only the qualfier system. Snipre (talk) 13:28, 25 December 2014 (UTC)
Sure I see the limits of single, unqualified properties for non-unique events. However it is the question whether a "married-to" property qualified by a point of time (or an interval) and whatever one deems important (location, ...) is more desirable or an "significant event" property qualified by a generic "type of event" with Q-item "marriage": The proposal taken to the extreme ends up with a version of wikidata with very few generic properties in alignment with datatypes plus a handful generic properties for use as qualifiers and the "semantic flesh" is shifted from properties to q-items as objects of generic properties. This definitely would be even more flexible but I think very different from the original design of wikidata. -- Gymel (talk) 19:31, 25 December 2014 (UTC)
Gymel It is not a question of small amount of properties or big amount of properties. It is a question of structuring data which are together using a way to connect them together. If you create two single properties for birth date and birth location, how do you connect these two properties which are elements of the same event ? You will have to specify somewhere in your system that these two properties are related. The problem is the connection bewteen data related to the same topic. And the only way to solve this is the qualifier system. It is not a choice, this is currently the only way to link data about the same event. And if the case of the birth or the death is simple, the case of the marriage shows the limits of the all properties system: if a event can occur several times you have to multiply the properties. Just a pratical example: one person is getting married 2 times, one event occuring several times. I don't want to discuss about what should be wikidata or was the original design of wikidata. I just want from you your explanations about how to model these data:
  • Q item: John Doe
  • statement 1: marriage with Calamity Janes in Paris the 2. February 2004. Divorced the 23. March 2007
  • statement 2: marriage with Mini Mouse in London the 15. June 2009.
Snipre (talk) 20:21, 25 December 2014 (UTC)
There are many possibilities and I do not have a preference there:
  1. a marriage-as-punctual-event property with the spouse as value and qualifiers for date and place plus an annotation for the "corresponding" divorce
  2. a marriage-as-period-of-time property with a time interval and corresponding points in space for the temporal endpoints and a qualifier for the type of termination
  3. the foregoing marriage properties qualified by values of a compound point-in-space-time or path-in-space-time datatype (taking values of eg. (London; 15. June 2009) or ((Paris; 2. February 2004) .. (unknown; 23. March 2007))
  4. a generic "significant-event" property with one or several properties as above for the corresponding space-time coordinates and a qualifier for "marriage" as the type of event. In natural language this would correspond to reducing the number of verbs in favor of adverbial or passivic constructions (attributes of bureaucratic language)
  5. similar to exhibitions as "institutionalized events" a q-item for any single marriage carrying "ordinary" properties for start and end points, locations and the persons involved (this may be the only solution which can be extended to polyamourous group marriages?). This is not as absurd a construction as it might first seem, cf. en:Presidency of Bill Clinton, an "event" which coupled the person Bill Clinton and the U.S. Government or the United States for a certain interval in time. We might borrow the notion of "reification" for this approach.
I still think we are dealing with two rather distinct questions here: How to cope with non-atomic data types (like the coupling of place and date with the additional difficulty of recording individual sources or annotations for each of the atoms) and about specific properties vs. very generic ones "typed" by q-items (you can express anything you want without introducing new properties but successful querying might more than before depend on rigorous and exhaustive subclass-relations on the space of q-items). -- Gymel (talk) 22:11, 25 December 2014 (UTC)

Datatype change: religious name (P1635)[edit]

(delete | history | links | logs | discussion)

Please refer to property proposal (btw why can't I find it anywhere in archives?). I believe that according to the discussion the datatype should be Multilingual text instead of Monolingual text..--DixonD (talk) 19:51, 11 December 2014 (UTC)

  • the datatype you suggest isn't available. --- Jura 20:01, 11 December 2014 (UTC)
  • I suggest add message "Warning: This property will be deleted then multilingual datatype appears. Be ready to switch your algorithms to new property." to the property talk page and keep the property for now. Conversion multiple monolingual values to one multilingual is looked simple. — Ivan A. Krestinin (talk) 20:48, 11 December 2014 (UTC)

influence of (P738)[edit]

(delete | history | links | logs) This property is a clear reversed duplicate of influenced by (P737) (and is actually stated to be so). Besides it is impossible to manage in a good number of cases: while a person can only be influenced by a limited number of people during his/her whole lifetime, the reverse is not true, and some influential thinkers can have a wide number of followers. Listing all the items influenced by Plato (Q859) or Jesus Christ (Q302) is going to be a major headache. Alexander Doria (talk) 17:16, 12 December 2014 (UTC)

  • Symbol keep vote.svg Lean keep. Alexander, what you label a "reversed duplicate" is typically called an "inverse". These are often useful and widespread on the Semantic Web. I wouldn't lead an argument for deletion with that rationale.
Your point about the huge number of potential claims that could be made with this property is worth considering, though. Adding each philosopher influenced by Plato to Plato (Q859) via influence of would clearly be a bad idea. However, I think looking at Plato's infobox in various Wikipedias indicates a possible solution to that problem:
Influenced by: Socrates, Homer, Hesiod, Aristophanes, Aesop, Protagoras, Parmenides, Pythagoras, Heraclitus, Orphism
Influence of: Most of Western philosophy (Q842333) that came after his works
Influenced by: Pre-Socratic philosophy, Socrates, Greco-Roman mysteries, Orphism
Influence of: Much of Western philosophy; part of Islamic philosophy (Q193104)
Influenced by: Socrates, Archytas, Democritus, Parmenides, Pythagoras, Heraclitus
Influence of: Aristotle, almost all European and Middle Eastern philosophers
In other words, for very influential things, simply have the value of influence of be a movement of which their influencees were a part. Then if we want to do inference down the road, we could look up or deduce the influencee's movement (P135) (or what have you), and infer that the influencer satisfies a large number of more specific influence of claims. Emw (talk) 01:15, 13 December 2014 (UTC)
I really don't see the need for an inverse (and I have already seen several successful PfD done on this ground). The WikidataQuery API already allows to do the exact same thing using influenced by (P737) : you can retrieve all the philosophers that claims to be influenced by Plato. We are merely doing the same work twice.
And I'm unconvinced by your solution: Most of Western philosophy is quite fuzzy. There are actually numerous influential western philosophical movements that do not claim an influence from Plato (Epicureanism, Cartenianism, Positivism…). It's really more suitable to only use influenced by (P737) and get all the results in a reverse way.
Alexander Doria (talk) 11:49, 13 December 2014 (UTC)
Wikipedia cannot use Wikidataquery to display info. Note that some widely used infoboxes like en:Template:Infobox scientist contain "influenced" fields. fr:Module:Infobox/Philopsophe makes use of this property as a default, though so far with no hits (fr:Catégorie:Page utilisant des données de Wikidata/P738).
When an item is not a "big influencer" (say, is p737 value in less than 10 items), a bot should update it automatically. When there are many potential values, I am not too sure what to do.--Zolo (talk) 13:09, 13 December 2014 (UTC)

located in place (P1134)[edit]

Since property 'event location' P766 has been merged last week with location (P276), and its definition is getting to a more generic 'location' property, I think P1134 can now also be merged into P276. So the new definition of P276 wil then change from: location the object or event is within to location the object, event or item is within. Michiel1972 (talk) 09:55, 13 December 2014 (UTC)

Royal Swedish treasury (Q9337727) uses all four location properties (located in the administrative territorial entity (P131), located on terrain feature (P706), located in place (P1134) and location (P276)). Please tell me which one is redundant. /ℇsquilo 17:23, 14 December 2014 (UTC)
All beside location (P276). The other can be obtained from where Stockholm Palace (Q750444) is located. Frank Robertson (talk) 21:52, 14 December 2014 (UTC)
So can country (P17), but is it a usable data-model where most properties has to be obtained through two, three or four levels of inheritance? As long as there is no implicit inheritance-statements in Wikidata, I'd say no, it is not. /ℇsquilo 07:03, 15 December 2014 (UTC)
No, P17 reads "sovereign state of this item", it is not limited to location. 91.9.120.70 18:35, 16 December 2014 (UTC)
"figure them out from the item that location (P276) points at" - yes please. 91.9.121.131 01:43, 21 December 2014 (UTC)
Pictogram voting comment.svg Comment ... but I can see editors choosing <painting> 'location:Dutch masters gallery' which is 'part of:national gallery' (and allows a transitive relationship between a museum and its galleries). So a pure location walk up the tree wouldn't work - queries would need to consider both location and part relationships. - PKM (talk) 20:00, 23 December 2014 (UTC)

merge narrative set in (P840) and filming location (P915)[edit]


date of baptism (P1636)[edit]

(delete | history | links | logs | discussion)

Since July [5] the event "baptism" has been listed as using significant event (P793). Note: I could not find a property proposal for date of baptism (P1636). --Frank Robertson (talk) 16:31, 13 December 2014 (UTC)

  • Just convert those to P1636. The preference is to use specific properties rather than one property with thousands of qualifiers. --- Jura 08:53, 14 December 2014 (UTC)
    Thousands of qualifiers? For "dates of " one only needs point in time (P585) and this exists already. So instead of date of baptism, date of burial, date of funeral, date of marriage, date of care incident, date of assault, date of dating, date of retirement (there are many more subclasses of "event"), one uses significant event (P793) and point in time (P585). What further qualifiers do you think of? Frank Robertson (talk) 11:43, 14 December 2014 (UTC)
    @Jura1: Could you please give a link to the RFC where this was discussed ? Casper Tinan (talk) 21:44, 14 December 2014 (UTC)
    No idea, but the result on the development plan is that «Querying for sources or qualifiers not to be done». --- Jura 06:26, 15 December 2014 (UTC)
  • Pictogram voting comment.svg Comment At Wikidata:Property proposal/Archive/12#P793 User:Filceolaire said:
    " 'More direct' time (and location) properties means a special time (and location) property for every type of event. Hundreds of them. With users having to try and find the right one. This is not better."
    User:Zolo and User:Tobias1984 supported the creation. Then suddenly a dedicated property P1636 is created, but this does not allow to store the location. One would need an extra one for this. And then, maybe one wants baptizer. So, one has three new properties. And the information related to one event is spread between several properties. Frank Robertson (talk) 21:30, 14 December 2014 (UTC)
  • @Ayack: Ayack, you created the property. Do you know where the proposal is? - About this deletion request: The two end-members of this discussion are either "one property for all events with qualifiers being used to further describe the events" and "specific properties for any possible event with qualifiers only used for clarifications". In any case I don't think we should take the appearance in the Wikidata-interface into consideration. Wikidata is somewhat of a hybrid between a data-entry form and a data-view. The data is going to be "unübersichtlich" (is unoverviewability a English word?) in either case and special database-view might need to be developed for domain-specific knowledge. (The secret behind "big data" is probably filtering 99.99 % of the information you don't want to see).

To sum this up: We should probably have an RfC about this soon. The question is, if we should enforce one end-member solution or decide for each new property. I personally have started to lean more towards creating more properties. It will be unoverviewable in any case. We need good filtering to solve this. --Tobias1984 (talk) 22:27, 14 December 2014 (UTC)

Tobias1984 See [6]. — Ayack (talk) 07:40, 15 December 2014 (UTC)
1)There is no filtering. The UI is as it is. Apart from UI problems: there can be several weddings and divorces, then one has to connect time/location/partner properties for each - how is this done? At Agnes Bulmer (Q16147344) I wanted to add the baptizer, but I found no generic "event/action carried out by". Now, it there is time of baptism and in future location of baptism, then one also needs baptizer. It doesn't scale. Frank Robertson (talk) 22:49, 14 December 2014 (UTC)
2) "specific properties for any possible event with qualifiers only used for clarifications" - There are ~8000 subclasses of event (Q1190554) [7]. If one needs on average two properties, that would be 16 000. Good luck. Frank Robertson (talk) 22:56, 14 December 2014 (UTC)
@Frank Robertson: Actually it does scale. We already have more than 1600 properties so 16000 is just one order of magnitude more. Increasing this number should not influence our decision, in my opinion. - In any case it might be a good idea to do a thorough review of all the event properties. Do you have time to set up an RfC about this? --Tobias1984 (talk) 07:26, 15 December 2014 (UTC)
@Tobias1984: 1329 at Wikidata:Database reports/List of properties/all, and six of these marked for deletion. Almost 600 of these are of type=string, AFAICS not much else than identifiers. That is ~700 left. From these, only some come as pairs or groups, like the "time of"/"location of" pairs. Where is "location of baptism"? The implementers of "time of baptism" broke storing the location in an obvious property. 91.9.120.70 18:30, 16 December 2014 (UTC)
Once we have property-type statements enabled, we will be able to set up subproperty-trees, so that will scale better than it currently does. But still maintaining this tree will add some work.
Beside, as Filceoalaire noted, in addition to the "date of X" tree, we will need a "place of X" tree, and possibly others.
Putting "date of X" and "place of X" in separate statements makes more sense when they come from different source, but still that is a bit unwieldy to work with.
Another benefit of significant event (P793) is that we can have a start date + an end date qualifier. (Admittedly that's off topic in a discussion about baptism, and hopefully, we will be able to do the same thing in the future in a single snak)
I find significant event (P793) convenient to use in infoboxe, or in scripts like Module:Timeline. --Zolo (talk) 18:32, 15 December 2014 (UTC)
1) Regarding location tree: Keep in mind that location itself comes in different forms: "located in the administrative territorial entity (P131)", "located on terrain feature (P706)", "located in place (P1134)" and "location (P276)". So maybe some people then will like to have "baptism located in the administrative territorial entity", "baptism located on terrain feature", "baptism located in place". From physics, I think, time and location is sufficient.
2) Regarding start and end date in one snak: Look at ISO 8601, it allows to have one string containing both. 91.9.120.70 18:41, 16 December 2014 (UTC)
Symbol delete vote.svg Delete. If someone is baptised twice then using this property as a first rank property won't tell us which date applies to which baptism. Using 'point in time' as a qualifier we do not have this problem. Getting baptised twice may be unusual but getting married twice is not. A politician is often elected to various positions over their career. Each of these positions use the position held (P39) property with qualifiers for start date, end date, preceded by, succeeded by, electoral district. Creating special properties won't help here as these qualifiers each apply to a particular statement. The only way round this is for us to have a separate Qitem for each of these events (rather than including them in the Qitem for the person). This will not (in my opinion) be an improvement. Qualifiers are useful and we should take advantage of them. Filceolaire (talk) 23:46, 17 December 2014 (UTC)
Symbol keep vote.svg Keep IIRC the intention to introduce a date of baptism property was to be able to record an analogy for date of birth (P569) in cases like Ludwig van Beethoven (Q255) where the date of birth is not known however it is an established fact that in that time baptism a) was already recorded and b) took place within a couple of days after birth. Thus the baptism property was not intended to record another "significant event" (taking up some denomination) in live but rather as an insignificant deviation from but usually quite good approximation to the unknown date of birth (and therefore denomination and place / church of baptism are not relevant in this respect). Of course, when place of birth (P19) and date of birth (P569) will be contracted to some complex "significant-event"-property, the baptism property/ies could change alike. -- Gymel (talk) 00:17, 18 December 2014 (UTC)
Pictogram voting comment.svg CommentBaptism can occur at any time after birth and there can be several occurrences - or none. While for humans there is a 1:1 relation with respect to birth. The property is not labeled
  • "date of baptism with the intention to be able to record an analogy" or
  • "date of baptism in cases like Ludwig van Beethoven"
  • "date of baptism in the Xth to Yth century"
but is labeled "date of baptism". And what is complex about the "significant-event"-property is probably a secret of User:Gymel. Does Gymel find it less complex splitting properties of one event between different statements in a way that doesn't allow the data consumer to know which belong together? Complexity reduced that much, that functionality was lost.... 91.9.121.131 01:37, 21 December 2014 (UTC)
Pictogram voting comment.svg Comment One problem with giving dates as qualifiers is that you can't then specify qualifiers on those dates (because you can't have a qualifier on a qualifier). So, for example, you can't mark a date of such an event as "circa" using sourcing circumstances (P1480) circa (Q5727902), or other similar such qualifiers. Jheald (talk) 22:50, 27 December 2014 (UTC)

Nova Scotia Register of Historic Places identifier (P909)[edit]

(delete | history | links | logs | discussion)

The Internet register of historic place of the province aparently disapear last year [8]. The site of the Heritage Property link now only to the Canadian Register of Historic Places[9] (Canadian Register of Historic Places identifier (P477))..--Fralambert (talk) 04:39, 27 December 2014 (UTC)