Documentation

https://twitter.com/$1
https://twitter.com/@$1
https://twitter.com/#!/$1
https://x.com/$1
https://twitter.com/intent/user?screen_name=$1
https://syndication.twitter.com/srv/timeline-profile/screen-name/$1
https://x.com/@$1

Robot and gadget jobs

DeltaBot does the following jobs:

<DeltaBot-format-removeFirst>

migrate the existing uses from website account on (P553), import from Template:Twitter (Q6741634)

BorkedBot automatically adds Twitter (X) numeric user ID (P6552) and updates social media followers (P8687)

Tracking: usage

Category:Pages using Wikidata property P2002 (Q27478228)

Tracking: local yes, WD no

Category:Twitter username not in Wikidata (Q26219999)

Related to country

United States of America (Q30) (See 762 others)

Queries[edit]

Users with more than 5 million followers in 2024[edit]

Properties used: formatter URL (P1630)   , social media followers (P8687)   , Twitter (X) username (P2002)   , point in time (P585)   , Twitter (X) numeric user ID (P6552)

SELECT
  ?value ?user (URI(REPLACE(?f,"\\$1",?user)) as ?url) ?d 
  ?item ?itemLabel ?itemDescription
WITH
{
    SELECT ?st ?value ?d 
    WHERE
    {
        ?st ps:P8687 ?value .
        FILTER ( ?value > 5000000 )   
        ?st pq:P585 ?d .
        FILTER ( YEAR(?d) = 2021 )   
     }
} as %a
WHERE
{
  INCLUDE %a
  ?st pq:P6552 ?id .  
  ?item p:P8687 ?st .   
  ?item p:P2002 [ ps:P2002 ?user ; pq:P6552 ?id ] .  
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
  wd:P2002 wdt:P1630 ?f . 
}
ORDER BY DESC(?value)

Try it!

Journalists on Twitter, by country[edit]

Items used: journalist (Q1930187)   , human (Q5)

Properties used: occupation (P106)   , Twitter (X) username (P2002)   , country of citizenship (P27)   , coordinate location (P625)   , instance of (P31)   , formatter URL (P1630)

Features used: map (Q24515275)

#  journalists on Twitter / by country
#defaultView:Map{"hide":["?coor"]}
SELECT ?item ?itemLabel ?itemDescription ?coor (URI(REPLACE(?f,"\\$1",?user)) as ?url) ?natLabel
{ 
	?item wdt:P106 wd:Q1930187 .
	?item wdt:P2002 ?user . 
	OPTIONAL { ?item wdt:P27 ?nat . ?nat wdt:P625 ?coor }
	?item wdt:P31 wd:Q5 .
	SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
	wd:P2002 wdt:P1630 ?f .
}

Try it!

Red Cross societies[edit]

Properties used: Red Cross FDRS ID (P9079)   , formatter URL (P1630)   , social media followers (P8687)   , Twitter (X) username (P2002)   , point in time (P585)   , Twitter (X) numeric user ID (P6552)

SELECT
  ?value ?user (URI(REPLACE(?f,"\\$1",?user)) as ?url) ?d 
  ?item ?itemLabel ?itemDescription
WHERE
{
  ?item wdt:P9079 [] . 
  ?item p:P8687 ?st .  
  ?st pq:P585 ?d .
  ?st pq:P6552 ?id .  
  ?st ps:P8687 ?value .
  FILTER NOT EXISTS { ?item p:P8687 [ pq:P585 ?d2 ;  pq:P6552 ?id ] . FILTER( ?d2 > ?d) }
  ?item p:P2002 [ ps:P2002 ?user ; pq:P6552 ?id ] .  
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
  wd:P2002 wdt:P1630 ?f . 
}

Try it!

Missing numeric id qualifier[edit]

default query of the property constraint below tends to time-out

Properties used: Twitter (X) username (P2002)   , Twitter (X) numeric user ID (P6552)

SELECT ?item ?username 
WHERE
{
	VALUES ?goodRanks { wikibase:NormalRank wikibase:PreferredRank }
	?item p:P2002 ?st .
	?st wikibase:rank ?goodRanks.
	MINUS { ?st pq:P6552 [] } . 
	?st ps:P2002 ?username
}
LIMIT 4000

Try it!

No recent P8687 value[edit]

Ideally at least one statement with social media followers (P8687) per year is available.

Properties used: Twitter (X) username (P2002)   , social media followers (P8687)   , Twitter (X) numeric user ID (P6552)   , point in time (P585)   , end time (P582)

# checks for a P8687-statement for the numeric id in the current year
# skips usernames with end date, missing or unknown numeric ids, deprecated rank
SELECT ?item ?username ?id
WHERE
{
  VALUES ?goodRanks { wikibase:NormalRank wikibase:PreferredRank }
  ?item p:P2002 ?st.
  ?st pq:P6552 ?id.
  MINUS {
    ?st0 pq:P6552 ?id; pq:P585 ?d. [] p:P8687 ?st0.
    FILTER(?d > "2023-31-12"^^xsd:dateTime)
  }
  ?st wikibase:rank ?goodRanks .
  ?st ps:P2002 ?username.
  MINUS { ?st pq:P582 [] }
  FILTER(!(wikibase:isSomeValue(?id)))
}
LIMIT 100

Try it!

P3744 qualifiers to convert to P8687[edit]

query

Discussion[edit]

Reliable way to get join date?[edit]

Hi! To fill in the mandatory start time, how can I get the join date? The website I have been using, http://www.twitterjoindate.com, does not work on some users (e.g. http://www.twitterjoindate.com/search?utf8=%E2%9C%93&name=bobtorricelli&commit=Search). DemonDays64 | Talk to me 14:49, 19 June 2020 (UTC) (please ping on reply)[reply]

P553[edit]

See website account on (P553), Query: CLAIM[553:918] and Wikidata:Bot requests. Visite fortuitement prolongée (talk) 19:32, 22 July 2015 (UTC)[reply]

Domain[edit]

It says domain: "human (Q5), organization (Q43229)"

But Q59 is currently a programming language. 91.9.127.6 10:16, 31 July 2015 (UTC)[reply]

Dead people[edit]

Is this property acceptable for dead people (e.g. for Glenn Gould (Q216924))? --Gloumouth1 (talk) 20:54, 28 January 2016 (UTC)[reply]

@Gloumouth1: Yes, if they created the account before death. However, Gould died in 1982. I've removed @GlennGouldFndn from that item, as it's the account for Glenn Gould Foundation (Q5568832), to which I have added it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:57, 27 September 2016 (UTC)[reply]

@Pigsonthewing: Ok thank you, it's clear. --Gloumouth1 (talk) 14:28, 28 September 2016 (UTC)[reply]

Jurisdiction[edit]

I note that applies to jurisdiction (P1001) is a legal qualifier for official website (P856) but not for Twitter (X) username (P2002). Would it make sense to add it here? I acknowledge that Twitter feeds are more likely to be distinguished by language of work than by applicable jurisdiction, but there do seem to be examples. tinyurl.com/yat5ulw4 - this query looks for Twitter usernames qualified with several country/jurisdiction properties. For example, iTunes Store (Q9593), McDonald’s (Q38076), Subaru (Q172741). If adopted, it would also be a single-value constraint qualifier. Bovlb (talk) 22:50, 3 April 2018 (UTC)[reply]

Notified participants of WikiProject property constraints Bovlb (talk) 22:58, 3 April 2018 (UTC)[reply]

Position[edit]

There also can be Twitter (X) username (P2002) for position (Q4164871). See German Federal Government spokesperson (Q28527966) --Davidpar (talk) 18:59, 6 April 2018 (UTC)[reply]

Proposition of a second property for the number of twitter followers[edit]

As around 65% of all statements with this property use number of subscribers (P3744) as a qualifier, I requested a new property for this functionality at Wikidata:Property proposal/Number of twitter follower. I would argue that the functionality of a qualifier is too limited, e.g. we cannot state the date when the follower count was determined. Sk!d (talk) 12:29, 6 July 2018 (UTC)[reply]

Not possible to have "no value"[edit]

It's not possible to set this property to no value; would it be possible to change this? It is possible to set Facebook username (P2013) values to no value. Trivialist (talk) 15:46, 6 October 2018 (UTC)[reply]

@Trivialist:

Done. Thanks for noticing. --abi án 15:59, 6 October 2018 (UTC)[reply]

@Abián: Thanks! Trivialist (talk) 16:08, 6 October 2018 (UTC)[reply]

Twitter: OMP_España[edit]

El usuario de Twitter de las Obras Misionales Pontificias en España es @OMP_ES, pero el sistema no me deja introducirlo (OMP_ES) en Wikidata.--Hard (talk) 11:39, 23 January 2019 (UTC)[reply]

Hola, Hard. El usuario debe escribirse sin la arroba delante. Si escribes «OMP_ES» no tendrás problemas. Un saludo y, ante cualquier otra duda, siéntete libre de preguntar de nuevo. --abi án 14:45, 23 January 2019 (UTC)[reply]

Hola, abi. Muchas gracias por tu rápida respuesta. Pero el caso es que lo introduje por segunda vez sin la arroba delante, y tampoco me dejó introducirlo. No sé si será por el uso de las mayúsculas. Muy agradecido por tu ayuda. Un cordial saludo, --Hard (talk) 15:17, 23 January 2019 (UTC)[reply]

@Hard: En esas ocasiones parece ser que has escrito «OMP_ES », es decir, con un espacio en blanco al final. Si lo has copiado y pegado de algún sitio, a veces pasa. Confía en mí, prueba de nuevo a escribir simplemente «OMP_ES» sin las comillas, deberías poder. :-) --abi án 15:25, 23 January 2019 (UTC)[reply]

Single value constraint[edit]

Pere Saló i Manera (Q21779182) has two Twitter (X) username (P2002), one as a personal profile and another one as a government official. What we should do if there is a single value constraint? --Davidpar (talk) 11:52, 2 March 2019 (UTC)[reply]

@Davidpar: Would adding the person in question to the exception to constraint list not work? I added him just now to illustrate the point, feel free to revert if you don't think it's the best solution. Moebeus (talk) 01:35, 3 March 2019 (UTC)[reply]

Ok, it's fine. Thanks! Davidpar (talk) 07:47, 3 March 2019 (UTC)[reply]

Verification[edit]

I've left a note on project chat (Wikidata:Project chat#Indicating verified accounts) on how best to indicate verified accounts across the different social media properties - comments welcome there. Andrew Gray (talk) 23:31, 15 March 2019 (UTC)[reply]

Duplicated vakyes[edit]

select distinct ?item ?itemLabel ?twitter1 ?twitter2  where
{
  ?item wdt:P2002 ?twitter1 . ?item wdt:P2002 ?twitter2 . 
  filter(?twitter1 > ?twitter2) . 
  # item has two values for twitter account
  filter((lcase(?twitter1)) = (lcase(?twitter2)) ) .
  # but they are the same case-insensitive text

  # nb please do *not* fix automatically by removing entries without checking them first
  # as one value may have key qualifiers (follower count, verification, sources, etc)!
  
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}

Try it!

This report may be useful - it's ~170 items that have two different Twitter account values, which are identical except for the capitalisation. Andrew Gray (talk) 19:14, 19 March 2019 (UTC)[reply]

I’ve added it as a complex constraint, see above. It makes a lot easier to keep track of it thanks to the bot updates popping up on recent changes/watchlists. —Tacsipacsi (talk) 21:26, 20 March 2019 (UTC)[reply]

It would be great to check that for distinct items too, but I am not sure it is possible to do that efficiently in SPARQL. Ideally it would be great to have a "distinct case-insensitive values" constraint, but implementing that is likely to be challenging (given that it would run into the same SPARQL issue). I have started a discussion about that in Wikidata talk:WikiProject property constraints. − Pintoch (talk) 07:11, 23 May 2019 (UTC)[reply]

@Andrew Gray, Tacsipacsi: I have proposed a related bot task to normalize the case of Twitter ids: Wikidata:Requests_for_permissions/Bot/PintochBot_5. − Pintoch (talk) 11:02, 24 May 2019 (UTC)[reply]

Renamed accounts?[edit]

Any idea what we should do with someone whose account has been renamed? This is more common than I expected - cleaning up a dataset of ~620 political accounts has found about a quarter which have been renamed. I was going to just replace the data but it might potentially be useful in the long run for looking at old usernames etc. On the other hand, if we have a non-functioning old username, I don't think there's any way to prove it belonged to the person unless we can find archived tweets.

If we do retain the old names, how should we enter them? Deprecated with a end time (P582) (if possible) and reason for deprecated rank (P2241)? Andrew Gray (talk) 21:28, 24 July 2019 (UTC)[reply]

Maybe we should have a bot add systematically Twitter (X) numeric user ID (P6552) as qualifier to all P2002. --- Jura 21:32, 24 July 2019 (UTC)[reply]

That sounds like a good idea - I'm setting up a run to update verified status and follower counts, so I could add Twitter (X) numeric user ID (P6552) to them all at the same time. It seems to make sense to tie them together like this. Andrew Gray (talk) 21:50, 24 July 2019 (UTC)[reply]

At Wikidata:Property proposal/subscribers, we are trying to figure out how to handle subscriber numbers. I think we should avoid dropping old data and keep at least annual numbers for most accounts. --- Jura 22:24, 24 July 2019 (UTC)[reply]

To answer your initial question, I think end date should be fine. The new name could have preferred rank. This makes we wonder if we wont have the same problem with other social media stuff. --- Jura 07:33, 25 July 2019 (UTC)[reply]

@Andrew Gray: What do you think of Wikidata:Bot_requests#Monthly_number_of_subscribers? Is this something you could add at the same time? --- Jura 15:46, 29 July 2019 (UTC)[reply]

I added it as a "suggested" mandatory qualifier. --- Jura 08:04, 25 January 2020 (UTC)[reply]

Impossible to add resonatecoop[edit]

For Resonate, I try to add the Twitter username for resonatecoop, but got this warning: Could not save due to an error.

The save has failed.
Warning: The provided Twitter account is invalid.
- Only include the relevant fragment, without "https://twitter.com/".
- Do not prepend "@".
- Visit the sandbox, in case you are making tests.
- If you are completely sure that your edit is valid, please explain your situation here.

– The preceding unsigned comment was added by [[User:|?]] ([[User talk:|talk]] • contribs).

It seems so: Special:AbuseLog/8374424.

@Ladsgroup: you seem to have edited the filter recently. FYI @Matěj Suchánek: --- Jura 14:40, 8 August 2019 (UTC)[reply]

Tricky, after the update, the diffing algorithm is the new enemy. --Matěj Suchánek (talk) 16:06, 8 August 2019 (UTC)[reply]

Looks like most others went smoothly. --- Jura 16:43, 8 August 2019 (UTC)[reply]

Multiple Twitter accounts/names with different fields of work, intended audience, responsible individuals, etc.[edit]

Anthrocon (Q4773878) has numerous Twitter accounts (and thus, usernames) in order to handle separate fields of work. I've therefore added field of work (P101) to these, despite it not being in the allowed qualifiers constraint. Should it be added to it? This is separate from applies to jurisdiction (P1001) as described above because that is about physical territories.

The above discussion mentions intended public (P2360) in the context of official website (P856). I suspect it should also apply to this property, as some Twitter accounts are aimed at a particular audience, e.g. programmer (Q5482740).

These accounts typically represent specific internal departments, like the art show, artists alley or dealers' den; some may have specific users (identified by other Twitter usernames) responsible for them, differing over time. Some appear to represent a topic area, such as dissemination of dining promotions for the benefit of attendees.

I am also uncertain as to whether I should have used object has role (P3831) to indicate the general output/activity of the account - I'd prefer has use (P366) (because it is not a singular "role" - there are announcements for different fields, and recruitment and customer support for different topic areas and intended audiences, e.g. artists and dealers vs. presenters vs. dancers), but this property was also not within the constraint. GreenReaper (talk) 02:55, 27 August 2019 (UTC)[reply]

Q3749450[edit]

Q3749450 doesn't accept this value: francesca_cheyenne, but it is the right username. -- L'Ospite Inatteso - I love to love you 10:03, 2 December 2019 (UTC)[reply]

@L'Ospite Inatteso: There’s no such thing that a property “doesn’t accept” a value (except that number properties don’t accept non-numerical values, coordinate properties don’t accept values that cannot be transformed into geocoordinates, and other similarly basic checks; this property is of type external identifier, so it accepts nearly any input). Properties simply generate warnings after save (but I don’t see any attempt to add Twitter (X) username (P2002) statement in Francesca Cheyenne (Q3749450)’s edit history). What really doesn’t accept francesca_cheyenne is twitter.com, which means it’s not the right user name. But anyway, twitter.com is out of our control. —Tacsipacsi (talk) 21:07, 13 December 2019 (UTC)[reply]

OK, thank you. -- L'Ospite Inatteso - I love to love you 09:37, 14 December 2019 (UTC)[reply]

statement or identifier[edit]

I've seen this used sometimes as a statement sometimes an an identifier, what's the difference and which one is correct? What can be done to help people avoid mixing the two? --AndrewHarvey4 (talk) 03:26, 9 January 2020 (UTC)[reply]

@AndrewHarvey4: Could you clarify what you mean? As far as I understand you, you’re speaking about external identifier statements and “normal” statements – the two are basically the same, simply the software puts statements with external identifier properties in a separate section. This distinction cannot be overridden on a case-by-case basis (so people are simply unable to mix the two), if a property was created with external identifier data type (like this one), it will always be put in the external identifiers section, and this will remain so forever; if a property was created with a different data type, it will never get into the external identifiers section. This may not be true only immediately after creating the statement: the statement is displayed in whatever section you created it, but a page refresh reorders statements so that all show up in the appropriate section. —Tacsipacsi (talk) 21:08, 15 January 2020 (UTC)[reply]

Adding a mandatory point in time (P585) qualifier constraint[edit]

In the process of seeking bot permissions to add appropriate Twitter (X) numeric user ID (P6552) qualifiers and update other details at the same time.

Having played with the data a bit, it seems to me that there should be a mandatory point in time (P585) qualifier constraint to date twitter data because this value is unstable and could change at any time. end time (P582) and start time (P580) also work in cases where there is a known time at which something changed (username changed or verified badge added), but also cause issues if there are qualifiers which apply to a snapshot in time (such as number of subscribers (P3744)). Thoughts? --SilentSpike (talk) 16:37, 2 February 2020 (UTC)[reply]

@SilentSpike: adding this as a mandatory constraint is a mistake. A mandatory constraint signals a critical issue with the data. As a user, if I add a twitter username to an item, this is a net gain for Wikidata: the fact that it is not associated with a numerical id should really not be signalled as a critical issue. This is especially problematic since numeric ids are not exposed in Twitter's UI directly - you need to know how to obtain them, which is not user-friendly at all. If you intend to run a bot to add these ids, then do this first, and then add the constraint, with a lower serevity level. Otherwise you are blaming users for an "issue" that isn't one. − Pintoch (talk) 15:15, 27 February 2020 (UTC)[reply]

@Pintoch: Please see linked discussion in section "reversing the roles pf P2002 and P6552". The reason numeric ID is a mandatory qualifier is because the username is not a stable identifier and the numeric ID is required to make the data consistently meaningful for all time. There is no other way to know which account a username is associated with historically (only for the present moment in time by querying Twitter). No user is being blamed for anything, the constraint comes from the data itself. Adding it as a suggestion constraint implies that it is not important, when clearly it is. --SilentSpike (talk) 15:56, 27 February 2020 (UTC)[reply]

@SilentSpike: I understand you are not trying to blame anyone, but having a mandatory constraint in this form is really discouraging people who might not be familiar with the issue. It is great that you are running a bot to add these ids - that's a great job for a bot, and you do not need the constraints to be in place to do that. I don't think we should expect users to manually add these numerical ids themselves, since they are hard to obtain. − Pintoch (talk) 18:12, 27 February 2020 (UTC)[reply]

@Pintoch: That's fair, if we're relying on the bot to add these anyway then it's reasonable to leave it as a suggestion constraint. --SilentSpike (talk) 18:19, 27 February 2020 (UTC)[reply]

@SilentSpike, Pintoch: I've recently been adding some social media accounts to Wikidata items for entities I follow, and adding the Twitter account is always uniquely a pain since unlike any other social account, in order to get the circled ! to go away, I have to add not just the username, but also the start time, numeric ID, and number of subscribers. From the discussion above, I can see the potential need for numeric ID, but number of subscribers? That's really not a necessary item, and having to add it in order to make the entries "clean" takes up my time and doesn't add much value to them. Sdkb (talk) 20:40, 18 June 2020 (UTC)[reply]

We should actually discourage adding follower counts in my opinion: it is volatile and harmful as a measure of popularity. If there is a constraint about these, it should be to forbid them, not to require them. − Pintoch (talk) 20:56, 18 June 2020 (UTC)[reply]

@Pintoch: I went ahead and removed the mandatoryness of follower count (I'm new to Wikidata, so if that was overly bold, please revert me). If followers are added, it should include a qualifier for point in time. I'm not sure if there can be a qualifier of a qualifier. That gets to the issue that "follower count" isn't really a qualifier of "Twitter username", but rather of "Twitter presence". Sdkb (talk) 21:53, 18 June 2020 (UTC)[reply]

"If followers are added, it should include a qualifier for point in time" This is why you place the point in time property below the subscriber count--Trade (talk) 22:04, 18 June 2020 (UTC)[reply]

@Trade: I think the current mandatory "start time" qualifier was supposed to be a mandatory "point in time" qualifier, based on the clarification, which states that it's required because the username can change over time. Sdkb (talk) 22:07, 18 June 2020 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

@Sdkb: Honestly I've largely given up on this data for the time being because the way we currently model it is too problematic if we want to include all the metadata. It seems that for now we're just storing all metadata (even though it makes the overall statement nonsensical to a machine) until a better solution is found. I wouldn't feel obligated to add anything beyond the username (though really the ID is most important) by hand if I were you. --SilentSpike (talk) 22:15, 18 June 2020 (UTC)[reply]

A solution for the problem could be Wikidata:Property_proposal/social_media_followers. --- Jura 06:14, 19 June 2020 (UTC)[reply]

Number of tweets[edit]

How should we record the number of tweets? Could we use the quantity field for example? (P1114) Back ache (talk) 09:51, 19 February 2020 (UTC)[reply]

Reversing the roles of P2002 and P6552[edit]

If interested in this topic please contribute to the discussion at Wikidata:Requests_for_permissions/Bot/SilentSpikeBot#Relevant_property_discussion where I seek to establish a bot task to handle this conversion and prevent data becoming stale. --SilentSpike (talk) 15:06, 20 February 2020 (UTC)[reply]

Representing various account qualities[edit]

@Jura1, Andrew Gray, Tacsipacsi: I believe you folks are interested in this data. Following on from the bot permission discussion (now running and adding numeric IDs), I've also added a new constraint for the has characteristic (P1552) qualifier to limit the allowed values. You can see from

SELECT ?qualifiervalue ?qualifiervalueLabel (COUNT(?item) as ?ct) 
{
   ?item p:P2002 [ pq:P1552 ?qualifiervalue ]
   SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }               
}
GROUP BY ?qualifiervalue ?qualifiervalueLabel 
ORDER BY DESC(?ct)

Try it!

There's not much usage beyond verified account or profile (Q28378282), but perhaps we should also agree on other sensible values to allow (and create items if needed). Ideally we could do this generally and apply the same constraints to other properties which represent social media accounts.

From the query, other qualities that could be represented seem to be:

Account suspension
Account deletion
Account inactivity
NSFW content
Posthumous creation
Account privacy (although, I feel like this shouldn't be included as surely it encourages violation of Wikidata:Living people)

Let me know your thoughts if interested. --SilentSpike (talk) 11:29, 29 February 2020 (UTC)[reply]

one-of qualifier value property constraint (Q52712340) isn't support by KrBot or the gadget. As it doesn't seem to happen, either a {{Complex constraint}} or a dedicated qualifier would be needed. "Posthumous creation" seems to be important to include. --- Jura 11:49, 29 February 2020 (UTC)[reply]
- I think it's still worth adding so that at least the "constraint" is represented some way in the structured data. Doesn't need to be an official constraint, more so a source of information for editors and data users to see how these qualities are expected to be marked. For posthumous accounts I think posthumous (Q1395509) seems fine as an allowable value. --SilentSpike (talk) 12:47, 29 February 2020 (UTC)[reply]

Have been going through a few User:SilentSpikeBot/TwitterForReview and think for suspended and deleted accounts it makes more sense to deprecate the statement and mark with reason for deprecated rank (P2241) either Q49776568 or Q65684169 --SilentSpike (talk) 12:03, 1 March 2020 (UTC)[reply]
- If it's suspended, we know it existed. I think normal rank with end date or end cause would do? --- Jura 12:08, 1 March 2020 (UTC)[reply]
  - Good point, I suppose deprecated probably isn't correct then since the data is accurate. Also should consider an account could be temporarily suspended, which could require multiple statements with start/end date qualifiers to reflect when this changed. So perhaps "has quality" is more appropriate and those two items shouldn't be instances of Wikibase reason for deprecated rank (Q27949697). --SilentSpike (talk) 12:36, 1 March 2020 (UTC)[reply]
  - I think your idea to use "end cause" to reflect whether deleted or suspended works best. Have updated the (currently useless) constraints to reflect this. Although will need to create new items to replace those existing ones which have been modelled as reasons for deprecation (self-invalidating since the account must have existed). --SilentSpike (talk) 14:41, 9 March 2020 (UTC)[reply]

I assume "Account privacy" is another word for protected Twitter account (Q78680253)? In what way does the inclusion of this quality violate Wikidata:Living people? --Trade (talk) 11:25, 31 May 2020 (UTC)[reply]

I have seen instances where someone's official (inactive) account have been hacked and/or hijackes by a spambot. How should i indicate this quality?--Trade (talk) 11:28, 31 May 2020 (UTC)[reply]

I think it would be good to have a property to indicate or inactive or deleted accounts/websites. --- Jura 11:50, 31 May 2020 (UTC)[reply]

Most people just just use reason for depreciation: broken link. --Trade (talk) 11:54, 31 May 2020 (UTC)[reply]

Which isn't correct --- Jura 12:16, 31 May 2020 (UTC)[reply]

Whats wrong with using it for properties as official website?@Jura1:?--Trade (talk) 16:11, 1 June 2020 (UTC)[reply]

What to do with number of followers[edit]

Please see Wikidata:Property proposal/social media followers, an additional proposal mentioned there is to move them to Commons data pages. --- Jura 07:40, 27 June 2020 (UTC)[reply]

Why am I tripping the abuse filter?[edit]

My change is here but it all looks fine.

Another example showing the actual edit being rejected is here. I'm not understanding which condition in the abuse filter i'm triggering.

BrokenSegue (talk) 15:26, 29 July 2020 (UTC)[reply]

Again the same filter. I've tried to add multiple times the value "vittoriopasteris" to Vittorio Pasteris (Q4015476), but the filter has always blocked me (one example: Special:AbuseLog/15399272). Someone can explain the problem? --Epìdosis 13:03, 27 December 2020 (UTC) Maybe @Matěj Suchánek, Abián, Ladsgroup:. --Epìdosis 13:04, 27 December 2020 (UTC)[reply]

@Epìdosis: ah well "vittoriopasteris" is 16 characters long and the rule only allows up to 15. That account is very old so I bet it somehow has a grandfathered length. So I guess the abuse filter needs an edit. Can admins do that? BrokenSegue (talk) 16:41, 27 December 2020 (UTC)[reply]

@BrokenSegue: Oh, yes, you are right! Just edited the filter and value correctly inserted. --Epìdosis 16:44, 27 December 2020 (UTC)[reply]

twitter[edit]

El nombre de la cuenta tiene despues un parentesis con una frase de "en casa" donde la casa es un emoji

the account name cannot contain an emoji. look at the url 00:32, 26 August 2020 (UTC)

CUENTA DE TWITTER[edit]

ESTA CUENTA ES REAL, ES MAS LA PUEDEN BUSCAR EN TWITTER PARA QUE LA VERIFIQUEN.

if you had said the twitter handle or the item id we could've helped you. BrokenSegue (talk) 17:26, 8 September 2020 (UTC)[reply]

Replacing number of subscribers (P3744) with social media followers (P8687)[edit]

social media followers (P8687) was recently created. It is much more applicable to this than number of subscribers (P3744) is. The qualifier should be changed. DemonDays64 | Talk to me 00:04, 15 October 2020 (UTC) (please ping on reply)[reply]

I don't believe that was the intention behind the new property. BrokenSegue (talk) 01:25, 15 October 2020 (UTC)[reply]

Numeric id should not be suggested to users[edit]

I have removed the constraint which suggests the addition of a numeric id as a qualifier, as it is counterproductive to display such a message to users. Users should not be discouraged from adding a username only. A bot can add such a qualifier later on. − Pintoch (talk) 22:02, 30 December 2020 (UTC)[reply]

And that was reverted on sight by BrokenSegue… It feels good to be back on Wikidata! − Pintoch (talk) 22:09, 30 December 2020 (UTC)[reply]

@Pintoch: hey sorry. I did check this talk page before reverting but this post wasn't here yet and I felt such a change merited at least a comment. I'm a little ambivalent about it personally. BrokenSegue (talk) 02:06, 31 December 2020 (UTC)[reply]

@BrokenSegue: Ok, let me expand: put yourself in the shoes of a newcomer who adds their first statement on Wikidata. They add the Twitter username of their favourite singer. After figuring out how Wikidata works, they manage to add the statement. But then they see a flag icon, which displays something about a "required qualifier constraint" which needs a Twitter numeric ID. They do not know what this numeric ID is, or how it can be found (and maybe don't know about qualifiers in the first place), so they delete the statement they added.

My point is: since we do not expect users to add this qualifier themselves, we should not display a warning message asking them to do so. A bot can add such qualifiers on its own and does not need the presence of a constraint declaration on the property to work.

By the same token I would remove the other required qualifier constraint about the starting date, since this can also be fetched by a bot in the same way, but I feel less strongly about this since humans can also add it relatively easily (but even then, I would say it is pretty counter-productive for the same reason). − Pintoch (talk) 07:47, 31 December 2020 (UTC)[reply]

The numeric id shouldn't really be missing, even if it could be added by bot. One could even argue that P2002 shouldn't be there at all. I don't think it's a good idea to delete constraints merely because not all contributors have figured them out. --- Jura 10:22, 31 December 2020 (UTC)[reply]

@Jura1:, (sorry for harsh comment), please, don't treat all users as dummies. Many users already know that "numeric ids" for any property are just some hidden integers, which can be found somewhere in the page source or via API (for those, who have API keys). And as more someone knows, more questions are raised.

In some cases these ids are valid (for example, when youtube channels have canonical non-readable ids and readable short-ids). However for social networks these ids are harmful as they enable cyberbullying; by definition they reassociate new usernames with old ones, when users clearly state that they don't want to be associated with old id anymore. That's why, for example, Instagram is actively removing ig_id parameter from API right now. It is just a question of time when Twitter removes all the traces of numeric ids.
As for Twitter, there are no guarantees that access by id should work (in the past or in the future). Just someone have discovered this and pushed it as a property proposal.
Everyone has seen these constraint warnings, but nobody has ever seen benefits, described in the motivation. Everyone are hasty to add numeric ids, but nobody checks whether these ids were vandalized (and it is extremely easy to vandalize them) or renamed.
Given #1, #2 and #3, it is unclear, what is an immediate benefit to ask human users to add these numeric ids.

Personally, I actively ignore such constraints. Maybe bot can add them, but not me. The sign of constraint violation becomes a time-waster, it just catches eye. And if it continues, eventually everyone will get accustomed to constraint violation signs. Instead of helping users to improve quality, constraint system turns into "suggest some garbage" system. --Lockal (talk) 10:32, 11 January 2021 (UTC)[reply]

I'm already accustomed to ignoring many constraint violations unfortunately. BrokenSegue (talk) 14:33, 11 January 2021 (UTC)[reply]

@Lockal: I think your comment is besides the point. Sorry if you find the question offensive, but Twitter user names can be highly problematic in Wikidata:

It's a basic requirement for identifiers we use, that they are meant to be stable. Twitter user names are not.
As it was pointed out earlier, 25% of accounts in a sample were renamed. The easiest way to get the current name would have been (if we had used it back then) the stable numeric id.
None of renames seem to happen for the reason you mention. Contrary to Instagram, Twitter feeds are generally public (and almost certainly when added to Wikidata). If you add non-public names or feeds to Wikidata, you should probably reconsider your approach.
If you think Wikidata statements should be partially protected, please ask the development team. This is not a question specific to Twitter ids.
As for most non-mandatory constraints, they help complete data. This is different from mandatory constraint, e.g. most format constraints.

BTW, we need help matching usernames in Mix'n'Match to the ones in Wikidata. Many are in Wikidata, but in different formats. Also a problem we wouldn't have when using the stable id directly. --- Jura 16:25, 11 January 2021 (UTC)[reply]

Sorry, I missed messages about 25%, could you give me a link to discussion? Is there a dump of this sample for analysis (to find out why these accounts were renamed, was it, for example, a CompanyA assets transfer to CompanyB, so now channel belongs to CompanyB)? Also there is no statistics to say "Contrary to Instagram, Twitter feeds are generally public". For me they both are social networks with slightly different functionality. As for different formats, well, I see this as an issue of Mix'n'Match. You can do case-insensitive reconciliation with OpenRefine. Mix'n'Match has very simplistic UI, and there is only one instance of Magnus Manske... --Lockal (talk) 10:29, 12 January 2021 (UTC)[reply]

This error message is both unhelpful (as new users have no idea how to find the numeric id) and pointless (as it is supplied by BorkedBot). Let's remove it. Bovlb (talk) 23:33, 13 September 2022 (UTC)[reply]

sure BrokenSegue (talk) 02:27, 14 September 2022 (UTC)[reply]

Format of usernames[edit]

How should we format usernames? Time to revisit the question? A few points:

Usernames are case insensitive.
Usernames have a preferred casing. They can be all lowercase, different forms of mixed case, or all uppercase.
Preferred casing can change.
Format on Wikidata varies:
1. preferred casing
2. casing preferred sometimes in the past
3. lowercase
4. some other
At some point, a bot determined the preferred casing and changed statements to that. It hasn't been active recently and might not have re-checked all values regularly.
Wikidata has now >260,000 usernames, MxM >210,000 unmatched usernames.
It's difficulte to look-up usernames that are not in the casing used on Wikidata (unless Wikidata uses all uppercase or all lowercase). While it's possible look-up names one-by-one, the approach doesn't scale to the current volume.
For DOI (P356), there was a similar problem on even larger scale and the format was normalized to uppercase.

Following some issue on MxM, the question was briefly discussed with @Magnus Manske, BrokenSegue:. The later mentioned the option to use lowercase only. The preferred casing could be moved to a qualifier (e.g. object named as (P1932)). This would improve the situation for MxM users @Gobonobo, NMaia, William Graham, 99of9, Andre Engels:. Also, it would be a change to the approach discussed two years ago (#Duplicated_vakyes), but no longer actively implemented. WDYT? --- Jura 10:39, 14 January 2021 (UTC)[reply]

Defaulting everything to lowercase sounds good to me. NMaia (talk) 11:39, 14 January 2021 (UTC)[reply]

i would support defaulting to lower case with an optional stated as with the correct casing (which a bot could populate). BrokenSegue (talk) 12:54, 14 January 2021 (UTC)[reply]

I support using lowercase only. It would be nice if MxM treated handles as case insensitive. gobonobo ⁺ ^c 13:09, 14 January 2021 (UTC)[reply]

Agree with lowercase only. William Graham (talk) 00:20, 15 January 2021 (UTC)[reply]

I oppose lowercasing, because it loses information. Lowercasing would also make problems for Entity Explosion - the way it's currently coded, it's looking up an exact matching string in the (preferred case) URL, so I would have to write a special case for Twitter. It can probably be done once (maybe I even did it already, I can't remember), but it's not a great precedent to set. I'm not sure how to solve the problem for MnM though. --99of9 (talk) 02:13, 15 January 2021 (UTC)[reply]

There is no loss of information, as a qualifier could store the information (P1932). If EE works correctly now, it would already do case insensitive matching given the four formats currently at Wikidata: 4.1-4.4 above. The coding would need to be similar as DOI's (I suppose you could also simplify it when they normalised it) --- Jura 07:31, 15 January 2021 (UTC)[reply]

Fixing single [unique] value constraint violations[edit]

Looking through some of the names with more followers, I fixed a few that appear twice. To avoid that names get re-imported, I set the rank to deprecated and qualified them with intended subject of deprecated statement (P8327). Samples: [1], [2]. When doing that, I moved the number of subscribers (P3744) and social media followers (P8687) if not present in the correct item. --- Jura 12:44, 24 January 2021 (UTC)[reply]

You probably meant "unique constraint", not a "single value". --Lockal (talk) 18:57, 24 January 2021 (UTC)[reply]

@Jura: I'm not sure that it will protect from reimporting via https://pltools.toolforge.org/harvesttemplates/ though, but I'm 100% sure that setting to novalue (with normal rank) works. Looks like that according to https://github.com/Pascalco/PLnode/blob/master/src/constraints/distinct.mjs template harvester uses ASK wdt: queries, so your idea may not work. @Pasleim: correct me if I'm wrong. Even wikibase constraint checker does not mark equal-by-valie but different-by-rank statements as violation. --Lockal (talk) 19:17, 24 January 2021 (UTC)[reply]

Yes, distinct/unique values. I think Harvesttemplates used to time-out when such checks are active on properties with many uses. https://www.wikidata.org/w/index.php?title=Wikidata:Database_reports/Constraint_violations/P2002&oldid=1231940826#%22Unique_value%22_violations has a list from last year (without checking for different casing). --- Jura 19:32, 24 January 2021 (UTC)[reply]

Ah, but after a second look this code will disallow reimport (as it also checks existance of deprecated statements). Also I did some instagram/twitter harvesting with pltools from jawiki last year, it works fine. --Lockal (talk) 20:39, 24 January 2021 (UTC)[reply]

Dedicated items for twitter accounts[edit]

I think that this property's value should have a Wikidata item that represents the X account (Q63976454) of an item instead of a string that links to an account.

Motivation

The Twitter account for the President of the United States (Q11696) resets after the current president leaves office. This means that the value (the link) to the account is not the same account as when first entered meaning the first entry link is technically incorrect. The only way to really solve this is to have seperate items.

Further reasoning

Currently User:BorkedBot updates Twitter account qualifiers for statistics. These statistics would probably be better-suited for a seperate Twitter account item since there are usually multiple timestamp entries that currently take up a lot of space/data on their parent item.

This change to moving Twitter accounts to items could possibly influence other properties for social media accounts to do the same.

However, I'm not so optimistic on this proposal. I might be missing something. I also expect some concerns about the notability of making Twitter account items, and possibly other things.

Here are the current instance of (P31) X account (Q63976454)s: Query --User:Lectrician1

Before creating social media followers (P8687) we experimented with a few alternatives. One was to create such items. Finally, we went for P8687.

So, in general, I don't think it's needed. An exception might be when there is no clear item we can add an account to, but we should include it due to some reason.

The question is if "POTUS" is such an account or not. Currently it's added the the item about the president (e.g. Joe Biden (Q6279)), but maybe it just needs to be at President of the United States (Q11696).

BTW, does the numeric id change or remain the same?

People somehow messed up various entries last month and I haven't checked if they have all been fixed yet. --- Jura 06:49, 6 February 2021 (UTC)[reply]

- It seems like that no accounts were replaced actually: https://www.theverge.com/2020/12/22/22195713/twitter-biden-reset-accounts-trump-potus-whitehouse The usernames just got renamed.
  I guess this change isn't really needed for my conflicting case anymore, however it still might be useful to have dedicated items for social media accounts. Especially regarding the statistics that should probably be in statements and not qualifiers.
  There are also probably a lot more statistics that we could document then what we currently do. What if we had an item for every YouTube video a channel published? Storing those in qualifiers would not be appropriate and they could possibly have their own statistics as qualifiers. Documenting YouTube videos might have some notability issues, but it does have a case for artists with music videos where timestamped statistics for them are sometimes displayed on Wikipedia. In that case, we'd need a property called youtube video that YouTube video ID (P1651) is then placed in as a statement. --Lectrician1 (talk) 14:10, 6 February 2021 (UTC)[reply]

I don't think we should do this in the general case. We want to keep contributing data like this lightweight. Forcing people to make new items to contribute a small piece of data is bad when it can be avoided. BrokenSegue (talk) 03:10, 7 February 2021 (UTC)[reply]

Lower, uppercase or as-written case for account name?[edit]

The Twitter account name may be written as, e.g., "Username", "username", "UserName" or "USERNAME". It might be an idea to converge on some form of consistency. I have usually entered the account name as the user hiermself writes it, but perhaps it is better to lowercase? As far as I understand Twitter ignores casing? — Finn Årup Nielsen (fnielsen) (talk) 08:51, 23 March 2021 (UTC)[reply]

See Property_talk:P2002#Format_of_usernames above. --- Jura 09:46, 23 March 2021 (UTC)[reply]

Renamed accounts (2)[edit]

There's a previous discussion about renamed accounts, but it doesn't completely clarify how they should be handled. Should there be two statements, one for each name, each with the same Twitter (X) numeric user ID (P6552) qualifier? I can give Thandiwe Newton (Q229029) as a test case, since the account was recently renamed from thandienewton to thandiwenewton (of course somebody just edited it in-place, without retaining the old name, so now it looks like the thandiwenewton has been used since 2011). Ghouston (talk) 02:05, 9 April 2021 (UTC)[reply]

personally I prefer two entries with the same id with one having an end date (of unknown if we don't know it). BrokenSegue (talk) 02:36, 9 April 2021 (UTC)[reply]

That's the only way that makes sense, I guess. Probably a lot of the start time (P580) statements refer to the account itself, rather than the current name. Ghouston (talk) 02:52, 9 April 2021 (UTC)[reply]

I edited it like that, I used earliest end date (P8554) and latest start date (P8555) since I don't know the exact date. Let's see if a bot comes along and messes it up. Ghouston (talk) 05:26, 9 April 2021 (UTC)[reply]

Search formatter URL[edit]

I'm trying to add the search formatter URL for this property(twitter-domain/search?f=user&q=$1) but it's blocked by the spam filter, does someone know how we could add it? Can admins do it? Abbe98 (talk) 20:21, 17 July 2021 (UTC)[reply]

Inactive accounts[edit]

I found a Swedish Region that stated that the account was inactive so I added the qualifier has characteristic (P1552) with inactive (Q29415492) on the statement. I wonder if anyone has done this in another way or if this could be established as best practice. Ainali (talk) 20:37, 25 July 2021 (UTC)[reply]

I wonder when we would claim that an account becomes inactive. After a year? After two years? Or does it even depend on the account in question?

There is also abandoned account (Q66107668) which appears like it was intended for reason for deprecated rank (P2241), I'm personally not a fan of that pattern. There is no reason to mark a statement as deprecated just because it's inactive... Abbe98 (talk) 07:25, 26 July 2021 (UTC)[reply]

agreed. don't mark deprecated. I would say you can mark an account as inactive if you can find a source that says that. don't mark as inactive merely due to lack of activity. BrokenSegue (talk) 14:01, 26 July 2021 (UTC)[reply]

I mostly agree. However, I tried out deprecating on Q108810321#P2003 and it does feel natural to me. The notice on the account serves as a kind of soft-redirect and I don't think the username should still pop up in queries as a truthy value... Depends on the individual case, maybe? --Azertus (talk) 09:17, 6 October 2021 (UTC)[reply]

@Azertus: sorry but deprecating is wrong. i undid that change. take a look at Help:Deprecation. BrokenSegue (talk) 15:09, 6 October 2021 (UTC)[reply]

URL match is currently broken for "follow URL's"[edit]

The URL match regex worked fine for simple URL's https://twitter.com/andrewstrong_ir but got confused when given a "follow" URL such as https://twitter.com/intent/follow?original_referer=https%3A%2F%2Fwww.antondubeke.tv%2F&ref_src=twsrc%5Etfw%7Ctwcamp%5Ebuttonembed%7Ctwterm%5Efollow%7Ctwgr%5Etheantondubeke&screen_name=theantondubeke and matched the string as "intent"

Have put a simplified version in that will ignore anything starting "intent" and finishing "screen_name=" please feel free to test it

Back ache (talk) Back ache (talk) 08:50, 6 October 2021 (UTC)[reply]

Error on save for no reason[edit]

I was trying to add laardercourantdebel as the Twitter handle of Laarder Courant de Bel (Q108970800). This got me a "Warning: The provided Twitter account is invalid." This is not true. 1Veertje (talk) 18:45, 20 October 2021 (UTC)[reply]

@1Veertje: It’s too long, abuse filter #96 allows only up to 16 characters long user names, and laardercourantdebel is 19 characters. I don’t know why is this limit, but you can try asking the admins to increase the limit. —Tacsipacsi (talk) 21:08, 20 October 2021 (UTC)[reply]

I increased the limit to 20 characters though this particular username doesn't seem to be valid? BrokenSegue (talk) 02:48, 21 October 2021 (UTC) but there are valid usernames above 16 characters. BrokenSegue (talk) 02:50, 21 October 2021 (UTC)[reply]

I had copied it from their contact page. Silly me thinking that would be accurate. Let's see if they changed it or something 🤷‍♂️ 1Veertje (talk) 07:48, 21 October 2021 (UTC)[reply]

Format of usernames (2022)[edit]

We reviewed the question last year: #Format_of_usernames.

As BrokenSegue's bot does most maintenance, I'd tend to support their preference to reformat values into camel-casing. --- Jura 09:59, 18 February 2022 (UTC)[reply]

@Jura1: I'm working on adding this functionality to the bot but re-reading the discussion it seems like lower case was preferred by most (with a object named as (P1932) qualifier). Disagree? BrokenSegue (talk) 18:09, 24 February 2022 (UTC)[reply]

@Jura1: ping on this? I honestly don't care which way we do it. BrokenSegue (talk) 03:11, 17 March 2022 (UTC)[reply]

Fediverse mirrors[edit]

The current constraints allow for a archive URL (P1065) qualifier, however most generic archival methods (like the wayback machine) do not work so well with Twitter's JavaScript-heavy interface. The only usable archives are Mastodon mirrors which replicate the data granularly, I think.

Disclaimer: I recently opened https://respublicae.eu/explore to mirror some EU Twitter accounts. I wonder if there's any value in referencing such mirrors and how to do it. Some accounts may have multiple mirrors, but sometimes mirrors go offline so it should probably be fine to remove them in that case. Nemo 08:09, 10 April 2022 (UTC)[reply]

I personally wouldn't consider Mastodon to be an "archive" of Twitter just because it doesn't also mirror the number of likes, retweets, and comments. I do think modeling it with "Mastodon address" as you did is a good step forward. I'm curious if we want to distinguish between third-party mirrors and first-party ones (e.g. @Kiwix). Legoktm (talk) 16:55, 11 April 2022 (UTC)[reply]

Hm, good point, where to draw a line with metadata to be archived?

I think it's useful to have a distinction but then maybe it's easier to use P4033 in its own statement and add a qualifier to distinguish unsupervised bots like object has role (P3831) robot (Q11012) and unofficial accounts has characteristic (P1552) unofficial (Q29509080) or something.

Currently we have quite a few usages of P4033 but often they're unofficial or abandoned. Nemo 17:19, 11 April 2022 (UTC)[reply]

Video tutorial for P6552[edit]

For those who still want to know how to get a numeric ID, see this thread. Regards Kirilloparma (talk) 20:59, 27 September 2022 (UTC)[reply]

Verified accounts[edit]

With "verification" on Twitter about to change from indicating a verified identity to showing that someone is a Twitter Blue subscriber, would it be possible to change all of the current uses of has characteristic (P1552)verified account or profile (Q28378282) to something more specific like "Twitter profile verified before November 2022" or "Twitter profile with verified identity"? Trivialist (talk) 20:54, 6 November 2022 (UTC)[reply]

the question is whether the API will allow us to distinguish between the two. if so then this isn't a problem we need to deal with now. we can probably wait to find out. BrokenSegue (talk) 23:07, 6 November 2022 (UTC)[reply]

Revision "‎Undo revision 1805627372 by Lectrician1 (talk): While "of" is deprecated it's still used and there is no replacement for this specific case. Removing it also breaks a bunch of tooling. " by Abbe98[edit]

@User:Abbe98 Revision What relationship does "of" make in this case? If you want to say that this is used to identify a Twitter account, well then that is why we have X username (Q53311579)identifies (P10476)X account (Q63976454) and Twitter (X) username (P2002)class of non-item property value (P10726)X username (Q53311579) Lectrician1 (talk) 22:31, 7 January 2023 (UTC)[reply]

@Lectrician1 I completely agree with you but let's migrate all of these uses under coordinated circumstances and at the same time to ensure things don't break. Abbe98 (talk) 12:29, 9 January 2023 (UTC)[reply]

Ok, I am migrating them right now. Lectrician1 (talk) 15:52, 9 January 2023 (UTC)[reply]

Thank you for breaking a bunch of tooling, and just removing the qualifier without an actual migration but rather just a removal. Abbe98 (talk) 12:59, 20 January 2023 (UTC)[reply]

@Abbe98 Can you be more specific about what tooling this breaks? Almost all of the values of the qualifier are already present on statements like applicable 'stated in' value (P9073).

Also, how do you exactly want me to "migrate" them? Lectrician1 (talk) 14:38, 20 January 2023 (UTC)[reply]

Still useful/reliable property?[edit]

Shall still we keep this property? I mean, is that relevant anymore to keep the Twitter Id for a public figure? After the recent disruptive changes in Twitter, an user is no longer reachable by an unlogged user; the number of tweets has been limited for non - subscribers and, basically, Twitter has been hidden behind a subscription wall. Has any sense to keep someone's ID here? -- Blackcat 20:20, 21 July 2023 (UTC)[reply]

yes definitely keep it. BrokenSegue (talk) 00:40, 22 July 2023 (UTC)[reply]

First, all these changes can (and I very much hope that will) be reverted. Second, even as long as/in case they are not reverted, the Twitter username is still a piece of data, and Wikidata collects data. It may make sense to reduce usage of this data (by removing the Twitter links from infoboxes and the like) if this subscription wall remains (but that should be discussed on the individual projects using Wikidata data, not here); reducing usage is also easier to revert than removal of data, should Twitter suddenly become more open after a longer time. —Tacsipacsi (talk) 19:06, 22 July 2023 (UTC)[reply]

Rename to "X username"?[edit]

Should we rename the label for this property? Ainali (talk) 09:33, 18 August 2023 (UTC)[reply]

Yes, we should Escargot bleu (talk) 09:37, 12 December 2023 (UTC)[reply]

Shouldn't this property should still be 'Twitter username', at least while Q918 is still 'Twitter'? Best, A smart kitten (talk) 12:25, 8 January 2024 (UTC)[reply]

I agree, I don't think this should be renamed yet. Plus, we still have Twitter list ID (P10804) and X topic ID (P8672). SWinxy (talk) 20:26, 15 January 2024 (UTC)[reply]

It was renamed by Pablo Busatto (talk • contribs • logs) on 3 Jan 2024. ZandDev (talk) 15:42, 9 February 2024 (UTC)[reply]

does it really matter either way as long as we have aliases? BrokenSegue (talk) 16:54, 9 February 2024 (UTC)[reply]

Property talk:P2002

Documentation

Queries[edit]

Users with more than 5 million followers in 2024[edit]

Journalists on Twitter, by country[edit]

Red Cross societies[edit]

Missing numeric id qualifier[edit]

No recent P8687 value[edit]

P3744 qualifiers to convert to P8687[edit]

Discussion[edit]

Reliable way to get join date?[edit]

P553[edit]

Domain[edit]

Dead people[edit]

Jurisdiction[edit]

Position[edit]

Proposition of a second property for the number of twitter followers[edit]

Not possible to have "no value"[edit]

Twitter: OMP_España[edit]

Single value constraint[edit]

Verification[edit]

Duplicated vakyes[edit]

Renamed accounts?[edit]

Impossible to add resonatecoop[edit]

Multiple Twitter accounts/names with different fields of work, intended audience, responsible individuals, etc.[edit]

Q3749450[edit]

statement or identifier[edit]

Adding a mandatory point in time (P585) qualifier constraint[edit]

Number of tweets[edit]

Reversing the roles of P2002 and P6552[edit]

Representing various account qualities[edit]

What to do with number of followers[edit]

Why am I tripping the abuse filter?[edit]

twitter[edit]

CUENTA DE TWITTER[edit]

Replacing number of subscribers (P3744) with social media followers (P8687)[edit]

Numeric id should not be suggested to users[edit]

Format of usernames[edit]

Fixing single [unique] value constraint violations[edit]

Dedicated items for twitter accounts[edit]

Lower, uppercase or as-written case for account name?[edit]

Renamed accounts (2)[edit]

Search formatter URL[edit]

Inactive accounts[edit]

URL match is currently broken for "follow URL's"[edit]

Error on save for no reason[edit]

Format of usernames (2022)[edit]

Fediverse mirrors[edit]

Video tutorial for P6552[edit]

Verified accounts[edit]

Revision "‎Undo revision 1805627372 by Lectrician1 (talk): While "of" is deprecated it's still used and there is no replacement for this specific case. Removing it also breaks a bunch of tooling. " by Abbe98[edit]

Still useful/reliable property?[edit]

Rename to "X username"?[edit]

Navigation menu

Search