Wikidata:Property proposal/Facebook numeric ID - Wikidata


Article Images

Originally proposed at Wikidata:Property proposal/Authority control

The numeric ID can be found at the source code by looking for page_id or with tools like this one. This could be used for example as a qualifier of Facebook username (P2013), like how we use X numeric user ID (P6552) as qualifier of X username (P2002). It might also make Facebook page ID (P4003) deprecated, since the /pages/ URLs contain the same numeric IDs at the end.

I couldn't find a numeric ID for my own FB profile but some other personal profiles have them, for instance this random fake Bill Gates profile I found still redirects to the correct page if we remove the profile.php?id= part from the URL. –guttitto(talk · contribs) 01:58, 2 February 2023 (UTC)[reply]

  •   Notified participants of WikiProject Authority control,   Notified participants of WikiProject Websites. –guttitto(talk · contribs) 01:58, 2 February 2023 (UTC)[reply]
  •   Comment These numbers seem to work as a value of Facebook username (P2013), but I see the use of separating the usernames from the numeric IDs. The Facebook ID property can take many values that go to the same account. -wd-Ryan (Talk/Edits) 02:30, 2 February 2023 (UTC)[reply]
    Yeah, I see now that one of the property examples does use the numeric ID, since the formatter URL is the same. We could maybe rename it to Facebook username if this passes. –guttitto(talk · contribs) 02:40, 2 February 2023 (UTC)[reply]
      Support as a qualifier to Facebook username (P2013) and to rename Facebook ID to Facebook username. -wd-Ryan (Talk/Edits) 22:32, 3 February 2023 (UTC)[reply]
  •   Support Numeric IDs are much better than usernames that aren't stable and can change at any time. It's quite straightforward to find the the numeric ID. Just view the page source and search for container_id. For instance, suppose I want to find the ID of Emma Raducanu's Facebook page and all I have is the address https://www.facebook.com/EmmaRaducanu/. I view the page source, search for container_id and, lo and behold, I see "container_id":"100067313167825". Thus, her numeric ID is 100067313167825, and https://www.facebook.com/100067313167825 does indeed redirect to the page. This works for both pages and profiles. By the way, there are (at time of writing) 11,557 uses of Facebook username (P2013) where the value is entirely numeric. Most of these will be candidates to migrate to this new property, and I'd suggest updating the format constraint on Facebook username (P2013) to reject entirely numeric identifiers. --Yirba (talk) 18:32, 2 February 2023 (UTC)[reply]
    Thanks, container_id seems to be better than page_id since I could now find my own personal ID with it. –guttitto(talk · contribs) 16:58, 4 February 2023 (UTC)[reply]
    I understand the need as a qualifier, but not as a replacement to Facebook username (P2013) is just easy to use for the casual user. While a bot could add those those numeric values for stability, and update the main value from the qualifier if it changes, I'd not want it encouraged as a top level property. One property for Facebook at that level seems best, and I'd not want the alphanumeric Facebook username (P2013) deprecated, as I think requiring contributors to hunt in page sources would put people off. A bot to convert Facebook page ID (P4003) into a pair of alphanumeric/numeric values so it can be deprecated does seem a good idea. Also while a number is more stable, EmmaRaducanu is much easier to sanity check for someone inspecting the data manually. And if we just want a numeric qualifier, do we really need a new property, why not use numeric value (P1181) Vicarage (talk) 21:54, 6 February 2023 (UTC)[reply]
    To answer the last question, I'd say that the usefulness of it as a property of its own would be the stability factor you mentioned, while the numeric IDs seem to be unique and non-changing for a specific page, the alphanumeric ID/username could probably be changed by the page owner. So if it turned into a dead link, the numeric ID qualifier would still work. –guttitto(talk · contribs) 22:20, 6 February 2023 (UTC)[reply]
    Btw, I agree that we don't necessarily need to get rid of the alphanumeric Facebook ID/username property. The two properties can perfectly co-exist, as the two Twitter properties I exemplified demonstrate. –guttitto(talk · contribs) 22:27, 6 February 2023 (UTC)[reply]
    I think you've made some good points, but I think this should be allowed as a top-level property. Not all Facebook profiles seem to have an alphanumeric username. Looking at that fake Bill Gates profile, for example, it either doesn't have a username or I'm really struggling to find it. Whereas, we know that all Facebook profiles and pages have a numeric ID. If we made the proposed property qualifier-only, then we'd have to set Facebook page ID (P4003) to novalue before we could set this property as a qualifier. I'm not sure if that's desirable or not.
    As for your last sentence about the need for a numeric qualifier, there is a strong precedent of using two properties in tandem: one for the human-readable string, and the other for the permanent ID. Some examples:
    But supposing we said that there shouldn't be a separate property for the numeric ID and we should instead use numeric value (P1181). This presents a few issues:
    • P1181 is really intended for mathematical values, which this isn't. There isn't any significance in the number 100086656281508 other than to identify the user. So I don't think it would be appropriate to use this property.
    • We could potentially have a new generic property called something like "permanent ID" which could be used as a qualifier for a wide range of services. I can see some benefits to this (all services that use permanent IDs that don't already have their own properties could make use of this). However, there are still a few issues:
      • There would be no formatter, so you couldn't click the value to access the external resource. I think it's important to have a link so that if the username changes, you can still easily get to the page.
      • We could potentially get around that by using another qualifier for the link. Maybe something like URL (P2699), although I'm not sure that would make clear the association between that qualifier and the new "permanent ID" qualifier. So we might need yet another qualifier property called something like "URL for permanent ID".
    As an aside, I recently proposed a property Patreon user numeric ID which acts much like the one proposed here. All the points made here also apply to the Patreon property, so I'd appreciate any thoughts on how we should handle permanent IDs in general, not just for Facebook, because I think it's important to be consistent about this. Yirba (talk) 22:10, 7 February 2023 (UTC)[reply]
    I picked numeric value (P1181) after a brief search, there may be better properties. But if we keep coming across sites with this dual alphanumeric/numeric issue, it seems clumsy to keep creating new properties rather than having a single approach. For Facebook, the numeric ID can be applied to Facebook username (P2013) so you could invert the problem and have a number in the ID and the alphanumeric as a generic 'title' qualifier. People could still add alphanumerics, and a bot would spot them and convert to a numeric and add the alphanumeric as a qualifier. Ease of use is key, I know of people who propose changing Mediawiki page references to magic number codes buried in the page information (its 111370672 for this page, BTW), but I'd not support that idea.
    I joined the discussion because I use Facebook ID in my WD derived web pages. I certainly could write the SPARQL to pick one of 3 ways to refer to a page, and then prepend facebook.com, but its a barrier to use, and would make my queries that bit more likely to timeout. I dutifully lookup YouTube channel ids using a 3rd-party site when adding them, but again its a barrier to populating the database.
    A numeric only page can just use it in Facebook username (P2013), and no title qualifer. Its more of a problem if the alphanmeric and numeric formatters for a site need to be different of course.
    I agree that a unified approach is best, even if leads to deprecation of existing properties like Twitter numeric ID. If that means 2 new generic properties, that might be better than many specific ones. Perhaps the discussion should be advertised on Project Chat to seek wider opinions. Vicarage (talk) 23:06, 7 February 2023 (UTC)[reply]
    Thanks for your suggestion. I have started a discussion at Wikidata:Project chat#How should we represent external identifiers where there is both a permanent ID and a human-friendly ID?. I'm not entirely sure what the best solution to this is, but it would be good to build consensus and find a consistent way of doing this. Yirba (talk) 00:38, 8 February 2023 (UTC)[reply]
    The discussion has now been archived. Many ideas were put forwards and I'd suggest that the conclusion is that a long-term solution would be to have a new datatype that combines human-readable username and persistent ID values. However, in the meantime, we should make do with two properties.
    I believe the proposed property is consistent with this short-term solution and other similar properties. I appreciate the concerns that were raised, and I think they have now been addressed. Yirba (talk) 22:30, 21 February 2023 (UTC)[reply]
  • Per suggestions from discussion I mark this as ready. Midleading (talk) 03:44, 31 March 2023 (UTC)[reply]