thiemowmde added a comment.
We discussed this in todays story time. We decided this should be a blocker for … - T73996: [RFC] Find a way to make global item ids <https://phabricator.wikimedia.org/T73996> - T76005: support multiple repos in one client <https://phabricator.wikimedia.org/T76005> - T76007: add ability to link/refer to foreign items and properties (federation) <https://phabricator.wikimedia.org/T76007> - T101752: [RFC] Introduce ExternalEntityId <https://phabricator.wikimedia.org/T101752> …, erm, why are there so many tickets with the same intent? Anyway, we decided this must be considered to not break stuff twice. Why? Because instead of introducing a new property type (or even a new value type, which is what https://phabricator.wikimedia.org/T101752 is about) it was suggested to make the existing EntityIdValue type more generic. What is this about? ------------------- Look at https://www.wikidata.org/wiki/Special:EntityData/Q21632765.json and search for "numeric-id". That's what we want to get rid of. Here is the relevant JSON snippet, representing an EntityIdValue: "value":{"entity-type":"item","numeric-id":184} Original proposal: Turn into string ----------------------------------- "value":"Q184" Issues: - The moment we want it to support items from an external repository (e.g. Commons should use the wikidata.org items), this must change again into something like `"value":"wikidata:Q184"` or even `"value":"http://www.wikidata.org/entity/Q184"`. - All ids must have a prefix then, even all internal ones, wasting massive amounts of bytes. Having ids with and without prefixes would be a bad hack, since this means `:` is not allowed in internal ids any more. - A string like `wikidata:Q184` combines two facts in one field, violating a basic database design principle. Todays proposal: Keep object ---------------------------- Note: I'm suggesting the new keys "repo" and "id" here. This can also be something else, e.g. "serialization". "value":{"repo":"wikidata","id":"Q184"} A format like this allows for a much more convenient migration path including a deprecation phase, which could look like this: "value":{"repo":"wikidata","id":"Q184","entity-type":"item","numeric-id":184} Advantages: - Makes it possible to add keys later, including full URIs and URLs (derived values, see https://phabricator.wikimedia.org/T118860). - Migration is possible. - The `repo` key can be omitted for internal links, saving bytes. Disadvantages: - Wastes bytes, compared to `"value":"wikidata:Q184"`. - Users can mistakenly ignore the `repo` part (no matter if it's always there or omitted for internal links) and think this is a link to https://www.wikidata.org/wiki/Q184. This can't happen with URIs like `wikidata:Q184`. Both proposals combined ----------------------- "value":{"id":"wikidata:Q184"} Issues: - Wastes bytes, compared to `"value":"wikidata:Q184"`. - Again, it's not possible to omit the prefix. - We can not start with `"id":"Q184"` and add the prefix later, since this would be an other breaking change. TASK DETAIL https://phabricator.wikimedia.org/T56085 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: thiemowmde Cc: thiemowmde, hoo, Jimkont, Ricordisamoa, Sumit, Lucie, Aklapper, Wikidata-bugs, Denny, JeroenDeDauw, Lydia_Pintscher, daniel, D3r1ck01, Izno, aude, Mbch331 _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
