| daniel added a comment. |
In T211800#4830605, @WMDE-leszek wrote:
- Having two not-necessarily same config flying around and parts of code arbitrarily picking one config, and other parts picking up the other seems like a bug/unfinished implementation to me. I am surprised it only surfaces now (it has been for 99% me who had messed that up), but should be fixed. If the current "broken" state actually makes commons work the fixing schedule can be of course postponed :)
That's indeed the current situation, yes. It's a consequence of the fact that client and repo are independent extensions, none of which depends on the other. But yes, both should share config for the DataAccess component, but doing so would be incompatible with the requirements and data we have.
- I don't claim to have the thorough understanding of the Commons issues now, but it seems to me that those two kinds of federation, i.e. one intending to have different entity types in different repos, possibly having e.g. items from multiple repos, and the one where it is clear some entity types are coming from repo A, and some from repo B are actually separate things, they're not really overlapping. The former requires and is based on the concept of prefixes (to be able to distinguish between different sources of items), whereas the latter could actually do without having prefixes at all. Both make sense as separate approach (the former for non-Wikimedia Wikibases, the latter for Commons, for instance). I am not aware of any practical or planned instance where mixing both concept would actually be needed. Therefore I would strongly encourage to NOT mix both approaches in the implementation and to NOT create a super generic federation where all the things could be done using some config magic. The existing stuff is already overly complicated. Let's at least not make it worse.
I tend to agree, but I'd like to further discuss with you how much of a difference this really makes in the code, how confusing a "mixed" config is, and what options a wikibase instance may have to go from one model to the other. We'd probably have to provide conversion scripts.
Coming back to the particular Commons topic: from WMDE perspective option 3 is really something we would not like to see added as the feature etc. I do understand that converting millions of Commons pages to just change Qxyz to wd:Qxyz is going to be a costly migration. We're happy to help with coming up with some temporary/intermediate solution that would allow Commons running while the migration is on-going.
I don't think we can target that solution without consulting the community. And in the light of what you said above, commons seems to fit the "no prefix" case, where we could just map entity types to repos.
That said, I am wondering whether from Commons perspective using prefixes is something what's intended? Or actually the opposite? I am not aware (as in: I simply don't know) whether prefixing Wikidata items on Commons has ever been discussed in previous 2 years. Or has it been simply assumed "we need to add prefixes because this is what software requires"? Or did we in the first place implement the wrong feature few years ago?
Using prefixed to access wikidata has not been proposed to the community, and was never the plan. To my knowledge, "option 2" in this ticket is the first time it has been proposed. And yes, the only reason to do it is because that's how the software is currently designed.
This was recognized as an issue when we first designed federation, and we discussed the idea of mapping entity types to repos, but this was put off for later, and then forgotten...
Finally, I have to admit that being away from IRC for a while I don't feel like I am fully up-to-date with the status of federation between Commons and Wikidata. My assumption was the recent Daniel's change to beta commons config allowed to use beta wikidata items on Commons and all seems fine for now? Is this correct, or is it all still completely broken?
beta-wikidata items and properties can be used on beta-commons now, in both repo (with prefix) and client (without prefix) code. But accessing MediaInfo from wikitext is not possible there. It's a bit tricky to test, since the UI for adding statements is currently disabled.
Regarding the most recent report above. @daniel could you please elaborate more what exactly does not work once you've verified whether it does or not? Having more information would make it easier for us (at least for me) to reason about the problem.
See my comments above.
Cc: WMDE-leszek, Cparle, Jdforrester-WMF, Abit, EBjune, Ramsey-WMF, Aklapper, daniel, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Anooprao, SandraF_WMF, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Silverfish, Poyekhali, _jensen, D3r1ck01, Susannaanas, Wong128hk, Jane023, Wikidata-bugs, Base, matthiasmullie, aude, El_Grafo, Dinoguy1000, Ricordisamoa, Wesalius, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
