Property talk:P4264
Add topicDocumentation
identifier for an official company, school, organisation page, or showcase page, on LinkedIn
List of violations of this constraint: Database reports/Constraint violations/P4264#single best value, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P4264#Unique value, SPARQL (every item), SPARQL (by value)
List of violations of this constraint: Database reports/Constraint violations/P4264#Format, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P4264#Type Q43229, Q1907114, Q35127, Q170584, Q7406919, Q10494269, Q1076486, Q431289, Q13235160, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P4264#Format, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P4264#Conflicts with P553, search, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P4264#Entity types
List of violations of this constraint: Database reports/Constraint violations/P4264#allowed qualifiers, SPARQL
|
This property is being used by:
Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.) |
| ||||||
Discussion
[edit]Link problem
[edit]I use this property for SMATRICS GmbH & Co KG (Q87212466). The correct link is this one. The only problem is that converts a & to a %26 and a ? to a %3F. If this wouldn't happen, the link would work. Any ideas for fixes? --D-Kuru (talk) 01:26, 7 March 2020 (UTC)
required qualifier constraint: online access status
[edit]A lot of LinkedIn accounts qualify for registration required. - Coagulans (talk) 11:10, 23 August 2021 (UTC)
- If registration required or not to view content often depends on user agents and previous visits, I can often see an account on one device but not another one, or can bypass login by using another browser... Is there any company pages that always requires login? Abbe98 (talk) 19:55, 23 August 2021 (UTC)
- Before adding this as a constraint, I would like to see at least one account that is universally not accessible. I'll revert until such proof is posted. Ainali (talk) 15:15, 24 August 2021 (UTC)
- @Ainali, Abbe98: I see we've been discussing this in two places --Azertus (talk) 12:57, 25 August 2021 (UTC)
- There does not seem to be consensus, nor is it actually clear if it's valid for LinkedIn accounts. I don't have LinkedIn and have yet to be unable to access an account. Feel free to point to an account which is universally inaccessible. Abbe98 (talk) 14:04, 25 August 2021 (UTC)
- If you read the linked discussion, you'll see I share your arguments ;-) --Azertus (talk) 15:07, 25 August 2021 (UTC)
- Sorry, I mistakenly addressed OP. Abbe98 (talk) 10:32, 27 August 2021 (UTC)
- If you read the linked discussion, you'll see I share your arguments ;-) --Azertus (talk) 15:07, 25 August 2021 (UTC)
- There does not seem to be consensus, nor is it actually clear if it's valid for LinkedIn accounts. I don't have LinkedIn and have yet to be unable to access an account. Feel free to point to an account which is universally inaccessible. Abbe98 (talk) 14:04, 25 August 2021 (UTC)
- @Ainali, Abbe98: I see we've been discussing this in two places --Azertus (talk) 12:57, 25 August 2021 (UTC)
- Before adding this as a constraint, I would like to see at least one account that is universally not accessible. I'll revert until such proof is posted. Ainali (talk) 15:15, 24 August 2021 (UTC)
Regex validation too strict
[edit]Hello, it seems that the regex validation is incorrectly warning that some values are invalid, when they are indeed valid.
Take for example this link: https://www.linkedin.com/company/pomerleau-inc./ Because of the period in the company ID it doesn't match the provided regex Wolfy13399 (talk) 14:44, 30 April 2025 (UTC)
- Seems like the regex is a bit over-restrictive and LinkedIn actually allows a lot of weird characters. IMO, it's useful to have a somewhat conservative format constraint to draw attention to possible mistakes, but if you know it's not a mistake, I think it's fine to expand the regex as needed. I just had to add fullwidth commas (, (Q87544556)) to the regex because Riitek (Q135956167)'s ID is shenzhen-riitek-co-,ltd. –IagoQnsi (talk) 17:00, 24 August 2025 (UTC)
- There's a UTF-8 apostrope (
') for Q20647765 that doesn't match the regex. It renders in the organisation URL as'%E2%80%8B(ie appended with a zero-width space). Gwirex (talk) 15:10, 29 December 2025 (UTC)
Numeric ID
[edit]LinkedIn assigns every company a numeric internal ID. For example, Brussels Museums (Q15873578) has the numeric ID 10515361. This ID follows the same pattern as the current company URL (https://www.linkedin.com/company/$1). You can locate it in the page’s source code by searching for urn:li:fs_normalized_company:. Using this numeric ID might be a more stable alternative to the current scheme.
JhowieNitnek (talk) 11:45, 25 July 2026 (UTC)
- @JhowieNitnek: I didn't know it was a thing, but I'm all for more stable IDs. That said, I think it might be better to propose a new property for this. Yirba (talk) 13:06, 25 July 2026 (UTC)
- @Yirba I have a few property proposals open so I am not going to propose anything new at this moment but feel gree to propose one yourself! -- JhowieNitnek (talk) 13:08, 25 July 2026 (UTC)
- Fair enough. I may well do so! Yirba (talk) 13:09, 25 July 2026 (UTC)
- @Yirba I have a few property proposals open so I am not going to propose anything new at this moment but feel gree to propose one yourself! -- JhowieNitnek (talk) 13:08, 25 July 2026 (UTC)
- By the way, I don't see
urn:li:fs_normalized_company:in the page source but I do seeurn:li:organization:10515361. When signed in, anyway. When signed out, I just get taken to the login screen. Yirba (talk) 15:03, 25 July 2026 (UTC)- @Yirba Weird I don't have
urn:li:organization:onlyurn:li:fs_normalized_companyJhowieNitnek (talk) 15:07, 25 July 2026 (UTC)
- @Yirba Weird I don't have
Deletion of property restriction
[edit]I have removed the added restriction regarding the qualificator LinkedIn numeric company ID, because contrary to the claim of User JhowieNitnek the identifier cannot simply be found in the source code. As long as this is the case, I consider the restriction on properties to be incorrect. --Gymnicus (talk) 23:47, 15 August 2026 (UTC)
- @Gymnicus Please see the discussion above, where we already discussed this. There are two possible parameters you can look for:
urn:li:organization:orurn:li:fs_normalized_company. - You can find these in the source code of the LinkedIn page. Could you please give me an example of a page where you could not find either of them? -- JhowieNitnek (talk) 11:00, 16 August 2026 (UTC)
- If you had read my comments properly, you would have noticed that I searched the source code specifically for those two terms. However, I cannot find either of these terms and consequently no ID in the source code for any of the examples listed under this property. As long as that remains the case, I am reverting the property restriction. --Gymnicus (talk) 15:42, 16 August 2026 (UTC)
- @Gymnicus I have looked in a on different pages and I can find them every time, are you sure you are doing it properly? @Yirba want to give your 2 cents? -- JhowieNitnek (talk) 18:10, 16 August 2026 (UTC)
- It's probably a bit unhelpful for me to say "it works on my machine", but I have no problem finding it, at least, although you do need to be signed in to LinkedIn. It does seem there are different versions of the HTML that are served (which is why there are the two parameters above). Perhaps there are actually more than two possible parameters. Unfortunately, I'm not sure what's happening in this case that means Gymnicus cannot find the ID. But the IDs certainly do exist, even if they may be difficult to find, so I think the constraint should still be present. Yirba (talk) 18:29, 16 August 2026 (UTC)
- In my case, when I view the source code of a LinkedIn page as an unregistered user, I usually only see various script functions rather than any actual HTML source code; consequently, neither of the two parameters is displayed. As long as the ID isn't easily accessible to everyone, I consider it a mistake to introduce this restriction, especially by making it mandatory. Gymnicus (talk) 22:18, 17 August 2026 (UTC)
- It's probably a bit unhelpful for me to say "it works on my machine", but I have no problem finding it, at least, although you do need to be signed in to LinkedIn. It does seem there are different versions of the HTML that are served (which is why there are the two parameters above). Perhaps there are actually more than two possible parameters. Unfortunately, I'm not sure what's happening in this case that means Gymnicus cannot find the ID. But the IDs certainly do exist, even if they may be difficult to find, so I think the constraint should still be present. Yirba (talk) 18:29, 16 August 2026 (UTC)
- @Gymnicus I have looked in a on different pages and I can find them every time, are you sure you are doing it properly? @Yirba want to give your 2 cents? -- JhowieNitnek (talk) 18:10, 16 August 2026 (UTC)
- If you had read my comments properly, you would have noticed that I searched the source code specifically for those two terms. However, I cannot find either of these terms and consequently no ID in the source code for any of the examples listed under this property. As long as that remains the case, I am reverting the property restriction. --Gymnicus (talk) 15:42, 16 August 2026 (UTC)
- United States-related properties
- All Properties
- Properties with external-id-datatype
- Properties used on 10000+ items
- Properties with single best value constraints
- Properties with unique value constraints
- Properties with format constraints
- Properties with constraints on type
- Properties with scope constraints
- Properties with conflicts with constraints
- Properties with entity type constraints
- Properties with qualifiers constraints