Wikidata talk:WikiProject WLM/Mapping tables/at (de)

Special case: Hochquellwasserleitungen

• Hochquellwasserleitung
  • XX XX Einstiegsturm 1
  • XX XX Einstiegsturm 2
  • XX XX BDA-Objekt "Einstiegsturm 3 & 4"
    • XX XX Einstiegsturm 3
    • XX XX Einstiegsturm 4
  • XX XX 3Kanalbrücke 5
    • XX XX BDA-Objekt "Linker Brückenteil"
    • XX XX BDA-Objekt "Rechter Brückenteil"

Legende

• XX NULL
• XX BDA-Object
• XX Real-life-object

monument id should not be part of description

moved to here from User talk:Alicia Fagerving (WMSE)

Tracked in Phabricator
Task T175369

Hi Alicia, looking at Gerspointgut Blühenbach (Q37921754) and similar objects for cultural heritage monuments in Austria, first I wanna thank you that you are doing this job. But then, I wanna mention that the Cultural heritage database in Austria ObjektID (P2951) is just an internal id (we use to identify the object and we use to communicate to the data provider with), but it lacks sufficient persistency and might be subject to change (the data provider plans to reorganize everything, the project alas is on hold by the administration). While we can use it still as an internal key (and have to map to new keys when their database scheme changes), it is my strong opinion that we should not mention it as a descriptive element. For the object mentioned above, Bauernhof in Werfen is ok for the description, but Bauernhof in Werfen (25398) is not. Can you please tell your bot to fix this? regards --Herzi Pinki (talk) 08:31, 25 August 2017 (UTC)

if there is any project page for this import of austrian monument data, feel free to move my concerns there. --Herzi Pinki (talk) 08:34, 25 August 2017 (UTC)

Also @André Costa (WMSE):, you work as a service provider, thanks for that, but for the semantics of data, could you please have an ear on local experts? regards --Herzi Pinki (talk) 22:21, 1 September 2017 (UTC)

Hi @Herzi Pinki:. Wikidata items have a requirement that their label+description is unique. There were some cases in the Austrian dataset where this was not the case. Since a disambiguation then needs to be added to the description the easiest one to use (which is guaranteed to be unique) is the id. It should be possible to rebuild our mechanism so that it is only used for those few cases rather then all of the Austria monuments. When that is done it should be possible to run a smal lbot job to remove the ids from the description in the cases where these are not needed.

We normally try to ping people when the mapping is done and a bot request is put up. Unfortunately it seems I missed adding you to that one for which I'm sorry.

If Cultural heritage database in Austria ObjektID (P2951) is not a persistent identifier you should raise that on the property discussion page as there is nothing there indicating that it is an internal-only identifier. /André Costa (WMSE) (talk) 11:34, 4 September 2017 (UTC)

Hi @André Costa (WMSE):, Sorry, I prefer the correct way to the easy way. Label and description can be changed by anybody, anytime, any language, by bots, humans, etc. In most languages both are not defined and thus cannot be unique. Uniqueness of defined values is enforced, you are right (I did not know, I tried it). Nevertheless label+description is for human readers. What does it help to add the BDA-id to similar objects like Q38011635 & Q38014160, which will not give the human any further hint than without this BDA-id? What is the purpose of this description? Even worse, what is the purpose of descriptions in Q38130973 & Halltal Christophorusmosaik (Q38131080) & Q38131209, all being described by a transient property Denkmalgeschütztes Objekt in Mariazell (<number>), while the existence of the object is a bit independent from its protection status. Protection might be withdrawn, and the object continues to exist, then descriptions like this get nonsense. This is not a petitesse, for about 8000 (about 21 % of all Austrian objects) do have a description like Denkmalgeschütztes Objekt in <municipality> (<number>). To fix all this cannot be left to the crowd. What is the process of not getting it done, but getting it right? regards --Herzi Pinki (talk) 15:58, 4 September 2017 (UTC)

While I agree that "Wohnhaus in Aschach an der Donau (4578)" adds nothing compared to "Wohnhaus in Aschach an der Donau" it definitely adds value compared to " " as the only description. And the only way of adding that info is by also adding a unique disambiguator.

I would also argue that "Denkmalgeschütztes Objekt in Mariazell" is way more valuable than just " " which is the only other available option. Yes there are many items with such generic descriptions but this is a limit in the source data and how much of it could be automatically parsed. If desired (by the Austrian community) we could nuke all such descriptions, but that would still leave the crowd with same manual work with adding descriptions as you have today. The only difference being that in the meantime there are no descriptions. Bot imports are not a magic bullet for eliminating all manual work, only to drastically reduce it. A bot import also does not guarantee that the item will be complete afterwards, like everything else in the Wikimedia universe things are never done but gradually getting better.

To make these discussions more easily findable in the future I suggest moving them to Wikidata_talk:WikiProject_WLM/Mapping_tables/at_(de) does that work for you? /André Costa (WMSE) (talk) 11:42, 6 September 2017 (UTC)

Thanks for moving the discussion. /André Costa (WMSE) (talk) 14:33, 8 September 2017 (UTC)

Municipality got a lot of IDs from bot run

See Zwettl (Q244506) as an example, I suppose the reason is that some article links in the monument database (namely Stadtmauer = city wall, https://tools.wmflabs.org/heritage/api/api.php?action=search&format=json&srcountry=at&srlanguage=de&srid=34132) link to anchors in the article about the municipality itself. This leads to the municipality instance of (P31) cultural property (Q2065736) and rathaus (Q543654). Please check whether my assumptions are correct and how to fix the case, please adopt your algorithm for the bot to handle article links that lead to an anchor in something (at least the municipality). This leads also to some constraint violations. From the structure of monument data in Austria, a municipality / city / whatever administrative unit cannot get the attribute protected and thus cannot get the Cultural heritage database in Austria ObjektID (P2951). @Alicia Fagerving (WMSE), André Costa (WMSE), Thomas Ledl: --Herzi Pinki (talk) 21:10, 13 September 2017 (UTC)

@Alicia Fagerving (WMSE), André Costa (WMSE), Thomas Ledl: any hint? --Herzi Pinki (talk) 01:55, 9 October 2017 (UTC)

• Kaigasse and Krotachgasse (Q1721407)
• @Alicia Fagerving (WMSE), André Costa (WMSE), Thomas Ledl: https://www.wikidata.org/w/index.php?title=Q38062344&type=revision&diff=577570588&oldid=547688262 the object description combines Parish church and cemetery to one object (the cemetery is integral part around the church), the import just reduced it to cemetery only. --Herzi Pinki (talk) 23:40, 14 October 2017 (UTC)

• https://www.wikidata.org/w/index.php?title=Q697537&oldid=548069061 what is the reason for adding instance of (P31) castle (Q23413)?

• Preiner Gscheid Pass (Q1794599) an object cannot be a mountain pass (Q133056) and a wayside shrine (Q3395121) at the same time --Herzi Pinki (talk) 18:12, 15 October 2017 (UTC)

Sorry for the delayed reply. We've adapted the bot algorithms to make it easier to spot incorrect matchings (and to ignore links with link anchors). Sadly this will only help for new imports, not existing ones.

Subsidiary church Saint Nicholas, St. Nikolai (Krems) (Q38062344) Didn't exist before the import so I'm not sure what change you are pointing to here. If there was an item for church+cemetery before then you can link it to the cemetary only item using "has parts"/"is part of".

Tauern Railway Tunnel (Q697537): The addition of burg is due to the same bug as I described before.

{Q|1794599}}: I would guess that this is to blame. This to should be picked up for new imports. For existing ones I would either revert (quick) or split the added information into a new object (better but more work). /André Costa (WMSE) (talk) 09:58, 16 October 2017 (UTC)

@André Costa (WMSE): nevertheless thanks for the answer. Although not quite satisfying. The bot corrupted it, the bot shall fix it. Thank you for setting up the bot and running it, but it does not help to run a bot (assumingly getting even paid for it) and then let the community run behind for nothing (Especially when the non-bot community is of that small size it is on wikidata). I even do not have an idea how to find all similar errors.

• Subsidiary church Saint Nicholas, St. Nikolai (Krems) (Q38062344) I'm pointing to a change I did to make the object correct. It wasn't correct before. If an object is something like Kath. Filialkirche hl. Nikolaus und Friedhof, you cannot degrade it to just Friedhof in Krems in Kärnten (63163) only. So the technical question is how the derivation of Friedhof (cemetery) is done from Filialkirche and Friedhof (church and cemetery) and why there is no derivation primarily of church. instance of (P31) church much more than a cemetery, because the cemetery is just around the church and an integral part of the object. But the object is not a cemetery. And please don't tell me the naming of the data provider is incorrect. Is there a description what the algorithm is to derive the value for instance of (P31)? If I know it, we could avoid pitfalls (e.g. categorization on commons as a church and a cemetery might cause a problem). The object described by our data provider is a church with a cemetery (at least by the naming), but a single object in our lists and the monument database. Not necessarily this is true for Commons (there might be two cats in a hierarchical relationship) nor for WP articles (there might be different articles for the church and the cemetery). And wikidata must cope with this asymmetry. wikidata might prefer some kind of normalization of objects (feels natural), while WP authors tend to combine various aspects in articles and don't care for normalization.
• Preiner Gscheid Pass (Q1794599): Needs splitting in two objects, I agree. The problem is that I read this as I should do it. And again, I did not cause the problem. Nor do I have lists of similar problems.

Your general bot algorithm will ignore links with link anchors (in the future). That is fine. But for the wrong stuff already created, again ... We need some iterative bot for the following reasons:

• Data will be changed by our data provider (this is dynamic content)
• We will change monument entries (link to new articles, change existing ones, correct errors, add / change commonscat, fix locations (we have a non empty set of questionable coordinates))
• The bot algorithm will evolve and improve.

Krdbot and Multichill's Erfgoedbot both do their work incrementally and in iterations. Combination of (single) waterfall by the bot and iteration by the community will not work and data will be there, but useless. Still, the primary source for your data are the publications of our data provider and the created monument lists in the German speaking WP. best --Herzi Pinki (talk) 17:21, 16 October 2017 (UTC)

former monuments

are ignored by Erfgoedbot as well as by the import bot. We in the German WP do not through away monuments that ceased to be protected. We keep them as former monuments. How to cope with this here? As an example Q1333934 where the protection was removed which makes the id dangling. @AleXXw, Multichill: best --Herzi Pinki (talk) 18:09, 21 October 2017 (UTC)

The heritage status generally has a start date, if it's no longer protected, add the end date.

Please don't remove the heritage status or the id. Multichill (talk) 16:32, 22 October 2017 (UTC)

Bot: Address

Donauhof, Innsbruck (Q38114526) original address in the monument lists is "Herzog-Friedrich-Straße 40 / Schlossergasse 1", but only the part after the slash was added as address: "Schlossergasse 1". --Herzi Pinki (talk) 10:39, 22 October 2017 (UTC)