The main issue has already been outlined in this thread - is such a project, in this case yours - going to stay around long enough and be aligned with OSM enough to be worth the while that OSM contributors divert attention and time away from working on core OSM?
It isn’t as if our contributors don’t see value in things that are peripheral to OSM but would improve the competitiveness relative to google and Apple, it is just that the track record over the the last two decades has been dismal, as in zero successful projects.
@SimonPoole Oh, I totally understand that. FWIW, lib.reviews has been around since 2016. To ensure its longevity, we publish full sanitized database dumps alongside the code. If it seems useful, we’d love to see more folks from the OSM community get involved, but I understand it probably has greatest appeal right now for folks who specifically want the “open reviews” problem to be solved.
What’s the issue with OSM promoting OSM on the OSM wiki (even given that the page in question is actually totally even handed, if not to say undeservedly nice to wikimapia)?
(apologies for continuing offtopic diversion from reviews)
Indeed, I can remember exactly what happens any time anyone mentions Wikimapia in certain OSM concepts
You’re going to have to show your working on that one, I’m afraid! My flippant comment above was because you seemed to be giving them more credit than they currently deserve!
However, that doesn’t mean that the OSM wiki page about it is a “problem” - the “We could probably learn some lessons about simplicity from this” is an entirely reasonable point of view, not without it’s issues (you’ve talked a lot of “the problems with people thinking they can write a simple editor” in the past, and I tend to agree with you on that). It’s a bit like many OSM wiki pages - a bit of an opinion piece; it’s not what I would have written, but it’s not “wrong” for that.
I’m actually unsure whether it’s supposed to be biased against or for Wikimapia! It omits “this site really doesn’t work any more” and “the data in it is very sparse” but arguably far more important is “we can’t copy data too and fro!”.
I think we actually fully agree. I was just concerned that somebody summoning the ghosts of the past would lead to a Wikimapia zombie being taken serious.
PS: yeah yeah, one day too late.
PPS: for the youngsters :-): Wikimapia was -the- crowdsourced competitor to OSM and had a seriously large following, mainly in Eastern Europe. It wasn’t really open data and the owners took a slightly cavalier approach to copyright and googles ToS.
@boramalper Great to see more interest in this space. I am the maintainer of Mangrove Reviews and I think it would be great to consolidate these ideas.
I think there are some misunderstandings about the purpose of the Mangrove Review Standard that I would like to clarify, as I think we can have these new features while maintaining a common standard. The idea behind the standard is to allow for easy inter-operation of different review services, each service can make their own decisions about how moderation, accounts and/or identifier persistence is managed. The standard is also extensible to allow for additional fields.
To cover the concrete points mentioned above:
Moderation: Any new reviews platform can choose to display some or none of the reviews submitted to the Initial Mangrove Reviews server, the platform can manage review whitelisting as it wishes allowing for moderation.
Aggregation: To allow for identifying true quality of reviewed places, Mangrove Reviews server can be extended with an aggregation algorithm which can apply a variety of rules to come up with the final rating. Currently the work was on a PageRank inspired algorithm, but decay can be also implemented. One can also implement custom aggregation algorithms per-platform, so you can apply your custom ranking as you like.
Persistent review subjects: Each Mangrove Review is supposed to reference a specific place at a specific time, which it does given its identifier scheme. This forms the basis upon which one can develop additional linking schemes. There is some art in that, as the same restaurant opening in a new place might have very different characteristics than the old venue. Such subject linking could be applied by your review platform, or we could build an extension to the current server which allows for specifying that two subject identifiers actually refer to the same place.
Any ideas how the scheme could be adapted to better fit the requirements above are welcome, it would be great to avoid fragmentation at least in the data format, even if platforms choose very different ways to set things up.
