subject:"\[OSM\-talk\] OSM relation ID property in Wikidata"

Hi.

Do you have any idea how this permanent ID could look like?
You dislike the overpass-approach (and yes, it's far from perfect).
What is your idea how a stable permanent ID to an object may be achieved?

Let's use a shop as an example (and wikidata as the foreign database as
an example, too).

1st stage: it's not mapped at all - okay, nothing to link to.
2nd stage: someone maps a shop - and only that shop, without name or
anything like that. Wikidata could of course link to the osm id, even if
it only contains a coordinate and shop=supermarket, but if they want
to do that, they have more information they could add to osm easily,
like name and usually at least parts of the address.
3rd stage: someone (e.g. the wikidata people) adds these details - the
overpass-api get's slightly more stable (I know, not completely stable
of course).
4th stage: someone replaces the node by a polygon mapping the
supermarkets building as a whole. Now the osm id has changed, so your
approach to use that as a link key fails here.
5th stage: someone refines that polygon to include the hole in the
middle, so it get's a multipolygon relation. again the internal osm id
changes, the overpass-api (when designed usefully) is kept.

6th stage: the name of the shop changes (small change due to corporates
decision, nothing really useful): The osm id is stable here, overpass is
likely to fail now (but knows about this failure as it's possible to
acknowledge the dead link).

7th stage: the shop moves to another address, therefore the tags are
moved to another building, let's say, 3 streets away. The OSM id looks
like it's still stable, but links to the wrong object. The overpass-id
is either still valid or is automatically known to be a dead link.

I agree, that the overpass-api isn't perfect and it's still possible to
produce links that are either (or may get) ambiguous or that may break
due to any edit in future. But the internal OSM ID has even more
drawbacks: while the overpass-permanent-id includes semantics for the
link, the osm id is a pure technical link.

I'm keen to get a better idea how that could be achieved, or why you
really think that the osm id is really better than overpass with respect
to stability and maintainability.

regards
Peter

Am 07.05.2013 00:31, schrieb Stefan Keller:
 Hi,
 
 I also think that linking from an OSM object to a growing no. of
 external databases (incl. Wikipedia/Wikidata) is not a good idea. And
 I respect the wish of the OSM maintainers to change the OSM id in the
 future. But the overpass-permanent-osm-id is no solution neither,
 primo because a set of key-values is a clumsy id, and secondo because
 there exist many OSM objects which have no identifying tags (or none
 at all).
 
 As this issue pops up from in increasingly frequent intervals I think
 it's time to think about a good mid term solution (short term is
 sticking to the OSM id).
 
 I'm proposing a solution alongside one of the following two directions:
 * either to implement a Linked Data API/service which maps from
 permanent ids to OSM objects (and which is what I like about overpass
 - being a service) -
 * or to add a permanent id as an additional XML tag to every OSM
 object! And if somebody thinks that's a waste of space we can easily
 drop the XML tag user which is completely redundant to uid (which
 in turn needs another simple API to find out the current users display
 name).
 
 Yours, Stefan
 
 
 
 2013/5/6 Peter Wendorff wendo...@uni-paderborn.de:
 Am 06.05.2013 23:07, schrieb andrzej zaborowski:
 Hi,

 On 6 May 2013 21:20, Peter Wendorff wendo...@uni-paderborn.de wrote:
 Am 06.05.2013 20:26, schrieb Tobias Knerr:
 On 06.05.2013 18:54, Peter Wendorff wrote:

 [...]
 Let's see this example: A building that was a merchants kontor a few
 hundret years ago, and now contains a museum and a restaurant, while in
 between it was - let's say - a hospital).

 That's historical mapping. The problems would be the same for e.g. the
 name. But as for the parts of the example that are not directly 
 historic:

 No, it's not. I did not speak about mapping the hospital and the
 merchants kontor, but about wikidata entries ahout the hospital and the
 merchants kontor - and wikidata in fact includes historical entities
 like that, too.

 If you're not adding those historical entities to OSM (or a similar
 database like that historical osm once discussed) then there's no
 issue with linking to Wikidata because there's nothing to be linked.

 Why not?
 The building is the same, and it's not of interest, that the tag
 amenity=museum is not (any more) existent in osm.

 If that's an argument any wikidata entity that's not tagged as complete
 as the wikidata entity itself would be nothing to be linked.

 Your cross-reference (only add a reference osm pointing to wikidata to
 the building, but link all other entities of wikidata to the building)
 argument may be valid, but it's complex (that's my question below); but
 especially historical

Re: [OSM-talk] OSM relation ID property in Wikidata

Am 07.05.2013 00:47, schrieb Tobias Knerr:
 Am 06.05.2013 23:55, schrieb Peter Wendorff:
 Am 06.05.2013 23:07, schrieb andrzej zaborowski:
 If you're not adding those historical entities to OSM (or a similar
 database like that historical osm once discussed) then there's no
 issue with linking to Wikidata because there's nothing to be linked.

 Why not?
 
 It wouldn't add any information. The hospital should be linked to the
 building _within_ Wikidata anyway because there are more properties that
 can be attached to a building than just a OSM building outline.
 
 So if we connect the OSM building and the Wikidata building, then the
 hospital is already (though Wikidata) linked to the OSM building, too.
 
 If it doesn't occupy the entire building then you can probably add the
 museum tag on the building geometry but later once you want to add a
 wikidata tag you'd probably split it out like you'd split a street
 object when you want to add an attribute that applies to a part of the
 attribute.  If you're into indoor mapping then you'd draw the museum
 outline separately anyway.
 so you propose to split it up because of an external ID you propose to
 add...
 While I in general agree that objects of osm are split when they get
 mapped in more detail (like in this example), I'm not happy to do that
 for the reason to enable matching to external references.
 
 Using the same OSM element for two distinct features actually
 contradicts a strict one feature, one OSM element principle. We do it
 anyway because it's convenient, but as soon as you want to add the same
 tag - whether it's name, opening_hours, or wikidata - to both features,
 you create two separate elements.
 
 That's not a special treatment of external IDs, but consistent with
 other tags, and using two separate elements is semantically better anyway.

I agree from a theoretical point of view. But your failing assumption
here is, that wikidata only would link to perfectly fine mapped stuff.

If you would add that link to wikidata, you probably would divide it to
several osm objects before. But is that realistic to assume, that the
wikidata folks will do that, too?
This would require wikidata people to entirely know the osm model, how
to edit and what might be the drawback of combining features in one object.
And keep in mind it's not clear in every case what to separate and what
not.

regards
Peter

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

Hi,

All use cases you describe are valid. It's up to the users of OSM
permanent id to keep track of changing OSM ids - it's an offer of OSM.
The only constraint I would propose is to avoid to delete and recreate
a new id only because of a tool (like an editor) likes to do it like
this.

The concept of permanent, unique and never-reused object ids is a
well-known property in the Object-Oriented and Linked Data technology.

As I said: The killer criteria not to use overpass-approach is that
there exist many OSM objects which have too few or no tags at all. And
using coordinates as identifiers is no solution neither because it's a
float number with different precision and implementation dependent. OO
overcame exactly this restriction of the relational paradigm (which
identified a tupel by the set of it's values).

Responsible for the unique generation of a permanent id is finally the
OSM server instance(s). In case the OSM servers are distributed a
distributed id scheme is applied as in NoSQL databases and here [1].

Yours, Stefan

[1] http://www.interlis.ch/oid/oid_e.php


2013/5/7 Peter Wendorff wendo...@uni-paderborn.de:
 Hi.

 Do you have any idea how this permanent ID could look like?
 You dislike the overpass-approach (and yes, it's far from perfect).
 What is your idea how a stable permanent ID to an object may be achieved?

 Let's use a shop as an example (and wikidata as the foreign database as
 an example, too).

 1st stage: it's not mapped at all - okay, nothing to link to.
 2nd stage: someone maps a shop - and only that shop, without name or
 anything like that. Wikidata could of course link to the osm id, even if
 it only contains a coordinate and shop=supermarket, but if they want
 to do that, they have more information they could add to osm easily,
 like name and usually at least parts of the address.
 3rd stage: someone (e.g. the wikidata people) adds these details - the
 overpass-api get's slightly more stable (I know, not completely stable
 of course).
 4th stage: someone replaces the node by a polygon mapping the
 supermarkets building as a whole. Now the osm id has changed, so your
 approach to use that as a link key fails here.
 5th stage: someone refines that polygon to include the hole in the
 middle, so it get's a multipolygon relation. again the internal osm id
 changes, the overpass-api (when designed usefully) is kept.

 6th stage: the name of the shop changes (small change due to corporates
 decision, nothing really useful): The osm id is stable here, overpass is
 likely to fail now (but knows about this failure as it's possible to
 acknowledge the dead link).

 7th stage: the shop moves to another address, therefore the tags are
 moved to another building, let's say, 3 streets away. The OSM id looks
 like it's still stable, but links to the wrong object. The overpass-id
 is either still valid or is automatically known to be a dead link.

 I agree, that the overpass-api isn't perfect and it's still possible to
 produce links that are either (or may get) ambiguous or that may break
 due to any edit in future. But the internal OSM ID has even more
 drawbacks: while the overpass-permanent-id includes semantics for the
 link, the osm id is a pure technical link.

 I'm keen to get a better idea how that could be achieved, or why you
 really think that the osm id is really better than overpass with respect
 to stability and maintainability.

 regards
 Peter

 Am 07.05.2013 00:31, schrieb Stefan Keller:
 Hi,

 I also think that linking from an OSM object to a growing no. of
 external databases (incl. Wikipedia/Wikidata) is not a good idea. And
 I respect the wish of the OSM maintainers to change the OSM id in the
 future. But the overpass-permanent-osm-id is no solution neither,
 primo because a set of key-values is a clumsy id, and secondo because
 there exist many OSM objects which have no identifying tags (or none
 at all).

 As this issue pops up from in increasingly frequent intervals I think
 it's time to think about a good mid term solution (short term is
 sticking to the OSM id).

 I'm proposing a solution alongside one of the following two directions:
 * either to implement a Linked Data API/service which maps from
 permanent ids to OSM objects (and which is what I like about overpass
 - being a service) -
 * or to add a permanent id as an additional XML tag to every OSM
 object! And if somebody thinks that's a waste of space we can easily
 drop the XML tag user which is completely redundant to uid (which
 in turn needs another simple API to find out the current users display
 name).

 Yours, Stefan



 2013/5/6 Peter Wendorff wendo...@uni-paderborn.de:
 Am 06.05.2013 23:07, schrieb andrzej zaborowski:
 Hi,

 On 6 May 2013 21:20, Peter Wendorff wendo...@uni-paderborn.de wrote:
 Am 06.05.2013 20:26, schrieb Tobias Knerr:
 On 06.05.2013 18:54, Peter Wendorff wrote:

 [...]
 Let's see this example: A building that was a merchants kontor a few
 hundret years ago, and now contains a

Re: [OSM-talk] OSM relation ID property in Wikidata

Am 07.05.2013 09:43, schrieb Stefan Keller:
 Hi,
 
 All use cases you describe are valid. It's up to the users of OSM
 permanent id to keep track of changing OSM ids - it's an offer of OSM.
 The only constraint I would propose is to avoid to delete and recreate
 a new id only because of a tool (like an editor) likes to do it like
 this.
 
 The concept of permanent, unique and never-reused object ids is a
 well-known property in the Object-Oriented and Linked Data technology.
 
 As I said: The killer criteria not to use overpass-approach is that
 there exist many OSM objects which have too few or no tags at all. And
 using coordinates as identifiers is no solution neither because it's a
 float number with different precision and implementation dependent. OO
 overcame exactly this restriction of the relational paradigm (which
 identified a tupel by the set of it's values).

But even then overpass is slightly better:
Let's say I only know I want to link a given supermarket.
Let's say that supermarket is not tagged in more detail then
shop=supermarket.
Linking to node 123 would break soon when that get's a polygon (not to
mention mappers who don't know or care about theory of data management
and reuse that node directly to map a waste_basket instead of creating a
new object).
Best case here would be a mapper that includes that node as one of the
nodes building the polygon - but who knows?

Overpass in contrast could add information about:
- we want to link a supermarket
- it's roughly in that bounding box (e.g. the city or a given part of
the city)

Of course this can break, too - but it's more stable than the ID alone,
even without any tag at all.

regards
Peter


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-07 Thread Christian Quest

Linking to OSM objet ID looks like a bad idea because they are not stable.

We had a recent long talk on talk-fr@ about permanent IDs that could
help linking external data to OSM, instead of multiplying ref:xxx in
OSM to link to external data.

I've proposed something that can be summarized like some generic
geoURL that could be used to describe something/somewhere in the form
something@somewhere

'something' could use some hierarchical semantic description, and
'somewhere' could use for example geohash.

Example for a bakery nearby my place: saines_saveurs.bakery.shop@u09v8s9fd5mc

These geoURL can be compared with some level of fuzzyness on something
and/or somewhere by reducing the level of details if necessary
(exemple: shop@u09v8s9fd5 has less details and can be matched with a
simple contain text search).

They can be translated into whatever query like an overpass-api query
to actually resolve to the current matching objets in OSM or somewhere
else as the geoURL are not OSM based in any way.

This mechanism works pretty well for node/polygon based POI, but needs
to be extended for more linear features (like a street), maybe using
more than one geohash (one at both ends ?).

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

Hi,

You wrote:
 - it's roughly in that bounding box (e.g. the city or a given part of

A soon as you use the word roughly - the id approach is doomed to fail.
According to OO and database technology an id is a well-defined
surrogate with a well-defined data type.

Yours, Stefan


2013/5/7 Peter Wendorff wendo...@uni-paderborn.de:
 Am 07.05.2013 09:43, schrieb Stefan Keller:
 Hi,

 All use cases you describe are valid. It's up to the users of OSM
 permanent id to keep track of changing OSM ids - it's an offer of OSM.
 The only constraint I would propose is to avoid to delete and recreate
 a new id only because of a tool (like an editor) likes to do it like
 this.

 The concept of permanent, unique and never-reused object ids is a
 well-known property in the Object-Oriented and Linked Data technology.

 As I said: The killer criteria not to use overpass-approach is that
 there exist many OSM objects which have too few or no tags at all. And
 using coordinates as identifiers is no solution neither because it's a
 float number with different precision and implementation dependent. OO
 overcame exactly this restriction of the relational paradigm (which
 identified a tupel by the set of it's values).

 But even then overpass is slightly better:
 Let's say I only know I want to link a given supermarket.
 Let's say that supermarket is not tagged in more detail then
 shop=supermarket.
 Linking to node 123 would break soon when that get's a polygon (not to
 mention mappers who don't know or care about theory of data management
 and reuse that node directly to map a waste_basket instead of creating a
 new object).
 Best case here would be a mapper that includes that node as one of the
 nodes building the polygon - but who knows?

 Overpass in contrast could add information about:
 - we want to link a supermarket
 - it's roughly in that bounding box (e.g. the city or a given part of
 the city)

 Of course this can break, too - but it's more stable than the ID alone,
 even without any tag at all.

 regards
 Peter


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

Am 07.05.2013 09:58, schrieb Stefan Keller:
 Hi,
 
 You wrote:
 - it's roughly in that bounding box (e.g. the city or a given part of
 
 A soon as you use the word roughly - the id approach is doomed to fail.
 According to OO and database technology an id is a well-defined
 surrogate with a well-defined data type.

Then it's not the same permanent we talk about.
Look what happens in OSM all the time: POIs are moved slightly to match
aerial images - following your definition that should be another ID now
- but that's not what people usually want if they request for a
permanent ID, similar to changes from node to polygon to multipolyogn etc.

It's in that bounding box nevertheless would have been the better
wording, (equalling is roughly at that position, so if you want to use
roughly/estimation, it's possible even then).

regards
Peter

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013/5/7 Christian Quest cqu...@openstreetmap.fr:
 Linking to OSM objet ID looks like a bad idea because they are not stable.

Agreed.

 I've proposed something that can be summarized like some generic
 geoURL that could be used to describe something/somewhere in the form
 something@somewhere

Am I understanding you correctly: You propose a kind of geoURL - like
linked data [1] - which is a tag attached to OSM nodes?
That would fulfill most of my criterias except that it does not
indicate that it's a system property
GeoHashes have a nice property of being completely independent of a
centralized (or partially centralized) id generator.
But they are not suited to identify object which are overlaying each other.

Yours, Stefan

[1]  http://semanticweb.org/wiki/GeoURL

2013/5/7 Christian Quest cqu...@openstreetmap.fr:
 Linking to OSM objet ID looks like a bad idea because they are not stable.

 We had a recent long talk on talk-fr@ about permanent IDs that could
 help linking external data to OSM, instead of multiplying ref:xxx in
 OSM to link to external data.

 I've proposed something that can be summarized like some generic
 geoURL that could be used to describe something/somewhere in the form
 something@somewhere

 'something' could use some hierarchical semantic description, and
 'somewhere' could use for example geohash.

 Example for a bakery nearby my place: saines_saveurs.bakery.shop@u09v8s9fd5mc

 These geoURL can be compared with some level of fuzzyness on something
 and/or somewhere by reducing the level of details if necessary
 (exemple: shop@u09v8s9fd5 has less details and can be matched with a
 simple contain text search).

 They can be translated into whatever query like an overpass-api query
 to actually resolve to the current matching objets in OSM or somewhere
 else as the geoURL are not OSM based in any way.

 This mechanism works pretty well for node/polygon based POI, but needs
 to be extended for more linear features (like a street), maybe using
 more than one geohash (one at both ends ?).

 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013/5/7 Peter Wendorff wendo...@uni-paderborn.de:
 Look what happens in OSM all the time: POIs are moved slightly to match
 aerial images - following your definition that should be another ID now

No, That's one of the nice properties of ids without coordinates!
To me it would remain the same - except when a tool or the user is
fooling the concept.
At least the tools you can debug.

Yours, Stefan

2013/5/7 Peter Wendorff wendo...@uni-paderborn.de:
 Am 07.05.2013 09:58, schrieb Stefan Keller:
 Hi,

 You wrote:
 - it's roughly in that bounding box (e.g. the city or a given part of

 A soon as you use the word roughly - the id approach is doomed to fail.
 According to OO and database technology an id is a well-defined
 surrogate with a well-defined data type.

 Then it's not the same permanent we talk about.
 Look what happens in OSM all the time: POIs are moved slightly to match
 aerial images - following your definition that should be another ID now
 - but that's not what people usually want if they request for a
 permanent ID, similar to changes from node to polygon to multipolyogn etc.

 It's in that bounding box nevertheless would have been the better
 wording, (equalling is roughly at that position, so if you want to use
 roughly/estimation, it's possible even then).

 regards
 Peter

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-07 Thread Christian Quest

I'm not proposing to add this as a new tag to OSM objects, but to use
these geoURL in external datasets instead of OSM IDs.

It is a way to keep a (fuzzy) link between datasets.

Fuzzyness seems mandatory at some level as I doubt it is possible to
have an exact match between data models that are completely different.

With higher and higher level of details in OSM data, it becomes more
and more difficult to describe more global things.
The node POI becomes a polygon POI, then maybe a multipolygon... the
single way street is later divided in several ways to describe each
part in details (pavement, oneway, light, trees, etc).

These geoURL could be generated from lat/lon + semantic infos about an
object, then resolved back to actual objects in whatever dataset
(including OSM but not only). overpass/XAPI could resolve these
geoURL by converting for example shop@u09v8s9fd5 into
[shop=*][bbox=] as geohash are in fact bboxes.

Think of it like the internet DNS system... hostname can be resolved
to IP addresses and the reverse. You don't have to resolve hostname to
know you're talking of the same thing but you have to in order to
access it.


2013/5/7 Stefan Keller sfkel...@gmail.com:
 2013/5/7 Christian Quest cqu...@openstreetmap.fr:
 Linking to OSM objet ID looks like a bad idea because they are not stable.

 Agreed.

 I've proposed something that can be summarized like some generic
 geoURL that could be used to describe something/somewhere in the form
 something@somewhere

 Am I understanding you correctly: You propose a kind of geoURL - like
 linked data [1] - which is a tag attached to OSM nodes?
 That would fulfill most of my criterias except that it does not
 indicate that it's a system property
 GeoHashes have a nice property of being completely independent of a
 centralized (or partially centralized) id generator.
 But they are not suited to identify object which are overlaying each other.

 Yours, Stefan

 [1]  http://semanticweb.org/wiki/GeoURL

 2013/5/7 Christian Quest cqu...@openstreetmap.fr:
 Linking to OSM objet ID looks like a bad idea because they are not stable.

 We had a recent long talk on talk-fr@ about permanent IDs that could
 help linking external data to OSM, instead of multiplying ref:xxx in
 OSM to link to external data.

 I've proposed something that can be summarized like some generic
 geoURL that could be used to describe something/somewhere in the form
 something@somewhere

 'something' could use some hierarchical semantic description, and
 'somewhere' could use for example geohash.

 Example for a bakery nearby my place: saines_saveurs.bakery.shop@u09v8s9fd5mc

 These geoURL can be compared with some level of fuzzyness on something
 and/or somewhere by reducing the level of details if necessary
 (exemple: shop@u09v8s9fd5 has less details and can be matched with a
 simple contain text search).

 They can be translated into whatever query like an overpass-api query
 to actually resolve to the current matching objets in OSM or somewhere
 else as the geoURL are not OSM based in any way.

 This mechanism works pretty well for node/polygon based POI, but needs
 to be extended for more linear features (like a street), maybe using
 more than one geohash (one at both ends ?).

 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk



-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

Unfortunately I'm too busy to investigate how much elements in OSM
change their meaning instead of deleting the old and creating the new
object.

In addition your fooling the concept is not correct. If a supermarket
is abandoned, and was tagged as a building + name + shop=supermarket,
you would not delete the whole object and add a new object with the
building tag alone, right?

regards
Peter

Am 07.05.2013 10:25, schrieb Stefan Keller:
 2013/5/7 Peter Wendorff wendo...@uni-paderborn.de:
 Look what happens in OSM all the time: POIs are moved slightly to match
 aerial images - following your definition that should be another ID now
 
 No, That's one of the nice properties of ids without coordinates!
 To me it would remain the same - except when a tool or the user is
 fooling the concept.
 At least the tools you can debug.
 
 Yours, Stefan
 
 2013/5/7 Peter Wendorff wendo...@uni-paderborn.de:
 Am 07.05.2013 09:58, schrieb Stefan Keller:
 Hi,

 You wrote:
 - it's roughly in that bounding box (e.g. the city or a given part of

 A soon as you use the word roughly - the id approach is doomed to fail.
 According to OO and database technology an id is a well-defined
 surrogate with a well-defined data type.

 Then it's not the same permanent we talk about.
 Look what happens in OSM all the time: POIs are moved slightly to match
 aerial images - following your definition that should be another ID now
 - but that's not what people usually want if they request for a
 permanent ID, similar to changes from node to polygon to multipolyogn etc.

 It's in that bounding box nevertheless would have been the better
 wording, (equalling is roughly at that position, so if you want to use
 roughly/estimation, it's possible even then).

 regards
 Peter
 


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-07 Thread Jo

Say the supermarket downsizes and the other half of the building becomes
used by another company. We split the building, creating 1 new building,
glued to the original building. Now there is a 50% chance the existing
building outline continues as the supermarket and 50% it's the new company
continuing life in OSM with that way id.

I'm working on our local bus stops a lot and they all have a ref displayed
on them, which is very convenient to refer back to them. In the other side
of the country and in Brussels, we have to make do with the name. If we
ever get access to the underlying DB, we might be able to add the internal
refs, which to me is still the most convenient way to identify specific bus
stops.

Right now there are usually at least 2 bus stops with the same name on both
sides of the road. relation membership could make them unique, once route
relations are added, but it complicates matters quite a bit to have to
identify them that way. (I'm not talking about linking bus stops to
Wikidata/Wikipedia). I need to link back to them to compare with the data
coming from upstream. Or to assist in creating/verifying route relations.

All that to say that, to me, ref tags on our objects seem like the most
stable and practical way to identify them.

Polyglot

2013/5/7 Peter Wendorff wendo...@uni-paderborn.de

 Unfortunately I'm too busy to investigate how much elements in OSM
 change their meaning instead of deleting the old and creating the new
 object.

 In addition your fooling the concept is not correct. If a supermarket
 is abandoned, and was tagged as a building + name + shop=supermarket,
 you would not delete the whole object and add a new object with the
 building tag alone, right?

 regards
 Peter

 Am 07.05.2013 10:25, schrieb Stefan Keller:
  2013/5/7 Peter Wendorff wendo...@uni-paderborn.de:
  Look what happens in OSM all the time: POIs are moved slightly to match
  aerial images - following your definition that should be another ID now
 
  No, That's one of the nice properties of ids without coordinates!
  To me it would remain the same - except when a tool or the user is
  fooling the concept.
  At least the tools you can debug.
 
  Yours, Stefan
 
  2013/5/7 Peter Wendorff wendo...@uni-paderborn.de:
  Am 07.05.2013 09:58, schrieb Stefan Keller:
  Hi,
 
  You wrote:
  - it's roughly in that bounding box (e.g. the city or a given part of
 
  A soon as you use the word roughly - the id approach is doomed to
 fail.
  According to OO and database technology an id is a well-defined
  surrogate with a well-defined data type.
 
  Then it's not the same permanent we talk about.
  Look what happens in OSM all the time: POIs are moved slightly to match
  aerial images - following your definition that should be another ID now
  - but that's not what people usually want if they request for a
  permanent ID, similar to changes from node to polygon to multipolyogn
 etc.
 
  It's in that bounding box nevertheless would have been the better
  wording, (equalling is roughly at that position, so if you want to use
  roughly/estimation, it's possible even then).
 
  regards
  Peter
 


 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

Am 07.05.2013 12:56, schrieb Stefan Keller:
 2013/5/7 Peter Wendorff wendo...@uni-paderborn.de:
 you would not delete the whole object and add a new object with the
 building tag alone, right?
 
 I said that it's up to the mapper to decide - as its common in OSM.
 External services which link to this object through the permanent id
 have to cope with this.
have to cope with this - but you didn't mention that when proposing to
use the OSM id (alone) as a reference...

regards
Peter

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-07 Thread Mike

I guess you are all both right and wrong on this matter and thus because 
you are loking from single angle only.


I recognize several different needs:


External link to coordinates

This is simply link to specific geographic coordinates. As it is not 
necessarily that there is an object on this coordinates that means there 
is no sense for such links to exist at all.



External link to location

Lets define location as specific place on map where object is located. 
It may not necessarily fixed to specific coordinates for the sole reason 
that coordinates may be changed for reasons like better measurements or 
fixed error or something like this. But, this is still just an location 
which may be linked externally regardless what type of object is located 
there.



External link to an property

Property is object on map that is fixed (if we disregard possibility 
that it may be destroyed or relocated in very exceptional conditions). 
Any kind of building is fine example. In some manner we may look at 
property and location as the same but with significant difference: 
location is related to geographic location and has eternal existence, 
and property is related on real object which is logically placed on a 
location but may be destroyed or (exceptionally) moved.


Back to the point, external link to an object is meant to target 
specific object that is not moveable.



External link to an property purpose

Property purpose is function object has. If we see building as an 
property, shop located in that building would be object purpose. Object 
purpose is not constant. It may change. Building may have number of 
purposes in time, or several purposes at the same time. But if some 
external database contains data about number of shops it needs to link 
to OSM data which related for specific shop. If shop moves few blocks 
away, external link should still point to that very shop.



So, to have database support all this needs it should have separate 
entities as location, property and property purpose in manner that one 
first defines location (with it's own ID), then defines property (with 
it's own ID) at that location and then attaches property purpose(s) 
(with their own ID(s)) for that object.



Whole discussion is caused because OSM database does not support this 
kind of objects. It is so loosely defined that object may serve all 
three roles from case to case and may even change role in time.



What could be solution?

First, let simplify things by merging role of location and role of 
property as they are very similar.


When new object is created in OSM database it should get it's unique ID. 
That ID stays unchanged until object is deleted. This is actually how 
thing are already done, and it will do the job for external linking to 
location or property.


But it does not help when property purposes are needed. So, OSM database 
may be expanded for another ID which is created when purpose is assigned 
to object and if purpose of the object is changed. It also should stay 
unique. This other property would allow linking to property purpose. If 
property purpose is deleted, it's ID is also deleted, but if purpose is 
moved to other object (on another location) then it's ID is moved to and 
unchanged, so external links will still be valid.



What happens when object is changed from point to multipoint or area or 
split?


It should done in such manner that object ID is preserved, or, in case 
new object is created instead of an old one, some kind of relation 
should be established so if database is queried for old object ID it 
would return info about new object with new ID which is replacement.


If object is split, one part preserves existing ID and other parts are 
considered as new objects with new ID's assigned.



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-07 Thread THEVENON Julien

 De : Mike mike.cuttl...@gmail.com

 I guess you are all both right and wrong on this matter and thus because 
 you are loking from single angle only.

 [...]

 If object is split, one part preserves existing ID and other parts are 
 considered as new objects with new ID's assigned.


Hi

I quite agree with Mike.
Properties should have a stable ID and geometrical objects ( 
way,node,relations) should refer to this ID to be qualified and on the other 
way it should be possible to find these objects from the ID.
By this way it would be easy to refer to a complex object like a motorway or 
country boundary even if it is made of a lot of subobjects. It would also solve 
the issue repeating a lot of tags on a lot of objects just because there is one 
change on part of the way
It would be a kind of everything is a relation but I'm afraid it could mean a 
change in OSM API

my 2 cents
Julien___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-06 Thread Andreas Labres

On 05.05.13 14:55, Kolossos wrote:
 I don't like to support different reference systems in WIWOSM.

I see the point. But WIWOSM seems not to work with anchor-links:

Neither
http://toolserver.org/~kolossos/openlayers/kml-on-ol-json3.php?lang=detitle=Liste%20der%20denkmalgesch%C3%BCtzten%20Objekte%20in%20Wien%2FPenzing%23objektid-25020
http://toolserver.org/%7Ekolossos/openlayers/kml-on-ol-json3.php?lang=detitle=Liste%20der%20denkmalgesch%C3%BCtzten%20Objekte%20in%20Wien%2FPenzing%23objektid-25020

nor
http://toolserver.org/~kolossos/openlayers/kml-on-ol-json3.php?lang=detitle=Liste_der_denkmalgesch%C3%BCtzten_Objekte_in_Wien%2FPenzing%23objektid-25026
http://toolserver.org/%7Ekolossos/openlayers/kml-on-ol-json3.php?lang=detitle=Liste_der_denkmalgesch%C3%BCtzten_Objekte_in_Wien%2FPenzing%23objektid-25026

(don't know how you want spaces encoded) does find the object in OSM.

And I'm not talking of a different reference system in WIWOSM.
Wikipedia/Wikidata should uniquely name those objects that only exist in
Wikipedia lists. We (OSM as well as WIWOSM) should only use those names.

/al

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-06 Thread Janko Mihelić

I made a wikidata tag proposal:

http://wiki.openstreetmap.org/wiki/Wikidata

I think osm -- wikidata is much better than wikidata -- osm. At least
while we don't have a solution for persistent ID's.

Janko
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-06 Thread colliar

Am 05.05.2013 05:26, schrieb malenki:
 On  04.05.2013 15:24, Paul Norman wrote:
 
 When I get new imagery for the area and re-trace the
 building depending on what is easiest I may end up creating a new way.
 
 The tool replace geometry exists - at least for JOSM. It even works
 on replacing an old (existing) Node for a new way.

Yes it is a nice tool but it only does include the node in the new way.

E.g. you still have a new object representing the real world object.

Cheers



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-06 Thread Kolossos

Hello Andreas,
It seems in principle possible to support anchor-links but it was not in
our focus, because our frontend had only one map per article. (You can
believe me the sytem was complex enough ;-)). I will talk about this
topic with my co-creator and the developer of WikiMiniAtlas.

It will also have some problems with articles in different languages
connected by Interwikilinks because the anchors could be different, so I
would like to support it later with Wikidata part 3 (lists).

Greetings Tim

Am 06.05.2013 11:03, schrieb Andreas Labres:

On 05.05.13 14:55, Kolossos wrote:

I don't like to support different reference systems in WIWOSM.

I see the point. But WIWOSM seems not to work with anchor-links:

Neither
http://toolserver.org/~kolossos/openlayers/kml-on-ol-json3.php?lang=detitle=Liste%20der%20denkmalgesch%C3%BCtzten%20Objekte%20in%20Wien%2FPenzing%23objektid-25020
http://toolserver.org/%7Ekolossos/openlayers/kml-on-ol-json3.php?lang=detitle=Liste%20der%20denkmalgesch%C3%BCtzten%20Objekte%20in%20Wien%2FPenzing%23objektid-25020

nor
http://toolserver.org/~kolossos/openlayers/kml-on-ol-json3.php?lang=detitle=Liste_der_denkmalgesch%C3%BCtzten_Objekte_in_Wien%2FPenzing%23objektid-25026
http://toolserver.org/%7Ekolossos/openlayers/kml-on-ol-json3.php?lang=detitle=Liste_der_denkmalgesch%C3%BCtzten_Objekte_in_Wien%2FPenzing%23objektid-25026

(don't know how you want spaces encoded) does find the object in OSM.

And I'm not talking of a different reference system in WIWOSM.
Wikipedia/Wikidata should uniquely name those objects that only exist in
Wikipedia lists. We (OSM as well as WIWOSM) should only use those names.

/al

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-06 Thread Peter Wendorff

Do they have something like a persistent ID in wikidata, yet?
Do you want to add dozens of wikidata-tags (or a comma separated value
or something like that), if more than one wikidata-element matches the
osm element.
Let's see this example: A building that was a merchants kontor a few
hundret years ago, and now contains a museum and a restaurant, while in
between it was - let's say - a hospital). The architect was a famous
person, too, and it's named by a third person.

So that osm element (building building would be referenced out of
wikidata from:
- the merchant's person page (his office)
- the museum's page
- the restaurant's page
- the hospital's page
- the architect's page
- the page of the person where the name of the building comes from

Which ID should be added to OSM here?
Is that really useful?

Wikidata seems to collect a lot of these links, including wiki-pages
(even in different languages) and so on, so wikidata in fact is built
around maintaining foreign references (at least it looks like that),
while OSM is definitively not (yet).

Perhaps look into the overpass-permanent-ID solution for that.

regards
Peter

Am 06.05.2013 16:14, schrieb Janko Mihelić:
 I made a wikidata tag proposal:
 
 http://wiki.openstreetmap.org/wiki/Wikidata
 
 I think osm -- wikidata is much better than wikidata -- osm. At least
 while we don't have a solution for persistent ID's.
 
 Janko
 
 
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk
 


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-06 Thread Tobias Knerr

On 06.05.2013 18:54, Peter Wendorff wrote:
 Do they have something like a persistent ID in wikidata, yet?

I think the Wikidata page title - something like Q35525 - is intended to
be rather stable. Of course there are sometimes problems, such as
duplicates or interwiki conflicts, that make it necessary to change
items. But unlike unlike OSM, Wikidata actually cares about providing an
ID for a distinct semantic entity.

In my opinion, this is a major reason to link to Wikidata using OSM
tags, and not the other way round. (Improving our data model in that
regard doesn't seem realistic in the short term.)

 Let's see this example: A building that was a merchants kontor a few
 hundret years ago, and now contains a museum and a restaurant, while in
 between it was - let's say - a hospital).

That's historical mapping. The problems would be the same for e.g. the
name. But as for the parts of the example that are not directly historic:

 - the merchant's person page (his office)

Wikidata would link to their internal building item instead. Not our job
imo.

 - the museum's page

Can be linked using the wikidata key at the museum POI.

 - the restaurant's page

Can be linked using the wikidata key at the restaurant POI.

 - the architect's page

Can be linked using the architect:wikidata key at the building.
It could be argued that we should leave that to Wikidata, though - they
have an architect property for buildings themselves.

 - the page of the person where the name of the building comes from

Can be linked using the name:etymology:wikidata key at the building.
Again, we theoretically could omit this and instead rely on Wikidata's
named after property.

 Perhaps look into the overpass-permanent-ID solution for that.

In my opinion that's not really a good solution here. Manually creating
Overpass API queries is too hard.

Tobias

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-06 Thread Eugene Alvin Villar

On Tue, May 7, 2013 at 2:26 AM, Tobias Knerr o...@tobias-knerr.de wrote:

 On 06.05.2013 18:54, Peter Wendorff wrote:
  Do they have something like a persistent ID in wikidata, yet?

 I think the Wikidata page title - something like Q35525 - is intended to
 be rather stable. Of course there are sometimes problems, such as
 duplicates or interwiki conflicts, that make it necessary to change
 items. But unlike unlike OSM, Wikidata actually cares about providing an
 ID for a distinct semantic entity.

 In my opinion, this is a major reason to link to Wikidata using OSM
 tags, and not the other way round. (Improving our data model in that
 regard doesn't seem realistic in the short term.)


For those who are not on the tagging mailing list, the wikidata=* tag has
been proposed[1], and discussed on the tagging mailing list starting late
February 2013[2]. Based on my assessment of the discussion, there doesn't
seem to be a clamor to add the wikidata=* tag to replace or even as an
additional tag to the wikipedia=* tag. The concern is that wikipedia=* is
much more easier for the average mapper to grasp than the wikidata=* tag.

[1] http://wiki.openstreetmap.org/wiki/Proposed_features/Wikidata
[2]
http://lists.openstreetmap.org/pipermail/tagging/2013-February/013077.html
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-06 Thread Tobias Knerr

On 06.05.2013 20:36, Eugene Alvin Villar wrote:
 For those who are not on the tagging mailing list, the wikidata=* tag
 has been proposed[1], and discussed on the tagging mailing list starting
 late February 2013[2]. Based on my assessment of the discussion, there
 doesn't seem to be a clamor to add the wikidata=* tag to replace or even
 as an additional tag to the wikipedia=* tag. The concern is that
 wikipedia=* is much more easier for the average mapper to grasp than the
 wikidata=* tag.

I'm subscribed to tagging and aware of that discussion, but it was
mostly based on the assumption that one could always get the Wikidata ID
indirectly from an Wikipedia article name. That was certainly true back
then - during phase 1 of the Wikidata rollout it was merely a new way of
storing the links between different Wikipedia languages - and is still
essentially true today because the entries were overwhelmingly based on
existing Wikipedia content.

However, Wikidata's scope is becoming broader. It is intended to replace
list articles in Wikipedia and will therefore likely include things that
don't have a Wikipedia article on their own. Depending on how the
notability politics play out, it may even include items that don't
appear on Wikipedia at all.

Therefore, there may be a reason to have a wikidata key even if we
prefer wikipedia links where they exist.

Anyway, most of the thread back then wasn't even about an overlap with
the wikipedia key, but about the possibility of replacing/syncing keys
such as operator with a wikidata link, which is of course a lot more
controversial than the tag in itself.

Tobias

 [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Wikidata
 [2]
 http://lists.openstreetmap.org/pipermail/tagging/2013-February/013077.html


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-06 Thread Peter Wendorff

Am 06.05.2013 20:26, schrieb Tobias Knerr:
 On 06.05.2013 18:54, Peter Wendorff wrote:
 
 [...]
 Let's see this example: A building that was a merchants kontor a few
 hundret years ago, and now contains a museum and a restaurant, while in
 between it was - let's say - a hospital).
 
 That's historical mapping. The problems would be the same for e.g. the
 name. But as for the parts of the example that are not directly historic:

No, it's not. I did not speak about mapping the hospital and the
merchants kontor, but about wikidata entries ahout the hospital and the
merchants kontor - and wikidata in fact includes historical entities
like that, too.

 
 - the merchant's person page (his office)
 
 Wikidata would link to their internal building item instead. Not our job
 imo.
 
 - the museum's page
 
 Can be linked using the wikidata key at the museum POI.
 
 - the restaurant's page
 
 Can be linked using the wikidata key at the restaurant POI.
You assume here that osm has distinct objects for building, restaurant
and museum, but often that's not the case.
Let's say the building mainly is/hosts the museum, and the restaurant
is a small part of it, covering a part of the building only (may be part
of the museum, too.

We don't have distinct objects in OSM in every case. Without the
restaurant, the museum and the building are the same, identical object;
but may be divided later perhaps into two objects (where one changes
it's semantics)
 
 - the architect's page
 
 Can be linked using the architect:wikidata key at the building.

Now you introduce a different approach to my overall question, and start
to use namespaces for wikidata-tags.
So why not in general use namespaces for all (even the cases above):

restaurant:wikidata
museum:wikidata
architect:wikidata
fire1934:wikidata
merchant:wikidata

I think, that get's very verbose once wikidata lifts off, and I don't
think it's a good idea.

 It could be argued that we should leave that to Wikidata, though - they
 have an architect property for buildings themselves.
+1

 
 - the page of the person where the name of the building comes from
 
 Can be linked using the name:etymology:wikidata key at the building.
 Again, we theoretically could omit this and instead rely on Wikidata's
 named after property.

To sum up your arguments:
well... let's use foreign keys, but only somewhere.
What's the rule you propose for this? when to use the wikidata-tag and
when not?
Is it possible to describe a rule for this? (even if we don't want to
enforce that rule, somehow what you propose should be documented and
therefore has to be documentable in a reasonable form).
 
 Perhaps look into the overpass-permanent-ID solution for that.
 
 In my opinion that's not really a good solution here. Manually creating
 Overpass API queries is too hard.
That's true, but what you propose is (yet) hard, too:
To decide where to link to wikidata and where to rely on wikidatas
internal links requires deep knowledge about the wikidata system, which
is IMHO not acceptable as a general precondition for mappers (whose
majority will have to deal with that in future to keep these links
reasonably up to date).

regards
Peter

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-06 Thread andrzej zaborowski

Hi,

On 6 May 2013 21:20, Peter Wendorff wendo...@uni-paderborn.de wrote:
 Am 06.05.2013 20:26, schrieb Tobias Knerr:
 On 06.05.2013 18:54, Peter Wendorff wrote:

 [...]
 Let's see this example: A building that was a merchants kontor a few
 hundret years ago, and now contains a museum and a restaurant, while in
 between it was - let's say - a hospital).

 That's historical mapping. The problems would be the same for e.g. the
 name. But as for the parts of the example that are not directly historic:

 No, it's not. I did not speak about mapping the hospital and the
 merchants kontor, but about wikidata entries ahout the hospital and the
 merchants kontor - and wikidata in fact includes historical entities
 like that, too.

If you're not adding those historical entities to OSM (or a similar
database like that historical osm once discussed) then there's no
issue with linking to Wikidata because there's nothing to be linked.
If on the other hand you want to add that hospital and that kontor,
then in the historical mapping schema I believe you'd add them as
separate objects with their own start_date and end_date tags so that's
what would link to wikidata (if you wanted to).



 - the merchant's person page (his office)

 Wikidata would link to their internal building item instead. Not our job
 imo.

 - the museum's page

 Can be linked using the wikidata key at the museum POI.

 - the restaurant's page

 Can be linked using the wikidata key at the restaurant POI.
 You assume here that osm has distinct objects for building, restaurant
 and museum, but often that's not the case.
 Let's say the building mainly is/hosts the museum, and the restaurant
 is a small part of it, covering a part of the building only (may be part
 of the museum, too.

If it doesn't occupy the entire building then you can probably add the
museum tag on the building geometry but later once you want to add a
wikidata tag you'd probably split it out like you'd split a street
object when you want to add an attribute that applies to a part of the
attribute.  If you're into indoor mapping then you'd draw the museum
outline separately anyway.

Or you could do namespaces, basically using the same criteria as with
different attributes.  For example opening_hours which may be
different for the museum and the building.  The mechanism can be the
same for wikidata=* as for e.g. opening_hours=* and oneway=*.

 We don't have distinct objects in OSM in every case. Without the
 restaurant, the museum and the building are the same, identical object;
 but may be divided later perhaps into two objects (where one changes
 it's semantics)

 - the architect's page

 Can be linked using the architect:wikidata key at the building.

 Now you introduce a different approach to my overall question, and start
 to use namespaces for wikidata-tags.
 So why not in general use namespaces for all (even the cases above):

 restaurant:wikidata
 museum:wikidata
 architect:wikidata
 fire1934:wikidata
 merchant:wikidata

 I think, that get's very verbose once wikidata lifts off, and I don't
 think it's a good idea.

 It could be argued that we should leave that to Wikidata, though - they
 have an architect property for buildings themselves.
 +1


 - the page of the person where the name of the building comes from

 Can be linked using the name:etymology:wikidata key at the building.
 Again, we theoretically could omit this and instead rely on Wikidata's
 named after property.

 To sum up your arguments:
 well... let's use foreign keys, but only somewhere.
 What's the rule you propose for this? when to use the wikidata-tag and
 when not?
 Is it possible to describe a rule for this? (even if we don't want to
 enforce that rule, somehow what you propose should be documented and
 therefore has to be documentable in a reasonable form).

 Perhaps look into the overpass-permanent-ID solution for that.

 In my opinion that's not really a good solution here. Manually creating
 Overpass API queries is too hard.
 That's true, but what you propose is (yet) hard, too:
 To decide where to link to wikidata and where to rely on wikidatas
 internal links requires deep knowledge about the wikidata system, which
 is IMHO not acceptable as a general precondition for mappers (whose
 majority will have to deal with that in future to keep these links
 reasonably up to date).

Again mappers are already dealing with this problem when they add
phone= or website= tags.  There's no clear criteria but it's not a a
problem specific to wikidata links.

Cheers

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-06 Thread Peter Wendorff

Am 06.05.2013 23:07, schrieb andrzej zaborowski:
 Hi,
 
 On 6 May 2013 21:20, Peter Wendorff wendo...@uni-paderborn.de wrote:
 Am 06.05.2013 20:26, schrieb Tobias Knerr:
 On 06.05.2013 18:54, Peter Wendorff wrote:

 [...]
 Let's see this example: A building that was a merchants kontor a few
 hundret years ago, and now contains a museum and a restaurant, while in
 between it was - let's say - a hospital).

 That's historical mapping. The problems would be the same for e.g. the
 name. But as for the parts of the example that are not directly historic:

 No, it's not. I did not speak about mapping the hospital and the
 merchants kontor, but about wikidata entries ahout the hospital and the
 merchants kontor - and wikidata in fact includes historical entities
 like that, too.
 
 If you're not adding those historical entities to OSM (or a similar
 database like that historical osm once discussed) then there's no
 issue with linking to Wikidata because there's nothing to be linked.

Why not?
The building is the same, and it's not of interest, that the tag
amenity=museum is not (any more) existent in osm.

If that's an argument any wikidata entity that's not tagged as complete
as the wikidata entity itself would be nothing to be linked.

Your cross-reference (only add a reference osm pointing to wikidata to
the building, but link all other entities of wikidata to the building)
argument may be valid, but it's complex (that's my question below); but
especially historical entities are of interest to be linked, as they are
not directly findable by going out and watch.


 [...] 
 - the restaurant's page

 Can be linked using the wikidata key at the restaurant POI.
 You assume here that osm has distinct objects for building, restaurant
 and museum, but often that's not the case.
 Let's say the building mainly is/hosts the museum, and the restaurant
 is a small part of it, covering a part of the building only (may be part
 of the museum, too.
 
 If it doesn't occupy the entire building then you can probably add the
 museum tag on the building geometry but later once you want to add a
 wikidata tag you'd probably split it out like you'd split a street
 object when you want to add an attribute that applies to a part of the
 attribute.  If you're into indoor mapping then you'd draw the museum
 outline separately anyway.
so you propose to split it up because of an external ID you propose to
add...
While I in general agree that objects of osm are split when they get
mapped in more detail (like in this example), I'm not happy to do that
for the reason to enable matching to external references.

 Or you could do namespaces, basically using the same criteria as with
 different attributes.  For example opening_hours which may be
 different for the museum and the building.  The mechanism can be the
 same for wikidata=* as for e.g. opening_hours=* and oneway=*.
and it's not working for opening_hours either afaik; usually we split
the pois in these cases.

[...]
 Perhaps look into the overpass-permanent-ID solution for that.

 In my opinion that's not really a good solution here. Manually creating
 Overpass API queries is too hard.
 That's true, but what you propose is (yet) hard, too:
 To decide where to link to wikidata and where to rely on wikidatas
 internal links requires deep knowledge about the wikidata system, which
 is IMHO not acceptable as a general precondition for mappers (whose
 majority will have to deal with that in future to keep these links
 reasonably up to date).
 
 Again mappers are already dealing with this problem when they add
 phone= or website= tags.  There's no clear criteria but it's not a a
 problem specific to wikidata links.
Of course not, but even the external id problem is not specific to
wikidata links.

Wikipedia links are for a long time relatively stable, and as wikipedia
I think is often used as one reference for osm, too, it's widely
accepted to be of benefit for both sides.

Wikidata is not yet proven that stable nor that useful, and -
especially: it's a data project. It would be a great task and solution
to design e.g. an overpass-permanent-osm-id-editor that defines the link
in a useful gui (e.g. derived from wikidata attributes like country,
county, city, postcode, location/coordinate, address, ... which might be
part of wikidata, I think.

Wikidata links are harder to maintain, nearly impossible to check
(without opening the page), while wikipedia links have meaningful names.

Wikidata links currently are mostly duplicates of wikipedia article's
entities (as that's the big imported stuff from the beginning).

Therefore I personally oppose currently to reference wikidata entities
from osm objects; at least where no good rules exist where and when to
link which types of objects, and which not.

regards
Peter

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-06 Thread Stefan Keller

Hi,

I also think that linking from an OSM object to a growing no. of
external databases (incl. Wikipedia/Wikidata) is not a good idea. And
I respect the wish of the OSM maintainers to change the OSM id in the
future. But the overpass-permanent-osm-id is no solution neither,
primo because a set of key-values is a clumsy id, and secondo because
there exist many OSM objects which have no identifying tags (or none
at all).

As this issue pops up from in increasingly frequent intervals I think
it's time to think about a good mid term solution (short term is
sticking to the OSM id).

I'm proposing a solution alongside one of the following two directions:
* either to implement a Linked Data API/service which maps from
permanent ids to OSM objects (and which is what I like about overpass
- being a service) -
* or to add a permanent id as an additional XML tag to every OSM
object! And if somebody thinks that's a waste of space we can easily
drop the XML tag user which is completely redundant to uid (which
in turn needs another simple API to find out the current users display
name).

Yours, Stefan



2013/5/6 Peter Wendorff wendo...@uni-paderborn.de:
 Am 06.05.2013 23:07, schrieb andrzej zaborowski:
 Hi,

 On 6 May 2013 21:20, Peter Wendorff wendo...@uni-paderborn.de wrote:
 Am 06.05.2013 20:26, schrieb Tobias Knerr:
 On 06.05.2013 18:54, Peter Wendorff wrote:

 [...]
 Let's see this example: A building that was a merchants kontor a few
 hundret years ago, and now contains a museum and a restaurant, while in
 between it was - let's say - a hospital).

 That's historical mapping. The problems would be the same for e.g. the
 name. But as for the parts of the example that are not directly historic:

 No, it's not. I did not speak about mapping the hospital and the
 merchants kontor, but about wikidata entries ahout the hospital and the
 merchants kontor - and wikidata in fact includes historical entities
 like that, too.

 If you're not adding those historical entities to OSM (or a similar
 database like that historical osm once discussed) then there's no
 issue with linking to Wikidata because there's nothing to be linked.

 Why not?
 The building is the same, and it's not of interest, that the tag
 amenity=museum is not (any more) existent in osm.

 If that's an argument any wikidata entity that's not tagged as complete
 as the wikidata entity itself would be nothing to be linked.

 Your cross-reference (only add a reference osm pointing to wikidata to
 the building, but link all other entities of wikidata to the building)
 argument may be valid, but it's complex (that's my question below); but
 especially historical entities are of interest to be linked, as they are
 not directly findable by going out and watch.


 [...]
 - the restaurant's page

 Can be linked using the wikidata key at the restaurant POI.
 You assume here that osm has distinct objects for building, restaurant
 and museum, but often that's not the case.
 Let's say the building mainly is/hosts the museum, and the restaurant
 is a small part of it, covering a part of the building only (may be part
 of the museum, too.

 If it doesn't occupy the entire building then you can probably add the
 museum tag on the building geometry but later once you want to add a
 wikidata tag you'd probably split it out like you'd split a street
 object when you want to add an attribute that applies to a part of the
 attribute.  If you're into indoor mapping then you'd draw the museum
 outline separately anyway.
 so you propose to split it up because of an external ID you propose to
 add...
 While I in general agree that objects of osm are split when they get
 mapped in more detail (like in this example), I'm not happy to do that
 for the reason to enable matching to external references.

 Or you could do namespaces, basically using the same criteria as with
 different attributes.  For example opening_hours which may be
 different for the museum and the building.  The mechanism can be the
 same for wikidata=* as for e.g. opening_hours=* and oneway=*.
 and it's not working for opening_hours either afaik; usually we split
 the pois in these cases.

[...]
 Perhaps look into the overpass-permanent-ID solution for that.

 In my opinion that's not really a good solution here. Manually creating
 Overpass API queries is too hard.
 That's true, but what you propose is (yet) hard, too:
 To decide where to link to wikidata and where to rely on wikidatas
 internal links requires deep knowledge about the wikidata system, which
 is IMHO not acceptable as a general precondition for mappers (whose
 majority will have to deal with that in future to keep these links
 reasonably up to date).

 Again mappers are already dealing with this problem when they add
 phone= or website= tags.  There's no clear criteria but it's not a a
 problem specific to wikidata links.
 Of course not, but even the external id problem is not specific to
 wikidata links.

 Wikipedia links are for a long time

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-06 Thread Tobias Knerr

Am 06.05.2013 23:55, schrieb Peter Wendorff:
 Am 06.05.2013 23:07, schrieb andrzej zaborowski:
 If you're not adding those historical entities to OSM (or a similar
 database like that historical osm once discussed) then there's no
 issue with linking to Wikidata because there's nothing to be linked.
 
 Why not?

It wouldn't add any information. The hospital should be linked to the
building _within_ Wikidata anyway because there are more properties that
can be attached to a building than just a OSM building outline.

So if we connect the OSM building and the Wikidata building, then the
hospital is already (though Wikidata) linked to the OSM building, too.

 If it doesn't occupy the entire building then you can probably add the
 museum tag on the building geometry but later once you want to add a
 wikidata tag you'd probably split it out like you'd split a street
 object when you want to add an attribute that applies to a part of the
 attribute.  If you're into indoor mapping then you'd draw the museum
 outline separately anyway.
 so you propose to split it up because of an external ID you propose to
 add...
 While I in general agree that objects of osm are split when they get
 mapped in more detail (like in this example), I'm not happy to do that
 for the reason to enable matching to external references.

Using the same OSM element for two distinct features actually
contradicts a strict one feature, one OSM element principle. We do it
anyway because it's convenient, but as soon as you want to add the same
tag - whether it's name, opening_hours, or wikidata - to both features,
you create two separate elements.

That's not a special treatment of external IDs, but consistent with
other tags, and using two separate elements is semantically better anyway.

 and it's not working for opening_hours either afaik; usually we split
 the pois in these cases.

Exactly.

 Wikidata links are harder to maintain, nearly impossible to check
 (without opening the page), while wikipedia links have meaningful names.

YMMV, but I always open Wikipedia links to check whether they are
(still) correct.

 Therefore I personally oppose currently to reference wikidata entities
 from osm objects; at least where no good rules exist where and when to
 link which types of objects, and which not.

I think a good rule to start with would be: If there is a Wikipedia or
Wikidata entry about that particular feature *itself*, then it can
always be linked (using the appropriate key).

Such links cannot possibly be replaced with links within Wikidata, and
there is a limited number of them. With the namespaced links, however,
we indeed get an essentially unbounded number of potential links and I
don't know a good rule for these atm.

Tobias

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-05 Thread Kolossos


Hello Andreas,
I hope Wikidata part 3 solve the problem with the list, so that an 
object would be one Wikidata entry and can be a member in different 
lists but can also have an own article.


A map with objects in the example article is here:[1]

I have no influence on the way how
http://www.openstreetmap.org/browse/way/48434939
links to Wikipedia, I could also only ask an admin.
With a link to index.php it would be easy to solve[2].

An external project with m:n-relations between OSM and WP would have 
it's own problems.


Greetings Tim alias Kolossos

[1]http://toolserver.org/~kolossos/openlayers/kml-on-ol.php?lang=deuselang=detitle=Liste%20der%20denkmalgesch%C3%BCtzten%20Objekte%20in%20Wien%2FPenzingzoom=15lat=48.21428lon=16.22318layers=B00FFTTF

[2]http://de.wikipedia.org/w/index.php?uselang=detitle=Liste_der_denkmalgesch%C3%BCtzten_Objekte_in_Wien/Penzing#objektid-25026

Am 05.05.2013 08:08, schrieb Andreas Labres:

Tim,

There are problems with WIWOSM that aren't solved at all...

Example: Historic monuments in Austria. They are all covered in Wikipedia, but
mostly only in Lists. And they do have a distinguishable objectID, but I can't
really state this in OSM.

For instance:

http://www.openstreetmap.org/browse/way/207854465 ist such a historic monument
with objectID 25020.
It can be found in Wikipedia here:
http://de.wikipedia.org/wiki/Liste_der_denkmalgesch%C3%BCtzten_Objekte_in_Wien/Penzing#objektid-25020

So I can only state the tag
wikipedia:de = Liste der denkmalgeschützten Objekte in
Wien/Penzing#objektid-25020

This has the effect that the link in OSM doesn't work (because OSM adds a
userlang parameter behind the anchor reference which I consider a bug of OSM
[did already report it]).

And also WIWOSM can't reference the distict object. Though it seems to be able
to reference some of the Liste_der_denkmalgeschützten_Objekte_in_Wien/Penzing.
It can't do all because some of the objects do have their own wikipedia
entrance, for instance Mariarunn church:

http://www.openstreetmap.org/browse/way/48434703
http://de.wikipedia.org/wiki/Pfarr-_und_Wallfahrtskirche_Mariabrunn

So what would be necessary is that wikipedia and OSM would agree on some kind of
generic ID, which could in the case of historic monuments in Austria be some
/monument/AT/$objectID, e.g.

   /monument/AT/25020, which then would redirect to

http://de.wikipedia.org/wiki/Liste_der_denkmalgesch%C3%BCtzten_Objekte_in_Wien/Penzing#objektid-25020

whereas

   /monument/AT/24616 could redirect to
   http://de.wikipedia.org/wiki/Pfarr-_und_Wallfahrtskirche_Mariabrunn

/al





___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-05 Thread Andreas Labres

Tim,

There are different problems, let's keep them separate (vielleicht reden wir
auch - Englisch - aneinander vorbei... ;)

a) There is a problem in the code of osm.org how it links wikipedia articles.
You can't do a link like this:

$PATH#anchor?uselang=en

   This is bad URL syntax. You (osm.org) have to do

   $PATH?uselang=en#anchor

   https://trac.openstreetmap.org/ticket/4802

b) It is not a good idea to link objects in Wikipedia lists like

Liste der denkmalgeschützten Objekte in Wien/Penzing#objektid-25026

   This object should have its own name in Wikipedia, which then redirects to
whereever this object can be found. This shouldn't be external but a feature
in Wikipedia/Wikidata/Wikiwhatsoever.

c) The objectID I'm referencing is nothing external, it's a nationally unique
ID given by the Austrian Bundesdenkmalamt which identifies each monument in
Austria. Therefore it's the best idea to use /this/ as /the/ reference to the
given object (with reference to it being a historic monument). Alex Wagner, who
created all the Denkmalgeschützte Objekte in Austria in the Wikipedia used it
when he created the Wikipedia pages.

   http://lists.openstreetmap.org/pipermail/talk-at/2013-April/005542.html  ff

OSM could save this objectID, say:

   ref:monument=AT:25026

and WIWOSM then knows how to find this (uniquely identified) object in 
Wikipedia.

/al


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-05 Thread Jan Kučera

Hi guys,

I am most likely the one who started the whole issue of adding relation
IDs to Wikipedia at all - I created the Wikipedia templates and inserted
several tenths of relation IDs to specific articles... and you know why?
Because at the time I did that there was no WIWOSM (or any other usable
tool for featuring OSM content within Wikimedia projects) and this was the
easiest (although I understand not the best) way to connect/link Wikipedia
to OSM. I understand tag query for a specific keywors(s) (probably deriving
from Wikipedia article name) would be much better, there simply WAS NOT a
simple enough tool to do this or at least I did not know about such a tool.

The original idea was to link a page that would show a desired object in a
map. So the action definitely was simply a result of lack of services on
OSM side. If this has changed now, I suggest we use such a tool that
produces similar output (in terms of data and speed) as the current
relations links.

Regards,
Kozuch


2013/5/5 Andreas Labres l...@lab.at

 Tim,

 There are different problems, let's keep them separate (vielleicht reden
 wir
 auch - Englisch - aneinander vorbei... ;)

 a) There is a problem in the code of osm.org how it links wikipedia
 articles.
 You can't do a link like this:

 $PATH#anchor?uselang=en

This is bad URL syntax. You (osm.org) have to do

$PATH?uselang=en#anchor

https://trac.openstreetmap.org/ticket/4802

 b) It is not a good idea to link objects in Wikipedia lists like

 Liste der denkmalgeschützten Objekte in Wien/Penzing#objektid-25026

This object should have its own name in Wikipedia, which then
 redirects to
 whereever this object can be found. This shouldn't be external but a
 feature
 in Wikipedia/Wikidata/Wikiwhatsoever.

 c) The objectID I'm referencing is nothing external, it's a nationally
 unique
 ID given by the Austrian Bundesdenkmalamt which identifies each monument
 in
 Austria. Therefore it's the best idea to use /this/ as /the/ reference to
 the
 given object (with reference to it being a historic monument). Alex
 Wagner, who
 created all the Denkmalgeschützte Objekte in Austria in the Wikipedia
 used it
 when he created the Wikipedia pages.

http://lists.openstreetmap.org/pipermail/talk-at/2013-April/005542.html ff

 OSM could save this objectID, say:

ref:monument=AT:25026

 and WIWOSM then knows how to find this (uniquely identified) object in
 Wikipedia.

 /al


 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-05 Thread malenki

[Quoting repaired on an (as it seems) accidential PM]

yve...@gmail.com wrote on Sun, 05 May 2013 08:53:04:
 malenki wrote

On  04.05.2013 15:24, Paul Norman wrote:

 When I get new imagery for the area and re-trace the
 building depending on what is easiest I may end up creating a new
 way.

The tool replace geometry exists - at least for JOSM. It even works
on replacing an old (existing) Node for a new way.

Josm is an editor, it's not concerned in affecting IDs at all. That's
the API job.

When you delete any object using any editor, the IDs are insofar
affected as the object the ID points to is marked as deleted. Don't
know if you are happy with a valid ID pointing to nowhere. ;)

Using replace geometry you can re-trace your building, mark both old
and new way and apply the tool so the old way with its nodes gets the
shape of the new way but keeps its and the nodes old IDs.

Regards
malenki


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-04 Thread Martin Raifer


Jason Remillard remillard.ja...@gmail.com wrote:


However, given what exists today shouldn't Wikipedia be using the
overpass API for referencing OSM?


I'd also say so: There already is a Permanent ID [1] service.

http://overpass-api.de/api/interpreter?data=[out:custom];rel[boundary=administrative][admin_level=6][name=London];out;

Regards,
Martin / tyr_asd

[1] http://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-04 Thread Andrew Gray

On 4 May 2013 00:49, Claus Stadler cstad...@informatik.uni-leipzig.de wrote:
 Hi,

 Shouldn't OSM use Wikipedia URLs as UUIDs where applicable rather than
 Wikipedia referring to database identifiers? (The answer is a clear 'yes'
 from my side.)
 In fact there are the (wikipedia, *) tags - but not sure how good the
 quality is - what can be seen on a first glance is, that people mix URLs and
 article names, and also encoding.

Wikipedia URLs are themselves potentially unstable, though - it's
usually more or less okay for geographic places, since we tend to have
fixed naming systems, but to pick a high-profile example, the URL
https://en.wikipedia.org/wiki/Perth has at various times over the past
ten years pointed to Perth in Perthshire, Perth in Western Australia,
and a placeholder disambiguator page.

(They are also, of course, language-dependent, but that's another
kettle of fish)

Wikidata entities are (with a few caveats) static and
language-independent (eg https://www.wikidata.org/wiki/Q3183 ), and
could potentially be useful here - but they're not human-readable and
you'd have to rely on an API to convert them into page titles, which
seems like it might not be desirable.

-- 
- Andrew Gray
  andrew.g...@dunelm.org.uk

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-04 Thread Claus Stadler


Hi,

 Wikidata entities are (with a few caveats) static and 
language-independent (eg https://www.wikidata.org/wiki/Q3183), and could 
potentially be useful here


I totally agree, so tagging OSM entities with Wikidata IDs (where 
applicable) might improve the stability even beyond that of using 
Wikipedia arctile names.


 but they're not human-readable and you'd have to rely on an API to 
convert them into page titles, which seems like it might not be desirable.
We are talking about people wanting stable references to OSM. If this is 
the most stable way to do, then ppl have to - and will - live with it. 
Because they are doing it already.


Right now, [1] is a popular source for stable identifiers - for each 
Wikipedia article, there a a corresponding *machine readable* DBpedia 
entry [2].
And in [3] you see an overview of datasets referring to these IDs. Note 
that by ID I actually mean IRIs in general.


So if Wikidata succeeds, we will be using their IDs all over the place. 
There is work in progress to make Wikidata Linked Data / Semantic Web 
compatible - in the next few months we will know more[4].



As for the Demo I meantioned in another mail:

I am the maintainer of the LinkedGeoData (LGD)[5] project where we 
publish the whole OSM database as RDF data.
This means I have a full, live synced replicate of the planet here - and 
let me say great job! to the osmosis devs :)


So I created a Wikipedia article name Linked Data API:
Note that there are just a bit more than 100K entities having a 
wikipedia tag, and the data quality seems really low.

http://test.linkedgeodata.org/wp/Catford

This does a lookup for the OSM id based on their wikipedia and 
wikipedia:en tags.


When you follow the shown sameAs link, you will go to:
http://test.linkedgeodata.org/triplify/node13878144

which is the RDF version of the corresponding OSM entity.

Yay!

Note, at this URL, you will see that it points to 
http://dbpedia.org/resource/Catford - so you can navigate the *data* 
just like hyperlinks in HTML documents.


Also note, that this is not just a I hack a REST API thing:
You can also query it - e.g. whiche user added the Wikipedia link and 
what else did he edit:


bit.ly/13chv0W http://bit.ly/13chv0W

Add 'Explain' before the 'SELECT' to see the SQL.
Yes, its a bit slow because Postgres takes a bad query plan for the 
conditional Wikipedia tags index _. Everything will get better with 
the new  materialized views support ;)


Cheers,
Claus


[1] http://dbpedia.org
[2] Example: http://dbpedia.org/resource/Catford
   Note:If you start scraping the HTML for data, you're doing it wrong ;)
 curl -LH Accept: application/rdf+xml 
http://dbpedia.org/resource/Catford
 curl -LH Accept: application/json 
http://dbpedia.org/resource/Catford

 Or visit: http://dbpedia.org/data/Catford.ntriples
  Same data, different formats.

[3] http://lod-cloud.net/versions/2011-09-19/lod-cloud_colored.html
[4] http://meta.wikimedia.org/wiki/Wikidata/Development/RDF
[5] http://linkedgeodata


On 05/04/2013 11:47 AM, Andrew Gray wrote:

On 4 May 2013 00:49, Claus Stadler cstad...@informatik.uni-leipzig.de wrote:

Hi,

Shouldn't OSM use Wikipedia URLs as UUIDs where applicable rather than
Wikipedia referring to database identifiers? (The answer is a clear 'yes'
from my side.)
In fact there are the (wikipedia, *) tags - but not sure how good the
quality is - what can be seen on a first glance is, that people mix URLs and
article names, and also encoding.

Wikipedia URLs are themselves potentially unstable, though - it's
usually more or less okay for geographic places, since we tend to have
fixed naming systems, but to pick a high-profile example, the URL
https://en.wikipedia.org/wiki/Perth has at various times over the past
ten years pointed to Perth in Perthshire, Perth in Western Australia,
and a placeholder disambiguator page.

(They are also, of course, language-dependent, but that's another
kettle of fish)

Wikidata entities are (with a few caveats) static and
language-independent (eg https://www.wikidata.org/wiki/Q3183 ), and
could potentially be useful here - but they're not human-readable and
you'd have to rely on an API to convert them into page titles, which
seems like it might not be desirable.




--
Dipl. Inf. Claus Stadler
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org/
Workpage  WebID: http://aksw.org/ClausStadler
Phone: +49 341 97-32260

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-04 Thread Shaun McDonald


On 4 May 2013, at 10:47, Andrew Gray andrew.g...@dunelm.org.uk wrote:

 On 4 May 2013 00:49, Claus Stadler cstad...@informatik.uni-leipzig.de wrote:
 Hi,
 
 Shouldn't OSM use Wikipedia URLs as UUIDs where applicable rather than
 Wikipedia referring to database identifiers? (The answer is a clear 'yes'
 from my side.)
 In fact there are the (wikipedia, *) tags - but not sure how good the
 quality is - what can be seen on a first glance is, that people mix URLs and
 article names, and also encoding.
 
 Wikipedia URLs are themselves potentially unstable, though - it's
 usually more or less okay for geographic places, since we tend to have
 fixed naming systems, but to pick a high-profile example, the URL
 https://en.wikipedia.org/wiki/Perth has at various times over the past
 ten years pointed to Perth in Perthshire, Perth in Western Australia,
 and a placeholder disambiguator page.
 
 (They are also, of course, language-dependent, but that's another
 kettle of fish)

Being language dependant isn't as issue as you simply state the language of the 
article name used, and then through interwiki links can link to the appropriate 
article in any wikipedia language.

Shaun

 
 Wikidata entities are (with a few caveats) static and
 language-independent (eg https://www.wikidata.org/wiki/Q3183 ), and
 could potentially be useful here - but they're not human-readable and
 you'd have to rely on an API to convert them into page titles, which
 seems like it might not be desirable.
 
 -- 
 - Andrew Gray
  andrew.g...@dunelm.org.uk
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-04 Thread Kolossos


Hello,
as co-creator of WIWOSM I was also against this Wikidata-property, but I 
came too late.
WIWOSM links are not only more stable and human-readable, the are also 
much more flexible. So in WIWOSM we can suport relations but also 
multirelations, ways, multiways nodes, multinodes. I'm waiting for the 
day where the people starts to create relations for each building only 
to be able to link on it from Wikidata.


We have now Wikipedia-Tags for over 300.000 objects and I would prefer 
to concentrate the power of the community to one system instead to split 
it.


In my eyes, what Wikidata perhaps need is one bit (created by a bot) 
with the information yes there is an matching OSM object to create a 
link to a map, the rest can come from WIWOSM.


Later if Wikidata starts to have entries without an own 
Wikipedia-article we should support a Wikidata-Tag, but thats on way[2]. 
This will happen at part 3 of Wikidata-project were they want to support 
list creation. With projects like WikiLovesMonuments I'm sure that we 
will have on some places a link for each building, so the problem above 
is not only theory.


Greetings Tim alias Kolossos

[1] http://taginfo.openstreetmap.org/keys/wikipedia
[2] http://wiki.openstreetmap.org/wiki/Proposed_features/Wikidata

Am 04.05.2013 01:49, schrieb Claus Stadler:

Hi,

Shouldn't OSM use Wikipedia URLs as UUIDs where applicable rather than
Wikipedia referring to database identifiers? (The answer is a clear
'yes' from my side.)
In fact there are the (wikipedia, *) tags - but not sure how good the
quality is - what can be seen on a first glance is, that people mix URLs
and article names, and also encoding.

Cheers,
Claus

On 05/04/2013 01:34 AM, Jason Remillard wrote:

Hi,

In general is seems like it might be useful to have some kind of
somewhat permanent URL to an element inside of OSM. However, given
what exists today shouldn't Wikipedia be using the overpass API for
referencing OSM?

Thanks
Jason.

On Fri, May 3, 2013 at 6:46 PM, Paul Norman penor...@mac.com wrote:

From: andrzej zaborowski [mailto:balr...@gmail.com]
Sent: Friday, May 03, 2013 2:08 PM
To: Frederik Ramm
Cc: OpenStreetMap
Subject: Re: [OSM-talk] OSM relation ID property in Wikidata


I am less concerned about the Wikidata side - if they make a bad
judgement then it is their mess to clean up. I am however concerned
that if more people simply assume that the status quo is there to stay
(IDs are stable enough), this will put pressure on *us* and limit
our flexibility in the future.

The OSMF has sent a pretty strong message saying that object IDs are
stable enough to base impactful legal decisions on them.  It will look
silly for them to go back to the stance that IDs aren't stable after
all.

There's two sides to ID stability. One is stability during software
or data
model changes and the other is stability during normal mapping.
Frederik's
post was concerned more with the former.

The latter is more complicated. Because the original message linked to
London, it's worth pointing out that a few admin relations did get
new IDs
in the redaction process for technical reasons and that periodically
relations get given new IDs because old large complex relations don't
interact well with the /history call.


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk








___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-04 Thread Mike


 I am however concerned that
 if more people simply assume that the status quo is there to stay (IDs
 are stable enough), this will put pressure on *us* and limit our
 flexibility in the future.

But, what is the point if ID's are not stable?

How can we externally link to the data and make sure link will stay 
valid in time? I am not talking about URL links but links to objects 
(which, obviously, is done by object ID).




___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-04 Thread Paul Norman

 From: Mike [mailto:mike.cuttl...@gmail.com]
 Sent: Saturday, May 04, 2013 1:36 PM
 To: talk@openstreetmap.org
 Subject: Re: [OSM-talk] OSM relation ID property in Wikidata

   I am however concerned that
   if more people simply assume that the status quo is there to stay
 (IDs   are stable enough), this will put pressure on *us* and limit
 our   flexibility in the future.

 But, what is the point if ID's are not stable?

 How can we externally link to the data and make sure link will stay
 valid in time? I am not talking about URL links but links to objects
 (which, obviously, is done by object ID).

A link to an OSM object will remain a link to an OSM object, but that's not
very helpful.

An OSM ID will normally correspond to the same physical object for all of
its versions, unless its deleted. There is no guarantee, but it allows you
to say that if node 123 is not deleted then it is probably Joe's coffee
shop. It doesn't allow you to say that Joe's coffee shop is node 123.

A physical object will not always correspond to the same OSM ID. It is this
last property that matters for external links. As an example, a particular
Lowe's home improvement store near me used to be OSM node 1498097430 and now
is OSM way 136961700. When I get new imagery for the area and re-trace the
building depending on what is easiest I may end up creating a new way.

Relying on the OSM representation of some real-world object to maintain the
same ID is wrong. There is no property of OSM IDs that allows you to say
that Joe's coffee shop will continue to be node 123.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-04 Thread malenki

On  04.05.2013 15:24, Paul Norman wrote:

 When I get new imagery for the area and re-trace the
 building depending on what is easiest I may end up creating a new way.

The tool replace geometry exists - at least for JOSM. It even works
on replacing an old (existing) Node for a new way.


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OSM relation ID property in Wikidata

2013-05-03 Thread Svavar Kjarrval

Hi.

Just wanted to notify those who didn't know: There is now a property
(P402) in use in Wikidata to link the corresponding entry to a relation
ID in OSM.

Example: https://www.wikidata.org/wiki/Q84

With regards,
Svavar Kjarrval


signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata


Hi,

On 03.05.2013 18:15, Svavar Kjarrval wrote:

Just wanted to notify those who didn't know: There is now a property
(P402) in use in Wikidata to link the corresponding entry to a relation
ID in OSM.


This is a very bad idea and should not be used.

Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-03 Thread Eugene Alvin Villar

On Sat, May 4, 2013 at 3:33 AM, Frederik Ramm frede...@remote.org wrote:

 On 03.05.2013 18:15, Svavar Kjarrval wrote:

 Just wanted to notify those who didn't know: There is now a property
 (P402) in use in Wikidata to link the corresponding entry to a relation
 ID in OSM.


 This is a very bad idea and should not be used.


I assume you think this is bad because OSM IDs are not stable with respect
to the objects they represent?

It seems this was discussed by the Wikidata users when there was a very
recent proposal to delete this OSM ID property (P402):
https://www.wikidata.org/wiki/Wikidata:Properties_for_deletion#Property:P402

The consensus was that--at least for place relations which are the target
of the said property--OSM relation IDs are stable enough and any changes in
IDs can be easily rectified. Wikidata is a wiki after all.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata


Hi,

On 03.05.2013 22:12, Eugene Alvin Villar wrote:

The consensus was that--at least for place relations which are the
target of the said property--OSM relation IDs are stable enough and any
changes in IDs can be easily rectified. Wikidata is a wiki after all.


I am less concerned about the Wikidata side - if they make a bad 
judgement then it is their mess to clean up. I am however concerned that 
if more people simply assume that the status quo is there to stay (IDs 
are stable enough), this will put pressure on *us* and limit our 
flexibility in the future.


I fear that some day soon we'll have a good idea about re-organising our 
admin bounds that involves large-scale changes, and then people come to 
us and say ah, that's unfortunate because we at [insert some other 
project or product or company] had assumed that relation IDs are 
relatively stable


As soon as everyone who uses our relation IDs as external pointers signs 
a document that says I know I am doing something that could potentially 
backfire and if it does I swear that I will not try to exert pressure on 
OSM but instead tell my own users that it is entirely my fault for being 
short-sighted and that I had been warned, then I guess that's fine ;)


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-03 Thread andrzej zaborowski

On 3 May 2013 22:58, Frederik Ramm frede...@remote.org wrote:
 On 03.05.2013 22:12, Eugene Alvin Villar wrote:
 The consensus was that--at least for place relations which are the
 target of the said property--OSM relation IDs are stable enough and any
 changes in IDs can be easily rectified. Wikidata is a wiki after all.

 I am less concerned about the Wikidata side - if they make a bad judgement
 then it is their mess to clean up. I am however concerned that if more
 people simply assume that the status quo is there to stay (IDs are stable
 enough), this will put pressure on *us* and limit our flexibility in the
 future.

The OSMF has sent a pretty strong message saying that object IDs are
stable enough to base impactful legal decisions on them.  It will look
silly for them to go back to the stance that IDs aren't stable after
all.

Cheers

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata


Hi,

On 03.05.2013 23:08, andrzej zaborowski wrote:

The OSMF has sent a pretty strong message saying that object IDs are
stable enough to base impactful legal decisions on them.


The OSMF has never sent messages saying that object IDs are stable or 
even stable enough for anything; if you interpreted any of the license 
change discussions in that way, you are mis-interpreting them.


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-03 Thread Jochen Topf

On Fri, May 03, 2013 at 11:08:01PM +0200, andrzej zaborowski wrote:
 On 3 May 2013 22:58, Frederik Ramm frede...@remote.org wrote:
  On 03.05.2013 22:12, Eugene Alvin Villar wrote:
  The consensus was that--at least for place relations which are the
  target of the said property--OSM relation IDs are stable enough and any
  changes in IDs can be easily rectified. Wikidata is a wiki after all.
 
  I am less concerned about the Wikidata side - if they make a bad judgement
  then it is their mess to clean up. I am however concerned that if more
  people simply assume that the status quo is there to stay (IDs are stable
  enough), this will put pressure on *us* and limit our flexibility in the
  future.
 
 The OSMF has sent a pretty strong message saying that object IDs are
 stable enough to base impactful legal decisions on them.  It will look
 silly for them to go back to the stance that IDs aren't stable after
 all.

What are you talking about?

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.jochentopf.com/  +49-721-388298

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata

2013-05-03 Thread andrzej zaborowski

On 3 May 2013 23:14, Frederik Ramm frede...@remote.org wrote:
 On 03.05.2013 23:08, andrzej zaborowski wrote:
 The OSMF has sent a pretty strong message saying that object IDs are
 stable enough to base impactful legal decisions on them.

 The OSMF has never sent messages saying that object IDs are stable or even
 stable enough for anything; if you interpreted any of the license change
 discussions in that way, you are mis-interpreting them.

I don't understand -- wasn't the entire process based on the
assumption that intellectual property persists as long as the object
ID persists?  Wasn't that in part your own decision?

Cheers

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM relation ID property in Wikidata