Wikidata:Properties for deletion/Archive/2019
![]() |
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion. |
Contents
- 1 Quais du polar writer ID (P5666)
- 2 candidacy in election (P3602)
- 3 Property:P5733
- 4 Property:P3113
- 5 Property:P3183
- 6 Soundex (P3878)
- 7 language of work or name (P407) and original language of film or TV show (P364)
- 8 download URL (P4945)
- 9 P3188 (P3188)
- 10 P969 (P969) (street address)
- 11 P1112 (P1112) + Pokémon index (P1685)
- 12 Soccerway player ID (P2369)
- 13 Commons category (P373)
- 14 Property:P1773
- 15 participant in (P1344)
- 16 NSZL name authority ID (P3133)
- 17 charter URL (P6378)
- 18 X username (P2002)
- 19 digital representation of (P6243)
- 20 Property:P6623
- 21 translation (P5972)
- 22 female form of label (P2521)
- 23 male form of label (P3321)
- 24 media legend (P2096)
- 25 P4603 (P4603)
- 26 P4497 (P4497)
- 27 P6270 (P6270)
- 28 LGDB game ID (P5116)
- 29 X numeric user ID (P6552)
- 30 P1946 (P1946)
- 31 business division (P199)
- 32 Property:P5482
- 33 Property:P2035
- 34 Property:P6779
- 35 first flight (P606)/UTC date of spacecraft launch (P619)/UTC date of spacecraft landing (P620)/time of object orbit decay (P621)/spacecraft docking/undocking date (P622)
- 36 P5367 (P5367)
- 37 Property:P6978
- 38 Property:P5482
- 39 Property:P5924
- 40 Property:P7082
- 41 Property:P6085
- 42 Property:P4828
- 43 Property:P527
- 44 Property:P7158
- 45 Property:P2396
- 46 Property:P5000
- 47 Property:P2847
- 48 Property:P3905
- 49 Property:P6243
- 50 Property:P1773
- 51 Property:P6482
- 52 Property:P5660
- 53 Property:P2157
- 54 Property:P5826
- 55 Property:P7288
- 56 P7728 (P7728)
- 57 Property:P727
- 58 Property:P134
- 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 --Pasleim (talk) 13:19, 1 January 2019 (UTC)
Quais du polar writer ID (P5666): (delete | history | links | entity usage | logs | discussion)
Ce site n'est en aucun cas un site de référence des littératures policières. C'est juste le site Internet d'un festival qui propose des pages sur leurs invités sans aucun objectif encyclopédique, sans aucun intérêt littéraire et sans jamais que ces fiches (qui ne sont même pas des fiches signalétiques construites) ne soient signées par qui que ce soit. --Matpib (talk) 13:03, 19 August 2018 (UTC)
- La proposition a etais fait par @Thierry Caro: qu'il pourrait expliquer. - yona b (talk) 08:31, 22 August 2018 (UTC)
- @ديفيد عادل وهبة خليل 2, Nomen ad hoc, Pintoch: from the proposal discussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:23, 23 August 2018 (UTC)
- Keep: no serious reason to delete. Nomen ad hoc (talk) 19:25, 23 August 2018 (UTC).
- Keep. Covers the biggest crime literature festival in France. Thierry Caro (talk) 19:38, 23 August 2018 (UTC)
- Keep Cwf97 (talk) 16:30, 21 October 2018 (UTC)
Pigsonthewing: how to archive the current discussion? Nomen ad hoc (talk) 10:49, 8 December 2018 (UTC).
- This section was archived on a request by: --Pasleim (talk) 13:39, 1 January 2019 (UTC)
- 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 --Pasleim (talk) 13:20, 1 January 2019 (UTC)
candidacy in election (P3602): (delete | history | links | entity usage | logs | discussion)
Pinging participants in both proposal discussions: @Shlomo, Danrok, Micru, Susannaanas, ChristianKl, Stryn:. This property was proposed in 2014, rejected as an inverse of candidate (P726), proposed again in 2017 on the basis that "For each municipality there can be tens or hundreds of candidates in municipal elections". (Incidentally, when re-proposing a property one should ping the participants of the original discussion imo.) I dispute that there are commonly elections where there be hundreds of different distinct options on the ballot. Does anyone know of any examples? I think it's very important not to have extra redundant properties in this area, as the two versions will quickly fall out of sync and be harder to use.
—Yair rand (talk) 18:20, 22 August 2018 (UTC)
- I think such elections are called general elections. Not all countries just elect a single candidate per electoral district.
--- Jura 18:29, 22 August 2018 (UTC)- @Jura1: I don't understand the relevance. Whether a single candidate or a group of candidates voted as a single option, we're only going to have one item listed as candidate, otherwise we wouldn't be able to list things like number of votes, right? --Yair rand (talk) 18:36, 22 August 2018 (UTC)
- Some systems are more complicated. Anyways, I don't see an advantage in not having this property.
--- Jura 18:39, 22 August 2018 (UTC)- I'm new to election-related editing. Please consider 2018 Vermont elections (Q55389072). I don't know the best way to model it in Wikidata, but it is commonly spoken of as the Vermont 2018 general election. The offices to be filled include 1 representative in Congress, the governor, several state-wide offices, around 5 offices in each of 14 counties, and justices of the peace in every town. There are nearly 2000 justices of the peace. I asked at project chat just now about how to handle this. Jc3s5h (talk) 19:03, 22 August 2018 (UTC)
- Some systems are more complicated. Anyways, I don't see an advantage in not having this property.
- @Jura1: I don't understand the relevance. Whether a single candidate or a group of candidates voted as a single option, we're only going to have one item listed as candidate, otherwise we wouldn't be able to list things like number of votes, right? --Yair rand (talk) 18:36, 22 August 2018 (UTC)
- Neutral This kind of property, to me, may or maynot be useful. But I'd love to know if there are overlapped properties or not. --Liuxinyu970226 (talk) 15:51, 23 August 2018 (UTC)
- Keep I observe that there are many interrelated election items and properties, many of which are absent for many elections and candidates. By having inverse properties, readers will find it easier to navigate when the set of ideal information is incomplete, and editors will find it easier to navigate while finding omissions and filling them. Also, this property is displayed for a candidate in the interactive interface if one clicks in the "show derived statements" box, provided the appropriate "candidate" property has been added to an election item. If this property were deleted, wouldn't this feature stop working? Jc3s5h (talk) 21:04, 23 August 2018 (UTC)
- Keep Inverse of candidate (P726) property is good only for elections with low number of candidates (like presidential elections), but very impractical for elections with high number of candidates (general elections, local elections). For these candidacy in election (P3602) is the only way to record such information.--Jklamo (talk) 10:21, 25 August 2018 (UTC)
WikiProject every politician has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.
- Keep 2017 United Kingdom general election (Q25052149) had thousands of candidates. In theory we could create individual items for each constituency in each election, and if we want to be able to generate tables such as those on Belfast East (UK Parliament constituency), I suspect we might want to go down that route eventually, but I suspect it's going to be quite some time before we do that consistently enough. --Oravrattas (talk) 09:13, 7 September 2018 (UTC)
- Keep Allows organizing information.--Arbnos (talk) 14:18, 12 September 2018 (UTC)
- This section was archived on a request by: --Pasleim (talk) 13:39, 1 January 2019 (UTC)
- 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 --Pasleim (talk) 13:22, 1 January 2019 (UTC)
Bilibili bangumi ID (P5733): (delete | history | links | entity usage | logs | discussion)
Pointed out by other users that the identifier is also assigned to series hosted on the site apparently without legitimate copyright license granted to the site (i.e. pirated content) C933103 (talk) 16:16, 9 September 2018 (UTC)
- Comment @C933103: Please give examples or a link to the discussion. John Samuel 17:02, 9 September 2018 (UTC)
- @Jsamwrites: Example: https://www.bilibili.com/bangumi/media/md1914/ Note when playing the media after opening song there's a url linking to a fansub site on screen. C933103 (talk) 17:23, 9 September 2018 (UTC)
- Keep Copyright problems are not this wiki concerned, if you have other reasons to nominate deletion than copyright, let's continue. --Liuxinyu970226 (talk) 23:11, 13 September 2018 (UTC)
- Or to put this in another way: I was anticipating to be able to reuse data from links via this identifier to help fill information and claims at wikidata. However with pirate=unofficial content being included in resources available via this identifier, some parameters that would have been made available via this identifier might no longer be certain to be true, and an originally anticipated purpose of the identifier to enable linking from wikipedia articles via the identifier to legitimate platforms that host content about related articles could not be automatically achieved, and thus losing part of the value of the property. C933103 (talk) 06:40, 21 September 2018 (UTC)
- Delete per C933103. Gamaliel (talk) 22:23, 10 December 2018 (UTC)
- Keep The usefulness of this and similar sites seems to me to be greater than the problems involved. --Spinoziano (talk) 16:19, 12 December 2018 (UTC)
- Keep Per Liuxinyu970226 and Spinoziano. --218.68.229.88 07:21, 24 December 2018 (UTC)
- Keep Wether it "supports" piracy or not, it's all goes down to the content platform, not Wikimedia. Flixwito^(•‿•)^ 05:37, 30 December 2018 (UTC)
- This section was archived on a request by: --Pasleim (talk) 13:39, 1 January 2019 (UTC)
- 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 --Pasleim (talk) 13:23, 1 January 2019 (UTC)
does not have part (P3113): (delete | history | links | entity usage | logs | discussion)
Has only 106 uses, and is redundant to has part(s) (P527) with a value of "no value". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:40, 3 October 2018 (UTC)
- @Pigsonthewing: how is it redundant to has part(s) (P527) with a value of "no value"? Where do you indicate the value from the does not have part (P3113) statement? ArthurPSmith (talk) 14:46, 3 October 2018 (UTC)
- Keep Invalid reason, per ArthurPSmith Germartin1 (talk) 12:52, 12 October 2018 (UTC)
- Keep per ArthurPSmith. Jc86035 (talk) 15:38, 1 November 2018 (UTC)
- @ArthurPSmith, Jc86035, Pigsonthewing: What would work however, and is equivalent, is to use author TomT0m / talk page 19:13, 2 November 2018 (UTC)
- Keep per ArthurPSmith. @TomT0m: I don't think this is a good idea. In my eyes wherever possible a mainsnak should also be valid without its qualifier, This proposal is actually dangerous since all querying has part(s) (P527) without also querying the qualifier quantity (P1114) would get exactly the opposite of what is meant. --Marsupium (talk) 20:56, 2 November 2018 (UTC)
- I tend to agree, that’s why I did not support the deletion proposal. I guess we should put the constraints that the number of parts should be generally positive. Wondering if we need « don’t has part of that type » but I don’t think so. author TomT0m / talk page 21:06, 2 November 2018 (UTC)
- Keep I think it's very useful to be able to describe anatomically concepts exactly and "no value" doesn't do anything for those usecases. ChristianKl ❪✉❫ 14:47, 12 December 2018 (UTC)
- Keep per ArthurPSmith... strakhov (talk) 13:04, 19 December 2018 (UTC)
- This section was archived on a request by: --Pasleim (talk) 13:39, 1 January 2019 (UTC)
- 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.
- Keep. Created Wikidata property for a discontinued website (Q60457486) for such cases. We should expect more cases like this in the future.--Micru (talk) 11:27, 6 January 2019 (UTC)
Wall Street Journal topic ID (P3183): (delete | history | links | entity usage | logs | discussion)
This external id property is broken and also seems to be unfixable. Was deleted from enwiki on the same rationale https://en.wikipedia.org/wiki/Wikipedia:Templates_for_discussion/Log/2017_November_16#Template:WSJ_topic Gotitbro (talk) 21:44, 21 May 2018 (UTC)
- Comment You mean the formatter URL is broken? That doesn't necessarily mean the identifier is invalid. If there's more to this perhaps you can link to relevant documentation/discussion? ArthurPSmith (talk) 14:23, 22 May 2018 (UTC)
- @ArthurPSmith: WSJ seems to have discontinued the use of topical categories on its website so the formatter URL cannot be fixed at all. This property is deprecated. I have already linked the Engish Wikipedia discussion above. Gotitbro (talk) 11:09, 12 June 2018 (UTC)
- Delete if it was discontinued. Doesn't really seem to be used (~100).
--- Jura 14:14, 1 June 2018 (UTC) - Delete Ok, I'll go along with that, seems not much point to keep it now. ArthurPSmith (talk) 15:07, 13 June 2018 (UTC)
- Keep "the formatter URL cannot be fixed at all" Oh, really? I fixed it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:22, 22 June 2018 (UTC)
- Keep I don't see why we should delete a historic (at this point) identifier. Linking to the Wayback machine is a reasonable fix. I expect we will need to do this for many more external ID properties to come in the following years... --Azertus (talk) 19:35, 12 September 2018 (UTC)
- Comment I don't know if we can mark a property as deprecated so that it doesn't show up in the suggestions anymore? Users wanting to still add IDs could do so by pasting the property ID into the search box. --Azertus (talk) 19:37, 12 September 2018 (UTC)
- This section was archived on a request by: --Pasleim (talk) 13:10, 8 January 2019 (UTC)
- 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 --Pasleim (talk) 13:09, 8 January 2019 (UTC)
Soundex (P3878): (delete | history | links | entity usage | logs | discussion)
This property can be computed by clear and fast algorithm from other data. It's a very bad practice to store such data in a database.--Ignatus (talk) 10:04, 13 July 2018 (UTC)
- Will SPARQL provide a function for this?--GZWDer (talk) 10:53, 14 July 2018 (UTC)
- That's nothing impossible in providing such an extension function (in the Callimachus project they have keyword:soundex, we can have e.g. wikibase:soundex). I don't know how deep in the database interface levels it can be put, but the developers can be contacted to ask for it if it is needed (that is probable). This is longer to wait for but way more flexible then introducing any property, and, the main thing, duplicating data is evil. Ignatus (talk) 19:31, 14 July 2018 (UTC)
- Would you do the necessary to implement it and come back to us once it's done?
--- Jura 07:10, 15 July 2018 (UTC)
- Would you do the necessary to implement it and come back to us once it's done?
- Keep Calculating anything in SPARQL is a phenomenally bad move, to be avoided if at all possible. The whole reason SPARQL can be efficient is that it is based on fast indexed lookup searches. That's not possible with calculated values. Jheald (talk) 23:29, 14 July 2018 (UTC)
- Keep Wikidata isn't a purely relational database and the data doesn't have to be normalized - we have bots that can run simple calculations and keep things synchronized if that's appropriate. In general I'm sympathetic to avoiding duplication of data, but I think in this case it's a useful property to have even if easily calculated. A more valid concern I think would be if the way this is used does not fit in with wikidata internationalization (does the property only work for some languages or its value is ambiguous due to language differences?) but I don't think that's what's being argued here. ArthurPSmith (talk) 13:47, 16 July 2018 (UTC)
- Keep per Jheald and ArthurPSmith − Pintoch (talk) 19:39, 28 October 2018 (UTC)
- Comment In fact there is an internationalization concern. Soundex is only applicable to the English language. There are other phonetic algorithms optimized for other languages, e. g. Cologne phonetics for German or the French version of Soundex. Shouldn't there be a more general solution then? --Dealerofsalvation (talk) 11:21, 31 October 2018 (UTC)
- Delete I don't think this is a good fit for Wikidata as it can be calculated easily, is only applicable to the English language and will always be less accurate and incomplete than a calculated version. --Pyfisch (talk) 20:54, 1 December 2018 (UTC)
- Keep per ArthurPSmith --Flixwito^(•‿•)^ 07:21, 6 January 2019 (UTC)
- This section was archived on a request by: --Pasleim (talk) 13:09, 8 January 2019 (UTC)
- 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, excluding usage on "television series" and "films" items. The property should be relabeled to reflect the tighter scope. ·addshore· talk to me! 11:36, 14 January 2019 (UTC)
- 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. (See below to discuss topics related to the upcoming migration, don't start any mass changes yet.) Matěj Suchánek (talk) 14:48, 13 May 2017 (UTC)
Proposal: Merge original language of film or TV show (P364) and language of work or name (P407). During the last years, the FRBR system was more and more applied. In the FRBR system, separate items are created for the original work and its translated editions. This makes two language properties for works superfluous. Moreover, for original works there are no clear rules which of the two properties should be used. The result is that it is almost random which property one will see on an item.
Both properties are heavily used (P364 on 961.271 items, P407 on 1.315.110 items) but currently, there are less than 1000 items which are using P364 and P407 with different values [1].
previous discussion: Wikidata:Requests for deletions/Archive/2016/Properties/1#language of work or name .28P407.29 and original language of work .28P364.29 - closed as undecided.--Pasleim (talk) 14:14, 4 February 2017 (UTC)
- Keep, See Q19156152.--Arbnos (talk) 17:41, 4 February 2017 (UTC)
- The original language can be inferred from edition or translation of (P629), no need to duplicate the statement. --Pasleim (talk) 00:09, 5 February 2017 (UTC)
- Validate the property isn't being used in other projects (using
{{ExternalUse}}
) and if it is leave a message in Village pump of those projects! Please link to announcement in ruwiki, bawiki, cawiki, eswiki... Eran (talk) 22:13, 4 February 2017 (UTC)
- @ערן: This proposal only affects templates using P364 and P407 concurrently. I checked in advanced the templates and found only templates using either P364 or P407. Therefore, the impact on Wikipedia is marginal and informing template editors once a decision is taken here is more purposeful. --Pasleim (talk) 00:09, 5 February 2017 (UTC)
- Pasleim: Thanks, but I think you should involve WP communities early in such discussions as decisions here affects their templates and it may be hard to find all uses in templates/modules. For example ru:Модуль:Sources-utils use both of them so Vlsergey may give here good input. Eran (talk) 07:04, 5 February 2017 (UTC)
- To repeat myself, the decision here will only affect templates marginally. In ru:Модуль:Sources-utils one would simply need to remove either line 483 or 484. Inviting the whole ruwiki community to discuss about this single line is excessively. --Pasleim (talk) 08:09, 5 February 2017 (UTC)
- Pasleim: Thanks, but I think you should involve WP communities early in such discussions as decisions here affects their templates and it may be hard to find all uses in templates/modules. For example ru:Модуль:Sources-utils use both of them so Vlsergey may give here good input. Eran (talk) 07:04, 5 February 2017 (UTC)
- Support, I dont see heavy reason to keep them apart. - Kareyac (talk) 05:40, 6 February 2017 (UTC)
- Keep Although the rationale is rational, unfortunately both properties are heavily used (50+ templates each). Deleting without fixing all using templates is very negatively affecting reputation of Wikidata on the projects - already very negative experience with ill-fated sibling (P3373) deployment.--Jklamo (talk) 08:57, 6 February 2017 (UTC)
- @Jklamo: Fixing the templates is straightforward and fast done. With brother/sister there is the issue that templates are using brother AND sister. Lua functions have to be written to combine sibling (P3373) and sex or gender (P21) to get the old values back. With P364 and P407 this is different. There are only templates using either P364 or P407 or P364 with fallback to P407 (like in ru:Шаблон:Опера). Fixing all templates can be done within minutes by a single user and no modules have to be programmed.--Pasleim (talk) 10:13, 6 February 2017 (UTC)
- Delete I don't see a need for two properties here. However, the work to migrate everything to language of work or name (P407) (which I assume is the one that should remain) should be done before P364 is deleted! ArthurPSmith (talk) 21:07, 7 February 2017 (UTC)
- Question @Pasleim: What's about P2439 (P2439) ? The best is to move everything to the new property. I am in favor of the merge but as a third property was created we need to take it into account. Snipre (talk) 20:49, 8 February 2017 (UTC)
- Delete I never understand the difference between this two properties. Tubezlob (🙋) 21:08, 8 February 2017 (UTC)
- Delete as per nomination. Due to heavy usage of both this needs merging. 50.53.1.33 22:42, 9 February 2017 (UTC)
- Delete. I never understood the difference. Thierry Caro (talk) 23:46, 10 February 2017 (UTC)
- Delete idem Thierry Caro and Tubezlob. --Fralambert (talk) 23:28, 13 February 2017 (UTC)
- Keep Deleting the property can create problems when we describe literary works. For instance, if we want to say that Barn Jesus i en krybbe lå (Q11960227) exists in Norwegian (Q9043). In this instance we can use original language of film or TV show (P364) to say it is originally in Danish (Q9035) and language of work or name (P407) to say it exists in Norwegian (Q9043) and Danish (Q9035). Usually we would not like to split between Norwegian (Q9043) and Danish (Q9035) versions as this will result in missing language link on Wikipedia between similar topics. As another example consider Digte (Q23009890) that is a Danish book (edition) which contains original poems in Danish (and a Danish dialect) as well as translations of English poems to Danish. — Finn Årup Nielsen (fnielsen) (talk) 10:04, 15 February 2017 (UTC)
- @Fnielsen: You first example is typically something which has to follow the FRBR system. With your example how can you specify that the Danish version was first performed in XXXX and Norwegian version was performed for the first time in YYYY if everything is mixed in the same item ? And you are wrong about the lost link between both versions between one will be defined as translation of the other. For book we have the edition or translation of (P629) relation, so perhaps we need a more specific property or a generalization of edition or translation of (P629) to include songs but the same principle can be applied.
- Your second example is wrong too. Even if you have have only one edition of a book, you need to create 2 items: one for the work and one of the edition. In the work you specify the language and this is the original language, then for the edition, you specify the languages as Danish, English and Danish dialect. Using information from both work and edition you can determine again what is the original labguage and what are the translations with only one property language.
- A strict aplication of the FRBR system can handle all your cases. This just implies the creation of the correct items and to link them with the appropriate relations. Snipre (talk) 22:17, 17 February 2017 (UTC)
- @Snipre: It is more complex than your explanation. For Barn Jesus i en krybbe lå (Q11960227), we would like to have the Danish and Norwegian Wikipedia page linked as well as the Wikisource. And indeed that is what is the case for now: You have a Danish Wikipedia article and two Norwegian versions, e.g., Bokmål version, as well as a Danish Wikisource edition. If we start to split the Wikidata item for the Danish and Norwegian versions we loose the language links. The Wikipedia pages essential describe the same thing: A poem written by H.C. Andersen and translated to Norwegian.
- For Digte (Q23009890), there is a problem that it is a work containing translations along with original Danish poems, so the work is written in Danish and a Danish dialect, while the original language is Danish, the Danish dialect and English. This work is not an edition of any English book. — Finn Årup Nielsen (fnielsen) (talk) 08:13, 18 February 2017 (UTC)
- @Fnielsen: I understood your problems but again you are wrong because you want to stay in the old scheme of WP interwikis. I start again my explanation. By applying the FRBR system you can in any case retrieve all links you mentioned by using the WD properties instead of the interwikis. If you build correctly the items in WD you can always find all translations of a work in a language by using the appropriate properties. The advantages of WD structure is the possibility to add specific informations to a translation. This is not possible if you mix everything in the same item. Again take the example of the first publication date of your first Norwegian version: you don't have a property "publication date of the edition" and another "publication date of the original work". So why do you wantto use a special structure for the language and not for the publication date ?
- If we go further in your first example, you have 3 editions, one Danish (original) and two Norwegians. So this represents 4 items, one for the work, one for the first original version in Danish and two for each Norwegian versions. You can link the three editions to the work item so you are then able to retrieve the link between all items and their associated interwikis even if the interwikis are not linked to an unique item. You loose nothing, you just need to extract the links between items with a query based on a property.
- For your second example, you have two items, one for the work and one for your special edition. The work provides the original language and the edition mentions the three languages so you are always able to define the original language by extracting the language of the work edition and you can still define that your edition was a mix of three languages as the three language will be mentioned in the edition item. Got it or do I have to use a table to explain the FRBR system ? The idea of the FRBR system is to separate the common data for all existing editions of a work in a special item. The original language is one of these general data like the author. Advantages of the system ? If you have 20 different editions or translations, you don't need to write in each edition/translation item, the original language or the name of the author as these data are available in the work item connected to all edition/translation items with a property. Disavantages ? You have to create always at least two items even if you have only one edition. Snipre (talk) 23:19, 20 February 2017 (UTC)
- Delete overkill and confusing. — billinghurst sDrewth 11:40, 3 March 2017 (UTC)
- Keep. Someone can explain how manage the original language of a movie and the dubbed version? I mean "Gone with the Wind" must have original language of film or TV show (P364)=English but if we create the Italian dubbed version ("Via col vento") we must use language of work or name (P407)=Italian. With 2 property we can do a query like: "all the audiovisual work" with "Original language" in English and dubbed/translate in Croatian. --ValterVB (talk) 09:26, 12 March 2017 (UTC)
- @ValterVB: Please have a look at the reference in movie structure: Wikidata:WikiProject_Movies/Properties#dubbing. So from that structure, you can see that each dubbed movie has a dedicated item which is different from the original one and then there is a link from the dubbed movie item with the original movie item using the property edition or translation of (P629). So you can extract the original language from the original movie item using this relation.
- This is the principle of the FRBR system. Snipre (talk) 20:22, 12 March 2017 (UTC)
- @ValterVB: I created Via col vento (Q29478369) and Via col vento (Q29478260). How is in this case original language of film or TV show (P364) and language of work or name (P407) needed? --Pasleim (talk) 13:34, 19 April 2017 (UTC)
- @Pasleim: How we can connect Gone with the Wind (Q2875) with Via col vento (Q29478369) and Via col vento (Q29478260) without SPARQL that don't work in template/infobox? --ValterVB (talk) 17:36, 19 April 2017 (UTC)
- The specific implementation im templates depends on Module:Wikidata (Q12069631). Using the Wikidata version of it, a template could use
{{#invoke:Wikidata|formatStatementsE|property=P407|item={{#invoke:Wikidata|formatStatementsE|property=P747|item=Q2875|displayformat=raw|numval=1}}}}
to show the language of dubbed versions. --Pasleim (talk) 18:24, 19 April 2017 (UTC)
- The specific implementation im templates depends on Module:Wikidata (Q12069631). Using the Wikidata version of it, a template could use
- @Pasleim: How we can connect Gone with the Wind (Q2875) with Via col vento (Q29478369) and Via col vento (Q29478260) without SPARQL that don't work in template/infobox? --ValterVB (talk) 17:36, 19 April 2017 (UTC)
- Comment I don't understand why translation of movies or audio-books should be different from textual mediums. Via col vento (Q29478369) looks fine to me. d1g (talk) 06:29, 1 May 2017 (UTC)
- merge both of them with P2439 (P2439) & Delete, per Snipre. Strakhov (talk) 21:27, 18 March 2017 (UTC)
- Comment I think we had this discussion before and ended up keeping both properties. This seems to create some problems for written works and books they are published in, but it's needed for films. There was a lengthy discussion about this on the Wikiproject for the later.
As for written works, it's seems odd that the situation couldn't be resolved with the existing structure (try subproperties) and why it would be resolved by merely deleting it. Merely citing some abstract approach one might not have read or be able to apply to a random book on Wikidata isn't really going to help us on everything. Maybe we need a new WikiProject that tries to actually create items for written works in a consistent way.
Neutral on its uses on written works. Keep for films.
--- Jura 06:32, 13 April 2017 (UTC)
- @Jura1: "Maybe we need a new WikiProject that tries to actually create items for written works in a consistent way": we have Wikidata:WikiProject Books which proposes a coherent system, the Functional Requirements for Bibliographic Records (FRBR) model. We just need to stop discussing and start to use the model with deletion of unnecessary properties which just create confusion. Snipre (talk) 16:06, 13 April 2017 (UTC)
- Maybe you could outline your plans there and detail what items you want to create and what currently prevents you from creating new items: https://www.wikidata.org/w/index.php?limit=100&title=Special%3AContributions&contribs=user&target=Snipre&namespace=0&tagfilter=&newOnly=1&year=2017&month=3 . Your activity seems somewhat limited. If you need to be reassured about Climate Change 2013 - The Physical Science Basis (Q28324305), it's ok in terms of what we expect you to do when creating items. Don't hesitate to create a few more. If you have specific questions about the item, I'd be happy to help.
--- Jura 17:37, 13 April 2017 (UTC)
- Maybe you could outline your plans there and detail what items you want to create and what currently prevents you from creating new items: https://www.wikidata.org/w/index.php?limit=100&title=Special%3AContributions&contribs=user&target=Snipre&namespace=0&tagfilter=&newOnly=1&year=2017&month=3 . Your activity seems somewhat limited. If you need to be reassured about Climate Change 2013 - The Physical Science Basis (Q28324305), it's ok in terms of what we expect you to do when creating items. Don't hesitate to create a few more. If you have specific questions about the item, I'd be happy to help.
- @Jura1: Could you please link to the lengthy discussion where it was concluded that P364/P407 are needed for films? Merely citing some abstract approach one might not have read or be able to apply to a random book on Wikidata ... Could you justify this statement by considering that the FRBR system is used on more items than the mingle-mangle with P364/P407. --Pasleim (talk) 13:36, 19 April 2017 (UTC)
- @Jura1: "Maybe we need a new WikiProject that tries to actually create items for written works in a consistent way": we have Wikidata:WikiProject Books which proposes a coherent system, the Functional Requirements for Bibliographic Records (FRBR) model. We just need to stop discussing and start to use the model with deletion of unnecessary properties which just create confusion. Snipre (talk) 16:06, 13 April 2017 (UTC)
- Keep per all "keep" above, it's still not safely to split movie items only because of FRBR. --Liuxinyu970226 (talk) 05:00, 20 April 2017 (UTC)
- == Active users == ValterVB LydiaPintscher Ermanon Mushroom Queryzo Danrok Rogi Mbch331 Jobu0101 putnik AmaryllisGardener Andreasmperu U+1F350 Bodhisattwa Shisma Wolverène Tris T7 Antoine2711 CptViraj ʂɤɲ Trivialist 2le2im-bdc Sotiale Wallacegromit1, mostly focus on media historiography and works from the Global South M2k~dewiki Rockpeterson Mathieu Kappler Sidohayder Spinster Gnoeee Ranjithsiji Ontogon Supaplex Carlinmack Haseeb Demadrend Jakeob9000 RealityBites Sriveenkat Keplersj dseomn Fuzheado BeLucky DaxServer PaperHumanNotified participants of WikiProject Movies --Liuxinyu970226 (talk) 05:06, 20 April 2017 (UTC)
- @Liuxinyu970226: "it's still not safely to split movie items only because of FRBR". It is not a question of FRBR, it is a question of logic: if you have a dubbed movie, in which item do you find the list of the actors of the original movie ? In the item dedicated to the original movie, you don't have a property "original actor"; in which item do you find the original release date of the original movie ? In the item dedicated to the original movie, you don't have a property "original publication date"; in which item do you find the original title of the original movie ? In the item dedicated to the original movie, you don't have a property "original title"; so why do you need an original language property in the dubbed movie item when you look for 90% of the data of the original movie in the item of the original movie ? What you are doing is just data duplication leading to potential errors due to unsynchronization. I think you don't understand the features of a database where 1) the data structure has to be always the same in order to create efficent queries (so you have to create the whole set of original properties (original title, original director,...) and you copy everything in the dubbed movie item or you separate all the data in the respective items without duplicating statements), 2) data should not be duplicated in order to avoid contradictions when somebody corrects one statement or not the others. WD is a database, not an WP article where all the data you want are in the same item. Snipre (talk) 23:46, 24 April 2017 (UTC)
- Delete We don't need two properties either for films as all known movie databases use a single value "language". Queryzo (talk) 05:57, 20 April 2017 (UTC)
- @Queryzo: You mean some may store language once with the film and once for translated titles with the same property? Unfortunately we can't do that.
--- Jura 18:36, 30 April 2017 (UTC)- We don't need a property for translated titles. Queryzo (talk) 19:40, 30 April 2017 (UTC)
- We could use qualifiers, of course, but in flat-structured environment like Wikidata, this tends to lead to a mess.
--- Jura 19:56, 30 April 2017 (UTC)
- We could use qualifiers, of course, but in flat-structured environment like Wikidata, this tends to lead to a mess.
- @Queryzo: You mean some may store language once with the film and once for translated titles with the same property? Unfortunately we can't do that.
- migrate P407 and P364, keep P2439 because 1. queries would be easier with one property (P2439). 2. information about edition or translation should be separated from work item (= original work) per every edition or translation.
- Le Prophète (Q19156152) should have "in French" value, while The Prophet (Q4380917) only with "in Russian" value.
- it is possible to access any edition using edition or translation of (P629) and has edition or translation (P747) properties, not just translations. "language-related" properties doesn't solve it as well as direct "edition of"/"editions:" links. d1g (talk) 06:19, 1 May 2017 (UTC)
Relation with P2439 (P2439)
- 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.
- The fate of this property has not been determined. Feel free to start another dicussion or request later. Matěj Suchánek (talk) 14:20, 9 July 2017 (UTC)
Meanwhile, we have got a new property P2439 (P2439). Its usage is marginal compared to these two properties, that's why I haven't mentioned it in the conclusion. But I think we have a good opportunity to make another decision about this one. Matěj Suchánek (talk) 14:48, 13 May 2017 (UTC)
- @Matěj Suchánek: Do we reaaly need a discussion about the fate of P2439 (P2439) ? This is clear that this property should be merged with the future unique property. Snipre (talk) 20:19, 28 May 2017 (UTC)
- No, it's not mandatory at the moment. But I thought we could benefit from the current attention and make a decision on it as well. Matěj Suchánek (talk) 07:20, 29 May 2017 (UTC)
Recipient
- 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.
- original language of film or TV show (P364) (original language) is going to be deleted. Matěj Suchánek (talk) 14:22, 9 July 2017 (UTC)
Which property will stay? I'm leaning to keeping language of work or name (P407) since it's used more often and its labels make its scope wider. Matěj Suchánek (talk) 14:48, 13 May 2017 (UTC)
- The labelling of the new property has to simplified: the current one is just creating confusion if the contributor want to specify the language of something which is not a work or a name, or something the contributor can't assimilate to a work or a name. Whats should he do ? Looking for another property ? Proposing the creation of a new property ? The best to simplify the future unique property with "language" only. The best is to delete original language, with the following rules
- if in one item the property "original language" is used:
- convert it into "language of work or name" if no existing statement using "language of work or name" is found
- delete it otherwise
- Snipre (talk) 20:04, 13 May 2017 (UTC)
- keep language of work or name (P407) and delete original language of film or TV show (P364) since P407 is slightly more used than P364 and it has a wider formulation. --Pasleim (talk) 20:44, 16 May 2017 (UTC)
Migration
Given that both properties have some external usage, how should the migration proceed? Should we create a timetable? (Announcing in WD:Status updates/Next is essential.) Matěj Suchánek (talk) 14:48, 13 May 2017 (UTC)
- announce the migration in WD:Status updates/Next
- copy over all values of "original language" to "language of work or name" but don't yet delete the "original language" statements
- fix all templates
- remove all "original language" statements and delete property
- I can help with all steps including fixing the templates on other projects --Pasleim (talk) 20:44, 16 May 2017 (UTC)
- Agree with this steps. Just to avoid error: we keep Property:P364 and delete Property:P407, correct? --ValterVB (talk) 16:50, 17 May 2017 (UTC)
- @ValterVB: Nope, the opposite (discussed in the section above). Matěj Suchánek (talk) 14:40, 20 May 2017 (UTC)
- Agree with this steps. Just to avoid error: we keep Property:P364 and delete Property:P407, correct? --ValterVB (talk) 16:50, 17 May 2017 (UTC)
- @Pasleim: Your proposition will create multiple opposing statements in the same item: what happens if one item about an edition has one statement original language of film or TV show (P364) and one statement language of work or name (P407) ? With your scenario, you will just create 2 statements for language of work or name (P407) and one will be wrong. You can't separate the conversion and the deletion process
- announce the migration in WD:Status updates/Next
- launch the migration with the following analysis:
- if in one item the property "original language" is used:
- convert it into "language of work or name" if no existing statement using "language of work or name" is found in the item
- delete it otherwise
- if in one item the property "original language" is used:
- No need of fixing templates to perform that action. Templates can be fixed later without any lost if the correct work/edition model was used in WD. If someone created the edition item without the work item, no template fixing will solve the data lost because you will need to create the work item first. So the problem is not template fixing but incorrect data modeling in WD. Snipre (talk) 20:13, 28 May 2017 (UTC)
- @Matěj Suchánek, Pasleim, ValterVB: Do you think we can proceed now for property merge ? Snipre (talk) 20:13, 28 May 2017 (UTC)
- Your approach looks good to me, I think we are mostly ready. Matěj Suchánek (talk) 07:48, 2 June 2017 (UTC)
- I added "(DEPRECATED)" mark to original language of film or TV show (P364) just now. --Liuxinyu970226 (talk) 04:39, 13 June 2017 (UTC)
- It seems the situation on books is a thoroughly confused and no basic statistics on it's status are available. See Wikidata talk:WikiProject Books. Before doing an merges, one should ensure an action plan is available to clean this up. Otherwise the merger just confuses the situation further. It appears that the scheme suggested at Wikidata:WikiProject Books can't be implemented in practice and a new approach may be needed, possibly with enhanced Wikibase features for relevant Wikidata items.
--- Jura 10:50, 8 July 2017 (UTC)- If missing statistics are indeed bothering you, here you have it:
- Items with P364 OR P407 statements: 1.337.876
- Items with P364 AND P407 statements: 13.674
- Items with identical P364 and P407 values: 12.171
- biggest classes: album (Q482994): 3558, film (Q11424): 1922, periodical (Q1002697): 1842, book (Q571): 1087, creative work (Q17537576): 1006, media (Q340169): 534
- Items with conflicting P364 and P407 values: 1.503
- biggest classes: poem (Q5185279): 256, translation (Q7553): 243, book (Q571): 209, film (Q11424): 186, version, edition or translation (Q3331189): 155, literary work (Q7725634): 66, musical work (Q2188189): 46, game (Q11410): 43, work of art (Q838948): 36
- Items with identical P364 and P407 values: 12.171
- The problem is not the number of items as such, but the relevancy of the language statement to the group of items. For films, things are clear, but might get messed up if you merge. For books, I don't think we have a clear vision what we want and how we get there. Merely stating some have P364 or P407, some sort of identifier about a random edition and sitelinks to a Wikipedia article about the work will make us loose information.
--- Jura 17:45, 8 July 2017 (UTC)
- If missing statistics are indeed bothering you, here you have it:
- For books, the problem may be that many items for editions don't have an item for the work. For all values with "original language of work" (P364) such items would need to be created.
--- Jura 14:49, 9 July 2017 (UTC)- Jura convinced me that the situation around books should get more attention. I found many cases of items containing data about both work and the edition. (Well, they mostly seem to represent editions, eg. they have translator (P655) but they also contain data about the original work, eg. original language of film or TV show (P364) or instance of (P31). Perhaps a bot could help here.)
- Nevertheless, the property should be marked as deprecated, so that we have additional means of preventing arbitrary new usages. Matěj Suchánek (talk) 11:30, 10 July 2017 (UTC)
- I'm fine with doing this for books (as it's already done), but if we mark it as such for any item, people may start introducing incorrect data for other items. For books, I think a plan should be worked out how to split these items if people are actually interested in using the model proposed at its WikiProject. An alternative solution may be to develop a property datatype that could more easily hold information for various ISBN.
--- Jura 05:44, 13 July 2017 (UTC)
- I'm fine with doing this for books (as it's already done), but if we mark it as such for any item, people may start introducing incorrect data for other items. For books, I think a plan should be worked out how to split these items if people are actually interested in using the model proposed at its WikiProject. An alternative solution may be to develop a property datatype that could more easily hold information for various ISBN.
- > various ISBN
- ISBN doesn't exist in 300BCE.
- This would take far more time than current properties with multiple items and not necessary better than current 629+747+language 05:21, 24 July 2017 (UTC)
- So how do we handle collected translations, where there is an original language, but NOT an original work? In particular it is common for translators to publish the surviving plays of Pautus as a collection, or the surviving fragments of Cratinus, but these items never had an original "work" to come from. The modern translation(s) are collected as a volume that is a translation, but not of any particular work. --EncycloPetey (talk) 00:23, 23 July 2017 (UTC)
- Use properties that don't assume any works: P2439 (P2439) 04:01, 24 July 2017 (UTC)
- It looks like we still lack a status and a clear plan for books. This is really problematic as it has a negative impact on other fields.
--- Jura 07:12, 23 July 2017 (UTC)- From my own experience, the biggest problems I run into involve dealing with translations of works, and dealing with collected works. Most of the decisions and properties have been made assuming (incorrectly) that (a) there will always be an "original work" from which a translation/edition will come, (b) that translations never have intermediary translations. They also fail to account for (c) editions of translations (a book that is a translation or contains translations, which book is then printed in editions), and (d) collections of works, which may exist in editions, and whose components are themselves translations and/or editions. --EncycloPetey (talk) 20:12, 23 July 2017 (UTC)
- that's why several users voted to keep only most generic property (P2439 (P2439))
- a, b - remove 364 (and possibly 407)
- c - not relevant here, use edition or translation of (P629) and has edition or translation (P747)
- d - use P629 and P747 and P2439 in any possible combination.
- @EncycloPetey: any single example when many items with P629 and P747 and P2439 not able to represent information? d1g (talk) 04:21, 24 July 2017 (UTC)
- I think the biggest challenge we face here is the casual dismissal of issues without meaningful discussion. D1gggg, I have to say I don't have much confidence in your suggestions, because it's clear from other edits that you don't know much about library data or the Wikidata properties you're using. You've added entirely the wrong property on more than one occasion, have altered project pages without consensus, and fail to sign your posts frequently. This shows unfamiliarity with the system. So, I will need to hear from more people with greater experience. Your responses above also show that you either do not understand the issues involved, or have not thought about the consequences. How will the data represent the "original language" in a situation like "c", which you claim is "not relevant here"? If we have editions of translations of works, that whatever system is retrieving the data to get the original language, it will have to know somehow to climb more than one step back to get that data. --EncycloPetey (talk) 14:17, 24 July 2017 (UTC)
- @EncycloPetey: The proposed system isn't a problem for translated editions:
- 1) "there will always be an "original work" from which a translation/edition will come". The model used for book is FRBR which is quite widely used. If we decide to use this system, we have to create the corresponding structure so if for one item about a translation we don't have to create one item which will be the work one. But for that we have start the migration in order to avoid people to continue to use the wrong model.
- 2) The current system with 2 language properties doens't help you to model the case you mentioned:
- A is a transaltion edition in French of B
- B is a transaltion edition in German of C
- C is the first edition in the original language English
- What is the original langauge for A ? German or English ?
- That's why the current system is wrong, because it collects data from different items in one item instead of keeping data separetely in the correct items and to use link between items to extract the data you need.
- We miss probably a property for items about translated editions which allow to identify which is the edition (in the original lnaguage or not) used as reference for the translation but this problem is not relevant for our present languages problem as the original langague property doesn't help you to solve the problem of intermediary translations.
- For the two last points you mentioned there is a need for additional properties but at the end having 2 languages properties don't help you to solve the problem you mention. I think your points should be discuss with the project Wikidata:WikiProject Books but not here in that discussion unless you can show how 2 languages properties can help to solve the problems you mentioned. Snipre (talk) 18:44, 24 July 2017 (UTC)
- @Snipre: I don't think you've understood some of the issues I raised:
- 1) There will NOT always be an "original work". And there is a real problem using translation/edition interchangeably. These two problems create most of the issues I have dealing with translations. Perhaps I need an actual example:
- A is the "edition" item for the 4th edition of Swanwick's "Tragedies of Sophocles".
- B is the "translation" data item for Swanwick's "Tragedies of Sophocles".
- But B is a translation of C, D, E, F, G, H, & J, which are all separate data items for the "works" by Sophocles in the original ancient Greek.
- So, is B a "work" because it has multiple editions? Or is it an "edition" because it is a translation of another author's works? And to return to the issue at hand: C, D, E, F, G, H, & J were are all originally written in ancient Greek, but as works they have no language at all. Only specific editions will be written or published in a particular language; even the first edition published or written. And any bot or tool that pulls data from this structure (by the current proposal) would run into difficulties, since, A and B are in English, and if A is an "edition" of B, how will it be indicated that English is not the original language when the data is extracted? We have a three-tiered hierarchy in these situations, but our model assumes that the hierarchy always has only two levels. --EncycloPetey (talk) 19:09, 24 July 2017 (UTC)
- @EncycloPetey: What's "translation" data ? I think you are not able to describe your problem. Is it book, an eletronic file, a scroll or different parts of a scroll or even different parts from different scrolls ? Data doesn't mean any thing at that level. Snipre (talk) 19:19, 24 July 2017 (UTC)
- @Snipre: You misunderstood. I did not say "translation data", I said "translation data item": A data item for the translation. The translation is a translation/work, and has four editions. Works are never physical objects, only specific editions of works have physical forms. The work itself can appear in any form: printed, electronic text file, audio recording, or performance. So it makes no sense to ask whether the translation is a book, file, scroll, etc. This is the fundamental problem in dealing with books that I keep trying to point out. Our labelling is fuzzy concerning the distinction between works, translation, editions, etc. --EncycloPetey (talk) 14:51, 25 July 2017 (UTC)
- @EncycloPetey: So again what is B ? What is C ? Books ? Scroll ?
- Then a book can't be a translation of several other books: it can contain translated parts from other books/documents but in that case, if the translated book is composed of several translations coming from different document, it is a new work compared to those documents, because the choice of the translations is a creative choice. I don't see any difficulty to treat your case, what is missing in your case is a link to other documents as inspired by (P941), based on (P144) or after a work by (P1877). A compilation of works is a new work. Snipre (talk) 20:12, 2 August 2017 (UTC)
- @Snipre: RE: So again what is B ? What is C ? Books ? Scroll ? I say again: C is a work; it is not an instance of that work, but a work itself. It is not a scroll, nor a book, nor anything physical. To ask whether it is a book or scroll, etc. it to completely fail to understand what a work is. Only the editions of works can be a book, scroll, performance, etc. B is a translation of C, and this is where we run into specifics of the problem. If a translation is treated as an edition, then it must have specific edition data such as a year of publication, but if translations are treated like works, then the translation can exist in multiple editions (as it often does), but in that case it is not a book, scroll, etc. as works have no physical form. This is in fact why translations are troublesome to enter. If I have a translation that exists in different editions as a book, as a chapter, as the right-hand pages of a book, or as an audio file, then the data item for the translation cannot be specified to exist in any particular form. So, again, B is not a book or scroll or anything you could hold or point to; it is a translation. Likewise, C is not a physical object, but is the original work. I am sorry that you cannot understand the difficulty. --EncycloPetey (talk) 20:37, 4 August 2017 (UTC)
- @EncycloPetey: The main problem is you don't used usual WD terminology with your "edition data item" or "work data item". We just use work item or edition item. In WD, an item is a collection of data, so when you say "edition data item", this gives something like "a collection of data about data of an edition". If you use your own definitions then don't be surprised to be not understandable.
- And finally your problem is you don't do any difference between a book which is a translation of a work and a book which contains a translation of a work. In the second case the book contains more than the translation of the work so it can be considered only as translation of that work but is something different so you need another property to link the book to the different works it contains typically "has part". This solves the problem of antologies or other collections you mentioned in the first time.
- Still stays the question of a new edition of a previous translation. In that case just take the FRBR model and consider that the edition definition corresponds to the manifestation definition of the FRBR model and we don't use the expression level of that model.
- So example:
- A is a work, B is the 1st edition in the original language, C is a translation of the 1st edition
- In a logical scheme C is not a translaion of the work, but a translation of an edition in the original language. In your system you should create an additional item D which is the work of the translation and represents this system with:
- D is a translation of A, C is a translation of B, B is an edition of A and C is an edition of D. And then you need a aditional property to link C and A. But this latter link is what most of people working with WD want to have.
- This creates more complexity for a minimal added value. So in WD, if you have W is a work, X is the 1st edition of W in the original language, Y is a translation of X and Z is a reedition of Y, then X, Y, Z and edition of W and to create the link between X, Y, Z you need new properties like "translated from" (Y translated from X) and "reedition of" (Z is a reedition of Y).
- In WD we choose to keep the system simple and to avoid to create to many abstract items like the ones you mentioned (translation defined as work).
- So is the WD system clear for you ? Snipre (talk) 23:32, 7 August 2017 (UTC)
- @Snipre: I'm sorry that you still don't understand. You're giving examples that have no application for the works I have to deal with. In your example, you say that "B (or X) is the 1st edition in the original language", but there lies one of the problems with the translations of classical literature: there is no 1st edition available anywhere. What we have are dozens of edited editions in the original language that have been reconstructed from medieval or Renaissance manuscripts, where these various editions and manuscripts all differ from each other. Sometimes, a translator will rely on a particular original language edition, but most often they will not. So there is no means of tying most translations to any specific edition printed in the original language. With that link in the chain broken, your entire proposal falls apart at the very first link. So, no the WD system is neither clear nor usable as you have described it, and that is why I have raised the issue of dealing with translations. --EncycloPetey (talk) 00:24, 8 August 2017 (UTC)
- @Snipre: RE: So again what is B ? What is C ? Books ? Scroll ? I say again: C is a work; it is not an instance of that work, but a work itself. It is not a scroll, nor a book, nor anything physical. To ask whether it is a book or scroll, etc. it to completely fail to understand what a work is. Only the editions of works can be a book, scroll, performance, etc. B is a translation of C, and this is where we run into specifics of the problem. If a translation is treated as an edition, then it must have specific edition data such as a year of publication, but if translations are treated like works, then the translation can exist in multiple editions (as it often does), but in that case it is not a book, scroll, etc. as works have no physical form. This is in fact why translations are troublesome to enter. If I have a translation that exists in different editions as a book, as a chapter, as the right-hand pages of a book, or as an audio file, then the data item for the translation cannot be specified to exist in any particular form. So, again, B is not a book or scroll or anything you could hold or point to; it is a translation. Likewise, C is not a physical object, but is the original work. I am sorry that you cannot understand the difficulty. --EncycloPetey (talk) 20:37, 4 August 2017 (UTC)
- @Snipre: You misunderstood. I did not say "translation data", I said "translation data item": A data item for the translation. The translation is a translation/work, and has four editions. Works are never physical objects, only specific editions of works have physical forms. The work itself can appear in any form: printed, electronic text file, audio recording, or performance. So it makes no sense to ask whether the translation is a book, file, scroll, etc. This is the fundamental problem in dealing with books that I keep trying to point out. Our labelling is fuzzy concerning the distinction between works, translation, editions, etc. --EncycloPetey (talk) 14:51, 25 July 2017 (UTC)
- @EncycloPetey: What's "translation" data ? I think you are not able to describe your problem. Is it book, an eletronic file, a scroll or different parts of a scroll or even different parts from different scrolls ? Data doesn't mean any thing at that level. Snipre (talk) 19:19, 24 July 2017 (UTC)
- @EncycloPetey: I understood your problem: WD community doesn't model the data in order to fit your problem because your translation problem is not relevant for the community objectives. Do you understand that there are different ways to model data and you choose the one which fit the objectives you want to reach ? WD model currently doesn't take care about the sequence of the translations or if a translation was based on two or three originals which were partially recovered. ONCE AGAIN, WD doesn't care about the relations between the different editions or translations. perhaps later we will try to do solve the problem you mentioned and we will create new properties to be able to create that relations.
- You don't understand that WD is a top level ontology and not a specialized ontology: we are not describing only books but animals, planets and comics. We want to reach a certain level of details but without having to deal with a heavy model with data relevant only to specialists.
- Saying that "the WD system is neither clear nor usable as you have described it" just indicates you don't know the purposes of WD concerning bibliographical data: citation. So we choose an appropriate model for that. If you want to be useful for this community try to understand what are the objectives of WD, which are perhaps not the same like yours. And if you really want to propose a new model which is able to solve the problem you mentioned, don't spent time here: go to Wikidata:WikiProject Books, propose your model there and convince people to use it. Currently I am trying to apply the model described on that page and which was accepted by a relative majority of the WD community, so if you don't like it please go there and try to change it there. You will save your time and the time of other contributors. Snipre (talk) 01:19, 8 August 2017 (UTC)
- {@Snipre: No, you didn't understand my problem, and as I pointed out, the model you propose above demonstrates strongly that you do not understand. Claiming that you understood all along, and claiming that I am the one who does not is simply avoiding the discussion by moving the goalposts and does not advance the discussion.
- Right now, there is no model for translations at Wikidata:WikiProject Books which is part of the reason I have my problem and am trying to get it addressed and solved. But each time I state the problem, people (such as yourself) first claim there is no problem, then claim that the problem is easily solved, and finally admit that the problem exists and is not easily solved, but then claim instead that it is not important after all. Look back through your own comments above, and this same pattern of response occurs. If you cannot see a solution, that is fine, but please do not simply dismiss the issue on false pretense. --EncycloPetey (talk) 02:28, 8 August 2017 (UTC)
Danish works
Looks like @Fnielsen: is still focusing on adding original language of film or TV show (P364) even duplicate language of work or name (P407) values, I don't know what's wrong within Danish that is not OK to lose original language of film or TV show (P364). --Liuxinyu970226 (talk) 23:57, 26 July 2017 (UTC)
- How would we describe Digte (Q23009890) (regardless of whether it is a work or a version, edition or translation (Q3331189)) without both original language of film or TV show (P364) and language of work or name (P407)? — Finn Årup Nielsen (fnielsen) (talk) 07:44, 27 July 2017 (UTC)
Should I copy suggestions from Snipre that is archived above? --Liuxinyu970226 (talk) 08:22, 27 July 2017 (UTC)- @Fnielsen: IMHO, I have an idea that describe that thing that without original language of film or TV show (P364) but with language of work or name (P407), and perhaps no splitting needed:
- 1. Allowing loop-back value of edition or translation of (P629) (i.e. adding Digte (Q23009890)edition or translation of (P629)Digte (Q23009890)) (note that country (P17) is such allowed in sovereign states items), with qualifiers:
- a. (may only available after description re-designing, or maybe new datatype needed) start point (P1427)Danish (Q9035)
- b. (ditto, :p) terminus (P559)English (Q1860)
- c. Wikidata usage instructions (P2559)This work item cannot be splitted, as it has English contents that are in conjunction with original Danish contents, and per the will of author those contents are just included in one work
- 2. language of work or name (P407)Danish (Q9035) PRIORITY: Preferred rank
- 3. language of work or name (P407)English (Q1860) PRIORITY: Normal rank
I wish you to understand this alternate. --Liuxinyu970226 (talk) 02:04, 28 July 2017 (UTC)
- We need to make sure that we don't loose any information. Until a clear plan is available, the best approach is to continue as of now, as said: no large scale changes should be made before.
--- Jura 07:08, 28 July 2017 (UTC)- @Snipre: It still needs your suggestion to resolve problems here. --Liuxinyu970226 (talk) 14:17, 4 August 2017 (UTC)
- I added to Digte (Q23009890) all works it compromises by using has part(s) (P527). This allows now to exactly determine which parts of the collection have original language Danish and which parts are translations from English. --Pasleim (talk) 23:06, 4 August 2017 (UTC)
- @Liuxinyu970226: Pasleim solved partially the problem: the final step is to delete the original language statements which just means nothing in that case. The English versions of the poem were translated from Danish or from Jutlandic dialect but not from Danish AND Jutlandic dialect. I am quite confident to think that in reality the original version of the poems is in Jutlandic dialect which were translated in Danish. But the current data structure doesn't provide any corretc information about the relation and just add confusion because we mix data: we mix data about the book with data about the poems. Each time you go further into the details you have to create item and not adding more and more informations in the general items. Just take the example of a village: you don't add data about the village in the country item where the village is located in. If the original language is different for each poem, the current statment current statement Original language = Danish/Jutlandic dialect is wrong because it is imprecise. That's why you shouldn't not mix data: the book is in English/Danish/Jutlandic dialect, that's a fact. Then for the original language we have to create an new item for the document which was used as original text or at least to provide the correct process: the poems author wrote them in one language and then translated them in another language, so be accurate and provide the correct sequence. And if you don't know the correct sequence don't write wrong information. Snipre (talk) 00:32, 8 August 2017 (UTC)
- @Snipre: That approach only works when there is only one document which was used as original text, and when we know exactly which document that is. For translations of whole books written in the modern era, that is usually possible, but it is not possible for most older texts where all the available source texts were used, or where the "original" is either not identified or never existed in written form. Even for a well known work like Shakespeare's Romeo and Juliet, there is no single source text used for modern editions or translations. All modern English editions of the play are amalgamations of several early texts, and translators seldom identify which edition(s) they worked from. --EncycloPetey (talk) 01:13, 8 August 2017 (UTC)
- @EncycloPetey: "That approach only works...when we know exactly which document that is." If you don't know exactly, don't write unsourced information. If an Italian translation of an older Greek document is not known has being translated from the original Greek document in Greek, don't write that the original version form of the Italian translation is Greek, because the translation was perhaps done from Latin. WD doesn't deal with some hypothetical possibilities but with facts. So if you don't know what was the original version used for a transaltion, don't add wrong information. Snipre (talk) 01:42, 8 August 2017 (UTC)
- @Snipre: That approach only works when there is only one document which was used as original text, and when we know exactly which document that is. For translations of whole books written in the modern era, that is usually possible, but it is not possible for most older texts where all the available source texts were used, or where the "original" is either not identified or never existed in written form. Even for a well known work like Shakespeare's Romeo and Juliet, there is no single source text used for modern editions or translations. All modern English editions of the play are amalgamations of several early texts, and translators seldom identify which edition(s) they worked from. --EncycloPetey (talk) 01:13, 8 August 2017 (UTC)
- @Liuxinyu970226: Pasleim solved partially the problem: the final step is to delete the original language statements which just means nothing in that case. The English versions of the poem were translated from Danish or from Jutlandic dialect but not from Danish AND Jutlandic dialect. I am quite confident to think that in reality the original version of the poems is in Jutlandic dialect which were translated in Danish. But the current data structure doesn't provide any corretc information about the relation and just add confusion because we mix data: we mix data about the book with data about the poems. Each time you go further into the details you have to create item and not adding more and more informations in the general items. Just take the example of a village: you don't add data about the village in the country item where the village is located in. If the original language is different for each poem, the current statment current statement Original language = Danish/Jutlandic dialect is wrong because it is imprecise. That's why you shouldn't not mix data: the book is in English/Danish/Jutlandic dialect, that's a fact. Then for the original language we have to create an new item for the document which was used as original text or at least to provide the correct process: the poems author wrote them in one language and then translated them in another language, so be accurate and provide the correct sequence. And if you don't know the correct sequence don't write wrong information. Snipre (talk) 00:32, 8 August 2017 (UTC)
- I added to Digte (Q23009890) all works it compromises by using has part(s) (P527). This allows now to exactly determine which parts of the collection have original language Danish and which parts are translations from English. --Pasleim (talk) 23:06, 4 August 2017 (UTC)
- @Jura1: Unfortunately, we still have some editors making major changes to many entries, such as User:Pasleim. --EncycloPetey (talk) 23:42, 6 August 2017 (UTC)
- @EncycloPetey: I'm cleaning up items which mix work with edition/translation. You can not abuse this discussion here to stop the whole Wikidata:WikiProject Books. --Pasleim (talk) 00:03, 7 August 2017 (UTC)
- @Pasleim: The resolution of the problems of edition / translation are part of the ongoing discussion. No resolution has been adopted by consensus in the discussion. --EncycloPetey (talk) 00:07, 7 August 2017 (UTC)
- The topic of this discussion is not if work items should be separated from edition/translation or how to discriminate an edition from a translation but how to merge original language of film or TV show (P364) into language of work or name (P407). As pointed out above by User:Matěj Suchánek, the problem are items constaining data both about work and edition/translation. A way has to be found how to separate these items. My constructive answer to this problem was to separate them manually... --Pasleim (talk) 01:22, 7 August 2017 (UTC)
- The topic of discussion is the removal / merger of a property associated with books. Refusing to discuss points pertaining to that discussion and removal / merger is not helpful. --EncycloPetey (talk) 02:58, 7 August 2017 (UTC)
- The topic of this discussion is the application of the model proposed on that page, so if you want to discuss again the model itself go there. Snipre (talk) 01:29, 8 August 2017 (UTC)
- No model is identified for translations at the location you have indicated, only models for "editions" that are used as sources. Wikisource data housed here for translations does not fall into that category, yet we are trying to house a wealth of translation data here. One cannot apply a model that does not exist. --EncycloPetey (talk) 02:32, 8 August 2017 (UTC)
- Have you seen Help:Sources#Books? Matěj Suchánek (talk) 08:56, 8 August 2017 (UTC)
- @Matěj Suchánek: Yes, but it does not provide the help needed for the large category of items in which I usually work, nor does it provide a useful example for translations or editions of translations. --EncycloPetey (talk) 02:06, 9 August 2017 (UTC)
- @EncycloPetey: Note that your undo actions are happened twice or three times, please do not violate 3RR, thx. --Liuxinyu970226 (talk) 03:45, 9 August 2017 (UTC)
- @Liuxinyu970226: Please note that WD has no 3RR policy. In fact, several MW projects have no such rule. You are thinking of Wikipedia. --EncycloPetey (talk) 14:05, 9 August 2017 (UTC)
- @EncycloPetey: So you can legally do a lot of edit war (Q764327) because you just want to keep one property? --Liuxinyu970226 (talk) 02:23, 10 August 2017 (UTC)
- @Liuxinyu970226: Making comments ascribing invented motives and goals to other people will not solve anything, and can damage the community. Please do not make such comments. What property do you think I want to keep? It seems you haven't read any of the above discussion, have you? The issue at hand is that, for some kinds of "books" and especially for their translations, we have no clearly defined model to work from, and so are trying to determine how best to proceed. Discussion above has indicated that no large-scale action be taken yet, because we're still deciding what action to take. Despite the ongoing discussion, and stated desire to hold off on enacting change, some editors are going ahead and making large-scale changes on their own without waiting for the discussion to conclude. But I am instead waiting to enact changes, and am trying to get this discussion to resolve some of the long-standing issues tied into this property. If you read all of the other discussion I've posted here, then that is what you'll find is going on. --EncycloPetey (talk) 03:18, 10 August 2017 (UTC)
- @EncycloPetey:
original language of film or TV show (P364)What property do you think I want to keep?
I read the entire PFD page carefully, that's the reason that I assume that you're edit-waring, as your edit comments like "consensus was to merge but NOT make changes yet" no longer make sense for me to still AGFIt seems you haven't read any of the above discussion, have you?
There's already consensus to drop P364 even for that Danish user, your "aganist" is too late.Discussion above has indicated that no large-scale action be taken yet, because we're still deciding what action to take.
By watching out the Special:CentralAuth/EncycloPetey, the 2 wikis that you are mostly editing are English Wiktionary and Wikisource, so can we concentrate on what's wrong within both English projects if one day we unfortunatelly deleted original language of film or TV show (P364), instead of discussing some random "large-scale changes" which you even did? --Liuxinyu970226 (talk) 03:39, 10 August 2017 (UTC)If you read all of the other discussion I've posted here, then that is what you'll find is going on.
- @Liuxinyu970226: We are getting way off topic, so I'll be brief: You're wrong on almost every point or assumption you state above, including which projects I've edited mostly. (I've edited heavily on wikispecies, for example, but that project doesn't seem to appear in the data when I follow the link.) So, instead of trying to pick apart other editors, let's stick to discussing the issue at hand, please? --EncycloPetey (talk) 03:50, 10 August 2017 (UTC)
- @EncycloPetey:
- @Liuxinyu970226: Making comments ascribing invented motives and goals to other people will not solve anything, and can damage the community. Please do not make such comments. What property do you think I want to keep? It seems you haven't read any of the above discussion, have you? The issue at hand is that, for some kinds of "books" and especially for their translations, we have no clearly defined model to work from, and so are trying to determine how best to proceed. Discussion above has indicated that no large-scale action be taken yet, because we're still deciding what action to take. Despite the ongoing discussion, and stated desire to hold off on enacting change, some editors are going ahead and making large-scale changes on their own without waiting for the discussion to conclude. But I am instead waiting to enact changes, and am trying to get this discussion to resolve some of the long-standing issues tied into this property. If you read all of the other discussion I've posted here, then that is what you'll find is going on. --EncycloPetey (talk) 03:18, 10 August 2017 (UTC)
- @EncycloPetey: So you can legally do a lot of edit war (Q764327) because you just want to keep one property? --Liuxinyu970226 (talk) 02:23, 10 August 2017 (UTC)
- @Liuxinyu970226: Please note that WD has no 3RR policy. In fact, several MW projects have no such rule. You are thinking of Wikipedia. --EncycloPetey (talk) 14:05, 9 August 2017 (UTC)
- @EncycloPetey: Note that your undo actions are happened twice or three times, please do not violate 3RR, thx. --Liuxinyu970226 (talk) 03:45, 9 August 2017 (UTC)
- @Matěj Suchánek: Yes, but it does not provide the help needed for the large category of items in which I usually work, nor does it provide a useful example for translations or editions of translations. --EncycloPetey (talk) 02:06, 9 August 2017 (UTC)
- Have you seen Help:Sources#Books? Matěj Suchánek (talk) 08:56, 8 August 2017 (UTC)
- No model is identified for translations at the location you have indicated, only models for "editions" that are used as sources. Wikisource data housed here for translations does not fall into that category, yet we are trying to house a wealth of translation data here. One cannot apply a model that does not exist. --EncycloPetey (talk) 02:32, 8 August 2017 (UTC)
- The topic of this discussion is the application of the model proposed on that page, so if you want to discuss again the model itself go there. Snipre (talk) 01:29, 8 August 2017 (UTC)
- The topic of discussion is the removal / merger of a property associated with books. Refusing to discuss points pertaining to that discussion and removal / merger is not helpful. --EncycloPetey (talk) 02:58, 7 August 2017 (UTC)
- The topic of this discussion is not if work items should be separated from edition/translation or how to discriminate an edition from a translation but how to merge original language of film or TV show (P364) into language of work or name (P407). As pointed out above by User:Matěj Suchánek, the problem are items constaining data both about work and edition/translation. A way has to be found how to separate these items. My constructive answer to this problem was to separate them manually... --Pasleim (talk) 01:22, 7 August 2017 (UTC)
- @Pasleim: The resolution of the problems of edition / translation are part of the ongoing discussion. No resolution has been adopted by consensus in the discussion. --EncycloPetey (talk) 00:07, 7 August 2017 (UTC)
- @EncycloPetey: I'm cleaning up items which mix work with edition/translation. You can not abuse this discussion here to stop the whole Wikidata:WikiProject Books. --Pasleim (talk) 00:03, 7 August 2017 (UTC)
- @Snipre: It still needs your suggestion to resolve problems here. --Liuxinyu970226 (talk) 14:17, 4 August 2017 (UTC)
Let me clarify some things concerning "Digte 1906" Digte (Q23009890) as there seems to be some misunderstandings. I really like that particular book as a test bed for Wikidata modeling as this collection of poems is quite complex to model in any database: Some poems were originally written in Danish and first appeared in a novel and as such appear in the Digte 1906. Two poems where written in the Danish dialect "Jutlandic" they were first published in a novel that was part of a triology, the three parts of the triology were collected to one novel which was termed "Kongens Fald" (in Wikidata, we have a work item The Fall of the King (Q1758876) and some edition items Q27655001 Kongens Fald, 1901 edition (Q34605018) and a edition with translation Kungens fall, 1906 (Q34607398)). This work contains body text in Danish, two poems in German, a bit of Latin text (if I recall correctly) as well as the two Jutlandic dialect poems. The two dialect poems are also published in the "Digte 1906" (perhaps with slight variation). The two dialect poems were put to music by Carl Nielsen and published in "Strofiske Sange Strofische Gesänge", a publication that contained the text in both Danish (including Jutlandic) and German (I believe a scanned copy is available somewhere on the Internet, but I cannot find it). Other poems in "Digte 1906" are translations from English to Danish. It is the three Whitman poems that Johannes V. Jensen translated. What further complicates matter is that "Digte 1906" which was actually called "Digte" was later extended a bit, then later extended yet again, extended and edited. The latest version was quite different for the 1906 version. Whether these new publications are new works or just new editions I really haven't come to any decision about. Through the 1900s the Digte 1906 gained a status of a classic so that the original "Digte 1906" where published as a new edition without the additions from the earlier versions! I do not think that "Digte 1906" has been translated in its entirety, but some individual poems exist in various translations. Sorry for this long and complicated explanation, but I invite interested Wikidata modellers to consider the works of Johannes V. Jensen, because the bibliography is so complicated, e.g., newspaper articles were turned into a poem and published in "Digte 1906", body text in a novel was turned (typoset) into a poem, etc. — Finn Årup Nielsen (fnielsen) (talk) 10:15, 8 August 2017 (UTC)
- Thanks for this clarifications. My proposal how to deal with this case:
- Digte (Q23009890) only contains texts in Danish and Jutlandig. So those should be the only values of language of work or name (P407). No other language statements or qualifiers should be added.
- Since Digte 1906 is a collection of works, use has part(s) (P527) to link to all poems resp. translated poems it contains.
- Create for each translated poem an own item as well as for each original poem. On the item about the translated poem use language of work or name (P407) to indicate the language of the translation; on the item about the orignal poem use language of work or name (P407) to indicate the original language. The translated poem can be linked with the original poem with edition or translation of (P629).
- published in (P1433) is used to show in which works a poem was published. This property can have many values. No distinction is made between the work in which the poem was first published and subsequent works.
- If a poem was put to music, create an own item for the song and use based on (P144) to link the song with the poem.
- If a work gets slightly extended, one has to decide if it's just a new edition or if it's a new work. No hard rule is applicable here. For a new edition, use edition or translation of (P629) to link to the original version. If you decide it is a new work, you can use instead based on (P144). --Pasleim (talk) 14:14, 8 August 2017 (UTC)
- But what should be done if a translated poem has multiple editions? I'm seeking clarification regarding you point above:
- "Create for each translated poem an own item as well as for each original poem. On the item about the translated poem use language of work or name (P407) to indicate the language of the translation; on the item about the orignal poem use language of work or name (P407) to indicate the original language. The translated poem can be linked with the original poem with edition or translation of (P629)."
- Are we going to use edition or translation of (P629) on the translation and then edition or translation of (P629) again on the edition of the translation, so that we have an "edition or translation of an edition or translation"? And for each item in such a situation, what should be used for instance of (P31)? Current practice in this regard leaves much to be desired. And with regard to the issue of "original language", it means that we end up with a situation in which the "original" language is not one tier above the edition, but two steps back. And I have situations analogous to Digte in which I fear we would have three steps. How will those who are making use of the data going to know the "original" language when the information may be one, two, or three data items away instead of a consistent number? Without a specific property to identify the original language, what can we do to clarify that information for users of WD? --EncycloPetey (talk) 03:28, 10 August 2017 (UTC)
- @EncycloPetey: Your comments here gave me those panoramas: We must discuss Park Geun-hye (Q138048) in conjunction with Kim Jong-un (Q56226) when talking about his policy (Q1156854) (really?), we must discuss John Cena (Q44437) in conjunction with Roman Reigns (Q275971) (2nd really?), we must discuss your heart in conjunction with automated external defibrillator (Q787407) (biggest REALLY?) mass edits can be happened in any conditions, and are those hurting you and you must "undo, revert, restore..."? e.g. Zhuyifei1999 made a large scale of recommendations to tool maintainers of our new Wikimedia Toolforge (Q36500248), so in your logic those recommendations must also be reverted? Anything is already big-rock-defined here. No more harassments to my Echo notifications, thx. --Liuxinyu970226 (talk) 15:05, 14 August 2017 (UTC)
- @Liuxinyu970226: I do not understand how your examples or discussion pertains to the topic being discussed. Your response does not address or solve any issue under consideration, and only distracts from the core problem. I ask again to the community: How will those who are making use of the data know the "original" language when the information is not on the data item, and that information may be one, two, or three data items away (instead of a consistent number), and has no property or qualifier to identify the original language? Without a specific marker to identify the original language, what can we do to clarify that information for users of WD? --EncycloPetey (talk) 16:52, 14 August 2017 (UTC)
- If you have a chain of 4 works/editions, how would you do it with the current system? We only have properties "language of work", "language of original work" but no property "language of original work of original work" and "language of original work of original work of original work". --Pasleim (talk) 17:54, 14 August 2017 (UTC)
- @Liuxinyu970226: I do not understand how your examples or discussion pertains to the topic being discussed. Your response does not address or solve any issue under consideration, and only distracts from the core problem. I ask again to the community: How will those who are making use of the data know the "original" language when the information is not on the data item, and that information may be one, two, or three data items away (instead of a consistent number), and has no property or qualifier to identify the original language? Without a specific marker to identify the original language, what can we do to clarify that information for users of WD? --EncycloPetey (talk) 16:52, 14 August 2017 (UTC)
- @EncycloPetey: Your comments here gave me those panoramas: We must discuss Park Geun-hye (Q138048) in conjunction with Kim Jong-un (Q56226) when talking about his policy (Q1156854) (really?), we must discuss John Cena (Q44437) in conjunction with Roman Reigns (Q275971) (2nd really?), we must discuss your heart in conjunction with automated external defibrillator (Q787407) (biggest REALLY?) mass edits can be happened in any conditions, and are those hurting you and you must "undo, revert, restore..."? e.g. Zhuyifei1999 made a large scale of recommendations to tool maintainers of our new Wikimedia Toolforge (Q36500248), so in your logic those recommendations must also be reverted? Anything is already big-rock-defined here. No more harassments to my Echo notifications, thx. --Liuxinyu970226 (talk) 15:05, 14 August 2017 (UTC)
- But what should be done if a translated poem has multiple editions? I'm seeking clarification regarding you point above:
Movies (or possibly Japanese animes)
Some users had questions about films and their dubbed versions. Will the FRBR system apply to them? Matěj Suchánek (talk) 14:48, 13 May 2017 (UTC)
- This discussion is related to a more global concept than the FRBR system: data duplication have to be avoided and data have to be saved in the more related item. These principles are important for bots, queries and automatic data extraction like the one for infoboxes in order to have general rules allowing codes reusability. We shouldn't not have a special way to store data for book and another for movies. WD is one database and we have to have general rules independent of the topics. Snipre (talk) 19:53, 13 May 2017 (UTC)
- I demonstrated the FRBR system for movies on Via col vento (Q29478369) and Via col vento (Q29478260). Till now, no member of the WikiProject Movie could show me how to express the data I added to this items without the FRBR system. I understand this as a silent agreement to the FRBR system. --Pasleim (talk) 20:44, 16 May 2017 (UTC)
If items are made for dubbing, this is the way suggested by WikiProject Movies. Please see the previous discussion on WikiProject Movies about this and the subsequent discussion at Wikidata:Bot_requests#Merge_of_.7B.7Bp.7C407.7D.7D_with_.7B.7Bp.7C364.7D.7D. This does not solve all other language issues for movies.
Further, you might have noticed at Wikidata talk:WikiProject Books, that the project didn't manage to implement the suggested scheme there either. Maybe it's either not suitable for Wikidata or users can't apply it. Maybe an action plan for WikiProject Books is needed before doing any merges on books as well. --- Jura 10:44, 8 July 2017 (UTC)
- Sorry, but I can't still see any problem. This series of edits and this discussion implies to me that there is a consensus regarding items for dubbed edition items. Please explain in detail to me as a non-involved person where you see problem. Matěj Suchánek (talk) 16:06, 9 July 2017 (UTC)
- We don't create such items in general. It seems that even the person who first sought help on how to create one isn't actually interested, or, at least, isn't able to create any. I don't have any real explanation for this inability. Maybe you can help us? Is this a specific contribution pattern that should be investigated?
In general, the core of the information on films is held on the main item. This includes the original language and one or several other languages. In general, there can be several dubbings and subtitlings of films in one language, but they still share core elements of the film. Similarly, there is now the possibility to link several items about posters and scripts of the film.
The idea seems to have been to adopt a solution that is proposed for books, but it appears it isn't working there either, so maybe it's better to consider the outcome of this as potentially desirable for textual work, but currently lacking a practical migration plan. If you see one for books, I'd be interested.
--- Jura 17:07, 9 July 2017 (UTC)- We – who? Me either?
- the person who first sought help – @Suruena: could you comment?
- the core of the information on films is held on the main item – we aren't going to delete it, are we?
- there can be several dubbings and subtitlings of films in one language – imagine having all of them stored in a single item...
- it isn't working there either – where not?
- Finally, do you have an example of item which would suffer from a significant (if any) data loss during the migration? Anyway, it sounds to me that you don't like the whole work-edition distinction, which was, however, approved in 2013. Matěj Suchánek (talk) 17:48, 9 July 2017 (UTC)
- I think any item that currently has its original work language determined will suffer. Maybe the migration plan for books can help sort this out, but looking at what Wikidata:WikiProject Books does and how they implemented it, it's just .. maybe you should read what active participants there write about it. In any case, you are actually deleting information, if there is no clear plan where the same information will be held afterwards.
--- Jura 18:03, 9 July 2017 (UTC)- @Jura1: Can you give me a movie example which splitting is not possible? --Liuxinyu970226 (talk) 02:19, 10 July 2017 (UTC)
- Looking only at items that use P31=film, there are currently about 200,000 of these with information about 470,000 different language versions. Some maybe up to 60 different ones. Obviously, we could created 270,000 new items, but these wouldn't be easy to maintain nor use by Wikipedia with the current tools. The confusion we currently have for books may spread further.
--- Jura 05:44, 13 July 2017 (UTC)- Could you please give a source for your numbers? So far I was assuming there are 189,000 movies with language information [2] holding information about 203,000 different language versions [3]. Those 11,000 items holding information about multiple languages [4] are typical movies produced in multiple languages e.g. Monty Python and the Holy Grail (Q25043). However, those do not suffer from the migration. --Pasleim (talk) 06:35, 13 July 2017 (UTC)
- I may found an example that not suitable for splitting: Detective Conan (Q185143) (Konggaru Starry K. Erne Mogilevich Santer AldNonUcallinme? Thibaut120094 Shikeishu C933103 Sight Contamination -Zest Vulphere Sakretsu Jean-Frédéric Tris T7 TT meNotified participants of WikiProject Anime and Manga for more help on it)
Wallacegromit1 Jeanjung212 Bagas Chrisara ミラP CrystallineLeMonde
Nicereddy Shisma (talk) MatrosMonk Bwk24 Mickn Rin RPI2026F1 Yirba Eniehack Wiccio IntensionalLogican - To the best of my knowledge, most of non-Japanese articles that linked by this item, are describing both Japanese and their dub works (*not only describing dubs in their own language, but also other lingua franca), so is it fairy to split it to 60 items? While it's technically possible, there will mostly have opposite voice from at least ja, ko and zhwiki as P407 value would be polluted. --Liuxinyu970226 (talk) 22:57, 14 July 2017 (UTC)
- The statements on Q185143#P674 have up to four voice actor (P725) qualifier. How can you tell if that are voice actors of the original work or of a dubbing? How do you plan to add publisher, publishing date, original network, website and translator of the dubbings? With qualifiers some of the data could be stored. But qualifiers on qualifiers do not exist so you will never be able to add all information if you don't split the item. A Wikipedia article describing both the original and the dub work can stay on the current item. --Pasleim (talk) 20:15, 17 July 2017 (UTC)
- Hello, Spanish Wikipedia user here. I'm not sure about the politics on different Wikipedias, I think the only thing I know is that in the English Wikipedia you use to translate the main article name to it's translation, in the case of Japanese animes and mangas (Blue Exorcist, The Qwaser of Stigmata, Attack on Titan, Future Diary, ...) but anything else. Talking about Wikipedia in Spanish, I'm truly not concerned about everything, because, for example, we keep the original Japanese titles on manga and anime articles, and in character names too, but there are cases in which, for some reason, the original name is replaced by a translated one (who the heck is Elsa Scarlet?), and that is defended by many users, some of them also participants of WikiProject Anime and Manga. I don't know if there will be a poll for using original names, but if so I'll be so happy, I've succeeded deleting that article for my memory, but every time I see things like Elsa Scarlet I got a mindblow and my body gets possessed. Ok, enough jokes, coming back to reality, there's also a lot of politics on Spanish Wikipedia concerning translations and original titles, for example, we use to keep the original name in its foreign language in movies, but for some reason we translate the title of books, so it's very confusing. --Erne Mogilevich (talk) 19:40, 20 July 2017 (UTC)
- The statements on Q185143#P674 have up to four voice actor (P725) qualifier. How can you tell if that are voice actors of the original work or of a dubbing? How do you plan to add publisher, publishing date, original network, website and translator of the dubbings? With qualifiers some of the data could be stored. But qualifiers on qualifiers do not exist so you will never be able to add all information if you don't split the item. A Wikipedia article describing both the original and the dub work can stay on the current item. --Pasleim (talk) 20:15, 17 July 2017 (UTC)
- I may found an example that not suitable for splitting: Detective Conan (Q185143) (
- Could you please give a source for your numbers? So far I was assuming there are 189,000 movies with language information [2] holding information about 203,000 different language versions [3]. Those 11,000 items holding information about multiple languages [4] are typical movies produced in multiple languages e.g. Monty Python and the Holy Grail (Q25043). However, those do not suffer from the migration. --Pasleim (talk) 06:35, 13 July 2017 (UTC)
- Looking only at items that use P31=film, there are currently about 200,000 of these with information about 470,000 different language versions. Some maybe up to 60 different ones. Obviously, we could created 270,000 new items, but these wouldn't be easy to maintain nor use by Wikipedia with the current tools. The confusion we currently have for books may spread further.
- @Jura1: Can you give me a movie example which splitting is not possible? --Liuxinyu970226 (talk) 02:19, 10 July 2017 (UTC)
- I think any item that currently has its original work language determined will suffer. Maybe the migration plan for books can help sort this out, but looking at what Wikidata:WikiProject Books does and how they implemented it, it's just .. maybe you should read what active participants there write about it. In any case, you are actually deleting information, if there is no clear plan where the same information will be held afterwards.
- We don't create such items in general. It seems that even the person who first sought help on how to create one isn't actually interested, or, at least, isn't able to create any. I don't have any real explanation for this inability. Maybe you can help us? Is this a specific contribution pattern that should be investigated?
Comment Still I don't see serious difference between movies and books. We possibly need widget to create "prepare 30 editions please" and to fill "voice actor" "translator" details. This difficulty isn't unique to movies, but for popular books too (or anything somehow global). d1g (talk) 01:20, 23 July 2017 (UTC) Comment In contrast to this, films and books without separation in 30 item would be cluttered with qualifiers:
- "applies to country"
- "applies to language"
- Which is way worse than to use separate items with direct statements. d1g (talk) 01:22, 23 July 2017 (UTC)
- The current solution for films works, includes information about 500,000 language versions and can accommodate additional elements (as illustrated with dubbings, film posters etc.). Unfortunately, we still don't have a plan for books (see section above). We should probably just close the section about movies and, if ever a solution is found for books, rename the property to limit it to films.
--- Jura 07:12, 23 July 2017 (UTC)
- Oppose, see what Snipe said carefully " in order to have general rules allowing codes reusability. We shouldn't not have a special way to store data for book and another for movies. WD is one database and we have to have general rules independent of the topics".
- Language of creative works applies to many concepts, far beyond "books and/or movies"
- It would be unproductive to create sets of specific properties for every of domain to perform same tasks.
- @Jura1: please provide an example how movie would be different from book? Why separate items would be wrong for movies? This question was raised several times, please address it. d1g (talk) 04:08, 24 July 2017 (UTC)
- The current solution for films works, but the one for books doesn't.
- Maybe you can provide a set of working samples for books. This was raised several times, but we haven't seen any actual work, plan or status.
- You mention elsewhere that we should follow some other website that would only have one for films, but they actually have three and they explicitly don't try to use their scheme. I don't quite see how the current approach doesn't allow you to map the properties to these three. If there are specific queries you have problems with, try Wikidata:Request a query.
--- Jura 07:08, 28 July 2017 (UTC)- @Jura1:
under which signal system? NTSC (Q185796)? PAL (Q105973)? SECAM (Q223765)? digital video recorder (Q865042)? Network Video Recorder (Q426040)? ...The current solution for films works
Huh? There's no entity books in your neighborhood?but we haven't seen any actual work, plan or status.
This could be intractable as I expanded this section to include ACG stuffs, but then your answer of "How can you tell if that are voice actors of the original work or of a dubbing?" from Pasleim is still missing, which could give me this daydream: the Marvel has actors from Cameroon from Tonga from Saint Helena... and they use Catalan use Faronese use Pitkern use Guarani... so they (the Marvel staffs) can re-use actors for all dubs of Captain America (Q190679) in all languages even some have ≤10,000 native users.but they actually have three and they explicitly don't try to use their scheme
- @Jura1:
--Liuxinyu970226 (talk) 12:35, 28 July 2017 (UTC)
- Also @Jura1: if you keep vote is having the reason of N/A (Q21686005), then my answer is that I suggest to merge this item to uncoded language (Q22283016) (ISO 639-3 mis). --Liuxinyu970226 (talk) 00:29, 8 August 2017 (UTC)
Specific movie example
How about considering A Fistful of Dollars (Q76479) as an example? The cast spoke Italian, German, and English, but the movie was filmed entirely without sound. The sound was dubbed on later. The movie was released in Italy first (in Italian), then in Germany, Spain, and other European countries, but did not have a US release until several years later. The US delay resulted from copyright issues because the Italian film was an adaptation of the Japanese samurai film Yojimbo (Q20475). So, what was the "original language" here? Do we need to have separate data items for every different language dub? Or how do we indicate that the movie exists in multiple language dubs? And do any of the languages get precedence or priority over others? --EncycloPetey (talk) 17:06, 14 August 2017 (UTC)
- Every different language dub can get its own item, see Wikidata talk:WikiProject Movies/Archive 1#Dubbings. A list of properties you can use with dubbings you find on Wikidata:WikiProject Movies/Properties#Synchronisation. --Pasleim (talk) 17:51, 14 August 2017 (UTC)
- Tricky question, still I think the current set of properties works generally fine for films. Maybe we could replace "work" with "film" in the label, once written works are sorted out. This would avoid creating additional properties, just to match some "schema".
--- Jura 17:56, 14 August 2017 (UTC)
- This still leaves the question of whether the main data item will have a language value. In this example, should the item for the work have no language at all, since every version of the movie was a dub? And if it has no language, then how do we mark the data item to keep editors from adding specific languages to the work instead of the data items for the individual dubs? --EncycloPetey (talk) 00:09, 15 August 2017 (UTC)
- For Le Bal (Q1637024), I came to the conclusion that an item with "no dialogue" might be the most suitable one. Maybe a similar one could be made for Q76479.
--- Jura 06:41, 15 August 2017 (UTC)- ...except that every released copy has dialogue. The problem is more general than just the one movie, since it is not always possible to pick out an "original" or "first" release of a film or publication. Even then, the "first" edition of any work is an edition and will be on a separate data item from the work itself. So, should we omit language properties from every work? and put them only on the editions / dubs? --EncycloPetey (talk) 13:44, 15 August 2017 (UTC)
- I don't think you can use the same item as on Q1637024, but it should be possible make an item that describes it. As you mention, not all are straigthforward, but with the current two properties, I think we should be able to describe films. This without creating additional ones, just follow schema.org. How is the situation for books evolving?
--- Jura 07:37, 17 August 2017 (UTC)- @Jura1: The two language properties schema.org uses for movies are http://schema.org/inLanguage and https://schema.org/subtitleLanguage. So is your suggestion to turn language of work or name (P407) into subtitleLanguage or what do you mean by "just follow schema.org"? --Pasleim (talk) 08:39, 17 August 2017 (UTC)
- @Jura1: Please either elaborate what you meant with "just follow schema.org" or cross your statement out. --Pasleim (talk) 21:21, 25 August 2017 (UTC)
- @EncycloPetey: Instead of omitting the language property for A Fistful of Dollars (Q76479), I would use the special value novalue since it's also an information that the movie was filmed without sound. --Pasleim (talk) 08:39, 17 August 2017 (UTC)
- I don't think you can use the same item as on Q1637024, but it should be possible make an item that describes it. As you mention, not all are straigthforward, but with the current two properties, I think we should be able to describe films. This without creating additional ones, just follow schema.org. How is the situation for books evolving?
- ...except that every released copy has dialogue. The problem is more general than just the one movie, since it is not always possible to pick out an "original" or "first" release of a film or publication. Even then, the "first" edition of any work is an edition and will be on a separate data item from the work itself. So, should we omit language properties from every work? and put them only on the editions / dubs? --EncycloPetey (talk) 13:44, 15 August 2017 (UTC)
- For Le Bal (Q1637024), I came to the conclusion that an item with "no dialogue" might be the most suitable one. Maybe a similar one could be made for Q76479.
- This still leaves the question of whether the main data item will have a language value. In this example, should the item for the work have no language at all, since every version of the movie was a dub? And if it has no language, then how do we mark the data item to keep editors from adding specific languages to the work instead of the data items for the individual dubs? --EncycloPetey (talk) 00:09, 15 August 2017 (UTC)
What about P2439?
- 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.
- this was discussed independently below, and closed with consensus to delete P2439 —MisterSynergy (talk) 09:48, 21 May 2018 (UTC)
If we go with P407, what should we do about P2439?
IMO one property for "language" should be enough.
Both P364 and P407 have millions of claims, it would more easier to move data to P2439 (with 3000 items - easy to check).
What should we do? d1g (talk) 01:07, 23 July 2017 (UTC)
- See above (closed thread). Matěj Suchánek (talk) 07:01, 24 July 2017 (UTC)
- P407 is unmatched with
- https://comicmeta.org/cbo/language.html - domain Series
- http://schema.org/inLanguage - Used on these types CommunicateAction CreativeWork Event WriteAction
- P2439 is the only options for properties above d1g (talk) 08:25, 24 July 2017 (UTC)
- @D1gggg: You are just wrong: 1) we first have to solve the original problem with P407 and P364 so no need to speak about P2439. 2) then we can speak about P2439. Can you just once consider the number of use of P407 and P364 with the one P2439 ? Can you just think about the number of edit to do to transfer everything from P407 and P364 to P2439 ? Somebody who is smart can easily understand that replacing P364 by P407 (and changing the label of P407 with language) and then replacing P2439 by P407 will save a lot of modifications ? If you still don't understand, just calculate the number of modifications and find the one with the minimal amount of modifications. Snipre (talk) 19:07, 24 July 2017 (UTC)
- @Snipre: I agree on 1, but 2: "replacing P2439 by P407" - what if we just keep P2439 for (creative works) and (events)?
- I never argued for amount of minimal edits, but how things would be in final state.
- At least part of discussion from 2014 argued to use "just language", so it should be P2439, not P407 "language of work".
- Should we rename P407 to "language"? - I missed this part of discussion. d1g (talk) 20:26, 24 July 2017 (UTC)
- It was proposed there. And please indicate where it is indicated that we need a different language for work and for event. Snipre (talk) 20:38, 24 July 2017 (UTC)
- I agree with what is said in #Recipient; @Snipre: no, we don't need separate properties "for work and for event", but one property, like what schema.org does. d1g (talk) 20:45, 24 July 2017 (UTC)
- I think they have three.
--- Jura 07:08, 28 July 2017 (UTC)- @Jura1: You still advertise P364 here by so-called "keeping 3 properties", so-called "it's better to create dummy items for your special cases instead of system-provided no value", so-called "good for films", and so-called "partially deprecated"... I would rather simply ask you again: why you're still keeping it? User friendly in which signal system world? NTSC? PAL? SECAM? Or some of DVRs? Of NVRs? --Liuxinyu970226 (talk) 15:35, 22 September 2017 (UTC)
- I think they have three.
- I agree with what is said in #Recipient; @Snipre: no, we don't need separate properties "for work and for event", but one property, like what schema.org does. d1g (talk) 20:45, 24 July 2017 (UTC)
- It was proposed there. And please indicate where it is indicated that we need a different language for work and for event. Snipre (talk) 20:38, 24 July 2017 (UTC)
- @D1gggg: You are just wrong: 1) we first have to solve the original problem with P407 and P364 so no need to speak about P2439. 2) then we can speak about P2439. Can you just once consider the number of use of P407 and P364 with the one P2439 ? Can you just think about the number of edit to do to transfer everything from P407 and P364 to P2439 ? Somebody who is smart can easily understand that replacing P364 by P407 (and changing the label of P407 with language) and then replacing P2439 by P407 will save a lot of modifications ? If you still don't understand, just calculate the number of modifications and find the one with the minimal amount of modifications. Snipre (talk) 19:07, 24 July 2017 (UTC)
- P407 is unmatched with
Moving forward and alternative proposal
@Jura1, Matěj Suchánek, Snipre, Liuxinyu970226, EncycloPetey, Fnielsen: Consensus was reached to merge original language of film or TV show (P364) and language of work or name (P407) and decision was made that original language of film or TV show (P364) will be deleted. Many subsequent discussions were held. However, some objections were raised without providing any concrete arguments ("movies need to language properties"), in some other discussions problems were brought up which will not be new with merging but already exist now, e.g. how to deal with translations that have intermediary translations. The only unresolved problem is how to deal with items containing data about both work and edition. Based on that I would like to propose the following procedure for merging:
- move P364 statement to P407 if no P407 statement is on the item
- delete P364 statement if it is equal to the P407 statement
- if a book item has P364 and P407 statements but their values differ, check manually if the items contains data about both work and edition and if necessary create new items to follow the guidelines on Wikidata:WikiProject Books.
The last step does not have to be considered for movies since no movie item has conflicting P364 and P407 values [5]. Before merging starts, it will be announced on WD:Status updates/Next and after merging, help will be provided to Wikipedia and sister projects to adapt their templates. --Pasleim (talk) 20:34, 26 September 2017 (UTC)
- As before, this proposal doesn't deal with the problem of books that are/contain translations for which no "original" work item can exist. G. M. Cookson's Four Plays of Aeschylus Four Plays of Aeschylus (Q26710829) is not a work, it is a translation (which Wikidata combines with edition). But no original "work" item of those four plays ever existed. So we have no possibility of indicating derivation.
- Also as before, no provision exists for parallel texts, where both an edition of a work and a translation of a work are included in the same volume.
- This doesn't look so much like an alternative proposal as merely a restatement of the same proposal with more specific details. --EncycloPetey (talk) 22:04, 26 September 2017 (UTC)
- This propsal does deal with these problems. It states that such items will be checked manually and edited according to the guidelines on Wikidata:WikiProject Books. In previous proposals this manual part was missing and it was suggested to do everyting programmatically. --Pasleim (talk) 22:30, 26 September 2017 (UTC)
- Fine for me. Just a last question: what's about the label of language of work or name (P407) ? No need of solving that question now but I think that changing "language of a work or name" to "language" will simplify the problem. Snipre (talk) 22:50, 26 September 2017 (UTC)
- @Pasleim: No, this proposal doesn't deal with those problems, and your last claim is not what the proposal says. The "new" proposal only makes provision for creating new items to follow the guidelines on Wikidata:WikiProject Books. It does not deal with existing items. Further, WikiProject Books does not currently have guidelines in place to deal with either of the situations I have described. Hand-waving and passing the buck are not solutions. I see no concrete solution that has yet been proposed for cases such as those I have raised, nor for similar situations. --EncycloPetey (talk) 00:00, 27 September 2017 (UTC)
- @EncycloPetey: Wikidata:WikiProject Books provides principle and not a solution for every special case. Instead of claiming that nobody is giving the solution you need please try to show by applying the principle of work/edition that this system is not able to answer the cases you raised.
- And I already provided some solutions for at least the first of your case: a compilation of original texts or translated texts is de facto a work. Four Plays of Aeschylus (Q26710829) is an edition and an additional item for work has to be created even if only one edition of this book exists. The item defined as work of Four Plays of Aeschylus (Q26710829) is a work composed of 4 other works and the characteristic allowing to consider the compilation of the 4 texts as work is the choice of selecting the 4 texts and to create a new text composed of 4 others.
- Then for the second case, I don't see a problem: as you mentioned, wikidata considers translation and edition in the same manner. So in your case what prevent you to define the item containing an original text and its translation as an edition/translation with two languages, the original language and the translation language ? It would be a problem if WD was considering edition and translation as different types of documents (but even in that case we could create a new class) but this not the case.
- The only problem we have to solve is to be able to link the different translations/editions by additional properties in order to provide more informations in case of translations about what was the original text (not the work but the edition) used as source for the translation. Snipre (talk) 01:01, 27 September 2017 (UTC)
- I'm sorry, but what? You are not using the standard terminology, I assume, because what you are saying makes no sense. Specifically, you are not using "work" in any sense that I understand it to mean. How can a "work" that consists of translations, consist of other works? Translations are never works; they are editions by Wikidata standards. So you are effectively stating that a work can consist of editions, which makes no logical sense.
- With regard to the second situation, we are considering the original text and the translation to be co-equal, which cannot ever be the case. The original text has an author (and possibly an editor), but the translation has a translator. One of the languages is that of the original text, while the other language is that of the translation text. We are talking about throwing all that information together without any means for the user to disentangle it.
- One point in all this is that we should be treating editions and translations as separate types of documents, and many of the difficulties of dealing with translations derive from our failure to distinguish between them. But that is another discussion.
- But back to the original issue in the first case: If a translator publishes a single translation on its own, that's clearly a translation/edition by our current standards. You are suggesting that if a translator publishes two translations together which were not originally published together in the combination in the original language, then it's a work. And if a translator publishes three translations together, it's also a work, unless those three form a trilogy in the original language and we have a data item for that, in which case it's a translation/edition. And I suppose then that if a poem or short story collection is translated in full, then the translated volume is an edition that consists of edition/translations. But if the translator plays editor and includes only three-quarters of the original stories, then the volume is now a work that consists of works, or perhaps edition/translations? Would this same logic apply to translations of parts of works? Because that is incredibly common. All the Japanese translations of Tom Brown's School Days (each done independently) omit huge sections of text and whole chapters. Nearly all English translations of Euclid's Elements of Geometry omit several of the original 13 books, and some include all "15" with apocrypha. The Christian Bible does not have regular contents in its various translations, since there are differing views of what constitutes canon, apocrypha, pseudepigrapha, etc. Does each translation that includes a differing set of books constitute a different "work" then? The logic of your reasoning escapes me. --EncycloPetey (talk) 02:42, 27 September 2017 (UTC)
- @EncycloPetey: Just be constructive once because until now you just critize everything without proposing something:
- First what is your work definition ? Because I provide an explanation about why I consider an book composed of existing texts or translations is a work: the selection of texts is a work. What is your problem with that definition ? When somebody says "I want to publish the best texts of an author", if sombody cuts a original text, he is performing a creation. Even if the choice is based on obvious criteria. It seems you have a very limited vision of what is creation, so please just give your definition of work first.
- Then about case, you lose nothing as you always have the the work item to identify the original data and to infer then the corresponding case:
- * work item:
- ** language: X
- ** author: XX
- * edition item:
- ** language: X, Y
- ** author: XX
- ** translator: ZZ
- What kind of information is lost ? And by the way, what is your solution to model this case in WD ? Snipre (talk) 02:16, 1 October 2017 (UTC)
- If selecting texts is a creation, and the result is a work, then why isn't translation also a creation, resulting in a work? Your definition doesn't explain that. --EncycloPetey (talk) 02:36, 1 October 2017 (UTC)
- @EncycloPetey: Translations could be considered as work, this is a choice we can do, the question is to know if we need to add more complexy and for which gain. I just created a first list of cases and I can describe quite complex cases for translated texts without need of work definition for translations. So if we don't need to have work for translation, no need to add it. We are creating a model and the purpose of a model is not the reach the perfection but to be useful for the application we want to use.
- And by the way you didn't provide any definition from your side. Do you want to be constructive or do you want to stay at the objections level ? Snipre (talk) 13:24, 1 October 2017 (UTC)
- If selecting texts is a creation, and the result is a work, then why isn't translation also a creation, resulting in a work? Your definition doesn't explain that. --EncycloPetey (talk) 02:36, 1 October 2017 (UTC)
- @Pasleim: No, this proposal doesn't deal with those problems, and your last claim is not what the proposal says. The "new" proposal only makes provision for creating new items to follow the guidelines on Wikidata:WikiProject Books. It does not deal with existing items. Further, WikiProject Books does not currently have guidelines in place to deal with either of the situations I have described. Hand-waving and passing the buck are not solutions. I see no concrete solution that has yet been proposed for cases such as those I have raised, nor for similar situations. --EncycloPetey (talk) 00:00, 27 September 2017 (UTC)
- Fine for me. Just a last question: what's about the label of language of work or name (P407) ? No need of solving that question now but I think that changing "language of a work or name" to "language" will simplify the problem. Snipre (talk) 22:50, 26 September 2017 (UTC)
- This propsal does deal with these problems. It states that such items will be checked manually and edited according to the guidelines on Wikidata:WikiProject Books. In previous proposals this manual part was missing and it was suggested to do everyting programmatically. --Pasleim (talk) 22:30, 26 September 2017 (UTC)
- edition or translation of (P629): somevalue, qualifier language of work or name (P407)? And I don't understand this: P364 has been "language of original work". But you also state: ... for which no "original" work item can exist. So usage of P364 looks wrong, doesn't it? Matěj Suchánek (talk) 07:30, 27 September 2017 (UTC)
- No original work in that form exists, but there is a translation because the components have original works from which they are translated. That is, the four plays were originally in ancient Greek, and the translations are in English, or French, or whatever, but there is not a "work" that consists of those four plays published in the original language used as the translation source, rather the individual plays are works that were all translated. So the original language was Greek, but the published language is English, and by all standards presented in the proposal, we would simply mark the translations as "English" with no indication whatsoever that they were ever written in any language but English, and with no indication whatsoever that they are translations rther than works originating in English. That is positively misleading the users. --EncycloPetey (talk) 12:58, 27 September 2017 (UTC)
- On Four Plays of Aeschylus (Q26710829) you state that it is an English [6] work [7] having multiple parts [8]. On the parts items you state that these are English translations [9]. You also provide for each translation a link to the original work item [10]. On the original work items you state that these are works [11] in Ancient Greek [12]. Now we will use P407 instead of P364 in the last linked edit. What is here misleading the users? --Pasleim (talk) 13:55, 27 September 2017 (UTC)
- Your links do not support what you claim. Where did I say that Four Plays of Aeschylus (Q26710829) was a "work"? If you feel we must do this incrementally, with diffs and details going over every word, then let's start there. Where did I say it was a "work"? --EncycloPetey (talk) 01:15, 28 September 2017 (UTC)
- In September 2016 when you added that instance of (P31)=book (Q571), book (Q571) was a direct subclass of work (Q386724). Today, book (Q571) is a subclass of intellectual work (Q15621286) which is subclass of work (Q386724). Since subclass of (P279) is a transitive property, stating that Four Plays of Aeschylus is a instance of a book, it is implicitly also an instance of a work. --Pasleim (talk) 05:45, 28 September 2017 (UTC)
- But, since this data item is for the copy at Wikisource, is that a correct value to use for "instance"? I used "book" because I could not find a more suitable value to use, but surely a particular copy cannot be a "work". (Please stay with me, and don't get sidetracked.) --EncycloPetey (talk) 13:54, 28 September 2017 (UTC)
- I'm not an expert on Wikisource and there are would be project pages with more knowledgeable users on Wikisource linking. But the question is whether s:en:Four Plays of Aeschylus (Cookson) describes the work by Cookson or a particular copy of the work. If it describes the work the item is fine, if it describes a particular copy we need two items. One item for the work, i.e. the compilation of the four translations, and one item for the copy. --Pasleim (talk) 21:25, 28 September 2017 (UTC)
- No, there are no project pages with more information, and that's part of the problem. This issue has never been worked through to its logical conclusion, nor has it ever been written up. Please don't waver on this discussion now.
- But as for the four English translations by Cookson: aren't they also "works" that will have multiple editions? Couldn't Cookson's translation of The Suppliants appear in more than one published edition? And so, in addition to having two data items for Cookson's book Four Plays (one for the book as a "work", and one for the edition housed at Wikisource), wouldn't we also have to have two data items for each of the four translations of plays included in the volume (one for the translation as a "work", and one for the specific edition of that translation that was published)? --EncycloPetey (talk) 02:20, 29 September 2017 (UTC)
- A translation is a translation and not a work. This does not exclude that a translation can not appear in more than one edition. Each edition gets its own item.
- Imagine I told you a translations are also works, would it change something on how we should delete P364? --Pasleim (talk) 09:13, 29 September 2017 (UTC)
- You're getting sidetracked here; please stay with me. Each publication of a work housed at Wikisource necessitates that each publication has a different data item. We are treating editions and translations as the same thing, yes? And Cookson's translation of Prometheus Unbound is a translation, yes, but there are multiple editions of that translation because it has been published by different editors in different volumes. We can't re-use the same data item every time the Cookson translation appears in another volume, so the translation must have multiple editions. We therefore must have a master data item indicating the information about the translation as a "work", and then data items for each edition of the translation. --EncycloPetey (talk) 15:53, 30 September 2017 (UTC)
- I almost agree with you, I just don't call the translation a "work" but maybe it would be easier if I do so. If a translation gets published by different editors then we need indeed an item for the translation and items for each edition. --Pasleim (talk) 18:26, 30 September 2017 (UTC)
- I agree that the terminology is inadequate for describing this situation. But continuing: What happens then when a translation has two (or more) different textual revisions, each of which has been published in more than one location? We have this issue with Browning's translation of Prometheus Bound and Shelley's translation of Cyclops' for example. As far as I can tell, we would have a data item for the original play, one for the translation as a "work", one data item for each "revision" of that translation as a "work", and one data item for each "edition" of each revision of that translation. --EncycloPetey (talk) 19:31, 30 September 2017 (UTC)
- Yes that is the idea. Sounds fairly complicated but it is the only way to give proper attribution to each editor and to show each publication date and place. And if Wikisource hosts multiple edition of a work/translation/revision there are even software restrictions which forces us to follow this data model. --Pasleim (talk) 20:03, 30 September 2017 (UTC)
- Complicated, but we're not quite done yet, though we can soon move on to the next step in the discussion. Before we go there, I must also point out that many translators translate using a specific edition of the original text, such as the Dindorf edition of a Greek text. So we can have an edition of a revision of a translation of an edition of a Greek publication of a work. The actual Wikisource edition must then have six data items in place, all of which are suitably interlinked. And someone seeking the original language would have to blindly navigate through six layers of data items to find what that original language was of the translated work. --EncycloPetey (talk) 20:44, 30 September 2017 (UTC)
- It is not a blind navigation. We have edition or translation of (P629) to link to the next upper layer and instance of (P31) to tell the type of the layer. --Pasleim (talk) 00:48, 1 October 2017 (UTC)
- It is blind. In the situation we've constructed, there are six layers of "edition/translation of" to sift through, but in the end, a person would have to follow a link into "has part/part of" and follow it back to find the original language, since the "work" in question would be marked as "English" for its language, since the book as a whole was not composed originally in Greek. A user would have to poke around every possible link or "edition/translation of" and "has part" or "part of" and might find the original language somewhere within a maze of interconnected data items. If they stopped too soon, or didn't know ahead of time which direction to follow for the links, they would mistakenly end up with the wrong language. --EncycloPetey (talk) 01:11, 1 October 2017 (UTC)
- Well if we go from a particular edition up to the work, there should never be more than one edition or translation of (P629) claim and if an item uses "has part/part of" it is possible that multiple original languages exist. If you have usability concerns, you should consider that seen over all books cases like Four Plays of Aeschylus (Q26710829) are rather rare. Moreover, the target audience of Wikidata are not users visiting wikidata.org but Wikipedia/Wikisource which include data from Wikidata and external pages retrieving data through the API or query service. For those, the current situation means that they have to poke around every possible statement and might find the original language somewhere within a maze of unstructured data. The original language can be found sometimes as qualifier on language of work or name (P407), sometimes as qualifier on original language of film or TV show (P364), sometimes as qualifier on edition or translation of (P629), sometimes as an own statement, or sometimes one has to follow the edition or translation of (P629) link. On the original work item, sometimes original language of film or TV show (P364) is used, sometimes language of work or name (P407), sometimes both. If there is a translation of a translation of a work, P364 is anyway illdefined. If we could do the migration, we could write a function for the Lua module on Wikipedia to retrieve the original language and external pages could add a while-loop to their code and we would finally have a distinct data structure that works in all situations. --Pasleim (talk) 02:39, 1 October 2017 (UTC)
- @Pasleim, EncycloPetey: I created a lis of cases here and I was trying to model the cases acording to the work/edition principle. I didn't find big issue until now, but we have to provide a more detailed example for some cases. The main problem is never the language but work definition so I think all the discussion above is out of the box concerning the issue of merging 2 properties about languages. I proposed to EncycloPetey to provide a defined case where the merge of the mentioned properties is a real problem. For the general discussion about the work/edition model, better discuss about that in the talk page of Wikibooks project.
- @EncycloPetey: I propose you to generate some cases based on what you mentioned like I did in my cases list and then we can discuss based on a generic case (and not on a real case where you are the only one knowing the details) the solution.
- @Pasleim: You mentioned that translations should have work items. If I agree in the absolute vision of a perfect classification, I ask you: where do you find an advantage of this more complex system compared to the one where translations are considered as edition ? The best will be to model the cases from my list with the addition of work for translations and see what are the results. Snipre (talk) 13:42, 1 October 2017 (UTC)
- @Snipre: I commented on the talk page of your list as the answer is irrelevant for the migration discussion here. --Pasleim (talk) 14:08, 1 October 2017 (UTC)
- Well if we go from a particular edition up to the work, there should never be more than one edition or translation of (P629) claim and if an item uses "has part/part of" it is possible that multiple original languages exist. If you have usability concerns, you should consider that seen over all books cases like Four Plays of Aeschylus (Q26710829) are rather rare. Moreover, the target audience of Wikidata are not users visiting wikidata.org but Wikipedia/Wikisource which include data from Wikidata and external pages retrieving data through the API or query service. For those, the current situation means that they have to poke around every possible statement and might find the original language somewhere within a maze of unstructured data. The original language can be found sometimes as qualifier on language of work or name (P407), sometimes as qualifier on original language of film or TV show (P364), sometimes as qualifier on edition or translation of (P629), sometimes as an own statement, or sometimes one has to follow the edition or translation of (P629) link. On the original work item, sometimes original language of film or TV show (P364) is used, sometimes language of work or name (P407), sometimes both. If there is a translation of a translation of a work, P364 is anyway illdefined. If we could do the migration, we could write a function for the Lua module on Wikipedia to retrieve the original language and external pages could add a while-loop to their code and we would finally have a distinct data structure that works in all situations. --Pasleim (talk) 02:39, 1 October 2017 (UTC)
- It is blind. In the situation we've constructed, there are six layers of "edition/translation of" to sift through, but in the end, a person would have to follow a link into "has part/part of" and follow it back to find the original language, since the "work" in question would be marked as "English" for its language, since the book as a whole was not composed originally in Greek. A user would have to poke around every possible link or "edition/translation of" and "has part" or "part of" and might find the original language somewhere within a maze of interconnected data items. If they stopped too soon, or didn't know ahead of time which direction to follow for the links, they would mistakenly end up with the wrong language. --EncycloPetey (talk) 01:11, 1 October 2017 (UTC)
- It is not a blind navigation. We have edition or translation of (P629) to link to the next upper layer and instance of (P31) to tell the type of the layer. --Pasleim (talk) 00:48, 1 October 2017 (UTC)
- Complicated, but we're not quite done yet, though we can soon move on to the next step in the discussion. Before we go there, I must also point out that many translators translate using a specific edition of the original text, such as the Dindorf edition of a Greek text. So we can have an edition of a revision of a translation of an edition of a Greek publication of a work. The actual Wikisource edition must then have six data items in place, all of which are suitably interlinked. And someone seeking the original language would have to blindly navigate through six layers of data items to find what that original language was of the translated work. --EncycloPetey (talk) 20:44, 30 September 2017 (UTC)
- Yes that is the idea. Sounds fairly complicated but it is the only way to give proper attribution to each editor and to show each publication date and place. And if Wikisource hosts multiple edition of a work/translation/revision there are even software restrictions which forces us to follow this data model. --Pasleim (talk) 20:03, 30 September 2017 (UTC)
- I agree that the terminology is inadequate for describing this situation. But continuing: What happens then when a translation has two (or more) different textual revisions, each of which has been published in more than one location? We have this issue with Browning's translation of Prometheus Bound and Shelley's translation of Cyclops' for example. As far as I can tell, we would have a data item for the original play, one for the translation as a "work", one data item for each "revision" of that translation as a "work", and one data item for each "edition" of each revision of that translation. --EncycloPetey (talk) 19:31, 30 September 2017 (UTC)
- I almost agree with you, I just don't call the translation a "work" but maybe it would be easier if I do so. If a translation gets published by different editors then we need indeed an item for the translation and items for each edition. --Pasleim (talk) 18:26, 30 September 2017 (UTC)
- You're getting sidetracked here; please stay with me. Each publication of a work housed at Wikisource necessitates that each publication has a different data item. We are treating editions and translations as the same thing, yes? And Cookson's translation of Prometheus Unbound is a translation, yes, but there are multiple editions of that translation because it has been published by different editors in different volumes. We can't re-use the same data item every time the Cookson translation appears in another volume, so the translation must have multiple editions. We therefore must have a master data item indicating the information about the translation as a "work", and then data items for each edition of the translation. --EncycloPetey (talk) 15:53, 30 September 2017 (UTC)
- I'm not an expert on Wikisource and there are would be project pages with more knowledgeable users on Wikisource linking. But the question is whether s:en:Four Plays of Aeschylus (Cookson) describes the work by Cookson or a particular copy of the work. If it describes the work the item is fine, if it describes a particular copy we need two items. One item for the work, i.e. the compilation of the four translations, and one item for the copy. --Pasleim (talk) 21:25, 28 September 2017 (UTC)
- But, since this data item is for the copy at Wikisource, is that a correct value to use for "instance"? I used "book" because I could not find a more suitable value to use, but surely a particular copy cannot be a "work". (Please stay with me, and don't get sidetracked.) --EncycloPetey (talk) 13:54, 28 September 2017 (UTC)
- In September 2016 when you added that instance of (P31)=book (Q571), book (Q571) was a direct subclass of work (Q386724). Today, book (Q571) is a subclass of intellectual work (Q15621286) which is subclass of work (Q386724). Since subclass of (P279) is a transitive property, stating that Four Plays of Aeschylus is a instance of a book, it is implicitly also an instance of a work. --Pasleim (talk) 05:45, 28 September 2017 (UTC)
- Your links do not support what you claim. Where did I say that Four Plays of Aeschylus (Q26710829) was a "work"? If you feel we must do this incrementally, with diffs and details going over every word, then let's start there. Where did I say it was a "work"? --EncycloPetey (talk) 01:15, 28 September 2017 (UTC)
- On Four Plays of Aeschylus (Q26710829) you state that it is an English [6] work [7] having multiple parts [8]. On the parts items you state that these are English translations [9]. You also provide for each translation a link to the original work item [10]. On the original work items you state that these are works [11] in Ancient Greek [12]. Now we will use P407 instead of P364 in the last linked edit. What is here misleading the users? --Pasleim (talk) 13:55, 27 September 2017 (UTC)
- No original work in that form exists, but there is a translation because the components have original works from which they are translated. That is, the four plays were originally in ancient Greek, and the translations are in English, or French, or whatever, but there is not a "work" that consists of those four plays published in the original language used as the translation source, rather the individual plays are works that were all translated. So the original language was Greek, but the published language is English, and by all standards presented in the proposal, we would simply mark the translations as "English" with no indication whatsoever that they were ever written in any language but English, and with no indication whatsoever that they are translations rther than works originating in English. That is positively misleading the users. --EncycloPetey (talk) 12:58, 27 September 2017 (UTC)
- @Pasleim: RE: "seen over all books cases like Four Plays of Aeschylus (Q26710829) are rather rare". Actually they aren't. If you like I can show you how almost any translated book becomes just as complicated. For example, The Time Machine: An Invention (Q627333) by H. G. Wells (Q42511) has no single authoritative edition to be the standard. Rather, there is the serialized version of the novel, and at least two book formats for the novel with significantly differing text and even different chapter numbers. That's just the major English editions. When one of these gets translated, we have to identify whcih English edition was the one translated, because it's not always one particular translation. The choice of edition affects the number of chapters, and this is hugely important for Wikisource, where editors like to be able to place the translated text side-by-side with the "original". To do this requires a data item for each chapter, both in the original language and in the translation, which means there must be data items for each chapter as part of the "work" and data items for each chapter of the "edition" and data items for each chapter of the "translation". And if the translation has gone through multiple editions (it usually has), then we end up with the same morass of data items that we had for the Greek plays.
- edition or translation of (P629): somevalue, qualifier language of work or name (P407)? And I don't understand this: P364 has been "language of original work". But you also state: ... for which no "original" work item can exist. So usage of P364 looks wrong, doesn't it? Matěj Suchánek (talk) 07:30, 27 September 2017 (UTC)
- Whether you consider Oliver Twist by Charles Dickens or L'Homme qui rit by Victor Hugo, you get the same complexity of hundreds of interconnected data items. Most of these works were serialized to begin with, later collecting them together as a novel, and sometimes then published over multiple volumes or parts even before the process of translation, and then having differing numbers of volumes in the translation. --EncycloPetey (talk) 15:30, 1 October 2017 (UTC)
- There is no consensus on the notability of Wikisource chapters on Wikidata.
- Whether we need a hundred items to model all editions and translation of Oliver Twist does not depend at all on whether we have one, two or three language properties. --Pasleim (talk) 15:59, 1 October 2017 (UTC)
- You've lost that train of thought we built up. What happens on the French, German, etc. editions of translations when we have so many data items and so many links to manage? How would an average user find the original language of a work in such a situation, when presented with a labyrinthine set of data items? Notability is unsettled, but that includes also those volumes where the book consists entirely of individual works by separate authors, which do seem to be accepted now. And chapters of translated books will exist on multiple WS projects, albeit in different languages. For those that will have translations on other WS, the balance is likely to tip in favor of inclusion. --EncycloPetey (talk) 01:37, 3 October 2017 (UTC)
- @EncycloPetey: And simply, can you please explain that what's your qualifier usage of original language of film or TV show (P364)? That so-called usage is simply confused to me, and even the talk page of that property also disencourage it. --Liuxinyu970226 (talk) 10:59, 3 October 2017 (UTC)
- I don't understand your question. I can't tell whether you meant to politely ask a question (which I do not understand) or meant to be insulting (I can't tell if that was intentional). --EncycloPetey (talk) 13:55, 3 October 2017 (UTC)
- @EncycloPetey: Well
- In Antigonae (Q24790761), what means the qualifier "original language of film or TV show (P364)Ancient Greek (Q35497)" within language of work or name (P407)German (Q188)?
- In those 4 items Choephori (Q22972166), Agamemnon (Q22810156), Eumenides (Q23012889) and The Persians (Q23308144), what means the qualifier "original language of film or TV show (P364)Ancient Greek (Q35497)" within language of work or name (P407)English (Q1860)?
- I don't understand your question. I can't tell whether you meant to politely ask a question (which I do not understand) or meant to be insulting (I can't tell if that was intentional). --EncycloPetey (talk) 13:55, 3 October 2017 (UTC)
- @EncycloPetey: And simply, can you please explain that what's your qualifier usage of original language of film or TV show (P364)? That so-called usage is simply confused to me, and even the talk page of that property also disencourage it. --Liuxinyu970226 (talk) 10:59, 3 October 2017 (UTC)
- You've lost that train of thought we built up. What happens on the French, German, etc. editions of translations when we have so many data items and so many links to manage? How would an average user find the original language of a work in such a situation, when presented with a labyrinthine set of data items? Notability is unsettled, but that includes also those volumes where the book consists entirely of individual works by separate authors, which do seem to be accepted now. And chapters of translated books will exist on multiple WS projects, albeit in different languages. For those that will have translations on other WS, the balance is likely to tip in favor of inclusion. --EncycloPetey (talk) 01:37, 3 October 2017 (UTC)
- Whether you consider Oliver Twist by Charles Dickens or L'Homme qui rit by Victor Hugo, you get the same complexity of hundreds of interconnected data items. Most of these works were serialized to begin with, later collecting them together as a novel, and sometimes then published over multiple volumes or parts even before the process of translation, and then having differing numbers of volumes in the translation. --EncycloPetey (talk) 15:30, 1 October 2017 (UTC)
--Liuxinyu970226 (talk) 06:58, 4 October 2017 (UTC)
- That is a work-around to indicate the language of the source text from which the translation was made. We currently have no standard to identify the source text (or edition), nor the means to identify the language of the text from which a translation was made. This is a significant point, as a translation is not made from a "work" but from a specific text or texts, and neither is a translation always made from the "original" but may be done from a translation. We have no preferred means to indicate any of this information. --EncycloPetey (talk) 12:17, 4 October 2017 (UTC)
- And even once we have a method for indicating source text and source language (for the immediate source, not the ultimate one), there are challenges. I was a translation of Euripides that was made from Dindorf's edition. However, I have no access to a copy of Dindorf's edition, so I have insufficient information to create the various data items that would be needed, such as which volumes contain which plays. Further, Dindorf's edition of the plays would have its language marked as both German and ancient Greek, since the play text is in English, but all prefatory materials and internal notes are in German. Having such a work as the source of the English translation leaves the question open of whether the English copy was translated from a Greek text or from a German text. Wikidata currently has no way at all to indicate which was the source language. --EncycloPetey (talk) 13:22, 4 October 2017 (UTC)
- Thank you for going ahead with this. I suggest including this to Tech News as well because templates can break when the property gets deleted.
- Note that when you include subclasses of film (Q11424) to the query after the third point, it does return some results. Not many, though. Matěj Suchánek (talk) 07:30, 27 September 2017 (UTC)
- We can include it to Tech News but I promise that I will fix the templates listed on Property talk:P364. Thus, there should be no broken templates. --Pasleim (talk) 21:25, 28 September 2017 (UTC)
- Just Delete as quickly as possible, all of those "keep" comments are daydream, and are illegal that try to defend their edit wars. --Liuxinyu970226 (talk) 05:28, 1 October 2017 (UTC)
- Comment I don't think much progress seems to have been made for movies. If we proceed with the suggested merger, this would just lead to make it indeterminable. There were some suggestions that we should follow schema.org for these, but as schema has three different ones for languages, I don't think this is would be any progress from the stable solution we have now for movies. Going forward, I'd keep excluding films from the merger.
As for books, I think it would be good to formulate a clear plan so users are able to determine what a language statement would mean on such items without loading dozens of items and attempting to check these for completeness. I can understand that some approach might seems theoretically desirable and work well in a single editor environment, but this doesn't necessarily help users with Wikidata problems.
--- Jura 06:40, 1 October 2017 (UTC)
- What kind of progress do you expect ? The principle is given: use of model based on FRBR system which is the only system which allows you to add data like voices or the publication date of each dubbed version. Until now you never provided any explanation how I can add the names of the voices like the ones available in this section of WP:fr and in this section of WP:es for The Hunt for Red October (Q507994). So your system is not applicable but this is our responsability to find a solution ? Perhaps it is time to wake up the Project Movies to define an action plan: the merge of the 2 languages properties is not a problem, this is a situation which reveals the problem.
- So I propose you a very simple deal: let us working on the book cases and from your side start to work on the movie cases. And please provide me an example how I can add the dubbed voices for the case of The Hunt for Red October (Q507994): I hope you won't consider this as a theoretical problem. Snipre (talk) 21:40, 1 October 2017 (UTC)
- @Jura1: Per above, the de facto most big problem with your P364 is how to handle actors of dubs, please just answer it, otherwise my delete vote is still okay. --Liuxinyu970226 (talk) 23:23, 4 October 2017 (UTC)
- Comment Snipre: Thanks for giving me credit for the Wikiproject Movies structure, but it's mostly undeserved even though I made efforts that it was spelled out, properly applied and even key indicator defined. As you notice, it's fairly clean, complete and even noise can be removed without much problem. It might be too ambitious, but I'd expect a similar working approach for books. The existing movie structure should work for your The Hunt for Red October (Q507994) sample without problems. Once done, we can then work together to make sure it appears in the Spanish infobox (French wont work, as I don't think they use Wikidata for films). Alternatively, if available, you could do one for Catalan (Catalan Wikipedia also uses Wikidata in film infoboxes). If you have problems with the properties for movies, please ask at the WikiProject. Please help us keep away purely disruptive or non-contributing efforts.
--- Jura 09:38, 8 October 2017 (UTC)- Although you claim that the WikiProject Movies structure is fairly clean and complete, some major information are missing. For example, why are two or even three language properties necesseary to describe a movie? --Pasleim (talk) 17:07, 9 October 2017 (UTC)
- Some people favoring merging advocated following schema.org which has three different scheme's for movies. Personally, I don't. We should we do with a property "subtitle language"?
--- Jura 08:38, 11 November 2017 (UTC)
- Some people favoring merging advocated following schema.org which has three different scheme's for movies. Personally, I don't. We should we do with a property "subtitle language"?
- @Jura1: So we agree that the current data structure described in Wikiproject Movies is the reference. So according to this data structure, the original movie requires only one language property and all dubbed movies have to be described in a different item using again one unique language property. There is no need of having 2 or more language properties in the same item so changing P364 by P407 will have no impact on items which follows the data structure described in the Wikiproject. Only the items which are not using the data structure required by the Wikiproject can be impacted but that's not our problem, that's the problem of the Wikiproject Movies which allows different data structures or didn't plan until now any data curation.
- So do we agree that
- 1) there is no need of 2 different language properties (based on the data structure of Wikiproject Movies) ?
- 2) we can deprecate P364 starting now (after changing the data structure of Wikiproject Movies) ?
- 3) we have to define a strategy to convert P364 by P407:
- for every item defined as instance of (P31):film (Q11424), short film (Q24862), television film (Q506240), anthology film (Q336144) and having one property original language of film or TV show (P364) ==> change original language of film or TV show (P364) by language of work or name (P407)
- for every item defined as instance of (P31):film (Q11424), short film (Q24862), television film (Q506240), anthology film (Q336144) and having one property original language of film or TV show (P364) and one or several language of work or name (P407) ==> this item is not following the data structure of Wikiproject Movies and has to be curated
- for every item defined as instance of (P31):dubbing of film (Q26204053) and having one property original language of film or TV show (P364) and one or several language of work or name (P407) this item is not following the data structure of Wikiproject Movies and original language of film or TV show (P364) can be deleted.
- for every item defined as instance of (P31):dubbing of film (Q26204053) has to be linked to the original movie using edition or translation of (P629) so it is possible to extract the original language by using the language of work or name (P407) of the original movie.
- All other cases are not following the data structure of Wikiproject and have to be curated. Snipre (talk) 11:50, 20 October 2017 (UTC)
- @Jura1: Please answer the above questions by Snipre and me. If you don't do so, I will soon start with the conversion outlined above, we still have to respect that a majority of users voted for merging P364 with P407. --Pasleim (talk) 08:29, 10 November 2017 (UTC)
- Also the question that about NTSC/PAL/SECAM issue that I asked more than 3 times here. --Liuxinyu970226 (talk) 12:49, 10 November 2017 (UTC)
- Pasleim: I don't really see how Snipre's proposal will help him achieve what he planned to do (sort out the books part, add the dubbed versions of "Red October") and why instead WikiProject movies gets told it's their responsibility to fix it for him. I don't think this is particularly respectful from participants in the discussion who don't actually contribute to Wikidata otherwise in the field. If we continue this way, it might just end up as an endless soap. Accordingly, I have asked this discussion to be closed as stale. Obviously, I could try to help you sort out the books part, but this doesn't need a deletion discussion nor is a deletion discussion a suitable forum There does seem to be consensus that books need help, but unfortunately it's not clear how this should be done. Merely voting isn't going to build a plan. Given the countless participants of the books projects, it's unclear why people of other projects should do that. Pasleim, I do appreciate your efforts to get some sense into this, but we probably both focus on more important things. Maybe Matěj Suchánek wants to address the SECAM question, I avoid doing that as he asked me not to do in another context.
--- Jura 08:38, 11 November 2017 (UTC)- I'm not going to address any made up terms like "SECAM". The result of initial discussion, which I closed in May, is clear: to merge two properties. Since this cannot be done by software (like with items), we need to migrate one to another. I gave users opportunity to share what issues we need to know about before the migration but now I see I shouldn't have.
- So yes, this discussion is stale and can be closed. The community had already decided anyway. Matěj Suchánek (talk) 15:37, 11 November 2017 (UTC)
- The problem is that it failed to develop an implementation plan. So we are just where we were 6 months ago. Despite a general idea, it's not something that can be acted upon. Maybe we should try to develop better support for WikiProject Books going forward. Users seems to be confused by conflicting approaches and chat in forums.
--- Jura 16:09, 11 November 2017 (UTC)
- The problem is that it failed to develop an implementation plan. So we are just where we were 6 months ago. Despite a general idea, it's not something that can be acted upon. Maybe we should try to develop better support for WikiProject Books going forward. Users seems to be confused by conflicting approaches and chat in forums.
- Pasleim: I don't really see how Snipre's proposal will help him achieve what he planned to do (sort out the books part, add the dubbed versions of "Red October") and why instead WikiProject movies gets told it's their responsibility to fix it for him. I don't think this is particularly respectful from participants in the discussion who don't actually contribute to Wikidata otherwise in the field. If we continue this way, it might just end up as an endless soap. Accordingly, I have asked this discussion to be closed as stale. Obviously, I could try to help you sort out the books part, but this doesn't need a deletion discussion nor is a deletion discussion a suitable forum There does seem to be consensus that books need help, but unfortunately it's not clear how this should be done. Merely voting isn't going to build a plan. Given the countless participants of the books projects, it's unclear why people of other projects should do that. Pasleim, I do appreciate your efforts to get some sense into this, but we probably both focus on more important things. Maybe Matěj Suchánek wants to address the SECAM question, I avoid doing that as he asked me not to do in another context.
- Although you claim that the WikiProject Movies structure is fairly clean and complete, some major information are missing. For example, why are two or even three language properties necesseary to describe a movie? --Pasleim (talk) 17:07, 9 October 2017 (UTC)
Closure of stale thread
As this hasn't really gotten ahead, I think we should leave it to the relevant WikiProjects to address possible needs for improvement. --- Jura 08:38, 11 November 2017 (UTC)
- Oppose The roadmap is only stucked by you, so peoples are discussing how you could be softhearted. --Liuxinyu970226 (talk) 09:16, 12 November 2017 (UTC)
- PS: Let's simply count the votes above:
- Arguments to keep (6, 30%): Arbnos, Jklamo, Finn Årup Nielsen (fnielsen), ValterVB, Jura, and EncycloPetey;
- Arguments to delete (13, 65%): Pasleim, Kareyac, ArthurPSmith, Tubezlob, 50.53.1.33, Thierry Caro, Fralambert, billinghurst, Strakhov, Liuxinyu970226 (don't surprise, I already decided to migrate), Snipre, Queryzo, d1g
- Arguments neutral or no idea (1, 5%): Eran
Maybe it's worth to encourage those 30% to change their brain on P364. --Liuxinyu970226 (talk) 11:51, 12 November 2017 (UTC)
- Actually, we were trying to figure out a plan, not bean count. As nothing useful came up, we can close the discussion and leave it to the projects to sort out.
--- Jura 13:10, 22 November 2017 (UTC)
FINAL VOTE: Suggested closure reasons
1. Close as "No consensus to do actual delete/Consensus to keep"
- Oppose Such "consensus to keep" overwritten are violating the MediaWiki Code of Conduct (Q45161493), and if Jura1's opinion is this, it can even be subject to one reason that I request fireing their Administrator right. --Liuxinyu970226 (talk) 04:36, 30 December 2017 (UTC)
- What the hell are you talking about Liuxinyu970226? Multichill (talk) 20:35, 5 February 2018 (UTC)
2. Close as "Consensus to remove all usages like P794 below, then delete"
- Neutral Will ask @Deryck Chan: separately and privately for the possibility of this opinion. --Liuxinyu970226 (talk) 04:38, 30 December 2017 (UTC)
- @Liuxinyu970226: The P794 experience showed that this is possible, as long as people agree on what use cases migrate where. Deryck Chan (talk) 11:38, 24 January 2018 (UTC)
- Support only reasonable solution --Pasleim (talk) 18:16, 27 March 2018 (UTC)
- Support First choice. There are only 487 uses of original language of film or TV show (P364) where an item presents different values for original language of film or TV show (P364) and language of work or name (P407). Most external uses of original language of film or TV show (P364) are for film infoboxes and it seems that none of them use original language of film or TV show (P364) and language of work or name (P407) in the same infobox. We could simply copy all existing statements of original language of film or TV show (P364) to language of work or name (P407), switch all film infoboxes over to language of work or name (P407), then deprecate and delete original language of film or TV show (P364). Deryck Chan (talk) 10:53, 11 January 2019 (UTC)
3. Close as "remove all except films' usages"
- Support --Liuxinyu970226 (talk) 14:34, 20 December 2017 (UTC)
Support --Pasleim (talk) 13:41, 21 December 2017 (UTC)- Oppose even after months no reason is provided why the language of a movie should be described in a different way than for examples songs, websites or books --Pasleim (talk) 18:16, 27 March 2018 (UTC)
- Support and P794 has to be relabelled as movie original language to avoid any other use of this property. Snipre (talk) 21:30, 28 December 2017 (UTC)
- Support and change label per Snipre ArthurPSmith (talk) 21:52, 5 February 2018 (UTC)
- Support and change label - seems like a consensus solution to me. - PKM (talk) 19:15, 31 July 2018 (UTC)
- Weak support Second choice. Deryck Chan (talk) 10:53, 11 January 2019 (UTC)
4. Discussion
Since when did we resolve matters by voting, rather than reaching consensus through discussion? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:32, 5 February 2018 (UTC)
- Since this request has been open for a year. It is not uncommon to have a vote if some discussion gets stale. Also, the arguments of the discussion are being repeated in the vote (suggested closure reasons). Sjoerd de Bruin (talk) 13:48, 6 February 2018 (UTC)
- @Pigsonthewing: I must point that the discussion related to P364 is opened for a whole year, A WHOLE YEAR, how can a consensus not be happened within a whole year? --Liuxinyu970226 (talk) 04:34, 7 February 2018 (UTC)
There are only 487 items where the same item presents different values of original language of film or TV show (P364) and language of work or name (P407):
SELECT ?item ?itemLabel ?worklang ?worklangLabel ?origlang ?origlangLabel
WHERE
{
?item wdt:P407 ?worklang .
?item wdt:P364 ?origlang .
FILTER (?worklang != ?origlang) .
SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
ORDER BY ASC(?itemLabel)
--Deryck Chan (talk) 10:53, 11 January 2019 (UTC)
Also, "remove all except films usages" is relatively undisruptive because there are only 608 250 Update: I've now excluded film series as well, which brings down the total non-film/TV items, mainly songs, using original language of film or TV show (P364). But as I had stated above, other than those 487 items in the query above (which I think are an issue of data quality rather than refinement), I don't see original language of film or TV show (P364) and language of work or name (P407) having different purposes at this point.
SELECT (COUNT(?item) AS ?count)
WHERE
{
?item wdt:P364 ?origlang .
FILTER NOT EXISTS {?item wdt:P31/wdt:P279* wd:Q2431196 }.
SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
ORDER BY ASC(?itemLabel)
- This section was archived on a request by: --Pasleim (talk) 14:40, 17 January 2019 (UTC)
- 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 --Pasleim (talk) 14:15, 17 January 2019 (UTC)
download URL (P4945): (delete | history | links | entity usage | logs | discussion)
Created not trough property proposal process--Edgars2007 (talk) 11:35, 14 March 2018 (UTC)
- I'm not sure deletion is the right response here, as it maybe useful to have this. Although I believe there were previous discussions for similar properties that had a number of reason to oppose having download URL's as part of our data. But I'm more concerned that one of our property creators, MichaelSchoenitzer appears not to be aware of Wikidata:Property creators. How did that happen? ArthurPSmith (talk) 15:19, 14 March 2018 (UTC)
- I got the right at at time when there rules haven't existed yet. I knew Property Proposal and used this process but didn't thought it's a "no exceptions"-rule. (The site also does not sound like that.) I proposed splitting the property streaming media URL (P963) and no one disagreed. When someone renamed the old property I paniced because so we now have a few thousand wrong statements in Wikidata. I'm sorry I broke rules I didn't knew, I won't do again but I still think that we should clean this up quickly but that's on other people to decide now. -- MichaelSchoenitzer (talk) 21:49, 14 March 2018 (UTC)
- @MichaelSchoenitzer: The argument that another property is being abused to support this is a good one for creating it. However, there is quite a bit of history here - here are previous discussions along these lines where the proposal was rejected or at least not yet approved: Wikidata:Property proposal/download link, Wikidata:Property proposal/external image URL (which links to older proposal discussions in the "see also" section). @NMaia, Pintoch, Mahir256, ChristianKl: @Pigsonthewing, ديفيد عادل وهبة خليل 2, Strakhov, Pasleim, Jura1: what do you think on this now? ArthurPSmith (talk) 14:24, 15 March 2018 (UTC)
- I stand by my comments from the ‘download link’ proposal. Also Wikidata:Property proposal/Proposals for files is another previous related discussion. Mahir256 (talk) 14:38, 15 March 2018 (UTC)
- Delete agree with nominator.
--- Jura 09:26, 19 April 2018 (UTC)- Comment Somehow I missed that we actually had a proposal for this at Wikidata:Property proposal/download link (see comment below by Jasc PL) and the conclusion of that was not to create this.
--- Jura 06:55, 8 May 2018 (UTC)
- Comment Somehow I missed that we actually had a proposal for this at Wikidata:Property proposal/download link (see comment below by Jasc PL) and the conclusion of that was not to create this.
- Keep, or delete - if a property proposal process is the absolute rule for us; move this discuss to Wikidata:Property proposal/download link, then recreate download URL (P4945) (I hope) with this exact name. There are several important arguments for having this property. BTW, I see that computing items needs are much insufficient represent in the WD. --Jasc PL (talk) 14:55, 20 April 2018 (UTC)
- WikiProject Informatics has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. I would like to be able to use a property like download URL (P4945) on open source software items to list the download URL of particular software versions (sourced from the official website, source control systems of Linux distribution package repositories, etc). In many cases, the qualifier checksum (P4092) could and should be included, sourced from either official website and/or Linux distribution package repositories. file format (P2701) should also be a mandatory qualifier. What I am not clear on, is what is the difference between download URL (P4945) and full work available at URL (P953)? Could the scope of full work available at URL (P953) simply be expanded to include software source distributions, binaries, etc? If so, how would one determine which URL is for a source tarball, and which is a binary package? How would one handle software which has multiple binary packages (either for different CPU architectures or different Linux distribution packaging systems)? Dhx1 (talk) 14:15, 20 April 2018 (UTC)
- Full Support for Dhx1 arguments. --Jasc PL (talk) 14:55, 20 April 2018 (UTC)
- Delete Needs to come through proper property proposal process.--Jklamo (talk) 07:57, 31 May 2018 (UTC)
- Keep --Niridya (talk) 14:47, 16 August 2018 (UTC)
- @Niridya: for what reason? --Liuxinyu970226 (talk) 23:04, 13 September 2018 (UTC)
- @Liuxinyu970226: : sometimes it can be useful. For example to create a link to the download page of a software. --Niridya (talk) 18:01, 14 September 2018 (UTC)
- @Niridya: for what reason? --Liuxinyu970226 (talk) 23:04, 13 September 2018 (UTC)
- Keep Germartin1 (talk) 12:56, 12 October 2018 (UTC)
- Keep per above, given that there are many different usages of this property, I think there's no fair way to migrate. --Liuxinyu970226 (talk) 15:13, 14 January 2019 (UTC)
- This section was archived on a request by: --Pasleim (talk) 14:40, 17 January 2019 (UTC)
- 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 --Pasleim (talk) 14:19, 17 January 2019 (UTC)
P3188 (P3188): (delete | history | links | entity usage | logs)
Hello. On the base on Pigsonthewing's suggestion, I propose that we delete the generic identifier for Nobel laureates in other to split it into more specific ones. It would help us to classify more precisely our properties with instance of (P31) (Physics under Wikidata property related to physics (Q22981316), literature under Wikidata property related to literature (Q29561722), etc.). It would also be useful for completing easily specific external links templates such as Template:Research links (Q54913733) on French WP.--Nomen ad hoc (talk) 15:38, 31 July 2018 (UTC)
- Of course, the deletion would be immediately followed by the creation of the specific properties. Nomen ad hoc (talk) 15:39, 31 July 2018 (UTC).
- Delete. Thierry Caro (talk) 15:48, 31 July 2018 (UTC)
- Comment Deletion should not "be immediately followed by the creation of the specific properties"; once there is consensus to delete this property, the deletion should be put on hold; the new properties should then be created, and once done, the data be copied (or moved) across. Only then should the current property be deleted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:05, 31 July 2018 (UTC)
- Comment You're right. Nomen ad hoc (talk) 07:19, 1 August 2018 (UTC).
- Keep Strong oppose Even with this change the ID's would still consist of at least a "year/name" format, I don't think that's a significant simplification. And I believe it's better to treat the prizes as a whole than split them up for several reasons: (1) the number of ID"s is not large as it is so making this change would drop each of them to at most about 300, (2) there is not that large a distinction among the science fields - chemists have won in physics and in medicine as well as chemistry (and also the peace prize). Maybe there's a legitimate reason to treat the literature and peace prizes differently, but I am strongly opposed to splitting up the science prizes into separate ID's. ArthurPSmith (talk) 17:17, 31 July 2018 (UTC)
- ArthurPSmith: I changed my mind and then agree with you. 3 distinct properties (science - including physics, chemistry and medicine.-, peace, and literature) would suffice. Hence could you please support it? Nomen ad hoc (talk) 08:19, 13 August 2018 (UTC).
- Keep I still see no valid reason for splitting the current property. Cdlt, VIGNERON (talk) 07:23, 14 August 2018 (UTC)
- Keep but clean it up and maybe change formatter URL. We have now a federated search see discussion Property_talk:P3188 ==> that we get all Nobel Prize winners defined see list. My understanding is that Nobelprize.org has redesigned the web so someone needs to spend some time and find matching pages. I have tried communicate with Nobelprize.org with no success see T203915 - Salgo60 (talk) 07:30, 7 October 2018 (UTC)
- Comment I'm wondering to what extent this can really be regarded as an ID. I just tried to get from William Nordhaus (Q562481) to his entry on the Nobel side via Q562481#P3188, and it did not work, since the corresponding formatter URL (P1630) and format as a regular expression (P1793) do not fit with the actual https://www.nobelprize.org/prizes/economics/2018/nordhaus/facts/ , although they work for the property examples given. --Daniel Mietchen (talk) 00:33, 9 October 2018 (UTC)
- Comment @Mietchen: I have a dialogue with Nobel data and has done some federated searches T200668 / Listeria lists and my understanding is that they are migrating the old web to a new and miss a timeplan. I have asked to get updated of the status maybe we should have a depreciated status?!?!- Salgo60 (talk) 13:25, 11 October 2018 (UTC)
- This section was archived on a request by: --Pasleim (talk) 14:40, 17 January 2019 (UTC)
P969 (P969) (street address)
- 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 to a new property with monolingual datatype --Pasleim (talk) 14:25, 17 January 2019 (UTC)
P969 (P969): (delete | history | links | entity usage | logs | discussion)
Per Liuxinyu970226, this property should have the monolingual-text datatype because there are places which are bilingual and/or use multiple writing systems, such as Hong Kong (zh/en), Macau (zh/pt), Morocco (ar/ber/fr), most of Xinjiang (zh/ug), parts of Switzerland (de/fr/it/rm), and most of India (en/hi/bn/te/...). If deleted the property would need automatic conversion to a new property with that datatype with the language set based on the writing system of the text and the local language of the located in the administrative territorial entity (P131) or country (P17). —Jc86035 (talk) 16:35, 15 August 2018 (UTC)
I haven't notified any of the many projects which use this property, partly because I'm not sure exactly how I'm supposed to do it. Notifying all talk page contributors of this discussion. Ahoerstemeier, Bcoh, Danrok, Esquilo, Fnielsen, Fralambert, Giftzwerg 88, GZWDer, Ivan A. Krestinin, Jeremyb, Jhertel, Jura1, Kolja21, Laddo, Michiel1972, Napoleon.tan, Pasleim, SPQRobin, Syced, VicVal, Zolo. Jc86035 (talk) 16:50, 15 August 2018 (UTC)
Notifying all contributors to the property in the last two years. Alfonso Márquez, Avatar6, ChristianKl, Edoderoo, Geertivp, Herzi Pinki, İncelemeelemani, J budissin, JakobVoss, JMagalhães, Kareyac, Laura Marianne, Maitsavend, Mormegil, NMaia, Nvrandow, Obaid Raza, Oriciu, Otets, Pyro z, Red Winged Duck, Renamerr, Romaine, Ryanag, Sannita, Sigwald, Sjoerddebruin, Soued031, Susannaanas, Venkisrimba, Zeroth, Zyksnowy, Спасимир, আফতাবুজ্জামান. Jc86035 (talk) 16:53, 15 August 2018 (UTC)
- I also need these users who joined former two RFD discussions for this property to join here: @VIGNERON, -revi, Jianhui67, Amqui, Pigsonthewing:@Billinghurst, Rana24news, Jsamwrites, Pustekuchen2014, ArthurPSmith:@Oursana, Srittau, Edgars2007, Jklamo, RolandUnger:@Jheald, Anvilaquarius, JerryL2017, Diggr, Okkn:. --Liuxinyu970226 (talk) 05:41, 18 August 2018 (UTC)
- I think we already had this before, I found some at
- Wikidata:Requests_for_deletions/Archive/2015/Properties/1#located_at_street_address_(P969)
- Wikidata:Requests_for_deletions/Archive/2017/Properties/1#located_at_street_address_(P969)
--- Jura 17:00, 15 August 2018 (UTC)
- @Jura1: The first proposal for deletion is on the basis that the property duplicates located on street (P669), which is irrelevant here. The second only has one actually relevant comment (by Billinghurst), while the other comments are irrelevant to the topic at hand (anyone can change a property label, and there is no officially formalized process for replacing a widely-used property with another one of a different data type). The property proposal for the P969 replacement is about as bad, since the only opposes are from you (I disagree with your oppose vote, but only because qualifiers can't themselves have qualifiers) and Srittau (who wasn't aware that the property had already been unsuccessfully proposed for deletion). The other comments are complaints about the content of the data, even though it is made clear that the property has the same purpose as the old one. Jc86035 (talk) 07:12, 16 August 2018 (UTC)
- Comment The replacement property before de deletion request? --Fralambert (talk) 17:15, 15 August 2018 (UTC)
- The royal route would be to create a new property -> move the data -> delete the old property. Yes, this will take time, but that should be no issue. Edoderoo (talk) 19:37, 15 August 2018 (UTC)
- Well, obviously I'm not proposing that P969 be deleted immediately if the discussion is closed as delete/replace, and the discussion has to go somewhere. Not a lot of people watch the property proposals subpages. Jc86035 (talk) 07:16, 16 August 2018 (UTC)
- Delete As said before, let's do this replacement. --Liuxinyu970226 (talk) 22:42, 15 August 2018 (UTC)
- Comment If I understand properly, you want to create a new (multilingual) property, do the migration, then delete this property? If you will do all of this, then yes I agree. Syced (talk) 03:00, 16 August 2018 (UTC)
- Comment Total items with P969 - 813000, items without P131 - 16700, items without P17 - 1450, items without P17 & P131 - 950. --Voll (talk) 08:28, 16 August 2018 (UTC)
- @Voll: Does the count of 950 include statements in which P969 (P969) is used as a qualifier? I guess those would have language added based on the object/value rather than the subject/item. Jc86035 (talk) 11:30, 16 August 2018 (UTC)
- It counts only real statements, no qualifiers. I wanted to say that using P17 in the migration is better, then P131. --Voll (talk) 15:03, 16 August 2018 (UTC)
- @Voll, Jc86035: I would love to know how this property is used on items that neither have P17 nor P131, are they mis-used this as e.g. IP addresses? --Liuxinyu970226 (talk) 06:02, 18 August 2018 (UTC)
- Is it enough for the investigation? --Voll (talk) 13:24, 19 August 2018 (UTC)Try it!
SELECT ?item ?itemLabel ?street WHERE { ?item wdt:P969 ?street. MINUS {?item wdt:P131 ?where}. MINUS {?item wdt:P17 ?country}. SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE]". } }
- Comment As per Syced. Sannita - not just another it.wiki sysop 10:43, 16 August 2018 (UTC)
- Comment the property is used as a qualifier outside of the the above examples, eg. to qualify births and death addresses, and to require those in multiple languages does not seem relevant, and in fact would seem detrimental to the available data if it is language particular. So maybe it useful for the major uses that you envisage, I do not see it universally advantageous where I add it. This aspect needs to be addressed as many places do not have multiple languages in place, and it appears that you are just making data addition harder. This has been raised previously, and again the proponents are not offering solutions.
It would be useful to see reports of where the property is used as a qualifier and to see the scenarios where it would be an advantage, and where it is a disadvantageous. — billinghurst sDrewth 06:03, 18 August 2018 (UTC)
- @billinghurst: For places of birth/death, we already have place of birth (P19) and place of death (P20) for several
decadesyears, why they still wanna full addresses for them, to reflect what things? Using monolingual text datatype can also introduce a stable way to sync translations of addresses, at least zhwiki users always translate foreign addresses in infoboxes of place articles, nothing is hard in this topic area by translating. I also believe that the Jc86035 is helping to find solution of this stable way, and if you think digging more and more property usage is indeed on this page, feel free to ping me in any free time, as I'm online here at least 8 hours per day. --Liuxinyu970226 (talk) 06:12, 18 August 2018 (UTC)- Truly asking that? Specific information that is regularly added to biographical articles now and in the 19thC, has been captured here as a qualifier and you are saying that it isn't pertinent? Why would ask for me to justify that? With burial data, we collect a place. Saying we ignore the cemetery? ignore the plot data? — billinghurst sDrewth 06:25, 18 August 2018 (UTC)
- Fwiw, such informations that are about fictional things, are called as dōjin (Q1272707) in Asian countries, and how these "dojin"s are also needed here? --Liuxinyu970226 (talk) 06:35, 18 August 2018 (UTC)
- Truly asking that? Specific information that is regularly added to biographical articles now and in the 19thC, has been captured here as a qualifier and you are saying that it isn't pertinent? Why would ask for me to justify that? With burial data, we collect a place. Saying we ignore the cemetery? ignore the plot data? — billinghurst sDrewth 06:25, 18 August 2018 (UTC)
- @billinghurst: For places of birth/death, we already have place of birth (P19) and place of death (P20) for several
- Delete the proposition seems about right. Not sure why I'm pinged, I almost always use located on street (P669) (true, it needs to create a specific items but it's so much better in the end). What would be good is to ping the top users of this property: @Michiel1972, Multichill, Anvilaquarius, Alicia Fagerving (WMSE), Yarl, Gzen92:. Cdlt, VIGNERON (talk) 07:18, 18 August 2018 (UTC)
- Delete located on street (P669) is more adapted. Gzen92 [discuter] 07:51, 19 August 2018 (UTC)
- @Gzen92, VIGNERON: My proposal is not to delete the property but to replace it with a new data type; I guess it would be possible to replace this with located on street (P669) but a lot of items for streets would have to be created in order for this to happen at all. Jc86035 (talk) 08:13, 19 August 2018 (UTC)
- @Jc86035: I knew and I understood that. Anyway and anyhow, I support the datatype change (which *is* a deletion technically) but for the long run, I still think that people should use located on street (P669), this is what I do at least and I can only advise others to do the same. Cdlt, VIGNERON (talk) 08:36, 19 August 2018 (UTC)
- Well, case by case, as a Chinese user, I would rather support showing addresses in both ways, this is very like that we the Wikimedia network don't only have one or two, but have five clusters (codfw (Q50396890), eqiad (Q50822718), eqsin (Q51009782), esams (Q50822709) and ulsfo (Q51012361)). --Liuxinyu970226 (talk) 11:15, 19 August 2018 (UTC)
- No, located on street (P669) cannot replace this property, there are countries (e.g. Thailand) where postal addresses usually don't contain a street. Ahoerstemeier (talk) 15:15, 20 August 2018 (UTC)
- Comment Address in Japan also cannot be represented by located on street (P669) and house number (P670) (see w:Japanese addressing system). Before deleting this property, we have to create other properties to represent it. --Okkn (talk) 09:36, 23 August 2018 (UTC)
- @Okkn: What about creating a lot of dummy items to say * Chōme (*丁目)? Or maybe Cebuano Wikipedia has plan to push them? Doing so can raise up a lot of P669 usage concerns in Japanese IMO. --Liuxinyu970226 (talk) 05:46, 24 August 2018 (UTC)
- @Liuxinyu970226: I don’t feel right about regarding "*丁目" as "street". "*丁目" or sometimes "*丁" is a block. OSM tags representing Japanese block number addressing system may be helpful (https://wiki.openstreetmap.org/wiki/JA:%E4%BD%8F%E6%89%80#.E6.97.A5.E6.9C.AC.E3.81.AE.E4.BD.8F.E6.89.80.E4.BD.93.E7.B3.BB.28.E8.A1.97.E5.8C.BA.E7.95.AA.E5.8F.B7.E3.83.BB.E5.9C.B0.E7.B1.8D.E8.BB.A2.E7.94.A8.29). --Okkn (talk) 06:37, 24 August 2018 (UTC)
- @Okkn: What about creating a lot of dummy items to say * Chōme (*丁目)? Or maybe Cebuano Wikipedia has plan to push them? Doing so can raise up a lot of P669 usage concerns in Japanese IMO. --Liuxinyu970226 (talk) 05:46, 24 August 2018 (UTC)
- Comment Address in Japan also cannot be represented by located on street (P669) and house number (P670) (see w:Japanese addressing system). Before deleting this property, we have to create other properties to represent it. --Okkn (talk) 09:36, 23 August 2018 (UTC)
- @Jc86035: I knew and I understood that. Anyway and anyhow, I support the datatype change (which *is* a deletion technically) but for the long run, I still think that people should use located on street (P669), this is what I do at least and I can only advise others to do the same. Cdlt, VIGNERON (talk) 08:36, 19 August 2018 (UTC)
- @Gzen92, VIGNERON: My proposal is not to delete the property but to replace it with a new data type; I guess it would be possible to replace this with located on street (P669) but a lot of items for streets would have to be created in order for this to happen at all. Jc86035 (talk) 08:13, 19 August 2018 (UTC)
Template:Vote not delete to see language it should have qualifier('s) language of work or name (P407), otherwise the language is default for local postal service. Monolingual property, instead of it is for now, would overuse the purpose of "postal address" by localizations that is not necessary in wikidata, that localisations should be done in local projects .--Avatar6 (talk) 17:32, 18 September 2018 (UTC)
- @Avatar6: Please see what I said before at Wikidata:Project_chat/Archive/2018/08#P969 concern, there are really a number of Wikipedias which don't have function to query qualifiers, thus P407 can't actually work for them. --Liuxinyu970226 (talk) 04:56, 19 September 2018 (UTC)
- Delete This property should learn How official name works. --223.104.7.133 02:15, 22 September 2018 (UTC)
- Caution Concerns similar to User:Billinghurst above. I am currently using this as a qualifier to place of publication (P291) based on catalogue records for some 18th century maps, using data from MARC field 264 in the library records. Once all the data is in, it will be valuable to be able to see and sanity-check what different addresses are given for the same person, and how these may correlate to other information in the records. I can guess that the language of that statement corresponds to the language of the work, but I can't be sure (in some cases, it may have been added by the cataloguer, for example). Jheald (talk) 16:52, 28 September 2018 (UTC)
- @Jheald: Why not just specify them as Latin (la)? --Liuxinyu970226 (talk) 04:04, 30 September 2018 (UTC)
: Delete I really can't agree some opinions like @Avatar6:'s "otherwise the language is default for local postal servic", Avatar6 I must tell you that the post stations in Canada always use both English and French for each place AT SAME TIME! Thus we the Canadian really wanna show the languages of addresses that a random place has. --180.97.204.2 23:32, 1 November 2018 (UTC)
- Delete A nonsense pure-string property, can be migrated to a translateable format, will this fall under snowball closure? --218.68.229.88 07:23, 24 December 2018 (UTC)
- Keep The application was to change the property type from string to monolingual-text not to delete the property itself. A bot can add the missing languages from the country property. The property is used in several wikis which means huge efforts in changing scripts and copying addresses by bots or manually. --RolandUnger (talk) 09:03, 6 January 2019 (UTC)
- @RolandUnger: Then why official name (P1448) can be a monolingual text and this cannot be? --117.13.95.179 03:21, 8 January 2019 (UTC)
- It is very simple: At the phase of application of P969 (P969) the English-speaking contributors had no idea about this problem. We discussed the type change to monolingual text several times at Wikidata but the discussions had no effect. --RolandUnger (talk) 05:33, 8 January 2019 (UTC)
- Really? At least Canadian people still have concerns against this per 180.97.204.2, where Canada is, as well as we the people around the world know, an en-fr bilingualism country. --125.38.13.94 01:14, 9 January 2019 (UTC)
- Additionally, @RolandUnger, Avatar6: Are you both supporting the United States-only, in fact *vetoed by many other English-speaking countries*, the English-only movement (Q2719842)? If yes, then you both can strike your votes right now, because Wikidata is a Multilingualism project, not a XXX language-only project. --Liuxinyu970226 (talk) 15:36, 14 January 2019 (UTC)
- It is very simple: At the phase of application of P969 (P969) the English-speaking contributors had no idea about this problem. We discussed the type change to monolingual text several times at Wikidata but the discussions had no effect. --RolandUnger (talk) 05:33, 8 January 2019 (UTC)
- Delete That said, Canadian users won't agree anythings that are English-only, and this is the only way Chinese users can show translated address without modifying locally. --125.38.13.94 01:16, 9 January 2019 (UTC)
- Comment Now the discussions reflected some Canadian issues, wondering if members of Wikimedia Canada (Q15627703) can tell us more info on this problem: @Benoit Rochon, Lea-Kim, Chabadin, GLafrance, GabrielArseno2:@Marie D Martel, BiblioQC, Thekidpossum, OhanaUnited, AlphaTwo:, and I will write emails to info wikimedia.org --117.13.95.57 05:31, 11 January 2019 (UTC)
- Comment It's hard to understand the real impact of all the above discussions, but one thing is certain, in Canada addresses can not be monolingual see also (fr). I hope I have focused your questioning. Best regards, Benoit Rochon (talk) 15:43, 12 January 2019 (UTC)
- Weak support migration to "monolingual text" datatype. With 300k uses of this property, I think it'll be difficult to identify the language of each address reliably, which is my only concern about migration. Oppose deletion without migration. Deryck Chan (talk) 17:32, 12 January 2019 (UTC)
- This section was archived on a request by: --Pasleim (talk) 14:40, 17 January 2019 (UTC)
- 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 P:P1685, no consensus on P:P1112 --Pasleim (talk) 14:09, 17 January 2019 (UTC)
P1112 (P1112): (delete | history | links | entity usage | logs) Pokémon index (P1685): (delete | history | links | entity usage | logs | discussion)
It's too specific and get's used to justify other very specific property proposals. Existing data should be moved to catalog code (P528).--ChristianKl (talk) 19:36, 4 November 2017 (UTC) @Legoktm, Jakob:
- I initially wanted to answer with
{{vote_keep}}
because I think wikidata should also provide space for very specific types of data. I like the approach you have with catalog code (P528) though. Lets find something similar for Stardate 😀 --Shisma (talk) 20:04, 4 November 2017 (UTC)
- Comment additional properties like this should not be created but this looks like a special exception. Pokémon seem to get sorted by this value in different lists. Before proposing a deletion we should come up with more detailed alternatives and examples. catalog code (P528) alone is not enough, how about the existing qualifiers? -- JakobVoss (talk) 08:22, 10 November 2017 (UTC)
- Comment The other property proposals seem to be Wikidata:Property proposal/Stardate.
--- Jura 08:49, 11 November 2017 (UTC) - P1112 is used for many different listings/catalogues (eg National Pokédex (Q20005020), Hoenn Pokédex (Q18086665)), using the unfortunate and ambiguous of (P642) to distinguish between them (instead of catalog (P972)). The property is also much too specific, per ChristianKl. Using catalog code (P528) seems like a good solution and we can move/adapt the existing qualifiers. Delete. --Yair rand (talk) 13:57, 14 November 2017 (UTC)
Question Do Pokemon items currently use catalog code (P528) for any other purpose? Comment We should try not to break fr:Modèle:Infobox Famille Pokémon/Espèce/Bac à sable. Deryck Chan (talk) 20:43, 16 November 2017 (UTC)Nevermind. That template is a sandbox and the use of Wikidata hasn't made its way to the actual sandbox yet. Deryck Chan (talk) 19:35, 11 December 2017 (UTC)- Okay I figured out that no item currently uses both P1112 (P1112) and catalog code (P528):
- Try it!
SELECT DISTINCT ?pokemon ?pokemonLabel ?pokedex WHERE { ?pokemon wdt:P1112 ?pokedex ; wdt:P972 ?catindex . SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . } } ORDER BY ?pokemonLabel LIMIT 1000
- ...and it's all qualified using of (P642) as discussed above:
- Try it!
SELECT DISTINCT ?pokemon ?pokemonLabel ?pokedex ?ofwhatLabel WHERE { ?pokemon wdt:P1112 ?pokedex ; p:P1112 ?statement . ?statement pq:P642 ?ofwhat . SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . } } ORDER BY ?pokemonLabel LIMIT 4000
- I agree with the proposal: Delete and migrate all P1112
of (P642) to catalog code (P528) catalog (P972). Deryck Chan (talk) 21:57, 16 November 2017 (UTC) Withdrawing my support for deletion at the moment. Lewis Hulbert's discovery would mean that it's not possible to delete both P1112 (P1112) and Pokémon index (P1685) without breaking fr:Modèle:Infobox Famille Pokémon/Espèce/Bac à sable which uses both, until {{#statements:}} or Module:Wikidata develop further functionality to select statements with certain qualifier targets only.Deryck Chan (talk) 14:14, 3 December 2017 (UTC)- Changing my mind again because I misunderstood the French template. It's still in draft mode and the use of Wikidata hasn't made it to the actual template yet. Deryck Chan (talk) 19:35, 11 December 2017 (UTC)
- Comment - Pokémon index (P1685) should also be included in this discussion, as it is essentially the same thing. --Lewis Hulbert (talk) 22:07, 17 November 2017 (UTC)
- I've added P1685 (Pokemon browser number) to this. We should also migrate Pokémon index (P1685)
of (P642) to catalog code (P528) catalog (P972). There is no conflict because Pokédex numbers and Pokémon Browser identifiers are in complementary distribution. Deryck Chan (talk) 15:50, 11 December 2017 (UTC)
- I've added P1685 (Pokemon browser number) to this. We should also migrate Pokémon index (P1685)
- Keep In order to sustain consistency and integrity of data, property constraints of (moderately) specific properties are helpful. --Okkn (talk) 02:13, 14 December 2017 (UTC)
- @Okkn: Constraints on specific types of uses could still be made to work via complex constraints. --Yair rand (talk) 23:51, 2 January 2018 (UTC)
- @Yair rand: They will work, but the talk page of catalog code (P528) will become too complex for human to read and to maintain. Specific (sub)property solution is simple and clear. --Okkn (talk) 04:48, 3 January 2018 (UTC)
- @Okkn: There's no "actual complex" in so many property talk pages, if you think Property talk:P528 will even be complex, then Property talk:P17 will only be accessable by the Bitcoin mining machines. --Liuxinyu970226 (talk) 05:09, 10 January 2018 (UTC)
- When we have P1112 (P1112) or other specific properties, we can describe most property constraints by using property constraint (P2302), independently of SPARQL language. Hard-coded SPARQL queries in the complex constraints template reduce the maintainability in exchange for their high flexibility. There is no necessity for us to lose the simple property constraint (P2302) solution in P1112 (P1112). P1112 (P1112) should be just a subproperty of catalog code (P528). --Okkn (talk) 09:06, 10 January 2018 (UTC)
- @Okkn: There's no "actual complex" in so many property talk pages, if you think Property talk:P528 will even be complex, then Property talk:P17 will only be accessable by the Bitcoin mining machines. --Liuxinyu970226 (talk) 05:09, 10 January 2018 (UTC)
- @Yair rand: They will work, but the talk page of catalog code (P528) will become too complex for human to read and to maintain. Specific (sub)property solution is simple and clear. --Okkn (talk) 04:48, 3 January 2018 (UTC)
- @Okkn: Constraints on specific types of uses could still be made to work via complex constraints. --Yair rand (talk) 23:51, 2 January 2018 (UTC)
@Ju gatsu mikka, Ebe123, Airon90, MGChecker: What do you think about this? You have edited Pokemon species items. --Okkn (talk) 10:08, 16 April 2018 (UTC)
- I agree P1685 is too specific, however I agree with user:Okkn that a specific property for Pokédex number has major benefits for data integrity. How would you like to specify similar constraints with P642? --MGChecker (talk) 19:40, 17 April 2018 (UTC)
- Good bye as Pokedexes can also be different between series (don't surprise, PM anime also have characters that ruled different dexes), I can't see a neutral way to create a lot of properties in order to sync something that ≤1000 usages. --Liuxinyu970226 (talk) 13:21, 25 April 2018 (UTC)
- Comment I don't understand what's the problem with an unambiguous property used hundreds of times. It's very specific, and so? Personally, I don't have nothing against specific properties:
- are often more intuitive than broader ones and therefore they make it easier for new editor to contribute;
- can be linked with external properties as specific as them;
- can be linked with broader properties via "subproperty of" and so they don't cause any problem in the ontology;
- are easier to manage for Quickstatement, bots and other third party tools than qualifiers.--Malore (talk) 08:13, 28 November 2018 (UTC)
- @MGChecker, Malore, Liuxinyu970226, Okkn, Yair rand, Lewis Hulbert: I have written a script that will migrate these properties as and when we need it. Test runs: [13][14][15]. Deryck Chan (talk) 16:25, 5 January 2019 (UTC)
- While this looks fine, I don't see an example of where you migrated P1685. Furthermore, I still don't like the negative effects this migration has on data integrity, as we can't use effective constraints anymore. --MGChecker (talk) 06:41, 8 January 2019 (UTC)
- I think we can summarize the discussion so far:
- There is consensus that existing uses of of (P642) as a qualifier to P1112 (P1112) and Pokémon index (P1685) should migrate to catalog (P972).
- There is consensus that Pokémon index (P1685) is too specific. We should deprecate it.
- We don't agree whether we should keep P1112 (P1112). That leaves us with three possibilities:
- Keep both properties, do nothing (default outcome, but I think consensus is against this)
- Deprecate Pokémon index (P1685). Specifically, move all Pokémon index (P1685)/of (P642) to P1112 (P1112)/catalog (P972); move all P1112 (P1112)/of (P642) to P1112 (P1112)/catalog (P972)
- Deprecate both Pokémon index (P1685) and P1112 (P1112). Move all Pokémon index (P1685)/of (P642) and P1112 (P1112)/of (P642) to catalog code (P528)/catalog (P972).
- I personally prefer 3 > 2 > 1. (Ping MGChecker again.) Deryck Chan (talk) 14:30, 10 January 2019 (UTC)
- 2 > 3 > 1 --MGChecker (talk) 23:20, 13 January 2019 (UTC)
- I think we can summarize the discussion so far:
- While this looks fine, I don't see an example of where you migrated P1685. Furthermore, I still don't like the negative effects this migration has on data integrity, as we can't use effective constraints anymore. --MGChecker (talk) 06:41, 8 January 2019 (UTC)
- @Pasleim: I've just found a technical problem which I didn't notice until you closed the discussion (and I apologize for not pointing it out earlier). Pokémon index (P1685) has String datatype while P1112 (P1112) has Quantity datatype. That means merging from P1685 to P1112 is technically impossible (because some entries have non-numerical characters in their Pokemon Browser codes); but merging in the other direction is feasible. There are no known external uses of these properties except in sandboxes. Would it be acceptable if I run my script in reverse and merge all uses of P1112 to P1685 instead? Deryck Chan (talk) 18:52, 18 January 2019 (UTC)
- for me this is okay. --Pasleim (talk) 20:29, 18 January 2019 (UTC)
- This section was archived on a request by: --Pasleim (talk) 10:19, 24 January 2019 (UTC)
- 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 support for deletion --Pasleim (talk) 09:22, 1 March 2019 (UTC)
Soccerway player ID (P2369): (delete | history | links | entity usage | logs | discussion)
This property retrieves the same data from the same database as the P3043 (P3043). When a player becomes a coach, his statistics disappear on Soccerway[16][17][18], but it still remains on Scoresway[19][20][21]. —Сидик из ПТУ (talk) 11:12, 18 October 2018 (UTC)
- Soccerway player ID (P2369) is used with Template:Soccerway (Q13234327) in Wikipedias: be, en, es, eu, it, ja, ka, mk, ro, sco, simple, sr, uk.Сидик из ПТУ (talk) 11:30, 18 October 2018 (UTC)
- Pinging maintainers (maybe) of the English version of that template: @BigDom, TheBigJagielka, Struway2, OffsBlink, Reckless182:@WOSlinker, The Earwig, Yellow Dingo, Zyxw, Pigsonthewing:@SLBedit, Primefac:, maybe other language versions can also be updated by importing or copy-pasting from enwiki. --Liuxinyu970226 (talk) 09:38, 26 January 2019 (UTC)
- This section was archived on a request by: --Pasleim (talk) 09:22, 1 March 2019 (UTC)
- 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 --Pasleim (talk) 09:23, 1 March 2019 (UTC)
Commons category (P373): (delete | history | links | entity usage | logs | discussion)
Systematically redundant property, merge with topic's main category (P910). For an item which has a direct interproject link to Commons category, this property is duplicate of the interproject link and it requires redundant maintenance work to keep the two linking forms consistent. For items which have a property topic's main category (P910), the property Commons category (P373) is redundant because the linked Commons category should be joined by an interproject link with the P910 target category. Before deletion of P373 property, all P373 data should by transformed to interproject links, either directly, or through the P910 target item. —ŠJů (talk) 15:42, 2 November 2018 (UTC)
- Request for clarification: Wikidata went against the general consensus of Commons users by favoring gallery (main space) pages on Commons over the Category pages, which most of us on Commons consider primary. That means there are a lot of items that are sitelinked to an (often useless) Commons gallery (main space) page in preference to a meaningful Commons category.
- If I understand correctly, your rationale is that in those cases there will always be a corresponding item on Wikidata for the category in question linked via topic's main category (P910) and that the Commons category will always be sitelinked from that item for the category, or that if it is not we can solve that with a bot before eliminating this property. Have I understood you correctly? - Jmabel (talk) 19:08, 2 November 2018 (UTC)
- @Jmabel: Generally, gallery pages never were a real equivalent of articles. The fact that both of them have no prefix at their projects doesn't mean that they have anything in common. While categories and articles should be unique for its items, one item can have more various gallery pages in one project. Commons gallery (P935) is similar to image (P18). Gallery pages should have no interproject links, such as file pages have no interwikis and no interproject links at Wikidata. Gallery pages are something like a collage image, in principle. Unique relations to item-unique pages should be linked through interproject/interwiki links, while 1:N links or links to examples or digests (selected images or galleries) should be properties.
- As long as some items have two item-pages on Wikidata (one for article pages and one for category pages), we should to keep the existing preferences: if the item have its own category on at least one Wikipedia project, the Commons category should by linked with the Wikipedia category and category item page. If the item has no category at non-Commons projects, the Commons category should be joined to the basic Wikidata item page (i.e. directly with articles of that item), unless it is blocked by Commons gallery page. In such case, we are forced to use two Wikidata item pages: first one for article and gallery pages, second one for Commons category page. --ŠJů (talk) 01:01, 3 November 2018 (UTC)
- I agree entirely that Wikidata's preference for gallery pages is misguided, and is based on a misapprehension of their nature.
- I think where you are headed with this is reasonable: just so long as Commons categories are understood to be the main relevant sitelink to Commons, and they won't ever be omitted entirely in favor of something else on Commons. - Jmabel (talk) 06:43, 3 November 2018 (UTC)
- Oppose Commons category (P373) would be useless if Wikidata hadn't preferred the useless galleries over category pages. Therefore, the fix shouldn't be going through a two-step path to find the meaningful Commons category but to have it as preferred option when it comes to an interproject link. --Discasto (talk) 19:23, 2 November 2018 (UTC)
- @Discasto: There are two basal problems. The first of them is that one item has two item pages on Wikidata, in some cases. The second one is a incomprehension of character of gallery pages. You mention only the second problem, while the first problem is more urgent to be treated and compensated. --ŠJů (talk) 01:12, 3 November 2018 (UTC)
- Keep topic's main category (P910) has a different datatype and merging would only be possible in the way described by Jmabel which isn't nice outlook. --Marsupium (talk) 21:17, 2 November 2018 (UTC)
- @Marsupium: It is rather a bug that topic's main category (P910) has a different datatype than Commons category (P373). The proposed merge can solve the bug elegantly. --ŠJů (talk) 01:12, 3 November 2018 (UTC)
- @ŠJů: I don't think I'd consider to create ~2M – wild guess, you might want to calculate it – single-sitelink Wikimedia category (Q4167836) items to be elegant. --Marsupium (talk) 01:24, 3 November 2018 (UTC)
- @Marsupium: It is rather a bug that topic's main category (P910) has a different datatype than Commons category (P373). The proposed merge can solve the bug elegantly. --ŠJů (talk) 01:12, 3 November 2018 (UTC)
- Comment I support this in the long run, but this request is probably a bit early. For background info, Pi bot has added hundreds of thousands of commons sitelinks over the last year, as the sitelinks are used by commons:Template:Wikidata Infobox. That was primarily based on Commons category (P373) values, but other matches have also been used (IDs and image (P18) values in particular). And as a temporary measure, the bot updates P373 values where they differ from the sitelink and they point to a commons category redirect. However, there are still quite a few P373 values that need manually resolving/the correct sitelink adding. Plus the gallery vs. category issue that Jmabel mentions above (although @Jheald: mostly fixed that by creating new category items for those cases, which are linked by topic's main category (P910)/category's main topic (P301)). And then there are all of the uses of this property outside of Wikidata ... I would however Support marking this property as deprecated, and resolving the remaining issues so that we can move over to using the sitelinks instead - but that will probably still take some time to accomplish. Thanks. Mike Peel (talk) 22:58, 2 November 2018 (UTC)
- Support marking as deprecated and cleaning up as needed. No definite opinion on the best route to clean up, but I support the effort to reduce redundant maintenance of data. Kaldari (talk) 00:41, 3 November 2018 (UTC)
- I don't think P373 can be deprecated as long as there's no official solution to the gallery sitelink problem. There was no consensus to prefer Commons category sitelinks to gallery links, last time I asked, and category items with only a sitelink to Commons are still prohibited by Wikidata:Notability. I'd also like to know if the Wikimedia software, when creating toolbar links in other projects, actually checks for a linked category item with a Commons sitelink. It's possible that a lot of links to Commons in other projects would be lost (or category links replaced with links to galleries). Ghouston (talk) 04:35, 3 November 2018 (UTC)
- I agree. All steps must be taken successively so that no information is lost.--ŠJů (talk) 11:18, 3 November 2018 (UTC)
- Unfortunately, the page Wikidata:Notability is completely out of reality and out of real consensus.
- It e.g. claims that "a sitelink cannot point to a redirect" and ignores consensually existing and useful item-pages for Wikimedia disambiguation page (Q4167410).
- It claims that "items to category pages on Wikimedia Commons are allowed if and only if they are linked with category pages on other Wikimedia sites" while such relations were massively, consensually and effectively used long before the start of Wikidata and there was no consensus to destroy such relations or to make them unfunctional.
- It claims that a Wikidata item-page "contains at least one valid sitelink", while really, there was and is a consensus to import monuments from monument lists (even for monuments which have no separate page – as an analogy of the external tool Commons:Monuments database) or streets from official street registers (even for streets which have no image uploaded and no category or article created yet). (I would be glad if this note did not inspire anyone to destroy this great work.) --ŠJů (talk) 11:45, 3 November 2018 (UTC)
- Sort of. I don't think your 3rd point is valid, since an item only needs to meet one of the 3 criteria, and the monuments can meet 2) instead of 1). For your first point, there's a footnote that says "Currently, the community has chosen to have redirects allowed, although the necessary changes have yet to be deployed on Wikidata." The second point is a problem though. I tried a while ago to change it (Wikidata_talk:Notability/Archive_4#Category_items) but there was some opposition and it just got archived without reaching consensus. Ghouston (talk) 22:38, 3 November 2018 (UTC)
- Keep Per Ghouston. Not the proper channel IMHO. Choosing how Wikidata should model its relation with Commons should not happen in a Property deletion request but... in a RFC. Additionally, I may add es.wikipedia (at least) is using P373 to fill two highly used templates. strakhov (talk) 22:31, 3 November 2018 (UTC)
- Comment Interesting proposal, but a couple of points: (1) P373 is currently being used massively by the MediaWiki configuration on most Wikipedias to determine what sitelink to show to Commons. Re-tooling to see whether (i) there is a topic's main category (P910), (ii) with a sitelink, (iii) that goes to Commons would need to be investigated and proven first. (2) That three-step process is significantly slower for big queries than looking up a P373 -- so, for example, in WDQS it is currently possible to count the number of uses of P373; but it is not (I think) possible to count the number of sitelinks within the query time-out. (eg: query to get total number of Commons categories with sitelinks
tinyurl.com/y74hneqx
already takes 40 seconds; query to see how many of those have P910tinyurl.com/y89d7mbl
times out). This can have implications for various sorts of maintenance queries. Jheald (talk) 10:47, 4 November 2018 (UTC)
- Another long-standing issue with P373 is that there are many categories on Commons that are the target of P373 statements from more than one main-type Wikidata item. See this query for some of the most popular:
tinyurl.com/yc8hwteb
. Some further queries to try to identify some of the Wikidata items which may not be primary matches to the Commons category can be found here: Property_talk:P373#More_queries. The community would need to definitively think about the desirability (or not) of these multi-matches, and which one to choose, or whether to take some other action, before retiring P373. Jheald (talk) 11:39, 4 November 2018 (UTC)
- @Multichill: fyi--- Jura 12:01, 4 November 2018 (UTC)
- Keep massive usage, not a good alternative. Multichill (talk) 12:33, 4 November 2018 (UTC)
- Delete. I have long supported deletion of this property in favor of storing the categories with topic's main category. Let's do that and use Wikidata for the power the property provides us. Yes, we add a few million items, but we're already at 50M. We can figure out which ones are the best targets for creation if we want, or we can take them all. (I'm inclined to take them all TBH; there will be value when we get around to SDC Soon.) Let's get WD:N fixed regarding those category items while we're at it. --Izno (talk) 13:39, 4 November 2018 (UTC)
- Oppose too soon, show me the migration plan, with some examples of a process. Slowking4 (talk) 23:55, 7 November 2018 (UTC)
- Can we at least agree on removing all interproject links to Commons galleries, as they were never supposed to be used that way?--DarwIn (talk) 21:10, 16 December 2018 (UTC)
- I would vote for that proposal. --Jarekt (talk) 03:09, 18 December 2018 (UTC)
- I'm OK with removing gallery sitelinks from everywhere, after copypasting them to Commons gallery (P935). strakhov (talk) 12:58, 19 December 2018 (UTC)
- If so, it would be needed to verify they are not pseudo-galleries (I mean, "redirects to categories"). In that case, they should be replaced by the category sitelink. strakhov (talk) 13:02, 19 December 2018 (UTC)
- Keep W use it a lot and for a lot of items there is no way of storing this connection in any other way, without creating massive number of additional items. --Jarekt (talk) 03:09, 18 December 2018 (UTC)
- Delete Used by two many items shouldn't be a keep reason, we deleted P794 (P794) before. --60.26.9.8 07:19, 20 December 2018 (UTC)
- Neutral Before planning of deleting P373 we should find solution for cases, when one categori is linked form more items. [Wikidata:Database_reports/Complex_constraint_violations/P373#Two_category_items_linking_to_the_same_Commons_category|example 1]], "Unique_value"_violations 2. JAn Dudík (talk) 19:57, 4 January 2019 (UTC)
- Keep. Commons category is a serviceable compromise solution to the problem described above: Commons uses namespaces differently from Wikipedia, and the Wikidata community doesn't want to cross namespaces among the sitelinks of an item, nor does Wikidata wants items with a Commons category as its sole sitelink. This property sidesteps the issue and has worked for some time, so until we can agree on an alternative way to represent the relationship between a Wikipedia article topic and its relevant Commons category, we should let this property stay. Deryck Chan (talk) 14:37, 10 January 2019 (UTC)
- @Deryck Chan: If the problem is "the Wikidata community doesn't want to cross namespaces among the sitelinks of an item", can't we ask re-allowing it? Or can't we ask for storeing both one gallery and one category on same one item? --218.68.229.42 02:10, 2 February 2019 (UTC)
- We can re-open the discussion on adding Commons categories as sitelinks to items, but until people can agree on that, it isn't time to delete this property. Storing both a gallery and a category to an item as sitelinks is technically impractical given how Wikidata has been running for seven years. Deryck Chan (talk) 10:16, 2 February 2019 (UTC)
- @Deryck Chan: If the problem is "the Wikidata community doesn't want to cross namespaces among the sitelinks of an item", can't we ask re-allowing it? Or can't we ask for storeing both one gallery and one category on same one item? --218.68.229.42 02:10, 2 February 2019 (UTC)
- Keep. - PKM (talk) 20:00, 19 January 2019 (UTC)
- Keep. --Derzno (talk) 06:01, 3 February 2019 (UTC)
- Keep. In Russian Wikipedia we use Commons category (P373) in a great deal of temlates including crucial important ones. Removing the property right now just would break links to Commons in a huge number of articles and categories, spoiled their interface. So of course I vote for keeping. But for me it's very strange to be the first editor of Russian Wikipedia who leaving comment here during such big period of time of the discussion. According to the header on the page: "Validate the property isn't being used in other projects and if it is, leave a message in Village pump of the project.". Can I watch a link on sush message to Village pump in Russian Wikipedia? I want to be sure all involved users in Russian Wikipedia could got such message. --Ksc~ruwiki (talk) 20:23, 5 February 2019 (UTC)
- Comment, it's by a very far margin the worst issue on WikiData, the perfectly unconvincing redundancy of a "commonscat" in "other sites" or in this property from hell. Whatever you decide, it MUST be prepared by a bot moving any "commonscat" in "other sites" to populate the property (if it's kept), or vice versa (if the property is deleted), resolving conflicts with Commons galleries in "other sites" on the fly, i.e., move any "commons gallery" in "other sites" to its property first, if this property is deleted. And please close this RfC if you (= the next user reading this) are logged in, the rough consensus appears to be rather obvious, no admin required. –84.46.53.251 13:29, 17 February 2019 (UTC)
- This section was archived on a request by: --Pasleim (talk) 09:23, 1 March 2019 (UTC)
- 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 --Pasleim (talk) 09:27, 1 March 2019 (UTC)
P1773 (P1773): (delete | history | links | entity usage | logs)
Apparently this shouldn't be used per Wikidata:WikiProject Visual arts/Item structure#Use of creator (P170) in uncertain cases. So we might as well delete it. --- Jura 14:46, 5 November 2018 (UTC)
- Delete, but deletion is the easiest part, migration has to be done first. --Marsupium (talk) 17:25, 7 November 2018 (UTC)
- Are we sure no other domains are using it besides art? I would like to first complete the migration to the new model. I don't think that can be done fully automatic because it needs a bit of checking and sourcing. When the property is no longer in use it can probably be deleted. Multichill (talk) 12:35, 10 November 2018 (UTC)
- @Trivialist: This guy usually use this, let's ask him? --Liuxinyu970226 (talk) 15:09, 20 November 2018 (UTC)
- I don't think I've used it on much more than Wilhelm scream (Q1141711), which isn't an artwork anyway. Trivialist (talk) 17:00, 20 November 2018 (UTC)
- Keep I think it is very important! I use it frequently for literary works - literary work (Q7725634). It is necessary for many ancient & medieval works. I even built a template in Hebrew Wikisource that uses it. שילוני (talk) 22:07, 22 November 2018 (UTC)
- Keep but add a constraint to written works. Standards for visual and written works are different here. Circeus (talk) 03:27, 23 December 2018 (UTC)
- Keep I think this a great property to use for both visual and literary works, especially when dealing with ancient, medieval, and early modern stuff. --Sp!ros (talk) 20:19, 28 January 2019 (UTC)
- This section was archived on a request by: --Pasleim (talk) 09:27, 1 March 2019 (UTC)
- 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 --Pasleim (talk) 09:28, 1 March 2019 (UTC)
participant in (P1344): (delete | history | links | entity usage | logs | discussion)
Is an inverse statement really necessary? It seems to contain a lot of duplicate data. Alternatively, participant (P710) should be removed. —U+1F360 (talk) 16:42, 10 November 2018 (UTC)
- There may be situations where one or the other is useful as a qualifier. I agree that it's an unfortunate duplication when they are used directly in statements and are redundant inverses. Perhaps participant (P710) could be marked for use in qualifiers only. Ghouston (talk) 00:50, 11 November 2018 (UTC)
- Clear Keep. This property is predominantly used as main value in the field of sportspersons. For sportpersons, this property including its qualifiers is the place to look at when filling an infobox with their participations/successes in Wikipedia. It would be very difficult to retrieve all this information from somewhere else, as we cannot use queries while building infoboxes; the same more or less holds for the inverse participant (P710) (and participating team (P1923)). —MisterSynergy (talk) 07:05, 11 November 2018 (UTC)
- The inverse thing is unfortunate. When querying data, you'd actually need to run the query in both directions and merge the results, since the inverses are often missing. Some properties, like employer (P108), exist without inverses, and isn't participant in (P1344) similar to that? Ghouston (talk) 22:07, 12 November 2018 (UTC)
- I don’t care about the inverse character of the property, I just want to have this property kept for use in infoboxes. Together with participating team (P1923) and participant (P710) it forms kind of a triangle which can’t fully inverse all statements anyway. —MisterSynergy (talk) 12:28, 13 November 2018 (UTC)
- @MisterSynergy: When you said "as we cannot use queries while building infoboxes", do you include lua infoboxes or your remark is just concerning wiki infoboxes using some lua subtemplates to retrieve values from WD. Snipre (talk) 17:15, 7 February 2019 (UTC)
- Not sure what you are exactly asking about. The exact infobox technique does not really matter, I just want to ensure that something like the medal record in the infobox in en:Kim Brennan is easily doable with data from Wikidata. It would be the easiest to have this data in the corresponding item Kim Brennan (Q576663), which somehow needs to link to the event and provide a ranking. The native approach is to have claims such as this one: ⟨ Kim Brennan (Q576663) ⟩ participant in (P1344) ⟨ rowing at the 2016 Summer Olympics – women's single sculls (Q22968973) ⟩
ranking (P1352) ⟨ 1 ⟩
country for sport (P1532) ⟨ Australia (Q408) ⟩
We thus need participant in (P1344) here. The deletion proposal suggests that de-duplication would be desirable, which means that this information could only be found in rowing at the 2016 Summer Olympics – women's single sculls (Q22968973) with the inverse participant (P710). It would be difficult to read it from there in the context of infoboxes using Lua. It is easy to read it with SPARQL, of course, but we do not have access to the SPARQL endpoint from Lua or basic template commands. —MisterSynergy (talk) 18:38, 7 February 2019 (UTC)
- Not sure what you are exactly asking about. The exact infobox technique does not really matter, I just want to ensure that something like the medal record in the infobox in en:Kim Brennan is easily doable with data from Wikidata. It would be the easiest to have this data in the corresponding item Kim Brennan (Q576663), which somehow needs to link to the event and provide a ranking. The native approach is to have claims such as this one:
- @MisterSynergy: When you said "as we cannot use queries while building infoboxes", do you include lua infoboxes or your remark is just concerning wiki infoboxes using some lua subtemplates to retrieve values from WD. Snipre (talk) 17:15, 7 February 2019 (UTC)
- I don’t care about the inverse character of the property, I just want to have this property kept for use in infoboxes. Together with participating team (P1923) and participant (P710) it forms kind of a triangle which can’t fully inverse all statements anyway. —MisterSynergy (talk) 12:28, 13 November 2018 (UTC)
- The inverse thing is unfortunate. When querying data, you'd actually need to run the query in both directions and merge the results, since the inverses are often missing. Some properties, like employer (P108), exist without inverses, and isn't participant in (P1344) similar to that? Ghouston (talk) 22:07, 12 November 2018 (UTC)
- Abstain: I'd favour not storing inverse data, in general, but we need a project-wide policy on when and when not to do so, rather than case-by-case deletion proposals. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:22, 13 November 2018 (UTC)
- Comment: I've just replaced P1441 by P1344. Nothing is wrong with P1344,
sadly bots can't decide which "inverse of P710 or P1923" has to be used if it is missingeven bots can figure out human vs. team. –84.46.52.183 01:37, 30 December 2018 (UTC) (updated inspired by a Project chat. –84.46.52.107 01:07, 4 January 2019 (UTC)) - Keep both. One serves infoboxes about people; the other serves infoboxes about events. While these properties are inverses of each other in terms of truth value, the two statements may have different ranks (e.g. a competition is important to a particular player, but the player isn't super-important for that competition). Deryck Chan (talk) 15:54, 11 January 2019 (UTC)
- This section was archived on a request by: --Pasleim (talk) 09:28, 1 March 2019 (UTC)
- 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 support for deletion --Pasleim (talk) 09:31, 1 March 2019 (UTC)
NSZL name authority ID (P3133): (delete | history | links | entity usage | logs | discussion)
The Hungarian Szechenyi Könyvtár has the maintenance this database closed. You find no any data on this links not now and not in the future. —Texaner (talk) 08:59, 13 November 2018 (UTC)
- The data is still available via the Wayback Machine (example) and so I have updated the formatter URL accordingly; but for just 36 IDs, it is probably not worth keeping. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:20, 13 November 2018 (UTC)
- Hi, I have checked after you changes the Wayback Machine, but there also no any links. This seems to be a really dead thing. Texaner (talk) 15:50, 13 November 2018 (UTC)
- VIAF has these IDs stored (HuBpOSK), so we can still potentially add these IDs and use the Wayback link. – Máté (talk) 12:38, 13 November 2018 (UTC)
- This section was archived on a request by: --Pasleim (talk) 09:31, 1 March 2019 (UTC)
- 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 for deletion. Multichill (talk) 12:47, 16 February 2019 (UTC)
charter URL (P6378): (delete | history | links | entity usage | logs | discussion)
Duplicates with foundational text (P457)/main regulatory text (P92) and full work available at URL (P953) - just create items for individual charters. —GZWDer (talk) 19:06, 19 January 2019 (UTC)
- @Nomen ad hoc, Adelsheim, Pintoch, ديفيد عادل وهبة خليل 2, Jklamo, PKM:, @Vladimir Alexiev, Thierry Caro:--GZWDer (talk) 19:12, 19 January 2019 (UTC)
- Keep. I'm fine with it. Thierry Caro (talk) 19:31, 19 January 2019 (UTC)
- Keep I don’t see a lot of value in creating bunches of items for organizational charters which aren’t all that significant in themselves, although if such items exist GZWDer's solution seems appropriate in those (rare?) cases. - PKM (talk) 19:55, 19 January 2019 (UTC)
- For consistency we should create items for individual charters; they clearly constitutes a structural need and we may expect finding charter URLs by a single way. Also, having such items allow us to add more information to these charters (at least language of work or name (P407)).--GZWDer (talk) 20:10, 19 January 2019 (UTC)
- Keep GZWDer's solution is surely appropriate for the cases where the documents are notable by themselves, but I do not think this is the case for the many minor companies that we describe. I don't see an advantage in giving these charters dedicated items, so there is no structural need as far as I can tell. − Pintoch (talk) 23:28, 19 January 2019 (UTC)
- Alternatively, you can add full work available at URL (P953) as qualifier.--GZWDer (talk) 03:52, 20 January 2019 (UTC)
- Keep Completely different from the rest David (talk) 06:52, 20 January 2019 (UTC)
- Keep full work available at URL (P953) can sometimes violate privacy But this won't. --125.38.13.238 01:00, 21 January 2019 (UTC)
- @125.38.13.238: Please explain.--GZWDer (talk) 21:09, 21 January 2019 (UTC)
- Keep Per above, there are concerns to these so-called replacements. --218.68.229.42 02:14, 2 February 2019 (UTC)
- @Deryck Chan, Renamerr, Bjankuloski06, Romaine, Davidpar:@Manu1400, Meno25, Liuxinyu970226, J. N. Squire, Arnaugir: who edited charter URL (P6378) please comment here. --218.68.229.42 02:17, 2 February 2019 (UTC)
- I don't think I have been involved with this property before? Anyway I've reviewed the discussion above and I'm Neutral. It seems that this property isn't an exact duplicate of something another property can do, but we can emigrate all existing uses by creating new items. Deryck Chan (talk) 10:19, 2 February 2019 (UTC)
- @Deryck Chan, Renamerr, Bjankuloski06, Romaine, Davidpar:@Manu1400, Meno25, Liuxinyu970226, J. N. Squire, Arnaugir: who edited charter URL (P6378) please comment here. --218.68.229.42 02:17, 2 February 2019 (UTC)
- Keep Per above, there are reasons that GZWDer's solutions are not accounted. --Liuxinyu970226 (talk) 14:07, 6 February 2019 (UTC)
- This section was archived on a request by: --Pasleim (talk) 09:38, 1 March 2019 (UTC)
- 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 the property. − Pintoch (talk) 16:55, 2 April 2019 (UTC)
X username (P2002): (delete | history | links | entity usage | logs | discussion)
Superseded by the X numeric user ID (P6552), which is more stable. NMaia (talk) 03:18, 2 March 2019 (UTC)
- Is there a way to link full Twitter profiles from this new property, rather than such short profiles? —MisterSynergy (talk) 07:22, 2 March 2019 (UTC)
- After some searching online, it looks like there isn't another way to link to a full Twitter profile with only the numeric identifier. Robin van der Vliet (talk) (contribs) 14:23, 2 March 2019 (UTC)
- @MisterSynergy: We can perhaps use https://tools.wmflabs.org/wikidata-externalid-url/ to redirect it to the userpage. Every user ID page links directly to the profile page. NMaia (talk) 02:11, 4 March 2019 (UTC)
- Not sure whether this is possible. The ID needs to be resolved to the username, which is probably only possible with a request to Twitter's API, right? —MisterSynergy (talk) 06:00, 4 March 2019 (UTC)
- Keep even where the underlying ID remains consistent it can be very useful to know what different usernames people have actively used (e.g. in the UK, many politicians change their twitter name during election campaigns).
- Keep This is independent and useful information, though it may not strictly qualify as an external id any more (user names can be reused right?). On linking via wikidata-externalid-url - that's not really within the scope of the app which was designed for just simple string re-writing; however I could look into it if this property is deleted and there's a strong demand for this. ArthurPSmith (talk) 14:48, 4 March 2019 (UTC)
- That would be really useful, I think. There's a ticket for it here. NMaia (talk) 22:28, 4 March 2019 (UTC)
- Keep There nothing to be gained from deletion of this property, which is widely used both on and outside Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:49, 4 March 2019 (UTC)
- Keep Why not re-purpose it to function as a qualifier to X numeric user ID (P6552), when that is more widely adopted? There is some value (at least in theory) in keeping historical usernames i would imagine. Moebeus (talk) 15:02, 5 March 2019 (UTC)
- A qualifier property already exists for that, website username or ID (P554). Ghouston (talk) 22:31, 13 March 2019 (UTC)
- Keep Useful property no need to delete Progressjude (talk)
- 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. I misunderstood this as duplicating image (P18) and depicts (P180), but it's actually related to copyright status (P6216) and the copyright issues around the Commons media files. As such, I withdraw the request. Thanks. Mike Peel (talk) 21:05, 29 March 2019 (UTC)
digital representation of (P6243): (delete | history | links | entity usage | logs | discussion)
This property is completely redundant to image (P18). —Mike Peel (talk) 23:54, 21 March 2019 (UTC) Or depicts (P180). Pinging the participants of the property proposal: @Jarekt, ArthurPSmith, Multichill, Jheald, Jura1: Thanks. Mike Peel (talk) 20:54, 27 March 2019 (UTC)
- I disagree. This is the "isA" predicate for 2D reproductions. P18 is the "illustrates" predicate. James F. (talk) 00:10, 22 March 2019 (UTC)
- @Jdforrester: I don't understand, can you explain "isA" and "predicate", please? Thanks. Mike Peel (talk) 00:40, 22 March 2019 (UTC)
- @Mike Peel: Sure.
- "Predicate" is the generic formal logic term for what we on Wikidata achieve through properties and their qualifiers. The enwiki article w:en:First-order logic is a not-great introduction; there's much more at [22] but don't read that unless you're intensely curious. :-)
- "isA" is the identity predicate, an identifies the thing you're talking about, and is the most fundamental predicate. It is represented on Wikidata as instance of (P31).
- In the specifics of P6243 vs. P31 vs. P180 vs. P18:
- * faithful "perfect" reproductions like this one would be digital representation of (P6243) to Mona Lisa (Q12418), the conceptual painting itself, and depicts (P180) to person depicted in Mona Lisa (Q11879536);
- * pictures including it like this one are merely a depicts (P180) to Mona Lisa (Q12418) (with qualifiers of location (P276) to Louvre Museum (Q19675) and whatever), and e.g. depicts (P180) to Louvre Museum (Q19675) too; and finally
- * pictures demonstrating e.g. how popular it is, like this one, might well be tagged image (P18), and depicts (P180) to tourist (Q5633897).
- Real-world 3D items, like individuals or sculptures or cities, could never have a P6243 faithful reproduction, but are very likely to have illustrative items. Conceptual items, like democracy, can also have illustrations, but arguably we should have a different predicate for those.
- In terms of use and quality restrictions, a media item would have one or zero P6243s (if you have two or more, then you're not faithfully reproducing them, you're just a P180 of them); conversely, it might have multiple P180s. An item would link to a media item via P18 for an example illustration, or a different property for "is faithfully depicted by", which we currently lack. A single item might have multiple incoming P6243s (e.g. before and after some restoration, or re-balanced colours, or whatever) – probably we'd want to tag all the files on C:Artwork:Mona Lisa as P6243s of Q12418.
- Hope this clarifies my comment! James F. (talk) 01:56, 22 March 2019 (UTC)
- @Jdforrester: I don't understand, can you explain "isA" and "predicate", please? Thanks. Mike Peel (talk) 00:40, 22 March 2019 (UTC)
- Good explanation, thanks. Emijrp (talk) 14:48, 22 March 2019 (UTC)
- @Jdforrester: I think I should have said that it duplicates depicts (P180) rather than image (P18). Ideally that property would be used on Commons to point to the Wikidata item depicted in the image, and then depicts (P180) in the Wikidata item can be used to describe what the item depicts if that's appropriate, using preferred ranks if needed. Otherwise things get way too complicated, with too much data being stored on Commons rather than on Wikidata (which isn't scalable). Thanks. Mike Peel (talk) 20:53, 27 March 2019 (UTC)
- @Mike Peel: I understand, however my (second, expanded) comment explicitly details why depicts (P180) is the wrong property to use for that situation. James F. (talk) 02:56, 28 March 2019 (UTC)
- Delete I think that it can be indicated some how like ⟨ Mona Lisa (Q12418) ⟩ image (P18) ⟨ File:Mona Lisa, by Leonardo da Vinci, from C2RMF retouched.jpg ⟩, I'm not convinced that we need separate property (and fill it in millions of painting items).--Jklamo (talk) 09:26, 27 March 2019 (UTC)
depicts (P180) ⟨ digital representation (Q42396623) ⟩- @Jklamo: I think you have misunderstood the property and what it is for. It's not primarily for use on Wikidata, it's primarily for use on the Commons wikibase.
- Suppose we have 500 images of the Mona Lisa on Commons. We don't want to have 500 values of image (P18) on Mona Lisa (Q12418). On Wikidata we just want a single value of image (P18) to indicate one regular image on the item.
- But on Commons, we do want to be able to say in Structured Data what each of those 500 images represents. We could use depicts (P180) Mona Lisa (Q12418). But it may be useful to have a special property to indicate the case that the image-file is specifically a faithful representation of the painting -- it shows no more, no less; that is its distinctive purpose. That is the use that digital representation of (P6243) is proposed for, per Jdforrester above. The purpose of this discussion is to indicate whether this is useful, over just P180.
- As for "fill it in for millions of painting items" -- that is the point of Structured Data for Commons: to be able to record key information for each of those images in wikibase statement form, in the Commons wikibase. Jheald (talk) 21:13, 27 March 2019 (UTC)
WikiProject sum of all paintings has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.--Jklamo (talk) 09:29, 27 March 2019 (UTC)
- Keep no, it's not complete redundant to image, it's needed for structured data on Commons, see the talk page. This is the structured data equivalent of PD-Art template. Multichill (talk) 21:03, 27 March 2019 (UTC)
- @Multichill: So it's completely redundant to depicts (P180)? Thanks. Mike Peel (talk) 21:06, 27 March 2019 (UTC)
- No it's not. Multichill (talk) 21:10, 27 March 2019 (UTC)
- @Multichill: It seems to be. I've replied on Commons to try to explain why. Did I miss a conversation on Commons about whether this property should be created in the first place? Thanks. Mike Peel (talk) 21:12, 27 March 2019 (UTC)
- No it's not. Multichill (talk) 21:10, 27 March 2019 (UTC)
- @Multichill: So it's completely redundant to depicts (P180)? Thanks. Mike Peel (talk) 21:06, 27 March 2019 (UTC)
- Keep As I understand it, this property is necessary to talk about copyright of things like paintings and prints versus things like 3-D sculpture. The digital representation of a thing can have many different states of being. This is not true for things depicted - they are just one thing. Jane023 (talk) 21:48, 27 March 2019 (UTC)
- @Jane023: That doesn't match up with my understanding - just say depicts (P180)=Mona Lisa (Q12418), and you can fetch the relevant copyright information if you want. Thanks. Mike Peel (talk) 21:53, 27 March 2019 (UTC)
- No that is not the same thing. The Mona Lisa is one specific thing, but a plate in a book can have a different copyright due to publication jurisdiction. Something can be somewhere in space and time, and something else is an illustration of it, and that illustration can have multiple forms. So this is a one-to-many concept whereas the depicts/depicted relationship is 1-1. Jane023 (talk) 22:31, 27 March 2019 (UTC)
- @Jane023: I still don't understand, sorry. In that case, doesn't that either fall under commons:Commons:Reuse of PD-Art photographs, or we'd have a separate Wikidata entry that we could link to using depicts (P180)? What do we gain in that situation that this property can cover, but depicts (P180) can't? Thanks. Mike Peel (talk) 22:40, 27 March 2019 (UTC)
- There is a difference between what you are talking about in Commons terms vs Wikidata terms. So the usage of depicts is for wikidata, and this is for Commons. Jane023 (talk) 22:47, 27 March 2019 (UTC)
- @Jane023: There is a bit of a difference, but I think it's two ways to use the same property in different contexts, rather than requiring a different property. Perhaps commons:File:Lovell Telescope 5.jpg might be a useful example here - that would be depicts (P180)=Lovell Telescope (Q555130), but the way we record that on Commons should be no different from how we record the info about an image depicting an artwork (even if you want to cover brush strokes, that's then heading towards 3D model (P4896)). Thanks. Mike Peel (talk)`
- No one picture can show the telescope before storm damage or something. You need to be able to address the various different types of illustrations. They are not equivalent. Jane023 (talk) 23:17, 27 March 2019 (UTC)
- @Jane023: There is a bit of a difference, but I think it's two ways to use the same property in different contexts, rather than requiring a different property. Perhaps commons:File:Lovell Telescope 5.jpg might be a useful example here - that would be depicts (P180)=Lovell Telescope (Q555130), but the way we record that on Commons should be no different from how we record the info about an image depicting an artwork (even if you want to cover brush strokes, that's then heading towards 3D model (P4896)). Thanks. Mike Peel (talk)`
- There is a difference between what you are talking about in Commons terms vs Wikidata terms. So the usage of depicts is for wikidata, and this is for Commons. Jane023 (talk) 22:47, 27 March 2019 (UTC)
- @Jane023: I still don't understand, sorry. In that case, doesn't that either fall under commons:Commons:Reuse of PD-Art photographs, or we'd have a separate Wikidata entry that we could link to using depicts (P180)? What do we gain in that situation that this property can cover, but depicts (P180) can't? Thanks. Mike Peel (talk) 22:40, 27 March 2019 (UTC)
- No that is not the same thing. The Mona Lisa is one specific thing, but a plate in a book can have a different copyright due to publication jurisdiction. Something can be somewhere in space and time, and something else is an illustration of it, and that illustration can have multiple forms. So this is a one-to-many concept whereas the depicts/depicted relationship is 1-1. Jane023 (talk) 22:31, 27 March 2019 (UTC)
- Keep I also find it confusing but I think that P6243 is a subset of image (P18) and depicts (P180), so every P6243 can be also P18 or P180 but most of those would not be P6243. --Jarekt (talk) 01:09, 28 March 2019 (UTC)
- Keep Definitely a distinct concept, this is for structured data on Commons, and to the degree they overlap, it would be the *inverse* of image (P18). Did the proposer read the proposal discussion before nominating for deletion here? ArthurPSmith (talk) 11:31, 29 March 2019 (UTC)
- @ArthurPSmith: If used on Wikidata, I thought it would duplicate image (P18). Used on Commons, however, it duplicates depicts (P180). Thanks. Mike Peel (talk) 15:46, 29 March 2019 (UTC)
- 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.
- Since the property now works, the deletion rationale is invalid. Withdrawing. Jc86035 (talk) 10:48, 9 April 2019 (UTC)
P6623 (P6623): (delete | history | links | entity usage | logs)
Gamepedia cannot handle interwiki links properly. www.gamepedia.com is not run on MediaWiki, and all of the Gamepedia wikis have outdated or incomplete interwiki tables; the one at help.gamepedia.com seems to be the most complete, but cannot link to specific pages on most Gamepedia wikis (although it can link to the home pages of all Gamepedia wikis). This is somewhat reasonable, since most of the wikis have unrelated content (and there are a lot of Gamepedia wikis), but this means that there is no formatter URL that works for Wikidata.
If there is no fix, then the property would have to be deleted due to a lack of a functioning formatter URL. I have submitted a ticket to gamepedia.zendesk.com; if Gamepedia refuse to fix the interwiki maps then the remaining options are implementing custom redirection through toollabs:wikidata-externalid-url and deleting the property. Jc86035 (talk) 12:26, 1 April 2019 (UTC)
- I totally agree to Delete, if none of the above options work out. --Kristbaum (talk) 17:37, 1 April 2019 (UTC)
- « implementing custom redirection through toollabs:wikidata-externalid-url and deleting the property. » I don’t understand: if we implement a custom redirection though wikidata-externalid-url (which we should), then surely we should keep this property no ? Jean-Fred (talk) 15:27, 2 April 2019 (UTC)
- @Jean-Frédéric: Yes, it would be preferable to keep the property. The primary purpose of creating the deletion discussion (I think...) was to centralize discussion and verify that there were no better solutions. I believe it is possible, so I have created an issue in the GitHub repository suggesting a fix (notifying ArthurPSmith). Jc86035 (talk) 12:21, 4 April 2019 (UTC)
- Ok, we are in agreement then :-). Submitted a pull-request. Jean-Fred (talk) 12:41, 4 April 2019 (UTC)
- Fix is implemented and this should be working now! ArthurPSmith (talk) 15:24, 4 April 2019 (UTC)
- Keep if that wasn't clear... ArthurPSmith (talk) 18:14, 5 April 2019 (UTC)
- Ok, we are in agreement then :-). Submitted a pull-request. Jean-Fred (talk) 12:41, 4 April 2019 (UTC)
- @Jean-Frédéric: Yes, it would be preferable to keep the property. The primary purpose of creating the deletion discussion (I think...) was to centralize discussion and verify that there were no better solutions. I believe it is possible, so I have created an issue in the GitHub repository suggesting a fix (notifying ArthurPSmith). Jc86035 (talk) 12:21, 4 April 2019 (UTC)
- 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 I don't see consensus for deletion. Multichill (talk) 20:31, 27 May 2019 (UTC)
translation (P5972): (delete | history | links | entity usage | logs | discussion)
@Tubezlob, Denny, Micru, Infovarius, Runner1928, Duesentrieb: @Sintakso, Jura1, Deryck Chan, Mfilot, TomT0m, ArthurPSmith:@Njardarlogar, Liamjamesperritt, fnielsen, Jc86035, Rua:
translation (P5972) requires every sense to be linked to every other sense with the same meaning. It scales very badly and it's difficult to maintain. Using item for this sense (P5137) is better because every sense needs only a link to the Q-item that represents its meaning.
The two objections to this approach are:
- it will create items whose meanings are only slightly different because some senses differ only in nuances;
- it will create items for verbs, adverbs, prepositions and adjectives.
IMO, the latter is not a problem because we already have adjectives (Orwellian (Q2156379)) and verbs (google (Q1156923). As regards prepositions, they are very few.
Previous similar discussions:
--Malore (talk) 05:04, 14 December 2018 (UTC)
- I think the explanation by @Denny: at Property_talk:P5972#Translation_as_property_and_query makes sense. I don't see an advantage to start creating even more items for words than we already have. --- Jura 05:08, 14 December 2018 (UTC)
- I agree that if translation (P5972) is used extensively, it will become unruly. I personally agree that creating Q-Items for Nouns, Verbs, Adjectives and Adverbs and linking those senses using item for this sense (P5137) is a good idea, as those categories clearly represent conceptual entities. However, I think that more functional lexical categories (such as prepositions, conjuctions, affixes, particles, articles etc.) should be kept out of the Q namespace, and translation (P5972) should still be used for those. Liamjamesperritt (talk) 05:21, 14 December 2018 (UTC)
- @Liamjamesperritt, ArthurPSmith: I see your point. What about limiting the scope of translation (P5972) to function words and rename it to something like "functional equivalence"?--Malore (talk) 19:38, 15 December 2018 (UTC)
- Before we can limit its scope, the community still needs to decide whether adding thousands of Senses to the Main namespace is a good idea. I believe it is an important direction to move towards, but there is yet to be any consensus on the issue. Liamjamesperritt (talk) 21:16, 15 December 2018 (UTC)
Weak oppose. I agree with Jura and Denny here. Translations aren't necessarily symmetric so linking to an item doesn't automatically solve all our problems. I see this as the centralized equivalent of the translation table on Wiktionary. Storing these in the Sense entry may make it unwieldy in Wikidata view, but seems to be what Wiktionary requires. Deryck Chan (talk) 10:31, 14 December 2018 (UTC)- It’s not necessarily an easy task, but the fact that translations differs just a little bit is also an opportunity to describe the relationship between them by statements. author TomT0m / talk page 10:37, 14 December 2018 (UTC)
- @Deryck Chan: To me it seems unnecessary to think of this in terms of translation. I think sense entities (i.e. items in the existing main namespace or in a dedicated sense namespace) can handle this perfectly if we leave minimal room for ambiguity. That is, if two languages have slightly different concepts for the colour blue, we create two separate sense entities for these two concepts and mark one as a subset of the other, or both as overlapping - whichever is correct.
- An important property of this implementation is that it is up to the user that queries for translations what counts as a "translation": should the translated word be a virtually exact match (i.e. uses the same sense entity), could the word have a broader or narrower meaning, and could it have an overlapping meaning? --Njardarlogar (talk) 11:53, 14 December 2018 (UTC)
- @Jura1, Denny, Deryck Chan: The current description says
word in another language that corresponds exactly to this meaning of the lexeme
. "corresponds exactly" suggests that the property is symmetrical.--Malore (talk) 17:48, 14 December 2018 (UTC)- Change to Neutral. It seems that this property is (badly) trying to solve a different problem as what I expect it to solve. Maybe we need to wait till Wiktionary can transclude Lexemes and then figure this out. Deryck Chan (talk) 22:41, 14 December 2018 (UTC)
- It’s not necessarily an easy task, but the fact that translations differs just a little bit is also an opportunity to describe the relationship between them by statements. author TomT0m / talk page 10:37, 14 December 2018 (UTC)
- My view is - I think we need translation (P5972) for now, but it should be reserved for cases that can't obviously be handled by item for this sense (P5137), and we should be actively figuring out how to migrate all uses of the first property to the second in some manner... ArthurPSmith (talk) 13:52, 14 December 2018 (UTC)
- Oppose I think in current shape of lexemes we need it, but use it only where item for this sense (P5137) does not work. KaMan (talk) 16:07, 16 December 2018 (UTC)
- I (also) think that we should use item for this sense (P5137), but fall back on translation (P5972). — Finn Årup Nielsen (fnielsen) (talk) 00:40, 31 January 2019 (UTC)
- Oppose per KaMan. ChristianKl ❪✉❫ 16:13, 12 February 2019 (UTC)
- temporary keep until we have a sane system to query Lexemes locally. --Liuxinyu970226 (talk) 12:46, 16 March 2019 (UTC)
female form of label (P2521)
- 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 for deletion and no alternative available yet. Multichill (talk) 20:40, 27 May 2019 (UTC))
female form of label (P2521): (delete | history | links | entity usage | logs | discussion)
Given that we now have Lexemes, there's no good reason to store this information in the item namespace ChristianKl ❪✉❫ 12:59, 14 January 2019 (UTC)
- Oppose Until an alternative is proposed (which should be a requirement when proposing a deletion). As far as I know, this property is currently being used at least in the French Wikipedia, so it would be a good idea to start with understanding the rational of the property creation. Going in that direction, maybe @Jura1: could elaborate on that in order to move forward. Andreasm háblame / just talk to me 13:58, 15 January 2019 (UTC)
- Delete The frwiki usage should be modified, they should query Lexemes. --2409:8902:9301:B6A9:5CB3:E6FD:4195:E1F7 04:48, 16 January 2019 (UTC)
- Oppose Eventually maybe but there's no replacement now. Data access to lexemes is not possible yet. The same applies to demonym (P1549). Matěj Suchánek (talk) 08:41, 16 January 2019 (UTC)
- Delete but On hold until the access to Lexemes is ready. Cheers, VIGNERON (talk) 11:59, 21 January 2019 (UTC)
{{o}} for now per Andreasmperu and Matěj Suchánek.(vote withdrawn given alternatives below) --Marsupium (talk) 01:58, 22 January 2019 (UTC), 10:47, 25 March 2019 (UTC)- There is also male form of label (P3321). Somehow lexeme contributors haven't found a way yet to link them in a structured way. --- Jura 13:00, 26 January 2019 (UTC)
- On hold until we migrate all the data to Lexemes and transfer existing external uses to Lexemes, then Support deprecation. Deryck Chan (talk) 19:38, 26 January 2019 (UTC)
- Keep Used extensively also in Catalan Wikipedia for infoboxes deppending on sex or gender (P21). I.e. Nicole Kidman is an actress, not an actor, and this is basic for languages with gender flexion. Previously, you need to have access to Lexemes and move all data. --Vriullop (talk) 08:03, 29 January 2019 (UTC)
- note @ChristianKl: I've mentioned this discussion in phab:T212843 as an urgent case of making Lexeme data accessible by other WMF wikis. Please head over there to discuss how Lexeme access should be implemented. Deryck Chan (talk) 14:05, 1 February 2019 (UTC)
- Keep Until now I saw no technical support on querying Lexemes, and even one day available, this property should also be used elsewhere if one wiki can't support it due to Parsoid problems. --218.68.229.42 02:12, 2 February 2019 (UTC)
- Keep this is a very useful and important property for my native Polish and I don't think there is a good alternative in place at the moment Powerek38 (talk) 21:28, 24 February 2019 (UTC)
- On hold until all data is migrated to lexemes and actually used on all Wikipedias. Robin van der Vliet (talk) (contribs) 14:00, 2 March 2019 (UTC)
- Keep I agree with the comments above about the lack of availability regarding lexemas. Besides, this a useful property for Galician language, as it let us distinguish between sexes in the infoboxes.Maria zaos (talk) 16:07, 6 March 2019 (UTC)
- Keep; It's often used in gl.wiki. --Estevoaei (talk) 21:53, 24 March 2019 (UTC)
- Keep The property is being used in a large number of articles, it can not be eliminated until the templates that use it are modified. Bye, --Elisardojm (talk) 23:00, 24 March 2019 (UTC)
- Delete
- (1) This property needlessly inscribes a specific gender model into the (relatively upper) ontology, which
- (a) raises point-of-view concerns and
- (b) introduces an imbalance (e.g., in terms of modeling permissions) between concepts’ genders (values of properties) as items and labels’ genders as implicit in this and other properties, allowing editors to create and use new gender items (e.g., non-binary (Q48270)), but not the label forms associated with such genders.
- (2) To the extent that gender (‘real-world’ gender, not grammatical gender; sexus, notgenus, in somewhat dated-seeming linguistic terms) is, or should be, linguistically marked, the imbalance in occurrences of the properties female form of label (P2521) and male form of label (P3321), respectively, suggests that the conceptualization of these properties or the structures built around them (e.g., infobox-generating code on Wikipedias) at best only leads to a reinforcement of questionable views of male gender being the default, female gender being an aberration in supposed need of explicit mention (and other genders supposedly being a phenomenon below the bar of notability or acceptability). Such views not being universally accepted raises doubts as to whether the current property model behooves a universal ontology.
- Conclusion: This property (along with male form of label (P3321)) should be deleted and could, while a lexeme-based solution is not yet within reach, be replaced by a new property “gendered form of label” (or perhaps, more generally, “qualified label”), using qualifiers referring to gender items (rather than property-implicit senses of gender). See below for what this might look like this when used for actor (Q33999) as an example.
- However, note external use.
- ―BlaueBlüte (talk) 05:56, 11 March 2019 (UTC)
- (1) This property needlessly inscribes a specific gender model into the (relatively upper) ontology, which
- Keep This property is largely used in cawiki infoboxex. Until lexemes were well upload and access to lexemes being available from LUA module, it can not be delete. It's curious to observe that the hardest positions in favor to delete it comes from people with a short number of editions. Amadalvarez (talk) 09:39, 25 March 2019 (UTC)
- Keep Same. --Davidpar (talk) 20:51, 25 March 2019 (UTC)
- Wait for Lexemes to mature, then Delete. NMaia (talk) 04:58, 31 March 2019 (UTC)
- Keep This is an excellent solution which is understood by all and has been put to good use. It works, allowing infoboxes to be flexible and relevant. --FocalPoint (talk) 09:29, 26 April 2019 (UTC)
- Keep for now used in several wikipedias. Long term, who knows. Not there yet. With regard to "gendered form of label"-proposal ...feel everyone free to propose that one. Only after getting created that property and copying the data from P2521&P3321 to that new one... propose the deletion of these two. IMHO I don't see much improvement in lumping together "male", "female" and "non-binary" labels in every language ...in the same property. And, after all, if lexemes are gonna be the long-term solution Wikidata probably doesn't need another temporal "patch". strakhov (talk) 18:11, 5 May 2019 (UTC)
- Keep : the human gender identity binary division is another problem. Here we just need to say how we deignate a grammatical gender (which is language specific and does not necessarily match the male/female genetic classification even if it also has exceptions in many species, unrelated to the human gender identity which is a sociologic problem). We still need to refer to groups that in some languages may be considered distinct, but not in others (notably for activities or nobility titles). At least these languages (not all) create a binary division and it is common. Note that this also applies to biological species : they may have a single unified gender (masculine or feminine or neutral) independantly of the fact individuals are male or female (e.g. in French : "une fouine" is feminine for both males and females, and "un serpent" is masculine for both males and females; other species have dictinct names, "une truie" if the female domestic pork, "un cochon" or "un porc" is the male domestic pork, but sometimes "porc" is used for any male or female individual ; most domestic animals have gender-based names, and the biological gender is also an important classification useful in agriculture because it is selective for the production).
- You may argue that "masculine"/"feminine" would go to the classification of lexems (instead of items) but this will only apply to the grammatical form of names (which is independant of the group classification of items which need to refer to social gender groups, or to biological genders for species). The grammatical genders of lexems will still very frequently not match the social or biological genders of classes of items, for which we need appropriate properties to create distinct classes of items, even their translated item label is identical in some language but not all; each item in Wikidata will refer to lexems only by language-specific pairing, there will be no 1-to-1 relation between items and lexems and in fact almost very item in Wikidata for classes will have multiple associated lexems with different grammatical properties. And even some instance items, like human individuals, will have multiple lexems to refer to them in the same specific language, including contextual grammatical forms (like genitives or abbreviated names, or different usage names: official, formal, civil, artist names, nicknames, surnames given by others, or names changed/augmented during their life becaue of mariages or given honor or change of nationality or residence, or variants used specifically only in specific regions or situations...). To make things even more complex, the grammatical gender may change depending if this is a different plural form (e.g. in French: "un amour" is grammatically masculine in singular independantly of the person gender, "des amours" is grammatically feminine in plural also independantly of the gender of persons even if they are only boys/men!)
- I say keep "masculine and feminine" (grammatically and socially for persons) as classes in Wikidata, but at least create another property or classes for male/female biological gender distinctions. And of course add separately the grammatical gender distinctions and forms in lexems. Verdy p (talk) 15:30, 14 May 2019 (UTC)
- Keep: useful. Nomen ad hoc (talk) 14:40, 21 May 2019 (UTC).
Proposed replacements
“gendered form of label”
This example (using item actor (Q33999)) would equally serve as an illustration of a possible “qualified label” property, which would comprise “gendered form of label” as a special case based on the qualifiers used.
gendered form of label |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
add value |
- @Andreasmperu, Matěj Suchánek, Marsupium, Vriullop, Powerek38:@Maria zaos, Jura1, Amire80, Nikerabbit, GerardM: do you all agree with the replacement here? Or you will still vote keep, regardless of it? --Liuxinyu970226 (talk) 11:49, 23 March 2019 (UTC)
- This proposal is interesting but I think this isn't suitable venue for discussing it. Wikidata:Project chat or Wikidata:Property proposal will definitely have greater attention. Matěj Suchánek (talk) 21:41, 24 March 2019 (UTC)
- Until this proposal (or another accepted alternative) were not totally deployed, the P2521 must be kept. Amadalvarez (talk) 09:39, 25 March 2019 (UTC)
- @Amadalvarez: male form of label (P3321) too? --Liuxinyu970226 (talk) 23:16, 26 March 2019 (UTC)
- @Liuxinyu970226: NO. We're not using P3321 in cawiki infoboxes. Thanks,Amadalvarez (talk) 05:15, 27 March 2019 (UTC)
- @Liuxinyu970226:I agree with Amadalvarez, so Keep P2125.--Maria zaos (talk) 20:29, 31 March 2019 (UTC)
- @Amadalvarez: male form of label (P3321) too? --Liuxinyu970226 (talk) 23:16, 26 March 2019 (UTC)
- Until this proposal (or another accepted alternative) were not totally deployed, the P2521 must be kept. Amadalvarez (talk) 09:39, 25 March 2019 (UTC)
- This proposal is interesting but I think this isn't suitable venue for discussing it. Wikidata:Project chat or Wikidata:Property proposal will definitely have greater attention. Matěj Suchánek (talk) 21:41, 24 March 2019 (UTC)
External use
This property is being used by: (list is incomplete) Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.) |
male form of label (P3321)
- 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 for deletion and no alternative available yet. Multichill (talk) 20:42, 27 May 2019 (UTC))
male form of label (P3321): (delete | history | links | entity usage | logs | discussion)
Per #Property:P2521 above, given that we now have Lexemes, we should also drop this property to just say "male form", but no other infos. --Liuxinyu970226 (talk) 15:06, 14 January 2019 (UTC)
- Keep Per above, there are usages elsewhere where really can't be replaced by Lexemes. --218.68.229.42 02:13, 2 February 2019 (UTC)
- Delete and replace with more general modeling. Discussion re female form of label (P2521) (above) applies analogously. ―BlaueBlüte (talk) 06:08, 11 March 2019 (UTC)
- Keep This is an excellent solution which is understood by all and has been put to good use. It works, allowing infoboxes to be flexible and relevant. --FocalPoint (talk) 09:30, 26 April 2019 (UTC)
- Keep I think it can be useful. DGtal (talk) 10:14, 13 May 2019 (UTC)
- 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 for deletion and no alternative available yet. No point of keeping this open as "on hold" for months. Once we have a good alternative up and we feel like this property is unneeded, it can be nominated for deletion again. Multichill (talk) 20:44, 27 May 2019 (UTC))
media legend (P2096): (delete | history | links | entity usage | logs | discussion)
This data should be moved to Commons since it supports Structured Data. Example: Douglas Adams (Q42) → image (P18) → commons:File:Douglas_adams_portrait_cropped.jpg —U+1F360 (talk) 05:47, 6 February 2019 (UTC)
- On hold This is similar to #P2521. It needs to wait until it's possible to fetch the data from Commons due its use in infoboxes. Matěj Suchánek (talk) 08:26, 6 February 2019 (UTC)
- Keep. You're too early. Come back here when you have a good alternative. Let's just close this one for now and don't leave it open for months. Multichill (talk) 12:41, 16 February 2019 (UTC)
- Damage report: Last (2nd) paragraph in Talk:Q2709#English description, –84.46.53.3 22:27, 23 February 2019 (UTC)
- Keep for now, at least; with no prejudice to renomination when circumstances change as Matěj explains. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:08, 4 March 2019 (UTC)
- Keep Depending on the context in which an image is shown it makes sense to have different media legends. ChristianKl ❪✉❫ 14:21, 8 March 2019 (UTC)
- On hold let's make sure this information is migrated to Commons first, then Delete. NMaia (talk) 05:02, 31 March 2019 (UTC)
- Keep. It's used by infoboxes on many Wikipedias. If we want to deprecate this, the following needs to happen:
- Make it feasible for Lua to transclude image captions on Commons.
- Copy all existing uses of this property to the caption fields in Commons.
- Migrate en:Module:Wikidata and all descendent modules from P2096 to Commons caption fields.
- Then remove all uses of this property and deprecate it.
- Deryck Chan (talk) 13:44, 7 April 2019 (UTC)
- On hold As many others said, I support deletion, but we do first many other things after remove the property. --Tinker Bell ★ ♥ 05:39, 15 April 2019 (UTC)
- Strongly Keep The same file can be used for many different purpose in different situation. The description on Commons cannot fullfill all those purposes. Sextvå.tvånoll.ettsjunoll.sjufyra (talk) 20:14, 19 April 2019 (UTC)
- 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 the Microsoft Store album ID (P4603). Multichill (talk) 20:23, 27 May 2019 (UTC)
P4603 (P4603): (delete | history | links | entity usage | logs)
The store has been closed. —★ → Airon 90 15:57, 12 February 2019 (UTC)
- Delete looks like it never really got used anyway. Multichill (talk) 12:33, 16 February 2019 (UTC)
- Delete Not sure this is useful if this was closed Misc (talk) 22:41, 17 February 2019 (UTC)
- Delete Per above. Esteban16 (talk) 17:42, 26 February 2019 (UTC)
- Keep While the website is no longer functional, there are thousands of IDs which can still be obtained due to having been saved in the Internet Archive. It may be beneficial to keep this data in Wikidata, although there may not be much of a use case at the moment. Jc86035 (talk) 08:51, 1 March 2019 (UTC)
- Keep per Jc86035. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:53, 4 March 2019 (UTC)
- Delete 3 actual uses as of today. --- Jura 21:13, 16 March 2019 (UTC)
- Delete; unused so far, it won't be useful in the future. --abián 14:52, 25 March 2019 (UTC)
- Delete. Too few uses to justify keeping a historical identifier. Deryck Chan (talk) 13:38, 7 April 2019 (UTC)
- Delete not used and website closed. --Rschen7754 18:22, 13 April 2019 (UTC)
- Keep It can still be used ny internet archive. Trade (talk) 16:04, 6 May 2019 (UTC)
- Delete Not used and never be completed. Snipre (talk) 23:54, 9 May 2019 (UTC)
- 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 the Microsoft Store artist ID (P4497). Multichill (talk) 20:27, 27 May 2019 (UTC)
P4497 (P4497): (delete | history | links | entity usage | logs)
The store has been closed. —★ → Airon 90 15:58, 12 February 2019 (UTC)
- Delete looks like it never really got used anyway. Multichill (talk) 12:34, 16 February 2019 (UTC)
- Delete not useful if closed Misc (talk) 22:42, 17 February 2019 (UTC)
- Delete Per above, and it was barely used. Esteban16 (talk) 17:40, 26 February 2019 (UTC)
- Keep While the website is no longer functional, there are thousands of IDs which can still be obtained due to having been saved in the Internet Archive. It may be beneficial to keep this data in Wikidata, although there may not be much of a use case at the moment. Jc86035 (talk) 08:51, 1 March 2019 (UTC)
- Keep per Jc86035. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:56, 4 March 2019 (UTC)
- Delete 9 uses as of today, 16 months after creation. --- Jura 21:11, 16 March 2019 (UTC)
- Delete; unused so far, it won't be useful in the future. --abián 14:53, 25 March 2019 (UTC)
- Delete. Too few uses to justify keeping a historical identifier. Deryck Chan (talk) 22:02, 6 April 2019 (UTC)
- Delete not used and website closed. --Rschen7754 18:22, 13 April 2019 (UTC)
- Delete; unused so far, it won't be useful in the future. Snipre (talk) 23:56, 9 May 2019 (UTC)
- 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 a majority to Delete the property, although this is clearly a contentious subject.
Wikidata can cover pornographic topics and it can link to user-edited websites. But this particular website can be used to publish intimate information about people without their consent, which poses a high risk. Concerns about data quality and relevance have also been raised. − Pintoch (talk) 13:26, 4 June 2019 (UTC)
P6270 (P6270): (delete | history | links | entity usage | logs)
Recently proposed on the project chat under Suitability of property "Boobpedia article", now archived (pinging StarryGrandma, ChristianKl, Ghouston, Micru, Lazypub, The Honorable, Mahir256, Robin van der Vliet, Valentina.Anitnelav, Gerwoman). StarryGrandma already put it much better than I could, especially in her second comment, and site administrator Th. Hon. also said they would support a deletion request, so I’ll keep my comment brief – IMHO this is some seriously creepy shit that I really don’t want to see on Wikidata. (And no, ChristianKl, this has nothing to do with me being conservatively minded
.) —Galaktos (talk) 15:56, 18 February 2019 (UTC)
- Delete see the previous discussion for my reasoning. ChristianKl ❪✉❫ 15:59, 18 February 2019 (UTC)
- Keep - to repeat my original comment "I don't think Boobpedia should be used to prove notability. But I find it no worse of a site than many of the others we have available." Lazypub (talk) 00:10, 19 February 2019 (UTC)
- Delete - I'm an admin on the site, so obviously I'm not "conservatively minded." Boobpedia is a user-edited wiki with articles of wildly varying reliability, mostly about living people. Having an official property for it gives a false impression about the quality and accuracy of the site. Th. Hon. 02:30, 19 February 2019 (UTC)
- But how is that any different than, as example, musicbrainz (which is considered authority control), discogs, or imdb? Lazypub (talk)
- Musicbrainz appears to be professional spam, this GUID is obviously not better than discogs or allmusic. OTOH your examples don't mention "boobs", some celebs might not welcome this name for a property, same idea as some stuff listed in the Project:Living people policy, e.g., weight, and cup size (as plain English version of boob) is worse than weight, here: mass. I'll have a screaming fit if somebody puts "was 32B, now 34D" in an enwiki article where I could add the references. Hopefully 34D isn't good enough for boobpedia, but I digress. –84.46.53.0 19:26, 19 February 2019 (UTC)
- But how is that any different than, as example, musicbrainz (which is considered authority control), discogs, or imdb? Lazypub (talk)
- Keep This property is just a property like any other. Qualifying this property like "creepy shit" is definitely not an objective criteria that we can use to evaluate our properties. If the scope is considered too broad, it can be narrowed by restricting its uses to professions where this property would be applicable.--Micru (talk) 06:09, 19 February 2019 (UTC)
- Delete per StarryGrandma -- Jneubert (talk) 09:12, 19 February 2019 (UTC)
- Delete - Valentina.Anitnelav (talk) 10:08, 19 February 2019 (UTC)
- Delete - --Gerwoman (talk) 17:58, 22 February 2019 (UTC)
- Delete I don't think we need property for all user-generated wikis.--Jklamo (talk) 12:31, 24 February 2019 (UTC)
- Keep If we got rid of the user-generated wikis, we could very easily delete half our properties. Trade (talk) 16:28, 25 February 2019 (UTC)
- Not to mention the fact that we are a user-generated wiki. Should other sites discount what we do here? Lazypub (talk)
- User-generated wikis aren't considered acceptable sources on enwiki. Th. Hon. 00:41, 27 February 2019 (UTC)
- Not to mention the fact that we are a user-generated wiki. Should other sites discount what we do here? Lazypub (talk)
- Keep As said before, qualifying this property like "creepy shit" is definitely not an objective criteria that we can use to evaluate our properties, and we do have a large number of other IDs using user generated content. Topics like pornography often deal with "machismo" and objectification of people, which is bad. But I do not think these topics should be swept under the rug. How to deal with it? Baloubet du Rouet (talk) 04:08, 28 February 2019 (UTC)
- I'm not sure if you read the discussion, but this is not about pornography (there are other identifiers in this area that are ok) and Boobpedia is not dedicated to porn ("Boobpedia is a free and user-edited encyclopedia of women with big boobs"). Accordingly there might be an article for any women with cup C and above and this id is used on people who have nothing to do with pornography, like Lara Logan (Q133653), Aretha Franklin (Q125121) and a lot more. While it might be normal to refer to women as "boobs" in the pornographic area this kind of objectification is degrading towards others and should not be made "official" by dedicating an own id to it. - Valentina.Anitnelav (talk) 11:29, 1 March 2019 (UTC)
- Delete I take a very liberal line to allowing IDs from "adult" sites, but this one presents non-trivial BLP issues (not to mention safe-space issues, when people start creating entries there for Wikimedians), and we get very little benefit from using it. Colleagues voting "keep" should consider how they would feel if someone created an entry there for their mother/ sister/ daughter/ life-partner. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:04, 4 March 2019 (UTC)
- Delete I don't want to lend any support to this dubious site. We have a responsibility to consider BLP and #MeToo issues; this clearly fails both. --Tagishsimon (talk) 22:30, 6 March 2019 (UTC)
- Delete Facepalm Gamaliel (talk) 19:44, 7 March 2019 (UTC)
- Keep. This is an ID like any other we store. Thierry Caro (talk) 14:42, 11 March 2019 (UTC)
- Delete per Jklamo, Multichill (talk) 16:31, 11 March 2019 (UTC)
- Delete Very problematic, per above. --Rschen7754 01:43, 16 March 2019 (UTC)
- As a user who's creating pages about erotic/pornographic models, including female, I can't remember a situation when Boobpedia was helpful for me. There are some catalogues of similar reliability which not mentionned in properties here, such as babesandstars.com, indexxx.com, thenude.eu, eurobabeindex.com... and there are not wiki-powered. However I'm voting Neutral, it's not an inferior-quality source. I'm still adding this to Statements 'cause I'm not much care. --Wolverène (talk) 15:45, 28 March 2019 (UTC)
- Keep Wikidata is a meta-database. We're defeating this purpose by deleting this property. I'm pinging some voters of the initial property proposal as well: PMG, Cwf97, Marberal, Daft fiction. --Deansfa (talk) 01:26, 5 April 2019 (UTC)
- Keep PMG (talk) 07:26, 5 April 2019 (UTC) In my opinion there is no difference between this property and other ID property to user generated content. It also fits to Wikidata:List of properties/pornography.
- Keep Marberal (talk) 14:38, 5 April 2019 (UTC) What Boobpedia brings to the table is a whole lot of information detailing physical characteristics of people, which is within the scope of the Wikidata project. I think that by counting on that information, Wikidata improves and increases the amount of information stored in it. As for the main critics, I'll address the main four in here: ¿Boobpedia is user-edited? As of right now that can also be said of other property IDs. ¿Boobpedia is disrespectful? The data it brings to the table is comprised of numbers/classes detailing physical characteristics such as height, weight, eye color and many others, and the references to that data, and thus doesn't contravene the policies detailed in the resolution about the biographies of living persons. ¿Boobpedia objectifies those people by providing such a detailed amount of physical data? Wikidata is a user-edited knowledge base, which by design objectifies everything to represent it as properties in a huge graph. For example, every person's data is represented as an object instanced from the class "human", with several added physical properties such as height, color or mass. ¿Boobpedia only compiles information about "women with big boobs"? As many other databases its scoped, which means that it only compiles information regarding its area of interest. The same can also be said about many other properties that we use, such as Musicbrainz which compiles data only about music. – The preceding unsigned comment was added by Marberal (talk • contribs) at 14:38, 5 April 2019 (UTC).
- There seem to be some misunderstandings:
- I could not find any concern that Boobpedia compiles only information about "women with big boobs" in the discussion above (could you point me to it?): There was a concern that Boobpedia's scope is too broad - as it makes no difference between women in the erotic/pornographic business and others.
- In this context "objectification" does not refer to collecting information about a person within a certain model. It is a concept referring to a certain way of representing another person (e.g. as just a means to a certain goal (in the sexual domain: sexual arousal, erotic desires) or reduction to body/appearance (unrelated to their skills and accomplishments and without considering the subject's dignity) - if you want to delve deeper into this topic you may have a look at the entry in the Stanford Encyclopedia of Philosophy [23]).
- Given point 2, the disrespectfulness (towards women outside the pornographic/erotic business), the tendency to violate their dignity and thus the violation of goals expressed in Wikidata:Living_people should become a bit clearer. It is not respectful towards Aretha Franklin or Lara Logan to reduce them to their "boobs" and it is not respectful to speculate (contrary to your impression it seems to me that this information is rather scarcely sourced) about their size of breasts/body measurements and represent this as an issue of general concern. - Valentina.Anitnelav (talk) 09:47, 7 April 2019 (UTC)
- There seem to be some misunderstandings:
- I'd like to point out that per some of the reasoning in the Keep votes, stalker-y and doxing sites like Encyclopedia Dramatica (Q159540), Porn Wikileaks (Q7230195), and Kiwi Farms would be acceptable sites for properties, as "just a property like any other." As I suggested upthread, perhaps limiting website properties to sites Wikipedia would consider acceptable sources is in order? Th. Hon. 01:53, 14 April 2019 (UTC)
- While I see why it would be shocking to have a identifier on those web sites, I can also see value to someone studying the harassement targetting some persons (or quantifying it somehow). --Misc (talk) 08:23, 9 May 2019 (UTC)
- Delete low quality, BLP problems, etc. --99of9 (talk) 14:05, 20 April 2019 (UTC)
- Keep Like the property for Bilibili ID (see archive), copyright problems aren't what Wikidata users concern. --Liuxinyu970226 (talk) 10:30, 29 April 2019 (UTC)
- Additional Comment @99of9: For BLP concerns, we may consider adding property that may violate privacy (Q44601380) to this property, hence we warned users to no longer abuse using it. --Liuxinyu970226 (talk) 23:29, 9 May 2019 (UTC)
- I don't think you are supposed to use property that may violate privacy (Q44601380) on identifiers. And what is it about about abuse you are talking about? --Trade (talk) 21:08, 10 May 2019 (UTC)
- @Trade: I boldly added it, can't I? --Liuxinyu970226 (talk) 01:23, 14 May 2019 (UTC)
- Adding property that may violate privacy (Q44601380) doesn't say that people should be careful about adding data. It says that data should be only added when it "be considered widespread public knowledge or openly supplied by the individual themselves". I'm doubting that's true for most of the people that currently have the tag. ChristianKl ❪✉❫ 11:53, 15 May 2019 (UTC)
- ChristianKl is right. While fine to add, that warning does not resolve the issue here. I expect that the vast majority of existing uses of this property are probably against that warning, and more importantly against our BLP policies. Keeping the property in place just invites more violations. --99of9 (talk) 00:44, 31 May 2019 (UTC)
- Adding property that may violate privacy (Q44601380) doesn't say that people should be careful about adding data. It says that data should be only added when it "be considered widespread public knowledge or openly supplied by the individual themselves". I'm doubting that's true for most of the people that currently have the tag. ChristianKl ❪✉❫ 11:53, 15 May 2019 (UTC)
- @Trade: I boldly added it, can't I? --Liuxinyu970226 (talk) 01:23, 14 May 2019 (UTC)
- I don't think you are supposed to use property that may violate privacy (Q44601380) on identifiers. And what is it about about abuse you are talking about? --Trade (talk) 21:08, 10 May 2019 (UTC)
- Additional Comment @99of9: For BLP concerns, we may consider adding property that may violate privacy (Q44601380) to this property, hence we warned users to no longer abuse using it. --Liuxinyu970226 (talk) 23:29, 9 May 2019 (UTC)
- Delete, for the people who say "creepiness" is not a valid deletion criterion, I am at a loss. Wikidata ought to be a safe space. Most of these people did not ask for, and likely do not want, a web site focusing on their breast measurements and bra size. The creepiness factor is one of the most important criteria—Wikidata should have no part in providing a venue for unwanted, sexualized attention being given to women just because they are females in the public eye. Dominic (talk) 00:51, 24 May 2019 (UTC)
- @Dominic: But then, are you asking that "copyvio" can be a simple reason to delete a property? --Liuxinyu970226 (talk) 04:47, 26 May 2019 (UTC)
- I don't see the point of litigating copyright issues with this property, since it should already be deleted in any case. Dominic (talk) 20:13, 31 May 2019 (UTC)
- @Dominic: But then, are you asking that "copyvio" can be a simple reason to delete a property? --Liuxinyu970226 (talk) 04:47, 26 May 2019 (UTC)
- Delete. A site like this poses a big BLP risk, and a much bigger BLP risk than most other external databases that might be linked. (Given that there is widespread social and moral disapproval of pornography, and in many countries it is even illegal, the BLP risk/impact is a lot higher than e.g. a database of authors of academic papers). While some of the women on the site are well-known in the sex industry, others are very obscure, and in some cases may have only briefly been involved in pornography, and may have now moved on to other things in their lives. I think it is with those more obscure individuals with which the biggest BLP risk lies: someone who briefly got involved in making pornography when younger, and has long left the industry, and may possibly even regret their time in it, and while what's out there is out there, they have a genuine BLP interest in a site like Wikidata not spreading it further. Putting aside the BLP issues of obscure pornographic actresses, it also includes various non-pornographic celebrities (mainstream film actresses, etc), and I think their aggregation with pornographic actresses may be seen by many as disrespectful (including probably in at least some cases by those non-pornographic celebrities themselves), which is an additional BLP problem. SJK (talk) 09:25, 1 June 2019 (UTC)
- Delete - not appropriate to our mission. -- The Anome (talk) 22:15, 1 June 2019 (UTC)
- Keep but limit the use to those in the pornography industry. --Stevenliuyi (talk) 06:55, 2 June 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 12:41, 24 June 2019 (UTC) |
- 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 --Pasleim (talk) 12:44, 24 June 2019 (UTC)
LGDB game ID (P5116): (delete | history | links | entity usage | logs | discussion)
Linux Game Database have been dead for quite some time. I think it's fair to say, they are not coming back. —Trade (talk) 00:05, 22 February 2019 (UTC)
- Yeah, I always kept the hope :-( Too bad I did not create a Mix’n’match beforehand − it’s a bit of pain to do it via Internet Archive.
- Regarding the property − I think current practice is to change the formatter URL to go to the Internet Archive.
- Jean-Fred (talk) 13:59, 22 February 2019 (UTC)
- I tagged the 4 LGDB properties with Wikidata property for a discontinued website (Q60457486) and added a preferred formatter URL (P1630). Jean-Fred (talk) 14:16, 22 February 2019 (UTC)
- Looks like the Internet Archive did a fairly good job:
- Games: 3,335 URLs captured;
- Emulators: 100 URLs captured;
- Tools: 86 URLs captured;
- Engines: 80 URLs captured.
- Jean-Fred (talk) 14:25, 22 February 2019 (UTC)
- Looks like the Internet Archive did a fairly good job:
- I tagged the 4 LGDB properties with Wikidata property for a discontinued website (Q60457486) and added a preferred formatter URL (P1630). Jean-Fred (talk) 14:16, 22 February 2019 (UTC)
- Keep And - as a meta issue - please can we stop having deletion discussions for identifiers which are no longer issued, but still exist in archives? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:55, 4 March 2019 (UTC)
- Keep I 10000% agree with Pigsonthewing said, plus we should refrain from PFDing for properties that "met copyright problems". --Liuxinyu970226 (talk) 10:32, 29 April 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 12:45, 24 June 2019 (UTC) |
- 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 --Pasleim (talk) 12:46, 24 June 2019 (UTC)
X numeric user ID (P6552): (delete | history | links | entity usage | logs | discussion)
Redundant with X username (P2002) and creation seems to be inconsistent with the discussion (see use on Q2013 by creator) --- Jura 11:12, 3 March 2019 (UTC)
- In what way is it inconsistent? NMaia (talk) 02:09, 4 March 2019 (UTC)
- Proposal discussion is at: Wikidata:Property proposal/Twitter user ID. Creation by User:Pintoch seems perfectly correct. The sole objection was from Jura1, who wrote only "Oppose adding both" with no rationale; and did not give an answer when asked why. There were four supporters, in addition to the proposer. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:47, 4 March 2019 (UTC)
- Keep, but use only as a qualifier to P2002 (or perhaps vice versa). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:47, 4 March 2019 (UTC)
- Keep. Not a valid rationale in my view. NMaia (talk) 22:36, 4 March 2019 (UTC)
- Keep; the username itself is still useful information. Trivialist (talk) 00:56, 5 March 2019 (UTC)
- Comment @NMaia: It seems that the actual "we" are confusing many pro/con lists of both properties, can we please restructure both as one section, to discuss both P2002 and P6552? --Liuxinyu970226 (talk) 14:36, 5 March 2019 (UTC)
- Keep Useful because a Twitter user may rename their account, but having a log of the name used has value. Also there is a known pattern where users will archive their accounts by renaming their account and then creating a new account with the original username. Having both the username and user id numbers allows us to track this. William Graham (talk) 19:27, 26 April 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 12:46, 24 June 2019 (UTC) |
- 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 --Pasleim (talk) 12:47, 24 June 2019 (UTC)
P1946 (P1946): (delete | history | links | entity usage | logs)
Identifier not used by National Library of Ireland, linked indentifiers are works, not authors. See Property talk:P1946. —Jklamo (talk) 16:38, 4 March 2019 (UTC)
- Delete based on the discussion on the property talk page it looks like this has never worked and is simply not a valid id. ArthurPSmith (talk) 18:15, 4 March 2019 (UTC)
- There are currently 16,501 uses of this property. Is the proposal to simply discard that data? Can nothing be salvaged? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:37, 4 March 2019 (UTC)
- I don't know how much can be salvaged, but this also discusses the problem. When the Property example on the property page is incorrect, there is a serious problem. Circeus (talk) 18:49, 4 March 2019 (UTC)
- @Pigsonthewing:, as far as I can tell from the talk page, this property's existence in VIAF has a) no connection whatsoever with the website data and b) is really just a mirror of the LCC data anyway. Circeus (talk) 12:32, 17 March 2019 (UTC)
- In that case, Delete. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:12, 17 March 2019 (UTC)
- Delete The very example on the property page is incorrect, and since almost all records are being added based on VIAF records which seem to reflect no actual ID in use at the Library, this is essentially unsalvageable. Circeus (talk) 12:32, 17 March 2019 (UTC)
- I don't have a vote either way, though I'm edging toward keep. I originally proposed this based on the data that the library was feeding to VIAF. It is still feeding that data and they are still digitizing their indices (according to their website). I think it stands to reason that if a library is actively creating identifiers and giving this data to VIAF that the numbers have meaning and likely use in the future, even if they don't link to anything today. Hazmat2 (talk) 23:17, 23 May 2019 (UTC)
- @hazmat2: Have you looked at the talk page for the property? Here's what someone who actually asked the NLI wtf was going on got for an answer: "The VTLS files [prob. referring to VTLS (Q7907618) software and not any standard] where added to VIAF as a test in 2014 and they had not been able to do any further things with them afterwards. The bibliographical records currently linked do share the same VTLS ID, but are totally independent from the authority record. No correlation whatsoever. The authority record linked in VIAF is correct, but it is not actually a record created by the NLI, it is a downloaded record from the Library of Congress authorities server. So basically a copy of the data with a new number in their own VTLS system."
- They will never "have meaning" and they are not actively either "creating identifiers" nor "giving this data to VIAF", because they're not adding anything further from the original data dump, which was never their data to begin with, but a mirror of LCC authorities. Circeus (talk) 23:37, 23 May 2019 (UTC)
- Nope. I wasn't actively following this on the talk page. All I knew was that there had been new VTLS numbers on VIAF since two years ago. Probably just evidence of linking on VIAF side then which I took as NLI linking them. If that's the case then I vote delete as well. Hazmat2 (talk) 00:23, 24 May 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 12:47, 24 June 2019 (UTC) |
- 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 --Pasleim (talk) 12:52, 24 June 2019 (UTC)
business division (P199): (delete | history | links | entity usage | logs | discussion)
Merge to has subsidiary (P355). To the extent there is any difference at all in the use of these two properties, it is subtle and inconsistent. They certainly don't offer a clear distinction in legal statuses, which vary from country to country anyway. —Swpb (talk) 14:55, 6 March 2019 (UTC)
- Delete I've never been sure when to use one or the other, and generally have just used has subsidiary (P355). Also the inverse property parent organization (P749) makes having two of these complicated. ArthurPSmith (talk) 17:03, 6 March 2019 (UTC)
- Keep Distinction is clear, has subsidiary (P355) for separate legal entity, business division (P199) for something else. Concept for legal entity does not vary from country to country so much. But I admit that distinction between has subsidiary (P355) and business division (P199) is not well described at the moment and even constraint violations are not set completely properly. I can fix that. Note that both has subsidiary (P355) and business division (P199) are currently used in multiple infoboxes at multiple wikis, so cleary there is a demand to distinct these two. For inverse properties I use parent organization (P749) for has subsidiary (P355) and part of (P361) for business division (P199).--Jklamo (talk) 17:30, 6 March 2019 (UTC)
- Ok, that's a reasonable argument. ArthurPSmith (talk) 20:16, 6 March 2019 (UTC)
- @Jklamo: The current English description doesn't seem to highlite the fact that it's for a separate legal entity. Maybe, we need to change the description to make that more clear? ChristianKl ❪✉❫ 14:24, 8 March 2019 (UTC)
- Keep If these are currently used inconsistently, that should be fixed, but they are distinct concepts. --Oravrattas (talk) 19:33, 6 March 2019 (UTC)
- Comment I have fixed the English descriptions, examples and constraint violations.--Jklamo (talk) 12:02, 24 March 2019 (UTC)
- Keep ChristianKl ❪✉❫ 07:50, 5 April 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 12:52, 24 June 2019 (UTC) |
- 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 to a new property with datatype "musical notation". --Pasleim (talk) 12:55, 24 June 2019 (UTC)
P5482 (P5482): (delete | history | links | entity usage | logs)
Procedural request; the datatype should be changed to "musical notation". Jc86035 (talk) 10:36, 17 March 2019 (UTC)
- Support Comment The new datatype is currently limited to 400 characters, whereas strings could be of any length. As of today, the longest occurrence is only 125 characters, but for the sake of discussion, I added a 760 character value at Il était un petit navire (Q2607622). LaddΩ chat ;) 15:02, 17 March 2019 (UTC)
- @Laddo: I was aware when floating the existence of a musical notation datatype that the limit for all string-based properties was 400 characters. Did this limit get larger some time ago for regular strings? If so, then the datatype should promptly be adjusted to use the new upper limit. Mahir256 (talk) 18:43, 17 March 2019 (UTC)
- @Mahir256: Dunno what the maximum number of character is, but Wikidata usage instructions (P2559) has one entry with 514 chars (), and I had no issue creating a string of 1000 chars here. LaddΩ chat ;) 20:43, 17 March 2019 (UTC)Try it!
PREFIX wd: <http://www.wikidata.org/entity/> SELECT ?item ?itemLabel ?valueLabel (strlen(?valueLabel) as ?nbChar) WHERE { ?item wdt:P2559 ?value . SERVICE wikibase:label { bd:serviceParam wikibase:language "en,en" } } order by desc (?nbChar) LIMIT 3
- @Lucas Werkmeister (WMDE), Lydia Pintscher (WMDE): can you clarify the maximum character limit for properties based on strings? If in fact it is higher than 400, can this new datatype be extended to use that character limit? Mahir256 (talk) 20:46, 17 March 2019 (UTC)
- @Mahir256: the limit for external identifiers, strings and URLs was recently raised to 1500 characters (T154660). No comment from me on whether that should apply to musical notation too. --Lucas Werkmeister (WMDE) (talk) 11:20, 18 March 2019 (UTC)
- I'm open to increasing it if we are confident we can deal with the licensing issues that potentially arise with longer musical pieces. --Lydia Pintscher (WMDE) (talk) 16:18, 18 March 2019 (UTC)
- @Mahir256: the limit for external identifiers, strings and URLs was recently raised to 1500 characters (T154660). No comment from me on whether that should apply to musical notation too. --Lucas Werkmeister (WMDE) (talk) 11:20, 18 March 2019 (UTC)
- @Lucas Werkmeister (WMDE), Lydia Pintscher (WMDE): can you clarify the maximum character limit for properties based on strings? If in fact it is higher than 400, can this new datatype be extended to use that character limit? Mahir256 (talk) 20:46, 17 March 2019 (UTC)
- @Mahir256: Dunno what the maximum number of character is, but Wikidata usage instructions (P2559) has one entry with 514 chars (
- @Laddo: I was aware when floating the existence of a musical notation datatype that the limit for all string-based properties was 400 characters. Did this limit get larger some time ago for regular strings? If so, then the datatype should promptly be adjusted to use the new upper limit. Mahir256 (talk) 18:43, 17 March 2019 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Laddo, Mahir256: Since the length limit has been increased, I think it would now be appropriate to replace the property. Jc86035 (talk) 16:29, 15 April 2019 (UTC)
- Support Let's replace it. NMaia (talk) 13:43, 13 June 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 12:55, 24 June 2019 (UTC) |
- 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 --Pasleim (talk) 12:37, 24 June 2019 (UTC)
P2035 (P2035): (delete | history | links | entity usage | logs)
This has been superseded by LinkedIn personal profile ID (P6634) (see consensus at Wikidata:Property proposal/LinkedIn personal profile_ID, and earlier discussions linked from there), and I have marked it as deprecated. I have now copied over existing values, excluding a few which were malformed, or otherwise not working. A few more have been moved to LinkedIn company or organization ID (P4264), where they correctly belong. I have placed notices of this breaking change on the talk pages of all versions of Template:LinkedIn URL (Q29508942). We need to decide how much time to allow sister projects to catch up before we delete the property. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:11, 29 March 2019 (UTC)
- Delete Looks like it's ready to go - thanks! ArthurPSmith (talk) 18:59, 1 April 2019 (UTC)
- Could somebody fix the errors listed in Wikidata:Database reports/Constraint violations/P2035#Format? Visite fortuitement prolongée (talk) 21:41, 4 April 2019 (UTC)
- What's the point, if the property is deprecated, and due for deletion? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:43, 9 April 2019 (UTC)
- The point is to avoid loosing data, if possible. Visite fortuitement prolongée (talk) 20:05, 10 April 2019 (UTC)
- What's the point, if the property is deprecated, and due for deletion? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:43, 9 April 2019 (UTC)
- Comment What about other templates using P2035 (P2035)? At its talkpage I can see much more templates and even that list is incomplete (most of wiki using modules are omitted).--Jklamo (talk) 11:23, 9 April 2019 (UTC)
- Delete --99of9 (talk) 14:11, 20 April 2019 (UTC)
- Delete Consensus to replace. --Liuxinyu970226 (talk) 10:27, 29 April 2019 (UTC)
- Delete but need to inform all the sister project that are list to use this property with date to delete it (let say and of may). - yona b (talk) 10:56, 2 May 2019 (UTC)
- Delete too. Nomen ad hoc (talk) 14:44, 21 May 2019 (UTC).
- Delete looks good to be replaced now. -- Ajraddatz (talk) 21:26, 27 May 2019 (UTC)
- Delete given the previous consensus to replace --DannyS712 (talk) 04:37, 2 June 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 12:37, 24 June 2019 (UTC) |
- 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 by Sannita. --Liuxinyu970226 (talk) 10:18, 3 June 2019 (UTC)
P6779 (P6779): (delete | history | links | entity usage | logs | discussion)
Request by the creator of the Property: Terms of use can not be respected on WD: CC BY-NC 4.0. The creation of a new property is also possible. Regards. --Eihel (talk) 15:09, 25 May 2019 (UTC)
- Comment @Eihel: not sure ot understand, for an identifier the license doesn't usually matter (the database can be fully copyrighted, you still have the right to point to this database). Cheers, VIGNERON (talk) 15:28, 27 May 2019 (UTC)
- @Eihel: Same as VIGNERON: why would a CC BY-NC license forbid Wikidata from linking to this service? Wikidata has plenty of identifiers linking to websites which are not CC0 themselves. Can you also add a link to the property proposal where this was discussed? − Pintoch (talk) 15:33, 27 May 2019 (UTC)
- @Pintoch: I believe the property proposal is Wikidata:Property proposal/Dimensions grant/project ID. --Lucas Werkmeister (talk) 15:52, 27 May 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 12:38, 24 June 2019 (UTC) |
first flight (P606)/UTC date of spacecraft launch (P619)/UTC date of spacecraft landing (P620)/time of object orbit decay (P621)/spacecraft docking/undocking date (P622)
- 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.
- Keep The discussion dragged on for two years and there are more votes to keep the property then to delete it. ChristianKl ❪✉❫ 10:25, 8 August 2019 (UTC)
first flight (P606): (delete | history | links | entity usage | logs | discussion) UTC date of spacecraft launch (P619): (delete | history | links | entity usage | logs | discussion) UTC date of spacecraft landing (P620): (delete | history | links | entity usage | logs | discussion) time of object orbit decay (P621): (delete | history | links | entity usage | logs | discussion) spacecraft docking/undocking date (P622): (delete | history | links | entity usage | logs | discussion)
Overly specific time properties. Use instead, with qualifier point in time (P585):
- significant event (P793)maiden flight (Q1362364)
- significant event (P793)rocket launch (Q797476)
- significant event (P793)landing (Q844947)
- significant event (P793)orbital decay (Q2918240)
- significant event (P793)docking and berthing of spacecraft (Q557450)
- significant event (P793)undocking (Q19858600)
--Swpb (talk) 18:19, 22 March 2017 (UTC)
- Oppose. Specific properties are more user-friendly for new users than generic properties with qualifiers. New users may easily discover specific properties and put useful data in them. They are much less likely to work out how to use P793 with qualifiers. And it is easier for other wikis to work out to consume a specific property than to consume a generic property filtered by qualifiers. If we were to go down this path, should we not to be consistent also delete date of birth (P569) and place of birth (P19) since they too can also be replaced by P793 with qualifiers? Also, even for experienced users, specific property is easier than generic property+qualifier because it is less typing/clicking to enter. And it is easier for people writing SPARQL queries, since the syntax for querying on qualifiers is more advanced than just querying for specific properties so this would make the SPARQL learning curve steeper (and it is pretty steep already, in my opinion). SJK (talk) 08:46, 24 March 2017 (UTC)
- @SJK: I have some doubt about the affirmation "New users may easily discover specific properties and put useful data in them". When you have more than 3000 properties it is difficult to say that a new user can easily find the right property especially when the numbering is not based on any logic. The most problem we have is from the people in WP who want to add one value in an infobox. Most of the time they access WD via the link between the article and the corresponding item. Then they add a new statement and they have to find the right property. They can be lucky by entering the correct words or not. If not what happens ? They don't want to extract all subproperties of significant event (P793) using a SPARQL query (most of wikipedians don't know anything about SPARQL) and they don't want to start any search to find the wikiproject responsible of managing the properties structure. So if the wikipedian doesn't find the correct property in the first search he won't continue to look for it and he will abandon. With one property there is a huge probability than the general property is already used in the item and it is easier to copy-paste the existing statements for a new addition. Even if they don't used the correct value for significant event (P793) like using maiden flight instead of first flight or the inverse, they can already add the location or the date and the error can be detected and corrected using the constraint violation reports. Snipre (talk) 15:29, 4 April 2017 (UTC)
- start_date, end_date, point_in_time are intuitive qualifiers/properties.
- Documentation of P793 could be improved to emphasize relevant qualifiers. d1g (talk) 15:35, 30 April 2017 (UTC)
- Delete per Snipre --Pasleim (talk) 11:44, 15 April 2017 (UTC)
- Keep first flight (P606). This one is well defined and used. This makes it very easy to query and use as well as to enter in the first place. The significant event (P793) method is not a problem, but also doesn't really offer an advantage over having first flight (P606) as a distinct property. Josh Baumgartner (talk) 20:24, 18 April 2017 (UTC)
- Delete
P793/P31/P279*/<event in space>
is easier to query than 5 distinct properties. It's better to create taxonomies of evens than a property for every event IMO. - Basic queries with P793 are both easy and narrow: significant event (P793)docking and berthing of spacecraft (Q557450) d1g (talk) 15:29, 30 April 2017 (UTC)
- Keep working with separate properties is easier than prop+qualifier. Some another prop+qualifier schemes had moved to separate properties scheme already. So significant event (P793)/point in time (P585) will be deleted too as I think. — Ivan A. Krestinin (talk) 08:01, 20 May 2017 (UTC)
- With birth/death events because every person dies... maybe.
- It isn't obvious to have 2 properties per every event over events +3 qualifiers.
- @Ivan A. Krestinin: almost 2 times less properties-or-events to find with P793.
- We also need to create properties, when we don't need to create events in most cases with significant event (P793) d1g (talk) 01:26, 15 June 2017 (UTC)
Comment I checked the usage of each template. PokestarFan • Drink some tea and talk with me • Stalk my edits • I'm not shouting, I just like this font! 23:03, 14 June 2017 (UTC)
- Keep first flight (P606) and UTC date of spacecraft launch (P619) because they have almost (or over) 5000 uses [24] [25]. PokestarFan • Drink some tea and talk with me • Stalk my edits • I'm not shouting, I just like this font! 23:03, 14 June 2017 (UTC)
- Delete UTC date of spacecraft landing (P620), time of object orbit decay (P621) and spacecraft docking/undocking date (P622) because they have at most 350 uses [26] [27] [28]. PokestarFan • Drink some tea and talk with me • Stalk my edits • I'm not shouting, I just like this font! 23:03, 14 June 2017 (UTC)
- This doesn't really make sense - these properties form a coherent group for describing concepts and so we should either have them all, or put them all as "significant event" qualifiers. All spacecraft go up and so all will have a launch date; not all have come down yet so there will be fewer with landing/decay times. It's natural to expect an imbalance between the two groups, much as we have far more people with "born" than "died". Andrew Gray (talk) 11:27, 25 July 2017 (UTC)
- Comment we shouldn't make decisions in any direction based on current usage. Maybe we don't have understanding what exactly is better, but we shouldn't make popularity-driven decisions. d1g (talk) 04:51, 10 August 2017 (UTC)
- Keep seems to be a working set of (sub-)properties.
--- Jura 14:50, 9 July 2017 (UTC)
Refuse to consider until time of day and time zone issues with Wikidata Datetimes are resolved. Jc3s5h (talk) 23:32, 20 July 2017 (UTC)
- Keep All of these properties seem to be useful and working with them is much easier than using qualifiers with significant event (P793). --Sintakso (talk) 22:56, 26 July 2017 (UTC)
- @Sintakso: in SPARQL difference is in 1 triple, 1 is less than 2, but I wouldn't call it "much".
- Can you show example how one property is far better than event?
- What happens when one needs to specify a qualifier for this property?
- But it takes more time to maintain individual property (create, translate in every language)
- Date-related properties aren't specific to space.
- 3(4 with location) qualifiers are free from "...location of ..." "...time of..." restrictions and much faster to enter data by humans. You only need to know 4 properties, not 5-10-300-1000. There is nothing to "discover" because so few options to make mistakes between. d1g (talk) 04:51, 10 August 2017 (UTC)
- @D1gggg: I didn't mean just the use of the properties in SPARQL queries. I believe that the users are much more likely to find a distinct property than they are to notice the existence significant event (P793), read it's documentation and remember that they can use it for inserting date of landing, docking etc. Distinct properties are easy to search, so the users don't even have to know/remember the property exists and they can still find it easily. The use of significant event (P793) wouldn't probably spare any time at all, because it would still be needed to translate labels of the items used with it and to check constraint violations regularly (so that users wouldn't be using eg. docking (Q22988075) instead of docking and berthing of spacecraft (Q557450)). The only change I would support would be to delete spacecraft docking/undocking date (P622) and replace it with two properties for docking and undocking. --Sintakso (talk) 06:52, 10 August 2017 (UTC)
- @Sintakso: because it would still be needed to translate labels of the items used with it
- Only for events never described in Wikipedia as separate article (something rare).
- E.g.: burial (Q331055) baptism (Q35856).
- We don't have specific properties to both of them, we will spend time on property creation.
- 300-1000 distinct events aren't stretched at all.
- Furthermore, when we use Q1764062, Q331055 and Q35856 in 793 users could read Wikipedia articles if they never heard about such event. d1g (talk) 20:32, 10 August 2017 (UTC)
- @Sintakso: we are using this approach in award received (P166)
- Point in time is not something we need to know every time, but additional information.
- E.g. "was it ever sequenced?" "how many times burial ceremony happened?"
- Where and when should be qualifiers d1g (talk) 20:42, 10 August 2017 (UTC)
- @D1gggg: I didn't mean just the use of the properties in SPARQL queries. I believe that the users are much more likely to find a distinct property than they are to notice the existence significant event (P793), read it's documentation and remember that they can use it for inserting date of landing, docking etc. Distinct properties are easy to search, so the users don't even have to know/remember the property exists and they can still find it easily. The use of significant event (P793) wouldn't probably spare any time at all, because it would still be needed to translate labels of the items used with it and to check constraint violations regularly (so that users wouldn't be using eg. docking (Q22988075) instead of docking and berthing of spacecraft (Q557450)). The only change I would support would be to delete spacecraft docking/undocking date (P622) and replace it with two properties for docking and undocking. --Sintakso (talk) 06:52, 10 August 2017 (UTC)
- @D1gggg: I agree that the significant event (P793) + qualifiers approach might be more useful for rare events. However, I believe that in case of common events the time spent with the property creation is outweighted by the user-friendliness of distinct properties. Also, I don't see any point in deleting properties which are already in use and replacing them with significant event (P793) as it doesn't seem to have any major advantages. --Sintakso (talk) 10:06, 11 August 2017 (UTC)
- Delete Not user-friendly for new users at all, because you must know these property before adding them, and don't forget to check if they exist! There are too many dates properties. This method (creating new properties) is very painstaking: if you want to add and event that doesn't have its own property, you must ask for a property creation, wait weeks... "Good" events have their own properties, "bad" have not... And why do we a have a "date of (event)" property and not others? For example, a "first flight" might be described not only by a date, but by the airport(s), the crew (pilot(s) and so on), important people who attended... Are we going to split each event into multiple properties? Please, have a look at General Dynamics YF-16 (Q17372279). El Caro (talk) 15:06, 20 August 2017 (UTC)
- Delete per El Caro's arguments --Hsarrazin (talk) 08:13, 25 August 2017 (UTC)
- Delete. Consistency is important. Storing data so many different ways makes it difficult to use. --Yair rand (talk) 23:40, 11 September 2017 (UTC)
- Keep. They are used by several Wikipedias using the {{#Property:P622}} etc syntax. Deleting these properties will break those infoboxes and there is no easy replacement solution in the proposed migration scheme that doesn't involve bespoke, locally hosted Lua scripts to let the infoboxes find the relevant significant event (P793) + point in time (P585) dates. Until parser functions become sufficiently advanced that these can be migrated by changing wikitext alone, we'll need to keep these properties. Deryck Chan (talk) 15:53, 24 September 2017 (UTC)
- Keep As Joshbaumgartner. Keep first flight (P606) and delete the rest. /ℇsquilo 14:02, 30 October 2018 (UTC)
- This is a drive of complex problems, and at the moment I don't think keep all or delete all are good either. If there's some spikes that prevents us to safety use P793, as well as other properties, then those are just bugs, we should actually fix em.
- And @Deryck Chan: isn't {{#Property:}} somewhat deprecated now? What's the technical block on migrating usages to be {{#statements:}} (at least, as you're a Cantonese user, what's problem on Cantonese Wikipedia (Q1190962))?
--Liuxinyu970226 (talk) 12:41, 27 October 2017 (UTC)
- @Liuxinyu970226: I looked at the property talk pages and checked the templates that used these properties. it:Template:Infobox missione spaziale is an example that uses the {{#Property:}} syntax (through Template:Wikidata (Q8478926)) to fetch this property. I'm not aware of any use of these properties on yue.wp. So my suggested plan of action is (0) mark these properties as deprecated (1) copy these statements into the proposed new statement structure (2) modify all the relevant templates to transfer all uses of these properties in other Wikimedia sites to the new statement structure (3) finally delete the property. Deryck Chan (talk) 11:22, 31 October 2017 (UTC)
- I've recently learned that it's not possible to select statements based on qualifier values using {{#statements:}}. Module:Wikidata (Q12069631) and Module:Wikidata2 (Q25936424) don't currently have that functionality either. So I think we should keep these properties until that becomes possible. Deryck Chan (talk) 14:47, 7 December 2017 (UTC)
- Some versions of Module:Wikidata2 (Q25936424) can read out statements based on qualifiers, e.g. the version on frwiki. Moreover, spacecraft docking/undocking date (P622) also requires qualifiers. Infoboxes need to select statements based on qualifier values to properly display the data of spacecraft docking/undocking date (P622). --Pasleim (talk) 06:43, 8 December 2017 (UTC)
- I've recently learned that it's not possible to select statements based on qualifier values using {{#statements:}}. Module:Wikidata (Q12069631) and Module:Wikidata2 (Q25936424) don't currently have that functionality either. So I think we should keep these properties until that becomes possible. Deryck Chan (talk) 14:47, 7 December 2017 (UTC)
- @Liuxinyu970226: I looked at the property talk pages and checked the templates that used these properties. it:Template:Infobox missione spaziale is an example that uses the {{#Property:}} syntax (through Template:Wikidata (Q8478926)) to fetch this property. I'm not aware of any use of these properties on yue.wp. So my suggested plan of action is (0) mark these properties as deprecated (1) copy these statements into the proposed new statement structure (2) modify all the relevant templates to transfer all uses of these properties in other Wikimedia sites to the new statement structure (3) finally delete the property. Deryck Chan (talk) 11:22, 31 October 2017 (UTC)
- Keep I vote to keep. There is no such thing as "too much specific". We have "subproperty" property for a reason. --Ogoorcs (talk) 01:56, 8 September 2018 (UTC)
- Keep I'm Okay with SJK Olivier LPB (talk) 10:53, 30 January 2019 (UTC)
- Keep I vote to keep. There is no such thing as "too much specific". This is easier to use by new users. Deror avi (talk) 08:22, 3 February 2019 (UTC)
- Keep Because of its wide used and related with common concepts. We shouldn't abuse of P793 and reserve it for unusual/open points in time that are difficult to foresee as property. Amadalvarez (talk) 10:58, 26 March 2019 (UTC)
- Delete because we can replace them with other properties--DiMon2711 12:36, 27 April 2019 (UTC)
- Delete: Why have a bunch of “time of spacecraft [event]” properties when most of the events (launch, landing, docking/undocking) apply to many kinds of vehicles, and the remaining one (orbital decay) applies to all kinds of spaceborne objects. Hawke666 (talk)
- Keep As an editor of space related things, I find this properties very useful, and as said above, this could lead to problems on infoboxes, and there is no such thing as "too much specific".--BugWarp (talk) 18:24, 1 August 2019 (UTC)
- 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 − Pintoch (talk) 20:19, 16 August 2019 (UTC)
P5367 (P5367): (delete | history | links | entity usage | logs)
As it was already announced before, unfortunately, today service YouTube Gaming was definitely closed. More specifically, YouTube has stopped supporting this service and subsequently, all the video game content now can be found only on the page https://www.youtube.com/gaming in the main YouTube app/page. As a result, all links now also redirected on this site, unfortunately I think that we will have to delete the property for obvious reasons since we can no longer do anything here, this is so sad :/- Internet Archive gives me an Your browser isn't supported :(error so i don't really think that's an option. Are there any other video game properties or video game databases that you think we should finish or create before they inevitable close down? --Trade (talk) 21:27, 30 May 2019 (UTC)
- I can confirm you, that at the moment we have only two video game streaming platforms, it's Twitch and also now closed YouTube Gaming. For all other platforms that exist, most of whom are not diffused, there is no identifier property, so there’s no need to worry about that. To create, I think, we still have for a moment Mixer (games) as other video game streaming platform, but it's not really diffused as Twitch, so I don't know. Kirilloparma (talk) 00:28, 31 May 2019 (UTC)
- I was thinking about gaming databases as a whole, not just streaming websites. Personally i'm concerned about Steam Greenlight (Q61905393) (Melody's Escape (Q60197903) - Melody's Escape). I've had trouble making a property proposal due to the nature of the URL. --Trade (talk) 01:40, 1 June 2019 (UTC)
- I can confirm you, that at the moment we have only two video game streaming platforms, it's Twitch and also now closed YouTube Gaming. For all other platforms that exist, most of whom are not diffused, there is no identifier property, so there’s no need to worry about that. To create, I think, we still have for a moment Mixer (games) as other video game streaming platform, but it's not really diffused as Twitch, so I don't know. Kirilloparma (talk) 00:28, 31 May 2019 (UTC)
- Internet Archive gives me an Your browser isn't supported :(error so i don't really think that's an option. Are there any other video game properties or video game databases that you think we should finish or create before they inevitable close down? --Trade (talk) 21:27, 30 May 2019 (UTC)
- Delete. Looks like this has already been deprecated so we can safely delete the property. Deryck Chan (talk) 17:39, 16 July 2019 (UTC)
- Delete: useless to keep a deprecated property. Nomen ad hoc (talk) 23:37, 8 August 2019 (UTC).
- Delete unused. --- Jura 14:42, 12 August 2019 (UTC)
- Delete for the same reasons. Nomen ad hoc (talk) 14:52, 12 August 2019 (UTC).
- 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 --- Jura 14:41, 12 August 2019 (UTC)
Scandinavian middle family name (P6978): (delete | history | links | entity usage | logs | discussion)
Premature creation as even the property creator can't explain how it's meant to be used. Besides, I get the impression they didn't bother reading the discussion, but merely run some script. --- Jura 08:58, 6 July 2019 (UTC)
- Keep We do not require property creators to resolve all points of discussion before creating a property - I'm grateful the creator finally got around to assessing this one and taking care of it. There's clearly a need for this property, and plenty of examples of how it would be used. ArthurPSmith (talk) 14:25, 6 July 2019 (UTC)
- Comment Unfortunately, ArthurPSmith changed the proposal after everybody else commented on it and we have no way to sort things out as we do usual. Let's recall the process: someone proposed a property, people support or oppose it, maybe comment to help improve it, then a property creator assesses the consensus and creates it. Nothing of that has been followed here. The property creator didn't even bother reading it. Let's start this correctly from zero and then decide it. --- Jura 14:34, 6 July 2019 (UTC)
- @Jura1: first your description of the situation is really incorrect. It does not seems premature (a lot of property are created more quickly, with less people participating and/or less favourable balance of pro vs. cons), please assume good faith of Pintoch, ArthurPSmith didn't change the proposal, he just changed the label and description in English from "Second family name in Scandinavian names" to "middle family name", this doesn't seem a very big change and we can still put back the previous label, no need to delete the property. Then, this is the pot calling the kettle black: you did the same thing (and even worse as datatype can't be change unlike the label, and more people disagreed with your creation) with P6712 (P6712). Cheers, VIGNERON (talk) 21:26, 6 July 2019 (UTC)
- This is to discuss the deletion request. Don't sidetrack the discussion about the nominator: not good VIGNERON. Don't lend people assumptions: not good VIGNERON. --- Jura 22:29, 6 July 2019 (UTC)
- @Jura1: first your description of the situation is really incorrect. It does not seems premature (a lot of property are created more quickly, with less people participating and/or less favourable balance of pro vs. cons), please assume good faith of Pintoch, ArthurPSmith didn't change the proposal, he just changed the label and description in English from "Second family name in Scandinavian names" to "middle family name", this doesn't seem a very big change and we can still put back the previous label, no need to delete the property. Then, this is the pot calling the kettle black: you did the same thing (and even worse as datatype can't be change unlike the label, and more people disagreed with your creation) with P6712 (P6712). Cheers, VIGNERON (talk) 21:26, 6 July 2019 (UTC)
- weak keep. Whoa this one is complicated. @1Veertje: Can you explain whether these middle family names are, in legal documents, given names or family names? And is the difference between Scandinavian middle family name (P6978) and second family name in Spanish name (P1950) that Scandinavian middle family name (P6978) is used before the main family name, while second family name in Spanish name (P1950) is used after the main family name? Deryck Chan (talk) 17:38, 16 July 2019 (UTC)
- they're a given name. It's not automatically the mother's maiden name: sometimes it's the family name of the godparent or a (local) notable person. Like middle names they are often abbreviated to just the letter. When the full name is written out they are before the family name. 1Veertje (talk) 17:50, 16 July 2019 (UTC)
- Keep The PFDer Jura1 has now somethings which match Japanese word "邪魔", such as insulting VIGNERON as confusing "not good XXX" for multiple times. --Liuxinyu970226 (talk) 14:48, 25 July 2019 (UTC)
- Keep These names are in legal documents given names (at least with respect to Norway). They can not be created into legal double last names. They comes after the given name, wich can consist of two names, and before the last name, who in general is only one "name" combinations of two names may however exist. But then generally in forms like Egede-Nissen. Example Johan Martin Rønning Tennøy can in formal use Johan Tennøy. And then Martin is his second given name Rønning his mothers last name and is middle Family name. Tennøy his last name. The middle Family name can not be transfered to the persons children or wife. Pmt (talk) 12:22, 10 August 2019 (UTC)
- Keep The scandinavian middle family name is pretty weird. It does not exist in legal terms, it is just a habit to get around the laws for how to build up the name. We use a given middle name as an additional family name. Without a specific field the additional family name will sip into the given name, which I believe would be bad. I belive Pmt is wrong about “They can not be created into legal double last names.” given navneloven §4 (7) and first part of “The middle Family name can not be transfered to the persons children or wife.” (4) There are a lot of exceptions, and this version of the law is from 2002. I'm not familiar with the earlier laws. Jeblad (talk) 13:14, 10 August 2019 (UTC)
- Keep This has been needed for a long time! I do not know the exact English definition of a "given name", so I will used the word "first name" here. In Norway the law quite clearly separates first names from family names. One can not choose a commonly used family name as the first name for your child, and a commonly used first name can not be used as a family name. Exceptions are made for foreign names, but there has to be proof of usage in the family. This means that more or less all names that end with -sen, -son, -berg, -rud, -stad, -øy, -land, etc. are simply illegal as first names. There are only very few first names that are also used as family names, and the best known is probably Magnus (from journalist Anders Magnus (Q11957889)). (I also have to mention that for us Norwegians the English naming traditions where a name can be both a first name and a family name are seriously confusing at times, since we are used to the strict rules.)
- One of the property examples, Tone Tveøy Strøm Gundersen (Q59643094), puzzle me a bit. Out of her four names, only Tone is a legal first name. Tveøy, Strøm and Gundersen are all strictly family names. So one can wonder if both Tveøy and Strøm are middle family names. Or if Tveøy is a middle family name, while Strøm Gundersen is a double family name. The current law (from 2002) apparently states that double family names should have a dash between them, but some sources say that it is not mandatory, so I guess it may have been different in earlier laws. I do not know the answer here, but I guess the example should be changed, as now it doesn't show as a good example. Bergenga (talk) 19:18, 10 August 2019 (UTC)
- 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, use LilyPond notation (P6883) instead. − Pintoch (talk) 07:49, 16 July 2019 (UTC)
P5482 (P5482): (delete | history | links | entity usage | logs)
Procedural nomination; all uses in the Item namespace have been migrated to LilyPond notation (P6883). Jc86035 (talk) 10:31, 8 July 2019 (UTC)
- Speedy delete No reason to keep, as the replacement property is created. --Liuxinyu970226 (talk) 21:22, 8 July 2019 (UTC)
- Delete ArthurPSmith (talk) 13:41, 9 July 2019 (UTC)
- Delete --DannyS712 (talk) 14:57, 9 July 2019 (UTC)
- Delete straightforward. --99of9 (talk) 03:05, 15 July 2019 (UTC)
- 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 − Pintoch (talk) 20:15, 16 August 2019 (UTC)
P5924 (P5924): (delete | history | links | entity usage | logs)
No reason for this property now that Fandom article ID (P6262) exists. —Trade (talk) 03:24, 23 July 2019 (UTC)
- Delete. Nomen ad hoc (talk) 06:50, 23 July 2019 (UTC).
- Delete. I copied all data to Fandom article ID (P6262). There were less only 71 uses, so it was quickly done. Robin van der Vliet (talk) (contribs) 22:08, 23 July 2019 (UTC)
- Delete Seems clear. ArthurPSmith (talk) 17:24, 24 July 2019 (UTC)
- Delete per nomination --DannyS712 (talk) 16:50, 25 July 2019 (UTC)
- Delete per nomination - Premeditated (talk) 07:56, 5 August 2019 (UTC)
- Delete if there were more uses (than 71), I'd have kept it. Wikis can move to another farm. --- Jura 14:39, 12 August 2019 (UTC)
- 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, moved to end grade (P7095) --MisterSynergy (talk) 14:22, 29 July 2019 (UTC)
P7082 (P7082): (delete | history | links | entity usage | logs)
Can we create this with another PID? I think it's confusing that start grade start grade (P7086) has a higher number --- Jura 07:28, 24 July 2019 (UTC)
- As it seems to be minor issue, I went ahead and moved it. --- Jura 05:31, 25 July 2019 (UTC)
- Speedy delete Creator's error. --Liuxinyu970226 (talk) 14:26, 25 July 2019 (UTC)
- Delete per Jura1 --DannyS712 (talk) 16:50, 25 July 2019 (UTC)
- 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.
- Done − Pintoch (talk) 08:36, 29 August 2019 (UTC)
P6085 (P6085): (delete | history | links | entity usage | logs)
Per ChristianKl and Dominic's comments at Wikidata:Property proposal/New York Times short URL, it might be better to either have a single property for unique short URLs, or to not have any special properties for short URLs at all. The property has, regardless, not seen any adoption aside from the three example values that I used in the property proposal form, so deleting it would not currently result in any significant loss of data. —Jc86035 (talk) 13:19, 7 January 2019 (UTC)
Notifying the other property proposal participants: Germartin1, Visite fortuitement prolongée, ArthurPSmith, MartinPoulter, eru, Pigsonthewing, Thierry Caro. Jc86035 (talk) 13:22, 7 January 2019 (UTC)
- No strong feelings on this. ArthurPSmith (talk) 15:18, 8 January 2019 (UTC)
- (Note: I created both property proposals. I forgot to mention this.) Jc86035 (talk) 17:22, 8 January 2019 (UTC)
*weak keep: all the Guardian articles fulfil a need. Probably thousands (?) of them have an online ID. So the property could be useful. Nomen ad hoc (talk) 21:51, 5 July 2019 (UTC).
- @Nomen ad hoc: On the other hand, it would be sort of pointless to do this for all original newspaper articles (assuming that those get imported at some point in the future), since we would then have thousands of properties just for newspapers instead of using full work available at URL (P953), and most of those article items (excluding those for AP/AFP/Reuters articles) would only use at most one identifier property. Jc86035 (talk) 07:29, 8 August 2019 (UTC)
- Delete URL are good enough to reference articles. Having the property means that we get plenty of other requests for properties for the articles of other newspapers that create additional work for property creation that's better spend dealing with already existing proposals. ChristianKl ❪✉❫ 10:10, 8 August 2019 (UTC)
- Delete Convinced by Jc & Christian. Nomen ad hoc (talk) 09:26, 9 August 2019 (UTC).
- 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.
- Done − Pintoch (talk) 08:37, 23 August 2019 (UTC)
P4828 (P4828): (delete | history | links | entity usage | logs)
Per Topic:V2ux3hpbf5ofitqw: isn't a real ID. No further need of a such property. Nomen ad hoc (talk) 14:44, 5 July 2019 (UTC). —Nomen ad hoc (talk) 14:44, 5 July 2019 (UTC)
Ayack
Ash Crow
Tubezlob
PAC2
Thierry Caro
Pymouss
Alphos
GAllegre
Jean-Frédéric
Manu1400
Marianne Casamance
Nattes à chat
Pierre André
Bouzinac
Jsamwrites
Baidax
LearnKnowGive1
Mathieu Kappler
Daieuxetdailleurs
Archives nationales DJI
Jmax
LearnKnowGive1
Koxinga
Maxime
Framawiki
Legonin
- Delete per request. Nomen ad hoc (talk) 21:46, 5 July 2019 (UTC).
- Delete − Pintoch (talk) 08:33, 6 July 2019 (UTC)
- Delete --Deansfa (talk) 15:15, 6 July 2019 (UTC)
- Delete Jean-Fred (talk) 16:50, 6 July 2019 (UTC)
- Delete --DannyS712 (talk) 14:56, 9 July 2019 (UTC)
So could any admin please delete this? Nomen ad hoc (talk) 12:35, 10 August 2019 (UTC).
- It's still used on many items, the existing claims must be removed first. -Ash Crow (talk) 09:23, 14 August 2019 (UTC)
- OK; I thought it didn't matter. I've opened a bot request. Nomen ad hoc (talk) 10:58, 14 August 2019 (UTC).
Right now the item is not used anymore, so the deletion can be performed? 82.19.127.189 06:56, 19 August 2019 (UTC)
has part(s) (P527): (delete | history | links | entity usage | logs | discussion)
Seems redundant with part of (P361), until I see no real need of a reverse property. A SPARQL request would certainly serve this purpose instead. —Nomen ad hoc (talk) 17:14, 28 August 2019 (UTC)
- Keep They are not strict inverses. See Help:Basic membership properties for some background on this. There are also cases where one direction is more sensible than the other (an item could be "part of" many other things - for the element hydrogen is "part of" almost every organic molecule, so the inverse "has part" (or "has parts of the class") is the better relation). ArthurPSmith (talk) 18:21, 28 August 2019 (UTC)
- Keep; we cannot query from Lua modules, thus redundancies like this one are often necessary. --MisterSynergy (talk) 18:30, 28 August 2019 (UTC)
- Keep It's not redundant. It's possible that 1000 items have "has part" QXXXXXXX with the same QXXXXXXX and there we don't want to have a list with 1000 part of statements. ChristianKl ❪✉❫ 11:33, 29 August 2019 (UTC)
- Keep I use this one a lot for the three parts of a triptych (Q79218) and in some other cases. Our data set is curated, we the editors choose if adding something like this is sensible. Shouldn't be added everywhere. Multichill (talk) 18:21, 2 September 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Nomen ad hoc (talk) 18:37, 2 September 2019 (UTC) |
- 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 − Pintoch (talk) 10:46, 12 September 2019 (UTC)
P7158 (P7158): (delete | history | links | entity usage | logs)
Mostly a search string to a webshop. https://merlin.pl/a/millennium/ shows that it's not a trustworthy authority for identification. What's claimed to be an artist is mix of things, mostly a publisher. Jagulin (talk) 19:32, 26 August 2019 (UTC)
- @Eurohunter:@ديفيد عادل وهبة خليل 2, Trade: I'm sure you want to have a say too. The recent proposal may have given the impression that merlin.pl is an authority naming authors, but to me it looks just like any web shop api searching for keywords. Examples metallica shows that it's not authors, nor persons and millennium indicates that it's not always identifying a single entity. I suggest this ID to be dropped before it gains more use. Then again, if there's a rule saying that all webshop api keys are notable for use in WD I guess that's the argument where I suggest the use of external data available at URL (P1325) rather than having specific properties for each site. Jagulin (talk) 20:16, 26 August 2019 (UTC)
- Delete Didn't realize it was a webshop until now. I though it was database. --Trade (talk) 21:31, 4 September 2019 (UTC)
- Somehow it recognise given name belong to artist, author or direcitor. Eurohunter (talk) 20:24, 26 August 2019 (UTC)
- Delete search string for webshop, nothing but spam.--Jklamo (talk) 09:49, 29 August 2019 (UTC)
- @Jklamo: Read my comment above. Prove it isn't id. Eurohunter (talk) 18:16, 29 August 2019 (UTC)
- @Eurohunter: https://merlin.pl/a/millennium/ shows that it's not a trustworthy authority for identification. If it's an ID or not is to me not the question. The question is: What value will this property bring to Wikidata? Can you help explain that again? Jagulin (talk) 01:37, 2 September 2019 (UTC)
- @Jklamo: Read my comment above. Prove it isn't id. Eurohunter (talk) 18:16, 29 August 2019 (UTC)
- Delete Already fall under AbuseFilter in some Wikipedias. --Liuxinyu970226 (talk) 08:08, 4 September 2019 (UTC)
- Delete Robin van der Vliet (talk) (contribs) 09:50, 11 September 2019 (UTC)
- 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, as this request clearly wasn't meant to contest the property. There was some vandalism which I reverted, and that's it. --MisterSynergy (talk) 09:11, 4 September 2019 (UTC)
image of function (P2396): (delete | history | links | entity usage | logs | discussion)
Repeated advertisement about himself, he was warned multiple times on Commons and bnwiki. Also via email. I'd recommend blocking the user. ~ Nahid Talk 08:36, 4 September 2019 (UTC)
- 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 (was: "analog or derivative of", property proposal: Wikidata:Property proposal/Analog or derivative of) − Pintoch (talk) 06:15, 22 October 2019 (UTC)
P5000 (P5000): (delete | history | links | entity usage | logs)
Property represents analogue (Q50824047) which is ambiguous and inaccurate and so it's incorrect from a chemistry perspective. It mixes different concepts of functional analog, structural analog, derivative and molecular similarity and some others; concepts that are neither synonymous nor similar, concepts that shouldn't be equated with each other. Problem of chemical classification is one of the most important and most challenging in WD's chemistry scope, but Wikiproject Chemistry hasn't been notified about this proposal and I found this property by accident. Fortunately, there is only one use of this property.
This property should be deleted as it's incorrect and importing data from the indicated sources can lead to addition of a huge collection of chaotic and inaccurate data. Discussion about chemical classification should be continued in Wikiproject Chemistry and such bypass solutions should not be created.
Leyo
Snipre
Dcirovic
Walkerma
Egon Willighagen
Denise Slenter
Daniel Mietchen
Kopiersperre
Emily Temple-Wood
Pablo Busatto (Almondega)
Antony Williams (EPA)
TomT0m
Wostr
Devon Fyson
User:DePiep
User:DavRosen
Benjaminabel
99of9
Kubaello
Fractaler
Sebotic
Netha
Hugo
Samuel Clark
Tris T7
Leiem
Christianhauck
SCIdude
Binter
Photocyte
Robert Giessmann
Cord Wiljes
Adriano Rutz
Jonathan Bisson
GrndStt
Ameisenigel
Charles Tapley Hoyt
ChemHobby
Peter Murray-Rust
Erfurth
TiagoLubiana
NadirSH
Matthias M.
S8321414
- Keep I see it is useful and has no problem.The description can be improved David (talk) 14:03, 23 September 2018 (UTC)
- Could you explain how this property is useful? Wostr (talk) 14:42, 23 September 2018 (UTC)
- I have to ping you, David, as I would like to know the answer or some argument for keeping this property. Especially in the light of my comment of September 24 (below, the long one beginning with I'm not sure), in which I pointed out major problems with the sources that were to be used to populate this property. Wostr (talk) 20:34, 12 November 2018 (UTC)
- I understand your concern. Do you have any plans to create more specific properties replacing this property? Or should we force this property to be used with a qualifier of object of statement has role (P3831) (Q25205085, structural analog (Q485014), Substrate analog (Q7632163), or Transition state analog (Q17087414))? Actually, the term "analog" is used ambiguously in molecular biology and in medicine, such as nucleic acid analogue (Q15057699) and insulin analog (Q742283). Also, I'd like to hear what is the chemically correct relationships between 2-chlorodiazepam (Q15408412) and diazepam (Q210402), or between fexofenadine hydrochloride (Q27255526) and fexofenadine (Q415122). Regards, --Okkn (talk) 09:10, 24 September 2018 (UTC)
- I'm not sure that properties are needed here at all. We had in Wikiproject Chemistry some initial discussions about chemical classification (e.g. here), but these discussions are not finished, as we in WP Chemistry have a lot to do before this (e.g. determining what we already have in WD and cleaning up after mass bot imports). From my POV the basic chemical classification should be based on classes of chemical compounds using instance of/subclass of (e.g. diazepam has a benzodiazepine, chloroaromatic classes; these classes are subclasses of more general classes etc.; this way diazepam and 2-chlorodiazepam are a member of the same classes). But this is my POV that has not been accepted (as any other) to be used in WD; and that's not the only option that can be present in WD. With the analogs, derivatives and so on there are IMHO too many problems: one can say that 2-chlorodiazepam is an analogue of diazepam, but there are really no clear and objective boundaries – methanol is an analog of methane? one can say that; diazepam is a structural analog of methane? some may argue that this is also true, really, I had that kind of discussions in pl.wiki, because we have 'derivatives' and 'similar compounds' parameteres in infoboxes...
The problem here is also that we would have several thousands of statements imported to WD and that's it. Many users like to import data to WD, but no one likes to curate that data, no one is checking whether imported data is correct or not. And in this case it would certainly be incorrect: just look what is the purpose of 'analogs & derivatives' in MeSH: It is used when the specific chemical heading is not available and no appropriate group heading exists i.e. it is used where there is no chemical class to be used for classification, so this is a kind of a substitute property, a replacement for something that is missing right now. ChEBI 'functional parent' have more sense (A has_functional_parent B if and only if given any a, a instantiates A , has molecular graph ag and a obo: has_part some functional group fg, then there is some b such that b instantiates B, has molecular graph bg and has functional group fg’ such that bg is the result of a graph transformation process on ag resulting in the conversion of fg into fg'.), but I don't think that such relationships are needed in WD, at least not right now.
My point is that: classification should be thoroughly discussed first and there should not be mass imports before that, because there are always people who wants to import something (no matter if this is correct or not), but there are no volunteers for cleaning this up. Wostr (talk) 14:06, 24 September 2018 (UTC)- I agree that before mass imports we have to discuss about this matter. I don't think P5000 (P5000) is the best solution, but a link from 2-chlorodiazepam (Q15408412) to diazepam (Q210402), in some way, is needed, isn't it? --Okkn (talk) 14:56, 24 September 2018 (UTC)
- Not necessarily a direct link between these two. It depends on the information we want to have in WD. For some uses, having these two items in one class would be sufficient, but there may be other uses in which there is a need to directly link these items — but we have to know why we have to link these items and how it would work for all the compounds in WD, i.e. what is the purpose and what is the intended result. For example, I think there should be some way for linking compounds used as a medicine (active ingredients) with their salts used in consumer products. But how to do this properly, e.g. which item should be linked from a Zolpimist (Q47522357)? zolpidem (Q218842) or zolpidem tartrate (Q27108595)? how to indicate the relation between these three items? Right now we have thousands of cases like that – cases resulted from mass import of data without any thought about proper linking between items – and zolpidem tartrate (Q27108595) is an active ingredient of Edluar (Q47521529) without any link to zolpidem (Q218842) (so without any link to the data about the active ingredient) and with Zolpimist (Q47522357) the situation is the opposite. We already have some properties for linking different compounds based on precise criteria: stereoisomer of (P3364), hydrated form of (P4770); we already have some classes being a mix of chemical and pharmacological classification, e.g. oxazolidinone antibiotic (Q55659933) (being a reflection of MeSH classification), that can be used for classification of biologically active compounds (but should it be used? I don't know which option for classification should be better). So thinking and discussion first (what we want to have and how to accomplish it), action then; not the opposite. Wostr (talk) 16:24, 24 September 2018 (UTC)
- I had noticed the issues on active ingredient (see User talk:ProteinBoxBot#Active ingredient). --Okkn (talk) 16:47, 24 September 2018 (UTC)
- @Okkn: For the relation between fexofenadine hydrochloride (Q27255526) and fexofenadine (Q415122) we can create a property " is a salt derivatve of". For 2-chlorodiazepam (Q15408412) and diazepam (Q210402), en:WP says that 2-chlorodiazepam (Q15408412) is a functional analog of diazepam (Q210402) but the definition of functional analog is not clear (can be structural or not) so this can be everything. Science requires better definition than that. Snipre (talk) 23:35, 7 October 2018 (UTC)
- I had noticed the issues on active ingredient (see User talk:ProteinBoxBot#Active ingredient). --Okkn (talk) 16:47, 24 September 2018 (UTC)
- Not necessarily a direct link between these two. It depends on the information we want to have in WD. For some uses, having these two items in one class would be sufficient, but there may be other uses in which there is a need to directly link these items — but we have to know why we have to link these items and how it would work for all the compounds in WD, i.e. what is the purpose and what is the intended result. For example, I think there should be some way for linking compounds used as a medicine (active ingredients) with their salts used in consumer products. But how to do this properly, e.g. which item should be linked from a Zolpimist (Q47522357)? zolpidem (Q218842) or zolpidem tartrate (Q27108595)? how to indicate the relation between these three items? Right now we have thousands of cases like that – cases resulted from mass import of data without any thought about proper linking between items – and zolpidem tartrate (Q27108595) is an active ingredient of Edluar (Q47521529) without any link to zolpidem (Q218842) (so without any link to the data about the active ingredient) and with Zolpimist (Q47522357) the situation is the opposite. We already have some properties for linking different compounds based on precise criteria: stereoisomer of (P3364), hydrated form of (P4770); we already have some classes being a mix of chemical and pharmacological classification, e.g. oxazolidinone antibiotic (Q55659933) (being a reflection of MeSH classification), that can be used for classification of biologically active compounds (but should it be used? I don't know which option for classification should be better). So thinking and discussion first (what we want to have and how to accomplish it), action then; not the opposite. Wostr (talk) 16:24, 24 September 2018 (UTC)
- I agree that before mass imports we have to discuss about this matter. I don't think P5000 (P5000) is the best solution, but a link from 2-chlorodiazepam (Q15408412) to diazepam (Q210402), in some way, is needed, isn't it? --Okkn (talk) 14:56, 24 September 2018 (UTC)
- I'm not sure that properties are needed here at all. We had in Wikiproject Chemistry some initial discussions about chemical classification (e.g. here), but these discussions are not finished, as we in WP Chemistry have a lot to do before this (e.g. determining what we already have in WD and cleaning up after mass bot imports). From my POV the basic chemical classification should be based on classes of chemical compounds using instance of/subclass of (e.g. diazepam has a benzodiazepine, chloroaromatic classes; these classes are subclasses of more general classes etc.; this way diazepam and 2-chlorodiazepam are a member of the same classes). But this is my POV that has not been accepted (as any other) to be used in WD; and that's not the only option that can be present in WD. With the analogs, derivatives and so on there are IMHO too many problems: one can say that 2-chlorodiazepam is an analogue of diazepam, but there are really no clear and objective boundaries – methanol is an analog of methane? one can say that; diazepam is a structural analog of methane? some may argue that this is also true, really, I had that kind of discussions in pl.wiki, because we have 'derivatives' and 'similar compounds' parameteres in infoboxes...
- I understand that a property like this makes interesting browsing, but I think it can be done differently. I agree with the point that analog and derivative are not so well defined, but my worries stems particularly from the fact that it is unbound and will lead to many links between chemical structures. I'm slightly in favor of removing. --Egon Willighagen (talk) 16:45, 25 September 2018 (UTC)
- Delete or at least rename based on a more specific relation. We already discussed the problem in WikiProject Chemistry and only relations based on a clear definition have to be used. Snipre (talk) 23:18, 7 October 2018 (UTC)
- Delete We do need better chemical relationship properties, but they need to be extremely clearly defined. --99of9 (talk) 01:06, 10 July 2019 (UTC)
- Given that this has only 3 uses currently, I think it's save to throw out the existing usages and rename the property into a more specific one (and not let the nice P5000 go to waste). I propose to go for "structural analog" here. ChristianKl ❪✉❫ 10:22, 8 August 2019 (UTC)
- I think that this property should be deleted a long time ago. This discussion is open for more than a year, most comments are in favor of deleting, the only comment to keep this property (BTW from a person with no particular interest in chemistry and who votes for creating every property and for keeping every property) lacks any arguments, even after I asked twice. I'm regularly deleting incorrect uses of this property, because it is used incorrectly in many fields (fortunately not in chemistry). Wostr (talk) 23:56, 14 October 2019 (UTC)
- Delete I also agree with a instance/subclass hierarchy which is already realized in ChEBI (they even get by with usage of is-a, only). --SCIdude (talk) 15:25, 16 October 2019 (UTC)
- 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 − Pintoch (talk) 06:06, 22 October 2019 (UTC)
Google+ ID (P2847): (delete | history | links | entity usage | logs | discussion) Google+ no longer exists. —37.42.13.167 02:00, 24 September 2019 (UTC)
- Keep Items point to Wayback Machine (formatter URL (P1630) has been changed), so this property is used on WD and also by other wikis… quite simply. —Eihel (talk) 04:49, 24 September 2019 (UTC)
- Keep There are archived copies of Google+ pages. Robin van der Vliet (talk) (contribs) 13:19, 24 September 2019 (UTC)
- Keep per the above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:39, 27 September 2019 (UTC)
- 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 (was: "GINCO ID") − Pintoch (talk) 09:32, 12 November 2019 (UTC)
P3905 (P3905): (delete | history | links | entity usage | logs)
This property is covered by 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) and I think it is better to have those seperate. —Lymantria (talk) 13:19, 19 November 2018 (UTC)
@Zolo, Shonagon, VIGNERON, Pigsonthewing, Gzen92, ChristianKl: Pinging those involved in the discussion on the property proposal of P3905 (P3905). Lymantria (talk) 12:06, 10 December 2018 (UTC)
- @Lymantria: could we have some more in-depth explanations? I think it's better to have one property for one database on one website. Just because this database has subparts means we need to have differents property (see. IMDb ID (P345) for an other example of a database with subparts). Plus, if we would use 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), then some fixing seems to be needed (I fixed the formatter URL (P1630) already). Also @Ayack: who did the proposal for P4979 and P4980 (who were accepted with only 2 votes each). Cheers, VIGNERON (talk) 12:49, 10 December 2018 (UTC)
- The main reason I think that it is better to have two seperate properties, is that for instance balcony (Q170552) has an entry in both and now yields a constraint violation for P3905 (P3905). Lymantria (talk) 13:11, 10 December 2018 (UTC)
- Oh, good point, thanks Lymantria. Is there a lot of case like that? by design, there should be few so they could easily be dealt with exceptions on the constraint (like I did Special:Diff/809146141), but if there is a lot (more than 10% of the total?) then indeed we should maybe have separate properties. @Ayack: signaled me that there is indeed a problem with the identifiers for P4979 and P4980 (what I thought was a fix caused some problems…), does someone has more informations (or even better specifications) on how this database(s) works? Cdlt, VIGNERON (talk) 15:06, 10 December 2018 (UTC)
- I have not really investigated if there are many of those cases, but I assume less than 10%. Still, the property now combines two thesauruses, which I think is not wise. Lymantria (talk) 17:34, 10 December 2018 (UTC)
- Oh, good point, thanks Lymantria. Is there a lot of case like that? by design, there should be few so they could easily be dealt with exceptions on the constraint (like I did Special:Diff/809146141), but if there is a lot (more than 10% of the total?) then indeed we should maybe have separate properties. @Ayack: signaled me that there is indeed a problem with the identifiers for P4979 and P4980 (what I thought was a fix caused some problems…), does someone has more informations (or even better specifications) on how this database(s) works? Cdlt, VIGNERON (talk) 15:06, 10 December 2018 (UTC)
- The main reason I think that it is better to have two seperate properties, is that for instance balcony (Q170552) has an entry in both and now yields a constraint violation for P3905 (P3905). Lymantria (talk) 13:11, 10 December 2018 (UTC)
- Delete @Lymantria: @VIGNERON: GINCO is an application (of the French Ministry of Culture), not a website, not a database, and not a single thesaurus. So indeed "identifiant GINCO" does not make sense. What would make sense could be "identifiant of the French Ministry of Culture", but that does not give much information either. So indeed having separate properties for separate thesaurus is more appropriate. Tfrancart (talk) 09:03, 4 November 2019 (UTC)
- Comment based on the explanations given, I'd delete either the above or the two other ones. --- Jura 06:14, 20 December 2018 (UTC)
- 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 this property, which I have marked as a subproperty of depicts (P180) per Spinster's suggestion. In short, this distinction is useful (at least) to draw the line between creative depictions of a work of art, which can be subject to copyright on their own, and faithful digitizations of works, where no creative choice is involved, which can be treated differently for copyright purposes. The copyright status of the work can also be represented separately. − Pintoch (talk) 10:56, 17 November 2019 (UTC)
digital representation of (P6243): (delete | history | links | entity usage | logs | discussion)
As far as I can tell, this property duplicates depicts (P180) within the context of Structured Data on Commons for the subtopic of digital reproductions. Despite what the property proposal said, commons:Template:Artwork should use depicts (P180)=Mona Lisa (Q12418) to replace the "wikidata=" parameter, and then fetch the depicts (P180) values from Mona Lisa (Q12418) to explain what the artwork depicts. It may need to use the 'preferred' rank to do that in cases where the image also depicts other things, such as the frame of the artwock, but that's technically straightforward to do. Note that I previously nominated this for deletion, which I withdrew as I thought it was only in use for copyright purposes (i.e., to auto-include commons:Template:PD-art on Commons), but further discussion seems to indicate that this is not the case. Thanks. Mike Peel (talk) 19:35, 20 September 2019 (UTC)
WikiProject sum of all paintings has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. Mike Peel (talk) 19:39, 20 September 2019 (UTC)
Pinging editors that participated in the property proposal. @Jarekt, ArthurPSmith, Multichill, Jheald, Jura1, Spinster: Mike Peel (talk) 19:42, 20 September 2019 (UTC)
Pinging editors that commented on the previous property deletion discussion, @Jdforrester, Emijrp, Jklamo, Jane023:, and those at Property talk:P6243, @Dominic, Tacsipacsi, Hannolans, Lokal Profil:, plus @SandraF (WMF), Keegan (WMF): from SDC. Thanks. Mike Peel (talk) 19:47, 20 September 2019 (UTC)
- Delete Convinced by Mike. Nomen ad hoc (talk) 19:38, 20 September 2019 (UTC).
- Comment I'm feeling very conflicted about this one. After giving it some thought, I'm much more in favor of 'clean' and separate copyright modeling as suggested by User:Lokal Profil on the property's talk page, mainly because that solution provides much more consistency in copyright modeling and provides more clear information to people unfamiliar with Wikimedia Commons policies (i.e. the majority of people out there). That said, faithful two-dimensional digital representations of two-dimensional documents and artworks (aka 'digital surrogates') are a special category of files, that would benefit from being clearly distinguishable as such. I'd be interested to hear input from experts familiar with this issue in GLAM data modeling whether a separate property indeed would make sense. I'll ask around and will post updates here when I succeed in receiving some feedback. Spinster 💬 20:07, 20 September 2019 (UTC)
- Agree that we should not use this property for copyright hamndling. Files should have their own copyright status handling. What we want to know of a file in commons is if there is a artistic influence of the photographer and thus a claim for copyright or just a reproduction of an existing work (either PD or CC). As this evaluation differs per legislation and has several edge cases we should nog use this property for copyright related issues. Wha we would like to know of a file is that it is a 1:1 of the seizes of the artwork --Hannolans (talk) 09:03, 21 September 2019 (UTC)
- Keep When a cultural institution scans a historical document to make an exact digital reproduction of it, this relationship between the object and the media file is different in nature from what is described when anything displayed in the image can be added in a "depicts" statement. Absent further explanation, I don't understand the suggestion that a faithful digital representation is the same as a depiction. Dominic (talk) 20:02, 20 September 2019 (UTC)
- And what to do if I make a picture of a work? And if I brighten the work? Or is this property for scans created following official ISO standards for scanning museum objects? But can't we derive that from the EXIF data? --Hannolans (talk) 20:13, 20 September 2019 (UTC)
- I agree those questions should have answers. I think what you are suggesting here are reasons for clearly defining a property's scope, but I don't see how deletion is a solution. Dominic (talk) 20:20, 20 September 2019 (UTC)
- The scope should definetely change to keep this porperty. --Hannolans (talk) 11:24, 22 September 2019 (UTC)
- I agree those questions should have answers. I think what you are suggesting here are reasons for clearly defining a property's scope, but I don't see how deletion is a solution. Dominic (talk) 20:20, 20 September 2019 (UTC)
- @Dominic: Scans of documents are a different case, which this property as-is doesn't seem to address. Thanks. Mike Peel (talk) 20:34, 20 September 2019 (UTC)
- If you want to replace "document" for "artwork" in my first comment, I am not sure how that changes the point. A depiction is not the same as a digitization. Or, at least, I think you have an obligation to at least attempt to explain why you are calling these redundant, since I don't see that you have. Dominic (talk) 21:03, 20 September 2019 (UTC)
- @Dominic: Can you give an example, please? The ones in the property proposal and documentation don't match this use case. Thanks. Mike Peel (talk) 21:10, 20 September 2019 (UTC)
- @Mike Peel: I am pointing out that there is a substantive semantic difference between a "faithful digitized representation" of the Mona Lisa and a work that in some way "depicts" the Mona Lisa. I think the burden is supposed to be on you to make an argument. From what I understand of your proposal, you seem a bit confused about the purpose of the property in the first place. Dominic (talk) 21:17, 20 September 2019 (UTC)
- @Dominic: Can you explain how the current property makes that difference, please? I can't see it myself, beyond the ranking of the depicts statement. I am "confused about the purpose of the property in the first place"! Mike Peel (talk) 21:51, 20 September 2019 (UTC)
- The words do not mean the same thing. What are you even asking for here? Dominic (talk) 21:58, 20 September 2019 (UTC)
- @Dominic: The words and the usage don't match. I'm asking for this property to either be deleted, or for its usage to be made significantly clearer. Thanks. Mike Peel (talk) 22:09, 20 September 2019 (UTC)
- The words do not mean the same thing. What are you even asking for here? Dominic (talk) 21:58, 20 September 2019 (UTC)
- @Dominic: Can you explain how the current property makes that difference, please? I can't see it myself, beyond the ranking of the depicts statement. I am "confused about the purpose of the property in the first place"! Mike Peel (talk) 21:51, 20 September 2019 (UTC)
- @Mike Peel: I am pointing out that there is a substantive semantic difference between a "faithful digitized representation" of the Mona Lisa and a work that in some way "depicts" the Mona Lisa. I think the burden is supposed to be on you to make an argument. From what I understand of your proposal, you seem a bit confused about the purpose of the property in the first place. Dominic (talk) 21:17, 20 September 2019 (UTC)
- @Dominic: Can you give an example, please? The ones in the property proposal and documentation don't match this use case. Thanks. Mike Peel (talk) 21:10, 20 September 2019 (UTC)
- If you want to replace "document" for "artwork" in my first comment, I am not sure how that changes the point. A depiction is not the same as a digitization. Or, at least, I think you have an obligation to at least attempt to explain why you are calling these redundant, since I don't see that you have. Dominic (talk) 21:03, 20 September 2019 (UTC)
- And what to do if I make a picture of a work? And if I brighten the work? Or is this property for scans created following official ISO standards for scanning museum objects? But can't we derive that from the EXIF data? --Hannolans (talk) 20:13, 20 September 2019 (UTC)
- Comment My understanding has been that the difference between depicts (P180) and digital representation of (P6243) is something like:
--Stevenliuyi (talk) 23:27, 20 September 2019 (UTC)
- Broadly agree. IMO the image on the right of "Starry Night", including frame, and taken from a slightly oblique angle, should not have a digital representation of (P6243) statement, but should have depicts (P180) = The Starry Night (Q45585) at preferred level.
- In the case of the Mona Lisa, only the Wikidata item Mona Lisa (Q12418) should have depicts (P180) = person depicted in Mona Lisa (Q11879536). IMO, the fact should not be in the structured data for the image itself, the fact should be inherited from Wikidata if the image has a digital representation of (P6243) or depicts (P180) statement pointing to Q12418. (This is the "depicts of depicts" functionality, which should be arriving for display and for search some time soon).
- It's a slightly open question for me, how much "retouching" of an image should be allowable, and it still to be appropriate to use P6243. For example, an image of the Mona Lisa with colours digitally adjusted to how it might have looked at the time of Leonardo IMO probably should not carry a digital representation of (P6243) statement -- but it would be useful to know what others think on this. Jheald (talk) 17:19, 21 September 2019 (UTC)
- Comment My understanding is that P180 must have an associated Wikidata item that represents the thing that depicts. On Commons, use of P180 is only possible because other Wikidata items than the Commons file have depicted the thing selected. In this case, there may not be any associated Wikidata item except for the thing this file is a digital representation of. Because of the overwhelming majority of such cases on Commons I find this property highly useful. It gives Commons people at least an indication that the file shows the whole thing described by the associated Wikidata item, albeit in some old sepia print. This is useful in the case of photos of e.g. old paintings before theft,loss by fire, restoration etc, and e.g. buildings before expansion or demolition. These properties are by no means related in my view. Jane023 (talk) 06:19, 21 September 2019 (UTC)
- But then we should rename this porperty. 'digital representation' could also mean the best colors etc, but that is not the case. Instead we could use a definition that states that the file covers exactly the dimensions of the artwork ('the whole thing described by the associated Wikidata item'). It would also mean that it is not only for 2d works, but also for songs and movies that covers exactly the whole movie and the whole song, and 3D files of monuments, that covers exactly that monument. --Hannolans (talk) 09:08, 21 September 2019 (UTC)
- Keep great people. Barely anyone is participating in the discussion to set up structured data on Commons modeling, but instead time is wasted on sabotaging the work already done. You're basically rehashing the discussions of When to use the PD-Art tag and When to use the PD-scan tag. Multichill (talk) 08:49, 21 September 2019 (UTC)
- Keep Per Multichill - Premeditated (talk) 09:12, 21 September 2019 (UTC)
- Confused as that discussion about is about 'When to use the PD-scan tag' is about the 'level of originality'. We should not use this property for evaluation of 'originality' as we now have Property:P6216 both for the file in commons as for depicts (P180) on Wikidata with qualifiers about the copyright evaluation. We could use this property when the dimensional overlap between the image and the object is 1:1. I think we have this discussion because this property is currently meant for copyright evalaution as well as 'is a scan of' --Hannolans (talk) 09:18, 21 September 2019 (UTC)
- Comment This is probably the first Commons-only property. As such, I think it should ultimately be determined on Commons if and how it should be used.
Still, the use should somewhat be consistent with the label and initial description of the property here on Wikidata.
If use should be limit to "copyright status" or "PD-copyright status" of the 2D artwork photographed or scanned, it should be labelled differently, meaning a property with a different label should be created and this deleted.
Occasionally creating items for c:Category:Paintings_without_Wikidata_item, I think use of such items goes beyond that. Otherwise, I'd probably not bother creating them. Not really convinced that including that item in P180 would be helpful, but it seems that currently much of Commons modeling is limited to that. --- Jura 09:39, 21 September 2019 (UTC)
- Comment if used for prints I am even more confused. For prints and books we have the individual copy in an archive, and the 'master'. Probably thia property should link to the individual copy of that particular archive, and depicts should link to the master? I did so for this map. I added digital representation of (P6243) -> Map Figurative Delft Second state inv.nr.65854 (Q64579998) and depicts (P180) -> Map figurative second state (Q64579843). Should that be the correct use for prints and books? That would mean we should only use digital representation of (P6243) if we have an item about that individual copy of that print or book page in wikidata, and depicts otherwise? --Hannolans (talk) 09:49, 21 September 2019 (UTC)
- @Hannolans: It's a good question. A related one is: what sort of items should one be creating on Wikidata? In particular, if one wants to create an item on Wikidata corresponding to a map that one has a digitisation of, should one be creating an item that is instance of (P31) map edition (Q56753859) or one that is instance of (P31) individual copy of a map (Q63872468) ? I flip-flop backwards and forwards a bit on this question; but (unless there is important provenance information to record), my yardstick would be whether there are likely to be visible differences between different exemplars of the edition. If eg a particular map has hand-colouring, it may make sense to have its own item (and then for the image to be digital representation of (P6243) of that). But if the map is simply as printed, with nothing to apparently difference it from any other copy, then it may make sense to make a Wikidata item for the whole map edition (Q56753859) (and in such a case I think it would still make sense to use P6243, to indicate that the image is a representative digital representation of the whole map edition). Where I don't think one can use P6243 is if the map has hand-colouring that is specific to the individual copy, rather than the edition. Then I think the image is presenting something more that just a representative of the edition, and it probably makes sense to create a Wikidata item for the individual object (which is always a safe fall-back). Also, a particular identifiable state of a map or engraving should usually have its own Wikidata item, as it will correspond to an edition in its own right. A marginal case is where a map from an edition might have acquired particular stains, or perhaps a visible library ownership stamp. In such a case I believe it would be reasonable to regard such marks as not of particular consequence, and it would be acceptable to describe the image as just a generic representation of the edition; but on the other hand I wouldn't object or nominate the item for deletion, if somebody created a distinct Wikidata item for it. But it would be useful to know whether this conforms to what other people think and/or are doing in this area. Jheald (talk) 16:57, 21 September 2019 (UTC)
- Every print in each museum is very unique. For digital representations as meant in this property I would be oppose to use this proprty for the concept and only use depicts. At the other hand, we could also use this property for manifestations of a concept. See the examples below --Hannolans (talk) 11:24, 22 September 2019 (UTC)
-
File:Google 2015 logo.svg digital representation of (P6243) -> Google logo (Q1764530)
-
File:Google 2015 logo.svg digital representation of (P6243) -> Rijkslogo (Q2315224)
-
File:Great coat of arms of Belgium.svg -> digital representation of (P6243) -> coat of arms of Belgium (Q199614)
- Keep Because I suspect people are going to want to search for files that are digital representations of (classes of) artworks, rather than just files depicting them; having this property will make such searches far more efficient -- I suspect that just relying on depicts and then filtering would be likely to make corresponding SPARQL queries time out.
- This property has a very specific meaning: it means that an image shows the whole of an 2D art object, all of it, faithfully, directly square-on, and nothing but the 2D art object (ie no frame, no adjacent wall, no surrounding gallery, no other work, etc). It's quite a common situation, encompassing eg works covered by the
{{PD-Art}}
tag (cf c:Commons:When_to_use_the_PD-Art_tag), with approaching 1.4 million transclusions; though of course that's only about 3% of Commons images. It is useful to have this property, to designate that an image has this nature. - I do not regard the property as a substitute for systematic standard copyright statements -- those should be present too. But in my view the fact that the image is a direct faithful representation of a particular 2d artwork is worth stating in its own right. It is also worth pointing out that the statement may apply in a few cases where
{{PD-Art}}
does not apply -- for example a faithful representation of an artwork that is still in copyright, but which has been released by the creator. P6243 is appropriate in this case too. - I am neutral as to whether an image should also have a parallel P180 statement. Ideally when "depicts of depicts" is implemented for search and display etc, statements would be inheritable via P6243 as well. That would make any parallel P180 statement redundant, but mostly harmless.
- So, overall, keep -- to make it easier to extract images which are faithful reproductions; and also to facilitate the workflow for such images, and to facilitate automatic checking (eg constraint checking) of statements on them (eg copyright statements) against data from the indicated wikidata item. Jheald (talk) 16:32, 21 September 2019 (UTC)
- @Jheald: Would it be possible to do a query for cases where there is only one depicts statement? E.g., to find cases where depicts (P180)=Mona Lisa (Q12418) that don't also have other depicts statements like depicts (P180)=picture frame (Q860792). I really don't like the data duplication inherent in this property (similar to P373!), nor the fact that it's somehow separate from P180. Another option might be a qualifier on P180 to say "is a faithful reproduction", which might also be easy to query? Thanks. Mike Peel (talk) 10:57, 28 September 2019 (UTC)
- May it be solved by putting digital representation of (P6243)→subproperty of (P1647)→depicts (P180)? and then you avoid to use depicts (P180) if the value is already set with digital representation of (P6243). Will the Structured Data searching tools works with that? if yes that would be great. Christian Ferrer (talk) 18:46, 21 September 2019 (UTC)
- @Christian Ferrer: That would probably work, but would be an extra layer of abstraction/coding. Why not just use P180? Thanks. Mike Peel (talk) 10:57, 28 September 2019 (UTC)
- @Mike Peel: Is it not related to the copyrights of the depicted artworks? Christian Ferrer (talk) 20:48, 28 September 2019 (UTC)
- @Christian Ferrer: That's what I thought, but see what I wrote in the deletion nomination above. Thanks. Mike Peel (talk) 07:31, 29 September 2019 (UTC)
- @Mike Peel: Is it not related to the copyrights of the depicted artworks? Christian Ferrer (talk) 20:48, 28 September 2019 (UTC)
- Keep I dont see, any argument in Mike Peel's proposal, its just about what he think. If I have a look on the description and proposals for depicts (P180) and digital representation of (P6243), I can see clear difference. Lets explain it by the example. You have a photograph or scan of a manuscript. What it depicts? It depicts laters/handscript/illustration. What it is a representation of? It is a representation of a manuscript/book, which may have its item on Wikidata.--Juandev (talk) 20:30, 21 September 2019 (UTC)
- If you have a scan of a book page, we can't say it is a digital representstion of that book. Or do you propose to create an item for every book page? --Hannolans (talk) 11:26, 22 September 2019 (UTC)
- No need to talk about hole books. We can stay with one paper maps, handscripts etc. --Juandev (talk) 10:28, 23 September 2019 (UTC)
- Many artworks are printed in a book and heritage institutions have a lot of scanned books. So what is the situation for prints and books? Using depicts (P180), based on (P144) or digital representation of (P6243). Use digital representation of (P6243) if it is a PDF of the whole book? And whisch should mention the specific book, and which to the concept of the book? --Hannolans (talk) 10:40, 23 September 2019 (UTC)
- Well even you have one page of a book, you still want to indicate what kind of book it is and for that this property is the right one. Juandev (talk) 21:51, 23 September 2019 (UTC)
- No need to talk about hole books. We can stay with one paper maps, handscripts etc. --Juandev (talk) 10:28, 23 September 2019 (UTC)
- If you have a scan of a book page, we can't say it is a digital representstion of that book. Or do you propose to create an item for every book page? --Hannolans (talk) 11:26, 22 September 2019 (UTC)
- Delete if the scope of this property stays unclear. If it used for copyright I am against it, as we have copyright status and the scope is now 2D whereas the new upcoming copyright directive of the EU will also include 3D files and 2D representations of 3D works that can't have copyright by the photograper. The property will work for paintings, but for logos, prints, books, coins, stamps, plates - all artworks that have multiple items, it is in the current definition unclear how to deal with it, if it is about the concept or the individual copy. Heritage institutions and professionals would expect it is linking ot the individual copy of that work as only then it is the digital reprensentation. And if it is about the concept, can we say a building plan drawing is a digital representation of a building? A weapon is a digital representation of a Coat of arms? And how about movies, digital born material? Is a music score a digital representation of that music? This property is created for old paintings but not well defined for other works of art. --Hannolans (talk) 11:41, 22 September 2019 (UTC)
- @Hannolans: The EU directive only says there should be no copyright if there is no original creativity by the photographer. Following the U.S. jurisprudence, expect all photographs of 3D items to pass that creativity threshold. Also expect the mother of all legal battles as to under what circumstances art repro photographs of 2D works may embody sufficient creativity. I think it's a 100% certainty that this will be fought very hard by the photo agencies, both at the legislative drafting stages and in the courts, I would expect all the way to the CJEU. And never bet on the outcome of a court case, because they very seldom go the way you think they are going to.
- This property was originally intended for faithful images of 2D artworks. That is how it should remain. It does a clear and useful job in that respect. Extending it and blurring its purpose will make it less useful, because query returns for uses of it will become less sharply defined and therefore less valuable. Jheald (talk) 12:34, 22 September 2019 (UTC)
- Sorry but Commons should be independent on current legislation but instead use structured data. We can't say there is no copyrighton the pictures of 2D artowork never and nowhere. It depends on the local copyright rules and let's not mixing up copyright rules with technologies. We already have based on (P144) to declare if a file is a copy and copyright status (P6216) to declare both the copyright for the artwork as well as the photograph or scan. --Hannolans (talk) 17:53, 22 September 2019 (UTC)
- @Hannolans: The relevance of digital representation of (P6243) for copyright is that (amongst other things) it indicates that the copyright status of the image will depend solely on the information for the wikidata item -- because there is nothing else about the image which could attract copyright. P6243 is not a substitute nor a replacement for specific copyright statements on the image. But it indicates (amongst other things) that it should be possible to check/assess their validity entirely from information on Wikidata. Jheald (talk) 21:56, 23 September 2019 (UTC)
- The copyright status is of a scan of a 2D work is based on a US case (Bridgeman Art Library v. Corel Corp. (Q1400715)) and not a worldwide ruling. In other countries it can be copyrighte for example in Germany. It was extended to 3d-works by Meshwerks, Inc. v. Toyota Motor Sales U.S.A., Inc. (Q19040164) and limited to exact representations only by Schiffer Publishing v. Chronicle Books (Q68351935). On Commons we voted to keep representations even when they are copyrighted in the source country. Using this property for a copyright status is therefore problematic. --Hannolans (talk) 14:20, 9 November 2019 (UTC)
- @Hannolans: The relevance of digital representation of (P6243) for copyright is that (amongst other things) it indicates that the copyright status of the image will depend solely on the information for the wikidata item -- because there is nothing else about the image which could attract copyright. P6243 is not a substitute nor a replacement for specific copyright statements on the image. But it indicates (amongst other things) that it should be possible to check/assess their validity entirely from information on Wikidata. Jheald (talk) 21:56, 23 September 2019 (UTC)
- Sorry but Commons should be independent on current legislation but instead use structured data. We can't say there is no copyrighton the pictures of 2D artowork never and nowhere. It depends on the local copyright rules and let's not mixing up copyright rules with technologies. We already have based on (P144) to declare if a file is a copy and copyright status (P6216) to declare both the copyright for the artwork as well as the photograph or scan. --Hannolans (talk) 17:53, 22 September 2019 (UTC)
- Keep But remove copyright from it's scope and broaden to go beyond just artworks. I'd also argue to broaden it to go beyond 2D. If I upload a 3D scan of an object then that file is "faithful" digital representation of the object (at least once Commons supports textures).
- Will there be lots of edge cases? Of course! But if we stop focusing on those I believe that the distinction between depicts (P180) "the item is somewhere in this image/file" and subject lexeme (P6254) "the whole of this item (and nothing else) is in this image/file" is pretty clear. Every single image/file sharing a digital representation of (P6243) target will be extremely similar (close to identical) wheres there is no such guaranteed relation between images/files sharing a depicts (P180) target. /Lokal_Profil 21:04, 23 September 2019 (UTC)
- Keep As I have now outlined multiple times. Repeatedly nominating this for deletion and failing to engage with everyone else is pretty disrespectful. Please stop. James F. (talk) 14:48, 26 September 2019 (UTC)
- @Jdforrester: It seems unfair to say that I'm "failing to engage" - although perhaps I am failing to understand. I don't mean to be disrespectful at all, I want to see this murky situation made clearer at least. Thanks. Mike Peel (talk) 10:57, 28 September 2019 (UTC)
- Very strong Keep, after giving it more thought, and after meeting and brainstorming with Andrea Wallace who has researched digital surrogates in the cultural sector. Some thoughts and input below:
- Faithful digital representations of creative works are definitely conceptually different from other depictions of artworks. Also having looked at GLAM files a lot over the years, I think a clear distinction between depicts (P180) and digital representation of (P6243) is a good way to address this.
- depicts (P180) and digital representation of (P6243) indeed have structurally different repercussions, especially around authorship. A basic way in which digital surrogates are different: they are meant to be faithful 'surrogates' of a work in digital form, and there is arguably no 'creative act' involved in their creation (outside of 'sweat of the brow' and the expertise needed for doing a quality digitization). Hence authorship of digital surrogates needs to be described/displayed differently.
- I accidentally found an illustrative example of this when looking at the Commons Tab Chrome browser extension by Slaporte. Compare these two cases:
-
Photo of a three-dimensional artwork. The browser extension displays attribution information generated from wikitext; while it would be good to also display the creator of the sculpture there (Stephan Huber), it is especially fully correct and necessary to attribute the photographer, because he made a creative decision in how to show the artwork in the photo.
-
Compare with this textbook example of a digital surrogate, where it actually makes no sense to display the name of the uploader of the file and it would be more beneficial to have an attribution line that focuses on the artwork itself (e.g. a combo of title, date, painter, collection).
- My point with this example is that, in order to provide more refined and correct attribution data to be used by tool builders, the distinction certainly makes sense.
- I would strongly advise to use the property for all faithful digital representations of creative works, including photographs, maps, but also potentially 3D scans, digitizations of films and music recordings, etc. Also use for faithful digital representations of works that are not PD yet but have been released under a Creative Commons or other free license. So no 1:1 replication of the PD-Art template on Wikimedia Commons. I recommend to use digital representation of (P6243) for all digital surrogates, if clearly intended to be 'precise and exact digitizations' of a document and creative work. Examples:
-
-
So this file is definitely not a digital surrogate (shadow, shows part of a wall of which the size was the photographer's decision) and should not use digital representation of (P6243). Use depicts (P180) -> The Starry Night (Q45585) here.
- I personally advise to introduce even more clarity by making digital representation of (P6243) a subproperty of depicts (P180) and hence only using one of either depicts (P180) or digital representation of (P6243), so not both at the same time pointing to the same work (sorry @Multichill: this will involve undoing some of your existing edits; I'll be happy to help clean it up because it's for a good cause!). It will mean some extra complexity in terms of indexing for search, and in terms of building Lua-powered templates, but it is to the long-term benefit of much more consistency and clarity for partners and re-users.
- Cheers, Spinster 💬 16:20, 31 October 2019 (UTC)
- I 100% support Spinster's analysis (have already !voted keep above). Jheald (talk) 18:38, 31 October 2019 (UTC)
- @Spinster: This is an interesting analysis, thanks for posting it. I'm still mulling it over, but a first thought is that you're making a distinction on the copyright side of things. Couldn't that be solved using copyright holder (P3931) vs. author (P50), or otherwise improving the attribution aspect of the file? A second thought is that perhaps instance of (P31)=digital representation (Q42396623) is an alternative way to do this (sorry James!!). As you know, I'm playing with commons:Template:Structured Data at the moment - that template doesn't use this property, and it already auto-invokes the Artwork template for paintings (the original purpose of this property), I'll continue playing with it to see how well it can cope with these examples too. Thanks. Mike Peel (talk) 19:19, 31 October 2019 (UTC)
- @Mike Peel: I have indeed also mulled over the instance of (P31)=digital representation (Q42396623) scenario, but I don't think that's a good fit as a file is not so much a digital surrogate in its nature - it's a digital photograph or scan that has the role/function of digital surrogate for a specific creative work which is indeed a more specific relationship than depicts (P180). I'd also argue it's about more than just copyright and authorship (which indeed need to be modelled separately), but also about how eventually information about files should be displayed and attributed. So I stick with my insistence on keeping digital representation of (P6243) and making it a subproperty of depicts (P180). Cheers! Spinster 💬 08:44, 1 November 2019 (UTC)
- +1 to have copyright modelled separately. I am also wondering if we with qualifiers can explain why and how it is a digital representation. For example the scan technology, colors and lighting used. And how to deal with a file that is a digititalisation not of the original work, but of a photograph of that work? For example Reproduction of a painting of Paul Klee. Is a black and white version a representation and if so how should we qualify that? --Hannolans (talk) 14:20, 9 November 2019 (UTC)
- @Mike Peel: I have indeed also mulled over the instance of (P31)=digital representation (Q42396623) scenario, but I don't think that's a good fit as a file is not so much a digital surrogate in its nature - it's a digital photograph or scan that has the role/function of digital surrogate for a specific creative work which is indeed a more specific relationship than depicts (P180). I'd also argue it's about more than just copyright and authorship (which indeed need to be modelled separately), but also about how eventually information about files should be displayed and attributed. So I stick with my insistence on keeping digital representation of (P6243) and making it a subproperty of depicts (P180). Cheers! Spinster 💬 08:44, 1 November 2019 (UTC)
- 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 --Pasleim (talk) 19:10, 4 December 2019 (UTC)
P1773 (P1773): (delete | history | links | entity usage | logs)
Should not be used per Wikidata talk:WikiProject Visual arts#Changing the way we handle attributed artworks. GZWDer (talk) 21:59, 5 October 2019 (UTC)
- @Jheald, Jane023, PKM, Marsupium, Multichill: Do we have an agreed deprecation plan? I can try to adapt my qualifier migrator for this, but we need to agree on what qualifier-target combination to tag these statements with. Deryck Chan (talk) 19:11, 11 November 2019 (UTC)
- There are some unusual usages - see Easter Sonata (Q30594711) where “attributed to” is used to mean “credited to” or “as by” for whose name was given as the composer at a performance. I think we need to manually tweak some of these outliers. - PKM (talk) 19:31, 11 November 2019 (UTC)
- Nevertheless, I think the "base case" migration might be:
- IF
- <creator> = "unknown value" or unknown (Q24238356) or anonymous (Q4233718)/any of its subclasses AND
- <creator> is qualified with P1773 (P1773) = Qnnnn
- THEN
- REPLACE the creator statement with <creator>= Qnnn qualified with sourcing circumstances (P1480) -> attribution (Q50137645)
- PRESERVE any references
- IF
- Does that sound right? - PKM (talk) 19:54, 11 November 2019 (UTC)
- Yes, sounds right to me! --Marsupium (talk) 20:07, 11 November 2019 (UTC)
- Yes this soounds right to me too. Jane023 (talk) 20:09, 11 November 2019 (UTC)
- @Marsupium, PKM, Jane023: User:Oursana redirected attribution (Q50137645) to attribution (Q230768). Do we want to use attribution (Q230768) or unmerge? Also what do you want to do with the entries where the main property is based on (P144), collection (P195), date of first performance (P1191)? Deryck Chan (talk) 18:57, 18 November 2019 (UTC)
- Perhaps we should change the English label to "attributed to (DEPRECATED)" and accordingly for other languages? Perhaps that can reduce usage of the property. Or is there any reason not to do that? --Marsupium (talk) 23:28, 11 November 2019 (UTC)
- Yes, a good first step. I suppose we should formally vote to delete the property here. - PKM (talk) 03:17, 12 November 2019 (UTC)
- Done: [29]. --Marsupium (talk) 18:07, 14 November 2019 (UTC)
- Yes, a good first step. I suppose we should formally vote to delete the property here. - PKM (talk) 03:17, 12 November 2019 (UTC)
- Delete - deprecate, migrate, and delete. - PKM (talk) 03:17, 12 November 2019 (UTC)
- Delete - deprecate, migrate, and delete. - Jane023 (talk) 18:27, 12 November 2019 (UTC)
- Comment so, after migration-deletion, any query for author would return fictional authors too? --Infovarius (talk) 17:41, 14 November 2019 (UTC)
- @Infovarius: P1773 (P1773) wasn't meant to express "fictional authorship" either. The best way to model it I can think of is this. --Marsupium (talk) 18:07, 14 November 2019 (UTC)
- Delete - deprecate, migrate, and delete. - Marsupium (talk) 18:07, 14 November 2019 (UTC)
- Delete per above. --Liuxinyu970226 (talk) 22:50, 14 November 2019 (UTC)
- Migration completed! Item namespace WhatLinksHere for P1773 is at 0. Does anyone want to go ahead and execute the deletion, Multichill? Perhaps Q65706154 should be deleted as well. Thanks, --Marsupium (talk) 22:08, 29 November 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 19:10, 4 December 2019 (UTC) |
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.
- Kept nothing wrong here. Plenty of usage (2000+) so I don't see any reason to delete this property. Multichill (talk) 20:47, 27 May 2019 (UTC)
Image Archive, Herder Institute (P6482): (delete | history | links | entity usage | logs | discussion)
I think something went wrong here, value is identical with subject --- Jura 19:37, 15 February 2019 (UTC)
- @Jura1: please ping the participants in the property proposal: @ديفيد عادل وهبة خليل 2, Jneubert, YULdigitalpreservation, Urban 3th: Jura1 proposes Property:P6482 for deletion. − Pintoch (talk) 08:30, 16 February 2019 (UTC)
- Seems to work as intended. John III Sobieski (Q53454) has Image Archive, Herder Institute (P6482) with contents "Q53454" on it. This links to https://www.herder-institut.de/bildkatalog/wikidata/Q53454 which resolves to https://www.herder-institut.de/bildkatalog/index/index?tree%5BPersonen%5D=5196 . So what do you think went wrong here? It's nice they adopted our identifiers. Multichill (talk) 12:39, 16 February 2019 (UTC)
- Value is identical with subject! Yes, thats intended. The database contains image sources of places, objects, events, persons, organizations, etc. If a Wikidata identifier is found for an entity (for example, Q53454 - John III Şoboski), it is stored in its associated record. Property "P6482" works like a beacon and determines the corresponding image sources in the database. The link https://www.herder-institut.de/bildkatalog/wikidata/Q53454 refers to the image sources associated with John III Şoboski. Urban 3th (talk) 07:13, 18 February 2019 (UTC)
- Keep as per Urban 3th. It's uncommon but somehow really nice to see QIDs in use as persistent identifiers for web access in an external database. Jneubert (talk) 08:58, 18 February 2019 (UTC)
- Delete and create a third-party formatter URL for Wikidata Q identifier (Q43649390). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:06, 4 March 2019 (UTC)
- Keep - it will not be identical in case of merge to another item. Also, User:Pigsonthewing does not explain how to store the information that for a given item in WD there is an ID in Herder. The formatter cannot tell that. 89.12.122.61 02:00, 14 April 2019 (UTC)
- The formatter [sic] does not need to do so; that's what http response headers are for. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:24, 14 April 2019 (UTC)
- User:Pigsonthewing, in which Wikidata property would the "http response headers" be stored, so that the information about existence of an ID in Herder is available in Wikidata? 78.55.63.171 19:26, 14 April 2019 (UTC)
- Delete Per 78.55.63.171, in which WMF policy, such http response headers can be disclosed on a wiki page? Disclosure of them are always violating wmf:Privacy Policy. --Liuxinyu970226 (talk) 10:34, 29 April 2019 (UTC)
- User:Pigsonthewing, in which Wikidata property would the "http response headers" be stored, so that the information about existence of an ID in Herder is available in Wikidata? 78.55.63.171 19:26, 14 April 2019 (UTC)
- The formatter [sic] does not need to do so; that's what http response headers are for. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:24, 14 April 2019 (UTC)
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.
- Since so-called "Second discussion" never happened after my responding request to Jura, I'm non-admin closed this as not happened. Maybe Jura1 should keep calm for several months before their next PFD here. – The preceding unsigned comment was added by Liuxinyu970226 (talk • contribs) at 21:19, 8 July 2019 (UTC).
- @Multichill: Given that it's a controversial property, I don't think a participating administrator should be closing this. Number of uses is irrelevant to reason for which this was listed. --- Jura 22:21, 1 June 2019 (UTC)
- So @Jura1: are you asking to re-start PFD process here? --Liuxinyu970226 (talk) 10:13, 3 June 2019 (UTC)
incorrect closures
Repeating previous comment:
- Given that it's a controversial property, I don't think a participating administrator should be closing this. Number of uses is irrelevant to reason for which this was listed. --- Jura 22:21, 1 June 2019 (UTC)
As Liux.. isn't an admin, there isn't much they can do about it either. --- Jura 22:41, 8 July 2019 (UTC)
3rd 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.
- consensus to keep. --Pasleim (talk) 13:46, 7 December 2019 (UTC)
- Keep Unless if Jura1 has a fresh new reason that this property should be deleted, I doubt if there's need to restart any discussions here. --125.38.13.0 07:49, 10 July 2019 (UTC)
- Liuxinyu970226, this is about the closure(s), I don't understand why you start a 2nd or a 3rd discussion. --- Jura 10:53, 10 July 2019 (UTC)
- @Jura1: When you repeat your reason of deletion, you are just re-starting it, it's true for every humans that edit wikis, anyone, anywhere and anyhow, please do not make so-called "connections" between 125.38.13.0 and me, this IP range has nothing to 5W1H-do and be with me, and just a violation of WD:AGF. --Liuxinyu970226 (talk) 13:21, 10 July 2019 (UTC)
- Sorry, I thought it was you logged out. Anyways, no it's not another deletion discussion as you and the ip seem to think. It's a meta question for administrators. Would you know if the IP is one? --- Jura 15:52, 10 July 2019 (UTC)
- @Jura1: When you repeat your reason of deletion, you are just re-starting it, it's true for every humans that edit wikis, anyone, anywhere and anyhow, please do not make so-called "connections" between 125.38.13.0 and me, this IP range has nothing to 5W1H-do and be with me, and just a violation of WD:AGF. --Liuxinyu970226 (talk) 13:21, 10 July 2019 (UTC)
- @Jneubert, Renamerr, Maqivi, Liridon, Epìdosis:@Taravyvan Adijene, Urban 3th, ديفيد عادل وهبة خليل 2, Davidpar, Pintoch:@Romaine: Do you all still think that this property should be kept? --Liuxinyu970226 (talk) 22:06, 10 July 2019 (UTC)
- Keep, for the reasons given above. Jneubert (talk) 07:24, 11 July 2019 (UTC)
- Keep--Liridon (talk) 11:21, 12 July 2019 (UTC)
What on Earth is going on here? There has clearly been an improper closure of the original discussion, by an admin making a "super vote", rather than assessing consensus in the discussion. Then we have new discussions, rather than the original discussion being reopened; and a bunch of pings in which I, who called for "delete" in the original discussion, was not included, but those calling "keep", an others who did not participate, were. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:18, 23 July 2019 (UTC)
- I'm also wondering that why in our world does Jura1 want this property to be deleted, even they know that there are too many keep concerns, what's their "solutions"? I can't believe that any person that does never do things like Kyoto Animation arson attack (Q65640303) can frequently PFD a property for more than 3 times, just because they want that "to be deleted" even won't happen. --Liuxinyu970226 (talk) 14:34, 25 July 2019 (UTC)
- Why this section is restored by you, @Jura1:? --Liuxinyu970226 (talk) 14:54, 4 September 2019 (UTC)
- Keep What a nonsense PFD. --117.15.55.5 02:41, 10 September 2019 (UTC)
- Keep, I don't see any reason to delete this… − Pintoch (talk) 06:03, 22 October 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 13:46, 7 December 2019 (UTC) |
- 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. --Pasleim (talk) 13:41, 7 December 2019 (UTC)
P5660 (P5660): (delete | history | links | entity usage | logs)
The related site has been closed and the content was moved to Savoirs ENS ID (P5664) (see for instance, in the case of Michel Serres (Q364456), [30] and [31]). —Nomen ad hoc (talk) 15:46, 4 June 2019 (UTC)
Ayack
Ash Crow
Tubezlob
PAC2
Thierry Caro
Pymouss
Alphos
GAllegre
Jean-Frédéric
Manu1400
Marianne Casamance
Nattes à chat
Pierre André
Bouzinac
Jsamwrites
Baidax
LearnKnowGive1
Mathieu Kappler
Daieuxetdailleurs
Archives nationales DJI
Jmax
LearnKnowGive1
Koxinga
Maxime
Framawiki
Legonin
WikiProject Wikidata for research has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.. Nomen ad hoc (talk) 06:58, 15 June 2019 (UTC).
- Delete − Pintoch (talk) 20:20, 16 August 2019 (UTC)
- The property is now not used anymore, so it can effectively be deleted. Edoderoo (talk) 05:55, 29 August 2019 (UTC)
- Delete as it's mostly gone by now. Personally, I'd have kept it. It's a different identifier for these people. It wasn't exactly high use though (ca. 350). --- Jura 14:54, 29 August 2019 (UTC)
- If the links had worked, I would have kept them too. Edoderoo (talk) 18:43, 29 August 2019 (UTC)
- Agree, but they're broken. Nomen ad hoc (talk) 18:47, 29 August 2019 (UTC).
- Don't we usually just de-activate the formatter URL? --- Jura 20:51, 29 August 2019 (UTC)
- Agree, but they're broken. Nomen ad hoc (talk) 18:47, 29 August 2019 (UTC).
- If the links had worked, I would have kept them too. Edoderoo (talk) 18:43, 29 August 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 13:41, 7 December 2019 (UTC) |
- 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. Replace statements with fabrication method (P2079). --Pasleim (talk) 13:36, 7 December 2019 (UTC)
P2157 (P2157): (delete | history | links | entity usage | logs)
This property seems over-specialized. I had been using statements like Exynos 7420 (Q28859206) fabrication method (P2079) 8nm LPP FinFET (Q25991737) and they seem adequate. The statements would be easy to convert. @MisterSanderson, Ruud Koot, Tobias1984: Ghouston (talk) 10:05, 26 June 2019 (UTC) —Ghouston (talk) 10:05, 26 June 2019 (UTC)
Aside from the point that there are numerous manufacturing techniques that apply to more things than semiconductors, and we don't really want properties for them all, it seems that these semiconductor techniques can be described more accurately. E.g., according to [32] there are processes like "8nm FinFET LPP (Low Power Plus)" and "7nm EUV (Extreme Ultra Violet)". The source for the Exynos 9820 says it uses 8nm FinFET LPP. If it was desired to group the semiconductor lithography processes together, that can be done by creating a subclass of manufacturing process (Q1408288). (that would probably be photolithography (Q622938), judging by its enwiki article). Ghouston (talk) 00:26, 27 June 2019 (UTC)
WikiProject Informatics has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.
- Other participants of the proposal: @Kopiersperre, Filceolaire:
- Participants of the more recent Wikidata:Property proposal/microarchitecture: @Amitie 10g, Mahir256, John Samuel, Tetizeraz: Visite fortuitement prolongée (talk) 21:00, 7 July 2019 (UTC)
- Delete Using fabrication method (P2079) makes sense to me. ArthurPSmith (talk) 17:23, 27 June 2019 (UTC)
- I would vote Delete, but not without discussing its usage in templates. Over-simplifying Wikidata by removing properties in favour of qualifiers is not the best solution for those uses. Let discuss at the Spanish Wikipedia, and depending the consensus, this property should be deleted or kept. --Amitie 10g (talk) 23:32, 7 July 2019 (UTC)
- Template use is a good question, I can see a link to ca:Plantilla:Infotaula equipament informàtic on the talk page, and it's visible on ca:Intel 8085, for example. My suggested alternative would be using a different property, not a qualifier, but it would have a wider range of possible values: any manufacturing process. Ghouston (talk) 07:56, 8 July 2019 (UTC)
- I already broke it a bit by changing a few of the English labels, before I figured out what was going on, and that they were supposed to have a special format. E.g., 14 nm lithography process (Q2750603), which originally resembled 12 nm lithography process (Q56062805). Ghouston (talk) 08:01, 8 July 2019 (UTC)
- Is it really that bad if there is a property that describes the production size of microprocessors? Should all information (eg. 8nm FinFET) really be stored in one property? Or would it be better to split it to production size (8nm) and production method (FinFET)? What if you know one, but not the other. In that case the provided entry would not be correct. However, there may is a better name other than lithography for that. Since I don't see any good other way I go with Keep for now --D-Kuru (talk)
- Unmentioned that this property (the microprocessors' structure size) is a very important information for all microprocessors and improves over time. I don't really care how the information is added, but it is an important piece of information. --D-Kuru (talk) 20:49, 20 August 2019 (UTC)
- It seems that there's not a lot of enthusiasm for removing the property, or much interest in it all really. I suppose we should just leave the status-quo. Reading the original discussion for the creation of the property, it's clear the the items are supposed to represent fabrication processes, and the labels like "14 nanometer" are just inherited from the English Wikipedia. I don't think it would do any harm to change them to "14nm lithography process" and make them subclasses of photolithography (Q622938). It should also be fine to further distinguish fabrication techniques, e.g., 14LPE or 14LPP discussed at [33]. It can be clarified that the property P2157 is purely a subproperty of fabrication method (P2079) for semiconductor lithography. Ghouston (talk) 04:18, 25 August 2019 (UTC)
- Unmentioned that this property (the microprocessors' structure size) is a very important information for all microprocessors and improves over time. I don't really care how the information is added, but it is an important piece of information. --D-Kuru (talk) 20:49, 20 August 2019 (UTC)
- Delete The template using isn't a problem: Lua modules can be useful in those cases. --Tinker Bell ★ ♥ 02:54, 20 September 2019 (UTC)
- Delete after migrating data from P2157 (P2157) to fabrication method (P2079). Dhx1 (talk) 14:18, 27 September 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 13:36, 7 December 2019 (UTC) |
- 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 --Pasleim (talk) 13:26, 7 December 2019 (UTC)
majority opinion by (P5826): (delete | history | links | entity usage | logs | discussion)
has part(s) (P527)majority opinion (Q6738447)
- Comment Isn't has part(s) (P527) the reverse of part of (P361)? Nomen ad hoc (talk) 07:16, 13 August 2019 (UTC).
- Keep A dedicated property seems justified. And connected properties for dissenting and concurring opinions too. Nomen ad hoc (talk) 14:37, 13 August 2019 (UTC).
- I agree with Nomen ad hoc that has part(s) (P527) doesn't seem to be appropriate here. has part(s) of the class (P2670) seems to be nearer to the intended meaning but seems to be a bit complex for this usecase. Given that there are lots of legal cases I vote Keep and endorse creating additional properties for "dissenting opinion by" and "concurring opinion by". ChristianKl ❪✉❫ 13:54, 13 August 2019 (UTC)
- Keep per both voters. Enivak (talk) 10:42, 27 August 2019 (UTC)
- I disagree both with using this property and with the proposed solution of having has part(s) (P527) point to a generic class with a author (P50) qualifier. We have thousands of pages on Wikisource associated with majority opinions of court cases. These pages should be linked to Wikidata items, given P50 statements, and linked to the cases. --Yair rand (talk) 23:23, 11 November 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 13:26, 7 December 2019 (UTC) |
- 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 support for deletion --Pasleim (talk) 13:22, 7 December 2019 (UTC)
Bursa Malaysia stock code (P7288): (delete | history | links | entity usage | logs | discussion)
Discussion still open --- Jura 18:42, 8 September 2019 (UTC)
- Keep as there was a consensus to create − Pintoch (talk) 06:00, 22 October 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 13:22, 7 December 2019 (UTC) |
- 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 by Romaine, 03:40 - 25 décembre 2019 à 03:40 —Eihel (talk) 05:39, 25 December 2019 (UTC)
P7728 (P7728): (delete | history | links | entity usage | logs)
Request from its creator, a speedy deletion of property in a way. It is a proposal containing a large number of voters for the creation of this property, I was confident, but I went a little quickly to press on "Create": the proposal contains several errors which do not allow the creation of this prop, for the moment. As the data type may change in the meantime, I request the deletion, purely and simply. Not in production and empty. Cordially. —Eihel (talk) 07:19, 23 December 2019 (UTC)
- Delete ArthurPSmith (talk) 19:22, 23 December 2019 (UTC)
- Dear Arthur, I hope the end of the year is going well for you. Would you be so kind as to look at the proposal? Maybe you will see the same thing there as I do? An intervention by someone external would have more weight on this avalanche of "support", especially someone of your stature. My opinion: group all types of catalog entries to make only one property and announce that the proposed property is not in conformity. Since I am the only opponent, I appear to be The Ugly Duckling (Q1144677), but I sense that the votes reflect the desire to have a property and not the fact that it is feasible (without explanation votes). Cordially et bonnes fêtes. —Eihel (talk) 02:48, 24 December 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. —Eihel (talk) 05:39, 25 December 2019 (UTC) |
P727 (P727): (delete | history | links | entity usage | logs)
Not a persistent identifier, per talk page. GZWDer (talk) 01:21, 13 December 2019 (UTC)
- I'm semi-inclined to agree this should be deleted. See also the discussion on the proposal for a new Europeana property (which has been created now). ArthurPSmith (talk) 16:49, 13 December 2019 (UTC)
- Delete replacement available. --Liuxinyu970226 (talk) 13:05, 8 January 2020 (UTC)
- Keep but re-verify if values are correct. Michael FV (talk) 04:22, 9 January 2020 (UTC)
- @Michael FV: There's a new and much more proper property available Europeana entity (P7704), you don't need to keep this old school property scheme. --Liuxinyu970226 (talk) 00:29, 10 January 2020 (UTC)
- Delete given the discussion on its talk page. --- Jura 11:04, 20 January 2020 (UTC)
- Delete This is just a scheme change. @Michael FV: Why keep the old one? --117.136.54.109 23:27, 20 January 2020 (UTC)
- Deleting given that this has over 77k uses, it may take a bit. Starting a batch edit to remove the statements, and I'll be back later to actually delete the property --DannyS712 (talk) 09:03, 24 March 2020 (UTC)
- On hold 70 of the uses cannot be removed; reported at phab:T248439 --DannyS712 (talk) 02:21, 25 March 2020 (UTC)
- Delete Not persistent, replaced. --Epìdosis 13:04, 28 March 2020 (UTC)
Did the clean up for the remaining usage and Deleted it. Thanks User:DannyS712 for doing the bulk of the work. Multichill (talk) 20:40, 29 March 2020 (UTC)
- @GZWDer, Multichill: Aren't you supposed to warn other projects that are using the property before deleting it? It was in use in Template:Wikidata Infobox (Q47517487), I've pulled it from the installation on Commons after it only caused 7,000 error messages, I'll check other wikis. Mike Peel (talk) 21:00, 29 March 2020 (UTC)
- I think it only affected Commons, I'm purging the cache for the affected pages. Mike Peel (talk) 21:15, 29 March 2020 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Liuxinyu970226 (talk) 06:35, 31 March 2020 (UTC) |
P134 (P134): (delete | history | links | entity usage | logs)
It can be replaced by Property:P4913 and it has been deprecated. —P134toP4913 (talk) 04:32, 4 December 2019 (UTC)
- There is already consensus to delete this property, see Wikidata:Requests_for_deletions/Archive/2018/Properties/1#P134. But we haven't yet deleted it because the property is used for a few Wikipedia infoboxes. --Pasleim (talk) 19:13, 4 December 2019 (UTC)
- Pinging Calatan Wikipedia editors: @Arnaugir, ToNToNi, Sarang, Amadalvarez, Dúnadan:@Martorell, ArinArin, Ludor, Glm, Pepetps:@Viktor~cawiki, Coet, David~cawiki, Vriullop, Sl:@KRLS, Spl908455, Tlustulimu, Bestiasonica, Castor:@Hinio, Jey, Visite fortuitement prolongée, Jarashi, Kette~cawiki: They should modify their local usages ca:Plantilla:Infotaula_de_llengua, ca:Plantilla:Infotaula llenguatge programació et ca:Plantilla:Infotaula família lingüística. --Liuxinyu970226 (talk) 00:13, 5 December 2019 (UTC)
- @Liuxinyu970226:, thanks to ping us. Is Done by Paucabot in ca:Plantilla:Infotaula_de_llengua, ca:Plantilla:Infotaula llenguatge programació. However, ca:Plantilla:Infotaula família lingüística do not use P134. May be this is not important but, where do you get this information from ?. Thanks, Amadalvarez (talk) 06:55, 5 December 2019 (UTC)
- It was in an old version, not used anymore in this template. --Vriullop (talk) 07:28, 5 December 2019 (UTC)
- Well, just from
{{ExternalUse}}
template of its talk page. --Liuxinyu970226 (talk) 07:00, 5 December 2019 (UTC)
- @Liuxinyu970226:, thanks to ping us. Is Done by Paucabot in ca:Plantilla:Infotaula_de_llengua, ca:Plantilla:Infotaula llenguatge programació. However, ca:Plantilla:Infotaula família lingüística do not use P134. May be this is not important but, where do you get this information from ?. Thanks, Amadalvarez (talk) 06:55, 5 December 2019 (UTC)
- Now slwiki users needed: @M11rtinb, Sporti, Pinky sl, Yerpo, XJaM:@TadejM, Andrejj: do we have time to modify sl:Predloga:Infopolje_programski_jezik/peskovnik and sl:Predloga:Infopolje_Programski_jezik? --Liuxinyu970226 (talk) 07:03, 5 December 2019 (UTC)
- Ok. I fixed the matter. So you can continue your good work. --Pinky sl (talk) 19:26, 7 December 2019 (UTC)
- Delete if at all, store in inverse. Michael FV (talk) 03:56, 9 January 2020 (UTC)
- Can this be migrated or not? --- Jura 11:05, 20 January 2020 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Pasleim (talk) 13:41, 14 April 2020 (UTC) |