Wikidata:Properties for deletion/Archive/2022/2

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

number of vaccinations (P9107)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

There is no consensus to delete this property. Discussions on changes of scope can happen on the property talk page. More general discussions about numerical data of countries could go to Project chat. — Martin (MSGJ · talk) 21:47, 3 February 2022 (UTC)

@Pamputt: created the property in violation of our rules. Our rules ask for "All opposing points of discussion should be addressed before creation occurs." The point about whether the property should be about the amount of people who got a vaccine dose or the amount of people who got all vaccine doses that are planned is not cleared and without it being clear the property will likely have some data of both and thus be mislead users who expect it to provide sensible data. —ChristianKl ❪✉❫ 22:14, 2 February 2021 (UTC)

Keep For reference here is the proposal discussion. While it's true that nobody provided a specific solution to ChristianKl's question, we generally use qualifiers to specify such details; in practice addressing this is going to come up immediately for anybody trying to use the property; I would hope the resolution finds a place on the property talk page. I don't think this broadly supported and clearly useful property needs to be deleted for this reason. ArthurPSmith (talk) 22:31, 2 February 2021 (UTC)
- @ArthurPSmith: It's a property that's likely to misinform people in an important public health area. Basically your idea is that people are likely to use qualifiers for this property, which means they won't use it in the way it was proposed to be used. Don't worry, nobody is going to use the property in the way it was suggested in the property proposal seems to me a bad argument. If we find out that people actually use it in the way that it was proposed, would you think your assessment is wrong? ChristianKl ❪✉❫ 13:00, 8 February 2021 (UTC)
Comment I have never understood why WD did not simply model this way [number] /of/ [what] --Bouzinac ^{💬●✒️●💛} 08:21, 8 February 2021 (UTC)
- Agree - Salgo60 (talk) 01:53, 9 February 2021 (UTC)
- Because it's unspecific and doesn't tell us the predicate of the relationship. English users will find it in many cases easy to guess what's meant based on context. Speakers of languages that don't have a direct equivalent to of will find it harder and generally there are cases where it might not be 100% clear what the predicate is. In many cases In many cases has part(s) of the class (P2670) with quantity (P1114) takes the same effort as [number] /of/ [what] would need but is more precise and it's clear to everyone what the predicate is.

Furthermore having the property proposal process gets data to be standardized so that different people don't understand the relationship differently and put in different things with the same properties.

I don't think requiring people who want to add data about vaccinations to Wikidata to first decide on which data they actually want to add before they get a property that allows them to input data to be unreasonable. It prevents people from getting mislead by inconsistent data with matter for important health data. ChristianKl ❪✉❫ 21:06, 9 February 2021 (UTC)

Speedy keep in use in Módulo:Ficha de epidemia at the Spanish Wikipedia. --Amitie 10g (talk) 00:03, 30 May 2021 (UTC)

Comment It may be worth clarifying whether this property includes number of persons vaccinated to immunity or number of vaccines administered. In particular for COVID-19, where two-dose and single-dose vaccines are co-marketed, this is important. – The preceding unsigned comment was added by Ari T. Benchaim (talk • contribs) at 23:47, June 21, 2021‎ (UTC).

Keep but change to "number of full vaccinations" or "number of vaccine doses given", or make a new property for either. AntisocialRyan (talk) 04:43, 7 August 2021 (UTC)

On which basis ? Since the creation of a vaccine ? Among living people ? During 1 year ? Including 3th, 4th or may be more boosters ? How woul be the property managed in the case of polio vaccine, for instance ? --Pa2chant.bis (talk) 08:12, 15 September 2021 (UTC)

Delete in the current usage. The property is likeable but lacks a good definition as pointed above. Moreover, this will once again flood country items with numerical data which are updated at regular intervals, something that would much better reside on Wikimedia Commons. It's just not sustainable to store numerical data in country-wide properties like this. In the original proposal, I suggested at least moving these data to vaccine items such as mRNA-1273 vaccine (Q87775025) if anything.Vojtěch Dostál (talk) 15:11, 25 November 2021 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

coordinates of depicted place (P9149)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Withdrawn. This isn't going anywhere. Thanks. Mike Peel (talk) 19:37, 21 January 2022 (UTC)

I missed the proposal of this property (sorry), but this seems to be a lazy approach to creating a new item with a coordinate location (P625) value, which will only cause more work further down the line. It's better to sort it out properly at the start. Pinging those involved in the property creation, @Jheald, Jura1, GZWDer, Ainali, NMaia, Multichill: —Mike Peel (talk) 21:21, 15 February 2021 (UTC)

The proposal has been open for nearly 3 months. Nominating properties for deletion on the same day the property was created is bad practice and disruptive. So I'm closing this one. No whataboutism (Q4053075) please. Those previous ones were disruptive too. Appeals at Wikidata:Administrators' noticeboard. Multichill (talk) 21:34, 15 February 2021 (UTC)
- @Multichill: I posted there yesterday, there has been no response. You created the property, you can't unilaterally close the discussion here, hence why I'm re-opening it. If you want me to stop, try answering the alternative solution I raised here? Thanks. Mike Peel (talk) 20:25, 17 February 2021 (UTC)
I personally find this property useful, especially on Wikimedia Commons. There you can specify both the camera position and the object position. Using the property ... you now have the option of specifying both positions in the "image data object". Keep --Gymnicus (talk) 14:22, 19 February 2021 (UTC)
@Gymnicus: The camera position makes sense, as that's arbitrary. But the object location isn't - you'll want to say that the image depicts the object anyway, so why not just create an item for it and use coordinate location (P625), rather than unnecessarily duplicating data? Thanks. Mike Peel (talk) 10:14, 24 February 2021 (UTC)

@Mike Peel: That is your opinion. I also like the property coordinates of depicted place (P9149). In addition, it is not the case with every image that the object coordinates are the same as the coordinates in the data object. Simply for the reason that objects are divided into various sub-objects, which, however, do not deserve their own data object. --Gymnicus (talk) 10:27, 24 February 2021 (UTC)

Except you don't want to always create an item for it. e.g. If someone takes a picture of a tree in the middle of a field, they can say it depicts a tree without having to create an item for that specific tree. Take File:Tree_On_A_Field_(108523987).jpeg, for example, the tree is clearly visible on satellite images and its coordinates could be added. - Nikki (talk) 09:51, 23 August 2021 (UTC)

Keep Let's take a painting of the eifel tower located in a London art gallery:

coordinates of depicted place (P9149) - Coords somewhere near the Eifel tower

coordinate location (P625) - Coords somewhere in London

location of the point of view (P7108) - Coords where to photo of the painting was made

The data object does not have the same coords at the object it depicts. --Schlurcher (talk) 13:54, 24 March 2021 (UTC)

Keep Not everything depicted should have an item so the argument for deletion falls. Ainali (talk) 21:50, 12 January 2022 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P4886 (P4886)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Deleting — Martin (MSGJ · talk) 12:30, 31 January 2022 (UTC)

P4886 (P4886): (delete | history | links | entity usage | logs)

Same reason as P4883 (P4883) :The website was heavily changed, and now all IDs lead to the main page. Therefore the property is useless now. Every ID have been transferred into their new ID which is FFF player ID (P9264) Kwayst (talk) 11:04, 26 May 2021 (UTC)

Notified participants of WikiProject France

Notified participants of WikiProject Association football Pamputt (talk) 06:21, 3 June 2021 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Track and Field Statistics male athlete ID (P3925)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Cannot be merged — Martin (MSGJ · talk) 08:41, 4 February 2022 (UTC)

Functionally identical to Track and Field Statistics female athlete ID (P3924). The only difference is the gender argument in the URL http://trackfield.brinkster.net/Profile.asp?ID=$1&Gender=M, which is not only irrelevant for the link to work (compare [1], [2], and also [3]), but also (if anything) should be constructed from sex or gender (P21). Thus, Track and Field Statistics male athlete ID (P3925) should be merged into Track and Field Statistics female athlete ID (P3924). —Bender235 (talk) 15:18, 3 July 2021 (UTC)

Notified participants of WikiProject Athletics

Oppose I would vote for merge, but first we should find where is used. This property is not just for Wikidata. If both properties were merged, the, the it should be unisex. --Amitie 10g (talk) 17:41, 28 August 2021 (UTC)
Support with unisex renaming. If some Wikipedia use Track and Field Statistics male athlete ID (P3925) in some modules they use Track and Field Statistics female athlete ID (P3924) in this modules too. Сидик из ПТУ (talk) 17:51, 28 August 2021 (UTC)
Support with rename to Track and Field Statistics athlete ID at merged property. I assumed these were distinct and split by gender, but all indications are the ID alone is unique for athletes at this site. Sillyfolkboy (talk) 12:59, 30 August 2021 (UTC)
~~Consensus to merge the data and delete the duplicate property — Martin (MSGJ · talk) 11:12, 3 February 2022 (UTC)~~
Reopened discussion. It seems that the gender is required. http://trackfield.brinkster.net/Profile.asp?ID=3344&Gender=W relates to Shelly-Ann Fraser-Pryce (Q5793) but http://trackfield.brinkster.net/Profile.asp?ID=3344 relates to someone called John Kilpatrick — Martin (MSGJ · talk) 11:23, 3 February 2022 (UTC)

@Bender235, Amitie 10g, Сидик из ПТУ, Sillyfolkboy: — Martin (MSGJ · talk) 11:26, 3 February 2022 (UTC)
This completely changes everything. I vote for keep both properties. Сидик из ПТУ (talk) 11:36, 3 February 2022 (UTC)

Agreed to end this discussion. The original basis for merging is not true. Sillyfolkboy (talk) 22:39, 3 February 2022 (UTC)

This is weird, given that my original examples ([4], [5], and also [6]) still work, so it can't be a recent change to their system. But either way, I agree with aborting the merger under these circumstances. --Bender235 (talk) 01:15, 4 February 2022 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P8510 (P8510)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Deleted Consensus for deletion. Pamputt (talk) 19:40, 6 August 2021 (UTC)

P8510 (P8510): (delete | history | links | entity usage | logs)

Exactly the same ID than P4724 (Maitron ID). A Maitron article is unique and can be used in "Le Maitron des Fusillés" or in others Maitron Dictionaries. This property is redundant and a bit ambiguous. I can take in charge the maintenance after the deletion of the property. @Nomen ad hoc, Pamputt:,

Notified participants of WikiProject France —Benoît (discussion) 07:40, 19 July 2021 (UTC)

+This explanation in French [7]. --Benoît (discussion) 07:42, 19 July 2021 (UTC)

Delete --Benoît (discussion) 07:42, 19 July 2021 (UTC)

Hello, OK but please be careful about these items... The two webpages does not show exacly same information, when same ID. Bouzinac ^{💬●✒️●💛} 07:47, 19 July 2021 (UTC)

Actually it is the same information (same article): Maitron des Fusillés ID means only that the article with Maitron ID was used in "Maitron des Fusillés" online. --Benoît (discussion) 08:31, 19 July 2021 (UTC)

Example with Marc Bloch [8] and [9] same text, same data, same images. Only the CSS is different. --Benoît (discussion) 08:37, 19 July 2021 (UTC)

Delete per discussion, Nomen ad hoc (talk) 17:03, 19 July 2021 (UTC).

FYI, there are currently 164 uses of P8510 (P8510). Let us wait until the end of the months to get more opinion and after, could you remove all statements that use P8510 (P8510) before I delete this property? Pamputt (talk) 08:37, 21 July 2021 (UTC)

I can manage these 164 usages. Before or just after the property deletion? @Pamputt:. --Benoît (discussion) 03:52, 22 July 2021 (UTC)

I would say, just before before, so that it is easy to find them using a query :-) Pamputt (talk) 05:45, 22 July 2021 (UTC)

I do that this evening :) Thanks. --Benoît (discussion) 16:13, 22 July 2021 (UTC)

Not at all usage of this property now (in the main). --Benoît (discussion) 11:00, 23 July 2021 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

TV.com ID (P2638)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Kept. Consensus to keep this. Thanks. Mike Peel (talk) 19:38, 21 January 2022 (UTC)

Hello, I am not sure, if am I doing this right, but this property maybe should be deleted because http://www.tv.com/ does not work anymore. —Patrik L. (talk) 20:32, 27 July 2021 (UTC)

Keep This is not a valid reason for deletion, since the identifiewr still exists, and broken links can be linked to archived version (if exists). --Amitie 10g (talk) 04:24, 28 July 2021 (UTC)
Keep I think this property is still helpful when it was popular and gains a lot of uses. A l p h a m a 03:36, 2 September 2021 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

ancestral home (P66)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Kept. Consensus to keep this. Thanks. Mike Peel (talk) 19:39, 21 January 2022 (UTC)

Discussed before and DR withdrawn upon guaranties that it would be used "only for Chinese people". Please see now how it is used arbitrarily for so many people. We must not keep this kind of subjective properties. Are we going to add ancestral country of Mustafa Kemal as Turkestan or Ancient Macedonia? This is astonishing! —E4024 (talk) 18:14, 28 September 2021 (UTC)

@E4024: There seems to be a need for the property, at least in the form it was originally envisioned (but properties may evolve in their scope). If you don’t like how it’s used, start a discussion about correct usage and after a proper discussion require references per property constraint and/or start to delete dubious statements. --Emu (talk) 19:45, 28 September 2021 (UTC)

Keep Doesn't seem to be another way to document this information Germartin1 (talk) 20:48, 2 October 2021 (UTC)

Keep The information is important for Chinese people. Most Chinese people have this property described in serious sources without mentioning place of birth (P19). Incorrect usages of the property can be removed. --Midleading (talk) 09:38, 7 October 2021 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P5326 (P5326)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Deleted Consensus for deletion. Pamputt (talk) 14:43, 29 December 2021 (UTC)

Deprecated and unused. WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.. As per this discussion all instances where this property was used have been replaced by stated in (P248) combined to reference has role (P6184): first valid description (Q1361864). —Christian Ferrer (talk) 13:09, 24 October 2021 (UTC)

Delete - This property was never a good idea. --Succu (talk) 15:17, 24 October 2021 (UTC)
Delete discussion supporting this seems clear. ArthurPSmith (talk) 14:18, 25 October 2021 (UTC)
Delete --SilentSpike (talk) 13:36, 24 November 2021 (UTC)

@Christian Ferrer, Succu, ArthurPSmith, SilentSpike: it seems that this property should be deleted. Could you remove the 33 remaining uses of this property so that we can delete the property? Pamputt (talk) 13:23, 29 December 2021 (UTC)

@Pamputt:

Done I removed it and replaced it where it was necessary. It is not used anymore. Christian Ferrer (talk) 13:52, 29 December 2021 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P10089 (P10089)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Deleted Consensus for deletion.Pamputt (talk) 12:48, 24 November 2021 (UTC)

P10089 (P10089): (delete | history | links | entity usage | logs)

Identcal to Language Council of Norways termwiki ID (P5445): Identifier for a term in the Norwegian language, as given by an entry in the Language Council of Norways termwiki. This is a terminology database for academic disciplines. The terms are usually given as Bokmål, Nynorsk, and English variants. —Pmt (talk) 21:25, 23 November 2021 (UTC) asked for deletion by User:Pmt who also proposed it

Delete re-create when ready/needed. Do not create properties to "not use". --- Jura 12:02, 24 November 2021 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P10083

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Not deleted No opposition to this property other than from the proposer. - Nikki (talk) 22:23, 27 December 2021 (UTC)

Given the problematic nature of the datasource and as corresponding concerns in the property proposal discussion weren't addressed. I ask the property creator for an explanation, but they couldn't explain if and how they see the matter resolved (User_talk:Pamputt#Property_for_potentially_problematic_content). --- Jura 12:58, 2 December 2021 (UTC)

Keep The only expressed concern was something from Jura about copyright violations, which doesn't seem to be a relevant issue in this case. ArthurPSmith (talk) 18:18, 2 December 2021 (UTC)

Keep Jura's claim that the website „mainly host[s] copyvios and the like“ was not elaborated even after being asked on the proposal page and excluding sites merely because they have "wiki" in their name or because they share the same topic as another site with "wiki" in its name feels arbitrary to me. --Nw520 (talk) 23:24, 2 December 2021 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P1849 (P1849)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Deleted — Martin (MSGJ · talk) 21:36, 3 February 2022 (UTC)

P1849 (P1849): (delete | history | links | entity usage | logs)

Identifier appears to have been abandoned

@Pigsonthewing, Jeblad: It appears this identifier is no longer in use. Also only 5 Wikidata items use this identifier and all instances are wrong according to the specified format. If one visits a page pointed to by a different property SSR place name number (P1850) one can see current and historic written forms of the location names. The original identifier cannot be found on that page however, instead one can sometimes find a reference to a case-number or an identifier consisting of the location name plus another number. But as far as I can tell it's inconsistent and thus ill-suited as a replacement. I also consider that any need to give a reference for written forms can be served by native label (P1705) with SSR place name number (P1850). —Infrastruktur (T | C) 09:24, 13 December 2021 (UTC)

Delete The usage of this planned according the property proposal seems complicated and is obviously not what people are doing with it (the few times it has been used). Given Infrastruktur's assessment above it does not seem worth keeping around here. ArthurPSmith (talk) 18:18, 13 December 2021 (UTC)
Delete per the above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:06, 14 December 2021 (UTC)
Delete it of no value, as leads us nowhere.589q (talk) 01:42, 7 January 2022 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

has part(s) of the class (P2670)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

request withdrawn --- Jura 12:59, 8 January 2022 (UTC)

This property is supposed to be used on classes and it's values should be classes. However, people who do not realize that an item is a class sometimes use has part(s) (P527) instead or both properties. It would be much more simple to use has part(s) (P527) and enforce that the value should be a class when used on classes and an instance when used on instances. —Lectrician1 (talk) 18:35, 27 December 2021 (UTC)

Keep These properties have different meanings, it makes no sense to delete one because the other exists. Consider the example item triathlon (Q10980) from P527. SilentSpike (talk) 15:32, 28 December 2021 (UTC)

@SilentSpike

The only difference between the properties is whether the are used on classes or instances. It seems like they have different definitions but this difference can be accounted for by only using has part(s) (P527) (unless you can find a situation in which both (has part(s) (P527) and has part(s) of the class (P2670) are needed).

triathlon (Q10980)has part(s) of the class (P2670)sports discipline (Q2312410)quantity (P1114)3 can already be inferred by instance of (P31)multisport sport (Q43767805) and the number of has part(s) (P527) values. You do not need has part(s) of the class (P2670) here because there are only the 3 sporting parts of a triathlon to be concerned with. Lectrician1 (talk) 18:19, 28 December 2021 (UTC)

I agree with you on triathlon (Q10980), however if they have different domains then by definition they are different properties. Yes, we could use one property and say that when used in different contexts it means different things, but that (to me) is a bad practice which is actually more complex. Taken to a logical extreme, we could have one property that means 10 different things depending on the presence of other properties, but it's an overly complex model. It makes more sense to me for the property to have a clear meaning regardless of other properties on the subject. SilentSpike (talk) 18:23, 28 December 2021 (UTC)

Yep, I totally see where you're coming from and agree.

I'll give the example that caused me to propose this deletion in the first place. I think I misunderstand how has part(s) of the class (P2670) should be used in particular instances.

For example, am I using has part(s) of the class (P2670) correctly on RDF dataset (Q31388616)? Lectrician1 (talk) 01:54, 29 December 2021 (UTC)

Keep While it may be a bit confusing, it's clearly a different meaning and should be kept. ArthurPSmith (talk) 19:50, 30 December 2021 (UTC)

@SilentSpike @ArthurPSmith since you both think that each are needed because they have different domain usages (has part(s) (P527) should only be used on and with classes, has part(s) (P527) only on and with instances), what do you think establishing the following constraints that could help prevent the current confusion?

prevent the use of has part(s) of the class (P2670) on items with has part(s) (P527)
prevent the use of has part(s) (P527) on items with subclass of (P279)
require items with has part(s) of the class (P2670) to have subclass of (P279)
require items with has part(s) (P527) to have instance of (P31)
require values of has part(s) of the class (P2670) to have subclass of (P279)
require values of has part(s) (P527) to have instance of (P31)
prevent values of has part(s) (P527) from having subclass of (P279)
prevent values of has part(s) (P527) from being instance of (P31) metaclass (Q19361238)

Lectrician1 (talk) 00:02, 7 January 2022 (UTC)

I have one uncertainty which is that an item can have both subclass of (P279) and instance of (P31). It might make more sense to say has part(s) (P527) "must have" instance of (P31) (rather than prevent subclass of (P279)). SilentSpike (talk) 15:48, 7 January 2022 (UTC)

@SilentSpike Hhhhhhh I just had this discussion on Telegram regarding President of the United States (Q11696), but if an item is truly just an instance and not a class, it should not have subclass of (P279). The item needs to be fixed if that's the case. Lectrician1 (talk) 16:29, 7 January 2022 (UTC)

@Lectrician1: I'm not sure I follow where you are getting these constraints from. Solar System (Q544) is not a class, but has parts of the class inner planet of the Solar System (Q3504248). has part(s) of the class (P2670) is perfectly fine applied to individual instances in cases like this, in fact that was my understanding of its main purpose. ArthurPSmith (talk) 17:44, 7 January 2022 (UTC)

Yes, that statement is valid, but Solar System (Q544) is an instance of (P31) planetary system (Q206717) and planetary system (Q206717) has already has a statement has part(s) of the class (P2670) planet (Q634).

I would prefer a classification system where the parts of a class are always classes and the parts of instances are always instances. Describing the part-whole relationship at the highest classification level and only at the highest level is the most-appropriate so that it is not unnecessarily repeated (thus maybe causing confusion) for subclasses or instances (unless, the subclasses have parts that are more-distinct).

Also, as a seasoned Wikidata editor, you've probably realized that has part(s) of the class (P2670) on a class could be used to constrain the types of parts an instance of that class has. Making sure the whole classification system is in the best order and has no confusing or incorrect has part(s) of the class (P2670)/has part(s) (P527) statements between levels of classes is essential for implementing this system in the future. Lectrician1 (talk) 18:15, 7 January 2022 (UTC)

@ArthurPSmith Oh and I forgot to mention that I do realize the use of has part(s) of the class (P2670) on Solar System (Q544). However, I don't find it's necessary because the classes of the parts of an instance can easily be found by querying what they are an instance of. We don't need to specify it explicitly. It's unnecessary and can cause confusion. Also, that would mean that we could do that to specify the class of the parts of any instance, which given how many instances there are out there, would absolutely be unnecessary. If we're going to establish conventions we might as well do it with the thought that they are going to and should be used where they're needed and only where they're needed. The current flexibility in the usage of has part(s) of the class (P2670) creates a system that is much too flexible and not always beneficial to documentation of parts of a class or instance because of the confusion it can cause. Lectrician1 (talk) 18:22, 7 January 2022 (UTC)

@Lectrician1: I think you are misunderstanding here (and I agree this can be confusing). inner planet of the Solar System (Q3504248) is a class with exactly four instances: the four inner planets of our solar system. Solar System (Q544) is the only stellar system where those four planets are found, and that class is specifically a class associated only with Solar System (Q544), nothing else. So it is not a question of classes only being allowed to use has part(s) of the class (P2670), non-classes like Solar System (Q544) need this property also to describe this sort of relationship. ArthurPSmith (talk) 18:33, 7 January 2022 (UTC)

@ArthurPSmith But you don't need the property. You can find the classes of the parts of an instance (in the case of Solar System (Q544), inner planet of the Solar System (Q3504248)) by looking at the parts or querying for them. Lectrician1 (talk) 19:25, 7 January 2022 (UTC)

I wonder if you don't assume that Wikidata "is complete". In any case, I think we can close this deletion discussion as everybody seems to agree on keeping it. --- Jura 20:02, 7 January 2022 (UTC)

I wonder if you don't assume that Wikidata "is complete".

I guess I don't assume it's complete? I'm not sure exactly what you mean.

In any case, I think we can close this deletion discussion as everybody seems to agree on keeping it.

Ya you should close. Do you want to continue this on your talk page @ArthurPSmith? Lectrician1 (talk) 20:44, 7 January 2022 (UTC)

"But you don't need the property. You can find the classes of the parts of an instance (in the case of Solar System (Q544), inner planet (Q3504248)) by looking at the parts or querying for them".

I think the above comment assumes that these are present (or Wikidata is complete in this regard) --- Jura 21:15, 7 January 2022 (UTC)

@Jura1 I understand your point. Okay, maybe we don't need to limit has part(s) of the class (P2670) to classes.

But what I do want to stop is the use of has part(s) (P527) on classes. Can we agree on that and move forward with the appropriate constraints? Lectrician1 (talk) 22:22, 7 January 2022 (UTC)

I don't think this is a trivial question and here is not really the place to discuss it. --- Jura 12:57, 8 January 2022 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Microsoft Academic ID (P6366)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Kept. Consensus to keep this. Thanks. Mike Peel (talk) 19:40, 21 January 2022 (UTC)

The Microsoft Academic project has been inactive for a long time (now fully retired) and no data is accessible since December 31, 2021. The links on Wikidata are redirected to Wayback Machine, but since the Microsoft Academic project is a JavaScript website, most pages are useless. On the other hand, the purpose is to show the current status of the publications. Redirecting to an older page is misleading. Moreover, the IDs were merely the address of web pages for each publication, institution, author, etc; and the ID in itself had/has no meaning to be useful as a reference ID for the future. —589q (talk) 01:37, 7 January 2022 (UTC)

As a side note, the Microsoft Academic IDs on Wikidata are all messed up with Wayback Machine. For example, check University of Toronto, the archive.org link leads to Plant & Food Research in New Zealand. This occurs for all the entries I checked. In addition, the references, which are all from gric.ac) are invalid because grid.ac has dropped Microsoft Academic ID. 589q (talk) 02:23, 7 January 2022 (UTC)

I agree on the observation, so

Delete Pamputt (talk) 06:46, 7 January 2022 (UTC)

As there are snapshots of Microsoft Academic Graph we should first get some data of how consistent the data is.--GZWDer (talk) 14:05, 7 January 2022 (UTC)

As I checked, all snapshots are oddly wrong because of JavaScript process. In any case, the snapshots are useless here. Next years, it is meaningless to have a link showing citations until 2021. There are other resources showing the same information. 589q (talk) 15:39, 7 January 2022 (UTC)

I think with "snapshop", GZWDer meant database dumps. What you seems to bother are broken links to archive.org. This is being fixed. --- Jura 16:08, 7 January 2022 (UTC)

My bad then! The available database dumps are much older, and back to a few years ago when Microsoft decided to abandon the project. It is unlikely to capture anything meaningful from those database dumps because Microsoft Academic was not producing any new contents in the first place. The best case scenario is that someone create a website from the latest database dumps and change the URL of the property to redirect to the new website. Otherwise, the current archive.org links are incorrect and misleading, and should be avoided at any cost. 589q (talk) 03:38, 8 January 2022 (UTC)

They should be gone in a couple of days. Let's keep this then. --- Jura 12:55, 8 January 2022 (UTC)

Keep OpenAlex took the last available dump of MAG and has published it as an open database, and will continue maintaining the data, see Wikidata:Property_proposal/OpenAlex_ID. There's also discussion how to migrate the identifier values: OpenAlex IDs are same as MAG ID, but with a prefix letter indicating the kind of item (Author, Institution, Venue, Work, Concept). So we need to keep it until it's migrated. --Vladimir Alexiev (talk) 08:50, 9 January 2022 (UTC)

It's wonderful to have a new project distributing the data, but there are two problems: (1) I anticipate major data discrepancies. Having the old data is not sufficient to continue producing the same data. The OpenAlex project needs the exact same program Microsoft used for identifying authors, institutions, etc. (2) If OpenAlex simply visualizes the Microsoft Academic data until 2021, it is fine to redirect the Microsoft Academic ID to OpenAlex. Otherwise, it is misleading to use the Microsoft brand for another project. As I checked the official website, OpenAlex uses different sources including Microsoft Academic. The purpose of the present proposal is to avoid misleading over the dead project of Microsoft Academic Graph. 589q (talk) 13:30, 9 January 2022 (UTC)

Keep no reason to delete. maybe a mirror will be stood up using the dump. even without a mirror it's fine to keep. BrokenSegue (talk) 14:09, 11 January 2022 (UTC)

Keep until the question around OpenAlex (or other mirrors) is resolved. As long as the data is useful (to someone) it should not be deleted. --Hannes Röst (talk) 14:51, 13 January 2022 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

inception (P571)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Consensus to keep — Martin (MSGJ · talk) 21:27, 3 February 2022 (UTC)

It is conceptually the same thing as start time (P580): when something begins. Therefore the properties should be merged. If two properties about when an item starts, it's likely that a more-specific property should be used. For example, distinguishing when something is created vs. published. Or, to avoid confusion between starting dates of items, more-specific event-based items can be created to distinguish the various events involved with an entity and their corresponding start dates. For example, a movie should have separate linked items for the filming, editing, release, etc. and when each of those started should be distinguished on those items - not the movie item. —Lectrician1 (talk) 19:08, 12 January 2022 (UTC)

@Eihel this may be of-interest since I saw your recent edits on the properties. Lectrician1 (talk) 19:25, 12 January 2022 (UTC)

I was about to say what I think the difference is, then I saw that start time (P580) says "an item begins to exist" in the description and now I have no idea what the difference is supposed to be.

Though WRT the "more specific item" things for something like a film: would that not just be significant event (P793) → principal photography (Q1256415) or whatever, plus the relevant qualifier of start time (P580)? Inductiveload (talk) 19:56, 12 January 2022 (UTC)

Hello, those properties do not have the same scope :

inception (P571) is a property for statements, indicating when the (non-living) item begins to exist. -> for living items, use date of birth (P569)
start time (P580) is a property for qualifiers, indicating when the statement begins to be true not created

KeepIf you thing inception (P571) should be merged, it would be with date of birth (P569), not start time (P580) Hsarrazin (talk) 20:42, 12 January 2022 (UTC)

@Hsarrazin That property is dedicated to the date of birth of humans. Merging it would completely destroy that definition because values of the start times non-human would be added. Lectrician1 (talk) 21:06, 12 January 2022 (UTC)

@Hsarrazin that's I thought, but it's not what start time (P580) actually says in its description: it says "an item begins to exist", which is what I thought inception (P571) was for. Inductiveload (talk) 22:54, 12 January 2022 (UTC)
Keep immediately Not at all, @Lectrician1:. I think this property has already been proposed for deletion on the same theme… or some have already thought of deleting it. When you look at Saami National day (Q2334578), you see that it is essential to have these 2 props, because there are indeed 2 different dates:
1. Saami Conference (Q7665234) approved Saami National day (Q2334578) in 1992 and
2. the first Saami National day (Q2334578) took place from 6 February 1993. @Abbe98, Ainali: will tell you a bit more about it. I went after them on the property because there was a constraint violation that I ignored for quite some time. Let us not forget that a qualifier qualifies a value and not the Item. It is therefore necessary to have 2 properties in the statements. Cordially. —Eihel (talk) 20:53, 12 January 2022 (UTC)
@Eihel Saami National day (Q2334578) is supposed to represent a series of days, not the motion by the Saami Conference (Q7665234) to start recognizing those days. Therefore, the appropriate start time is just the day that series of days started. If you want say how that series of days started, you should create an item that represents the motion to start recognizing those set of days and use the current inception (P571) value there. Lectrician1 (talk) 21:28, 12 January 2022 (UTC)
A start date also implies an end date. We cannot say a date of foundation "started" and a date of foundation "completed". This is where the concept is different. In addition, we cannot create an element each time we want to put a statement, otherwise we only make Items with a statement which is in fact a value. Then deleting the proposals at this point is very limiting (and "chronophage"): we are not going to keep only the property date and add a multitude of qualifiers ! When proposing a property for deletion, please check the Debate, Talk page and usage of that property first. Looking at the example I gave, we can clearly see the difference and the importance of the 2 properties. Cordially. —Eihel (talk) 05:54, 13 January 2022 (UTC)
@Eihel

We cannot say a date of foundation "started" and a date of foundation "completed".

That's why you would use point in time (P585) on a foundation item. Not inception/start time.

In addition, we cannot create an element each time we want to put a statement, otherwise we only make Items with a statement which is in fact a value.

Actually we can. Additionally, making an item for such a motion could have other benefits such as describing who voted on the motion.

Then deleting the proposals at this point is very limiting (and "chronophage"): we are not going to keep only the property date and add a multitude of qualifiers ! When proposing a property for deletion, please check the Debate, Talk page and usage of that property first.

I don't really understand what you're saying here...

Looking at the example I gave, we can clearly see the difference and the importance of the 2 properties. Cordially.

As humans, yes, we can infer what those properties are describing. However, machines can't. Every property should have an exact definition and usage. Otherwise they're going to be used in a conflated situation like in the example you gave and make the data very inconsistent between other items and hard to interpret for machines. Lectrician1 (talk) 06:08, 13 January 2022 (UTC)
Well in that case, @Lectrician1:, you want WD to be no longer a db, but a list of Items! Foolish I think. —Eihel (talk) 06:35, 13 January 2022 (UTC)

ps : There is the same debate for the images. Yes, we could keep that date and add qualifiers, but in this case, we would have to keep only date and remove all the other date (time) type properties. I think we can debate for a long time. At the end, we will end up with date of string type as on BNF… —Eihel (talk) 06:46, 13 January 2022 (UTC)
@Eihel How is a data model like this not reasonable?

Saami National day (Q2334578)
inception/start date6 February 1993

created from1992 Saami Conference

1992 Saami Conference
point in time (P585)1992 Lectrician1 (talk) 06:47, 13 January 2022 (UTC)
Yes @Lectrician1:, if you want. In this case, it is as I have already written: 1)create as a replacement all the Items corresponding to the values which will have to be put in "qualifiers" for all the date properties (except P585) 2)add date to each Item using a property date other than P585. 3)propose for deletion all the properties of the date style at the same time (except P585). You can see the use of all date properties (except P585) to imagine the extent of the work. So I think I'll be dead, a long time ago, when you finish this job. As long as this is not done, we keep this property. —Eihel (talk) 07:35, 13 January 2022 (UTC)
@Eihel How is a machine supposed to infer the difference between the current usage of inception (P571) vs. start time (P580) on Saami National day (Q2334578)? This isn't a matter of "I want all date properties to be deleted". It's a matter of "they actually kind of have to be deleted". Lectrician1 (talk) 12:12, 13 January 2022 (UTC)

@Eihel I think I know what you're talking about and I likely actually agree with using qualifiers on images, but can you share an example? Lectrician1 (talk) 06:55, 13 January 2022 (UTC)
Keep I don't agree with it being "conceptually the same". Ainali (talk) 21:44, 12 January 2022 (UTC)
@Ainali then please explain how it is different. Lectrician1 (talk) 21:45, 12 January 2022 (UTC)
Something that has a start time is expected to be able to have an end time, whereas something that has an inception might exist forever. Ainali (talk) 22:07, 12 January 2022 (UTC)
@Ainali What's something that can exist forever? Lectrician1 (talk) 22:22, 12 January 2022 (UTC)

And how does that make inception different than start time if they both mean when something starts to exist? Lectrician1 (talk) 22:23, 12 January 2022 (UTC)
It's different since start time means that there will be an end time. But, for example, an invention or a theory will never cease to exist. This clarifies the semantic differences between the properties. Ainali (talk) 22:45, 12 January 2022 (UTC)
@Ainali An invention or theory could cease to exist if the knowledge of it by humans ceases. I know that's quite a metaphysical argument, but what I'm trying to get at is, why go through the hassle of maintaining the domain of their semantic usage like by using constraints when they mean the same thing and could just be one property? Lectrician1 (talk) 23:04, 12 January 2022 (UTC)
Because they are not even meant to be the same date. An item could have both properties with different values. Let's say a day for commemoration. The inception would be the date when it was decided, start time when it first happened. Ainali (talk) 08:21, 13 January 2022 (UTC)
@Ainali I think impressing semantics on general properties in domain-specific ways is an incredibly bad idea. How is someone supposed to figure out that the inception (P571) of a commemorative event refers to when it was decided and not the first time it happened? How many commemorative events use that schema? I know that's what Wikidata:WikiProject Events/Models says, but it's not consistently used. The (well, a) semantically-correct way to express that might be significant event (P793) → date of establishment (Q3406134), as well as significant event (P793) → date of establishment (Q3406134). Furthermore, most commemorative events appear to use point in time (P585) for the date it first occurred (which I argue is also unacceptably vague, but, regardless, it's not start time (P580)). Inductiveload (talk) 09:34, 13 January 2022 (UTC)
Well, I find it both useful and helpful. It's easy to figure out as soon as you ask the two different questions, when was it founded and when did it first take place. It's also generic enough to carry over the same meaning in the similar fashion to many domains other than only events. Ainali (talk) 20:41, 23 January 2022 (UTC)
@Ainali So inception (P571) means when the idea came into existence for an item and then start time (P580) means when an event starts. I guess those are separate domains of usage. So would constraining inception (P571) to ideas (which I actually can't find a class for lol) and start time (P580) to time periods be appropriate?

You said that this could carry over to other domains, which is likely to disrupt such constraints. What domains would those be? Lectrician1 (talk) 21:31, 23 January 2022 (UTC)
Not really. The idea likely came into existence a lot earlier. It's not like you come to a big international convention and on the spot comes up with the idea "Perhaps we should have a yearly day of commemoration?" and then everybody votes to approve it. More likely, the idea has been debated and refined much longer. At the inception date, it is rather formalized or decided in some way. How that formalization plays out, might vary (by convention) in different domains. Ainali (talk) 20:05, 24 January 2022 (UTC)
@Ainali I don't think it's possible to have a property that flexible in usage/definition. That could be very problematic and confusing to use for editors. Lectrician1 (talk) 10:19, 25 January 2022 (UTC)
On the contrary, we already do have a property like that, the very one you are proposing to delete. It is already used in this way. Ainali (talk) 20:16, 25 January 2022 (UTC)
@Ainali Actually I'm really confused at the current state of this conversation. Why exactly do you think we can't we merge the properties? We need 1 start date property and right now we have 2. Lectrician1 (talk) 21:14, 25 January 2022 (UTC)
I'm sorry that you are confused and that I have not been able to explain in a clear way that right now we only have one start date property. The other property is for inceptions, which are not the same. But as you can see in this proposal, there are (right now) ten votes for keep, one neutral and no vote for delete, so it seems like most other users can see the difference between the two. Ainali (talk) 21:24, 25 January 2022 (UTC)

Keep I use start time (P580) as a qualifier of inception (P571), expecially for building who where built during many year. Having the same property as a property and a qualifier would be wierd. [10] --Fralambert (talk) 23:36, 12 January 2022 (UTC)

expecially for building who where built during many year

Okay, this is just terrible usage (which is also why it would look weird with 2 of the same statements) and really calls for the implementation of Extended Date/Time Format time intervals, but whatever. You're not going to die if they're merged. Merging them is needed to end the current confusion between and misuse of the properties. Lectrician1 (talk) 01:50, 13 January 2022 (UTC)

This, as you say, is the only way it is possible to give the period something was created, when we don't know the exact date... or when the creation lasted for years (for the construction of a cathedral or a castle), it could be decades... If you have some other solution to indicate it, then, please, explain it... Hsarrazin (talk) 13:53, 13 January 2022 (UTC)

@Hsarrazin I inferred that I don't really care about the current usage. However, I do not think that this usage should be an excuse to not merge the properties. Lectrician1 (talk) 14:35, 13 January 2022 (UTC)

A needed usage should not be an excuse for something that would make a lot of statements impossible... because you think that they should be merged ?

Need is what drives the creation of properties as they are... if you do not propose a satisfying solution, merging those properties is just a denial of this need

the fact that you do not have that specific need is not pertinent here... Hsarrazin (talk) 14:44, 13 January 2022 (UTC)

A needed usage should not be an excuse for something that would make a lot of statements impossible

It won't make anything impossible. You're just going to have start time as both the claim's property and the qualifier's property.

Also, I agree InductiveLoad's suggestion of qualifying the date with earliest date (P1319)/latest date (P1326) rather than start time/end time. So if done, we should not run into the above weirdness anyways. Lectrician1 (talk) 15:28, 13 January 2022 (UTC)

@Hsarrazin is it meaningful to use such a "generic" property (i.e. P580 or P571) to refer specifically to the construction of items (as in, the physical act of putting things together), as opposed to, say planning it, or opening it? What does the inception (P571) of High Speed 2 (Q798868) actually mean? The date someone thought of it? The day someone proposed it? Proposed in it's current form? Named it "HS2"? The day funding was approved? The day funding was released? First spade in the ground? When it was declared "done"? When it was first opened in some way? First opened completely?

The same can go for lots of items: there are often various things you might be able to call an "inception". Companies may be founded one day, but begin trading on another and open in a physical location on another. Events are "incepted" long before they actually happen. And so on and so on.

Perhaps being more specific is simply a matter of qualifying inception (P571) with something like applies to part (P518) (or something else if that's not for processes, maybe object has role (P3831)), or use something specific to "events" that apply to an object such as significant event (P793) → "the process" as below.

Also, WRT when we don't know the exact date. if you don't know the date exactly, would that not be earliest date (P1319)/latest date (P1326) rather than start time (P580)/end time (P582)? Thus avoiding conflating the concepts of an extended event vs uncertainty in the event's timing (though to be fair, I do not clearly see how you handle uncertainty one or both end points of an extended event). Inductiveload (talk) 14:46, 13 January 2022 (UTC)

Surely that can't be right? Who is going to know that start/end qualifiers on the inception of a building refers to the time taken to build it? Surely that would be significant event (P793) → construction (Q385378) qualified with start time (P580)+end time (P582)? And you might have separate statements, e.g. for site preparation (Q29585447) etc. Inductiveload (talk) 08:15, 13 January 2022 (UTC)

Keep. Not the same as “start time”. - PKM (talk) 02:44, 13 January 2022 (UTC)
@PKM Ayaya please explain and don't just vote! If I have a reason to delete, you've got to have a reason to keep. Lectrician1 (talk) 02:47, 13 January 2022 (UTC)
Speedy Keep. I don't know english word Inception, but translate to many languages shows, that is different concept. Typically something was build (P571), and serves as something from-to and then was something else from-to and then ends P576. JAn Dudík (talk) 06:31, 13 January 2022 (UTC)
@JAn Dudík so are you saying inception (P571) and start time (P580) are used together sometimes? Could you share an example of their different usages/definitions on a Wikidata item? Lectrician1 (talk) 06:51, 13 January 2022 (UTC)
Eg. Maria column in Černovice (Q67185128). From and To are primary for qualifiers

Please, take in mind there is not only English label. I am not sure, if I find in Czech correct word which covers both case.. JAn Dudík (talk) 20:20, 13 January 2022 (UTC)

Keep Too useful as a property. My two cents : a siege (Q188055) has mainly start time (P580)/ end time (P582) because it is a "process" in the time. But a city or anything build has inception (P571). But if I were to build again from scratch the dates models, I'd have worked only [date] [qualifyer : start, end, foundation, signature, publication, etc]. Bouzinac ^{💬●✒️●💛} 08:36, 13 January 2022 (UTC)

@Bouzinac eh, technically, anything built by a physical process has a start and end time (just ask the High Speed 2 (Q798868) project manager!), rather than a perfect point in time when it pings into existence. Cities are actually very good examples of something where construction takes a very extended period of time—so good that it's an idiom: Rome wasn't built in a day. London, say, is still under construction nearly 1000 years since its foundation in 47 AD, and, in fact, the period of construction for any city is probably exactly the same as the period that the city existed at all. And again, as above, with the buildings, this seems to be equally well or better represented as significant event (P793) → construction (Q385378) with start time (P580) rather than a single time point. Inductiveload (talk) 09:11, 13 January 2022 (UTC)

Try adding state of use (P5817) = building or structure under construction (Q12377751) to London (Q84), I'm pretty sure you'll raise eyebrows

Bouzinac ^{💬●✒️●💛} 10:03, 13 January 2022 (UTC)

If you lived near a Crossrail station you'd agree! I didn't say it's necessarily useful data to add, but the point is that for a lot of things, a top-level inception (P571) is extremely fuzzy in terms of what meaning it carries: is it the declaration of the city being "a thing"? What if it was a village with the same name and only became a city later? Is it a city charter being signed? The charter being promulgated? Breaking ground? Completion of the first building? The last building? Inductiveload (talk) 10:21, 13 January 2022 (UTC)

As a pretty perfect, if unintentional example, the inception (P571) -> 47CE statement on London (Q84): the referenced site simply says A timber drain of AD 47 beneath the main road is the earliest, securely dated structure yet known from Londinium. It doesn't necessarily mean anything actually happened in 47CE to "incept" a city except that someone built a drain under a road. Inductiveload (talk) 10:43, 13 January 2022 (UTC)

Keep while I think the difference between the two properties can be made even clearer and actually defined I don't think such a discussion should be driven by the idea of deleting one of them. Abbe98 (talk) 10:56, 13 January 2022 (UTC)
@Abbe98

clearer and actually defined

How could we make them actually defined?

I don't think such a discussion should be driven by the idea of deleting one of them

In reality I'm proposing to merge them. Lectrician1 (talk) 12:16, 13 January 2022 (UTC)
Keep continued. This was discussed in Project Chat back in 2018. As User:Máté said then "I think the idea behind not making P571 qualifier only was that it is better suited for events (not recurring ones, but single events, or instances of recurring events) and event-like items than P580". That is how I use these properties, applying "inception" to things (including events, buildings, creative works) that are created and "start time" to temporal concepts like Bronze Age (Q11761), Jacobean era (Q2559155), or 2010 Tour de France (Q217287). - PKM (talk) 21:48, 13 January 2022 (UTC)
That sounds like there could also some overlap with point in time (P585): is there a defined distinction between "point in time" and "inception" for an event, say? Inductiveload (talk) 22:43, 13 January 2022 (UTC)

@PKM All of the examples you gave were things that have a date when they started - whether they be buildings or historical eras. The definition between the two properties has no difference.

I understand that it might look weird to have inception (P571) as a qualifier because of its name in comparison with it's opposite end time (P582). But, I'm thinking about merging inception into start time (P580) so the new property would have the name "start time" and would actually look appropriate as a property that can be used as a qualifier and a main property. Lectrician1 (talk) 23:45, 13 January 2022 (UTC)

Keep true this is close but it's not exactly the same (as said by previous voters), the property could be better documented to explain the difference but the merge is not a good solution. Cheers, VIGNERON (talk) 13:07, 15 January 2022 (UTC)
@VIGNERON The properties not being different is central to my argument for deleting one of them. Can you please thoroughly explain how they are different? Lectrician1 (talk) 18:25, 15 January 2022 (UTC)
@Lectrician1: you are reversing the charge of proof. It's up to you to prove that they are exactly the same and that the merge is possible. For instance, how do you plan to deal with the 17000+ items with both property (as direct property, there is some more as qualifiers) ; there is indeed most likely a lot of cleaning to do (for that part, I'm totally in favour), but can they all be merged? I feel they can't but again, it's up to you that there is no exception and that they are indeed tje same. Cheers, VIGNERON (talk) 18:56, 15 January 2022 (UTC)
@VIGNERON They are exactly the same because their descriptions describe the same thing and the properties are always used to describe when something starts.

How they will be merged is a QuickStatements job will move all of the values on inception (P571) to start time (P580) for both mainsnak claims and qualifier claims. Then, inception (P571)'s aliases will be copied to start time (P580). Finally, inception (P571) will be deleted. Lectrician1 (talk) 19:11, 15 January 2022 (UTC)
@Lectrician1: still not convinced, I think there are problems that need fixing around P571 but you still don't address clearly basic questions about the proposed merge (see all the comments above). Cheers, VIGNERON (talk) 20:13, 15 January 2022 (UTC)
@VIGNERON I'm not sure how those things that people cited are problems... The properties mean the same thing so if they were merged, technically nothing would change conceptually...

What have I not a addressed above? Lectrician1 (talk) 20:19, 15 January 2022 (UTC)

Neutral I have to say most of the arguments in favour of keeping this property are not convincing. I think the Saami National day (Q2334578) example is the only compelling point, highlighting the difference between the time something was conceptualised and the time it was realised. However, I'm not convinced this matches with actual usage or the property descriptions/modelling. SilentSpike (talk) 22:20, 15 January 2022 (UTC)

Also just to note, inception (P571) is currently modelled as a subproperty of (P1647) start time (P580) - suggesting it is the same thing in a specific context (which as far as I can tell nobody can explain). SilentSpike (talk) 22:31, 15 January 2022 (UTC)

Keep Think as a car: inception (P571) is for the date of manufacturing, while start time (P580) is the date it starts to run. Also, the property is currently used in templates (namely infoboxes). --Amitie 10g (talk) 11:41, 3 February 2022 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P3188

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

There is consensus that this property no longer has any value and so will be deleted shortly. — Martin (MSGJ · talk) 06:54, 23 January 2022 (UTC)

P3188 (P3188): (delete | history | links | entity usage | logs)

This property is obsolete. When created we assumed that Nobelprize.org had a stable web which is not the case. As Nobelprize has an API were every Nobelprize winner is identified with an unique persistant number a new property Nobel Laureate API ID (P8024) has been created. This new property Nobel Laureate API ID (P8024) is now also used by Template:Nobelprize (Q91652187) as we now have a new linking model see T248939 and T251055 —Salgo60 (talk) 04:38, 30 April 2020 (UTC)

Delete the new property looks like it has been applied at least as widely as the old one, so no harm in deleting now. ArthurPSmith (talk) 20:42, 30 April 2020 (UTC)
- yes we have everyone in the new property. Its a very small dataset - Salgo60 (talk) 16:33, 1 May 2020 (UTC)
~~Keep~~ the new number does not lead to a landing page with a biography. --RAN (talk) 07:47, 2 May 2020 (UTC)
Suggest to ask WikiProject Sweden (Q11509296) members: @Josve05a, Reckless182, Newroderick895, Ipigott, Yakikaki:@AddyFBG, Fred J, Finnish Gas, Chiswick Chap, Johan Elisson: --Liuxinyu970226 (talk) 23:15, 2 May 2020 (UTC)
- @Richard Arthur Norton (1958- ): I am in a dialogue with the Nobelprize people (Hans Mehlin) and we agree of using the new ID Nobel Laureate API ID (P8024) and the old one is not useful... please explain what you want and were you still can use the P3188 (P3188), list new ID, category in en:Wikipedia using Nobel Laureate API ID (P8024) see en:Category:Nobelprize_template_using_Wikidata_property_P8024, task pushing this to more language versions see T251055 - Salgo60 (talk) 09:32, 6 May 2020 (UTC)
Delete I check some winner of nobel price from recent years and decades ago and the landing page look the same. only In ones who won multiple time, the page is different for example look Marie Curie (Q7186). - yona b (talk) 11:29, 5 May 2020 (UTC)

Why is it that when I click on the link at Nobel_prize_ID I get taken to a biography, and when I click on the new links I get an error message? This is the new link we are using for Marie Curie: Marie Curie This is the the old link Marie Curie. All three examples at Nobel Laureate API ID give error messages. What is going on? We should keep the old system in place until the new system is stable. --RAN (talk) 15:13, 6 May 2020 (UTC)

@Richard Arthur Norton (1958- ): nobelprize.org had a link problem 2020-may-07 09:16 - 2020-may-07 13:22 see T252093 - Salgo60 (talk) 09:36, 13 May 2020 (UTC)

The problem appears to be fixed now. --RAN (talk) 05:04, 9 May 2020 (UTC)

nobelprize.org had a link problem 2020-may-07 09:16 - 2020-may-07 13:22 see T252093 - Salgo60 (talk) 10:43, 17 May 2020 (UTC)

Delete: sounds sensible. Nomen ad hoc (talk) 18:06, 10 May 2020 (UTC).
Keep: decent coverage (100%?), seems to be stable (since 4 years), used by other WMF sites, and the other id redirects there too. --- Jura 20:45, 13 May 2020 (UTC)

Comment I guess every third Nobelprize link has en:Link rot in en:Wikipedia and P3188 (P3188) has been impossible to maintain as it has changed more times when Nobelprize.org has done a new webdesign. Now Nobelprize.org takes responsibility for maintain this and we just need to store the unique number in Wikidata - Salgo60 (talk) 10:51, 17 May 2020 (UTC)

We already do store it. There is no need to delete historic information. This is not Wikipedia. --- Jura 11:20, 17 May 2020 (UTC)

Comment@Jura:please explain. The IT people at Nobelprize.org also see the chaos with linking the old web and agree of this new approach

P3188 (P3188) no one has the last year tried to maintain it
P3188 (P3188) has bad data and cant be trusted
having more properties with different quality just adds confusion
P3188 (P3188) was created to make linking the Nobelprize.org chaos easier but failed. What is the historic value of that..?

- Salgo60 (talk) 01:07, 18 May 2020 (UTC)

Wikidata isn't here for the IT people at Nobelprize.org. Identifiers here can be used outside the source database. If you find a database problematic, maybe you shouldn't propose storing (additional) identifiers for it. --- Jura 10:29, 18 May 2020 (UTC)

@Jura1: the discussion is about if we can delete P3188 (P3188) or not. I see no arguments why we shouldn't delete it

Just to update you on the background:

Wikipedia has a lot of en:Linkrot to Nobelprize.org as the old approach with a relative path stored in P3188 (P3188) is not stable and has shown not working (I have seen no example of someone using it because of the bad quality)
1. Nobelprize.org has had the anti-pattern when they redesigned the web or part of the web they changed urls and had no redirects --> Wikipedia got en:Linkrot and we couldn't maintain P3188 (P3188)
Nobelprize.org created an API where every winner got an unique persistent id eg. en:Albert_Einstein has 26
I have before raised this problem with the Nobelprize.org people that Wikipedia thinks Nobelprize.org is not stable linking (see blogpost 2019-feb) Wikipedia gets a lot of link root
Mar 31 2020 see Task T248939 the following request was sent to the Nobel people if they could help Wikipedia making the linking more stable
answer Nobelprize.com Apr 15 2020
Wed, Apr 29, 11:42 AM the new solution was implemented using Nobel Laureate API ID (P8024)

P3188 (P3188) is and has been obsolete the last years so I recommend to delete it if no one can explain who is using it

- 18:37, 21 May 2020 (UTC)

I think you explained your webdirectory approach in detail. There are various ways of maintaining such things in an automated way, without alienating all users and requiring them to use a redirect service. --- Jura 20:00, 21 May 2020 (UTC)

@Jura: "redirect service"?!=?! Nobelprize.org tells us link us using the unique number we have dedicated every prizewinner as this is the only way we can manage the en:Linkrot. Step 1 is always to have persistently identifiers and now we have that

@Jura: we are discussing if P3188 (P3188) should be deleted or not do you Jura see any usage of this property that has not been usable the last years? Please gives us user cases when P3188 (P3188) is used? - Salgo60 (talk) 06:51, 22 May 2020 (UTC)

Did a fast check to see the quality of the old property P3188 (P3188) list compared with the new. Can be used if someone would like to maintain P3188 (P3188), less problem than I thought but now we have an easy way to find what the "correct link is" and with the new approach Nobelprize.org has "one" landing page for every Nobelprize winner also if they have received more prizes...

http 404: 13 times
Missing P3188 (P3188): 24 objects
The whole list

- Salgo60 (talk) 10:22, 22 May 2020 (UTC)

A little support Delete, as I'm confused that what "redirect service" that @Jura1: said is. --Liuxinyu970226 (talk) 22:39, 3 June 2020 (UTC)

I guess the redirect mentioned is that Albert Einstein (Q937) with Nobel Laureate API ID (P8024)

has the following pattern with an unique number 26 --> www.nobelprize.org/laureate/26 that gets an redirect to www.nobelprize.org/prizes/physics/1921/einstein/facts/
if we look at the usage of P3188 (P3188) we can see that the Nobelprize people also has created redirects when they changed the pages location. The problem is that this was not good maintained at the Noibelprize.org. As they now has an API with unique numbers for every Nobelprize winner I guess this redirects will be easier to maintain for them and much easier for Wikidata as our link will be stable

- Salgo60 (talk) 09:35, 4 June 2020 (UTC)

Delete I see no value in keeping this property. If we go ahead with deletion I suggest we warn wmfprojects who uses it, they should some time to change to the new ID before deletion IMO. Maybe we can put a redirect to this discussion on the deleted page or indicate in some way why it was deleted. – The preceding unsigned comment was added by So9q (talk • contribs) at 12:59, 2 February 2021 (UTC).
Delete The property as described does not work with the Nobel Prize's present website (eg, medicine/laureates/1990/thomas should be medicine/1990/thomas/. It's not necessarily difficult to change all instances on wikidata, but such maintenance would have to be done if we keep the category, and at that point, it would almost certainly be better to use the more-stable API property. Mathmitch7 (talk) 22:50, 15 April 2021 (UTC)
Keep Not used in Template:Nobelprize at the English Wikipedia but referenced at its documentation. Please discuss at the Village Pump first. --Amitie 10g (talk) 00:03, 30 May 2021 (UTC)
No need to, just feel free to submit an {{Edit request}} on enwiki to remove so. Liuxinyu970226 (talk) 07:52, 1 November 2021 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Removing statements now — Martin (MSGJ · talk) 12:29, 10 February 2022 (UTC)

Filmstarts title ID (P8531)

Initial discussion

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Not deleted, no willingness to delete except that of the proposer. Pamputt (talk) 10:56, 22 October 2020 (UTC)

Redundant (see creation discussion): the same identifiers is used on several websites of the publisher and we already have a property for it (Property:P1265). Unfortunatly the proposer omitted mentioning this when the proposal was first made. --- Jura 08:43, 17 August 2020 (UTC)

You and 99of9 were the only ones opposed to the creation of this property. Eihel responded on the creation proposal page to all your arguments. This property is also similar to others we already have such as AdoroCinema film ID (P7777). Pamputt (talk) 08:50, 17 August 2020 (UTC)

KeepThe "proposer", It's me ! You might have the courage of your convictions: when you write about a contributor, you notify him. It's the least of politeness, because what you write is completely false and you know it very well. The deletion procedure is clearly explained in the header of this page. I don't understand your eagerness to suppress these properties. The examples and opinions show that the identifiers of the proposition are not always the same. The proponent (me) has clearly explained the gain in having this property and not citing other properties on the proposal is not a valid criterion. Jura1's opposition has already been rejected twice, here and then again in the debate. Therefore, like the last time, I will immediately request the early closure (without waiting 7 days) of this deletion request, because it has no serious basis. Thanks for the contributors' waste of time. —Eihel (talk) 14:30, 17 August 2020 (UTC)
Not mentioning this was previously listed for deletion by the same person seems bad faith to me. Keep if only on those grounds. BrokenSegue (talk) 14:39, 17 August 2020 (UTC)
Neutral Maybe another datatype would be better? --Liuxinyu970226 (talk) 14:29, 23 August 2020 (UTC)
Keep Description of Filmstarts (Q1415290) is "German movie website" (filmstarts.de) and so it is. I don't know if the identifier is equal to Allocine-ID, but the content is not, e.g. for Cloud Whispers (Q52777610) there is http://www.filmstarts.de/kritiken/254579/kritik.html and http://www.filmstarts.de/kritiken/254579/pressespiegel/ . This is absolutely NOT redundant. -- MovieFex (talk) 09:19, 1 September 2020 (UTC)
- It's frequent that the same identifier is shared by several sites. It's even the purpose of identifiers. --- Jura 07:17, 15 October 2020 (UTC)

The sites are different. -- MovieFex (talk) 21:20, 16 October 2020 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Second discussion (?)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Kept No consensus to delete this. Thanks. Mike Peel (talk) 21:07, 4 February 2022 (UTC)

@Pamputt, Jura1: Jura1 reverted my archive action because "closed by involved admin", is this meaning that we should re-open the deletion discussions here? --Liuxinyu970226 (talk) 10:42, 23 October 2020 (UTC)

Delete Unless if @pamputt, eihel: can explain why this is so-called "useful". --117.136.1.51 03:02, 27 October 2020 (UTC)

Keep Hello Liuxinyu970226 , Jura1 put up the same resistance for this closing. The community will be monopolized by trivia. I think I have to give a slightly stronger reply. …for 10 Seconds (Q169103), 177818 is the identifier for AlloCiné film ID (P1265) and 137934 is the identifier for filmstarts. There is no identifier for this movie for AdoroCinema film ID (P7777) and the contents are different. So the motivation of the applicant is still incorrect. We have all been clear and Pamputt is also doing what makes sense to her. This property was created because I contradicted Jura1's opposition in the proposal. If this contributor gives the same motivation here, the result is the same. Should an admin also archive closed debates? No, if Jura1 has a valid request, I am ready to discuss it, but we must follow the opinion of the community. If Pamputt creates a property because she considers the opposition to the creation to be unreasonable, I have no problem with closing a PFD if there are completely identical reasons and with stronger reasons if she's an admin. Jura1, you can focus on your own proposals… by putting the right datatype for example . Cordially. —Eihel (talk) 13:26, 27 October 2020 (UTC)

Delete Thanks for re-opening this: the administrator (who created it before the usual seven day wait) is misusing their admin role by closing the deletion request.
Besides, as noted just above, the identifier is identical to the one used in another property and the numbers show this eventually leads to massive duplication.--- Jura 19:33, 2 December 2020 (UTC)

@Liuxinyu970226: still only Jura1 (and one IP) opposes the creation of this property. Can we close this discussion now or should we wait longer (I do not expect more discussion about this, especially after the Eihel's reply). Pamputt (talk) 09:12, 4 January 2021 (UTC)

Comment: Out of 124 usages of the property, there are 41 identical to Allociné ID, 3 different, 80 without Allociné ID (and 52966 usages of Allociné ID without Filmstarts ID). --Mormegil (talk) 13:01, 4 January 2021 (UTC)
- So no conflicting uses (as it's the same identifier). It was just created when nominated here. We also had P9099 (P9099) created by the same admin (Wikidata:Property proposal/Baudenkmal-ID Niedersachsen) as some ids from Monument Atlas Lower Saxony Objekt-ID (P7900) couldn't be found in there. Now it's listed for deletion at Wikidata:Properties_for_deletion#Cultural_heritage_ID_in_Lower_Saxony_(P9099). --- Jura 07:04, 9 February 2021 (UTC)
@Jura1: If there are no conflicting uses, that does not mean that there are the same identifiers, on the contrary. When you add "this is the same identifier", I wonder if you are reading the comments correctly. Or is it preventing everyone from contributing serenely, or taking up time? It has not just been created, it is you who put this property here just after its creation more than five months ago, it is not by chance. The creation followed a normal process following the responses to your opposition during the proposal. The creation of this property was not prevented in any way, but you pursue your idea as if you have blinders. I gave examples, Mormegil gave examples and data of the differences. It's the first time I've seen someone interpret the numbers on WD. I add another identifier different from Allociné. You are not being fair. For the other properties, this is not the place to be discussed. Your anti-collaborative attitude is not appreciated at all and I'm not the only one to think that. —Eihel (talk) 12:14, 9 February 2021 (UTC)

@Jura1, Liuxinyu970226: can we consider the dicussions are over? Pamputt (talk) 06:45, 27 January 2021 (UTC)

@Pamputt: I think what Jura1 think is, this can be closed, but not by you, nor any administrators that are directly made their efforts here, it must therefore be closed by non-involved administrators. --Liuxinyu970226 (talk) 04:03, 7 February 2021 (UTC)

There are olders ones still open. In the meantime, there is a similar one below: Wikidata:Properties_for_deletion#Cultural_heritage_ID_in_Lower_Saxony_(P9099) --- Jura 07:04, 9 February 2021 (UTC)

@Jura1: could we consider this discussion as over? Pamputt (talk) 08:39, 21 July 2021 (UTC)

Speedy Keep Since the nominator didn't add anything other than repeating the initial one above. --Liuxinyu970226 (talk) 11:09, 11 September 2021 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P460

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Kept per consensus here. There are open issues, but they would be better dealt with on the talk page or through an RfC. Thanks. Mike Peel (talk) 21:02, 4 February 2022 (UTC)

Subjective. Used so arbitrarily that it is better not to have it. E4024 (talk) 00:00, 13 September 2021 (UTC)

Keep Subjective, but sometimes useful. Eg - some hamlet have item as settlement and second as street. According to some users are settlement and street different concepst which cannot be merged, accordin some others are both the same. And whic other property use for Q3222766#P460? JAn Dudík (talk) 08:33, 13 September 2021 (UTC)

"Sometimes useful" is a weak argument. "Many times" it is harmful. For example there is a very passionate effort to claim personal names in different languages to be "same as". If John is same (sorry "said to be the same") with Jean, then we can simply use the same logic to say English is said to be the same with French! (BTW we can add the Turkish name Can to this couple, as it is pronounced the same way as John, although it means "soul", "life". :) In the same line with the parenthesis, people tend to claim a "sameness" among names which are written in a similar way. In Turkish, my native language, we have the name Anıl, which means "be remembered, be recalled"; a wish that parents make when they name their newborn, so that s/he would be remembered -as a good person- after her/his life adventure in this world. It is not "same" nor "said to be same as" the name Anil which belongs to another culture and certainly has some meaning that I ignore. I simply doubt it may mean "be remembered", does it? Is there any user who knows the meaning of the name "Anil" in its native language? I am also against the other property that claims "name without diacritical marks" etc nonsense. "Anil" does not have any such relation of that kind with "Anıl". BTW Anıl does not have any diacritical mark, either... Look, classifying things, trying to make a databank means separating similar things, not putting different things into the same basket. "Similar" means "different". I hope I am clear enough. --E4024 (talk) 13:26, 13 September 2021 (UTC)

Keep but perhaps it should have a constraint requiring a source? I agree with E4024 that it seems to be overused right now for things that really are not the same concept. But for example sometimes we have two different items that may be for the same person, place, (or species as with Brontosaurus (Q3222766)), but maybe not, and different sources disagree. In such a case this property really is needed. ArthurPSmith (talk) 17:03, 13 September 2021 (UTC)
Comment Maybe it needs a better label. 'is "the same" as' here means that it's different. --- Jura 11:39, 14 September 2021 (UTC)

Comment the synonym list for this makes no sense to me. If this property means "this item is said to be the same as that item, but it's uncertain or disputed", then it is certainly not a property that means "equivalent to", "similar to" or "the same as". In fact, it's the exact opposite: if it's truly "equivalent", then it's not "said to be the same". It is the same. What's actually happening is that this one property is smashing together multiple concepts:

These two items are wrongly "sometimes" (by who? citation needed!) mistaken or conflated with each other. This is a hard one to separate, because whether you're mistaking something for something else or conflating it really depends on whether the source "saying it's the same" knows the items are separate, so we can't easily tell from this end. Possible examples (though arguable, as I say):
- "Conflation": open-source software (Q1130645) and free software (Q341);
- "Mistaken": rice porridge (Q35661296) and rice pudding (Q19029)
In "some contexts" (e.g. according to certain people/source) no distinction is drawn between them: God in Islam (Q2095353) and God (Q190)
The two items are analogous items at different times (a historical equivalent): Parliament of Great Britain (Q2739604) and Parliament of the United Kingdom (Q11010)
One item is a subclass of another that only applies in "some domain": village in Turkey (Q1529096) and village (Q532)
One item is a "local" definition of the other: e.g. the time zones (Central European Summer Time (Q207020) and UTC+02:00 (Q6723) are the same but GMT+2 isn't a class, so CEST can't be a subclass)
One item is a part of or overlaps with to the other: Greater Budapest (Q1213898) and Budapest (Q1781)
The two items are actually the same thing and should to be merged: Q19712921 and alkali metal (Q19557)
The two items are equivalent in some technical sense:
- Mathematical/logical (e.g. Legendre's constant (Q73026) and 1 (Q199))
  - These can also be possibly equivalent, but not proved: P (Q846354) and NP (Q628036) (these two don't use P460).
- Functional (e.g. sucrose (Q4027534) and sugar (Q11002))
The two items are homographs in the same language: Hinterland (Q2478477) and hinterland (Q4354)
The two items are cognates in different languages: Simeón (Q27179185) and Simeon (Q1557) (i.e. most of the names)
The two items are near-homographs in the same language that may be confused/mis-spelled mainly due to orthographic similarity rather than semantic: Brahms (Q536246) and Brahm (Q897273)
The two item are "false friends" in different languages (i.e. they're homographs or near-homographs that are not cognates): Fogh (Q20758703) and Fog (Q449415)

And some are just flat out wrong:

biography of Salvador Dalí (Q33134633) and Salvador Dalí (Q5577)

Much of the time, it's hard to say exactly which category they fall into. So, basically, it's an enormous mess of ~270k statements and there's no way to really tell what any given said to be the same as (P460) statement means. I'd say "migrate to correct statements then delete this one" would be the right course of action, but I can't really see that happening. Examples of correct statements might be "cognate of", "mathematically equivalent to", "functionally equivalent to", "homograph of", etc.

Proposal: Since stripping this property is unlikely to be practical given the huge usage, perhaps assigning a mandatory qualifier constraint and adding a set of qualifiers to establish what the "sameness" being claimed actually is. For example:

Legendre's constant (Q73026) and 1 (Q199): said to be the same as (P460), qualified by object has role (P3831) → "mathematical equivalence".
Simeón (Q27179185) and Simeon (Q1557): said to be the same as (P460), qualified by object has role (P3831) → "cognate".

And all these roles must be subclasses of, I guess, binary relation (Q130901).

Advantage of this: easy to query, semantically useful and one item can have many P460's with different qualfiers (e.g. Jan (Q12173670) is a homograph of Jan (Q18220903), a cognate of Ján (Q6319579) and a mis-spelling of Jann (Q19968009)) Inductiveload (talk) 21:23, 21 September 2021 (UTC)

See this for the meaning of the Indian given name Anil and this for the Turkish given name Anıl. (Wind vs be remembered.) --E4024 (talk) 12:32, 25 September 2021 (UTC)

I think you've hit the nail on the head here and if we were thinking big we would go with more limited scope sub-properties for all of these cases. I've said before elsewhere, but properties with a conditional meaning (interpreted differently depending on subject) are a "bad data smell" to me. SilentSpike (talk) 13:42, 24 November 2021 (UTC)

My understanding of this property is that it's for two items, for which it is a matter of dispute whether or not the respective topic are actually the same thing as each other. The given sources are those which say they're the same. (If everyone agreed they were the same, it wouldn't be a separate item, it would just have an alias.) The "said to be" is there because people seem to prefer (?) avoiding giving disputed statements without qualifying it in the property name, when possible. Unfortunately, the property is currently misused in some areas. I say Keep, clarify intended use, and clean up. --Yair rand (talk) 06:05, 1 October 2021 (UTC)
@Yair rand when you say clean up, what exactly does that entail? Keeping track of which of over 1/4 million instances actually do refer to the concept of "have disputed equivalence", rather than one of a large palette of other conflated relationships, is going to be rather difficult, no? The only way I can think of is to start adding qualifiers to items which have been verified to be valid. At which point we might as well allow other qualifiers to capture the alternative senses. Inductiveload (talk) 19:48, 5 October 2021 (UTC)
Keep per above Germartin1 (talk) 20:48, 2 October 2021 (UTC)
keep immediatly —Eihel (talk) 17:54, 5 October 2021 (UTC)

Keep This property's use is to document entities that are often thoughtfully mixed up in society. This is culturally significant and therefore appropriate to document. If you want to stop arbitrary usage (which I haven't seen much of really) I'd recommend requiring a reference. Lectrician1 (talk) 00:10, 7 January 2022 (UTC)

@Lectrician1 you haven't addressed the issue that this is used for far more than just things "thoughtfully mixed up in society" (which I do not deny is a useful piece of data). As it stands, the semantic content is of a given said to be the same as (P460) statement is minimal, because you cannot tell what the statement actually is supposed to mean. Yes, a human can usually intuit it, but that's not what Wikidata is for. Inductiveload (talk) 10:13, 13 January 2022 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

MovieMeter film ID (P1970)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Kept There is no consensus to delete this property. Thanks. Mike Peel (talk) 21:03, 4 February 2022 (UTC)

In 2015 this property was proposed based on the idea that the website is similar to Rotten Tomatoes. That is not the case at all. Rotten Tomatoes has more authority and more impact than MovieMeter, for which not a single source can be found to establish any kind of notability. Hiro (talk) 17:01, 23 April 2021 (UTC)

how would deleting this property improve wikidata now that it already exists? is it being used to spam? BrokenSegue (talk) 00:27, 24 April 2021 (UTC)

The real question is how this property improves Wikidata. It was created under the false pretense that the website is similar to Rotten Tomatoes. It is not. We are just pumping data around by having this property. We already have the IMDb-properties, why have another one that links to a much smaller website that has the exact same information but targeted at a much smaller audience of which the review scores are insignificant and irrelevant. Please don't tell me that the only counterargument is that the website exists. Hiro (talk) 07:31, 28 April 2021 (UTC)

we have lots of properties that cover the same ground. BrokenSegue (talk) 00:38, 8 May 2021 (UTC)

My point is not that IMDb should be the only source of movie related information. The problem that I have with the MovieMeter-properties is that MovieMeter is not as significant. The counterarguments that the website exists and that the property already exists, don't hold up to scrutiny:

A website that exists, might not add any value to Wikidata or other Wikimedia projects. In the header above I linked to another website that 'exists' but holds no significance by any standard. Whether a website does add value, should be discussed in the property proposal. When the two properties were proposed in 2015, the only argument was "similar to Rotten Tomatoes". I challenge that argument as MovieMeter is not similar to Rotten Tomatoes. Sure, both sites are focused on movies and user generated content and reviews, but that's it. There is no similarity in significance, no similarity in usage.
No property should exist forever, just for the sake of it. Hence the existence of this very page. If a property does not add any value, it should be deleted. Deleting anything without value, adds to the overall value.

Hiro (talk) 16:56, 24 May 2021 (UTC)

Please give a reason. —198.60.5.253 21:00, 2 May 2021 (UTC)

Please read everything I wrote. There are your reasons. Hiro (talk) 08:01, 6 May 2021 (UTC)

Keep for two reasons. First, the website provides information in Dutch; there are still a lot of people in the Netherlands (the target audience of the site) for whom this is an important factor. Second, it provides information that is not available on IMDb or Rotten Tomatoes, like content rating icons (Kijkwijzer) and availability on Dutch streaming platforms. --bdijkstra (overleg) 16:02, 27 October 2021 (UTC)

Keep We have dozens of identifiers for different sites that have a database of movies (see Template:Movie properties). The whole purpose of Wikidata is linking together different databases of information that are about the same item and might all contain different information (like what Bdijkstra mentions). This property is currently used on over 75.000 movies. I see no reason for deleting the property. Husky (talk) 23:42, 14 January 2022 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P1969

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Deleting property — Martin (MSGJ · talk) 15:46, 9 February 2022 (UTC)

P1969 (P1969): (delete | history | links | entity usage | logs)

In 2015 this property was proposed based on the idea that the website is similar to Rotten Tomatoes. That is not the case at all. Rotten Tomatoes has more authority and more impact than MovieMeter, for which not a single source can be found to establish any kind of notability. Hiro (talk) 17:01, 23 April 2021 (UTC)

I don't know about the original proposal but it's used over 17,000 times and the site seems to be real (and in Dutch). I see you're proposing the NL wikipedia page nl:MovieMeter for deletion, but Wikidata criteria are a little different from Wikipedia's. ArthurPSmith (talk) 17:22, 23 April 2021 (UTC)

The website is real, yes. But so is this website. The property creation criteria say nothing about a condition or limitations, but I presume that there needs to be more about a website than just its existance before a property can be based on it? Hiro (talk) 17:39, 23 April 2021 (UTC)

Is the information on the website reliable or not? Mbch331 (talk) 08:22, 24 April 2021 (UTC)

I don't know. It seems to be copied from IMDb, so, sure. Is that all it takes? Copy information from one database to start another one and have it made a property? Hiro (talk) 10:36, 24 April 2021 (UTC)

Note that the original IDs are no longer advertised by the site, all director URLs have become HTTP redirects to person-pages that correspond to MovieMeter person ID (P9463). (For some people there is now a "Wikicode" field with a longer ID that is also a redirect.) I have gathered the new person-IDs and imported them into Wikidata. --bdijkstra (overleg) 16:12, 28 October 2021 (UTC)

Thank you bdijkstra. Can you confirm that no information will be lost if this property is deleted? — Martin (MSGJ · talk) 10:17, 9 February 2022 (UTC)

Yes, assuming that this query is correct (list items with a director-ID but without a person-ID) and that the query returns 0 records right before the property is deleted. bdijkstra (overleg) 10:32, 9 February 2022 (UTC)

Copy that, I think we can safely delete this property then — Martin (MSGJ · talk) 12:41, 9 February 2022 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Post close discussion

Comment Property still being used by nl:Sjabloon:Infobox filmproducent and nl:Sjabloon:Infobox filmregisseur — Martin (MSGJ · talk) 12:44, 9 February 2022 (UTC)

As a fall-back, yes. I've cleaned that up now. --bdijkstra (overleg) 13:12, 9 February 2022 (UTC)

Thanks. Removing statements now — Martin (MSGJ · talk) 15:47, 9 February 2022 (UTC)

I'm quite mad that I'm only seeing this now. Yes, these became redirects but it is still useful to keep this property and its values. At one point these IDs existed, and they could be used in the future to resolve these IDs if ever needed. There is no use in deleting them, though. Máté (talk) 18:01, 9 February 2022 (UTC)

Resolve how? Can you give an example scenario? bdijkstra (overleg) 23:43, 9 February 2022 (UTC)

Generally speaking, it's never a good idea to remove data that once held true. You might have a table somewhere which identifies directors by this ID. If I want to get the new IDs (or any other property available here), Wikidata is a great resource to query and join them. Máté (talk) 06:13, 10 February 2022 (UTC)

Sorry you didn't see the discussion before it got closed. A tag was placed on the property talk as required. I'm not sure what I can do to help now, as most of these statements have been removed. Of course I would be happy to revert those if consensus can be found that these identifiers are useful. I don't think a proposal at Wikidata:Property proposal would get very far if this was a new proposal. — Martin (MSGJ · talk) 12:16, 10 February 2022 (UTC)

Máté has a point here. After some digging I found Wikidata:Requests for comment/Handling of stored IDs after they've been deleted or redirected in the external database and Wikidata talk:Identifiers#Typical repair situations. On the other hand, the external website can still be used to convert director ID's to person ID's. bdijkstra (overleg) 12:35, 10 February 2022 (UTC)

P9416 (P9416)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Deleting property — Martin (MSGJ · talk) 12:57, 11 February 2022 (UTC)

P9416 (P9416): (delete | history | links | entity usage | logs)

ScoreStorybook is a side project of Inforegister (Inforegister ID (P9321) recently created as well). Identifiers for the latter for the most part seem to be same and ScoreStorybook entries apparently can be linked using existing Business Registry code (Estonia) (P6518) identifiers if necessary (e.g. [11] for Q31273705). So ScoreStorybook identifier seems redudant to the latter two identifiers. Moreover ScoreStorybook is a commercial project that relies on heavy advertising, and so the sole reason to request creation of this property was most likely the improvment of business goals by means of manipulating Google results via Wikidata metadata. @UWashPrincipalCataloger, Marie Rosin: —2001:7D0:81F7:B580:2C7B:6201:436A:B2C0 08:40, 6 April 2021 (UTC)

Delete Yes, at least all the examples have the same ID as for Business Registry code (Estonia) (P6518) and could be handled with a 3rd party formatter URL if wanted. ArthurPSmith (talk) 14:00, 6 April 2021 (UTC)
Delete unused (and redundant it seems). --- Jura 19:50, 10 February 2022 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Familypedia person ID (P4193)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

No consensus to delete at this time — Martin (MSGJ · talk) 12:55, 11 February 2022 (UTC)

This property is redundant and should be replaced by Fandom article ID (P6262) Trade (talk) 16:28, 22 March 2020 (UTC)

Delete Just once parameters migrations are done. --Liuxinyu970226 (talk) 11:22, 24 March 2020 (UTC)

All identifiers could be replaced by described at URL (P973), but the as for any other identifier, it can helpful to have a distinct property for this. It doesn't really matter if the database/website is currently hosted at Wikia or elsewhere. In any case, don't use Fandom article ID (P6262) or described at URL (P973) in addition to Familypedia person ID (P4193). --- Jura 19:46, 26 March 2020 (UTC)

Delete Per nomination. The Property is very redundant. Current uses should be migrated. –MJL ‐Tauk‐^☖ 07:56, 16 November 2020 (UTC)

Comment In use at Template:Dump at the English Wikipedia. Please discuss at the Village Pump first. --Amitie 10g (talk) 00:03, 30 May 2021 (UTC)

Keep per above. --- Jura 08:22, 22 September 2021 (UTC)
Keep per above. No need to delete the property, as Jura explained it is not "redundant" it is simply specific. --Hannes Röst (talk) 14:58, 13 January 2022 (UTC)
Keep per Jura1 --Gymnicus (talk) 18:06, 8 February 2022 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P2679

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

No consensus to delete. Please continue discussion on Property talk:P2679 or renominate with more concrete proposal for replacement. — Martin (MSGJ · talk) 10:14, 9 February 2022 (UTC)

Duplicate of front and back matter (P8570)+author (P50) and the current property does not handle books with multiple forewords. GZWDer (talk) 19:24, 18 July 2021 (UTC)

Keep premature. I disagree with this proposed deletion. Firstly the suggested alternative is not an alternative to noting the author of a preface or foreword. These authors are regularly noted on the title page of a work, so have a level of billing that should be clearly annunciated. I do see that their is potential for use of contributor to the creative work or subject (P767) as a replacement *if* we then qualify the contributor with the aspect of their contribution, be it one of any number of forewords, of part of the body of the work. I don't see how the alternate proposed handles the situation that is noted as a problem. in fact I see that it could make it worse.

I will also note that this issue has not been raised with Wikidata:WikiProject Books for their discussion, nor even alerted following its nomination. Circumventing projects is problematic as most of us will be looking to the project for guidance and the norms. — billinghurst sDrewth 12:09, 19 July 2021 (UTC)

Comment Deletion right now might be a bit premature, but it does seem to me that this should probably be more correctly captured as:

author (P50) → the author's item (or should it be contributor to the creative work or subject (P767), I guess not creator (P170))
- applies to part (P518) → foreword (Q1358138) (or introduction (Q305178), imprimatur (Q955005), afterword (Q677297), etc as appropriate)

If nothing else, this doesn't link the property tightly to "preface". Inductiveload (talk) 21:21, 20 August 2021 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

territory claimed by (P1336)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Property kept. No consensus to delete and lack of detail provided on alternative methods of recording this data — Martin (MSGJ · talk) 20:44, 12 February 2022 (UTC)

Based on this RFC, I think it's now the good time we deprecate it, it's already enough to say something is conflicting between two and more countries, by adding qualifiers to their country (P17) values. —Liuxinyu970226 (talk) 00:13, 15 November 2019 (UTC)

Comment Who will move current uses to a new ontology ?. I think we cannot delete until there are no uses of it.Amadalvarez (talk) 09:14, 15 November 2019 (UTC)

@Amadalvarez: Just merge em back to P17, see RFC for details. --Liuxinyu970226 (talk) 22:59, 16 November 2019 (UTC)

Keep not only a country can claim territory. Michael FV (talk) 03:51, 9 January 2020 (UTC)
@Michael FV: Please read that RFC carefully before such voting keep, thx. --Liuxinyu970226 (talk) 00:31, 10 January 2020 (UTC)
Recognised etc. from the RFC could qualify “claimed by” just as well as it could qualify country (P17) or located in the administrative territorial entity (P131). And what about something like Palestine (Q23792)territory claimed by (P1336)Palestine Liberation Organization (Q26683), where the claimant is an organisation, not a state? ⁓ Pelagic ( messages ) 19:23, 31 January 2022 (UTC)
Some uses of this are countries claimed by another country, or by each other. With this change, would Cyprus would only have "country: Northern Cyprus" and Northern Cyprus only have "country: Cyprus", or would the items also have P17 statements linking to themselves? There are probably others that are similar. Peter James (talk) 16:24, 17 January 2020 (UTC)
Keep given the points mentioned in the rfc --- Jura 11:02, 20 January 2020 (UTC)

j*:@Jura1: Which point. --2409:8902:9001:1F4F:1444:B367:16E3:3F84 00:59, 21 January 2020 (UTC)

Delete Given that this is spammly used to make so-called claim e.g. wrongly says that "Shenzhen is a part of Hong Kong". --117.136.54.109 22:32, 20 January 2020 (UTC)

Delete Replacement available. --223.104.7.115 22:09, 9 May 2020 (UTC)

Comment I repeat my concern that the current information should be move to new ontology before delete. Liuxinyu970226 told me that "I follow RFC", but I'm user of this information in WD powered infoboxes. I'll take care handling new structure in infoboxes code, but not migrating data, because IMHO it should be move in a batch process when the change were full approved. Thanks, Amadalvarez (talk) 16:57, 21 May 2020 (UTC)

In addition, could you please write down the final ontology with {{Claim}} or similar. I'm not sure if "new properties" described in inital proposal have been created (and what are?) or you decide use some other proposed in the discussion. What are the final combination of property and qualifiers for each circumstances described in "Proposal section" ?. etc. Maybe in your mind it's very clear, but a RFC is open for "comments". So, if it is still open, please ping me when we have a final ontology. Thanks, Amadalvarez (talk) 19:36, 21 May 2020 (UTC)

Comment Could you give an example of new modelling for instance in the very famous Taiwan (Q865) and People's Republic of China (Q148) ? I'm interested as I'm having a topic here https://www.wikidata.org/wiki/Wikidata:Property_proposal/Generic#est/a_%C3%A9t%C3%A9_en_conflit_avec Bouzinac ^{💬●✒️●💛} 20:49, 13 September 2020 (UTC)

Keep The idea is to replace the property by 4 others ones ; The properties "recognition" (qualifier only), "recognized by", and "not recognized by" and "de jure"/"de facto" properties. It should result in very long lists of countries in the infobox (among 200 countries, who recognises, who does'nt ?), et complicate the problem. --Pa2chant.bis (talk) 07:19, 15 September 2021 (UTC)
I'm totally confused by your propose of re-using it, repeating will only waste RAMs of Wikimedia servers, aren't they?

If you think we need better way, to not delete P1336 and, in your opinion, to re-classify the disputed territories, write them on that link RFC, otherwise as someone anonymous said above, Replacement available. Liuxinyu970226 (talk) 07:56, 1 November 2021 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Argentinian Historic Heritage ID (P4587)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

No consensus - a fine balance between "not worth keeping" and "might be useful one day" — Martin (MSGJ · talk) 21:06, 12 February 2022 (UTC)

Doesn't exist anymore (and is not coming back in the same format) —Mauricio V. Genta (talk) 01:00, 10 December 2019 (UTC)

Keep and mark as historic. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:06, 10 December 2019 (UTC)

If it was used a lot I would say mark as historic, but I see it's used less than 50 times so in this case it's not really worth the effort to keep it around. @Mauricio V. Genta: what's the replacement for Argentina? Looking in the monuments database I see links, but these go nowhere. Multichill (talk) 19:01, 12 December 2019 (UTC)

Nothing. It was really kind of a test, i did not see the property request in time to vote negative. They do not have a URI or unique ID for them, not even in physical paper. From my position in WMAR, and as a museology student in the school that depend on the National Commission of Monuments, already advised them in better practices and the uses of URIs..but there is no budget. Mauricio V. Genta (talk) 04:52, 13 December 2019 (UTC)

Delete Since no archive.org archives available for em. --Liuxinyu970226 (talk) 03:42, 8 January 2020 (UTC)

Keep shutdown of other site is no reason for deletion of information from own site. Michael FV (talk) 04:12, 9 January 2020 (UTC)
@Michael FV: obsolete Wikidata property (Q18644427) says "If there is no archived version mark for deletion with "obsolete Wikidata property"", so do you have any archive places of this? If not, then shutted down is just a valid reason to delete this. --Liuxinyu970226 (talk) 00:58, 10 January 2020 (UTC)
It's hardly used, otherwise I'd keep it. --- Jura 10:59, 20 January 2020 (UTC)
Delete Neither archives nor replacements available. --117.136.54.109 23:25, 20 January 2020 (UTC)
Keep. How can we be sure the data isn't available somewhere (there are archives other than archive.org) and this wouldn't be eventually useful? Just add a notice that it's historical. BrokenSegue (talk) 05:59, 21 May 2020 (UTC)
Keep, as some of the links from monumentos.culturagob.ar are still accessible through the Wayback machine. See e.g.Colón Theater (Q827401). --DavidJRasp (talk) 17:40, 9 August 2020 (UTC)
Keep Keep and mark as historic. --Sezgin İbiş (talk) 22:06, 6 September 2020 (UTC)
Delete per the above. NMaia (talk) 02:31, 14 October 2020 (UTC)
Delete with less than 50 entries this is not crucial data to keep. --Hannes Röst (talk) 14:53, 13 January 2022 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P9745 / translation of

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

There is consensus that this property is useful, and further that is desirable to separate it from edition or translation of (P629). That leaves open the issue of whether the scope of edition or translation of (P629) should be changed. Unfortunately the discussion at Wikidata talk:WikiProject Books/2021#Formal discussion about translation of (P9745) did not result in a consensus, but I suggest trying again there or at Property talk:P629 — Martin (MSGJ · talk) 21:38, 13 February 2022 (UTC)

Newly created property that was not created in consultation with the project leading in the subject area. Its creation is premature and does not completely capture the complexity of the subject matter. This should be nullified prior to it being utilised. Wikidata:Property proposal/translation of for creation discussion and my issue with its creation. Properties like this should only be created in clear consultation with the relevant project and it should be checked that the project has been suitably alerted and involved in that discussion prior to any creation of a new property. — billinghurst sDrewth 11:52, 19 July 2021 (UTC)

Delete This duplicates the function of edition or translation of (P629), and was created without notifying or consulting Wikidata:WikiProject Books. We found out about this property when it was added to our project page. [12] The "new" property muddies the waters, since there is not always a clear division between editions and translations. A bitext (Q1346592) such as Aspis (The Shield) (Q105703709) is both an edition and a translation at the same time. Chaucer's The Canterbury Tales (Q191663) may be translated from Middle English to modern English. But Harry Potter and the Philosopher's Stone (Q43361) was "translated" from UK English into US English and released under a different title. A work in traditional Chinese was be "translated" into simplified Chinese characters. A work in Serbian (Q9299) may be written in Cyrillic script or in Latin script, or be "translated" into Serbo-Croatian (Q9301). There is no clear dividing line between editions and translations, but rather a spectrum of actions where the distinction is clear only at the opposite ends. --EncycloPetey (talk) 15:17, 19 July 2021 (UTC)

@EncycloPetey: These are just some ideas to solve the problems you mentioned. I'm not mad or heavily defending them.

"A bitext (Q1346592) such as Aspis (The Shield) (Q105703709) is both an edition and a translation at the same time."

Then include both "edition of" and "translation of" statements.

"But Harry Potter and the Philosopher's Stone (Q43361) was "translated" from UK English into US English and released under a different title."

This kind of gets me. Why isn't there items for the specific releases of Harry Potter and the Philosopher's Stone in the U.S.? Wikiproject Music documents all releases. There might be a lot of releases for a book like Harry Potter and the Philosopher's Stone as it's been printed continuously and in many formats, but it might worth documenting. And in this case, it can also solve the "translated" problem.

"A work in traditional Chinese was be "translated" into simplified Chinese characters."

This would definitely be considered a translation. Wikidata itself has support for Simplified and Traditional Chinese translations.

"A work in Serbian (Q9299) may be written in Cyrillic script or in Latin script, or be "translated" into Serbo-Croatian (Q9301)."

I think this would be considered a translation too?

"There is no clear dividing line between editions and translations, but rather a spectrum of actions where the distinction is clear only at the opposite ends."

It seems pretty clear to me. There's a reason why many other databases have a "transation of" property: it's needed, useful, and identifiable. Lectrician1 (talk) 00:56, 21 July 2021 (UTC)

This isn't the forum for suggesting alternative approached for Wikiproject:Books. The issue here is that (a) a property was created that duplicates the function of an existing property, and (b) it was created without an input, notification, or the knowledge of the Wikiproject whose project page was then altered. Do you support the duplication of property functions? Do you condone the creation of properties without notifying or consulting established projects who are directly impacted by the new property? The underlying issues can be discussed at Wikidata:WikiProject Books, if you believe you have helpful ideas. The few examples I gave merely illustrate the complexity of this issue goes beyond anything that was discussed in the hasty approval of the property. --EncycloPetey (talk) 05:23, 21 July 2021 (UTC)

@EncycloPetey: Should I start a discussion on WP:Books about the property now, or after it is maybe deleted? Lectrician1 (talk) 19:45, 21 July 2021 (UTC)

You could do either. Whether this property remains or is deleted, many of the complexities of this issue will still exist. --EncycloPetey (talk) 19:47, 21 July 2021 (UTC)

Discussion about the property created: Wikidata talk:WikiProject Books#Formal discussion about translation of (P9745) Lectrician1 (talk) 01:10, 25 July 2021 (UTC)

Keep Wikidata would be better served it was aligned with bibliographic properties used in the cataloging world, where translation is a very different relationship to revision. In FRBR and IFLA LRM, both revision and translation create new derivative expressions. A revised edition of a textbook is quite a different thing to a translation of the textbook, and I think Wikidata ought to have separate properties to describe these relationships. Resource Description and Access (Q1519318), the cataloging standard used predominantly in North America, the U.K., Germany, and other places, has a variety of these properties to differentiate types of relationships between expressions: is translation of; is free translation of; is dubbed version of; is revision of. is translation of "relates an expression to an expression whose language is modified to create a new expression that is different from another expression of the same work." is revision of "relates an expression to an expression that is updated, corrected, or expanded to create a new expression of the same work." UWashPrincipalCataloger (talk) 22:58, 28 July 2021 (UTC)

Merge and delete P629 is good enough for a decade. --Liuxinyu970226 (talk) 02:02, 5 August 2021 (UTC)
Keep @Liuxinyu970226: This property as discussed clearly serves a purpose for distinguishing which versions of a work are translations of another. When used correctly this property does not replace the usage of edition or translation of (P629). All editions and translations should remain under that property. All translation of (P9745) does is establish a relation statement between fellow versions that would be under has edition or translation (P747) together. This allows for users to distinguish which editions are translations of other editions with a simple statement and not have to user qualifiers on has edition or translation (P747). It also allows for the distinguishment of translations that are based on translations themselves, with all translations and editions being under the same work (see discussion). Clearly this property has a need and necessary in the cataloging of creative works. --Lectrician1 (talk) 22:11, 5 August 2021 (UTC)
P9745 has been reported as having difficult on translations of Asian languages, where P629 doesn't have. Liuxinyu970226 (talk) 22:27, 5 August 2021 (UTC)
@Liuxinyu970226: I'm confused by what you mean? edition or translation of (P629) is still supposed to be used for all translations and editions. All translation of (P9745) does is relate what editions are translations of another. Lectrician1 (talk) 14:54, 6 August 2021 (UTC)
@Lectrician1 I guess that these languages don't have better P9745 translations due to grammar rules, if Yandex, Google or else don't make me shame?
Amharic: የ $1 ትርጉም (then use የ or ትርጉም?)

Armenian: $1- ի թարգմանություն (really "ի թարգմանություն $1-" is okay?)

Azerbaijani: $1 tərcüməsi (I believe they won't agree "tərcüməsi $1")

Basque: $1-ren itzulpena ("-ren itzulpena $1"? hehe)

Bengali: $1 এর অনুবাদ (I don't think "এর অনুবাদ $1" is okay)

Burmese: $1 ဘာသာပြန်ချက် (I don't think "ဘာသာပြန်ချက် $1" is okay)

Chinese: $1的翻译/$1的翻譯 ("的翻译 $1/的翻譯 $1"? lol)

Estonian: $1 tõlge ("tõlge $1" can work?)

Finnish: $1 käännös ("käännös $1" can work?)

Georgian: $1- ის თარგმანი (don't expect "ის თარგმანი $1-" can work)

Gujarati: $1 નું ભાષાંતર (I don't think "નું ભાષાંતર $1" is okay)

Hindi: $1 . का अनुवाद (I don't think "का अनुवाद $1 . " is okay)

Hungarian: $1 fordítása (maybe someone can tell me if "fordítása $1" is okay or not)

Japanese: $1の翻訳 ("の翻訳 $1" would really be nonsense)

Kannada: $1 ಅನುವಾದ (I don't think "ಅನುವಾದ $1" is okay)

Kazakh: $1 аудармасы (I believe they won't agree "аудармасы $1")

Korean: $1 번역 ("번역 $1" can work?)

Kyrgyz: $1 котормосу (I believe they won't agree "котормосу $1")

Lithuanian: $1 vertimas ("vertimas $1" can work?)

Malayalam: $1 വിവർത്തനം (I don't think "വിവർത്തനം $1" is okay)

Marathi: $1 चे भाषांतर (I don't think "चे भाषांतर $1" is okay)

Mongolian: $1 орчуулга (I believe they won't agree "орчуулга $1")

Nepali: $1 को अनुवाद (I don't think "को अनुवाद $1" is okay)

Odia: $1 ର ଅନୁବାଦ (I don't think "ର ଅନୁବାଦ $1" is okay)

Pashto: د $1 ژباړه (As a RTL language, I don't see any reasons "د" or "ژباړه" may just work lonely)

Punjabi: $1 ਦਾ ਅਨੁਵਾਦ (I don't think "ਦਾ ਅਨੁਵਾਦ $1" is okay)

Sindhi: $1 جو ترجمو (As a RTL language, do we think "جو ترجمو $1" may work?)

Sinhalese: $1 පරිවර්තනය (I don't think "පරිවර්තනය $1" is okay)

Tamil: $1 இன் மொழிபெயர்ப்பு (I don't think "இன் மொழிபெயர்ப்பு $1" is okay)

Tatar: $1 тәрҗемәсе (I believe they won't agree "тәрҗемәсе $1")

Telugu: $1 యొక్క అనువాదం (I don't think "యొక్క అనువాదం $1" is okay)

Turkish: $1'un çevirisi (do you have evidences "'un çevirisi $1" may work?)

Turkmen: $1 terjimesi (I believe they won't agree "terjimesi $1")

Urdu: $1 کا ترجمہ (still think "کا ترجمہ $1" may work?)

Uyghur: $1 نىڭ تەرجىمىسى (still think "نىڭ تەرجىمىسى $1" may work?)

Uzbek: $1 tarjimasi (I believe they won't agree "tarjimasi $1")

(although we even don't think all speakers of them can trust MT tools, we need at least a way to let values shown before these translation words, or do you have other ways to fix them?) Liuxinyu970226 (talk) 00:11, 18 August 2021 (UTC)
@Liuxinyu970226: Ummmmmmmmmmmmmmm. Well, how to these languages work with other properties that are named with a noun and the "of"? Why is "translation of" such a barrier grammatically compared to other properties? Lectrician1 (talk) 00:23, 18 August 2021 (UTC)
Indeed, these languages can always have such problems on translating property names, just if their English names have the word "of". Liuxinyu970226 (talk) 00:27, 18 August 2021 (UTC)
@Liuxinyu970226: Well if this translation problem for the property is something other properties suffer from, I'm not really sure why it should be a barrier to keeping it. The property serves an important purpose and that's what's important. These translation problems could be worked out through descriptions. Lectrician1 (talk) 17:37, 18 August 2021 (UTC)
Or probably, we need to discuss the English name "translation of" is proper or not, since this really causes translation difficults for nearly all Turkic, Indic and RTL languages. Liuxinyu970226 (talk) 01:45, 11 January 2022 (UTC)
Delete Prematurely created and pretty confusing (note that translated edition is usually a translation of another edition, not the work, sometimes even translation of another translated edition, etc.). --Jklamo (talk) 23:20, 14 August 2021 (UTC)
@Jklamo: Wait, if you understand how the property works, why are you for deleting it? Lectrician1 (talk) 00:25, 18 August 2021 (UTC)
Keep This property is now actively used for music, strongly against deleting it. Moving away from old ambiguous properties that require inverse statements is only a good thing imo. Moebeus (talk) 19:05, 27 December 2021 (UTC)
Keep I am also clearly against a deletion here. I find this property very useful. --Gymnicus (talk) 10:00, 12 February 2022 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

shrinkage (P7079)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

No consensus to delete — Martin (MSGJ · talk) 12:37, 14 February 2022 (UTC)

Unused —217.117.125.72 17:15, 13 October 2020 (UTC)

Notified participants of WikiProject Mathematics ^^ --Liuxinyu970226 (talk) 22:21, 13 October 2020 (UTC)

~~Support~~ There literally is no usage [13]. It seems like a weird property to begin with, so I don't mind deleting it.— The Erinaceous One 🦔 02:52, 14 October 2020 (UTC)

@Thibdx: (proposal creator)

Notified participants of WikiProject Physics (more appropriate than maths) author TomT0m / talk page 06:53, 14 October 2020 (UTC)

Support This isn't even used in the given example. --Mu301 (talk) 13:05, 14 October 2020 (UTC)
Keep It certainly had support, no usage is not reason to delete it Germartin1 (talk) 19:30, 20 October 2020 (UTC)
- @The-erinaceous-one, Mu301, Germartin1: As header: Support or Oppose what? Please, use Keep or Delete. —Eihel (talk) 20:17, 20 October 2020 (UTC)
  - Got it, I meant Delete. — The Erinaceous One 🦔 21:27, 20 October 2020 (UTC)
- @Germartin1: By that logic, we should never delete any property because they all had support at one point. But sometimes we are collectively mistaken on whether a particular property will be useful so we should be open to deleting unused properties. — The Erinaceous One 🦔 21:27, 20 October 2020 (UTC)
Delete @Germartin1: Not really to be used due to hard technical challanges, if the technical problem is solved in the near future, this can be request-restored. --Liuxinyu970226 (talk) 09:50, 23 October 2020 (UTC)
Delete Vojtěch Dostál (talk) 14:12, 5 November 2020 (UTC)
Keep Unless there is an actual problem with the property, no use is a poor reason. If we are just missing active users with an interest in updating materials, let's have this property hanging around, it costs much less energy than trying to undelete it later. Ainali (talk) 15:11, 12 February 2021 (UTC)
Keep, disuse is not a reason to delete. Arbnos (talk) 21:38, 27 April 2021 (UTC)
Keep this property is one of the series of properties related to materials science and it should be discussed in relation to other properties from that series. As the only argument for deletion is no usage, I see no other option as to vote to keep this. Wostr (talk) 17:06, 7 July 2021 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P6453 (P6453)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Property will be migrated to Bilibili bangumi ID (P5733) and deleted — Martin (MSGJ · talk) 22:05, 14 February 2022 (UTC)

P6453 (P6453): (delete | history | links | entity usage | logs)

This property is identical to Bilibili bangumi ID (P5733). Since it has only been used 6 times, it would be easy to migrate current uses to Bilibili bangumi ID (P5733). Meanwhile, we should probably change the label of Bilibili bangumi ID (P5733) to "Bilibili bangumi ID" to better reflect the scope of the property and distinguish it from other Bilibili properties like Bilibili user ID (P6455) and Bilibili video ID (P6456). —Stevenliuyi (talk) 06:07, 17 April 2021 (UTC)

Delete I agree after reviewing these properties. One thing to keep in mind when updating is they're using slightly different formats for their URLs/identifiers as one includes the 'md' at the start of every ID and the other doesn't. --Jeanjung212 (talk) 01:30, 21 April 2021 (UTC)
Delete delete or merge. P6453 (P6453) and Bilibili bangumi ID (P5733)are basically the same. Kethyga (talk) 07:39, 29 December 2021 (UTC)
Delete because it's redundant. User:Veracious ^(•‿•)^ 09:36, 23 January 2022 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Implementation notes

Data has been migrated Bilibili bangumi ID (P5733). Deleting soon — Martin (MSGJ · talk) 22:12, 14 February 2022 (UTC)
Done — Martin (MSGJ · talk) 16:36, 15 February 2022 (UTC)

P5330 (P5330)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Consensus to migrate data to class of station (P5606) then delete — Martin (MSGJ · talk) 13:18, 11 February 2022 (UTC)

P5330 (P5330): (delete | history | links | entity usage | logs)

I don't think we need a specialized property than class of station (P5606). GZWDer (talk) 21:46, 8 December 2019 (UTC)

Delete after data migration. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:05, 10 December 2019 (UTC)

Keep The general property explicitly says "use subproperties where available" and has constraints that conflict with their use. No apparent benefit to generalisation over specificity so data migration would just be makework. Thryduulf (talk) 14:28, 16 December 2019 (UTC)

Notified participants of WikiProject Railways Thryduulf (talk) 14:29, 16 December 2019 (UTC)

Delete I agree with GZWDer and Andy, not need to have a special property and delete after migration. Multichill (talk) 18:48, 16 December 2019 (UTC)

Delete The specific property (P5330) is largely redundant to the general property (P5606). An argument could be made that the general property should be deleted instead and replaced with specific properties for each network, but here the relationship with the network can be inferred from the station category items, so including the network as part of the property is functionally unnecessary. Jc86035 (talk) 23:13, 16 December 2019 (UTC)

Delete Per above, unlike station codes and line numbers where both may triage URL schemes, linking to these items for ranking of stations are good enough. --Liuxinyu970226 (talk) 11:26, 17 December 2019 (UTC)

Additionally, should we redesign the {{Ping project|Railways}} to be {{Ping project|Taxonomy}} like? --Liuxinyu970226 (talk) 11:27, 17 December 2019 (UTC)

Keep per description of P5606: "Use subproperties where available" Michael FV (talk) 04:03, 9 January 2020 (UTC)
@Michael FV, Thryduulf: If there's no URL schemes for "subproperties" available, then there are entirely no reason to have subproperties, we can merge them back to this one now. --Liuxinyu970226 (talk) 00:30, 10 January 2020 (UTC)
@Liuxinyu970226: If you think a property needs to be merged then what you need to do is get consensus to merge it, not nominate it for deletion. My recommendation to keep this stands. Thryduulf (talk) 09:53, 10 January 2020 (UTC)

@Thryduulf: Hmm, is there be possible to merge two or more properties without deleting? --Liuxinyu970226 (talk) 09:52, 23 October 2020 (UTC)

Keep clear scope. Enables reports with @Ivan_A._Krestinin:'s Krbot. --- Jura 10:58, 20 January 2020 (UTC)
Delete replacement available, no need to create any subproperties for anything that don't affect URL schemes. ForIvan_A._Krestinin'sbot, Ithink weshouldasktheproblem viatheirGithub? --117.136.54.109 23:23, 20 January 2020 (UTC)

Delete As values are only items, merge em back won't hurt anything. --223.104.7.115 22:11, 9 May 2020 (UTC)

Delete No need to fragment data into multiple properties. --Tinker Bell ★ ♥ 01:53, 25 October 2020 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Implementation notes

@GZWDer: would you be able to help migrate this data? There are 109 statements. Thanks — Martin (MSGJ · talk) 13:21, 11 February 2022 (UTC)

Done — Martin (MSGJ · talk) 21:07, 15 February 2022 (UTC)

Joconde IDs

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Consensus is to keep these properties — Martin (MSGJ · talk) 21:35, 15 February 2022 (UTC)

Thésaurus de la désignation des objets mobiliers ID (P4979): (delete | history | links | entity usage | logs | discussion)
Thésaurus de la désignation des œuvres architecturales et des espaces aménagés ID (P4980): (delete | history | links | entity usage | logs | discussion)
Joconde author ID (P7711): (delete | history | links | entity usage | logs | discussion)
Joconde domain ID (P7712): (delete | history | links | entity usage | logs | discussion)
Joconde epoch ID (P7786): (delete | history | links | entity usage | logs | discussion)
Joconde object type ID (P7844): (delete | history | links | entity usage | logs | discussion)
Joconde location ID (P7850): (delete | history | links | entity usage | logs | discussion)
Joconde inscription ID (P7884): (delete | history | links | entity usage | logs | discussion)
Joconde time period ID (P7885): (delete | history | links | entity usage | logs | discussion)
Joconde discovery ID (P7960): (delete | history | links | entity usage | logs | discussion)
Joconde creation ID (P7961): (delete | history | links | entity usage | logs | discussion)

I propose to merge these properties to one single property for consistency. See User_talk:Vladimir_Alexiev/Archive_1#Joconde_IDs.--GZWDer (talk) 06:37, 4 April 2020 (UTC)

~~Delete~~ That's fine with me. But you should maybe propose a new property for this first, or pick one of them to be the main one? ArthurPSmith (talk) 17:32, 6 April 2020 (UTC)

I rescind my vote here given the discussion below - if there are cases where the same item would have identifiers from more than one of these properties, then keeping them separate seems the better choice. I really don't have a strong opinion on this either way though. ArthurPSmith (talk) 13:24, 8 April 2020 (UTC)

Keep Those properties link to different and specific vocabularies. For reuse, we need this differentiation. For example on Nicolas Poussin (Q41554) with the value of Joconde author ID (P7711) we can make a link trough the structured data on data.culture.fr to make enable a specific search to the POP results on Jocond Artist field. --Shonagon (talk) 11:39, 7 April 2020 (UTC)

Keep If we merge the Joconde properties it may lead to confusion between similar terms used in different vocabularies and lose their original meaning. For example Domaine : Afrique du Nord http://data.culture.fr/thesaurus/page/ark:/67717/T51-112 and Lieux : Afrique du Nord http://data.culture.fr/thesaurus/page/ark:/67717/T84-2. --Christelle Molinié (talk) 16:06, 7 April 2020 (UTC)

As Joconde is a French website:

Notified participants of WikiProject France --Liuxinyu970226 (talk) 01:23, 8 April 2020 (UTC)

Keep: same as for Shonagon. Nomen ad hoc (talk) 06:56, 8 April 2020 (UTC).
Neutral both cases (unique property or separate properties) have advantages. For the records, there was a unique property P3905 (P3905) (created in 2017, Wikidata:Property proposal/Ginco id) but it has been deleted (in 2018) and split into these separate properties. I'm not keen to go back to the previous situation without a good reason. That said, to answer @ArthurPSmith: question, if we go back so a single property, the best would be to undelete P3905 (P3905). Cdlt, VIGNERON (talk) 08:13, 8 April 2020 (UTC)
Keep Per Shonagon, Christelle Molinié and VIGNERON. There are edge cases that would be too far and wide to solve easily, seeing as some items can fall into two (or more ? ) categories, depending on the axis you want to reach them from, and it is actually sometimes interesting to search all items by one axis, which merging all properties would make a bit more complicated. As an aside, unlike what was said on Vladimir Alexiev's talk page, they aren't "UUIDs" as they're not 128-bit integers (even assuming the letters to be 8-bit) : unique identifiers aren't necessarily UUIDs… Alphos (talk) 09:14, 8 April 2020 (UTC)
I suggest you synthesis and maybe a unanimous exit will see the light of day. Above all, tell me if I write bullshit!
1. I think ArthurPSmith votes {{Vd}} because he sees that it is technically possible. The identifiers of each property will always be linked to a part of http://data.culture.fr/, but in a different way (url_prefix) and will always point to the right page (for each property). I think he has in mind the example of IMDb ID (P345): IDs present for each part (tt, nm, etc.), but linked by a single property. But he expressed the reservation that a proposal be made. (Maybe he's even waiting for a "Pull request" for index.php ?)
2. So the opinions of @Shonagon, Christelle Molinié, Alphos: can be guaranteed, whether it is Author, Location or Domain, and whether it is UUid or not.
3. For P3905 (P3905) from VIGNERON, the return of this property should not be useful, but when I see that sword (Q12791) has not been carried over to Thésaurus de la désignation des objets mobiliers ID (P4979), it would be useful to recover the old forgotten IDs.
4. According to the problems formulated above, single-value constraint (Q19474404) and distinct-values constraint (Q21502410) will no longer be used in the future Property and indicated in the proposal. Only the complexity of RegEx will allow proper use.
5. For RegEx, I recommend a separation of a term designating one of the old Property by : and the IDs themselves. The old RegEx will be taken over to form the new RegEx. So the future Regex will have the following form: (thesaurus:(T69-[1-9]\d{0,6}|T96-[1-9]\d{0,6})|author:(T513-[1-9]\d{0,4}|[0-9a-f]{8}(-[0-9a-f]{4}){3}-[0-9a-f]{12})|domain:(T51-[1-9]\d{0,2}|[0-9a-f]{8}(-[0-9a-f]{4}){3}-[0-9a-f]{12})|epoch:[1-9]\d{0,5}|etc. I don't know how long a RegEx can take on WD. Current Ids will take a prefix: thesaurus, author, domain, epoch, etc. Example of ID provided by Shonagon: Nicolas Poussin (Q41554) → author:T513-25084. syntax clarification (P2916) should be used to refer contributors.
6. Before deletion, the old IDs should be taken back. They are 363. This is why I agree with Delete: some current properties have less than 10 entries. Maybe an Open Refine would take the IDs (fetch URL?). I would also like a proposal before deletion. Warmest regards —Eihel (talk) 12:30, 8 April 2020 (UTC)
Neutral —Eihel (talk) 01:31, 19 February 2021 (UTC)
My first idea (before discussion with Vladimir Alexiev and this proposal) is to create a new property "Joconde UUID" and rename all other properties to "Joconde legacy xxx ID".--GZWDer (talk) 12:59, 8 April 2020 (UTC)

@Eihel: I'm sure I understand your position. You say « the return of this property should not be useful » and then « I agree with {{Vd}} », but deletion of the separate properties is exactly the same as return to P3905 (P3905).

Plus, the analogy with IMDb ID (P345) is only partially relevant as each part is separate and disjoint (it's tt or - exclusive or - nm, which make it easier to manage and maintain) while here there is a lot of overlap between the thesauri (it's T69- and T96- for example) which may cause some trouble (including but not limited to the "single value" constraint as you pointed out; the "unique distinct value" constraint is still true though).

Cheers, VIGNERON (talk) 13:45, 8 April 2020 (UTC)

@Eihel: Yes that could have been a solution except that unfortunately the prefix is not reliable. It is a remnant of an old system for ancient entries. All new entries use UUID and are intentionally opaque. Example of artist Joconde with UUID: MASCAUX Claude Léon. Best regards --Shonagon (talk) 14:33, 8 April 2020 (UTC)

I have another point for deletion: there seems to be much more thesauri than Wikidata properties we have. Creating an property for each of them does not seems scalable.--GZWDer (talk) 13:48, 8 April 2020 (UTC)

@GZWDer: These vocabularies are all those of the Joconde database and are particularly important in France, used for hundreds of museum collections. Best regards --Shonagon (talk) 14:33, 8 April 2020 (UTC)

Comment This thus look rather un-coodinated. We also seem to have more properties than some of those properties have actual uses. How many more properties should there be created? --- Jura 08:13, 10 April 2020 (UTC)
Keep See https://www.wikidata.org/wiki/Property_talk:P7844: @Christelle Molinié, Shonagon: had a phone call a few days ago with colleagues at the french Ministry of Culture. (@DannyS712, ArthurPSmith, 99of9, Nikola Tulechki, Crowjane7, GZWDer:). They said they'll keep separate thesauri, are very interested in linking to WD, and are working to link the thesauri to POP (the FR aggregation of artworks). I completely agree with Christelle that we have to respect the wish/organization of the thesaurus provider, despite some messiness in their organization. What we need to do is below. I hope culture.fr people, @Christelle Molinié, Shonagon: can help with the last 3 bullets (the last 2 are the big-effort part) --Vladimir Alexiev (talk) 10:28, 23 April 2020 (UTC)
- Relax regexes to just [\w-]+
- Edit formatterURL to remove T69- (and the like)
- Migrate existing values to put T69- (and the like) inside the value
- Create a central page to describe all FR thesauri, with description, links to home page and prop, MnM catalog. A good place is a sub-page of Wikidata:WikiProject Visual arts
- Import more of the thesauri to Mix-n-Match catalogs so they can be coreferenced
- (when there is interest) Create more props and catalogs for more thesauri

Yes I see a point for doing so. I withdrew the deletion request but this should not be closed yet until others agree Vladimir Alexiev's proposal.--GZWDer (talk) 12:15, 23 April 2020 (UTC)

Vladimir Alexiev's proposal sounds fine to me. ArthurPSmith (talk) 20:44, 30 April 2020 (UTC)

I dont't think the id should be changed to include the database identifier if we keep separate properties. --- Jura 07:58, 2 May 2020 (UTC)

OTH, the format seems to be either "<database id><old id>" or "<uuid>" .. --- Jura 08:03, 2 May 2020 (UTC)

@Alphos, @ArthurPSmith, @Christelle Molinié, @Eihel, @GZWDer, @Jura, @Liuxinyu970226, @Nomen ad hoc, @VIGNERON, @Vladimir Alexiev
Hello,
Following the various suggestions:

Properties have been corrected or completed (format, constraints, source website,...),
Regex formats are adapted for specific identifier or uuid,
Existing values for all Joconde properties claims have been corrected if necessary,
A Wikiproject Vocabulaires Joconde was created (thanks to Christelle Molinié),
Joconde thesauri have been imported to Mix'n'Match : list of vocabularies with Mix'n'Match links.

IMHO, creating more props for more thesauri is a challenge depending on the interest of the thesaurus and the implication of wikidata editors. For information there is a script on Github that can help to convert a data.culture vocabulary (in RDF/XML syntax) to a CSV file for Mix'n'Match, using the SKOS poperties (altLabel, broader, narrower) for description.
Best regards --Shonagon (talk) 11:43, 12 May 2020 (UTC)

Thanks @Shonagon: that's great!

edited to fix some bullets
edited query to add Nomenclature
removed type constraint at https://www.wikidata.org/wiki/Property_talk:P7712#Type_constraint
I wonder how to approach a translation of these pages to EN, in order to make this effort approachable by a bigger crowd. I'm not familiar with Wikidata translation mechanisms... @Christelle Molinié: can you help? --Vladimir Alexiev (talk) 05:39, 27 May 2020 (UTC)

Hi @Vladimir Alexiev: I've started the translation here but haven't finished yet. Maybe a lot of things to correct...--Christelle Molinié (talk) 10:15, 27 May 2020 (UTC)

Keep Okay, per Vladimir Alexiev, I don't think that deprecating it is good for us. --Liuxinyu970226 (talk) 22:41, 3 June 2020 (UTC)

Delete How do I add http://data.culture.fr/thesaurus/page/ark:/67717/T1-1187 to telephone (Q11035)? There does not seem to be an applicable Joconde (Q809825) vocabulary property here even though these are now all managed under the same GINCO ("Gestion Informatisée de Nomenclatures Collaboratives et Ouvertes") software at the Ministry of Culture (Q384602). Also newer terms have UUID identifiers that do not specify a specific vocabulary. This and the fact that they all currently have the same valued for ARK formatter (P8054) and formatter URL (P1630) makes me think these various properties ought to be merged. If we are to keep the separate Joconde (Q809825) properties they should be restricted to the appropriate Archival Resource Key (Q2860403) subspace instead of attempting to share the same. Some method should be devised to support the newer UUID identifiers too. Thanks. 50.53.22.81 02:06, 13 September 2020 (UTC)

You cannot currently add it because "Thésaurus-matières pour l'indexation des archives locales" is not made into a WD property. Given that we now have many culture.fr people involved in this effort on WD, i think we should leave it up to them to decide which culture.fr thesauri are worth exposing on WD. --Vladimir Alexiev (talk) 11:38, 24 November 2021 (UTC)

Keep Given the significant effort on Wikidata:WikiProject_Vocabulaires_Joconde it would be folly to delete these props and disturb their effort --Vladimir Alexiev (talk) 11:38, 24 November 2021 (UTC)

@Christelle Molinié, Shonagon: Why are Thésaurus de la désignation des objets mobiliers ID (P4979) and Thésaurus de la désignation des œuvres architecturales et des espaces aménagés ID (P4980) missing from that project? Are they "second class" thesauri and the WD props should be deleted, or will they be coreferenced and maintained like the rest? --Vladimir Alexiev (talk) 11:38, 24 November 2021 (UTC)
Hi @Vladimir Alexiev It's because they are linked to others cultural databases : Palissy and Mérimée that are separate of Joconde. They are all accessible via the platform POP but supported by different departements of the french ministry of culture who use their own vocabularies. it's a pity but we have to deal with it... Christelle Molinié (talk) 16:08, 24 November 2021 (UTC)

@Christelle Molinié, Shonagon: Can't you take them under your wing as well? They have MnM catalogs, and the same problem (format regexes need to be changed, and the values migrated to include T69-, respectively T96- ). Please include them in your pages, thanks!! --Vladimir Alexiev (talk) 12:10, 27 November 2021 (UTC)

Hello @Vladimir Alexiev and @Shonagon I've just created a global page for the vocabularies of the french ministry of culture which includes the Joconde project. I hope that will be more understandable. Christelle Molinié (talk) 11:14, 4 December 2021 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P5105 (P5105)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Consensus to merge to class of station (P5606) and delete — Martin (MSGJ · talk) 20:59, 12 February 2022 (UTC)

P5105 (P5105): (delete | history | links | entity usage | logs)

I don't think we need a specialized property than class of station (P5606). GZWDer (talk) 21:46, 8 December 2019 (UTC)

Notified participants of WikiProject Railways and especially, because it's used by hu:Sablon:Állomás infobox, @B.Zsolt, Tacsipacsi: ^^ --Liuxinyu970226 (talk) 00:54, 10 December 2019 (UTC)

Delete after data migration. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:05, 10 December 2019 (UTC)

Keep Wikidata have lot of external identifiers, why need deletion? --B.Zsolt (talk) 13:31, 11 December 2019 (UTC)

Delete@B.Zsolt: Because there's a more useful identifier as replacement. --Liuxinyu970226 (talk) 14:53, 11 December 2019 (UTC)

Delete per Andy. This is an item property btw, not an external identifier property. Multichill (talk) 19:04, 12 December 2019 (UTC)

Delete after data migration. Robin van der Vliet (talk) (contribs) 00:43, 16 December 2019 (UTC)

Keep The general property explicitly says "use subproperties where available" and has constraints that conflict with their use. No apparent benefit to generalisation over specificity so data migration would just be makework. Thryduulf (talk) 14:27, 16 December 2019 (UTC)

Delete The specific property (P5105) is largely redundant to the general property (P5606). An argument could be made that the general property should be deleted instead and replaced with specific properties for each network, but here the relationship with the operator can be inferred from the station category items, so including the operator as part of the property is functionally unnecessary. Jc86035 (talk) 23:13, 16 December 2019 (UTC)

Keep per Thryduulf Michael FV (talk) 04:01, 9 January 2020 (UTC)
Keep clear scope. Enables reports with @Ivan_A._Krestinin:'s Krbot. --- Jura 11:04, 20 January 2020 (UTC)
Delete replacement available, no need to create any subproperties for anything that don't affect URL schemes. --117.136.54.109 23:22, 20 January 2020 (UTC)
Keep per above Germartin1 (talk) 09:55, 2 April 2020 (UTC)
@Jura1, Germartin1: "Enables reports with someone's bot" isn't a valid keep reason, we can ask them on Github to request cancelling their relative codes. --Liuxinyu970226 (talk) 00:49, 8 April 2020 (UTC)

Delete As values are only items, merge em back won't hurt anything. --223.104.7.115 22:11, 9 May 2020 (UTC)

Delete No need to fragment data into multiple properties. --Tinker Bell ★ ♥ 01:55, 25 October 2020 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Notes

Migrating data to class of station (P5606) ... — Martin (MSGJ · talk) 22:17, 14 February 2022 (UTC)
Done — Martin (MSGJ · talk) 21:04, 15 February 2022 (UTC)
Need to update hu:Sablon:Állomás infobox Y
Removing statements now — Martin (MSGJ · talk) 21:04, 15 February 2022 (UTC)
Deleted — Martin (MSGJ · talk) 21:43, 15 February 2022 (UTC)

Scoresway handball person ID (archived) (P4451)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Kept — Martin (MSGJ · talk) 22:13, 16 February 2022 (UTC)

See also Wikidata:Properties for deletion/P3043

Pages do not exist as scoresway.com is defunct. Pelmeen10 (talk) 19:56, 2 April 2020 (UTC)

A little Keep per above. --Liuxinyu970226 (talk) 01:10, 3 April 2020 (UTC)
Keep In use at Module:External links/conf/Sports at the English Wikipedia. Module transcluded in thousand of pages. --Amitie 10g (talk) 00:03, 30 May 2021 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P6656 (P6656)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Consensus to delete — Martin (MSGJ · talk) 22:35, 16 February 2022 (UTC)

P6656 (P6656): (delete | history | links | entity usage | logs)

Replaced by BHCL UUID (P9037). P6656 only redirects to the IDs of BHCL UUID (P9037) —Vojtěch Dostál (talk) 12:02, 10 September 2021 (UTC)

Notified participants of WikiProject Czech Republic Vojtěch Dostál (talk) 12:03, 10 September 2021 (UTC)

Delete Replacement is better.--Jklamo (talk) 12:23, 14 September 2021 (UTC)
Comment It's a bit odd that it get listed for deletion shortly after P9037 was added. Does that mean that it wasn't really of much use in general? So if this is deleted, maybe P9037 should be as well. --- Jura 12:27, 14 September 2021 (UTC)
@Jura1 Why is that odd? P9037 is a replacement for P6656. Vojtěch Dostál (talk) 13:46, 20 September 2021 (UTC)
- Some think that identifiers should be added to Wikidata so that others can reconcile datasets they have with Wikidata. --- Jura 08:24, 22 September 2021 (UTC)
Delete. @Jura1: Do you claim that P6656 (P6656) values are already used in a bunch of other databases? @Vojtěch Dostál: please comment --Vladimir Alexiev (talk) 10:44, 24 November 2021 (UTC)
I am not aware of a database which uses hard-coded links with the old identifier values. Vojtěch Dostál (talk) 12:06, 24 November 2021 (UTC)
- If it was added to Wikidata, it should have a use beyond merely providing links. --- Jura 13:18, 8 January 2022 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Implementation notes

Question: @Vojtěch Dostál: do you know if all 36,546 statements with this property been migrated to BHCL UUID (P9037)? — Martin (MSGJ · talk) 22:18, 16 February 2022 (UTC)
According to Wikidata:Database reports/Constraint violations/P6656#Item_P9037 there are three but I've checked them and they are not valid — Martin (MSGJ · talk) 22:38, 16 February 2022 (UTC)
@MSGJ All seem to be migrated, thanks for fixing the three. Vojtěch Dostál (talk) 05:45, 17 February 2022 (UTC)
Removing statements — Martin (MSGJ · talk) 12:12, 17 February 2022 (UTC)
Done — Martin (MSGJ · talk) 22:18, 17 February 2022 (UTC)

P6066 (P6066)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Property will be deleted — Martin (MSGJ · talk) 22:22, 17 February 2022 (UTC)

P6066 (P6066): (delete | history | links | entity usage | logs)

See also: Wikidata:Properties for deletion/P3043

Pages do not exist as scoresway.com is defunct. I already removed the few usages it had. Pelmeen10 (talk) 11:14, 2 April 2020 (UTC)

A little Keep per above. --Liuxinyu970226 (talk) 01:10, 3 April 2020 (UTC)
- @Liuxinyu970226: Online archives are mostly not available (specific links has to be checked one by one). Only if the link was used as a reference in Wikipedia - then archive.org automatically makes a copy (but unfortunately often the links were not). So in some cases the archives may be available, but what would you do with these properties after kept? Seems pretty useless to me. Pelmeen10 (talk) 12:22, 3 April 2020 (UTC)
  - @Pelmeen10: Why delete information though? Why remove existing entries? I suggest you revert you removal of its usages and we keep it. BrokenSegue (talk) 19:14, 29 May 2020 (UTC)
    - @BrokenSegue: done, all 12 of them.. Pelmeen10 (talk) 21:25, 29 May 2020 (UTC)
Comment hardly used. --- Jura 08:10, 10 April 2020 (UTC)
Delete No archive, 15 uses only.--Jklamo (talk) 14:26, 6 September 2020 (UTC)
@Pelmeen10: was the information moved to another website? — Martin (MSGJ · talk) 12:55, 14 February 2022 (UTC)
- @MSGJ: I have no idea... But I don't think so. Pelmeen10 (talk) 23:17, 14 February 2022 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Wikidata:Properties for deletion/Archive/2022/2

Initial discussion

Second discussion (?)

Post close discussion

Property:P9745 / translation of

Implementation notes

Implementation notes

Joconde IDs

Notes

Implementation notes

Navigation menu

Search