Property talk:P381

From Wikidata
Jump to navigation Jump to search

Documentation

PCP reference number
identifier for cultural properties in Switzerland
Descriptionidentifier for cultural properties in Switzerland
Representsclass A Swiss cultural property of national significance (Q8274529), class B Swiss cultural property of regional significance (Q12126757)
Associated itemSwiss Federal Office for Civil Protection (Q3349626)
Data typeExternal identifier
Domain
According to statements in the property:
geographical feature (Q618123), collection (Q2668072), item of collection or exhibition (Q18593264), organization (Q43229), watercraft (Q1229765) or work of art (Q838948)
When possible, data should only be stored as statements
Allowed values\d{5,5} (alway 5 digits, leading zero's are added)
ExampleLugano railway station (Q174946)05559
Zwingli house (Q244845)08422
Sourceen:Swiss Inventory of Cultural Property of National and Regional Significance (note: this information should be moved to a property statement; use property source website for the property (P1896))
Formatter URLhttps://wikidata-externalid-url.toolforge.org/?url=https%3A%2F%2Fheritage.toolforge.org%2Fapi%2Fapi.php%3Faction%3Dsearch%26format%3Dhtml%26srcountry%3Dch%26srid%3D%251&exp=0*(.*)&id=$1 (Redirect to heritage.toolforge.org with removed leading zeros)
https://heritage.toolforge.org/api/api.php?action=search&format=html&srcountry=ch&srid=$1 (Does not work for identifiers starting with 0)
Robot and gadget jobsDeltaBot does the following jobs:
Tracking: usageCategory:Pages using Wikidata property P381 (Q56243189)
Related to country Switzerland (Q39) (See 75 others)
Lists
  • Items with the most statements of this property
  • Count of items by number of statements (chart)
  • Count of items by number of sitelinks (chart)
  • 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)
  • Chart by item creation date
  • Database reports/Constraint violations/P381
  • Map
  • Random list
  • Proposal discussionProposal discussion
    Current uses
    Total13,675
    Main statement13,40698% of uses
    Qualifier2601.9% of uses
    Reference9<0.1% of uses
    Search for values
    [create Create a translatable help page (preferably in English) for this property to be included here]
    Format “1?\d{1,5}: value must be formatted using this pattern (PCRE syntax). (Help)
    List of violations of this constraint: Database reports/Constraint violations/P381#Format, hourly updated report, SPARQL
    Format “\d{5,5}: 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/P381#Format, SPARQL
    Item “country (P17): Switzerland (Q39): Items with this property should also have “country (P17): Switzerland (Q39)”. (Help)
    List of violations of this constraint: Database reports/Constraint violations/P381#Item P17, hourly updated report, search, SPARQL
    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/P381#Single value, SPARQL
    Item “coordinate location (P625): Items with this property should also have “coordinate location (P625)”. (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/P381#Item P625, 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/P381#Entity types
    Item “instance of (P31): Items with this property should also have “instance of (P31)”. (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/P381#Item P31, search, SPARQL
    Scope is as main value (Q54828448), as qualifier (Q54828449): the property must be used by specified way only (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/P381#Scope, SPARQL
    This property is being used by:

    Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)



    References

    [edit]

    See also: Tentative list of requirements for items with the property P381 --Beat Estermann (talk) 17:14, 28 July 2013 (UTC)[reply]

    Issues encountered when removing constraint violations

    [edit]

    How best to link a building to a collection?

    Objects spanning several municipalities have one PCP reference number per municipality; this is typically the case for bridges. In these cases, a cultural property should have two or more PCP reference numbers. Example:

    There are some instances of collections where a part of the collection does not have the same protection status as the whole:

    In the case of heritage institutions, there is often confusion between the organisation and its collection(s). - Should they be disentangled? - Examples include:

    • Musée d'art et d'histoire (Geneva): It is an organisation located in a building (with a PCP number for the building) and has a collection (with another PCP number for the collection). Right now, the Wikidata entry for the organisation and for the collection are confounded, as the Wikipedia article is about the organisation and we just added the PCP number referring to the collection to the same Wikidata entry.
    • Kantonsbibliothek Appenzell Ausserrhoden: Here one part of the collection is confounded with the organisation (the Wikidata entry for the organisation has the corresponding PCP number), while another part of the collection has its own Wikidata entry with a different PCP number.

    --Beat Estermann (talk) 21:20, 7 September 2014 (UTC)[reply]

    Proposal to change the constraints

    [edit]

    Working on the organization of WLM 2018 I found a lot of constrains, so I would like to propose some changes on the constraints of this property. In particular:

    1. located in the administrative territorial entity (P131): this property ask to indicate the lowest administrative location, but our property needs that we indicate also the canton. I suggest to remove the constraint of indicate the canton.
    2. P969 (P969): I suggest to remove this constraint, because also official lists doesn't indicate the addresses for all the monuments.

    Thanks --CristianNX (talk) 08:20, 25 August 2018 (UTC)[reply]

     Support. About the address, there are also elements that cannot have an address, such as boats or collections (unlike the buildings were they are kept). And yes, I think the indication of cantons in located in the administrative territorial entity (P131) is wrong. --Yiyi .... (talk!) 08:27, 25 August 2018 (UTC)[reply]
    • Not sure. None of these constraints are mandatory, so if you can't fill the data, don't worry about it. Someone else eventually might do so.
    It's possible to indicate several levels in P131. There is nothing "wrong" about it. There is no need to remove layers one doesn't want. The problem with indicating low levels is that they keep getting invalid. To avoid too much maintenance, I think it's good to focus on stable layers.
    P969 (P969): looking at the items that are currently lacking it, I think many could still use it.
    For most purpose, coordinate location (P625) is probably better anyways.
    --- Jura 08:41, 25 August 2018 (UTC)[reply]
    It's not mandatory, but it's strange: P131 want the lowest administrative location, as municipality or others lowest levels, but P381 wants the cantons, that's not correct for P131. It's possible to indicate several levels in P131, but I assure you that there are cases where users remove the cantons, according to the P131 indication. As you said, it's not mandatory, but as wikimedians we have to do things in a correct way, and this situation is like "a dog biting its own tail". --CristianNX (talk) 09:03, 25 August 2018 (UTC)[reply]
    It's possible that some users incorrectly remove valid content. It's a wiki afterall. Anyways, what problem are you trying to solve? It should be possible to organize your 2018 event without undoing the whole database. Depending on what you are looking for, you could just adjust the query.
    --- Jura 09:08, 25 August 2018 (UTC)[reply]
    I'm not talking about undoing the database or working massively on items to remove informations, I'm just suggesting to remove a constraint from this property. Because when you indicate where a monument is (municipality or quarter) you simply don't need to indicate other higher administrative levels. If these informations are indicated, just keep them where they are. I was only suggesting to remove "the indication of the canton" as a constraint (even not mandatory) for P381: it's not fundamental, it's only a proposal to solve a strange vicious circle between different property constraints. --CristianNX (talk) 09:41, 25 August 2018 (UTC)[reply]
    I support the removal of these constraints. located in the administrative territorial entity (P131) should always only be used for the lowest level and moveable objects can not have a P969 (P969). --Pasleim (talk) 16:25, 25 August 2018 (UTC)[reply]
    I agree to leave the address as constraint. Some monuments are based in strange positions (i.e. in a forest) and they don't have an address, while the Geo coords are more helpful. --Ilario (talk) 13:07, 26 August 2018 (UTC)[reply]
    • Do we have an estimate how many monuments this concerns? What do you consider moveable? Which ones shouldn't have an address? If there are just a few, it's better to keep the constraint and just list (e.g.) 5 boats as exceptions. Moveable ones are likely to have other issues as well. Besides, as long as it's not mandatory, it's just considered a potential issue. Currently, there are some 1000 items missing this and many should actually have them.
      --- Jura 13:23, 26 August 2018 (UTC)[reply]
    [edit]

    It seems that currently for a given topic (such as port facility with pier, railroad station and warehouses (Q95984300)) we link to a Wikimonuments database and generate a link like this: https://tools.wmflabs.org/heritage/api/api.php?action=search&format=html&srcountry=ch&srid=5146 (or https://tools.wmflabs.org/heritage/api/api.php?action=search&format=html&srcountry=ch&srid=$1). However there is also an official database that uses the same identifier from the Swiss government and it would be neat to link to that too: https://api.geo.admin.ch/rest/services/ech/MapServer/ch.babs.kulturgueter/5146/extendedHtmlPopup?lang=en (eg https://api.geo.admin.ch/rest/services/ech/MapServer/ch.babs.kulturgueter/$1/extendedHtmlPopup?lang=en) . Would that gain support here and if so, is that technically possible? I think this would be a great benefit for users since linking to official government databases should be the "gold" option. What are your thoughts? Best --Hannes Röst (talk) 14:24, 11 June 2020 (UTC)[reply]

    I basically support changing the formatter URL but it seems like the official database is missing many entries, e.g. Zwinglikirche (Q244838) [1] or Lugano railway station (Q174946) [2]. --Pasleim (talk) 09:41, 14 June 2020 (UTC)[reply]
    It seems like they only have entries for the A objects -- I wonder if there is a way to add the link only to those entries. --Hannes Röst (talk) 03:10, 29 July 2020 (UTC)[reply]
    [edit]

    Hello The number scheme for PCP reference number (P381) has changed to 5-digit with leading zeros , regardless the number e.g. 13 becomes 00013 288 becomes 00288 or 9876 becomes 09876. - Source: https://www.babs.admin.ch/en/aufgabenbabs/kgs/inventar.html

    The links in WD do not work any more with leading 0's. Examples: Amthaus of the former monastery St. Blasien (Q19362321), Marschallhaus (Q17505197), upper tower (Q19362324) If you click the 5-digit Number after PCP reference number in the WD item, it shows a white background of the landing page.

    IHMO it's a bug what need sto be fixed.

    cheeers, AnBuKu (talk) 14:40, 25 January 2023 (UTC)[reply]

    Siehe auch
    M2k~dewiki (talk) 14:47, 25 January 2023 (UTC)[reply]
    https://phabricator.wikimedia.org/T327956 M2k~dewiki (talk) 20:56, 25 January 2023 (UTC)[reply]
    I added a temporary fix until T327956 is fixed. Lockal (talk) 10:02, 28 January 2023 (UTC)[reply]
    @AnBuKu, M2k~dewiki, Lockal: I just noticed this topic. Looks like all lists on German Wikipedia have the leading zero's now. We should probably apply that change here too and on Commons. I can do the change on Commons. Anyone else who can do it here? Than we'll have everything in sync again. Multichill (talk) 19:41, 26 August 2024 (UTC)[reply]
    Basically there are 5-digit numbers for KGS objects since beginning 2023. Means, for numbers before 2023 consisting of 2 or 3 or 4 digits, the space before the number is filled up with zeros. Example. 456 -> 00456 or 2378 -> 02378
    cheers, h. AnBuKu (talk) 20:23, 26 August 2024 (UTC)[reply]
    @AnBuKu: I know how it works, I'm just asking someone else to fix it here.
    I'll probably end up doing it myself, but it's worth a try :-) Multichill (talk) 21:22, 26 August 2024 (UTC)[reply]
    Oh, you mean with "here" Wikidata, right? I, a non techie dude, fixed them so far by hand, when I met them during my work. :-( AnBuKu (talk) 21:30, 26 August 2024 (UTC)[reply]