Property talk:P2941

Active discussions

Documentation

Munk's Roll ID
identifier of a person, in the biographical website of the Royal College of Physicians, London
[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.
List of this constraint violations: Database reports/Constraint violations/P2941#Single value, SPARQL, SPARQL (new)
 
Distinct values: this property likely contains a value that is different from all other items. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P2941#Unique value, SPARQL (every item), SPARQL (by value), SPARQL (new)
 
Item “instance of (P31): human (Q5): Items with this property should also have “instance of (P31): human (Q5)”. (Help)
List of this constraint violations: Database reports/Constraint violations/P2941#Item P31, hourly updated report, search, SPARQL, SPARQL (new)
 
Format “[a-z][a-z-]+\d?: value must be formatted using this pattern (PCRE syntax). (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P2941#Format, SPARQL, SPARQL (new)
 
Item “occupation (P106): Items with this property should also have “occupation (P106)”. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P2941#Item P106, search, SPARQL, SPARQL (new)
 
Scope is as main value (Q54828448), as reference (Q54828450): the property must be used by specified way only (Help)
List of this constraint violations: Database reports/Constraint violations/P2941#scope, hourly updated report, SPARQL, SPARQL (new)
 
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.
List of this constraint violations: Database reports/Constraint violations/P2941#allowed entity types, SPARQL (new)


ID changeEdit

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)

Return to "P2941" page.