Shortcuts: WD:PC, WD:CHAT, WD:?

Wikidata:Project chat

From Wikidata
Jump to navigation Jump to search

Wikidata project chat
A place to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.

Please use {{Q}} or {{P}} the first time you mention an item or property, respectively.
Other places to find help

Start a new discussion
Edit
On this page, old discussions are archived after 7 days. An overview of all archives can be found at this page's archive index. The current archive is located at 2021/08.

Blazegraph is unmaintained and does not scale - is JanusGraph a viable replacement for WDQS?[edit]

I'm investigating alternatives to Blazegraph (Q20127748). JanusGraph (Q56856628) based on Apache TinkerPop (Q20942022) is the best alternative I could find and it scales well and it used by giants like Netflix, RedHat, IBM, AWS, HADOOP, Microsoft, and others. It is FLOSS and in active development, BUT it uses Gremlin (Q5607337) graph traversal language instead of SPARQL...

I found a SPARQL->Gremlin traversal transpiler (stale since 2020) that could help us migrate because it seems to support most of the SELECT queries we currently have in our examples.

I really like the idea of federation, and TinkerPop seems to sort of support that too, see https://github.com/unipop-graph/unipop (stale since 2018 though)

Let's face it. Amazon killed Blazegraph[1]. It's not going to get any bug fixes or new features. It's brittle (ask the WMF operations team or take a look in phabricator) and it is not built for the number of triples now in WD (according to Lydia in the WD telegram channel).

Time to move with the rest of the industry and adopt TinkerPop as backend framework and retire Blazegraph as a legacy-solution after a transition period?

Maybe WMF/WMDE can encourage someone else to run/develop Blazegraph or any other viable SPARQL 1.1 update capable database that scales. (there are currently no others with a feature set on par with Blazegraph to my knowledge). If you ask me Blazegraph seems like a dead end and SPARQL 1.1 has not seen mass adoption (many endpoints listed here are now dead :/) and I find it unlikely that it ever will.

After AWS aqui-hired Blazegraph and renamed it to Amazon Neptune they immediately added support for Gremlin and now mentions that first in their promotional pages. This if anything is a sign that SPARQL is not doing so well. Note that "An acqui-hire basically is a fancy way to say your company is being bought predominantly for the fabulous team you've assembled and not for the product/service you were (trying) to bring to market." which again points to the fact that Blazegraph is and was not ready for market, but the competent team seems to have since made a viable PaaS in-house at AWS.

AWS did the math and decided they could not market graph PaaS WITHOUT support for Gremlin. Microsoft decided not to support SPARQL in CosmosDB because of lack of demand, but has both Gremlin and Cassandra APIs which is another nail in the coffin if you ask me.

Gremlin has an active user group and over 2600+ questions on stackoverflow (sparql has 5000+ but that could be because it is a much older language).

I'm certain that moving away from SPARQL/RDF will kill Wikidata, it will become just another data island. Even if Gremin is twice as popular as it is now Graph weaver (talk) 14:39, 12 August 2021 (UTC)Graph weaver

I say we go with the flow and immediately start building a working prototype of WDQS with JanusGraph as backend, WDYT?--So9q (talk) 10:40, 26 July 2021 (UTC)

See also this comparison of Dgraph, Neo4j and JanusGraph.
My guess is that whatever we choose, we are going to lose some functionality in the beginning until the new backend is improved according to our needs (we can encourage coding stuff we need with a round of Grants focused on this). Keeping a legacy Blazegraph-WQDS around can help transition more smoothly. I suggest we keep a WDQS where the scholary articles are filtered out to get below the threshold that Blazegraph can handle. Those who need to search scholary articles via SPARQL can then either set up their own Blazegraph-Wikibase or use the query language in the new system (likely Gremlin because that seems to have the widest adoption at the moment).--So9q (talk) 11:41, 26 July 2021 (UTC)
  • sounds good to me but who would do the work and make the transition? surely we'd need the wikibase devs to sign off on this? BrokenSegue (talk) 13:50, 26 July 2021 (UTC)
Yes of course. I would love to see WMF/WMDE involve the community more and communicate about this challenge. It is probably a too big a task to fit in a max $100.000 grant so maybe the best way forward is for WMDE to be tasked with this challenge. Problem is that WMDE from what I know already has their hands full. Anyone who feels like can start hacking on this. The problem is only going to get worse. WD is growing a lot and Blazegraph is a bottleneck.
Has anyone here tried loading WD into another graph database like Dgraph or JanusGraph? What are the obstacles? Are the datatypes supported? Do the triplets need to be converted? It seems that for Dgraph a schema is needed.--So9q (talk) 21:23, 26 July 2021 (UTC)
@So9q: so I'm a SWE with too much free time at the moment. Investigating and prototyping this is something I'd be interested in. Just the infrastructure costs of this project would take non-trivial money but I'm not sure why you think $100k is not enough (and I'm unsure where that number comes from, do you mean 10k)? I'd also be keen to collaborate with people on this. BrokenSegue (talk) 23:58, 26 July 2021 (UTC)
Thanks for your insight and thoughts on the issue of scaling up WDQS's graph backend. This is one of the top priorities for the WMF Search team this fiscal year (in collaboration with WMDE), as we know Blazegraph is not currently scaling well and is also end of life, as you have pointed out. There are a number of criteria (~50 or so last time graph backends were evaluated) that the Search team will need to consider in a Blazegraph alternative (I notice that you are aware of and active on the phab ticket to find an alternative). This is something we want to work closely with the community on, and to learn from your experience with different alternatives and how they suit your needs (or not), so I appreciate that the conversation around this is already happening here. If you end up building out a prototype on a different graph backend, we'd love to see it!
On our end, we're in the process of analyzing the volume of queries to WDQS and structure of WD for ways to optimize based on current usage patterns: this includes better understanding potential benefits of graph-splitting, as you mentioned with the case of scholarly articles. We are finalizing WDQS user research initiatives right now, and are also planning on speaking more about WDQS scaling challenges at WikidataCon 2021. The Search team has a lot on our plate right now, and we appreciate your patience and continuing participation with us as we work on improving our services. MPham (WMF) (talk) 12:34, 27 July 2021 (UTC)
  • It would be interesting to see a trial installation of JanusGraph on toolforge with a subset of Wikidata items. Maybe one with everything directly linked from instances of film (Q11424). This would help compare the two query languages and experiment with subsets of items. --- Jura 08:02, 29 July 2021 (UTC)
    • I think even such a small subset of items would need substantially more than toolforge's default quota. I wonder if they'd be willing to grant us more to try this out. @MPham (WMF): do you know? would such a trial be useful to you? BrokenSegue (talk) 13:18, 30 July 2021 (UTC)
      • @BrokenSegue: It is a little too early for the Search team to know exactly all the tests we'd need to run on which potential Blazegraph alternatives, as we have other immediate commitments for this quarter. Unfortunately, this means there aren't exact specifications for how we'd want to evaluate each candidate to determine if it will meet our scaling needs. For consideration though, here is the output of the last time graph backend candidates were evaluated, and the criteria that were considered -- please keep in mind though that this document is years old and does not necessarily reflect all the candidates, or the priorities and criteria we currently need for scaling WDQS.
      • @BrokenSegue: It does not have to run on the toolserver. Petscan runs in a VPS in https://wikitech.wikimedia.org/wiki/Portal:Cloud_VPS (where Toolserver is also running). If I were to poke at this I would request a VPS and start from there.--So9q (talk) 12:45, 4 August 2021 (UTC)
I don't anticipate that my team can allocate resources to help with external trials at the moment, but if you provided a proposal/request with more detail, it is something we could officially consider. MPham (WMF) (talk) 15:22, 3 August 2021 (UTC)
@MPham (WMF): Thanks for letting us know about your status.--So9q (talk) 12:45, 4 August 2021 (UTC)
@MPham (WMF): Seems the status hasn't much progressed since the community raised the problem more than three years ago (Wikidata:Contact_the_development_team/Archive/2018/07#Future_of_query_server). Maybe it's time to seek external help on the issue. The approach suggested by BrokenSegue could be one. --- Jura 05:54, 7 August 2021 (UTC)
  • While I see your concerns for Blazegraph you seem to completely underestimate what happens when you move away from it. It's not just another query language, it's a completely different data model. The point of RDF is that it has universal identifiers that are used by many people out there, that's the beauty of Wikidata in its current form. With SPARQL/RDF we can fetch data from Wikidata that we don't have to maintain in our own endpoints. I'm one of many people/companies/organizations that do that and you cannot simply take that away and say "here is Gremlin, good luck". I would even argue that the selling point of Wikidata is that it is available as Linked Data in RDF. If that is gone, using the data will be waaaay harder and for me the point of Wikidata is to maintain data that is useful for others in here so we all share the work and profit from it. When this is no longer the case and it's hard to link it with other RDF based data, I would not see a single motivation anymore to use Wikidata and move back to DBpedia. I don't have a problem when the data is available in other query languages as well but none of them will be as useful as the result is siloed data, not a re-usable datamodel like RDF. I know this is very hard to understand for some who are not working in this stack but for the love of god, don't f... this up. For moving forward: I would be interested in discussing potential alternatives. On the top of my head, I see two ways forward: Implement an RDF & SPARQL layer on top of another DB (Postgres was a candidate we talked about at a W3C Graph Workshop in Berlin 2019) or get more funding/development for one of the existing RDF/SPARQL DBs. I have a pretty good idea of the space as this is my daily business and the one I would talk to here is Oxigraph. That is currently mainly a one-man show but it's Rust and the guy is really skilled. Given additional resources/money I could imagine this could be a potential candidate for scaling. TheKtk (talk) 12:44, 9 August 2021 (UTC)
    • I concur, moving away from RDF and SPARQL would make wikidata lot less useful. For scaling there are other SPARQL capable stores, including opensource ones that can scale beyond what blazegraph could on identical hardware (e.g. virtuoso opensource). Dropping RDF means dropping ShEx for quality control in practical terms. I also don't believe JanusGraph actually scales to provide the required performance at the required scale. Adding new properties and doing so automatically requires significant custom work that would also be required by tools that map SPARQL to SQL. Developing that would allow the WikiMedia team to reuse existing skills for managing databases and have a much wider selection of implementations than what TinkerPop allows. A solveable problem is migrating the special SERVICE calls implemented for Blazegraph. These are also very hard to migrate to JanusGraph etc. Jerven
    • Update: I got pointed to this issue, apparently the consensus is that SPARQL is not optional: https://phabricator.wikimedia.org/T206560 TheKtk (talk) 14:32, 9 August 2021 (UTC)
    • Just, please don't. RDF and SPARQL is are open standards, which is why Wikidata is such a useful source for shared knowledge. Dropping it would be a great loss Tomasz Pluskiewicz
  • I share the concern about using an abandoned solution such as Blazegraph and I was wondering about how long Wikidata will continue to use it myself. However, I never thought about it in terms of abandoning RDF and SPARQL just because one implementation, even though it is the currently used one, was abandoned. There are many other triplestore and SPARQL implementations that can be used instead. Access to Wikidata in RDF is my primary use case and without it, the data would lose a lot of its usability and with it, motivation to contribute to Wikidata. I think this would be a huge mistake. Jakub Klímek (talk) 06:34, 10 August 2021 (UTC)

Nasty suggester script interfering with sitelinks-wikipedia[edit]

One can made the following exercise (tested on the Vector skin both current and legacy with no suspicious gadgets or user scripts enabled).

  1. Go to #sitelinks-wikipedia on any entity and press edit.
  2. Go to the lower left input field (defined by the code <input class="noime ui-suggester-input" placeholder="wiki"…>) and type ru into it.
  3. Leave the field (by Tab ↹ or pressing a mouse button).

We see our input replaced with qu.

I deem this interference unreasonable, error-friendly and frustrating. If there is no way to disable it via Special:Preferences, then at least suggest which piece of your JS makes the bad change. Incnis Mrsi (talk) 15:41, 1 August 2021 (UTC)

You need to select the ru option from the dropdown list of ~4 options presented to you. If you merely tab, you in effect select the first on the list, which happens to be qu. You can argue that this is poor UI but. --Tagishsimon (talk) 21:09, 1 August 2021 (UTC)
The question (namely, how to identify and disable bad JS) was not addressed by Tagishsimon and stands intact. Dismiss the reply above. Incnis Mrsi (talk) 06:12, 2 August 2021 (UTC)
@Incnis Mrsi: you are blocked on multiple wiki's for the way you interact with other users. Please try to be civil and friendly. I'll give an example reply:
@Tagishsimon: thanks for your reply, but I'm still looking for the piece of javascript that is causing this. Do you have any idea what is causing this or how to find it? Multichill (talk) 18:21, 3 August 2021 (UTC)
t/y Multichill. I suspect tab selecting the top of the list of values is by design, not error. Seems useful to me, if a trap for the unwary. Incnis Mrsi would need to convince any of us that the behaviour is unreasonable, error-friendly and frustrating, rather than, say, quite handy, especially for lists of length 1. --Tagishsimon (talk) 18:37, 3 August 2021 (UTC)
Partial solution: disable the site ID to interwiki to be able to type ruw (for ruwiki) and similar. Found the source of interference with some help by Google many days ago; contrast it to human regulars who either contributed nothing or directed the thread to my person. Incnis Mrsi (talk) 16:11, 10 August 2021 (UTC)
You have still yet to establish that there is a problem, rather than a feature you dislike; per the above thread. --Tagishsimon (talk) 16:20, 10 August 2021 (UTC)
Am not obliged to Wikidata, and am not much interested which opinions hold the majority of regulars (or a plurality thereof). I deem jQuery.ui.languagesuggester intrusive and silly, whereas anyone is free to agree or disagree. Incnis Mrsi (talk) 08:37, 11 August 2021 (UTC)
Sure. But you'd need to build consensus that there is a problem in order to get a change made to the UI. As you don't seem to have any skills at all in that department, the probability that the UI will be changed as a result of your intervention is vanishingly small. So this whole thread works quite well as performance art, less well as a serious attempt to improve the WD UI. --Tagishsimon (talk) 08:46, 11 August 2021 (UTC)
The user interface is personal, isn’t it? Seriously we should remind it to a user who pops in a technical thread? Now look above: it’s allegedly Incnis_Mrsi who “doesn't seem to have any skills at all”. Incnis Mrsi (talk) 10:32, 12 August 2021 (UTC)
There's a single design of user interface, which we all use. If you wish to change the behaviour of the user interface, it changes for everyone. That's why consensus would be required. This is not difficult. --Tagishsimon (talk) 10:35, 12 August 2021 (UTC)

Addition and future update of References to WikiTree site for selected statements.[edit]

I intend to add references to some statements that have data available on WikiTree site for persons that are linked to https://www.WikiTree.com This is to addition to identifier WikiTree person ID (P2949) that is used on over 215K person pages. The properties I initially intend to add references to are:

The reference statements I intend to add are:

I also intend to maintain the references as the data on WikiTree changes in the future.

I have several Questions:

1) Should the reference also be added to the Identifier WikiTree person ID (P2949) defining the link?

2) What are the preferred statements in the reference for this case? Are the P248, P2949 and P813 optimal solution. I could add just some of them. I could also add more, like named as (P1810). I noticed that reference URL (P854) is often used, but I see no point in adding it, since P2949 already contains the link.

3) How are the references maintained in case of a change on the wikitree site. Should I only add additional reference to the new value with the new retrieved date? Or should the old reference be deleted? In case it should be deleted, should the old statement also be deleted if there are no other references on it?

4) Is there a statement, that I could use to identify the reference as automatically added by me. That way I would know that I can delete it if it is no longer valid.

5) I am doing all my updates using QuickStatements. Is that optimal/preferred way to do it.

Here is an example of how I would add a reference for the father. 

Q96305421	P22	Q96305756	S248	Q1074931	S2949	"Bennet-71"	S813	+2021-09-01T00:00:00Z/11

SparQL queries References to WikiTree Aditional statmentes on references to WikiTree

Thanks for your responses. Lesko987a (talk) 22:03, 1 August 2021 (UTC)

Good plan. 1. No need for reference; Id value links to wikitree (although retrieved (P813) maybe useful). 2. IMO it would be beneficial to have reference URL (P854), which makes it easier for users to traverse to the reference source. Schlepping down to P2949 will be non-obvious to many users, a PITA on items with very many statements. Useful to add named as (P1810) as a qualifier of P2949 since it can be useful for signalling mistakes, provding new alises, &c; but P1810 not required on each statement ref. 3. I think you can delete dead refs where you have a new valid ref to add. Otherwise, I think, leave in place. 4. Probably not. 5. QS works well, and your QS string looks good. You could also consider https://github.com/maxlath/wikibase-cli although in this case, probably not any great advantage. --Tagishsimon (talk) 22:34, 1 August 2021 (UTC)
1) I was thinking of adding retrieved (P813), but I do validate the property each week and correct them in case of a change or remove them in case the profile on WikiTree was deleted. So all WikiTree person ID (P2949) are up to date. 2) Adding reference URL (P854) doesn't add much to the reference, since P2949 is automatically translated to the target URL. It just adds another thing to maintain. I don't understand what PITA stands for. However adding named as (P1810) on Relatives statements seems like a good point. 5) I think I will have a problem with QS, since it can't delete a single reference. It seems only the whole statement can be deleted. I will have to find something else. wikibase-cli looks good, but I can't use JS apps on my end. Probably I will have to use API directly. Lesko987a (talk) 09:35, 2 August 2021 (UTC)
I made the first parent references for father: http://www.wikidata.org/entity/statement/Q100446957-43c5b448-6090-4fed-a8d2-342b00a47289 and http://www.wikidata.org/entity/statement/Q100447009-8ceb5020-72d3-4560-a450-7bd0ecf63da6 with
Q100447009	P22	Q100446957	S248	Q1074931	S2949	"Sears-62"	S1810	"Capt Paul Sears (20 Feb 1638 - 20 Feb 1707)"	S813	+2021-08-03T00:00:00Z/11
Q100446957	P40	Q100447009	S248	Q1074931	S2949	"Sears-63"	S1810	"Paul Sears II (15 Jun 1669 - certain 17 Feb 1740)"	S813	+2021-08-03T00:00:00Z/11
Would that be ok. Note that the "named as" contain the name of the relative. I guess that is the way it should be. Lesko987a (talk) 23:29, 2 August 2021 (UTC)
named as (P1810) should contain the name of the person (subject) of the item where you have set the statement. If you are wanting to record how the name of an object (relative) is recorded in the source, you will need to use stated as (P1932). From Hill To Shore (talk) 00:27, 4 August 2021 (UTC)
  • Great plan! "Named as" is important for wives, since they may be here in Wikidata under their married name, or maiden name, or a combo of the two with their maiden name as the middle name. --RAN (talk) 23:18, 3 August 2021 (UTC)
  • @Lesko987a: The referencing format should be Help:Sources#Databases, not Help:Sources#Web_page (with P854).
    I don't think it's acceptable to use Wikidata as a temporary mirror, that is to add and remove references and statements as the other database changes. Statements should be deprecated (or marked as preferred). See Help:Ranking about this.
    Also, can you spell out the agreed way of handling changing parent-child relationships somewhere (maybe Wikidata:WikiProject_Genealogy and mention in on the relevant property talk pages). I don't think Wikidata has well equipped to multiple hypotheses. --- Jura 06:08, 7 August 2021 (UTC)
    • I figured out it shouldn't be a Web Page (P854). But it is used by people Query.
      It is not meant as a mirror. but removing the wrong data seems like a reasonable thing to do. Having two fathers is always confusing. I guess queries ignore the deprecated rank. It can also be a case of invalid WikiTree Profile to WikiData Item match. You definitely don't need that as part of the history. Same goes for the Dates. There are cases of typos, conflicting sources, ...
      I wasn't aware of WikiProject_Genealogy. It certainly makes sense to move this discussion there. I will do it with some changes, that I already got resolved. Lesko987a (talk) 15:26, 7 August 2021 (UTC)
      • We don't want ever changing statements on Wikidata. Once it's added, only the rank should change or additional references added. Maybe you want to wait some time until you import new data from (or references to) Wikitree (e.g. 6 months after addition to Wikitree). --- Jura 07:59, 8 August 2021 (UTC)

Start time qualifiers that are aligned with an item's inception[edit]

I've run into this issue a few times and would like to see if the community can decide on the best way to handle it. Consider an item for a country that started off its existence called Foo and later changed its name to Bar. For official name (P1448), we'd want to have two values, with Bar preferred-ranked with reason for preferred rank (P7452) set to most recent value (Q71533355). For Bar, we'd want to have start time (P580) with the date of the renaming, and probably end time (P582) set to "no value" to indicate that the new name has persisted through the present. For Foo, we'd want to have end time (P582) with the renaming date, but what should we have for start time (P580)? In many places, I've seen it just duplicate the value of inception (P571), which is one way to do it. But another option would be to leave it out, since a property without a start time can be assumed to apply to the item starting with its inception. Going further down that path, the way we signify something is intentionally omitted is through setting it to "no value", so perhaps we should set the start time for Foo to "no value" just like we do for the end time of Bar. This would be more elegant, since it'd prevent us having to record the inception in multiple places, but it'd introduce the possibility of the "no value" being misread as the value having existed forever. What do you all think is best practice here? {{u|Sdkb}} talk 21:18, 3 August 2021 (UTC)

There does not seem a great problem in Foo having a start time equal to the Inception statement value (presuming that marks the start of Foo). All of the alternatives seem more problematical. Not least, failing to state the start time leaves the reader wondering whether or not it might be the same as the inception date, and WD best avoids this sort of ambiguity, at the small cost of duplicating values - but each time supplying them with a useful context: the start of the thing; the start of this name of the thing. --Tagishsimon (talk) 21:32, 3 August 2021 (UTC)
There is also "some value" ("unknown value") as an option, if you're not sure that was the name when the entity was created, or inception date is unknown. ArthurPSmith (talk) 16:43, 4 August 2021 (UTC)
Please do not set end time (P582) to no value. This is never correct.
--Quesotiotyo (talk) 02:45, 5 August 2021 (UTC)
@Quesotiotyo: Do you have any suggested alternative for indicating that something extends through the present? P582 doesn't have any way to set something to "present" that I know of. {{u|Sdkb}} talk 04:28, 6 August 2021 (UTC)
Why would you use end time (P582) for something that has not ended? Perhaps reading through Help:Evolving_knowledge will provide some clarity.
--Quesotiotyo (talk) 16:55, 6 August 2021 (UTC)
Interesting page, but doesn't look too developed. I think we'd want to have some way of being able to note that a value is current. Perhaps some additional tools are needed. {{u|Sdkb}} talk 17:11, 6 August 2021 (UTC)
It's both developed and accepted by the WD community. You're flogging a dead horse. There's no practical way of providing a no end date value that assures the reader that a statement is valid now. At best, we could conceive of a value which states that at this timestamp there was no end date, but as you'll appreciate, that timestamp will not be now, but whenever the statement validity was last checked. For practical purposes, the heuristic no statement end date and no item end date (e.g. date of death, date dissolved, abolished or demolished) = statement is valid seems to work about as well as at this timestamp there was no end date. --Tagishsimon (talk) 17:43, 6 August 2021 (UTC)
@Tagishsimon: The page is only 3500 bytes long, has seven edits over its lifespan, and when I just fixed some pretty glaring typos, my edit was the first since 2018. If that qualifies as a well-developed page, we're in serious trouble. I'm interested in discussing this topic to reach a consensus, since I haven't come across any substantial discussion on it before and have heard contradictory views/seen contradictory approaches in the showcase items. It's fine for you to have whatever views on the topic you have, but saying "stop making noise about this, it's already been discussed and settled" without pointing to any actual prior discussion on it or established guidance is not helpful. If such prior discussion does exist and just no one here has found it yet, that would genuinely be great and I'd like to see it. {{u|Sdkb}} talk 23:42, 7 August 2021 (UTC)
You've floated two suggestions here; an idea that statements should not have start time if the start time matches the inception ... although without explaining why that's a problem in the first place. The suggestion got no support and some knockback. Your suggestion number 2, is that statements should affirmatively specify that they have not ended. You've ducked the argument that such affirmation would always be historic, and thus not much more use than the current assumptions users work under; and you're instead arguing the toss over whether a help page which has been settled since 2018 is in fact settled. You say you want to develop consensus. But consensus is already well evidenced by the millions of statements which are not end dated, and by the absence of any mechanism - or indeed, demand for a mechanism, yours aside - for an affirmtive no-end-date solution. One of the excellent things about WD is how taciturn its users are; and in this case I think the users have spoken by declining to join in the conversation. So I say again: this horse is not pining for the fjords, but has in fact shuffled off its mortal coil. --Tagishsimon (talk) 00:42, 8 August 2021 (UTC)
I would just add that "a property without a start time can be assumed to apply to the item starting with its inception" is not true. Wikidata uses the w:en:Open-world_assumption so any information not present is not assumed (though obviously in practice it would be impractical to add a start time to every statement ever, my general rule of thumb is that if the statement applies for the entire item lifetime then there's no need). --SilentSpike (talk) 08:51, 5 August 2021 (UTC)
Ah, good point. {{u|Sdkb}} talk 04:28, 6 August 2021 (UTC)

Flying ace[edit]

I want to tag all the WWI flying aces, do you think it should be "award=flying ace" or "significant event=flying ace"? --RAN (talk) 17:23, 5 August 2021 (UTC)

Neither. It's not an award. It's not an event. Perhaps has quality (P1552)? --Tagishsimon (talk) 17:38, 5 August 2021 (UTC)
That sounds better, currently there is no one way they are tagged. --RAN (talk) 00:00, 6 August 2021 (UTC)
Occupation seems to be the most commonly used property for flying ace with over a thousand hits, eg Alan Jerrard (Q4706977) and Ernst Udet (Q57179) Piecesofuk (talk) 16:58, 6 August 2021 (UTC)
True - https://w.wiki/3nmC - yet it's well arguable that their occupation is aviator, whilst they have the distinction of being flying aces; & so occupation is a poor property choice. --Tagishsimon (talk) 17:48, 6 August 2021 (UTC)
  • there are several fields containing "flying ace", and many more unmarked, and some only marked in the description, that is why I want to harmonize it so it can be found in a single simpler search. --RAN (talk) 17:52, 6 August 2021 (UTC)
Occupation aviator with has quality (P1552) or subject has role (P2868) as qualifier is an option as well. subject has role (P2868) can be used as main statement as well. The most important thing is that we're consistent. I recently finished a similar project, where I harmonized the use of (super)centenarian. I settled on subject has role (P2868), see https://www.wikidata.org/wiki/Q312082#P2868.
There's a lot of these items that are used as a way of tagging items/people. millionaire (Q1075912) is another. Curiously, both of these can (sometimes) be inferred from other properties (net worth (P2218) and age at death). I don't think it'd be easy to settle on a single way of tagging, since it's dependent on what properties are available in the field of interest, but it's maybe something to think about. Or at the least we could start documenting the various approaches. --Azertus (talk) 15:59, 7 August 2021 (UTC)

Master’s student/advisor properties[edit]

In some fields, a master’s degree is a terminal degree (for example, architecture or fine art). So for these fields and academics in them, it is important to have properties master’s advisor and master’s student, corresponding to PhD properties doctoral advisor (P184) and doctoral student (P185). Does that make sense? Have I missed existing properties to use for these? Perhaps to limit clutter, they should only be used for such fields? —Michael Z. 18:31, 6 August 2021 (UTC)

You may be right that WD would benefit from master’s advisor and master’s student properties, but I'm not convinced by your assertion that some fields peg out at the Master level - https://www.arct.cam.ac.uk/courses/postgraduate/phd-in-architecture - https://www.southampton.ac.uk/wsa/postgraduate/research_degrees/courses/phd-fine-art.page --Tagishsimon (talk) 18:48, 6 August 2021 (UTC)
Having properties for noting Master's degree advisors would be benefiticial. Some universities may publish these metadata online. We also have opponent during disputation (P3323) and thesis committee member (P9161) which are general enough to be used for Master's theses as well. Vojtěch Dostál (talk) 06:15, 8 August 2021 (UTC)

Another "how to" question[edit]

How do I relate (link) Category:Songs written by Olcayto Ahmet Tuğsuz (Q32732721) with Category:Songs composed by Olcayto Ahmet Tuğsuz (Q32732722)? (BTW I cannot believe that this guy has created several songs for the Eurovision Song Contest and has no WP articles!..) --E4024 (talk) 15:07, 7 August 2021 (UTC)

Unique constraint violation with deleted object[edit]

Tracked in Phabricator
Task T272120
Tracked in Phabricator
Task T267175

Hello, the newly created object d:Q107986623 shows a unique constraint violation for GND and VIAF. According to the error message, GND and VIAF are also included in object d:Q107166925, which recently has been deleted. Can the two objects be merged? How can a deleted object have a VIAF and GND? --M2k~dewiki (talk) 21:19, 7 August 2021 (UTC)

Most likely lag in the system somewhere. The item was deleted earlier today. Grafana is showing only 30 mins WDQS lag right now, but WDQS thinks the item still exists - https://w.wiki/3oVe . The constraint warning arises from a WDQS query, afaik. So maybe the processing of deletions is delayed. Come back tomorrow, maybe. --Tagishsimon (talk) 21:34, 7 August 2021 (UTC)
Thanks a lot! Now the error message disappeared. The deleted object ID is still used in the VIAF record (see history of the VIAF entry): https://viaf.org/viaf/80232010/ --M2k~dewiki (talk) 21:43, 7 August 2021 (UTC)
Mmm. That's unfortunate. Don't quite know the background, but wonder if it's appropriate / possible to redirect from Q107166925 to Q107986623 - e.g. by undeleting and then merging? @Mahir256: based on https://www.wikidata.org/wiki/Special:Log?page=Q107166925 --Tagishsimon (talk) 21:50, 7 August 2021 (UTC)
I'd rather the lag take care of things rather than cave in to the contributions of a globally banned user. Mahir256 (talk) 22:00, 7 August 2021 (UTC)
We'll have to trust that VIAF is on the ball, then. --Tagishsimon (talk) 22:03, 7 August 2021 (UTC)
We need to find a list of VIAF entries referring items that no longer exists.--GZWDer (talk) 15:01, 8 August 2021 (UTC)
The unique constraint violation for GND and VIAF for d:Q107986623 and d:Q107166925 are now shown again in object d:Q107986623 (before, the error message disappeared after a while). --M2k~dewiki (talk) 07:35, 9 August 2021 (UTC)
WDQS still thinks the item exists. Given the constraint violation appears and disappears, the probability is that the item exists on some of the WDQS servers, does not exist on others. A trip to phab is indicated. --Tagishsimon (talk) 07:56, 9 August 2021 (UTC)
Deletions on query server are currently "manual", i.e. WMF launches a script that deletes items (and lexemes) once in a while. There was a report about it at Wikidata:Contact the development team/Query Service and search, but somehow GZWDer made it complicated to find it. --- Jura 08:57, 9 August 2021 (UTC)

Wikimania talk - input on important stuff over the last year[edit]

Hey folks :)

I have a talk at Wikimania in about a week to talk about cool/interesting/important things that happened around Wikidata over the past year. If you have something that you think is important to mention please let me know.

Cheers Lydia Pintscher (WMDE) (talk) 14:05, 8 August 2021 (UTC)

Hello @Lydia Pintscher (WMDE): some of the projects of the german languages communities (Wikidata:WikiProject Germany, Wikidata:WikiProject Austria, Wikidata:WikiProject Switzerland)) have been working on:

  • There was COVID and we got a lot of new data on case numbers, publications and hospitals. --- Jura 09:00, 9 August 2021 (UTC)
See Wikidata:WikiProject_COVID-19. --M2k~dewiki (talk) 09:03, 9 August 2021 (UTC)
  • A considerable number of authority control resources from libraries were identified and its identifiers added to Wikidata: User:Epìdosis/Koha. --- Jura 09:05, 9 August 2021 (UTC)
  • Sizes of country items (like "Portugal" (Q45)) were recently reduced by 30% to 50% by moving a few economics properties to "economy of"-items (sample: "economy of Portugal" (Q1649355)). The item "economy of Portugal" ended up being larger than "Portugal". This can simplify uses of country items that previously timed-out. Infoboxes can still access the properties with the link through "economy of topic" (P8744). --- Jura 09:11, 9 August 2021 (UTC)


Thanks so much everyone! I'll not be able to mention all of it but I'll try to cover some. <3 --Lydia Pintscher (WMDE) (talk) 18:39, 9 August 2021 (UTC)

  • Several Lexeme contests, tools and many imports. --Infovarius (talk) 09:34, 12 August 2021 (UTC)

Double entry, single Dutch something[edit]

Q7497525 ("Shinichiro Kobayashi"), which until today propagated the fiction that Kobayashi was born in 1939, is about the same person that Q17222216 ("Shin'ichirō Kobayashi") is about. Some joker dreamt up 1939 for this unreferenced edit, which I fixed today (14 months later). (The man's name is normally pronounced in Japanese Kobayashi Shin'ichirō. Kobayashi is the surname; the order is normally reversed for anglophone consumption. Macrons and apostrophes are often dropped.) Really, it's the same one person, born in 1956. I fixed the fictional YoB in Q7497525 and then attempted to use Special:MergeItems, but was told (in red!) "Failed to merge Items, please resolve any conflicts first. / Error: Conflicting descriptions for language nl." Maybe I'm sleepy, but I don't notice anything Dutch here. Over to you! -- Hoary (talk) 00:32, 9 August 2021 (UTC)

Done? --E4024 (talk) 00:47, 9 August 2021 (UTC)
Thank you, E4024. I was going to merge them in the opposite direction, but I don't suppose that the direction matters. I have to say that I'm most puzzled by all this use of "imported from Wikimedia project: [language] Wikipedia"; I'd been intending to add this (PDF of a leaflet put out by a museum) and similar as references wherever possible: but hadn't yet figured out how to do so: WD seemed to demand an item, and I was deterred from creating one by the warning that an item had to be "notable", and surely a single sheet of A4 was not notable. -- Hoary (talk) 02:07, 9 August 2021 (UTC)

Bot mistake[edit]

Some bots (or scripts, templates, whatever it is called) make a strange Turkish language description for names. Please use "kadın adı" for female given name and not "kadın ismidir" which means "It is a female name." (You cannot write a complete sentence w/o capitalization and the full stop.) Same thing for male given name. Plase change the Turkish description script to "erkek adı". "erkek ismidir" is a complete sentence, as such unnecessary, and written in a wrong way w/o capitalization and full stop. Both these options use a now forgotten Arabic word "isim" instead of the modern and pure Turkish "ad/adı". BTW surname = soyadı. --E4024 (talk) 01:57, 9 August 2021 (UTC)

@Jura1: Yours: https://www.wikidata.org/w/index.php?title=Q21401534&type=revision&diff=912121647&oldid=912121361 --Tagishsimon (talk) 10:39, 9 August 2021 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ It is not a great issue, but what I defend is better. Nobody would support an old word like "isim" among Turkish participants. "Complete sentence" is a common fact; I understand we avoid them. Less we would make any without capitalization nor adding a period/full stop at the end. (OTOH the script correctly uses soyadı for Turkish and not "soyismi" or "soyisim". Ask a primary school student these two latter words and probably s/he will not understand.)

BTW at the above thingy I just noticed something like 'İtalya\'nın Komünleri'... In Turkish we do not write ordinary nouns with a capital letter. It should be İtalya'nın komünleri. (I ignore if the slush sign thereat responds to any technical necessity.) Always ready to help with Turkish wording. Thanks for the input. --E4024 (talk) 15:33, 9 August 2021 (UTC)

@E4024: Looks like the .js is being maintained, in response to requests made on its talk page - MediaWiki talk:Gadget-autoEdit.js. That's probably the best place to take this next so as to improve handling of Turkish. --Tagishsimon (talk) 16:52, 9 August 2021 (UTC)

Wikidata weekly summary #477[edit]

Wikidata-logo-en.svg
Here's your quick overview of what has been happening around Wikidata over the last week.
  • Development
    • Mismatch Finder: Finishing work on importing mismatches and moved on to building the API for retrieving mismatches from the mismatch store.
    • Added tags for all edits done through the UI to more easily distinguish them from edits made through tools and other means (phab:T236893)
    • Moved regular expression checking for constraints from the SPARQL endpoint to a dedicated service to make it faster and put less stress on the SPARQL endpoint (phab:T176312)

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Read the full report · Unsubscribe · Mohammed Sadat (WMDE) 14:56, 9 August 2021 (UTC)

Welcome, Manuel![edit]

Hey everyone :)

I’m super excited to announce that Manuel Merz has joined the Wikidata team as Analytics Product Manager!

Manuel and I will work closely together in supporting Wikidata’s development and you all. As Wikidata's second product manager, Manuel will especially focus on strengthening our data analytics and long-term maintenance work. This includes the product responsibility for bug reports from the Wikidata community, so you will see him more and more on Phabricator.

Manuel is a long-time Wikimedian: He started as a volunteer Wikipedia editor in 2006, has built up Wikimedia Deutschland's impact orientation since 2012, and in 2019 in his free time, he published his Ph.D. thesis on the Wikipedia community. He also runs a small software development company which aids to his product management experience.

Please leave a note on his talk page at User:Manuel Merz (WMDE) or write to him directly anytime at manuel.merz@wikimedia.de. He will also be at Wikimania, e.g. the Wikidata Pink Pony session, so this would be an excellent way to get to know him!

Manuel, it's great to have you on the team!

Cheers --Lydia Pintscher (WMDE) (talk) 18:45, 9 August 2021 (UTC)

New WikiProject: Neighborhood Public Art in Boston[edit]

Hi, we've just started a new WikiProject focusing on public art in Boston neighborhoods, starting with Roxbury (Q20138) and South End (Q2304457)). It's still early days; we'll be expanding the project page with more details, but would definitely welcome feedback and/or new participants. Thanks! --Ballerlikemahler (talk) 20:40, 10 August 2021 (UTC)

How to mark items of nonsense/unidentifiable subjects? GeoNames problem.[edit]

Many items based on ceb+sv Wikipedia articles are linked using GeoNames ID (P1566) to GeoNames (Q830106), a low quality "geographic" project with many errors, nonsenses, garbled names, and inaccurate or nonsensical coordinates. In some cases, it is possible to trace which subject the item should apply to, and then the coordinates and name can be corrected. But what about such items, where the data are so erroneous and ambiguous that they cannot be assigned to any real place and object? Is there any property that can be used to mark an item as invalid or untrusted without suggesting that it be deleted? (See Červený Potok (Q23821033) as an example – there exist many watercourses called "Červený potok" but none of them at the coordinates stated here.) --ŠJů (talk) 15:19, 11 August 2021 (UTC)

Maybe X instance of (P31) possibly invalid entry requiring further references (Q35779580). --Matěj Suchánek (talk) 09:45, 13 August 2021 (UTC)
  • So many typographical errors and duplicates, we worked for months to merge duplicates and flag errors. But, to be fair, all large data sets contain errors. We have lists of them awaiting correction at the source here: Wikidata:WikiProject_Data_Quality. It also has a list of queries we run to identify errors. For instance VIAF contains error that are caused by Wikidata, they mirror OUR errors when we do a bad merge by conflating people with a similar name. --RAN (talk) 17:18, 13 August 2021 (UTC)

Istanbul Airport (Q3661908)[edit]

The Airport was inaugurated on 29.10.2018 but began functioning on 05.04.2019. I could not find out how to introduce this "operational since" date. --E4024 (talk) 15:51, 11 August 2021 (UTC)

service entry (P729) maybe? --Tagishsimon (talk) 16:33, 11 August 2021 (UTC)
Exactly! Tyvm. --E4024 (talk) 16:41, 11 August 2021 (UTC)

fr-N[edit]

Please someone tell me where was the charismatic French actor Grant Lawrens born ("Où es-tu né?").  – The preceding unsigned comment was added by Coagulans (talk • contribs) at 16:58, August 11, 2021‎ (UTC).

How to return administrative / municipal boundary data (e.g. city, township) based on a Wikidata ID?[edit]

I'm trying to use the Wikidata Query Service to return the geojson polygon data for administrative boundaries, based on a Wikidata ID.

For example, given the Wikidata ID for Chicago (Q1297), I would like to return the geojson polygon information for it. I'm trying to use this query in the SPARQL Editor:

SELECT ?item ?itemLabel ?geoshape ?geoshapeLabel WHERE { 

 VALUES ?item { wd:Q1297 }
 ?item wdt:P3896 ?geoshape.
 SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }

}

But I'm getting "No matching records found."

Is there a problem with my syntax in the query statement? Is what I'm trying to do possible? Any help would be much appreciated

Chicago (Q1297) does not have a geoshape (P3896) statement. As a proof of concept for your report, here it is with Spain (Q29) added as a VALUE.
SELECT ?item ?itemLabel ?geoshape ?geoshapeLabel WHERE {

 VALUES ?item { wd:Q1297 wd:Q29 }
 ?item wdt:P3896 ?geoshape.
 SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }

}
Try it! --Tagishsimon (talk) 20:10, 11 August 2021 (UTC)

Yet another "How to" question[edit]

Hello! What's the correct way to link to a former official website of a defunct project? The domain name was obtained by a third party and doesn't point at the said website anymore. Myuno (talk) 20:00, 11 August 2021 (UTC)

Presuming it needs doing, either or both of, add an end date qualifier; and set the rank of the current official website to 'preferred' whilst leaving the former official website statement as 'normal'. --Tagishsimon (talk) 20:12, 11 August 2021 (UTC)

Separate entries for persons and for biographical articles[edit]

I posted in Requests for comment, but this may be a better place. I am working on naval biographies, and have found several people who have entries for both the person and one of more biographical articles, for example John James Onslow (Q5933370) (British Royal Navy officer}; Onslow, John James (Q96779042) (entry in the Royal Naval Biography); and Onslow, John James (NBD) (Q24020295) (entry in the Naval Biographical Dictionary). There is no apparent link between these items, which is not helpful. I can see two possible approaches: (1) merge the items into a single person item with the biographies specified by "described by source (P1343)"; or (2) to retain the existing items and add a "main subject (P921)" property to each of the biographical items to refer to the person. Is there a policy/preference on this? Thanks Kognos (talk) 20:13, 11 August 2021 (UTC)

The more important of the two is main subject (P921) to point the biog item at the person item. However described by source (P1343) from the person to the biog item is also welcome. A person item is quite useful even if it does not point to all/any biographical sources. A biography item is less useful if it does not identify the subject of the biography. --Tagishsimon (talk) 20:22, 11 August 2021 (UTC)
@Kognos: because the biography item in your case has more information than just an external web link (it has an author and a link to Wikisource), it would not be possible to merge the two items by distilling the biography item into a single statement and adding that statement to the person item. Mahir256 (talk) 20:25, 11 August 2021 (UTC)
Thanks, very helpful Kognos (talk) 20:54, 11 August 2021 (UTC)

Wikidata Query Service (WDQS) User Survey 2021[edit]

In the 2021-2022 fiscal year, the WMF Search team is working on scaling up Wikidata Query Service (WDQS) to handle increasing graph size and queries -- we will be following up shortly with more updates regarding this. In order to design a querying service that works for most use cases, it is important for us to understand the needs of WDQS users.

We are trying to cover the diverse use cases of WDQS. Whether you are an occasional user of the service, running queries regularly, for example for maintenance purposes, or hitting the WDQS daily with your tools, your feedback is welcome on this short survey. If you are interested in providing feedback, please fill out our survey: https://docs.google.com/forms/d/e/1FAIpQLSe1H_OXQFDCiGlp0QRwP6-Z2CGCgm96MWBBmiqsMLu0a6bhLg/viewform?usp=sf_link

Thanks for your participation!

This survey will be conducted via a third-party service, which may subject it to additional terms. For more information on privacy and data-handling, see the survey privacy statement For technical issues with the survey, please contact mpham@wikimedia.org MPham (WMF) (talk) 15:44, 12 August 2021 (UTC)

Notability of aircraft[edit]

A very simple question: are planes, helicopters etc. (I mean indvidual ones, not types etc.) notable enough to have their own individual items, named most likely after their registration? For ships the answer is yes, as far as I can see, but what about aircraft? Many have their categories on Commons, but I know that is obviously not enough as a reason at WD. I'm looking forward to reading your opinion. Powerek38 (talk) 17:27, 12 August 2021 (UTC)

They meet WD:N criteria 2; aircraft have long been publicly documented for the plane spotter community, and authorities such as the UK CAA make their register publicly available. [3]. A rough count of the figures in w:en:List of most-produced aircraft suggests ~1M aircraft have been built. So, on the face of it, in scope and not of a volume that would cause great concern. --Tagishsimon (talk) 19:43, 12 August 2021 (UTC)

Some script issue?[edit]

I see that several items, when added a German description, lack letters. Example: Selin Sayek Böke (Q21044822). The German description says "ürkische Wirtschaftswissenschaftlerin". I am correcting this to türkische Wirtschaftswissenschaftlerin, w/o knowing German, but I assure you this is not the first such case I noticed. I corrected several others time ago, although I do not remember the item titles now. Somewhere there must have been an issue that causes this. --E4024 (talk) 20:33, 12 August 2021 (UTC)

The editing was definitely done by the Edoderoobot. But it's new to me that bots write German descriptions. To be honest, I've never seen this before. --Gymnicus (talk) 20:39, 12 August 2021 (UTC)
Some more, fwiw. --Tagishsimon (talk) 21:08, 12 August 2021 (UTC)
Clear mistake, of course “türkischer” (men) and “türkische” (women) ist correct. According to this edit there might be a problem with Edoderoobot’s edits taken from w:Vorlage:Personendaten. I fixed 9 women but there are still 75 “ürkischer” men left. --Emu (talk) 21:10, 12 August 2021 (UTC)
✓ Done per Edit group 7f8c4d478c9 --Emu (talk) 21:21, 12 August 2021 (UTC)

subclass[edit]

There is an unsolved conflicting type constraint regarding musical ensemble (see ABBA). It notices that a musical group is a group of humans but it is not a human.
human and group of humans are not effectively connected. - Coagulans (talk) 22:07, 12 August 2021 (UTC)

It would be helpful if you could point more precisely to an instance of the issue. The item for Abba does not have a value of musical ensemble; items that do, do not have a type constraint issue that I can see. 'group of humans' is connected to 'human' ... effectiveness, or not, perhaps rests more with the setup of the constraint than the contents of the item? As I cannot see an instance of the issue, and as you have not pointed to the property on which the constraint exists, I think we might be in the dark. --Tagishsimon (talk) 22:23, 12 August 2021 (UTC)
12 IDs with type constraint issues on ABBA page: Munzinger, Theatricalia, RollDaBeats, Victoria and Albert Museum, Juno Download, Moov, NME, The DJ List, IFPI Danmark, SNEP, AccuRadio, Filmdatenbank. "Entities using (...) ID property should be instances of human (or of a subclass of it), but ABBA currently isn't." - Coagulans (talk) 01:36, 13 August 2021 (UTC)
So the cure is to fix the constraint definitions: example. --Tagishsimon (talk) 08:55, 13 August 2021 (UTC)
For all of them? There are a lot of person IDs on WKD. It's about the absurdity of actually dealing with "human" and "group of humans" as if they were totally unrelated entities. We should find a way to effectively connect them. - Coagulans (talk) 11:12, 13 August 2021 (UTC)
They /are/ effectively connected. But constraint type definitions look either for instance of or subclass of, and a group of humans is not an instance of or a subclass of a human. It isn't really too much to ask that the constraint type statement for a property carries the values necessary to make it perform correctly; that is preferable to requesting a bodge to the modelling of the connection between group of humans, and human, to avoid setting up the constraint definition properly. As for quantity, see Quickstatements. --Tagishsimon (talk) 11:26, 13 August 2021 (UTC)
They are inconsistently connected. The item for group of humans is a subclass of group of living things but human is not a subclass of living thing (just a metaclass), hence the issue mentioned. - Coagulans (talk) 17:57, 13 August 2021 (UTC)
It may well be the case that there is inconsistency in how both of them are connected to other things, but that has no bearing on the constraint violation issue you raised. There is a lot wrong with many WD class trees. --Tagishsimon (talk) 18:53, 13 August 2021 (UTC)
Indeed, it wouldn't solve the problem. Maybe human or group of humans? - Coagulans (talk) 19:10, 13 August 2021 (UTC)
The search for the w:en:Philosopher's stone continues. --Tagishsimon (talk) 19:17, 13 August 2021 (UTC)

Using Wikidata as vanity spam?[edit]

Added today on Wikidata, with a Commons pic, is what I believe is a blatant piece of vanity spam with obvious spam links... i.e. using Wikidata as a personal promotional web space, see here. Can those who have greater Wikidata experience, and editorial oversight, please look at this? Thanks. Acabashi (talk) 10:18, 13 August 2021 (UTC)

Yes. Very spammy. Have asked for its deletion. --Tagishsimon (talk) 10:27, 13 August 2021 (UTC)
Good catch. Just blatant self-promotion. --Christian140 (talk) 10:47, 13 August 2021 (UTC)

content analysis property?[edit]

Hello. For items representing bibliographic citations, is there a property that one could use to link to relevant content analysis? For example, the textual analyser Voyant Tools (Q28405731) produces a summary analysis of words in this article. Is there a corresponding content analysis property? Thanks. -- Oa01 (talk) 14:27, 13 August 2021 (UTC)

Presuming there isn't, one could use described at URL (P973) with a qualifier object has role (P3831) taking a value such as content analysis (Q653137). --Tagishsimon (talk) 14:35, 13 August 2021 (UTC)
@Tagishsimon: Thanks for the suggestion! Tried it out here. -- Oa01 (talk) 14:51, 13 August 2021 (UTC)
is there value in such links? BrokenSegue (talk) 14:39, 13 August 2021 (UTC)
It's a different way of reading. Useful for quickly understanding a work, for example. -- Oa01 (talk) 14:56, 13 August 2021 (UTC)
I'm not questioning the value of content analysis. I'm questioning the value of the links. I assume these are machine generated so every document could have such a link. BrokenSegue (talk) 15:07, 13 August 2021 (UTC)

Idea: 2 types of deletion[edit]

  • Soft deletion (the item will be possible to be "recycled" with any content) E. g. let's say that:
    a deletion discussion on Q9876543210 closed with soft delete due to no notability. Then an administrator could soft-delete Q9876543210, and when one finds a link to Q9876543210, one could make it with a notable subject and sources.
  • Hard deletion (the item isn't possible to be recycled, only undeleted. This is what we have.)

This allows for fewer item names that just exist unused because they got deleted and can't be recreated. Comments on this? Alfa-ketosav (talk) 16:43, 13 August 2021 (UTC)

Recycling item IDs such that at time a they mean one thing, and time b they mean another, is a poor idea, for the reason that we do not know what third party uses have been made of the ID whilst it was associated with its first meaning; and so changing the meaning is liable to make things that point to the ID point to a thing with, in context, a 'wrong' meaning. Besides which, there is no shortage of numbers; no reason to try to conserve and re-use numbers. --Tagishsimon (talk) 17:32, 13 August 2021 (UTC)
Generally, ID stability is a value for databases and while Wikidata isn't always perfect about upholding it this proposal means that we would be worse at that metric while we get little in return. ChristianKl ❪✉❫ 20:32, 13 August 2021 (UTC)
One idea is to redirect all soft-deleted items to one item, though it may break if there are external sites referring to such IDs.--GZWDer (talk) 01:05, 14 August 2021 (UTC)

Mistakes in TR:WP[edit]

Mistakes in TR:WP cause issues like this. This is not a disam page; it is only about a "mahalle" (small urban settlement). Can someone make it only a "mahalle" (neighbourhood) item in so many languages please? We need a bot. --E4024 (talk) 20:20, 13 August 2021 (UTC)

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=1479997727"