[OSM-talk] Can wikidata links help fight name inflation?
Arch Arch
7h3.arch at gmail.com
Fri May 29 09:45:56 UTC 2015
I don't think that's a good idea to try to solve the problems we're
faced with by our current OSM data model by setting up a second
database. We need an improved data model which fits our needs.
Am 29.05.2015 um 11:28 schrieb Jo:
> We need our own OSMdata instance in between to describe real world
> objects and concepts. And maybe we could even solve the ridiculous
> amount of duplication we're experiencing at the moment.
>
> True, the editor software will have to be adapted to cope with merges
> and splits, so the human editor can decide what OSM object(s) belong
> to what real world object(s).
>
> Either that or we should start using relations more intelligently. But
> they are heavyweight and supposedly they are also "complicated".
>
> Polyglot
>
> 2015-05-29 10:58 GMT+02:00 Martin Koppenhoefer <dieterdreist at gmail.com
> <mailto:dieterdreist at gmail.com>>:
>
>
> 2015-05-28 23:00 GMT+02:00 Andy Mabbett <andy at pigsonthewing.org.uk
> <mailto:andy at pigsonthewing.org.uk>>:
>
> On 28 May 2015 at 09:50, Martin Koppenhoefer
> <dieterdreist at gmail.com <mailto:dieterdreist at gmail.com>> wrote:
>
> > e.g. the "en:Spanish Steps" / "de:Spanische Treppe" are
> > called "Scalinata di Trinità dei Monti" in the local
> language (it is located
> > at "piazza di Spagna", that's where the foreign name comes
> from, while in
> > Italian it is called after to church it leads to).
> Naturally, OSM has the
> > original name of this world famous monument, but Wikidata
> hasn't.
>
> It does now.
>
>
>
> OK, this is one point for you, but it also proves my point:
> wikidata at the moment is not sufficiently mature (IMHO) to
> replace name tags in different languages in OSM. Of course you can
> fix wikidata issues (if you understand how it is done, I haven't
> had enough time yet to understand how to make edits like this, and
> the fact that not all tags are shown to me (e.g. only 4 out of all
> language labels, after I have explicitly clicked on "in more
> languages")) doesn't help.
>
> // sidenote:
>
> Now I could link the wikidata object of the spanish steps to the
> OSM object and get an Italian name. But I will not have an Italian
> wikipedia article about it, because it is covered in the spanish
> square (piazza di spagna) article in Italian. How would I ideally
> procede now?
>
> a) in wikidata link the article of the piazza di spagna (in
> italian) to the wikidata object about the spanish steps?
>
> a2) like a) but link to an anchor: Piazza_di_Spagna#La_scalinata ?
>
> b) in wikipedia split the italian wikipedia article in 2, one for
> the square and one for the steps?
>
> c) in osm add an additional tag like
> wikipedia:it=Piazza_di_Spagna#La_scalinata to the steps object?
>
> d) something different...
>
> //sidenote off
>
>
> > If we were to massively use wikidata _instead of duplicating
> some details
> > from there also in our db_ we would have to improve wikidata
> as well,
>
> You'd be welcome to do so. ...
>
>
> > and impose our entity structure on them,
>
> Really? Good luck with that.
>
>
>
> what I meant, and what you do confirm below: if for instance there
> is an object in wikidata which is an administrative entity and a
> geographic place at the same time, but for OSM we'd need 2
> distinct objects, we will have to split the wikidata object. This
> could be done only if there wasn't resistance from other wikidata
> users who might want to keep the current unmodified object because
> it links better to wikipedia articles. We might introduce another
> object that linked the split objects onto one, which could serve
> for wikipedia articles, etc. but this is a much more complicated
> procedure than changing tags in OSM alone.
>
> We've always said that we wanted editing to be simple, so that we
> can maximize the amount of available editors, but with the tight
> integration of another dynamic dataset (for one of the core
> competences we are dealing with: toponyms)
>
>
>
> > or it won't work in some cases (and if it doesn't work in
> some case, it doesn't work at all).
>
> That is, of course, nonsense.
>
>
>
> OK, let's say it is nonesense, because you can accept that a
> solution works for most of the cases and try work around those
> that don't work. Currently (all names in OSM) we don't have these
> problems though.
>
>
> > Another issue I see with wikidata is that it contains
> information and
> > details about spatial objects, but it doesn't contain the
> geometry it refers
> > to.
>
> The geometry is in OSM, is it not? Why would Wikidata want to
> replicate that?
>
>
>
> IMHO you have to understand to which geometry you are referring
> when you make edits, or you might break stuff without noticing it.
> Wikidata editors would have to look at OSM geometries to ensure
> that their edit maintains consistency, and OSM users would have to
> check wikidata to see if editing something in a certain way (e.g.
> merges or splits, adding tags, changing geometry) is OK or whether
> they have to split the wikidata object and update the wikidata
> link. It is not impossible, but it is an enormous amount of
> complexity added, and it also augments the risk of
> non-availability of the backend by 100% (because now we depend on
> 2 services and not on one).
>
>
> I want
>
> > to point out is that there seem to be different criteria
> defined for
> > different languages:
>
> These descriptions aid users; they are not proscriptive. There are
> also local and cultural variations. Just like "city" in OSM.
>
>
>
> Maybe these are descriptions to aid in some regional wiki projects
> and proscriptive rules in others like Germany, where rules rule?
> Just like in OSM ;-)
> It would rather confuse than aid me if the descriptions in some
> language says something is foo and in another language they tell
> me it is not foo.
>
>
>
>
> TL;DR; wikidata is a gorgeous project, combining their knowledge
> with ours is very promising. Still, in my opinion, for the current
> state of where they are (and where the tools to combine both are),
> I would _not remove tags_ from OSM just because the same
> information might be available in wikidata.
>
> Cheers,
> Martin
>
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org <mailto:talk at openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk
>
>
>
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20150529/ecfa9739/attachment.html>
More information about the talk
mailing list