so kann man natürlich auch versuchen, Tatsachen zu schaffen, die dann “bestenfalls” von mehreren Usern getragen werden. Wat ne Einstellung zur im Jange befindlichen Diskussion
Wambacher, secondary wikipedia links have been documented in osm wiki since 2013. Are you saying it no longer applies after 5 years? In any case, I do agree it should not be a single person project. I’m just making the queries to highlight the problem, and posting it for discussion. The current system of linking a memorial to the person seems incorrect to me, but my opinion might be wrong. Eventually I do hope we come up with a solution that satisfies most mappers.
wambacher, wikidata is a permanent link to wikipedia. Why should we separate the two? But this is a separate discussion. More importantly, I just updated my original post at the top - see the examples of issues I found. Do you think they should use wikipedia/wikidata links in the present form? Thx
For Wikipedia we’ve tolerated secondary links because they add information in a parseable way. If you have a cathedral which is linked to its Wikipedia entry, then people might have added a link to the architect’s Wikipedia entry separately because it might not be trivial to parse the architect from Wikipedia.
With Wikidata this is different; if the object itself is linked to Wikidata then we don’t need additional wikidata links for architect etc.; the data is useful only in conjunction with Wikidata anyway so why duplicate the internal linking in Wikidata. Look up the object on Wikidata and follow the “architect” link from there if you must.
An object in OSM should only ever have more than one Wikidata link if the object itself is not present on Wikidata. For example,I suspect that not every “Stolperstein” monument will have its own entity on Wikidata, hence it is possible that a “Stolperstein” in OSM could link to the person the monument is for, and the the person who made the monument, on Wikidata.
Nyuriks, you cannot assume that anything valid for Wikipedia is valid for Wikidata as well for the reasons described above. Also, you cannot assume that any decisions made when an average city had 20 Wikipedia links still hold once wiki* links start popping up on every other building.
woodpeck, from your own logic, does it mean that they should be fixed? (see examples in the first post) Currently these Wikipedia links are not about the objects, so they should be secondary, right? Because it seems @wambacher doesn’t agree. I do agree that if wikidata is specifically about the feature, and it already describes who the artist/subject/… of a place is, there is no need to duplicate it in OSM. On the other hand, some people say that OSM should have all possible data and shouldn’t rely on external db. But then this is another problem - in order to rely on what is in wikidata, we must be certain that wikidata is a 1:1 for the feature. As a data consumer, if I see wikidata=Q314003 on a feature, I need to know if I can use the statements of that feature. If wikidata tag describes a class of these objects, or a part of these objects, I need to know not to use its statements.
Some of these features may get their own entries, but other things like individual buildings by various architects might not…or they may, but I’m sure Wikidata won’t have every McDonald’s in the world… I hope. Are you sure its a good idea to use wikipedia tags for the subject of a Stolperstein? I would say that de:Stolpersteine is a better link. It describes what the object is, as oppose to who it’s about.
Woodpeck, my argument about wikipedia/wikidata is slightly different. I might have misunderstood the counter points, and I would love to understand them better. I maintain that wikidata was originally created to link to all languages of an article. The “statements” are an added bonuses that came later. In other words, adding a primary wikidata link is equivalent to wikipedia=Q12345 – a language neutral, rename-proof permanent link to Wikipedia. I have heard of some people complaining that different languages of an article might be slightly different, but I haven’t actually seen any substantial examples of these being a problem.
Hence the conundrum - either we treat wikidata as a permalink to wikipedia – then the rules are more relaxed. Both admin boundary and a village features can point to the same wiki page via the permalink. Or we treat wikidata as a separate value that we can examine automatically, and decide to show multilingual names, brand icons, subject of a memorial, … In that case wikidata must be 1:1 with the feature, and if doesn’t exist, we must use secondary wikidata tags. Or we can adapt “mirror” approach - wikidata is simply a reflection of wikipedia, they always come in pairs, and wikipedia tag must also be 1:1. Which of these should we go with? BTW, if these are good choices, we may want to start a fresh talk discussion presenting these, so that discussion can be better framed and productive.
Ich halte die Links in den von Nyuriks genannten Beispielen für definitiv falsch. Eine Statue sollte keinesfalls im normalen Wikidata-Tag zum Wiki-Eintrag des Künstlers verlinken. Ebensowenig gehört ein Künstler bei einem Theater verlinkt. Das ist in beiden Fällen keine direkte Beziehung und gehört wenn dann in irgendwelche author:wikidata oder was auch immer für Tags, aber nicht in den normalen Wikidata-Tag. Das ist definitiv falsch.
dito, die Links sind für mich Unfug.
Ich kann mir das nur so erklären, dass ein Mapper zum Node/way eine Wikipedia-Fundstelle ergoogelt,
und diesen Artikel unter dem Motto “besser als nichts” verlinkt.
Eine Verlinkung per “wikipedia=” auf derartige “Sammelartikel” ist aber nur in den seltensten Fällen sinnvoll.
Nur das ein Werk in einer Künstler-Werkliste erwähnt wird reicht da nicht aus.
Minimum wäre für mich ein eigener Abschnitt/Absatz, der sich dezidiert mit dem node/way beschäftigt.
(Dass das OSM-Wiki für derartige “Sammelartikel”-Verlinkungen ein eigens Tagging “wikipedia:[Sprachversion]=[Sammelartikel]” vorsieht,
JOSM seit kurzem genau dieses Tagging aber anmeckert gehört wohl zu den OSM-Kuriositäten, deren Diskussion jetzt und hier wahrscheinlich zu weit führt.)