Re: [Tagging] Permanent IDs RFC (was part_of:wikidata)

[Frederik Ramm]

Ah, I forgot to say: The result of many, lengthy, previous discussions
about permanent IDs was generally: We don't want to shoulder the
responsibility of maintaining a permanent ID in OSM that others can use
for easy linking; instead, those others should be doing that work for
themselves. Hence the idea of "fuzzy" permanent links was born, where
your link is not really a link but a search query:

"A restaurant named Bella Italia in the general vicinity of X", or "The
restaurant that is in this building, if any", and so on. That way, the
person placing the link has to decide which property, for *them*, is the
"essence" of what they're pointing to, instead of burdening us in OSM to
add a ton of IDs to a restaurant object. Some work has been done by
Roland Olbricht (of Overpass API) to make the concept workable, see:

http://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID

Bye
Frederik

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

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Permanent IDs RFC (was part_of:wikidata)

[Frederik Ramm]

Hi,

On 30.11.2017 03:13, Yuri Astrakhan wrote:
> Permanent IDs has been brought up several times, especially as part of
> the Wikidata ID discussion. I started a wiki page to outline the
> requirements and goals, but it might be incomplete, feel free to add /
> correct / comment.

See https://wiki.openstreetmap.org/wiki/Proposed_Features/UUID for an
earlier and somewhat failed idea.

Biggest issue IMHO that came up in the UUID discussion is that it is
unclear what the ID relates to, and mappers cannot be expected to handle
that topic in all its complexity properly.

Example:

Restaurant "Bella Italia" with well-known Michelin 4-star chef changes
its name to "Apulia" but otherwise stays the same. What happens with the
ID? What if someone has, somewhere, compiled a list: "All restaurants
named something with Italy" and linked to them by ID?

Example:

Same case as above, but restaurant (including chef and name) moves to a
different part of the city. Should the ID move? What if someone has
compiled a list: "Restaurants in 19th century buildings", of which the
old "Bella Italia" was a part, but the new one isn't?

To do this right, you would have to have different IDs for the same OSM
object - one for the "instance of restaurant" that happens to be here,
one for the building, one for the chef, one for the name - there's no
end. Somehow with a permanent ID you want to capture the "essence" of
something and stick the ID to that, but the "essence" of something is
often a combination of factors (name, location, cuisine...).

There are many other examples that illustrate that the very concept of
permanent IDs is hard to make work in OSM.

Bye
Frederik

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

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Permanent IDs RFC (was part_of:wikidata)

[Yuri Astrakhan]

Marc, good points, thanks. Naturally it will never be decided by software.
The tools should aid in continuity preservation, not dictate it. We as a
community should definitely how each one of these and other cases should be
handled -- to define what "permanence" means.

>

> * What if the shop moves to a new address ? What if someone already
> recorded the shop at the new location, how do we merge the IDs?
>
If we decide that a moved shop should have the same id, than this is a case
for merge+making one redirect to the other.

>
> * A restaurant POI and the building it resides in are 2 different
> concepts, they both need their own permanent ID. How can we
> distinguish them ?

If the entire building is a restaurant (e.g. a standalone McDonald's), than
it should probably be the same id. But if restaurant is occupying the first
floor of a residential bldg, probably two.

How does the software knows this when someone "joins" the POI and the
> building ?
>
Software wouldn't know, but an editor should always keep this in mind, and
there tools should offer some "join" mechanism.

>

> * What do you do when a modern part is attached to a listed building ?
> Will the building parts have permanent IDs ?
>
If the building or a road is extended, it should keep the old id. If the
new part is notable on its own, the part may get a new id as well, while
also being part of the old id.

>
> This is something you cannot solve with software alone. A human has to
> try to decide what you have to do with the permanent IDs in some
> (many?) cases.
>
I would say the human has to decide it in every case :). The software
should help with the process. That's why I listed community education as a
big part of introducing this.

Btw, permanent IDs would help with historical maps too.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Permanent IDs RFC (was part_of:wikidata)

[Marc Gemis]

I also see several problems to define the "same" concept:

* a shop that closes (bankrupt) and a new that opens afterwards. Is
this the same shop ? Is there a difference when the shop owner remains
the same?  When the products they sell are the same (I have a case of
bakery that closed and opened a few months later with new owners and a
different name in my town) ?

* What if the shop moves to a new address ? What if someone already
recorded the shop at the new location, how do we merge the IDs?

* A restaurant POI and the building it resides in are 2 different
concepts, they both need their own permanent ID. How can we
distinguish them ? How does the software knows this when someone
"joins" the POI and the building ?

* What do you do when a modern part is attached to a listed building ?
Will the building parts have permanent IDs ?

This is something you cannot solve with software alone. A human has to
try to decide what you have to do with the permanent IDs in some
(many?) cases.

m.

On Thu, Nov 30, 2017 at 3:13 AM, Yuri Astrakhan  wrote:
> Permanent IDs has been brought up several times, especially as part of the
> Wikidata ID discussion. I started a wiki page to outline the requirements
> and goals, but it might be incomplete, feel free to add / correct / comment.
>
> https://wiki.openstreetmap.org/wiki/Permanent_ID
>
> Once we reach the agreement on the goals, we can figure out the
> implementation strategy.
>
>
> On Tue, Nov 28, 2017 at 2:47 PM, Andy Mabbett 
> wrote:
>>
>> On 28 November 2017 at 16:40, Christoph Hormann  wrote:
>>
>> > The problem is OSM is a map of the physical world, not a map of the
>> > world's databases.  If Wikidata wants to create links between OSM and
>> > other databases that is great but so far i think no one has made a good
>> > case why this linking information should be stored in OSM rather than
>> > Wikidata.
>>
>> Then you are not paying attention. OSM IDs are volatile - far more
>> volatile than Wikipedia IDs, let alone Wikidata IDs.
>>
>> > Again my suggestion: Working on better ways to address features in OSM
>> > in a stable way from the outside would be much more productive
>>
>> Great! Let us know when you have a working solution, consensus to
>> implement it, and tools that work with it.
>>
>> --
>> Andy Mabbett
>> @pigsonthewing
>> http://pigsonthewing.org.uk
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] part_of:wikidata key

[Marc Gemis]

Do I understand it correctly that one of the reasons you do not want
to use Wikidata IDs because the data on the item is not verified
according to the same rules as OSM ?

For me Wikidata IDs can be viewed as URLs, just like the URL of a
shop. If I can verify that it describes the same item (more or less
(*)), I can add the Wikidata ID (or shop URL).

regards

m.

(*) Even URLs of hotels can describe too much (e.g. the environment,
things to see, etc.), but I haven't seen anyone complaining about
that.

On Wed, Nov 29, 2017 at 3:08 PM, Christoph Hormann  wrote:
> On Wednesday 29 November 2017, Marc Gemis wrote:
>>
>> I assume you mean verifiable without accessing the Wikidata website.
>> I often hear contradicting information about "verifiable". Some
>> people say it's only "on the ground", others find it OK to ask
>> locals. It would be nice to know what you understand under
>> "verifiable".
>
> Verifiability ultimately has relatively little to with the sources used.
> On the contrary being independent of specific sources is a key aspect
> of it.
>
> For physically observable things this is pretty easy because it often
> boils down to if you can measure something - either directly as a
> quantity (like a geometry or the iconic height tag of a building) or
> using statistics (an area can qualify as natural=wood if it features a
> certain density of trees).  You can usually measure with better
> reliability and more accurately when you are locally on the ground so
> in cases of doubt the observation on the ground stands above remote
> assessment.
>
> For things like a name it is more complex because it is not usually
> observable physically - unless there are signs.  But you can verifiably
> determine the name of a lake for example by spending sufficient time
> around it and asking every local you meet for the name of the lake.  If
> you get consistent results (like 3/4 of the people giving you the same
> name) you have a verifiable name.  No one practically does this test of
> course but as a local mapper you have an intuitive feeling for what the
> test will have as results.
>
> Now the wikidata ID is different - not mainly because you have to look
> it up in a separate database (which you could argue is similar to the
> idea of asking a local for the name of something) but because what you
> look at there is not first hand local knowledge and because you cannot
> independently verify if this information is true or false.
>
> If i assume for a moment that every piece of information in wikidata is
> diligently recorded according to the rules there it would be possible
> to reconstruct this information from the "serious and publicly
> available references" used but in many cases it could *only* be
> reconstructed based on these sources and not independently.  This is
> the main reason why wikidata information is not verifiable according to
> the OSM understanding of verifiability.
>
> In other words: If a sufficient number of "serious and publicly
> available references" assert something is true this qualifies it for
> being recorded in wikidata.  So a lot of things in wikidata are not
> verifiable in the OSM sense because if they are true or false depends
> on what sources exactly you consider for your assessment.  And because
> of that the mapper in OSM cannot verifiably determine if a wikidata
> object created based on such information qualifies for being specified
> in a wikidata tag.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] part_of:wikidata key

[Yuri Astrakhan]

Jo, take a look at
* Links to Wikipedia pages about multiple objects


There are several cases when an OSM feature matches a part of
Wiki(pedia|data) article, and I don't think part_of would cover them all.
Also, Wikipedia page usually represents a "concept", whereas part of the
page may or may not contain that concept - often depending on the language
of the wiki.  I think a more generic "related:wikipedia" is  more
appropriate - it would indicate that there is no 1:1 matching article or
wikidata, but it would help future OSM editors find relevant information in
a Wikipedia page.

P.S. I tried to document some of the requirements for the OSM Permanent ID
* https://wiki.openstreetmap.org/wiki/Permanent_ID

On Tue, Nov 28, 2017 at 6:34 AM, Jo  wrote:

> Hi,
>
> I would like to propose a new key:
>
> part_of:wikidata
>
> The wikidata key itself should only occur on a single OSM object.
>
> When trying to add it to linear features, this poses a problem, as it's
> possible to split such features.
>
> Grouping objects in associatedStreet and river relations (and adding
> wikidata identifiers on them) partly solves this, but associatedStreet
> wasn't liked much and is pretty much dead in the water and in the river
> relations, only the linear features are included, not the riverbank area
> ways.
>
> Does it make sense to create pages for this on the wiki? Or would several
> people have issues with such a proposal?
>
> Polyglot
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Permanent IDs RFC (was part_of:wikidata)

[Yuri Astrakhan]

Permanent IDs has been brought up several times, especially as part of the
Wikidata ID discussion. I started a wiki page to outline the requirements
and goals, but it might be incomplete, feel free to add / correct / comment.

https://wiki.openstreetmap.org/wiki/Permanent_ID

Once we reach the agreement on the goals, we can figure out the
implementation strategy.


On Tue, Nov 28, 2017 at 2:47 PM, Andy Mabbett 
wrote:

> On 28 November 2017 at 16:40, Christoph Hormann  wrote:
>
> > The problem is OSM is a map of the physical world, not a map of the
> > world's databases.  If Wikidata wants to create links between OSM and
> > other databases that is great but so far i think no one has made a good
> > case why this linking information should be stored in OSM rather than
> > Wikidata.
>
> Then you are not paying attention. OSM IDs are volatile - far more
> volatile than Wikipedia IDs, let alone Wikidata IDs.
>
> > Again my suggestion: Working on better ways to address features in OSM
> > in a stable way from the outside would be much more productive
>
> Great! Let us know when you have a working solution, consensus to
> implement it, and tools that work with it.
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (Fire Hydrant Extensions (part 2))

[François Lacombe]

Hi Alberto,

This is a nice news :)
Thank you to bring this up !

Francois

2017-11-29 22:26 GMT+01:00 Viking :

> Finally the proposal [1] has been approved.
> Thank you to all people who worked on this project.
> As soon as possible we will update fire hydrant wiki page.
> Then we can go on with part 3... :)
>
> [1] https://wiki.openstreetmap.org/wiki/Proposed_features/
> Fire_Hydrant_Extensions_(part_2)
>
> Best regards
> Alberto
>
>
> ---
> Questa e-mail è stata controllata per individuare virus con Avast
> antivirus.
> https://www.avast.com/antivirus
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (Fire Hydrant Extensions (part 2))

[Viking]

Finally the proposal [1] has been approved.
Thank you to all people who worked on this project.
As soon as possible we will update fire hydrant wiki page.
Then we can go on with part 3... :)

[1] 
https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant_Extensions_(part_2)

Best regards
Alberto


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] wikidata <> other ref <> no ref

[Marc Gemis]

> Therefore, BEFORE you run a query to READ wikidata key in osm, you used
> an EXTERNAL source (for exemple a list of address of those buildings)
> and made a import or mass edition (often undocumented and therefore not
> following the rule) to WRITE wikidata on all buildings.

And what if local people just know which John Smith made the building
in their neighbourhood and mapped that ? Why do you assume 1 person
mapped all of that ?

m.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] wikidata <> other ref <> no ref

[Andy Mabbett]

On 29 November 2017 at 13:05, marc marc  wrote:
> Le 29. 11. 17 à 12:06, Andy Mabbett a écrit :
>> On 29 November 2017 at 00:40, marc marc wrote:
>>
>>> my query shows you that you can get the same without wikidata.
>>
>> Please demonstrate how you would write a query that lists all the
>> buildings whose architect is (hypothetically) John Smith.

>> Without using Wikidata.
>
> I'm sure that 100% of those buildings are NOT mapped with
> architect:wikidata=thevalue

So am I - currently - which is why I deliberately used the word
"hypothetically".

Can you make such a query, or not?

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] part_of:wikidata key

[Christoph Hormann]

On Wednesday 29 November 2017, Marc Gemis wrote:
>
> I assume you mean verifiable without accessing the Wikidata website.
> I often hear contradicting information about "verifiable". Some
> people say it's only "on the ground", others find it OK to ask
> locals. It would be nice to know what you understand under
> "verifiable".

Verifiability ultimately has relatively little to with the sources used.  
On the contrary being independent of specific sources is a key aspect 
of it.

For physically observable things this is pretty easy because it often 
boils down to if you can measure something - either directly as a 
quantity (like a geometry or the iconic height tag of a building) or 
using statistics (an area can qualify as natural=wood if it features a 
certain density of trees).  You can usually measure with better 
reliability and more accurately when you are locally on the ground so 
in cases of doubt the observation on the ground stands above remote 
assessment.

For things like a name it is more complex because it is not usually 
observable physically - unless there are signs.  But you can verifiably 
determine the name of a lake for example by spending sufficient time 
around it and asking every local you meet for the name of the lake.  If 
you get consistent results (like 3/4 of the people giving you the same 
name) you have a verifiable name.  No one practically does this test of 
course but as a local mapper you have an intuitive feeling for what the 
test will have as results.

Now the wikidata ID is different - not mainly because you have to look 
it up in a separate database (which you could argue is similar to the 
idea of asking a local for the name of something) but because what you 
look at there is not first hand local knowledge and because you cannot 
independently verify if this information is true or false.

If i assume for a moment that every piece of information in wikidata is 
diligently recorded according to the rules there it would be possible 
to reconstruct this information from the "serious and publicly 
available references" used but in many cases it could *only* be 
reconstructed based on these sources and not independently.  This is 
the main reason why wikidata information is not verifiable according to 
the OSM understanding of verifiability.  

In other words: If a sufficient number of "serious and publicly 
available references" assert something is true this qualifies it for 
being recorded in wikidata.  So a lot of things in wikidata are not 
verifiable in the OSM sense because if they are true or false depends 
on what sources exactly you consider for your assessment.  And because 
of that the mapper in OSM cannot verifiably determine if a wikidata 
object created based on such information qualifies for being specified 
in a wikidata tag.

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] wikidata <> other ref <> no ref

[marc marc]

Le 29. 11. 17 à 12:06, Andy Mabbett a écrit :
> On 29 November 2017 at 00:40, marc marc wrote:
> 
>> my query shows you that you can get the same without wikidata.
> 
> Please demonstrate how you would write a query that lists all the
> buildings whose architect is (hypothetically) John Smith.
> 
> That's the architect John Smith born in London in 1853, not the
> architect John Smith born in London in 1867, nor the architect John
> Smith born in Birmingham in 1853.
> 
> Without using Wikidata.

I'm sure that 100% of those buildings are NOT mapped with 
architect:wikidata=thevalue by someone who passes through the street and 
adds wikidata key after reading "architect John Smith born in London in 
1853" on the building.

Therefore, BEFORE you run a query to READ wikidata key in osm, you used 
an EXTERNAL source (for exemple a list of address of those buildings) 
and made a import or mass edition (often undocumented and therefore not 
following the rule) to WRITE wikidata on all buildings.

If you have the tool/extra db to import missing tags into osm, this is 
proof that you can select those osm buildings without wikidata key in 
osm db.

I don't think it is necessary to put wikidata keys to define all the 
possible and imaginable characteristics.
For example finding all stores that sell organic blue sweaters was very 
useful to me, but it is not the role of osm to have this information 
regularly imported. some infos are better outside osm

Coming back to the first subject, the name of the streets, if you still 
believe that it is necessary to have a wikidata key to find a street 
because the name key can have errors, then follow through and also 
suggest replacing addr:street with a wikidata key because this key 
should also have some typos.
And what next ? all keys are likely to have typos or unwanted 
translation. like building=maison (in french) in stead of building=house.

Regards,
Marc
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] part_of:wikidata key

[Marc Gemis]

On Wed, Nov 29, 2017 at 12:06 PM, Christoph Hormann  wrote:
>
> I have no real problem with that either - just like i have no problem
> with people keeping adding is_in tags.  As said i would advise against
> it but we have the freedom to use any tags you want and i firmly
> believe in that.  You can question if this freedom applies to
> non-verifiable tags but i am not niggling here.

I assume you mean verifiable without accessing the Wikidata website.
I often hear contradicting information about "verifiable". Some people
say it's only "on the ground", others find it OK to ask locals.
It would be nice to know what you understand under "verifiable".

m.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] part_of:wikidata key

[Christoph Hormann]

On Wednesday 29 November 2017, Eugene Alvin Villar wrote:
>
> So you want us to develop OSM tools and improve editors to preserve
> and manage OSM ID inheritance/permanence. But this is not a simple
> problem to solve.
>
> On the other hand, you deem maintenance of Wikidata IDs in OSM a huge
> bother. But we can create OSM tools and improve editors as well to
> help manage this. I imagine that this is a simpler problem to solve
> than the first problem of OSM ID permanence.
>
> Also, we don't require mappers to add wikipedia=* tags to objects
> they map in OSM, or to maintain these Wikipedia tags so that they
> remain accurate and updated. Other mappers are free to update and
> maintain these tags. This is accepted practice and there is no huge
> outcry against adding more wikipedia=* tags.

Please don't recite what i wrote in a distorting way.  I said nothing of 
what you imply i said above.  You are free to ignore what i said or 
interpret it for you as you like but you are not free to present a 
distorting interpretation as if i actually said that.

I am aware that that the analysis and suggestions i present are often 
very brief and sometimes difficult to understand - when i say something 
like "external IDs [...] will never scale on a level of hundreds of 
millions of features in the end" you will only be able to understand 
what i mean if you approach the subject with an open mind and analyze 
the same scenario questioning any preconceived assumptions you might 
have about it.  But i have no intention pressing anyone who is not 
ready for it to do that.

> This accepted practice with respect to wikipedia=* tags can be
> equally applied to wikidata=* tags. We won't require mappers to do
> research to add this tag, but other mappers are free to add/maintain
> these as well. I see no huge problem with this.

I have no real problem with that either - just like i have no problem 
with people keeping adding is_in tags.  As said i would advise against 
it but we have the freedom to use any tags you want and i firmly 
believe in that.  You can question if this freedom applies to 
non-verifiable tags but i am not niggling here.  Automated edits 
adding/modifying wikidata tags are a different subject of course but 
that is not the topic here.

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] wikidata <> other ref

[Andy Mabbett]

On 29 November 2017 at 00:40, marc marc  wrote:

> my query shows you that you can get the same without wikidata.

Please demonstrate how you would write a query that lists all the
buildings whose architect is (hypothetically) John Smith.

That's the architect John Smith born in London in 1853, not the
architect John Smith born in London in 1867, nor the architect John
Smith born in Birmingham in 1853.

Without using Wikidata.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging