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 <dieterdre...@gmail.com
<mailto:dieterdre...@gmail.com>>:
2015-05-28 23:00 GMT+02:00 Andy Mabbett <a...@pigsonthewing.org.uk
<mailto:a...@pigsonthewing.org.uk>>:
On 28 May 2015 at 09:50, Martin Koppenhoefer
<dieterdre...@gmail.com <mailto:dieterdre...@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@openstreetmap.org <mailto:talk@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
