| Yurik added a comment. |
@thiemowmde @daniel my last patch only refactors Wikibase extension a bit, without touching the data model. It fixes the last few places I found that used direct Item ID parsing/composition, instead using the same common interface used by other code. Are there any concerns with that? For example, Lua function getSiteLink() used TermIdconstructor, whereas all other code in that same file used EntityParser instance.
Merging this code should be a noop for Wikidata, and it may even simplify T114904 -- all related code may be in one place. Or it certainly shouldn't get in the way of the db migration.
So if this patch has no impact on Wikidata, but helps us, could you merge it to help us?
I do understand your point about the UI, but sadly that's the problem -- it is not just UI issue in OSM. The OSM ecosystem is much less centralized than Wikidata. There is no single editor to make it consistent. There is no common validation system. There is really only one "convention" that all tools understand -- that OSM data is stored as a simple key-value string table. Tools do not assume anything else about the data, e.g. semantic meaning of the keys, etc. So it is almost always up to the users to type in or copy/paste all values.
One of the conventions is how Wikidata Q items are entered - e.g. wikidata = Q42. Any user in any tool can instantly tell that Q42 is a Wikidata item, and some tools even make it into a link using heuristics, e.g. if the key contains the word wikidata, and the value matches Qnnn regex, it shows as a link, but other tools simply show it as text. Most OSM users by now are fairly well versed in this.
If we introduce OSM Wikibase, it will be stored in the same way - a text string, with some key. For example, if community decides to introduce a few items in OSM Wikibase, e.g. "type of OSM feature", and possibly one more "something else", the feature key-value table would look like this:
| key | value |
| feature_type | Q123 |
| wikidata | Q456 |
| something_else | Q789 |
As you can see, this is very confusing. We cannot suddenly change how we store Wikidata items - that will break all of the existing tools and data consumers. Requiring an`osm:Q123` style for osm-stored items would also lead to problems - many users will simply forget to type it in, and multiple OSM editing tools make it impossible to effectively enforce it. Having no way to visually distinguish the source of item will potentially create a chaos.
I have already extensively tested my patch, and it seems that it solves what we need - effective way to store "osm items" as having different prefix. I'm sure I can work with other tools to adapt them to this need as well.
Cc: WMDE-leszek, Lydia_Pintscher, thiemowmde, Bugreporter, gerritbot, daniel, Aklapper, Yurik, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
