Wikidata:Property proposal/social media followers

From Wikidata
Jump to navigation Jump to search

Número de seguidores en las redes sociales[edit]

Originally proposed at Wikidata:Property proposal/Person

   Done
Descriptionnúmero de suscriptores como se indica en el sitio web, calificar con "punto en el tiempo" (P) y la propiedad de la cuenta. Para Twitter, use una identificación numérica.
Data typeQuantity
Allowed valuesintegers >1000. Generally, one value per media and calendar year, not more than one per quarter.
Allowed unitsnone
Example 1
Example 2MISSING
Example 3MISSING
SourceMedia. If another source is used, add a reference to the statement

Motivation[edit]

It seems that the previous discussions (notably Wikidata:Property proposal/subscribers) haven't really resolved this and we still have problems with storing this data. A series of options are mentioned in Wikidata:Property proposal/subscribers. This is an additional one.

A problem we currently have is that repairs of previous attempts lead to continuous edits of statements that should essentially be static. (Add your motivation for this property here.) --- Jura 09:33, 5 May 2020 (UTC)[reply]

@Mike Peel, OsamaK, Gereon K., SilentSpike, Maxlath: involved in recent discussions/data additions. --- Jura 09:33, 5 May 2020 (UTC)[reply]

Discussion[edit]

  •  Question Should we use string datatype for this? Values would generally be integers and quantity datatype at Wikidata involves substantially more overhead/complications for edits. --- Jura 09:39, 5 May 2020 (UTC)[reply]
  •  Support I don't know if this is a perfect solution, but it's certainly better than the current situation and I'm all for incremental improvement. This solves the most problematic piece of data we currently store as a qualifier on social media statements (really as much as I hate it we almost do just need items for social media accounts if we're going to qualify the qualifiers). It's a pity there's no property constraint for exclusive mandatory qualifiers so we could specify a set of social media identifiers of which one must be added. Also I think it should remain a quantity. --SilentSpike (talk) 11:10, 5 May 2020 (UTC)[reply]
  •  Support Thank you, Jura for pushing things forward. I agree with SilentSpike. This solution provides a neat incremental improvement. I also agree with the proposed once-a-year update frequency.--OsamaK (talk) 17:06, 6 May 2020 (UTC)[reply]
  •  Oppose Given that this data is frequently changing I would prefer tabular data for it. ChristianKl16:54, 11 May 2020 (UTC)[reply]
    •  Question @ChristianKl: how would such tables look/work given the granularity of the data, current update patterns and use on the associated item? --- Jura 18:25, 11 May 2020 (UTC)[reply]
      • I would have one column per social media statement. One row for the type of social media account. One row for the username. One row for each update of the value. This allows for updates for lots of items without producing edits in Wikidata which compete with resources for other edits for the query service. Editing a commons table is a lot cheaper. It could even allow for monthly updates of the values if that's desired. ChristianKl10:38, 12 May 2020 (UTC)[reply]
        • @ChristianKl: With one table per item (person)? I'm not sure if this is really easier to update (probably not manually) and it wont be queryiable. --- Jura 10:45, 12 May 2020 (UTC)[reply]
          • Updating it doesn't touch Wikidata and while Wikidata is not easily scaleable a file store like WikiCommons is easily scaleable. ChristianKl11:24, 12 May 2020 (UTC)[reply]
            • The question is how a user from Wikipedia would go about adding that there (about whoever they are interested) and how it's queried. If your argument is just one of theoretical possibility, it's something we can bear in mind for future plans. --- Jura 11:28, 12 May 2020 (UTC)[reply]
    • I'm interested in this approach also, however I'm not sure one table per item would suffice. You may need one per account with each row reflecting a new point in time at which some piece of data has changed (in this way you could also track changing of verified status, changing of username, etc.). --SilentSpike (talk) 12:11, 12 May 2020 (UTC)[reply]
      • I think it could work for a more limited universe with regular or absent updates. Here people update one or several datapoints at irregular intervals from different sources, typically what Wikidata was designed for. --- Jura 14:35, 12 May 2020 (UTC)[reply]
  •  Question How the use of point in time (P585) here. The followers count may increase/decrease in the same day.?-❙❚❚❙❙ GnOeee ❚❙❚❙❙ 17:30, 9 August 2020 (UTC)[reply]
  •  Support but should we also qualify with the social media platform in question? BrokenSegue (talk) 13:10, 30 September 2020 (UTC)[reply]
  • @Jura1: ✓ Done with social media followers (P8687) MSGJ (talk) 17:05, 5 October 2020 (UTC)[reply]