[OSM-talk] Fixing wiki* -> brand:wiki*

Lester Caine lester at lsces.co.uk
Wed Sep 27 20:39:23 UTC 2017

On 27/09/17 20:56, Yuri Astrakhan wrote:
>     That formed no part of the early discussions on how wikidata should
>     work? I bowed out when the discussions were going down a path I did not
>     find to be at all useful. The current offering is certainly a lot more
>     'organised' than those original discussions.
> Getting the initial points across is always a process. Hard to get it
> right from the start :)  I hope we can progress in a more organized and
> beneficial way.

I've been working with data involving addresses and other material for
over 25 years using relation databases, and I don't find many of the
'modern' approaches add anything to managing that data.

>     I WOULD still like to see a
>     storage model that allows third party lists to be managed and cross
>     referenced, but that does not fit the wikidata model. It is why I think
>     'another' cross-reference tool may be more appropriate with OSM and
>     wikipedia/wikidata simply being sources.
> I am not exactly sure what you mean here. What goals do you have in mind
> that cannot be stored with the current system?

I'm not sure that every third party source will want their data included
in either OSM or wikidata. I have a large volume of data that I can't
provide access to. I can currently access OSM via coordinates, but I
would like to tie every National Street Gazetteer entry to the matching
objects in OSM. wikidata should probably have an entry for every street
in the UK, but since the NSG data is not currently public domain using
this source is not CURRENTLY possible. Other data sources are linked
using NSG references so mapping those to OSM objects allows that data to
be used where it's licence does allow. Other countries have this same
mix of open data and private stuff which is nowadays a manageable
minefield from which the public domain content can be accessed.

>     THAT requires OSM to have a
>     'unique id' one can use to cross reference though :(
>  If a third party list has a list of OSM objects, any time a new object
> is added or existing one is changed, that 3rd party list needs to be
> updated.  Generally you don't want that. Also, it would require a
> substantial fundamental change to OSM data structure and social dynamics
> - the "ID" would have to be placed above all else, like it is done in
> Wikidata.  The ID meaning should never change, and merging two IDs
> should leave a redirect from one to the other.  I doubt that can be
> easily achievable. 

The whole point here is that any change should be easy to pick up. If a
new bus stop is added to that database, a bot monitoring this will pick
up the change and make the change available to other users. Similarly
when a record is updated, and changes that affect the monitoring bot's
target can be flagged. More and more sources are being made open access
and using suitable data to improve OSM's quality should be something
that is easy to manage.

YES the current OSM data structure has a problem when adding this layer
of management. A database like wikidata might be an option to provide
higher level lists of objects, which can then be linked to bot's which
manage primary data such as the NSG's update reports adding new streets
and changes to location hierarchy. But I should prefer that this layer
is part of OSM rather than a third party service.

Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

More information about the talk mailing list