[Wikidata-bugs] [Maniphest] [Commented On] T101752: Introduce ExternalEntityId
daniel added a comment. In https://phabricator.wikimedia.org/T101752#1350742, @JeroenDeDauw wrote: 3rd party wikis using Wikidata items as unit identifiers. Can you be more specific? I'm guessing you are talking about third party wikis running a Wikibase Repository, and have items in there with entityid datavalues pointing to Wikidata? Yes, in EntityIdValues, but also as unit URI in QuantityValue, calendar URI in TimeValue, and globe URI in GlobeCoordinateValue. I see no breaking change nor a contract change. Will all code that currently works with an EntityId do the correct thing when it gets such an instance of this new derivative? I don't think so. Code that uses getNumericId will break. The assumption that getNumericId exists is invalid,, but still made in some parts of the code. Other than that, I can't think of any issues. EntityId is completely opaque. In https://phabricator.wikimedia.org/T101752#1352159, @mkroetzsch wrote: I would suggest to use this and to store pairs sitekey,localEntityId and to have the URI prefix stored in the sites table. It's cleaner than storing the actual URI string (which might change if an external site is reconfigured!) in the actual values on the page. Cool URIs never change :) Yes, I have been thinking about this too. May be an option, not quite sure yet. A strategy for introducing this without breaking anything much is to keep the local wikis sitekey as the default setting in all cases. So callers who are not aware of the external site support can keep sending local ids and will get the right thing. Only when they read data they will have to mind the new information (but that's always the case if you enable linking to external entities). That was the idea, yes. TASK DETAIL https://phabricator.wikimedia.org/T101752 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: mkroetzsch, JeroenDeDauw, Aklapper, daniel, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T101752: Introduce ExternalEntityId
mkroetzsch added a comment. I think this is a useful change if you want Wikibase sites to be able to refer to other Wikibase sites. In WDTK, all of our EntityId objects are external, of course. A lesson learned for us was that it is not enough to know the base URI in all cases. You sometimes need URLs for API, file path, and page path in addition to the plain URI. MediaWiki already has a solution for this in form of the sites table. I would suggest to use this and to store pairs sitekey,localEntityId and to have the URI prefix stored in the sites table. It's cleaner than storing the actual URI string (which might change if an external site is reconfigured!) in the actual values on the page. A strategy for introducing this without breaking anything much is to keep the local wikis sitekey as the default setting in all cases. So callers who are not aware of the external site support can keep sending local ids and will get the right thing. Only when they read data they will have to mind the new information (but that's always the case if you enable linking to external entities). But, overall, I think it would be good to make this change. Commons will want to link to Wikidata, for example, but also many Wikibase instances outside of WMF will benefit from the ability to link to WIkidata content. TASK DETAIL https://phabricator.wikimedia.org/T101752 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mkroetzsch Cc: mkroetzsch, JeroenDeDauw, Aklapper, daniel, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T101752: Introduce ExternalEntityId
JeroenDeDauw added a comment. Other than that, I can't think of any issues. EntityId is completely opaque. While EntityId might not be explicitly providing certain guarantees, many users of it can still make assumptions that would be violated when introducing this new derivative. If the URL is included, then the max length is presumably different. I just did a quick search on the Wikibase.git codebase and there are over a thousand places using EntityId. The first type hint I looked at was `RepoLinker::getEntityUrl`. By looking at this quickly, it is very much not obvious to me this code will behave correctly when getting this new EntityId derivative. In fact, it looks like it will not. I'd hate for us having to go through all these EntityId usages to verify they will handle the new one correctly. TASK DETAIL https://phabricator.wikimedia.org/T101752 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JeroenDeDauw Cc: mkroetzsch, JeroenDeDauw, Aklapper, daniel, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
