Re: [OSM-talk] iD news: v1.9.6 released

[Andreas Labres]

On 17.06.16 16:35, Martin Koppenhoefer wrote:
Another issue I believe to have found in this item looking at 
https://www.wikidata.org/wiki/Q486972 :
the first words, (I believe it is meant to be the definition, although it does 
not explicitly say so,) are "densely populated geographic location


  * populated place
  * settlement
  * human community
  * inhabited place"



ACK. This is a definition (in German) I'd agree with: Siedlungsformen: Art, Zahl 
undräumlicheAnordnungmenschlicher Behausungen (kinds of settlement: kind, number 
and areal arrangement of human dwellings).


Also a single farm (ein alleinstehender Einzelhof) is one kind of settlement 
(and often has a name, BTW). And of the group settlements (Gruppensiedlungen: 
Einschicht, Weiler, Rotte, Dorf, Markt und Stadt) there are different kinds, 
some of which are explicitely *not* densely populated (Einschicht, Weiler, 
Rotte). See http://www.aeiou.at/aeiou.encyclop.s/s567496.htm for kinds of 
settlements (in German).


I'd define "settlement" just as: (group of) human dwellings.

And to me there also is a difference: a settlement's extent isn't defined per 
se. It can be a group of houses and generally it is countable what houses belong 
to that settlement. But this doesn't define what fields/land/acres are/is 
included. In contrast, an "administrative territorial entity" 
(Verwaltungseinheit) solely defines the land it includes (of course with all the 
buildings on it).


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

Re: [OSM-talk] iD news: v1.9.6 released

[Martin Koppenhoefer]

sent from a phone

> Il giorno 18 giu 2016, alle ore 03:44, Minh Nguyen 
>  ha scritto:
> 
> I'm familiar with our guidelines on automatic edits, but I find it a stretch
> to apply them here. iD is essentially inserting an alternative, more stable
> representation of a title the mapper specifically chose. This is no more
> automatic than an editor silently deleting TIGER tags upon touching a node,
> filling in the `source` tag of a changeset based on the imagery layers used,
> or stripping spaces after semicolons in tags.


I think wikidata objects are somehow more serious than Wikipedia articles, 
because the latter require interpretation with a grain of salt, while wikidata 
appears to be mathematically precise descriptions of things and the 
relationship between them. This difference is way bigger than spaces or not 
after semicolons, or the removal of meaningless or redundant tags (tiger), as 
we have seen there are substantial differences on a semantic level.


cheers,
Martin 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD news: v1.9.6 released

[Martin Koppenhoefer]

sent from a phone

> Il giorno 18 giu 2016, alle ore 03:44, Minh Nguyen 
>  ha scritto:
> 
> I see no problem with the semantics in
> .


if you wanted, you could see problems also there: it is at the same time: 
"abandoned village, town or city, usually one which contains substantial 
visible remains" and is a subclass of "abandoned village", shouldn't it be the 
opposite, abandoned village a subclass of ghost towns?

abandoned village is covered (?) by the German article "Wüstung" which is a 
word for an abandoned settlement or deserted site (de:Wirtschaftsfläche, i.e. 
it is much broader in scope): 
https://www.wikidata.org/wiki/Q350895
the languages af and nl seem to be similar to the German version.

This is a maze, with significant differences between Wikipedia articles in 
different languages alone, and in comparison with wikidata, and the attached 
semantics in wikidata. Almost any time you look at an wikidata item there are 
issues and content level contradictions. Yes, most of this is to be found in WP 
as well, but the difference is that an article is not machine readable, and a 
human will more likely know how to interpret the information.


cheers,
Martin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD news: v1.9.6 released

[Minh Nguyen]

(Sorry, I sent from the wrong address, so this message got stuck in moderation.)

Martin Koppenhoefer  gmail.com> writes:

> 
> 
> 
> Sorry that it took me a while to reply, I was out of office and just came
back now.
> 
> 
> Il giorno 10 giu 2016, alle ore 21:07, Minh Nguyen 
nguyen.cincinnati.oh.us> ha scritto:
> 
> 
> 
> is this your interpretation or is it explicitly defined like this? I'm
> astonished that these 2 concepts are supposedly structured vertically and
not horizontally in wikidata 
> 
> 
>  is defined in Wikidata as a
subsetof . I agree that this is a
suboptimalrelationship – anyone can edit
> 
> 
> 
> it's not a big problem to have errors in the relations as long as
everybody can agree that it's an error and should be corrected. But the fact
that this wrong relation still sits in there and doesn't actually get
corrected is a bit troubling, particularly as this is IMHO a major bug which
has influence on all settlements that are in wikidata.
> 
> 
> Another issue I believe to have found in this item looking at
https://www.wikidata.org/wiki/Q486972 :the first words, (I believe it is
meant to be the definition, although it does not explicitly say so,) are
"densely populated geographic location
> 
> 
> populated place
> settlement
> human community
> inhabited place"
> 
> Now when you think about a ghost town, it clearly is a human settlement,
but this definition falls short in covering it. I would prefer, rather than
a collection of related terms (human community, inhabited place etc), a
complete sentence that defines the term, e.g. "a human settlement is a place
where a community of humans lives or lived and decided in the past to settle
and create dwellings." (surely could be improved, just an example).
> 
> There are lots of unanswered questions in wikidata, and probably, by
judging from the current state of the data, not enough editors to manage to
look through all of it.
> Another issue that comes to mind: what about contradictions between an
article and a wikidata object? How is the relationship between the articles
and wikidata? Apparently, you can only associate on article to one item, so
this suggests a strong relationsship, but clearly there are articles in many
languages, and there will be lots of contradictions between those languages
(because there are lots of articles, and because nearly noone cross checks
different languages). IMHO it would have been a better idea to have a less
strong relationship, something like "this article has information about this
item" (and hence allow multiple articles to be associated with an object)
rather than what it seems conceptually  to be thought of now (the articles
and this wikidata object deal with the same thing, are the same thing, here
in article form and here as mathematical relations).For me these are just
more indications that we should not base automatic edits on this source at
the moment. 

You raise a number of important points, but I think these concerns should be
posed on Wikidata's village pump or mailing list, where they can be more
effectively addressed. The Wikidata community has more answers that I would
individually.

I disagree that these considerations make the iD feature less correct given
that the wikidata tag is already widely used.

In fact, many of these same questions could be asked of Wikipedia. If the
mapper is tagging a ghost town POI with a Wikipedia article, can we be sure
at a technical level that the article's contents or categorization matches
OSM's semantics? Regardless, if the tagged feature is tagged as a ghost town
in OSM, the fact that it is tagged as a non-former human settlement in
Wikidata merely means the Wikidata item needs to be retagged as a ghost
town. I see no problem with the semantics in
.

When an English-speaking mapper tags `wikipedia=en:China`, what's to say
`wikipedia=fr:Chine` has the same semantics? It's two hops away from the
English article, rather than the one hop to Wikidata. Yet most tools and
users assume that one is equivalent to the other when tagged on an object.
Otherwise, we'd have to maintain a litany of redundant `wikipedia:xy` tags
on every place POI and basically try to replicate Wikidata's interwiki
function for any Wikipedia tag to be broadly useful.

It wasn't so long ago that most Wikipedias' articles named "Crimea" referred
to the political entity as well as or instead of the peninsula. If, back
then, the administrative boundary in OSM had been tagged with
`wikipedia=en:Crimea` and mappers subsequently forgot about that tag, it
would've suddenly become illogical as soon as Wikipedia editors decided to
move the "Crimea" article somewhere else and replace it with what was
previously titled "Crimean peninsula". (The opposite happened with the
"China" article.) Meanwhile, the `wikidata` tag would've continued to point
to an administrative territorial entity 

Re: [OSM-talk] iD news: v1.9.6 released

[Martin Koppenhoefer]

2016-06-17 17:55 GMT+02:00 Minh Nguyen :

> I disagree that these considerations make the iD feature less correct
> given that the wikidata tag is already widely used.




the important difference is, that someone adding a wikidata tag manually
will likely check the wikidata object, someone doing it automatically will
likely not.

Cheers,
Martin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD news: v1.9.6 released

[Martin Koppenhoefer]

Sorry that it took me a while to reply, I was out of office and just came
back now.

Il giorno 10 giu 2016, alle ore 21:07, Minh Nguyen <
m...@nguyen.cincinnati.oh.us> ha scritto:

is this your interpretation or is it explicitly defined like this? I'm
astonished that these 2 concepts are supposedly structured vertically and
not horizontally in wikidata


 is defined in Wikidata as a subset
of . I agree that this is a suboptimal
relationship – anyone can edit



it's not a big problem to have errors in the relations as long as everybody
can agree that it's an error and should be corrected. But the fact that
this wrong relation still sits in there and doesn't actually get corrected
is a bit troubling, particularly as this is IMHO a major bug which has
influence on all settlements that are in wikidata.

Another issue I believe to have found in this item looking at
https://www.wikidata.org/wiki/Q486972 :
the first words, (I believe it is meant to be the definition, although it
does not explicitly say so,) are "densely populated geographic location

   - populated place
   - settlement
   - human community
   - inhabited place"


   -


   - Now when you think about a ghost town, it clearly is a human
   settlement, but this definition falls short in covering it. I would prefer,
   rather than a collection of related terms (human community, inhabited place
   etc), a complete sentence that defines the term, e.g. "a human settlement
   is a place where a community of humans lives or lived and decided in the
   past to settle and create dwellings." (surely could be improved, just an
   example).

There are lots of unanswered questions in wikidata, and probably, by
judging from the current state of the data, not enough editors to manage to
look through all of it.

Another issue that comes to mind: what about contradictions between an
article and a wikidata object? How is the relationship between the articles
and wikidata? Apparently, you can only associate on article to one item, so
this suggests a strong relationsship, but clearly there are articles in
many languages, and there will be lots of contradictions between those
languages (because there are lots of articles, and because nearly noone
cross checks different languages). IMHO it would have been a better idea to
have a less strong relationship, something like "this article has
information about this item" (and hence allow multiple articles to be
associated with an object) rather than what it seems conceptually to be
thought of now (the articles and this wikidata object deal with the same
thing, are the same thing, here in article form and here as mathematical
relations).
For me these are just more indications that we should not base automatic
edits on this source at the moment.

Generally, in OSM we are proud about the high quality of our data, because
the mappers base their work on first hand experience and human judgement,
and we shouldn't give these up just to gain a little more editing
convenience (IMHO).

We do have very strict guidelines for imports and automated edits, and IMHO
this new features falls into the second category...

Cheers,
Martin

[1] http://wiki.openstreetmap.org/wiki/Automated_edits
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD news: v1.9.6 released

[Minh Nguyen]

Martin Koppenhoefer  gmail.com> writes:

> 
> 
> sent from a phone
> 
> > Il giorno 10 giu 2016, alle ore 01:58, Minh Nguyen 
nguyen.cincinnati.oh.us> ha scritto:
> > 
> > 
> > * “Administrative territorial entity” is the superset of “human
> > settlements”. This superset has 2,225,880 items. [2] You’d see these items
> > on place POIs and boundary=administrative boundary relations.
> > 
> > * “Human-geographic territorial entity” is the superset of “administrative
> > territorial entity” that also includes cultural and purely political
> > boundaries. That superset is less than 1% larger (2,245,631)
> 
> is this your interpretation or is it explicitly defined like this? I'm
astonished that these 2 concepts are
> supposedly structured vertically and not horizontally in wikidata 

 is defined in Wikidata as a subset
of . I agree that this is a suboptimal
relationship – anyone can edit, I suppose – but it shouldn’t affect the
quality of the `wikidata` tags that iD comes up with.

> > . [3] Something
> > that’s a human-geographic territorial entity but not an administrative
> > territorial entity probably shouldn’t be mapped in OSM in the first place.
> 
> I dissent, OSM is about humans observing their environment and mapping it.
There's no requirement for
> administrative independence. Administrative territorial entities on the
other hand are set up
> following different logics and rules, sometimes differing from the actual
social-geographic reality.

I should’ve been clearer in my wording. The distinction between an
“administrative territorial entity” and any other “human-geographic
territorial entity” in Wikidata is based not on administrative independence
but rather on whether the area within the territory is administered
differently than the area outside of the territory.

An example of a non-administative territorial entity would be a “statistical
territorial entity” , such as a
Census-Designated Place in the United States
. I guess I can’t speak to mapping
practices in every country. But in perrennial discussions on talk-us, the
consensus has been to phase out or retag the TIGER-imported administrative
boundaries for CDPs, on the grounds that the boundaries are a statistical
fiction that can’t be observed in any way on the ground. I see no daylight
between Wikidata and OSM when it comes to the difference between
administrative and non-administrative boundaries, even if the terminology
differs somewhat.

Also, I personally expect that this iD feature will wind up affecting
landmarks and non-place POIs more than boundary relations.

> > 
> > Rather than searching Wikidata, iD essentially only follows the explicit
> > link from the user-specified Wikipedia article to its Wikidata item. The
> > presence of this link indicates that Wikipedians currently consider the item
> > to be synonymous.
> 
> the presence of the link does not indicate that they're seen as
synonymous, but that it might be useful to
> look at it, and that there is some connection between the two, but that's
not the same as synonymous 

I think it’s more than that: I think we can agree that the English Wikipedia
article “United States” and the French Wikipedia article “États-Unis”
discuss the same concept (ignoring any content-level differences). In order
for the two articles to link to each other in the “In other languages”
section, they have to share exactly one Wikidata item in common. This is
enforced at a technical level for all Wikipedia languages. (This is
Wikidata’s most important feature: serving as a replacement for the old
“interwiki links” system.)

Increasingly, Wikipedias are relying on Wikidata to supply information for
infoboxes and other elements. For example, the municipality infoboxes on
some Wikipedias automatically display the “population” property of the
Wikidata item linked to the article. It would make no sense for a city
article to state a population based on a “useful to look at” relationship.

-- 
Minh Nguyen 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD news: v1.9.6 released

[Martin Koppenhoefer]

sent from a phone

> Il giorno 10 giu 2016, alle ore 01:58, Minh Nguyen 
>  ha scritto:
> 
> 
> * Currently, Wikidata has 1,775,365 items tagged as “human settlements”. [1]
> You’d expect to see these items tagged on place POIs, including cities and
> villages but also places that don’t have boundaries (like unincorporated
> places).


seems fine ("boundaries" meant as formally defined legal boundaries, because 
any settlement will likely have a boundary of some kind)


> 
> * “Administrative territorial entity” is the superset of “human
> settlements”. This superset has 2,225,880 items. [2] You’d see these items
> on place POIs and boundary=administrative boundary relations.
> 
> * “Human-geographic territorial entity” is the superset of “administrative
> territorial entity” that also includes cultural and purely political
> boundaries. That superset is less than 1% larger (2,245,631)


is this your interpretation or is it explicitly defined like this? I'm 
astonished that these 2 concepts are supposedly structured vertically and not 
horizontally in wikidata 



> . [3] Something
> that’s a human-geographic territorial entity but not an administrative
> territorial entity probably shouldn’t be mapped in OSM in the first place.


I dissent, OSM is about humans observing their environment and mapping it. 
There's no requirement for administrative independence. Administrative 
territorial entities on the other hand are set up following different logics 
and rules, sometimes differing from the actual social-geographic reality.



> 
> Rather than searching Wikidata, iD essentially only follows the explicit
> link from the user-specified Wikipedia article to its Wikidata item. The
> presence of this link indicates that Wikipedians currently consider the item
> to be synonymous.


the presence of the link does not indicate that they're seen as synonymous, but 
that it might be useful to look at it, and that there is some connection 
between the two, but that's not the same as synonymous 


cheers,
Martin 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD news: v1.9.6 released

[Minh Nguyen]

Martin Koppenhoefer  gmail.com> writes:

> 
> 
> sent from a phone
> 
> > Il giorno 09 giu 2016, alle ore 02:23, Minh Nguyen 
nguyen.cincinnati.oh.us> ha scritto:
> > 
> > If I understand correctly, you’re referring to a situation where, for
> > instance, Wikipedia editors have opted to discuss both an “administrative
> > territorial entity” and its government in the same article, whereas Wikidata
> > editors have decided to separate the concepts into two different items
> 
> at least the former is very common for cities I believe (didn't conduct a
scientific study about it though),
> I'm not so sure how common the latter is, my impression when I last looked
was that many of the socio
> geographic entities are still missing in wikidata (so rather than using 2
distinct objects there is one
> which corresponds to a part of the article), their editors seem to have a
preference for political
> administrative entities.

I’m not sure whether we’re talking about the same concepts, so here are some
data points about the kinds of Wikidata items that iD might end up
associating with place POIs or boundary relations (among the many kinds of
features that can be tagged with `wikipedia` and `wikidata`):

* Currently, Wikidata has 1,775,365 items tagged as “human settlements”. [1]
You’d expect to see these items tagged on place POIs, including cities and
villages but also places that don’t have boundaries (like unincorporated
places).

* “Administrative territorial entity” is the superset of “human
settlements”. This superset has 2,225,880 items. [2] You’d see these items
on place POIs and boundary=administrative boundary relations.

* “Human-geographic territorial entity” is the superset of “administrative
territorial entity” that also includes cultural and purely political
boundaries. That superset is less than 1% larger (2,245,631). [3] Something
that’s a human-geographic territorial entity but not an administrative
territorial entity probably shouldn’t be mapped in OSM in the first place.

Rather than searching Wikidata, iD essentially only follows the explicit
link from the user-specified Wikipedia article to its Wikidata item. The
presence of this link indicates that Wikipedians currently consider the item
to be synonymous. To get a better sense of how widespread these iD-generated
tags would be, the queries above could be filtered to those items that have
sitelinks. Unfortunately, that particular query times out on the Wikidata
Query Service. (It’s a great service, but like overpass turbo, it has its
limits.)

> > Wikipedia tends to be proactive about creating separate articles when
> > there’s a notable distinction between the various meanings of a name, but
> > Wikidata follows suit almost as a rule. So there is a 1:1 correspondence
> > between the various meanings of China on the English Wikipedia and the
> > various Wikidata items for those meanings. `wikipedia=en:China` maps to
> > , which is for the People's Republic. If
> > the mapper had a different definition of China in mind, both the `wikipedia`
> > and `wikidata` tags would reflect that.
> 
> clearly the china article in wp/en has a much broader scope than the
linked Wikidata item people's republic
> of china. The latter starts looking at things from 1949, Wikipedia "China"
some thousand years earlier.

The Wikipedia article provides historical context, including historical
borders, as any encyclopedia article on this topic should. By contrast, the
Wikidata item is more focused on the present, much the way an OSM boundary
relation should reflect the present. (The historical boundaries go in
OpenHistoricalMap, after all.) Both Wikipedia and Wikidata have entries for
other definitions of China. [4] To me, this suggests that the Wikidata item
more naturally fits an OSM feature than the Wikipedia article does.

[1] http://tinyurl.com/h9p4qb7
[2] http://tinyurl.com/zvrft74
[3] http://tinyurl.com/zuzcvly
[4] https://en.wikipedia.org/wiki/China_(disambiguation) and the Wikidata
items linked to the articles linked from that page

-- 
Minh Nguyen 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD news: v1.9.6 released

[Martin Koppenhoefer]

sent from a phone

> Il giorno 09 giu 2016, alle ore 02:23, Minh Nguyen 
>  ha scritto:
> 
> If I understand correctly, you’re referring to a situation where, for
> instance, Wikipedia editors have opted to discuss both an “administrative
> territorial entity” and its government in the same article, whereas Wikidata
> editors have decided to separate the concepts into two different items



at least the former is very common for cities I believe (didn't conduct a 
scientific study about it though), I'm not so sure how common the latter is, my 
impression when I last looked was that many of the socio geographic entities 
are still missing in wikidata (so rather than using 2 distinct objects there is 
one which corresponds to a part of the article), their editors seem to have a 
preference for political administrative entities.


> 
> Wikipedia tends to be proactive about creating separate articles when
> there’s a notable distinction between the various meanings of a name, but
> Wikidata follows suit almost as a rule. So there is a 1:1 correspondence
> between the various meanings of China on the English Wikipedia and the
> various Wikidata items for those meanings. `wikipedia=en:China` maps to
> , which is for the People's Republic. If
> the mapper had a different definition of China in mind, both the `wikipedia`
> and `wikidata` tags would reflect that.


clearly the china article in wp/en has a much broader scope than the linked 
Wikidata item people's republic of china. The latter starts looking at things 
from 1949, Wikipedia "China" some thousand years earlier.


cheers,
Martin 


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

Re: [OSM-talk] iD news: v1.9.6 released

[Coleman McCormick]

Bryan - This is an awesome release, great work by yourself and all the
contributing team!

-- 
Coleman McCormick
@colemanm

On June 8, 2016 at 11:59:11, Bryan Housel (br...@7thposition.com) wrote:

> *iD v1.9.6* was released June 7 2016 and is now available for editing on
> openstreetmap.org
>
> The release includes:
> - Embed interactive Mapillary JS viewer (worked on by Peter Neubauer and
> Kushan Joshi)
> - Add “grill” as search term for `amenity=bbq` preset (worked on by
> Manfred Brandl)
> - When setting Wikipedia field value, also set corresponding Wikidata tag
> (worked on by Minh Nguyễn)
>
> Changelog:
> https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#196
>
> These are some very cool new features that we’ve been waiting a long time
> for — please share!
>
> Twitter:
>   v1.9.6: https://twitter.com/bhousel/status/740557505634422784
>   Wikidata: https://twitter.com/bhousel/status/740567649894031369
>   Mapillary JS:  https://twitter.com/Mapbox/status/740210415641198592
>
> Blog:  https://www.mapbox.com/blog/id-mapillary-js/
>
>
> Thanks,
> Bryan
>
> Follow me on Twitter https://twitter.com/bhousel, or follow the iD
> project on GitHub https://github.com/openstreetmap/iD for more iD tips
> and updates.
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD news: v1.9.6 released

[Minh Nguyen]

Martin Koppenhoefer  gmail.com> writes:

> 
> 
> sent from a phone
> 
> Il giorno 08 giu 2016, alle ore 18:44, Michael Reichert 
gmx.net> ha scritto:
> 
> >> Am 08.06.2016 um 17:59 schrieb Bryan Housel:
> >> - When setting Wikipedia field value, also set corresponding Wikidata
tag (worked on by Minh Nguyễn)
> > 
> > Isn't this a kind of mechanical edit which should be discussed on this
> > mailing list *beforehand*?
> 
> I also see this critical, if I understood correctly what it means, as the
relationship between Wikipedia
> articles and wikidata items is not 1:1. Yes, the initial wikidata set has
been created from Wikipedia
> articles, but looking at a topic very important to osm, places and
administrative entities, you'll find
> that Wikipedia articles often cover both, a place and the administrative
entity for/of this place, but
> wikidata objects often do not cover both. Adding a wp link to a place
object (typically node) in osm can be
> correct while at the same time adding the wikidata object that corresponds
to the wp article would not be
> (because it refers to the administrative entity)

If I understand correctly, you’re referring to a situation where, for
instance, Wikipedia editors have opted to discuss both an “administrative
territorial entity” and its government in the same article, whereas Wikidata
editors have decided to separate the concepts into two different items, yet
one of the Wikidata items still links to the unified Wikipedia article. Can
you think of an item that would be problematic in this way? How often would
this situation come up on newly tagged features?

In practice, Wikidata gives the various Wikipedia editions a strong
incentive to agree on the scope of an item, because a Wikidata item can only
link to one Wikipedia article per language and a Wikipedia article can only
link to one Wikidata item.

Wikipedia tends to be proactive about creating separate articles when
there’s a notable distinction between the various meanings of a name, but
Wikidata follows suit almost as a rule. So there is a 1:1 correspondence
between the various meanings of China on the English Wikipedia and the
various Wikidata items for those meanings. `wikipedia=en:China` maps to
, which is for the People's Republic. If
the mapper had a different definition of China in mind, both the `wikipedia`
and `wikidata` tags would reflect that.

In another example, the English Wikipedia article
 has one section for
each highway numbered 980 in the U.S. state of Arkansas. This article is
linked to one Wikidata item: . If
another Wikipedia edition wanted to inflate its article count by creating a
separate stub article for each of these highways, none of these stub
articles could be linked to Q2431651. If you were to tag
`wikipedia=en:Arkansas Highway 980`, iD would add `wikidata=Q2431651`. But
if you were to tag `wikipedia=es:Carretera Arkansas 980 (condado de Van
Buren)`, iD would add no `wikidata` tag.

It would be far more problematic if iD were to automatically edit Wikidata,
adding the edited OSM node’s ID to the item’s statements, since a) OSM IDs
are even more unstable than Wikipedia article titles, and b) OSM can
represent even a single place with multiple features (for example, a
boundary relation and a place POI with role=label, or a 3D building relation
with a building area with role=outline). Fortunately, there are no plans to
do automatically edit Wikidata from within iD.

Finally, I think this feature (and hopefully similar features in other
editors) would help us ensure that, if a real mechanical edit to introduce
Wikidata tags [1] ever gets approved, it would be a smaller, one-time affair
instead of a larger, recurring task.

[1] http://wiki.openstreetmap.org/wiki/Mechanical_Edits/wikidata and
previous threads on this list

-- 
Minh Nguyen 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD news: v1.9.6 released

[Martin Koppenhoefer]

 

sent from a phone

Il giorno 08 giu 2016, alle ore 18:44, Michael Reichert  ha 
scritto:

>> Am 08.06.2016 um 17:59 schrieb Bryan Housel:
>> - When setting Wikipedia field value, also set corresponding Wikidata tag 
>> (worked on by Minh Nguyễn)
> 
> Isn't this a kind of mechanical edit which should be discussed on this
> mailing list *beforehand*?


I also see this critical, if I understood correctly what it means, as the 
relationship between Wikipedia articles and wikidata items is not 1:1. Yes, the 
initial wikidata set has been created from Wikipedia articles, but looking at a 
topic very important to osm, places and administrative entities, you'll find 
that Wikipedia articles often cover both, a place and the administrative entity 
for/of this place, but wikidata objects often do not cover both. Adding a wp 
link to a place object (typically node) in osm can be correct while at the same 
time adding the wikidata object that corresponds to the wp article would not be 
(because it refers to the administrative entity)

cheers,
Martin 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD news: v1.9.6 released

[Simone Cortesi]

On Wed, Jun 8, 2016 at 11:13 PM, Andy Mabbett  wrote:
>> Naturally (see previous wikidata discussions) it is questionable why it is
>> necessary to add a tag that can automatically be determined from the other
>> attributes of the object (as this feature proves without doubt).
>
> As answered in those self-same discussions: the Wikipedia link is
> volatile, the Wikidata ID is virtually permanent. The latter is also
> not language-centric.

+1

-- 
-S

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

Re: [OSM-talk] iD news: v1.9.6 released

[Andy Mabbett]

On 8 June 2016 at 21:23, Simon Poole  wrote:

> Naturally (see previous wikidata discussions) it is questionable why it is
> necessary to add a tag that can automatically be determined from the other
> attributes of the object (as this feature proves without doubt).

As answered in those self-same discussions: the Wikipedia link is
volatile, the Wikidata ID is virtually permanent. The latter is also
not language-centric.

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

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

Re: [OSM-talk] iD news: v1.9.6 released

[Andy Mabbett]

On 8 June 2016 at 16:59, Bryan Housel  wrote:

> iD v1.9.6 was released June 7 2016 and is now available for editing on
> openstreetmap.org
>
> The release includes:

> - When setting Wikipedia field value, also set corresponding Wikidata tag
> (worked on by Minh Nguyễn)

This is excellent news; thank you.

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

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

Re: [OSM-talk] iD news: v1.9.6 released

[Dave F]

It's only adding them to the single entity that's selected, killing two 
birds with one stone.


It's good time saver

Dave

On 08/06/2016 17:44, Michael Reichert wrote:

Hi Bryan,

Am 08.06.2016 um 17:59 schrieb Bryan Housel:

- When setting Wikipedia field value, also set corresponding Wikidata tag 
(worked on by Minh Nguyễn)

Isn't this a kind of mechanical edit which should be discussed on this
mailing list *beforehand*?

https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct

Best regards

Michael




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




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD news: v1.9.6 released

[Simon Poole]

The way I understand it, it simply adds an extra tag if the user adds a
wikimedia tag, don't seriously think that counts as a mechanical edit in
the sense of our guidelines.

Naturally (see previous wikidata discussions) it is questionable why it
is necessary to add a tag that can automatically be determined from the
other attributes of the object (as this feature proves without doubt).

Simon

Am 08.06.2016 um 18:44 schrieb Michael Reichert:
> Hi Bryan,
>
> Am 08.06.2016 um 17:59 schrieb Bryan Housel:
>> - When setting Wikipedia field value, also set corresponding Wikidata tag 
>> (worked on by Minh Nguyễn)
> Isn't this a kind of mechanical edit which should be discussed on this
> mailing list *beforehand*?
>
> https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
>
> Best regards
>
> Michael
>
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk





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

Re: [OSM-talk] iD news: v1.9.6 released

[Hans De Kryger]

https://github.com/openstreetmap/iD/pull/2732

Regards,
Hans
On Jun 8, 2016 9:47 AM, "Michael Reichert"  wrote:

> Hi Bryan,
>
> Am 08.06.2016 um 17:59 schrieb Bryan Housel:
> > - When setting Wikipedia field value, also set corresponding Wikidata
> tag (worked on by Minh Nguyễn)
>
> Isn't this a kind of mechanical edit which should be discussed on this
> mailing list *beforehand*?
>
> https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
>
> Best regards
>
> Michael
>
>
> --
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
> ausgenommen)
> I prefer GPG encryption of emails. (does not apply on mailing lists)
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD news: v1.9.6 released

[Michael Reichert]

Hi Bryan,

Am 08.06.2016 um 17:59 schrieb Bryan Housel:
> - When setting Wikipedia field value, also set corresponding Wikidata tag 
> (worked on by Minh Nguyễn)

Isn't this a kind of mechanical edit which should be discussed on this
mailing list *beforehand*?

https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)




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

[OSM-talk] iD news: v1.9.6 released

[Bryan Housel]

iD v1.9.6 was released June 7 2016 and is now available for editing on 
openstreetmap.org 

The release includes:
- Embed interactive Mapillary JS viewer (worked on by Peter Neubauer and Kushan 
Joshi)
- Add “grill” as search term for `amenity=bbq` preset (worked on by Manfred 
Brandl)
- When setting Wikipedia field value, also set corresponding Wikidata tag 
(worked on by Minh Nguyễn)

Changelog: https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#196 


These are some very cool new features that we’ve been waiting a long time for — 
please share!

Twitter:  
  v1.9.6: https://twitter.com/bhousel/status/740557505634422784 

  Wikidata: https://twitter.com/bhousel/status/740567649894031369 

  Mapillary JS:  https://twitter.com/Mapbox/status/740210415641198592 


Blog:  https://www.mapbox.com/blog/id-mapillary-js/ 



Thanks,
Bryan

Follow me on Twitter https://twitter.com/bhousel , 
or follow the iD project on GitHub https://github.com/openstreetmap/iD 
 for more iD tips and updates.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk