Property talk:P1456

Documentation

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

list of monuments
link to the list of heritage monuments in the place/area

Description	link to the list of heritage monuments in the place/area.
Represents	monument (Q4989906)
Data type	Item
Domain	According to this template: place, local or regional category of monuments According to statements in the property: geographic location (Q2221906) When possible, data should only be stored as statements
Allowed values	lists of heritage monuments (note: this should be moved to the property statements)
Example	Český Krumlov (Q188082) → list of cultural monuments in Český Krumlov (Q12052348) Saint-Paul (Q316887) → liste des monuments historiques de Saint-Paul (Q3252197) Glacier National Park (Q373567) → National Register of Historic Places listings in Glacier National Park (Q6976143)
Source	monument database of Wiki Loves Monuments
Tracking: usage	Category:Pages using Wikidata property P1456 (Q23909129)
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 By value of property Most statements Fewest statements Most sitelinks Most linked wikis Most identifiers 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 Database reports/Constraint violations/P1456 Map Random list
Proposal discussion	Proposal discussion
Current uses	Total 21,723 Main statement 21,718 >99.9% of uses Qualifier 3 <0.1% of uses Reference 2 <0.1% of uses
Search for values

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

Item “country (P17)”: Items with this property should also have “country (P17)”. (Help)

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

Item “located in the administrative territorial entity (P131)”: Items with this property should also have “located in the administrative territorial entity (P131)”. (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/P1456#Item P131, search, SPARQL

Value type “Wikimedia list article (Q13406463)”: This property should use items as value that contain property “instance of (P31)”. On these, the value for instance of (P31) should be an item that uses subclass of (P279) with value Wikimedia list article (Q13406463) (or a subclass thereof). (Help)

List of violations of this constraint: Database reports/Constraint violations/P1456#Value type Q13406463, hourly updated report, SPARQL

Type “geographic location (Q2221906)”: item must contain property “instance of (P31)” with classes “geographic location (Q2221906)” or their subclasses (defined using subclass of (P279)). (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/P1456#Type Q2221906, SPARQL

Property “country (P17)” declared by target items of “list of monuments (P1456)”: If [item A] has this property with value [item B], [item B] is required to have property “country (P17)”. (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/P1456#Target required claim P17, SPARQL, SPARQL (by value)

Property “is a list of (P360)” declared by target items of “list of monuments (P1456)”: If [item A] has this property with value [item B], [item B] is required to have property “is a list of (P360)”. (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/P1456#Target required claim P360, SPARQL, SPARQL (by value)

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/P1456#Unique value, SPARQL (every item), SPARQL (by value)

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

List of violations of this constraint: Database reports/Constraint violations/P1456#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/P1456#Entity types

This property is being used by: uk:Шаблон:Населений пункт Словаччини de:Vorlage:Navigationsleiste Denkmalgeschützte Objekte, de:Vorlage:Navigationsleiste Denkmalgeschützte Objekte Österreich, de:Vorlage:Navigationsleiste Denkmalgeschützte Objekte Österreich Katastralgemeinde Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

source

using https://commons.wikimedia.org/wiki/Commons:Monuments_database as a source / Quelle might be convenient, but is a wikiverse self-reference and should be avoided. Instead, the real local, country dependent, monument repositories should be used instead. Otherwise this will hide the real origin of data. --Herzi Pinki (talk) 07:21, 29 May 2017 (UTC)

• These lists aren't meant as a reference for individual entries (an item about a monument). This property is to link items for specific lists at Wikipedia, similar to category of associated people (P1792) that is meant to link to items for categories. There are several such properties. This shouldn't link actual databases.
  --- Jura 04:08, 25 August 2017 (UTC)

@Jura1:, the monument database is NOT a specific list at WP, but a database extracted from various lists. Wikidata property example (P1855) for this property links to a specific list, which is ok, but source website for the property (P1896) says it is extracted from the monument database, which might be true, but is not ok. Furthermore the monument database is also used for reference URL (P854), where I would expect a reliable external source and not some internal self-reference. regards --Herzi Pinki (talk) 08:12, 25 August 2017 (UTC)

I have a hard time imagining an external reference for:

"Český Krumlov" = (Q188082) category of associated people (P1792): Category:People from Český Krumlov (Q8755463))

If it's added in an automated way, it needs to be imported from Wikipedia or Commons in one way or the other. I don't see much of a difference to this property.

The part I don't quite like about the sample for P1456 is that it's missing at Q188082.
--- Jura 08:22, 25 August 2017 (UTC)

Sorry, did not talk about people, but monuments. For monuments (which is an offical status), there must be some external definition, what is a monument and what isn't. For the Austrian monuments, let me outline the process:

1. Our data provider (Bundesdenkmalamt, BDA for short), an administrative unit of the Austrian government, has a database about what is protected and what isn't
2. BDA issues lists of monuments once a year (one list per federal state). Not everything is published for various reasons. But these data are available in machine readable format.
3. With the help of a bot and with some helping hands, we transform the monuments to lists per municipality. People augment data e.g. by adding coordinates (which are not part of the official data). They change various things and they make errors.
4. Multichill now uses these lists to fill the monument database.
5. then some wikidata bot harvests the monument database and adds information to WD giving the monument database as the source. The real source however is the published data from BDA. This information gets lost.
6. in the end some sv or ceb bots automatically create lists of monuments or articles about monuments and give the monument database as a source. Even more, external users of Wikidata might do the same. The tracability to the real source is completely hidden.

Even if it is technically the easiest way to get the data from the monument database, you cannot use this as the written source. In all of our mounument lists in the WP:de the data source used is stated and could be extracted as well. Situation should be similar in other countries, but of course details will differ. If the list was created by some benevolent expert without any official source, this is the wrong stuff for the monument database. --Herzi Pinki (talk) 11:21, 25 August 2017 (UTC)

• Do we talk about references for P1456 claims here, or about stated in (P248)/imported from Wikimedia project (P143) Wiki Loves Monuments monuments database (Q28563569) references on claims of other properties? —MisterSynergy (talk) 09:18, 25 August 2017 (UTC)

Hi, sorry, if this was the wrong place to start, I'm talking as well about stated in (P248), publication date (P577), reference URL (P854) (e.g. at Gasthof Kandolf, Tamsweg (Q37920354)). But this here is the simple case: monument lists do not come out of the monument database, but from various Wikipedias. This is not a formal question, formally everything is ok, you use the monument database as a source, you're honest and state the monument database as a source, but semantically this leads to intrinsically correct self-references without any chance to validate against the original source. regards --Herzi Pinki (talk) 11:21, 25 August 2017 (UTC)

Okay, I think I understand. Some remarks:

• At Wikidata, Wikimedia-internal references are somewhat accepted, and particularly desired if they help to indicate data provenance of imported data. Since a large part of information was in fact imported from other Wikimedia projects, this is very useful especially when mistakes show up. Data users have to judge each and every reference individually anyway to decide whether they consider a particular information as sourced or not in their environment. In most cases this can be done automatically (as some Wikipedia templates do).
• There are plenty of references which use Wiki Loves Monuments monuments database (Q28563569) as a value: this query shows ~1.34M references with stated in (P248) and 437k references with imported from Wikimedia project (P143).
• Nevertheless, your request for (additional) external references to the original sources is correct. Import references do not supersede external references permanently. Unfortunately the Wiki Loves Monuments monuments database (Q28563569) does not contain information about original sources right now, as far as I can see. Is that correct? If so, it will be very difficult to add sources on a reasonable scale, taking into account that there are already 1.8 million referenced claims about monuments at Wikidata. This needs to be fixed automatically somehow.

Without any experience with the monuments project at Commons it is difficult to offer more help here. I can't even locate the original source for your example item Gasthof Kandolf, Tamsweg (Q37920354), and I don't know whether it is machine-readable. Regards, MisterSynergy (talk) 11:49, 25 August 2017 (UTC)

You got it, and of course this is a mass problem. And of course it is difficult. But necessary. Your last statement about not finding the source for Gasthof Kandolf, Tamsweg (Q37920354) is just a prove of my concerns, the trace back to the original source is broken (in reality it is not, it is just three clicks away, using another external (and somehow deprecated) application, which is kept alive with awe) Having your understanding: how can I / we proceed? --Herzi Pinki (talk) 12:11, 25 August 2017 (UTC)

Well, good question. It kinda depends on many factors.

• Do you plan to have a co-existence of Wiki Loves Monuments monuments database (Q28563569) and information at Wikidata? If so, how do you keep them synchronized? How do you handle (annular) updates of the external source?
• Are you interested to fix monument data references in all countries, or just a particular one (e.g. Austria)?
• Given the fact that we have ~1.8M references to the monument database here at Wikidata, I suppose it also was to a large extent compiled from original sources with a script. Is this correct? Do you think it is possible to complement (external) references to its entries? If so, it would be not so difficult to add them to Wikidata items as well (with bot). Otherwise things would be very difficult.
• Maybe it is necessary to set up some mapping for each external database individually. I really have no idea how the external sources look like. The only identifier in the example item does not link to an external web service as well. Meanwhile GLAMs and other maintainers of cultural heritage more and more start to provide their data in machine-readable form (JSON format, etc.), ideally following some common standards. If that was the case here, things would be much easier.
• Having this data at Wikidata might already be valuable for data curation, even if the original sources are still missing. However, external references would also make it possible to re-use the data in Wikipedias.

Difficult case. Who else is involved in Wiki Loves Monuments monuments database (Q28563569) and the import job to Wikidata? —MisterSynergy (talk) 13:15, 25 August 2017 (UTC)

Okay, I meanwhile found the heritage project on Toolforge and the mechanism how the Monuments database is harvested from structured Wikipedia lists about monuments. The example item was probably crawled from de:Liste der denkmalgeschützten Objekte in Tamsweg, which also includes the original source (of which the CSV version is somewhat machine-readable, but CSV isn't really the best way to go).

The link between individual data points and the source is in fact already lost in the Wikipedia article, which combines information from the source as well as “unsourced” complemented information (such as the links to images, descriptions, etc). That means that source information can't really be imported to the Monuments database. Whatever you want to do to add references at Wikidata basically needs individual setup on a per-source basis. Not good. —MisterSynergy (talk) 13:58, 25 August 2017 (UTC)

MisterSynergy, thanks for your attention. Your analysis is correct as far as I know. Let me answer the questions:

• We, in Austria, do handle annual updates based on the lists in the German WP. We change properties, we add entries, and move entries to the section of former monuments. This is done based on information provided by Krdbot, who does some kind of three way merge (with the merge part done manually). This process is only based on the monument lists in the German WP and the new data (CSV format) from our data provider. It takes two weeks to complete with a handful of people working more or less on it.
• The monument database is doing some harvesting from the lists in the WP:de. So the primary source still are the lists. (the monument database does not care for former monuments, a pity)
• For me the monument database is legacy. As soon as Wikidata is capable of holding the necessary information, no monument database is needed any more. Wikidata will become the new monument database.
• Some entries related to the monument database are obviously wrong, like the publication date (P577), which does not match the constraints.
• I'm just thinking about the monuments in Austria (it is full time job for some years now), but if we can give good examples, well, ...
• It will be possible to add external references to wikidata, either by the bot who supports the annual update or by some new feature (@Thomas Ledl, André_Costa_(WMSE), Alicia Fagerving (WMSE): are working on. - that's why I reactivated my forgotten question from May.
• The team is working now on bringing the ids to wikidata (and also the protected monuments to wikidata), and in reverse Thomas Ledl will be adding the wikidata id to our monument lists. Then we can check for synchronous data and later we can get provider specific data from wikidata.
• As a long told story that did not come true yet: Our data provider will change the database completely, objects will be identified by separate resources (URIs) instead of the IDs you know by now. But this will allow to address objects individually. But until then we will stick to 9 different CSVs for the 9 federal states of Austria. We do not have a choice to get some other format.
• The connection to the primary source is not lost completely, the tupel of (federal state, id) will identify each entry uniquely. Ids are globally unique, but data is split into 9 separate CSVs. We have a region iso code in each entry, which corresponds perfectly with the CSVs. So from Iso code & ID, we could generate a globally unique object identification allowing to access the correct CSV (and to address the individual object in the CSV, if odbc allows). CSVs for federal states do change their names every year, so some linkage code would be necessary and must be maintained.
• What we want (in the end): Have all the data from our provider in Wikidata (since 2016 they are published under a pd license, which is good for wikidata); create the monument lists dynamically from wikidata and merge entries with other information not in wikidata (like language dependent descriptions, personal choice of images, etc.) - no idea how this will work. And have the update process run on Wikidata instead on the lists in Wikipedia. This mechanism shall allow not only to create a list for a municipality (as we do have now), but for a freely defined scope (like all gothic churches in Austria, all statues of John of Nepomuk in a federal state, etc., ad hoc and fully dynamic). In short: less maintenance, less manual list crafting, less edit wars about nothing (like the official names given from the provider).

regards --Herzi Pinki (talk) 18:38, 25 August 2017 (UTC)

• The long-term goal of that plan sounds very nice, but there is of course a lot of work to do.
• It is useful to have a link between an entry in any external database and the Wikidata item about the object—inside Wikidata (i.e. add suitable identifiers to the Wikidata objects). The example item does already have such an identifier, but I am not sure whether this is the case for all objects. It is pretty simple to update Wikidata items if this link is properly set up, so consider the identifier claims as an important base for future tasks. Resolvers such as resolver do already exist (this one redirects to our example item).
• Working with URIs in future is a very good idea; I recently worked on a task with a library that offers Handle System (Q3126718) identifiers for the objects they manage, which is very comfortable (there are also alternative services available to my knowledge). Those identifiers are typically stable for very long times, and unique world wide (unlike string/number IDs).
• If you have contact to your data provider (Bundesdenkmalamt (Q876452), right?), advice them to provide different output formats as well, and data on a per-monument base. JSON is very useful format when working with Python, XML might also be valuable. Wikidata can do this as well (e.g. [1] for the example item). I don’t know whether there is a “standard vocabulary” available for monument data to name fields in such formats, but if heritage maintainers would agree on a standard output vocabulary, processing of different sources from different maintainers would become easier.

Good luck! —MisterSynergy (talk) 21:14, 25 August 2017 (UTC)

Short comment. The imported from Wikimedia project (P143)Wiki Loves Monuments monuments database (Q28563569) is added for a couple of reasons.

1) WD:BOT requires imported statements to have a source

2) Since there is an url to the particular entry it's easy to find out if we did a mistake during the migration (for anyone wanting to verify)

3) It is the de-facto source of the info (since we cannot say if the data has been manually updated between being imported from the original source to Wikipedia and being harvested by the Monuments Database).

I would compare it to the imported from Wikimedia project (P143)English Wikipedia (Q328) statements (but slightly more useful) in that it gives an indication of where a more appropriate source can be found. Sadly investigating the original sources for the list is not possible if we want to migrate all of the monuments in the Monument Database to Wikidata.

I would also argue that these source statements could be removed once you have added a proper source statement for the same claim (and similarly for imported from Wikimedia project (P143)English Wikipedia (Q328)). But that is the topic of a bigger discussion =). /André Costa (WMSE) (talk) 10:11, 29 August 2017 (UTC)