Page semi-protected from being moved
Shortcut: WD:PFD

Wikidata:Properties for deletion

From Wikidata
Jump to: navigation, search

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.



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

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)

Symbol keep vote.svg Keep I'll add more --Adert (talk) 19:07, 16 June 2015 (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)
  • Symbol keep vote.svg Keep: If we were to get rid of this, then we would have to get rid of Parent or Child, as these can also be considered inverse properties. Staple of data in my mind. Hazmat2 (talk) 15:32, 27 April 2015 (UTC)
    And we should (get rid of child in this case). That parent has been allowed to survive is... a problem. :) --Izno (talk) 21:44, 1 May 2015 (UTC)
    • You made my day. Hazmat2 (talk) 03:19, 2 May 2015 (UTC)
  • Delete. This is clearly a property that should be deleted because of problems regarding citeability and scope. And to be honest, it's not important to the person who is doing the influencing; only the person who is influenced. --Izno (talk) 21:44, 1 May 2015 (UTC)
    • I agree. Symbol delete vote.svg Delete. --Yair rand (talk) 20:36, 21 July 2015 (UTC)
  • Symbol delete vote.svg Delete Use only influenced by (P737). --- Jura 05:54, 22 July 2015 (UTC)
  • Symbol delete vote.svg Delete. I agree with the concern above that the influenced people may not be important to the influencer. For cases where the relationship is important, we already have doctoral student (P185), student (P802), and similar. Deryck Chan (talk) 13:33, 22 July 2015 (UTC)
  • Symbol delete vote.svg Delete I agree this belongs to the influencee, and it's redundant. author  TomT0m / talk page 13:36, 22 July 2015 (UTC)
  • Symbol delete vote.svg Delete Per Alexander Doria. Casper Tinan (talk) 15:39, 22 July 2015 (UTC)
  • Symbol delete vote.svg Delete Just used this in Henrik Ibsen and was wondering why I had to use it as it is clearly asymmetrical and unbounded property. I go with Iznos argument, this is a delete. Jeblad (talk) 17:36, 27 July 2015 (UTC)
  • Pictogram voting comment.svg Comment (updating my comment above) this property is used in the frwiki version of Template:Infobox artist (Q5914426) where it matches a prewikidata parameter. It is currently used in 6 pages. --Zolo (talk) 18:05, 27 July 2015 (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 [1]. The site of the Heritage Property link now only to the Canadian Register of Historic Places[2] (Canadian Register of Historic Places identifier (P477))..--Fralambert (talk) 04:39, 27 December 2014 (UTC)

Symbol keep vote.svg Keep that something disappears is not a reason to delete it from Wikidata. E.g. there is Julius Caesar (Q1048). WK7489 (talk) 12:40, 28 December 2014 (UTC)
Symbol delete vote.svg Delete, better to delete disappeared databases because they are not useful but misleading. --Stryn (talk) 12:55, 28 December 2014 (UTC)
  • Pictogram voting comment.svg Comment personally I'd tend to keep it, but it seems only rarely used and its proposer thinks it should be deleted. --- Jura 17:22, 9 January 2015 (UTC)
  • Pictogram voting comment.svg Comment I think it could be deleted but only if we know for sure that t won't reappear. WK7489 misses the point we don't delete what disappeared but the references to it(like you would throw away a note which says "ask Julius Caesar (Q1048)".--Saehrimnir (talk) 06:26, 22 April 2015 (UTC)

language of work (or name) (P407)[edit]

(delete | history | links | logs | discussion)

By using the FRBR system we don't need anymore two properties to describe language of a work: one language propery is enough per item in case of work and translated edition. The original language of the work can be retrieved from the language property of the work item for every translated edition. This implies for sure the possibility to access to several items from one WP article, but as this feature is in development we can already prepare the merge of these two properties. Snipre (talk) 22:48, 8 January 2015 (UTC)
Complementary information: The proposed action is to merge original language of work (P364) and language of work (or name) (P407) in one property "Language" which can be used for all cases where an item or a statement has to be defined according to its language. This can be for work, but for name or other kind of items. Snipre (talk) 16:04, 26 May 2015 (UTC)

I see there is a lot of good arguments, but the two properties can´t be merged easily. In cases where p 364 is uses as it should be, it must be deleted and secured that p 364 is added to the corresponding work item. In many (thousands) of other cases p364 is used not the way as it is intended instead of p407. So p364 is messed up much more than p 407. I find the concept of p407 is easier to understand, so I suggest to change the RFD round to delete p364 instead, no matter how often the property is used. Once it is done properly, a bot can change the number within hours.--Giftzwerg 88 (talk) 18:42, 18 January 2015 (UTC)
  • I suppose that language of work (or name) (P407) is used also for other types of entities, for example, in names. Which is not easily convertible to original language of work (P364). --Infovarius (talk) 14:03, 20 February 2015 (UTC)
  • I have used language of work (or name) (P407) a lot on WikiNews items. Several of them had multiple languages attached. I would therefor keep it. Edoderoo (talk) 22:19, 22 March 2015 (UTC)
    @Infovarius: What is the problem if we merge both properties into "language" ?Snipre (talk) 13:05, 23 March 2015 (UTC)
    @Edoderoo: Can you provide an example please ? And if the new property is called "language", is it still a problem ? Snipre (talk) 13:05, 23 March 2015 (UTC)
    @Edoderoo: How can you use a language property for a wikinews article ? As I see there is a French corresponding article so why English and not French ? Snipre (talk) 16:26, 27 March 2015 (UTC)
    Because English *and* French. I'm Dutch, so for me the English and the French go perfectly together on the same property without any issue ;-) Edoderoo (talk) 22:07, 27 March 2015 (UTC)
    A wikinews can be in language "A" about some public speech which was performed in another language "B". I suppose we can point both languages with different properties (language of work (or name) (P407) for A, original language of work (P364) for B). --Infovarius (talk) 08:36, 2 April 2015 (UTC)
    @Edoderoo, Infovarius: You mix different concept: the language of the wikinews and the language of the object of the wikinews article. For the first language, this is redundant with the sitelink information. If you want a French article you filter the sitelinks and select the ones which are in French. The example you gave was an typical example of the problem of redundancy: the language properties were not updated according to the sitelinks. And this organization is not applied in the others items: the language property is never used to describe the language of the WPs connected to the item. Look at apple (Q89): 153 sitelinks and around the same number of different languages. But no use of language of work (or name) (P407) or original language of work (P364). So why do we have to have another practice for wikinews articles ?
    Then about the language of the object of the article. Here we have a problem of definition: Is the item about the wikinews article or about the object of the article ? The classification of the item is clear in your example: instance of Wikinews article. So the language of the object in not part of this item. You should use Israeli legislative election, 2015 (Q17012412) to define the language of the object of the article, and how can an election have a language property ? Here we have a confusion based on the relation "the election is in Israel", "Hebrew is speaking in Israel" so "language of election is Hebrew". Snipre (talk) 14:31, 7 April 2015 (UTC)
  • @Snipre: Which "language property of the work item" are you referring to? As far as I can tell, it's possible to create an item without any language property except for language of work (or name) (P407) unless someone uses title (P1476) and signifies the language. There are occasionally works that have titles in more than one language, despite the text only being in one, so going by the title language doesn't make sense to me. The way the descriptions are written, I've always used original language of work (P364) as the language of the first edition, not necessarily the current translation. To me, that's been language of work (or name) (P407). Hazmat2 (talk) 15:42, 27 April 2015 (UTC)
    The idea is to have one language property called "Language" and to use this property for work AND editions items. The use of the merged property "Language" can be used to retrieve all works in a defined language as well to define the language of the editions in the original language or the language of the translated editions. No need any more of a original language property for work and another property for the editions items. We can't use the language of the title because the language of the title can be different from the language of the work/edition. --Snipre (talk) 16:05, 10 May 2015 (UTC)
  • Understood. Thank you, Hazmat2 (talk) 20:21, 26 May 2015 (UTC)
The proposed action is to merge original language of work (P364) and language of work (or name) (P407) in one property "Language" which can be used for all cases where an item or a statement has to be defined according to its language. This can be for work, but for name or other kind of items.
Please provide your support or opposition to this request in order to progress to a decision. If you are not convinced better vote {{oppose}} but this wiil help at least to close the discussion. Thank you. Snipre (talk) 16:18, 26 May 2015 (UTC)
  • If original language of work (P364) and language of work (or name) (P407) will be merged, then how to handle in a case when the original text is unknown, but we know the original language? -- Sergey kudryavtsev (talk) 10:02, 27 May 2015 (UTC)
    @Sergey kudryavtsev: Please provide an example. I don't understand the problem. Snipre (talk) 10:44, 27 May 2015 (UTC)
    The example: s:ru:Я целый день изнемогаю (Гейне/Фет) — we know the translator — Afanasy Fet (Q314212), the author — Heinrich Heine (Q44403) and the original language — German (Q188), but we don't known the original text. -- Sergey kudryavtsev (talk) 11:30, 27 May 2015 (UTC)
    @Snipre: What you say about this example? -- Sergey kudryavtsev (talk) 03:55, 4 June 2015 (UTC)
    @Sergey kudryavtsev: The rule is for translation to have a different item. So in your case you should create an item for the original text and a second one for the translation. We don't care about the original text because we use concept in WD. So in the item of the original text we use "language": german and in the second "language": russian. Snipre (talk) 08:07, 4 June 2015 (UTC)
    The way, which you recommend, is very unnatural. In fact you suggest to describe in wikidata the hypothetical, irreal things. -- Sergey kudryavtsev (talk) 10:28, 4 June 2015 (UTC)
    Does your original exist or not ? If you have proof that a translation was made (like a reference) so you can't say that the text was hypothetical or non real. In summary if you have enough sources to say that the author was Heinrich Heine (Q44403) and that the original language was German to put that information (all information should normally have sources in WD) in the item of the translated text, you have enough proofs to be able to create an item for the original text. Snipre (talk) 20:29, 4 June 2015 (UTC)
    Does your original exist or not ? — we don't know this until the original will be found. The text in the books has a subttle "From Heine", but not say which exactly. The subtitle may be true or false — we don't know. E.g. this poem by Dmitry Minaev (Q4293952) has a subttle "Изъ T. Мура." ("From T. Moore" in English). In fact this isn't a translation from Thomas Moore (Q315346), but the original poem! Minaev put this subttle to easyly pass the censura barriers in the Russia:
    В русской переводческой практике 60-х годов случаи публикации "переводов" без оригиналов были нередкими и даже до известной стег пени оправданными: оригинальное стихотворение с вольнолюбивым содержанием легче прорывалось в печать сквозь цензурные рогатки, если оно объявлялось переводом какого-либо известного иностранного автора; именем чужеземного поэта прикрывались также первые робкие попытки начинающих литераторов, пытавшихся ускользнуть от критических упреков, всегда звучавших строже по отношению к еще безвестным в литературе новичкам. Имя Мура в этом смысле также служило порой щитом для неофитов: известны, например, стихотворения Д. Д. Минаева, выдававшиеся за переводы из Мура, но в действительности ими не являвшиеся.
    431 Таково, например, стих. Д. Д. Минаева "Просьба", в качестве перевода из Мура вошедшее в хрестоматию Н. В. Гербеля "Английские поэты в биографиях и образцах", с. 250:
    Не молись за меня!-- может быть, это грех,
    Но в мольбу я не верю, не верю судьбе!
    Помолись, моя милая, лучше за тех,
    Кто еще не измучен в борьбе...
    Оно впервые напечатано в качестве оригинального стихотворения без всякого указания на Мура в кн.: Д. Д. Минаев. На перепутьи. Новые стихотворения. СПб., 1871, с. label (Q4061691), Мур и русские поэты 40--50-х годов: А. Фет, И. Крешев и др.-- Отзвуки популярности Мура в русской литературе второй половины XIX века.
    The article above is written by a expert in literature, not dilettante. In this case we believe the expert (see this poem in ru-ws). -- Sergey kudryavtsev (talk) 11:43, 5 June 2015 (UTC)
    Sorry I wasn't accurate when I was asking if the original text. WD like WP don't need to have a proof of existence to create an item or an article, they just need to have a document with some authority saying that was true (or not) and then you create your item based on that source and you cite the source in the different statements.
    If you have a document X saying that text Y is a translation of text Z and that the original language was OL with the author AA and the translation was done by TT in language TL, you can create three items:
    • item about document X
    • item about text Z
      • author: AA, source: item about document X
      • language: OL, source: item about document X
    • item about text Y
      • translation of : item about text Y
      • translator: TT, source: item about document X
      • language: TL, source: item about document X
    Snipre (talk) 16:23, 7 June 2015 (UTC)
    You have a mistake: Y and Z is muddled. ;-) But this is not impotant in a case of unknown original text (s:ru:Я целый день изнемогаю (Гейне/Фет)). -- Sergey kudryavtsev (talk) 17:59, 7 June 2015 (UTC)
    Thanks. Snipre (talk) 11:40, 10 June 2015 (UTC)
  • Symbol oppose vote.svg Oppose There can be situations when 1 property can be not enough. I can not find convincing example, but here is another one. A film (for example, animated) can be in language A originally (original language of work (P364)), but voice actor (P725) can provide different backgroud languages (so language of work (or name) (P407) can be used as qualifier for them). --Infovarius (talk) 10:21, 27 May 2015 (UTC)
    Already treated: in the data structure of WD your scenario is described by two items: one for the original movie with the main voices and then a second item for the second language with another set of voices. You can't mix now all voices for different languages in one item. The only open question is about subtitled versions. But you can perhaps show the problem using this item Shrek the Third (Q486588). Snipre (talk) 10:35, 27 May 2015 (UTC)
  • Symbol keep vote.svg Keep the both properties. Instead of deleting, we should impose the rule about language of work (or name) (P407) and original language of work (P364): either only language of work (or name) (P407) (for the original works) or both (for the translated/dubbed works). -- Sergey kudryavtsev (talk) 10:28, 4 June 2015 (UTC)
  • Symbol delete vote.svg Delete Merge the two properties. Per Snipre. --Casper Tinan (talk) 11:43, 4 June 2015 (UTC)
  • Symbol delete vote.svg Delete. Merge the two properties. Name the merged property "Language of Work". Create a new property named "Language" for names and other things that aren't creative works. Filceolaire (talk) 20:56, 18 June 2015 (UTC)
  • Symbol keep vote.svg Keep both properties. It's easier to have a separate property than a property plus a qualifier for the main use case. --- Jura 17:10, 26 June 2015 (UTC)
    @Jura1: Sorry but I don't see where you find the mention of a qualifier: we don't need a qualifier because according to the general structure for works in WD you create different items for the different versions of a work. And when you need the language of the original version you use the data of the item of the work and not the items of the versions. Snipre (talk) 12:36, 1 July 2015 (UTC)
    I don't see people creating items for each synchronized version of a film. Original language is sufficient as a property for these (P364). Add additional languages with the other property if you must. It would be a horrible mess if we would create multiple items for the same film or tv series. --- Jura 12:42, 1 July 2015 (UTC)
    @Jura1: You don't see people creating items for synchronized versions because they aren't trained to do it. But now the question it to now for which purpose you want to add language of work (or name) (P407) in an item of a movie ? Just to say that a movie exists in a certain language ? What's about the publication or release date of the synchronized versions ? What's about the name of the voices in the translated versions ? Just think about anime movies where for each language and for each character you have a different person. "It would be a horrible mess if we would create multiple items for the same film or tv series." That's what we are doing for books and this was never a problem. Snipre (talk) 15:29, 15 July 2015 (UTC)
  • Symbol delete vote.svg Delete Merge the two properties. - The use of the 2 different properties is a mess while treating articles in periodicals. One Language property is enough. --Hsarrazin (talk) 12:17, 1 July 2015 (UTC)
    • Just add P364 and you are fine. --- Jura 12:42, 1 July 2015 (UTC)
  • A book can be a translation in a specific language from a specific original language. If we remove the original language, then we must always have an item for the original work. We get away with one less property, but must add a whole bunch of new items for the works themselves. But then, translations should be a directed graph… The language is a property of the original work, and the translation is done from a previous work and into a new one, implying the new work should have its own language likewise the old work. Will there always be an item for the old work? If not then we need an original language. Jeblad (talk) 22:39, 29 July 2015 (UTC)

station number (P1655)[edit]

(delete | history | links | logs | discussion)

Duplicate of station code (P296).-- 22:44, 9 January 2015 (UTC)

Symbol delete vote.svg Delete--DangSunM (talk)
I must say: Symbol keep vote.svg Keep, except if the Single value and Unique value limits of station code (P296)
can be cancelled
. --Liuxinyu970226 (talk) 06:02, 13 January 2015 (UTC)
Indeed it looks like they are not quite duplicated. ·addshore· talk to me! 12:18, 18 January 2015 (UTC)
They seem to be different, but to me it's not entirely clear which code they're supposed to be. There are several code systems for railway station (UIC, IBNR, IFOPT, german railway (DS100, including stations from other countries), swiss railway (DIDOK, including stations from other countries), austrian railway, …) out there. My guess is that station code (P296) is something russian, P722 is either UIC or IBNR and P1655 something korean. So we need a clarification on them and new properties for the remaining code systems. --Nenntmichruhigip (talk) 22:57, 11 February 2015 (UTC)
Indeed, codes of a station are mixable, even if that's not an interchange station (Q1147171). So let's restart the PFD of station code (P296) if no tldr. The IBNR property is IBNR identifier (P954). --Liuxinyu970226 (talk) 00:58, 20 February 2015 (UTC)
Symbol delete vote.svg Delete. station code (P296) is meant as a generic property with qualifier 'catalog ( P972)' to specify which station code system applies. Stations can therefore have multiple codes as long as these have different values for the qualifier. This means UIC station code (P722), station number (P1655), IBNR identifier (P954), MTR station code (P1377) are redundant and can all be deleted. Alternatively we need to create codes for every system of station naming (thousands?) in this case we definitely need to keep station code (P296) and add "subproperty of:station code" statements to all the specific properties in the hope that at some time in the future we can query for statements using "station code;including subproperties" so we don't have to know what the special property is in order to get the station info. Filceolaire (talk) 01:11, 2 May 2015 (UTC)
But then P296 would have to be altered accordingly. I'll list the affected properties here, feel free to add others to the list: --Nenntmichruhigip (talk) 15:13, 2 May 2015 (UTC)

Pokédex number (P1112)[edit]

(delete | history | links | logs | discussion)

Wrong datatype; should be String, not Number (Quantity). Ebe123 (talk | contributions) 01:41, 1 February 2015 (UTC)

  • If the Pokemon Browser is a subclass of the Pokedex, wouldn't it be better to migrate the subclass into the main class and to correct Pokédex number (P1112)?(Additional, numbers of Pokémon browser number (P1685) aren't consistent.)--Koltars (talk) 20:32, 1 February 2015 (UTC)
    • Yes, it could be done that way. My thinking was that as the Pokémon Browser number is a String and that the existant values are still valid (they all have a qualifier), we could merge the Pokédex number in P1685 and rename it to Pokédex number. That would save some work moving all values (we'll only have to do some). Ebe123 (talk | contributions) 22:59, 1 February 2015 (UTC)
Retrospectively, I think I shouldn't have supported the creation of Pokémon browser number (P1685) as it's actually more efficient to have separate properties for each numbering scheme.
For this property, string would be the datatype we use for these. So yes, support deletion and re-creation with that type. --- Jura 07:21, 5 February 2015 (UTC)

I don't know if it would be good to merge both properties into one with text-type because normal Pokédex numbers are unique in every dex a number is unique, while in Browsers there is an other system with letters with not unige numbers. Furthermore, there are more possibilities to make mistakes by editing. --MGChecker (talk) 14:42, 7 June 2015 (UTC)

architectural style (P149)[edit]

(delete | history | links | logs | discussion)

No tangible benefit from using this property rather than movement (P135). As written in Property talk:P149: The only difference beteween the two properties is that architectural style (P149) is restricted to some classes of items but that does not seem very useful. In practice, p135 is also used for buildings anyway (compare fr:Catégorie:Page utilisant des données de Wikidata/P149‎ and fr:Catégorie:Page utilisant des données de Wikidata/P135). --Zolo (talk) 11:24, 1 February 2015 (UTC).--Zolo (talk) 11:24, 1 February 2015 (UTC)

How is it too vague ? If we say that the movement of monument is neogothic, what can it mean except that architectural style is neogothic ? --Zolo (talk) 16:35, 24 February 2015 (UTC)
"movement of a monument is neogothic" require a lot of imagination to make any sense. It maybe works semantically, but it's not an obvious choice for an amateur. -- Innocent bystander (talk) 09:55, 6 March 2015 (UTC)
@Innocent bystander: Just add an alias or change the label. TomT0m (talk) 15:24, 6 March 2015 (UTC)
Agree, but to what? The problem is that I cannot find any good word that fits one area, but would not be misleading for others and vice versa. -- Innocent bystander (talk) 15:30, 6 March 2015 (UTC)
Maybe we could expand P135 for politics as well. "Movement" fits well there ;) --- Jura 20:36, 8 March 2015 (UTC)
  • Symbol keep vote.svg Keep Unless the English label is changed for movement, it doesn't make sense to merge them as style and movement are not synonymous. (I had to reference a couple dictionaries just to be sure I'm not missing something.) A style can be part of a movement (ie. aestheticism), but not necessarily vice versa. I'm not an expert, but have studied architecture and I've never once heard of a style referred to as a movement. Hazmat2 (talk) 15:56, 27 April 2015 (UTC)
  • It's a stretch to call some architectural styles movements – Modernism yes, Streamline Moderne no – whereas the term "style" always applies to these. But I also see the argument that "architectural style" is to architecture what "movement" is to (e.g.) painting, resulting in the duplication mentioned above. I would prefer to see the properties merged, but called "movement or style"... so Symbol delete vote.svg Delete. Ham II (talk) 18:59, 12 May 2015 (UTC)
  • Symbol keep vote.svg Keeptwo different concepts --Rippitippi (talk) 15:04, 13 June 2015 (UTC)
  • Symbol keep vote.svg Keep. A style is often more specific, 'superficial' and ornamental than an art movement. Pictogram voting comment.svg Comment To slightly contradict - or add nuance to - my opinion: the widely used Art and Architecture Thesaurus by the Getty combines movements and styles in one 'branch' of its thesaurus tree (example). Spinster (talk) 17:11, 24 July 2015 (UTC)

MTR station code (P1377)[edit]

(delete | history | links | logs | discussion)

Redundant to station code (P296). Jc86035 (talk) 13:03, 29 April 2015 (UTC)

See discussion for P1655 above. Same for China railway TMIS station code (P1378), --Nenntmichruhigip (talk) 18:10, 30 April 2015 (UTC)
Pictogram voting comment.svg Comment At the same time, other people are splitting off specific properties from the more generic; not least so that we can use formatter URL (P1630). We need to agree a project-wide policy on this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:51, 30 April 2015 (UTC)
Symbol keep vote.svg Keep ID sets can overlap, e.g. there are several ID systems to identify countries (three from ISO, Special:WhatLinksHere/Q906278) and many for people. Merging them makes them less accessible. But if you want to do that: Merge all into "identifier" and use qualifier to point to the item describing the ID, e.g. ISO 3166-1 alpha-3 code (Q1341492). FreightXPress (talk) 00:26, 1 May 2015 (UTC)
The argument was that we should have one station code (P296) property so all station infoboxes could import info from that property with some lua code to import the "catalog" info from the qualifier. Has that changed now that the various specialised "station code" properties can be marked as "subproperty of (P1647):station code (P296)? Filceolaire (talk) 23:59, 1 May 2015 (UTC)
Symbol keep vote.svg Keep Current quality of station code (P296) values is very low. Adding one more code to this garbage place will make situation worse. — Ivan A. Krestinin (talk) 11:25, 2 May 2015 (UTC)
And speedily Symbol keep vote.svg Keep by formal reason: steps described on this page header were not executed. — Ivan A. Krestinin (talk) 11:32, 2 May 2015 (UTC)
Symbol delete vote.svg Delete Imo it is better to have lesser but more general properties because this makes finding the correct property easier and allows broader usage of few properties. This makes clear that the general idea behind the property is the same. More information can be added using qualifiers or are clear because of the context of the item. For a station code for a station in Hong Kong it is already clear that it is an MTR station code. -- Bene* talk 12:24, 2 May 2015 (UTC)
Bene* - one station can have several IDs, like English on Q1860 has a dozen of IDs. Merging into one general language code property would be loss of information. FreightXPress (talk) 23:59, 4 May 2015 (UTC)
Wtf? The item you linked is a language, not a station. How can a station have multiple station codes? -- Bene* talk 09:22, 5 May 2015 (UTC)
@FreightXPress: Perhaps you are confusing a "station code" with the general identifier datatype. A datatype is not a property. Having only one "station code" property would still allow other properties with the datatype "identifier" to exist. -- Bene* talk 09:24, 5 May 2015 (UTC)
Bene* - "How can a station have multiple station codes?" - Can you answer the question how a language can have multiple identifiers? FreightXPress (talk) 17:29, 5 May 2015 (UTC)
The "station code" property is about stations, not languages. The discussion about languages is offtopic and does not belong into this RFD. -- Bene* talk 20:07, 5 May 2015 (UTC)
The answer for languages could have been an answer for your stations question. It was meant for general education to avoid have this discussion about each class of objects (stations, roads, languages, stars, humans). FreightXPress (talk) 11:45, 7 May 2015 (UTC)
Again, Symbol keep vote.svg Keep, unless if we can cancel the "Single value" & "Unique value" limits of P296. --Liuxinyu970226 (talk) 03:15, 5 May 2015 (UTC)
Symbol keep vote.svg Keep, ... and also the formal constraints check would have to be dropped, since IMHO there is no universal authority prescribing the format of station codes... Property talk:P296 illustrates the confusion, nobody knows what that property really stands for. If we had an identifier datatype of necessary complexity (at least a triple containing of Q-item for the identifier system, formatter URL and identifier value, currently we model things of such complexity as properties where the "constant" attributes are elegantly dealt with as properties-for-properties), then the deletion request would make sense. For the time being we should abandon station code (P296) (or turn it into a class) to avoid deletion requests for properties one can work with. -- Gymel (talk) 09:52, 5 May 2015 (UTC)
@Gymel: Can you provide an example where a station has more than one station code? If I understand that correctly, this property should be used for the official code used for a particular station. Therefore, I think there will be only one official station code per instance. Am I wrong here? -- Bene* talk 12:14, 5 May 2015 (UTC)
w:de:Mannheim Hbf: DB: RM, SBB: MAN, IBNR: 8000244, UIC: (unknown, but exists), IFOPT: de:8222:2417:1, Express-3: 8068585. Have I missed any? --Nenntmichruhigip (talk) 12:51, 5 May 2015 (UTC)
Ok, I see that point. So either we need a property for each of these databases or use the same property in every place. I don't see which option should be preferred as both ones are not ideal. :-/ -- Bene* talk 20:11, 5 May 2015 (UTC)

courtesy name (P1782)[edit]

temple name (P1785)[edit]

Property:P659, Property:P857 and Property:P1152[edit]

(delete | history | links | logs | discussion)
(delete | history | links | logs | discussion)
(delete | history | links | logs | discussion)

All three properties seem to have the wrong datatype and there is no interest in these properties.

Pinging User:Tobias1984, User:GZWDer, User:Chinmay26, User:Li3939108, User:Duesentrieb who proposed/created the properties. --Pasleim (talk) 23:13, 10 May 2015 (UTC)

Andrew Su
Marc Robinson-Rechavi
Pierre Lindenbaum
Michael Kuhn
Dan Bolser
Timo Willemsen
Salvatore Loguercio
Daniel Mietchen
Ben Moore
Vojtěch Dostál
Andra Waagmeester
Elvira Mitraka
David Bikard
Dan Lawson
Francesco Sirocco
Konrad U. Förstner (talk)
Chris Mungall (talk)
Kristina Hettne
Pictogram voting comment.svg Notified participants of Wikiproject Molecular biology --Tobias1984 (talk) 17:46, 11 May 2015 (UTC)

@Pasleim: It is too early to delete properties because too few items or no item are using them. WD is in some sleeping mode because too few WPs are using the data mainly because of some development reasons. We have to wait at least until the implementation of the arbitrary access is finished and after the development of the first infoboxes using mainly WD as data source is lauching to start the purge of properties. Snipre (talk) 15:58, 20 May 2015 (UTC)
@Snipre: I'm not requesting deletion because of too few items using them, otherwise I could request deletion of 271 properties (17% of all properties!). That's the current number of properties with 5 or less usages. But P659, P857 and P1152 are different, as they can't even be used and according to the talk pages nobody realized it. --Pasleim (talk) 13:09, 22 May 2015 (UTC)
  • Symbol support vote.svg Support deletion: as they are not being used, can't be used and nobody (other than Pasleim) tried to use them. --- Jura 05:44, 21 May 2015 (UTC)

eligible voters (P1867)[edit]

(delete | history | links | logs | discussion)

This property duplicate electorate (P1831)

Ping : @Pigsonthewing:, @Милан Јелисавчић:, @Wylve:, @Pikolas:, @Александр Сигачёв:, @Kopiersperre:, @Nikosguard:, @Andreasmperu:, @Nurni:, @GZWDer:, @Pasleim: & @Putnik:. --Dom (talk) 15:13, 20 May 2015 (UTC)

  • Symbol oppose vote.svg Oppose no, it isn't. -- Vlsergey (talk) 15:34, 20 May 2015 (UTC)
    Please give the difference because there is no huge difference in the descriptions, at least in English. Snipre (talk) 15:53, 20 May 2015 (UTC)
    Well, shouldn't we start with arguments about similarity first then, before asking for contra? Anyway, P1831 is about place, P1867 is about election. While P1831 is used for statistical reasons, and regularry updated field (updated with year qualificators), P1867 is fixed-value field, with additional restrictions like "single value only". -- Vlsergey (talk) 15:59, 20 May 2015 (UTC)
    eligible voters (P1867): number of eligible voters for a particular election
    electorate (P1831): number of registered voters for the place
    As I explained but perhaps you didn't read: there is no huge differences in the descriptions. So as you have enough knowledge to say there are not the same, just finish your comment. And no in some countries there is no difference between registered and eligible electors. Snipre (talk) 20:21, 20 May 2015 (UTC)
    I agree with Snipre, I don't see the difference as the only usage of electorate (P1831) is the election no label (Q16634815). So if if electorate (P1831) must be only linked to a location (Q17334923) (or perhaps more precisely to a constituency (Q192611)) and not to an election (Q40231) it must be specified in the specification of this property. --Dom (talk) 08:29, 25 May 2015 (UTC)
    I don't see the difference between the number of voters in a constituency and the number of voters in an election in that constituency. I think the values above could be indicated with the same property with a point in time qualifier.. Filceolaire (talk) 10:24, 3 June 2015 (UTC)
  • The following scenario should show the difference between the two properties: Election is about to take place at Wikitopia on June 20. Unregistered citizens must register on or before June 1 in order to vote in the upcoming election. On June 2, there are 1000 confirmed registered voters. However this doesn't deter others from registering to become voters. On June 5, 100 more citizens registered to become voters. After that, no more citizens registered. If the government publishes a report on the election on June 20, the eligible voters (P1867) would be 1000 (referring to the election) and the electorate (P1831) would be 1100 (referring to Wikitopia). —Wylve (talk) 18:51, 20 May 2015 (UTC)
    @Wylve: Which is the number who tells the numbers of potential voters and which is the number of registred voters and which is the number of those who actually voted? And to which election are you reffering here? Is it the municipal board of Wikisburg or the national election of Wikitopia? Where I live, different elections have different rules. In my county 193,777 had the right to vote for the regional parliament and 189,842 had the right to vote in the national parliament. These two elections took place at the same day, and we used the same voting-card for both of these elections, together with the municipal election, which I do not know the numbers of voters in, but it should be the same as the regional election. -- Innocent bystander (talk) 20:24, 20 May 2015 (UTC)
    @Innocent bystander: To model votes, we currently have eligible voters (P1867), electorate (P1831), ballots cast (P1868), total valid votes (P1697) and votes received (P1111). All of those properties should only be included on items about an election only, except for electorate (P1831), which should be included in the constituency item (or item of a certain administrative area). As to your first few questions, eligible voters (P1867) shows the potential number of voters. As to the number of registered voters, we have electorate (P1831). Not all elections require voter registration, so there might be cases where eligible voters (P1867) is higher than electorate (P1831). ballots cast (P1868) shows the total actual ballots inserted into ballot boxes for a particular election, or in other words, the actual number of voters voted.
The problem you've raised concerning the discrepancy between municipal and national elections only lies in votes received (P1111), as it is the only property that is not election-specific, but area-specific. I'm not sure what the consensus is, but I would have the municipal and national elections as two items, since they are fundamentally different in nature (different electorate, different candidates and the different jobs carried out by successful candidates). Each election item would have their own eligible voters (P1867). —Wylve (talk) 23:15, 20 May 2015 (UTC)
Thank you! You do not have to register here where I live, it's done automaticly. But the lists of voters can be wrong, so the lists of voters are made public during some weeks. If your name by some reason is missing, you can "register" as voter, but such changes in the lists are rare and I have never seen any such number published.
In the 2015 election of Båstad Municipality (Q499464) (the 2014 election was disqualified since those who counted the votes made some severe mistakes) We had [3] eligible voters (P1867): 11,874 ballots cast (P1868): 7,552. (Båstad Municipality is not divided in constituencies, but larger municipalities are.) total valid votes (P1697) 7,494. 11 out of 13 registred political parties got votes received (P1111). 4 non-registred political parties got a total amount of 8 votes. The 41 seats in the local parliament was divided between 7 different political parties. [4] -- Innocent bystander (talk) 05:37, 21 May 2015 (UTC)
  • Symbol keep vote.svg Keep From the discussion, it makes sense to have two properties here, and it's obvious that we need more properties for votes. But I think the labels and description of them could be better. I had to change the Swedish labels here, since they did not fit the description in this discussion. -- Innocent bystander (talk) 04:29, 22 May 2015 (UTC)
  • Symbol delete vote.svg Delete I agree that we must have more properties for elections (as it can be seen on the WikiProject Politics infoboxes), but these two ones don't seems to be very diffrent. --Dom (talk) 08:29, 25 May 2015 (UTC)
  • Symbol delete vote.svg Delete. I can't see a need for 'number of voters in a constituency' and 'number of voters in an election in that constituency' to be different properties and I have read the examples above carefully. Filceolaire (talk) 10:24, 3 June 2015 (UTC)
  • Symbol keep vote.svg Keep. The properties describe two distinct relationships between entities. Here are my reasons for keeping the property:
  1. Not all elections are constituency-based. Keeping this property would allow non-geographical elections, such as notable board elections of a company or party leadership elections.
  2. Not all elections require registration of voters. Therefore, electorate (P1831) could not be assigned to any constituency/geographical area item.
  3. The value of eligible voters (P1867) could not be inferred from that of electorate (P1831), as demonstrated in the example above. —Wylve (talk) 16:42, 12 June 2015 (UTC)

input set (P1851)[edit]

(delete | history | links | logs | discussion)

Unclear definition AS (talk) 01:11, 27 May 2015 (UTC)

I have reviewed the creation discussion and still have no idea what this is for. Symbol delete vote.svg Delete unless @TomT0m, Danneks, Cuvwb: can shed some light on this. Filceolaire (talk) 10:35, 3 June 2015 (UTC)

@Filceolaire: you provided incorrect discussion link. It is about different property. -- Vlsergey (talk) 20:15, 16 June 2015 (UTC)
@AS, Filceolaire: This property can help to describe functions whose domains are too complicated, and maybe not notable by themselves. It is not used much at the moment, but functions (e.g. in set-theoretic sense) are widely used in mathematics, so I think that it may be potentially useful. Danneks (talk) 18:22, 3 June 2015 (UTC)
@Filceolaire, AS: It's the A set in this mathworld definition. It's commonly used for example for the inverse function on the real, who has no value in R for 0, but still has R as input set, for example. The real domain of the function is nonzero real number (Q19546578) (View with Reasonator). TomT0m (talk) 11:22, 6 June 2015 (UTC)
what is the difference between domain (P1568) and input set (P1851)? Can you provide an example when domain (P1568) is not enought? -- Vlsergey (talk) 20:15, 16 June 2015 (UTC)
@Vlsergey: It's done, see my previous message. TomT0m (talk) 20:49, 16 June 2015 (UTC)
@TomT0m: let me make it clear. You want to express that and , right? But we have . Why do we need to duplicate that in function itself? -- Vlsergey (talk) 20:55, 16 June 2015 (UTC)
@Vlsergey: One can be used when we speak of a relation on any sets to any set, not only to functions. For example a database, when a customer can be registered but has not yet bought anything, or a complicated function like 1/(x-1)(x-2)(x-3). The input set of the relation beetween customer and transactions would still be customer, but some may have no relations at all. domain is clearly out of scope here. input set can be applied to function. It's unlikely that the item R minus {1,2,3} will be created either. TomT0m (talk) 21:03, 16 June 2015 (UTC)
@TomT0m: okay, i understood about math functions. Still this can be expressed with qualifiers (R except...). For database relationship it is still not clear for me. What is item and why we can't put "customer" into domain (P1568)? (with broader domain (P1568) definition of course). It would be better to provide an example with actual Wikidata entries. I care little about abstract concepts, sorry. Vlsergey (talk) 21:12, 16 June 2015 (UTC)
I have many example of non total functions, halting problem (Q622849) (View with Reasonator) involves a HALT function which is from programs to 1,0 which has programs as input set but is undecidable. partial function (Q1756942) (View with Reasonator) provides other examples. The notion of domain is also non applicable for relations ( ordering relation (Q1069998) (View with Reasonator) ) like 1<2 or other binary relation (Q130901) (View with Reasonator). It's well know that functions can be seen as binary relations iRo with i (input set) as their domain and o (output set) as their range. TomT0m (talk) 07:21, 17 June 2015 (UTC)

Commonwealth War Graves Commission burial ground identifier (P1920)[edit]

Please delete the above until there is a consensus on on how to define it.

There seems to have been a misunderstanding at Wikidata:Property_proposal/Place#Commonwealth_War_Graves_Commission_burial_ground_identifier on how to define it.

The property was created too quickly by the proposer. --- Jura 21:30, 30 May 2015 (UTC)

  • Keep This is overkill. Jura agreed that the property should be created. I misread his comment about one detail, and now we have a disagreement about how it should be used, which can be resolved - as I requested them to do; see their talk page - in a talk page discussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:57, 30 May 2015 (UTC)
    • I don't think the datatype is a minor detail. To avoid disrupting our downstream users, let's delete this until the proposal discussion comes to a conclusion. Otherwise we end up with more unresolved problems as with the ones you created for Wikidata:Project_chat/Archive/2015/05#How_to_record_property_examples, this despite people providing feedback. --- Jura 04:03, 31 May 2015 (UTC)
      • The data type will be "string", whether we record the full identifier or just the numeric part. The linked, archived, discussion to which you link is immaterial to this matter. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:48, 31 May 2015 (UTC)
        • It's no big deal to delete this. I'm sure we will be able to sort it out eventually. --- Jura 06:33, 1 June 2015 (UTC)
  • Symbol keep vote.svg Keep It's not an ideal situation, but the property exists now and I don't see what deleting it would achieve. It's not clear that the property is wrong as it is. The property does seem to be wanted in some form. Deleting it does not help us store the data. Deleting it does not help to define how it should be used. Deleting and later recreating it (potentially unnecessarily) does not prevent disruption to downstream data users. In fact, I would say the best way to avoid disruption to downstream users would be to focus on determining the best way to store the data so that any changes that are needed can be made as soon as possible, not to get sidetracked by trying to delete it before it's clear that deleting it is even necessary. - Nikki (talk) 10:36, 1 June 2015 (UTC)
  • Calm down the pair of you. Andy Mabbett you shouldn't be creating properties you proposed yourself. Please don't do that again. Jura this is an issue which could have been handled better and with less drama by some direct communication on another forum. Filceolaire (talk) 10:48, 3 June 2015 (UTC)
    • I am, and have been throughout, perfectly calm. When I asked whether I should create properties I proposed myself, on the "Project chat" page there were zero objections. Indeed, one editor thanked me for doing so: Jura. However, I already refrain from doing so where there are objections. As I have already stated on Jura's talk page, with an apology, I misread Jura's latter comment on the proposal in this case. As you can see there, I also invited Jura to raise his concerns on talk page. He has not done so. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:41, 3 June 2015 (UTC)

officeholder (P1308)[edit]

(delete | history | links | logs | discussion)

Proposal pages: Original proposal (accepted, property created), later duplicated proposal (rejected), third duplicate proposal (rejected, most participants not aware that the property already existed afaict). This property is an inverse of position held (P39), which could result in many position items having literally hundreds or thousands of values set, making the item potentially unusable. Regardless of whether inverses are ever sensible, it's fairly clear that in this case it would be thoroughly unmanageable. --Yair rand (talk) 09:39, 14 June 2015 (UTC)

Pinging original proposer @Jdforrester: and property creator @Jakec:. (Apparently the property_proposer and property_creator parameters in Template:Request for deletion don't actually do anything.) --Yair rand (talk) 09:43, 14 June 2015 (UTC)
  • Symbol delete vote.svg Delete With arbitrary access rolling out, this property should be deleted. —Wylve (talk) 13:13, 17 June 2015 (UTC)
  • Pictogram voting comment.svg Comment there is actually a third way doing more or less the same: head of government (P6) and head of state (P35).
    officeholder (P1308) has the advantage of not overloading items for countries as does head of government (P6).
    position held (P39) does work well to make lists like Governors of Vermont --- Jura 09:54, 18 June 2015 (UTC)
  • Symbol keep vote.svg Keep; P6 and P35 are inappropriate for the wider needs, as widely discussed at the time. Individuals' unwillingness to help build the data right now isn't a good criterion for whether we should have the flexibility to express it. James F. (talk) 02:28, 22 June 2015 (UTC)
    @Jdforrester: This is redundant to position held (P39), not head of government (P6) and head of state (P35). Many offices (though not, afaik, offices of head of state/government) have been held by thousands of people. --Yair rand (talk) 11:36, 22 June 2015 (UTC)
    @Yair rand: San Marino elects at least 4 head of states every year. And Stockholm has 12 kommunalråd. -- Innocent bystander (talk) 13:12, 15 July 2015 (UTC)
    @Yair rand: Except it's precisely the ontological reverse of position held (P39), which allows us to model more complex things (like parallel office holders, pretenders, etc.). James F. (talk) 00:41, 28 June 2015 (UTC)
    I don't understand what you're saying. (This is probably because I don't recognize the term "ontological reverse".) Do you disagree that this is just a simple inverse of position held (P39), and adds no new data? If so, could you give an example of data this property could be used for that position held (P39) couldn't be used for? --Yair rand (talk) 16:53, 28 June 2015 (UTC)
    If it is the inverse of another property it adds new data per definition. If A is connected to B by one property B is connected to A by its inverse, so deleting the inverse would require another inverse propery to replace it. - cycŋ - (talkcontribslogs) 12:18, 15 July 2015 (UTC)
    No, it would not. Properties are not required to have inverse properties. This inverse in particular is completely unmanageable. --Yair rand (talk) 18:19, 15 July 2015 (UTC)

no label (P1361)[edit]


(delete | history | links | logs | discussion)

Created with no answer to the concerns I raised. Duplicates official website (P856), which has the alias "official blog". Only used on ten items. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:13, 8 July 2015 (UTC)

  • Symbol delete vote.svg Delete Redundant, there should be a qualifier for official website that allows the specification of what type of website though. Antrocent (talk) 03:09, 15 July 2015 (UTC)
  • Symbol delete vote.svg Delete agree with Antrocent, here --Hsarrazin (talk) 23:20, 16 July 2015 (UTC)
  • Symbol keep vote.svg Keep I don't see what the benefit to changing it to a qualifier would be, nor is it clear to me which qualifier is even being proposed. I would rather remove the blog aliases from official website (P856) (the first of which, as far as I can tell, was added by you after this property had been created) and add subproperty of (P1647) official website (P856) to this one. As for it only being used 10 times, it sounds like we actually need to add/import more data (en:Template:Official blog would be a start). Also pinging @DunDunDunt, AmaryllisGardener, Ivan A. Krestinin, Micru: who proposed/supported this property originally. - Nikki (talk) 03:07, 17 July 2015 (UTC)
  • Symbol keep vote.svg Keep per Nikki. Filceolaire (talk) 03:14, 21 July 2015 (UTC)
  • Symbol keep vote.svg Keep per Nikki. Most entities for which this could be applied have a unique official (main) website and unique official blog. This property would be quite useful to import data from Wikipedia. Innotata (talk) 02:45, 29 July 2015 (UTC)


(delete | history | links | logs | discussion)

Redundant to replaced by (P1366) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:37, 8 July 2015 (UTC)

  • Symbol keep vote.svg Keep There is significant ambiguity in the idea of "replaced by" when dealing with things that are not explicitly part of a series in the way that presidents (etc.) are. I think it is useful to have a property that explicitly states the replacement was spatial. An object could be replaced both spatially and functionally in two different ways. Antrocent (talk) 03:14, 15 July 2015 (UTC)
  • Symbol keep vote.svg Keep per Antrocent. I have added a statement that this is a 'subproperty of:replaced by'. Eventually we will be able to search on 'replaced by (including subproperties)'. Filceolaire (talk) 03:17, 21 July 2015 (UTC)


(delete | history | links | logs | discussion)

Apepars to duplicate Catalan object of cultural interest ID (P1586) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:48, 8 July 2015 (UTC)

Have a look at the property descriptions on the talk pages. --- Jura 08:52, 8 July 2015 (UTC)