Martin Koppenhoefer <dieterdreist <at> gmail.com> writes: > > > sent from a phone > > > Il giorno 10 giu 2016, alle ore 01:58, Minh Nguyen <minh <at> 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
<https://www.wikidata.org/wiki/Q486972> is defined in Wikidata as a subset of <https://www.wikidata.org/wiki/Q56061>. 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” <https://www.wikidata.org/wiki/Q15042037>, such as a Census-Designated Place in the United States <https://www.wikidata.org/wiki/Q498162>. 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 <m...@nguyen.cincinnati.oh.us> _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
