Name-suggestion-index: Bypassing Wikidata for social logo's

[UKChris-osm]

As some of the wikidata articles still get removed for one reason or another (such as Teapresso #4829 or Bedmart #4036) I'm wondering if there is a way we could bypass Wikidata for entries that don't qualify, so that we can still gain access to social media logos, even when wikidata isn't an option?

I was thinking something baked into the build script that would check for social media sites that we're able to add manually, such as:

{
  "displayName": "Bedmart",
  "locationSet": {"include": ["us"]},
  "socials": {
    "twitter": "shopbedmart",
    "facebook": "BedMartNW"
  },
  "tags": {
    "brand": "Bedmart",
    "name": "Bedmart",
    "shop": "furniture"
  }
}

[Adamant36]

I think this had been suggested and rejected before because going through Wikidata as opposed to accessing the icons ourselves allows us to get around any potential copyright issues. Otherwise, we would have to self store them or at least be directly accessing them. Which could cause copyright problems At least that's how I remember it Maybe we could promising to access them directly or something now that @bhousel works for Facebook and they use it in Rapid.Id though.

[1ec5]

The proposal above is simply to inline the Facebook and Twitter user names in this repository instead of through an external reference to Wikidata. It doesn’t mean the logo images would be stored in this repository. So it seems unlikely that copyright or trademark concerns would be relevant.

That said, I’d hope any brand or network notable enough for NSI would be notable enough for Wikidata. From what I’ve seen, Wikidata has deleted items for not sufficiently _establishing_ notability, to distinguish them from spam, not because the brands themselves are definitively non-notable.

[kymckay]

Yeah I'd be inclined not to do this since our notability criteria should really be in alignment with Wikidata's. As users of Wikidata we want to encourage good use of the platform as it's a reciprocal relationship (i.e. when creating items they should be adequately established with details to avoid deletion).

[Adamant36]

It seems unlikely that copyright or trademark concerns would be relevant.

I thought there was issues with not directly consuming them from Facebook either or we would have just done that in the first place instead of bothering with Wikidata. I could be wrong though.

That said, I’d hope any brand or network notable enough for NSI would be notable enough for Wikidata. From what I’ve seen, Wikidata has deleted items for not sufficiently establishing notability, to distinguish them from spam, not because the brands themselves are definitively non-notable.

That's mostly correct. There has a been a few, like FoodMaxx, that were deleted anyway. Even when notability was sufficiently established. It was even linked to a parent organization. Which should have qualified it as notable. That's the rare case though.

[1ec5]

I thought there was issues with not directly consuming them from Facebook either or we would have just done that in the first place instead of bothering with Wikidata. I could be wrong though.

As I understand it, the concern was about NSI copying and hosting the images (as in the raw pixels), or alternatively about a downstream project like iD loading the images based on the data in NSI.

It was even linked to a parent organization. Which should have qualified it as notable.

I don’t have visibility into deleted items, but if FoodMaxx had a parent organization (P749) statement, the parent company’s item should’ve linked back with a reciprocal subsidiary (P355) statement. That alone would’ve prevented deletion. There are plenty of other ways to establish notability for a brick-and-mortar store, let alone a chain of them. I mentioned some of them in this OSM Wiki documentation. How can we improve this documentation and also the documentation here in this repository to prevent future deletions?

[UKChris-osm]

My understanding of logo's within the NSI was that they were always URL references to Facebook / Twitter servers, and never stored by the NSI, ID, or any other project that used the NSI. Whenever the wikibuild script is run, it simply looks for Facebook / Twitter accounts associated with each entry, and finds (ands stores) that URL for the logo. Then, when ID uses the NSI, it would simply call a basic HTTP request for the URL of the desired logo at the time it was needed.

If it's considered that all entries within the NSI are likely to be notable enough for Wikidata, then this idea isn't really needed I guess - my concern was without a secondary procedure in place, we would be missing out on logo usage based on some entries not being notable enough for Wikidata.

With the two entries I mentioned in the opening post, perhaps it was simply a case of deletion due to lack of content in each one? Perhaps in this scenario, it would be better to evaluate what data should be included, and create a fresh Wikidata item, rather than case the Wikidata people to undelete what was possibly a very basic entry?

[1ec5]

With the two entries I mentioned in the opening post, perhaps it was simply a case of deletion due to lack of content in each one? Perhaps in this scenario, it would be better to evaluate what data should be included, and create a fresh Wikidata item, rather than case the Wikidata people to undelete what was possibly a very basic entry?

Recreating a deleted item can be viewed unfavorably as effectively overriding an administrator’s decision to delete (at least on Wikipedia – not sure about Wikidata, where it isn’t always clear when a concept has already been deleted). If you go the route of creating a new item, make sure to follow these guidelines to establish notability and, if possible, make the item useful beyond the bare minimum. As long as the original item wasn’t pure spam or very poorly modeled, I think it would be preferable to get it restored with the promise of promptly expanding it, but it’s hard to say without knowing what was there originally.

[ArloJamesBarnes]

it’s hard to say without knowing what was there originally.

I touched all of the entities created by @TheAdventurer64 (https://wikidata.org/wiki/special:contribs/98.151.117.16) up to January 2nd. They were just labels and descriptions, so I added an 'instance of' statement for each, and 'located in the administrative territorial entity' where the description indicated Hawaii. I was occupied with other things and didn't do more at the moment, and later that day user:Esteban16 mass-deleted them on notability grounds (which as pointed out is about absence of evidence of notability, not necessarily evidence of absence [which, what would that even be?]). Agreed that recreating without giving context by appealing for an undeletion would not look great, and I think even then we should pick and choose our undeletions.

As for the logo image topic, I seem to recall that Commons-hosted logos were preferred to be served over social media ones for quality reasons even more than copyrestriction reasons; Commons often hosts a crisp SVG version, the social media profile and cover images can only be raster...brands often change up their social media image (for commemoration of holidays or pride days, or to promote sales events), whereas Commons' images are basically stable. The main advantage in the other direction is that profile pics are square.

[Adamant36]

For Foodmaxx we created a new Wikidata and the one that was deleted eventually got restored. Now there's two entries in Wikidata for it, Q61894844 and Q61989375. Which isn't so good either. So we should figured out a preferred way to get deleted entries back. Un-deletion requests at least have the advantage of following the process and don't look like attempts at spamming. The downside is that it takes an extremely long time, the entry might not get recreated (which I guess is a good thing in some cases, and in the meantime we are stuck without that entry in the index. I think for Foodmaxx to be restored it took at least a few months if not more. Which is ridiculous, but understandable. I'm sure there are other pros and cons of both options and it would be good to have a backup plan if possible. So we aren't as at the whim of Wikidata.

[1ec5]

For Foodmaxx we created a new Wikidata and the one that was deleted eventually got restored. Now there's two entries in Wikidata for it, Q61894844 and Q61989375. Which isn't so good either.

Items can be merged. In fact, I’ve installed a gadget that makes it a two-click process. But merging two items can be disruptive too, since one item ends up as a redirect. Make sure to update off-wiki consumers like NSI afterwards.