Closed RayBB closed 1 week ago
Or perhaps this was an intentional decision?
Initially the focus of the NSI was just the name, and brand came a little later, and location restrictions later still. This means that a single brand that was available world wide would usually have used a single wikidata, perhaps of the parent company.
As the index has grown, more regional wikidata's have been used, so there's nothing wrong with changing it as such, but it's not an automatic process, and I'd suggesting thinking about if such a change is necessary, for example "is the logo used different", "is the current wikidata already used a lot", "would a mass edit be required", "would a wikidata change be a genuine benefit to end users".
Thanks for the explanation of the history. I don't feel particularly strong about it. Perhaps it is more effort than it's worth given the changes needed. Though if anyone else feels different please let us know.
I tend to keep the same wikidata, because there are many such precedents in NSI (of course we must admit that the operations of 711 in Japan and 711 in the United States will be very different, but currently there are different differences in NSI) Wikidata is mainly on departments of the same bank in different countries)
Moreover, in areas like China and Taiwan also have 711, but the bound wikidata is global. Therefore, it is more appropriate to call it the global 711 rather than the American 711. From this perspective, perhaps the editor of the Japanese Wikipedia just wanted to highlight that Japan’s 711 legally belongs to a certain company, but ignored that other countries also have their own legal entities.
Thanks for sharing your perspective I think that is helpful!
7-Eleven Japan wikidata https://www.wikidata.org/wiki/Q11278357
https://nsi.guide/index.html?t=brands&k=shop&v=convenience&tt=7-eleven The 7-Eleven Japan in NSI currently used the American company wikidata in https://github.com/osmlab/name-suggestion-index/blob/4d2e06032f3afa1016bd868e42835374dde8cb76/data/brands/shop/convenience.json#L7368-L7387
Or perhaps this was an intentional decision?