Property talk:P2941

Documentation

• Start a query
• Current uses
• Statistics by class
• String length
• List of qualifiers
• Count

Munk's Roll ID
identifier of a person, in the biographical website of the Royal College of Physicians, London

Applicable "stated in" value	Munk's Roll (Q6936720)
Data type	External identifier
Domain	human (Q5) (note: this should be moved to the property statements)
Allowed values	[a-z][a-z-]+\d?
Example	John Abercrombie (Q14946811) → john-abercrombie John Jackson (Q52222339) → john-jackson Andrew Wilson (Q59985128) → andrew-wilson
Formatter URL	https://history.rcplondon.ac.uk/inspiring-physicians/$1
Tracking: usage	Category:Pages using Wikidata property P2941 (Q54836238)
Related to country	United Kingdom (Q145) (See 329 others)
See also	Australian Medical Pioneers Index ID (P9853), Médicos históricos doctor ID (P5496), Whonamedit? doctor ID (P5415), Historia de la Medicina person ID (P5468)
Lists	Items with the most statements of this property Count of items by number of statements (chart) Items with the most statements Items with the fewest statements Count of items by number of sitelinks (chart) Items with the most sitelinks Items with the most sitelinks, but no link to one Wikipedia (sample: Welsh Wikipedia, cywiki) Items with the fewest sitelinks Most linked wikis Items with the most identifier properties Items with no other external identifier Items with no other statements Most recently created items Items with novalue claims Items with unknown value claims Usage history (total) Usage history (main statement) Chart by item creation date Map of people by place values: place of birth educated at work location residence place of death place of burial January 1st dates People with date of birth on January 1 People with date of death on January 1 People with both dates on January 1 Mix'n'match (Report) Database reports/Humans with missing claims/P2941 Database reports/Constraint violations/P2941 Map Random list
Proposal discussion	Proposal discussion
Current uses	Total 7,699 Main statement 5,855 76% of uses Qualifier 3 <0.1% of uses Reference 1,841 23.9% of uses
Search for values

[create Create a translatable help page (preferably in English) for this property to be included here]

Single value: this property generally contains a single value. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2941#Single value, SPARQL

Distinct values: this property likely contains a value that is different from all other items. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2941#Unique value, SPARQL (every item), SPARQL (by value)

Item “instance of (P31): human (Q5)”: Items with this property should also have “instance of (P31): human (Q5)”. (Help)

List of violations of this constraint: Database reports/Constraint violations/P2941#Item P31, hourly updated report, search, SPARQL

Format “[a-z][a-z-]+\d?”: value must be formatted using this pattern (PCRE syntax). (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2941#Format, SPARQL

Item “occupation (P106)”: Items with this property should also have “occupation (P106)”. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2941#Item P106, search, SPARQL

Scope is as main value (Q54828448), as reference (Q54828450): the property must be used by specified way only (Help)

List of violations of this constraint: Database reports/Constraint violations/P2941#Scope, hourly updated report, SPARQL

Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2941#Entity types

Label required in languages: en: Entities using this property should have labels in one of the following languages: en (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2941#Label in 'en' language, search, SPARQL

ID change

This website has changed its IDs to non-numeric, old links/IDs don't work anymore. I have changed the Mix'n'match property to a new catalog with the non-numeric IDs, and deactivated the old one. I propose the IDs here are changed accordingly, then I can re-enable MnM syncing. --Magnus Manske (talk) 14:11, 9 March 2020 (UTC)

•  Support weird this change needs to be voted on? Looks more like maintenance-as-usual. Can't remember the number of times I have seen "permanent" ids change due to some software upgrade or reorganization of an institute. Jane023 (talk) 16:10, 9 March 2020 (UTC)
• Sure, please make a proposal at Wikidata:Property proposal. --- Jura 16:30, 9 March 2020 (UTC)
•  Support doesn't seem to be a need for a new proposal if we are not changing the purpose of the existing ID, and it's discussed here. From a practical perspective, can we shift over the existing ones easily, or will we need to fully rematch? Andrew Gray (talk) 23:21, 9 March 2020 (UTC)
•  Oppose We should not change the meaning of a property, especially for external IDs. This property is for the old IDs, and a new one for the new IDs should be created. This allows people reusing our data to map the old IDs to the new IDs, instead of breaking whatever they do with them. — Envlh (talk) 08:04, 10 March 2020 (UTC)

Sorry, I didn't see the oppose until after I removed the old IDs. I did save the old ID mappings here though. I guess now the question is - restore the old IDs, or create a new property for the current ones? I'd go for the former myself. Historic use is nice but a bit impractical in this case. --Magnus Manske (talk) 10:33, 10 March 2020 (UTC)

Being bold, importing the new IDs now. Any IDs, especially working ones, are better than none. --Magnus Manske (talk) 09:29, 11 March 2020 (UTC)

•  Support I don't agree that this will change "the meaning" of the property. I agree with Andrew that the "purpose" is unchanged. (On the reuse, it turns out it is possible to query previous states of Wikidata: and therefore the matching can in principle be found.) Charles Matthews (talk) 11:10, 11 March 2020 (UTC)
  • It's a clearly a scheme change and data users who used it before the change now have their matching broken. Data users can include other WMF websites like Commons. --- Jura 12:11, 11 March 2020 (UTC)
    • Yes, it's a schema change (IDs and URL pattern). But since the old IDs did not work for anything on the source site, they were pretty much broken already; what practical purpose would they serve, except for "this used to be the ID" stamp collecting? At least now the IDs are working (albeit with a new URL pattern). If someone really depends on the old ID<=>Wikidata mapping, they can update from my pastebin link above. --Magnus Manske (talk) 13:56, 11 March 2020 (UTC)
      • If these weren't stable identifiers in the first place, I don't think we should have created the property. Users (such as Wikimedia Commons) should still be able to match identifier values with items without having to go through a pastebin. In any case, I think there at least four questions: should we support the new scheme (If we aren't sure any more about the initial choice, maybe no)? how to store the scheme change (versionize definitions or create a new property)? what to do with the old scheme identifiers? Should we care about data users or not (references here, Wikimedia Commons, other WMF projects, others)?

Anyways, I see the discussion was re-opened on: Wikidata:Project_chat#Policy_for_ID/schema_change?. --- Jura 19:26, 11 March 2020 (UTC)

"Stable identifiers" can hardly be locked in when such institutions are involved: their policy making cannot be binding in that way. Look, we have to do our best here. Charles Matthews (talk) 09:44, 12 March 2020 (UTC)

• If it's not a stable identifier, it probably shouldn't be included. --- Jura 11:57, 4 November 2021 (UTC)

Source of duplicates, inadequately described, nearly empty items?

Values from this show up on Wikidata:Database reports/identical birth and death dates/1.

I wonder how many of the 400 redirects were duplicates from its import [1].

This currently finds 2000 items (of the 5400 with the identifier) with only 4 statements, probably dob/dod and the identifier. Most descriptions are limited to full dates of birth and death.

Can this be improved somehow? --- Jura 11:57, 4 November 2021 (UTC)

Same dates

• Q108755317
• Winston Murray Leslie Turner (Q108755383)

have the same lifespan. Could be coincidence or some mixup. --- Jura 21:31, 10 November 2021 (UTC)