<div dir="ltr">On Wed, 11 Sep 2019 at 22:26, Janko Mihelić <<a href="mailto:janjko@gmail.com">janjko@gmail.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">sri, 11. ruj 2019. u 20:24 Mateusz Konieczny <<a href="mailto:matkoniecz@tutanota.com" target="_blank">matkoniecz@tutanota.com</a>> napisao je:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
<div>can you give specific example of case<br></div><div>where part:wikidata would be better<br></div><div>than wikidata?</div></div></blockquote><div><br></div><div>The classic example is a street. Streets are one of those objects in OSM which are defined by a unique name on several ways. So if a wikidata item is about a street, all ways get the same part:wikidata=*</div></div></div></blockquote><div><br></div><div>In this case, I'm not convinced that we couldn't accept a many-to-one mapping of ways to</div><div>wikidata.  But if you insist, put them in a relation of some kind.  Maybe a type=wikidata, even,</div><div>although I suspect that would have more problems than benefits.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>
<div>Art or memorial installations like Stolperstein[1], which are distributed, but have one wikidata item. It's hard to imagine every Stolperstein will get its own article. And a relation with all these nodes makes no sense.<br></div></div></div></blockquote><div><br></div><div>If a relation makes no sense, a wikidata item shared by them probably doesn't, either.  I'll just</div><div>go and look at wikidata for stolperstein...  It's not identified as a category, but it clearly is one.  It's</div><div>a sub-class of commemorative plaque.  It makes no more sense to apply <span class="gmail-wikibase-title"><span class="gmail-wikibase-title-id">Q26703203 to every</span></span></div><div><span class="gmail-wikibase-title"><span class="gmail-wikibase-title-id">stolperstein than it does to apply Q532 to every village.  Don't force round pegs into square<br></span></span></div><div><span class="gmail-wikibase-title"><span class="gmail-wikibase-title-id">holes and don't whittle down trees into round pegs so you can force the resulting round peg</span></span></div><div><span class="gmail-wikibase-title"><span class="gmail-wikibase-title-id"> into a square hole.</span></span></div><div><span class="gmail-wikibase-title"><span class="gmail-wikibase-title-id"><br></span></span></div><div><span class="gmail-wikibase-title"><span class="gmail-wikibase-title-id">If you have a wikidata item for a specific, unique stolperstein then you can tag it, if you wish.</span></span></div><div><span class="gmail-wikibase-title"><span class="gmail-wikibase-title-id">But adding Q26703203 to every stolperstein doesn't help anyone.  A data consumer using</span></span></div><div><span class="gmail-wikibase-title"><span class="gmail-wikibase-title-id">the query tool of standard carto to find out what the symbol is of gets a list of tags, amongst</span></span></div><div><span class="gmail-wikibase-title"><span class="gmail-wikibase-title-id">them being memorial=stoperstein, and stolperstein is a link to the OSM wiki documentation,</span></span></div><div><span class="gmail-wikibase-title"><span class="gmail-wikibase-title-id">the OSM wiki documentation has links to the wikipedia article and the wikidata item.  Adding</span></span></div><div><span class="gmail-wikibase-title"><span class="gmail-wikibase-title-id">a generic stolperstein wikidata item to all stolpersteine is redundant and unhelpful.</span></span></div><div><span class="gmail-wikibase-title"><span class="gmail-wikibase-title-id"><br></span></span></div><div><span class="gmail-wikibase-title"><span class="gmail-wikibase-title-id">Not only that, what happens when a stolperstein with the generic Q26703203 gets its own</span></span></div><div><span class="gmail-wikibase-title"><span class="gmail-wikibase-title-id"> wikidata item?  Semi-colon list, causing problems for some consumers?  Delete the</span></span></div><div><span class="gmail-wikibase-title"><span class="gmail-wikibase-title-id">part:wikidata=Q26703203 and add a wikidata=*, thus confounding anyone thinking an</span></span></div><div><span class="gmail-wikibase-title"><span class="gmail-wikibase-title-id"> overpass query for part:wikidata=Q26703203 will find ALL stolpersteine?  You are putting</span></span></div><div><span class="gmail-wikibase-title"><span class="gmail-wikibase-title-id">stumbling stones in everyone's path here [pun intended].<br></span></span></div><div><span class="gmail-wikibase-title"><span class="gmail-wikibase-title-id"><br></span></span></div><div><span class="gmail-wikibase-title"><span class="gmail-wikibase-title-id">OSM and Wikidata have different worldviews.  Don't insist on fitting wikidata items to every</span></span></div><div><span class="gmail-wikibase-title"><span class="gmail-wikibase-title-id">object in OSM.  Accept that sometimes our views of the world diverge so much that there's</span></span></div><div><span class="gmail-wikibase-title"><span class="gmail-wikibase-title-id">no straightforward relationship between one and the other.<br></span></span></div><div><span class="gmail-wikibase-title"><span class="gmail-wikibase-title-id"><br></span></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>And then it could be used when the mapper isn't sure how to map a wikidata item, so she just tags all the parts with part:wikdiata=*. Then someone more experienced shows up, and creates a valid relation, and sums up all those parts into one wikidata=* (and deletes the part:wikidata=* tags).</div></div></blockquote><div><br></div><div>So what you want is synonymous with "fixme."  But more complicated and requiring more work.</div><div>I'm not convinced this is a good idea.<br></div><div><br></div><div>-- <br></div><div>Paul</div><div><br></div></div></div>