Open main menu

Wikidata:Properties for deletion

Properties for deletion
This is the page for requesting the deletion of a property (for items, with IDs beginning with "Q", please use requests for deletions). To nominate a property for deletion, complete the following steps:
  • Place the {{Property for deletion}} template on the property talk page.
  • Open the discussion on this page under the "Requests" section below.
  • Notify the user who originally proposed the property and the property creator for it on their respective talk pages.
  • Validate the property isn't being used in other projects (using {{ExternalUse}}) and if it is, leave a message in Village pump of the project.

Requests may be closed after 7 days, but may be extended if consensus is not reached. If an extended discussion becomes stale and has been left unclosed, a request for closure can be made at the administrators' noticeboard. If the request is uncontroversial, for example "accidentally created with wrong datatype", please use the faster-moving requests for deletions instead.

Add a new request

Edit


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


Contents

RequestsEdit

Please add a new request at the bottom of this section, using {{subst:Rfd|1=PAGENAME|2=REASON FOR DELETION}}.


first flight (P606)/time of spacecraft launch (P619)/time of spacecraft landing (P620)/time of spacecraft orbit decay (P621)/spacecraft docking/undocking date (P622)Edit

first flight (P606): (delete | history | links | entity usage | logs | discussion) time of spacecraft launch (P619): (delete | history | links | entity usage | logs | discussion) time of spacecraft landing (P620): (delete | history | links | entity usage | logs | discussion) time of spacecraft 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):

--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 time of spacecraft launch (P619) because they have almost (or over) 5000 uses [1] [2]. 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 time of spacecraft landing (P620), time of spacecraft orbit decay (P621) and spacecraft docking/undocking date (P622) because they have at most 350 uses [3] [4] [5]. 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 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 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 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 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)

  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)

Pokédex number (DEPRECATED, use P1685) (P1112) + Pokédex / Pokémon browser number (P1685)Edit


  • @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édex / Pokémon browser number (P1685) has String datatype while Pokédex number (DEPRECATED, use P1685) (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)

analog or derivative of (P5000)Edit

analog or derivative of (P5000): (delete | history | links | entity usage | logs | discussion)

Property represents analog (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.

Saehrimnir
Leyo
Snipre
Jasper Deng
Dcirovic
Walkerma
Egon Willighagen
Denise Slenter
Daniel Mietchen
Andy Mabbett
Kopiersperre
Emily Temple-Wood
Pablo Busatto (Almondega)
Nothingserious
Antony Williams (EPA)
TomT0m
Wostr
Devon Fyson
User:DePiep
User:DavRosen
Benjaminabel
99of9
Kubaello
Fractaler
Sebotic
Netha
Hugo
Samuel Clark
Tris T7
  Notified participants of WikiProject Chemistry, pinging participants of the property proposal discussion: @Andrew Su, YULdigitalpreservation, Okkn, ديفيد_عادل_وهبة_خليل_2, Andrawaag, Gstupp:. —Wostr (talk) 13:21, 23 September 2018 (UTC)

  •   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 has role (P3831) (functional analog (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 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)

Soccerway player ID (P2369)Edit

Soccerway player ID (P2369): (delete | history | links | entity usage | logs | discussion)

This property retrieves the same data from the same database as the Scoresway soccer person ID (P3043). When a player becomes a coach, his statistics disappear on Soccerway[9][10][11], but it still remains on Scoresway[12][13][14]. —Сидик из ПТУ (talk) 11:12, 18 October 2018 (UTC)

Commons category (P373)Edit

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)
  •   Comment I support this in the long run, but this request is probably a bit early. For background info, Pi bot (talkcontribslogs) 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 P910 tinyurl.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)
  •   Keep. - PKM (talk) 20:00, 19 January 2019 (UTC)

demonym (P1549)Edit

demonym (P1549): (delete | history | links | entity usage | logs | discussion)

I think this property could be replaced with one that links to senses (e.g. sense 1 of Kenyan (L35249)); this would be especially useful for words with lots of conjugations. I have not created a new property proposal because it would be more appropriate to have the discussion in one place.

I've already created 161 English noun lexemes which would be able to replace current uses; it would also be necessary to create equivalent items for adjectives, as well as to create the relevant senses for the noun and adjective lexemes (I've only added a sense to L35249 so far). —Jc86035 (talk) 10:33, 4 November 2018 (UTC)

Notified 94 contributors to the property and its talk page: User:Nikki User:Abián User:Jura1 User:VIGNERON User:Tubezlob User:Jheald User:Lockal User:Infovarius User:Putnik User:Laddo User:Kalogeropoulos User:Innocent bystander User:Event User:Jakec User:Vinhtantran User:MaGa User:Labant User:K175 User:Autom User:Robin van der Vliet User:Matěj Suchánek User:Janezdrilc User:Ctschiebout User:Kevin Scannell User:Maria zaos User:Horcrux User:Soued031 User:Metsavend User:Obaid Raza User:İncelemeelemani User:Pinky sl User:Andreasmperu User:Рөстәм Нурыев User:Pmt User:Gustavo Rubén User:Oriciu User:Mr. Ibrahem User:زكريا User:ToJack User:Renessaince User:Arnaugir User:MisterSynergy User:AmaryllisGardener User:Beta16 User:Mahir256 User:Спасимир User:Asierog User:Avatar6 User:Wylve User:Şêr Jc86035 (talk) 10:39, 4 November 2018 (UTC) User:Krupolskiy Anonim User:YMS User:ಶಿವಕುಮಾರ್ ನಾಯಕ್ User:Hibm98 User:GAllegre User:Epìdosis User:Jklamo User:David1010 User:SR5 User:Máté User:Ślimaczek User:HakanIST User:FocalPoint User:Allen4names User:Mbch331 User:Zygimantus User:Fnielsen User:Peppepz User:Geraki User:Supaplex User:Thierry Caro User:NMaia User:Loischantada User:ANDROBETA User:Marklar2007 User:Kikos User:Raid5 User:Doostdar User:Palapa User:Octahedron80 User:Милан Јелисавчић User:Frokor User:Rippitippi User:Conny User:Qllach User:Miguillen User:יונה בנדלאק User:Liuxinyu970226 User:桂鷺淵 User:Bjankuloski06 User:Thomas11 User:Ayack User:Чаховіч Уладзіслаў User:Александр Сигачёв Jc86035 (talk) 10:41, 4 November 2018 (UTC)

I would like to note that the property is used as label for country of citizenship (P27) at huwiki. If the property is deleted, the current data needs to be imported into the newly accepted structure, and huwiki needs to be notified to create a workaround to the new structure if possible. Ideally, the new structure should make it possible. – Máté (talk) 12:10, 4 November 2018 (UTC)

This is also the case for WD powered templates at svwiki, frwiki and probably many more. /Autom (talk) 13:13, 4 November 2018 (UTC)
@Máté, Autom: Where is it used on huwiki/svwiki/frwiki? Those are not listed in the box on the talk page, perhaps the script which looks for property usage can be improved. @Jc86035: Please notify the projects using this property too. - Nikki (talk) 14:52, 4 November 2018 (UTC)
@Nikki: hu:Sablon:Személy infobox of the top of my head. – Máté (talk) 14:58, 4 November 2018 (UTC)
@Nikki: On svwp, it is used by the module Wikidata2, which in invoked by a lot of templates (like Faktamall biografi WD in biografies). I know frwiki had a similar system a year ago (it's possible it has change since then). /Autom (talk) 18:25, 4 November 2018 (UTC)
  •   Delete but probably wait some weeks/months until Lexemes are more stable. Cdlt, VIGNERON (talk) 12:17, 4 November 2018 (UTC)
  • I agree that we should eventually replace the existing property with lexemes, but we shouldn't delete this until people are able to switch to using lexemes. We still need to decide how we want to link things together. - Nikki (talk) 14:52, 4 November 2018 (UTC)
  •   Delete The property demonym of (P6271) has been created. This one can now be deleted (first declare obsolete, move content, then delete).--Micru (talk) 17:30, 19 December 2018 (UTC)
  •   Comment If this property is being used in an infobox or by a Lua module, it will need to be retained and to go on having its values added to and extended, at least and until such time as inverse property values become obtainable via Lua - as at present they are not. Jheald (talk) 18:09, 19 December 2018 (UTC)
  •   On hold. I agree with Jheald that we need a place -> demonym property to keep infoboxes working. We should keep this property until we have a new Item -> Lexeme "demonym" property, migrate all existing uses and infoboxes, then delete P1549. Deryck Chan (talk) 15:52, 11 January 2019 (UTC)

Property:P1773Edit

attributed to (P1773): (delete | history | links | entity usage | logs | discussion)

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)
  •   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)

participant of (P1344)Edit

participant of (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 of (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)
  • 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)

NSZL name authority ID (P3133)Edit

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)

GINCO ID (P3905)Edit

GINCO ID (P3905): (delete | history | links | entity usage | logs | discussion)

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 GINCO ID (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 GINCO ID (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)
  •   Comment based on the explanations given, I'd delete either the above or the two other ones. --- Jura 06:14, 20 December 2018 (UTC)

translation (P5972)Edit

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)

  • 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)
  • 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)

e-mail (P968)Edit

e-mail (P968): (delete | history | links | entity usage | logs | discussion)

Change data type to string. According to this RFC, this property can't be used correctly in it.voy as they want to show the email with a link to mailto: URI and you can't do [mailto:EMAILADDRESS EMAILADDRESS] right now. —Micru (talk) 18:37, 26 December 2018 (UTC)

  Oppose - We shouldn't change the datatype here because 1 re-user (it.voy) can't handle the default output. In this case it.voy should adapt their module:wikidata so it does render the output they want. For some projects other properties may be hard to handle because of their current datatype if they use the data as outputted by default. If the data output doesn't suit you, you need to make a script/module (or ask for help with a script/module) so it renders the way you want. Mbch331 (talk) 14:39, 27 December 2018 (UTC)
  •   Comment the it.voy usage aside, I think it's just plainly redundant. Using a string with the formatter URL mailto:$1 seems a much more logical choice. phone number (P1329) does it that way already. Lewis Hulbert (talk) 19:30, 4 January 2019 (UTC)
  •   Oppose - The property is used in many wikis. To change this means a comparatively high effort. It is very simple to remove mailto: from the string. --RolandUnger (talk) 08:54, 6 January 2019 (UTC)
  •   Support I support changing the datatype, but we should likely first create a new one, copy over the values and then slowly deprecate the old one.
It will be easier to enter data when the user doesn't have to write mailto: in front of every email address and making it easier to enter data is valuable. ChristianKl❫ 10:11, 6 January 2019 (UTC)
  •   Oppose - It is not a big deal to make [mailto:email email]. I don't know which tool are you retrieving the email from Wikidata, in my following example, I use Módule:WikidataIB:
{{#invoke:WikidataIB|getValue|fetchwikidata=ALL|noicon=yes|onlysourced=yes|P968|qid=Q1581634}}mailto:mam@mam.org.br
{{#invoke:String|replace|source={{#invoke:WikidataIB|getValue|fetchwikidata=ALL|noicon=yes|onlysourced=yes|P968|qid=Q1581634}}|pattern=mailto:|replace=}} → mam@mam.org.br
So,
[{{#invoke:WikidataIB|getValue|fetchwikidata=ALL|noicon=yes|onlysourced=yes|P968|qid=Q1581634}} {{#invoke:String|replace|source={{#invoke:WikidataIB|getValue|fetchwikidata=ALL|noicon=yes|onlysourced=yes|P968|qid=Q1581634}}|pattern=mailto:|replace=}}]mam@mam.org.br
And you can use some subst's as well. Sorry for the long coding. Ederporto (talk) 16:12, 6 January 2019 (UTC)
@Ederporto: I'm so sorry, but this format can't work if a wiki has wiki with script conversion (Q36509592) support, in that case, your example will wrongly shown as "man-{@}-man.org.br", where @ is enclosed by "-{}-". --Liuxinyu970226 (talk) 01:38, 12 January 2019 (UTC)
@Liuxinyu970226: Wouldn't {{#invoke:String|replace|source=man-{@}-man.org.br|pattern=-{@}-|replace=@}} solve it? Ederporto (talk) 14:52, 12 January 2019 (UTC)

The Guardian article ID (P6085)Edit

The Guardian article ID (P6085): (delete | history | links | entity usage | logs | discussion)

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)

Property:P2521Edit

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)

Property:P3321Edit

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)

charter URL (P6378)Edit

charter URL (P6378): (delete | history | links | entity usage | logs | discussion)

Duplicates with foundational text (P457)/main regulatory text (P92) and full work available at (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)
  •   Keep Completely different from the rest David (talk) 06:52, 20 January 2019 (UTC)
  Keep full work available at (P953) can sometimes violate privacy But this won't. --125.38.13.238 01:00, 21 January 2019 (UTC)