Property talk:P381
Documentation
identifier for cultural properties in Switzerland
Description | identifier for cultural properties in Switzerland | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Represents | class A Swiss cultural property of national significance (Q8274529), class B Swiss cultural property of regional significance (Q12126757) | ||||||||||||
Associated item | Swiss Federal Office for Civil Protection (Q3349626) | ||||||||||||
Data type | External identifier | ||||||||||||
Domain | According to this template:
cultural property (Q2065736), either class A Swiss cultural property of national significance (Q8274529) or class B Swiss cultural property of regional significance (Q12126757)
According to statements in the property:
When possible, data should only be stored as statementsgeographical feature (Q618123), collection (Q2668072), item of collection or exhibition (Q18593264), organization (Q43229), watercraft (Q1229765) or work of art (Q838948) | ||||||||||||
Allowed values | \d{5,5} (alway 5 digits, leading zero's are added) | ||||||||||||
Example | Lugano railway station (Q174946) → 05559 Zwingli house (Q244845) → 08422 | ||||||||||||
Source | en: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 URL | https://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 jobs | DeltaBot does the following jobs: | ||||||||||||
Tracking: usage | Category:Pages using Wikidata property P381 (Q56243189) | ||||||||||||
Related to country | Switzerland (Q39) (See 75 others) | ||||||||||||
Lists |
| ||||||||||||
Proposal discussion | Proposal discussion | ||||||||||||
Current uses |
| ||||||||||||
Search for values |
List of violations of this constraint: Database reports/Constraint violations/P381#Format, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P381#Single value, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P381#Unique value, SPARQL (every item), SPARQL (by value)
List of violations of this constraint: Database reports/Constraint violations/P381#Item P625, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P381#Type Q618123, Q2668072, Q18593264, Q43229, Q1229765, Q838948, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P381#Entity types
List of violations of this constraint: Database reports/Constraint violations/P381#Item P31, search, SPARQL
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- Inventory of Cultural Property in Switzerland:
- GIS Portal of Cultural Properties in Switzerland (contains only A-objects, i.e. cultural properties of national significance, as of July 2013):
See also: Tentative list of requirements for items with the property P381 --Beat Estermann (talk) 17:14, 28 July 2013 (UTC)
Issues encountered when removing constraint violations
editHow best to link a building to a collection?
- Musée d'art et d'histoire (Geneva): Musée d'Art et d'Histoire (building) / Musée d'art et d'histoire
- Maison Tavel (Geneva): Tavel House / Maison Tavel (Museum)
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:
- Kantonsbibliothek Appenzell Ausserrhoden: Cantonal Library of Appenzell Ausserrhoden / Cantonal Library of Appenzell Ausserrhoden (PCP category B object)
- Stadtbibliothek St. Gallen
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)
- For bridges with multiple PCP reference numbers (e.g. Wooden Bridge across the Reuss river (Sins-Hünenberg) (Q2146628)) it is engouh to have one item and add all PCP reference numbers to this item.
- For museums I would say it is eligible to have three items: one for the collection, one for the orgianisation and one for the building. They can be linked by headquarters location (P159) or similar properties. --Pasleim (talk) 14:19, 14 September 2014 (UTC)
Proposal to change the constraints
editWorking 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:
- 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.
- 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)
- 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)
- 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)
- 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)
- 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)
- 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.
- 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)
- 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)
- 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)
- 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)
Link to official database
editIt 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)
- 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)
- 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)
PCP reference number (P381) - Broken link with leading 0's
editHello
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)
- Siehe auch
- M2k~dewiki (talk) 14:47, 25 January 2023 (UTC)
- https://phabricator.wikimedia.org/T327956 M2k~dewiki (talk) 20:56, 25 January 2023 (UTC)
- I added a temporary fix until T327956 is fixed. Lockal (talk) 10:02, 28 January 2023 (UTC)
- @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)
- 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)
- @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)
- 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)
- @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)
- I added a temporary fix until T327956 is fixed. Lockal (talk) 10:02, 28 January 2023 (UTC)
- https://phabricator.wikimedia.org/T327956 M2k~dewiki (talk) 20:56, 25 January 2023 (UTC)