<p dir="ltr">Hi Erik,</p>
<p dir="ltr">Interesting project, though I must admit some caution about its success. How do you plan to develop readership for this site? Yelp seems to have a commanding lead.</p>
<p dir="ltr">Pine</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Aug 5, 2016 18:17, "Erik Moeller" <<a href="mailto:eloquence@gmail.com">eloquence@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Michał,<br>
<br>
Thanks for your comments!<br>
<br>
On Fri, Aug 5, 2016 at 4:55 PM, Michał Brzozowski <<a href="mailto:www.haxor@gmail.com">www.haxor@gmail.com</a>> wrote:<br>
<br>
> Have you devised any robust algorithm for linking OSM primitives to<br>
> objects in the external database? In general case, it seems really<br>
> hard to track objects as they get converted from nodes to areas, or<br>
> decide whether given OSM feature is no longer representing some entity<br>
> in the external database.<br>
<br>
No, and I'm not very familiar with OSM's data structures and APIs yet.<br>
What I'm imagining for now as the initial OSM-related features are:<br>
<br>
1) enabling search for POIs similar to <a href="http://openpoimap.org/" rel="noreferrer" target="_blank">http://openpoimap.org/</a> but more<br>
lightweight and purpose-focused (so you can start a review and just<br>
select a POI from the map to identify it)<br>
<br>
2) importing (and attributing!) relevant data on demand, which by the<br>
looks of e.g. <a href="https://www.openstreetmap.org/way/422293736" rel="noreferrer" target="_blank">https://www.openstreetmap.org/<wbr>way/422293736</a> seems like<br>
it often includes quite a bit of relevant data that future reviewers<br>
would appreciate.<br>
<br>
If possible, I'd also like to add:<br>
<br>
3) flagging imported data as read-only and synchronizing it in regular<br>
intervals. People who want to improve that data would then just be<br>
pointed to OSM (or Wikidata, or whatever community source).<br>
<br>
I have no intention of performing a bulk import anytime soon; while<br>
this could be good for bootstrapping, it will be too big of a<br>
technical challenge too early, I think. Instead for now we'll<br>
add/import metadata about things we review if/when we review them.<br>
<br>
Do you see fundamental technical challenges with any of the above? I<br>
don't think conversion from nodes to areas would necessarily be<br>
problematic, as long as the sync job can learn that such a change has<br>
occurred to the object it's trying to keep in sync.<br>
<br>
> A framework / API for performing such linking would be of great<br>
> interest, as it could enable many applications to exist on top of OSM<br>
> - recognizing that not everything belongs to OSM.<br>
<br>
*nod* OSM-land is interesting compared with the Wikimedia world I'm<br>
more familiar with, with much more emphasis on a large distributed<br>
community building tools and APIs, some proprietary, some open. I'll<br>
want to look at the state of the open tools out there to see if what<br>
I'm describing above can already be built, or if there's someone who's<br>
willing to collaborate!<br>
<br>
> Regarding the idea, I reckon it may not scale well, if at all. Weeding<br>
> out spammers needs constant attention, and community moderation is<br>
> prone to the Sybil attacks. This may be less of a problem on sites<br>
> such as OSM or Wikipedia where data needs verifiability that or<br>
> another way (so in order to gain trust you have to do actual work).<br>
> Reviews are inherently subjective. Not to mention any legal BS one may<br>
> get from business owners.<br>
<br>
Heh, it's certainly a hard problem. :) Here are a few things to note:<br>
<br>
- Currently the system is invite-only and likely will be for a while.<br>
I reckon building a core community that cares about quality,<br>
organization, etc. will take a while, and we can then give a lot of<br>
those folks permission to also act as moderators so they can ban<br>
spammers once we (temporarily or permanently) open the floodgates.<br>
Invitation is something we can give away liberally, but it functions<br>
as a bit of a barrier to entry for bad faith actors.<br>
<br>
- I'm building into the architecture strong notions of trust and<br>
affiliation. Users can be members of like-minded teams with given<br>
rules (think sub-reddit as an analogy), and they can individually<br>
express trust toward one another, so we can track the trust graph that<br>
allowed an abuser to act with elevated trust levels. Trust will likely<br>
factor into ranking calculations, visibility of content, and so on. To<br>
give an example, it's already the case that the reviews shown on<br>
<a href="https://lib.reviews/" rel="noreferrer" target="_blank">https://lib.reviews/</a> are written by users with the "trusted" flag set,<br>
while <a href="https://lib.reviews/feed" rel="noreferrer" target="_blank">https://lib.reviews/feed</a> shows all (unfiltered) reviews.<br>
<br>
- In general, my experience with Wikimedia has taught me that<br>
transparent community collaboration in good faith is a pretty good way<br>
to deal with such problems. Wikimedia has to deal with paid PR flacks<br>
regularly, for example, and generally has established procedures for<br>
spotting and kicking out such folks. Similarly, WMF has had to face<br>
down nasty legal threats long before it had a big budget. As long as I<br>
give the community good tools to self-organize rather than following<br>
an enterprise-style approach of solving everything from the top down,<br>
I am optimistic that we can make decisions such as "when do we open<br>
the floodgates" collaboratively.)<br>
<br>
Warmly,<br>
Erik<br>
<br>
______________________________<wbr>_________________<br>
talk mailing list<br>
<a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk</a><br>
</blockquote></div></div>