With #Wikidata increasingly used and gaining traction in academic contexts (including #GLAM ), we should engage with the larger community in earnest. I just became aware of the discussions around the reform of current notability policies: https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Notability_policy_reform. Even though this seems mainly focussed on self-promotion, it also addresses the underlying infrastructural problems of the platform by limiting the growth of the knowledge graph, and might heavily impact what we can and cannot do with Wikidata.

We should therefore seriously engage with the issue and participate in the discussion.

Also tagging some colleagues active on the Wikiverse: @JensB @awinkler @rettinghaus

#WikiKult #OpenGLAM #DigitalHumanities @dhandlib

Wikidata:Requests for comment/Notability policy reform - Wikidata

@tillgrallert @JensB @awinkler @rettinghaus @dhandlib

Highly relevant point, I agree!

These notability requirements on Wikidata are one of the reasons why we decided to use a separate Wikibase.cloud instance for our work on mapping the #DigitalHumanities.

We need to be able add people and groups no matter what level of notability they have outside DH.

But the downside of a separate instance is huge, with a lot of duplication of entites (e.g. places and universities) and effort.

@tillgrallert @JensB @rettinghaus @dhandlib thanks for pointing to this issue! I'm not entirely sure about the underlying causes. I'm not convinced by technical limits (there are very likely technical solutions) and very hesitant wrt social limits (would they be resolved if everybody moved to their own wikibase instance?). Moving away from the WD main instance comes, as @christof has written, at a high cost and is, in my view, very risky. At least for the communities I'm concerned with.
@awinkler @JensB @rettinghaus @dhandlib @christof Absolutely agreed. However, we have seen the recent graph split and its effect on Wikidata-centred knowledge ecologies. Scholia’s “temporary” move to qlever should be seen as an indicator of the larger problems in this regard. To my knowledge, there is no reliable and performant implementation of federated queries (which is THE bummer of the semantic web vision, imho).
@tillgrallert @JensB @rettinghaus @dhandlib @christof I'm probably missing something, but so far the major bottleneck for federation in my use cases was the performance of the sparql engines (leaving aside the very availability of rdf data ...). qlever is a huge leap forward, i think. Federation among qlever endpoints works really well. With increasing performacne, we'll hopefully discover interesting scenarios for federation.
@tillgrallert I raised this in a conversation with Wikimedia UK folk recently. I'd respond to the consultation but the structure is a bit confusing - I'm not sure which questions are considered settled and which are still open for discussion
@mia I find these comment pages extremely confusing too. One can reply to each and every comment but it’s not clear where it would matter and to whom
@tillgrallert I'm kinda glad it's not just me, but it's also a bit depressing. How many norms does one need to know before commenting?
@mia and where to find them? These opaque (at least for me) decision making processes are currently the largest obstacle to convincing more people to actively contribute to the Wikiverse. It always feels as if a) there is a widely accepted and well-established process and b) that somehow I am the only one not aware of this common knowledge. A bit like the Fediverse, now that I think about it.

@tillgrallert @JensB @awinkler @rettinghaus @dhandlib

reminds me of https://fedihum.org/@scigma/115951194032704089

Using wd for a project's own research data cannot justify notability for each and every item, and cannot take the risk to loose some to a policy change later on.

In the wd discussion, underlining the diffs between wd and wikipedia is very convincing.

Wikidata items are, to start with, an existential quantification: ∃ THERE EXISTS.

@FactGrid is another stakeholder here.