Re: [Tagging] Part/whole confusion with Wikidata tag, and the need for enveloping parts into a whole
sent from a phone > On 8. Aug 2018, at 02:22, Yuri Astrakhan wrote: > > If we duplicated everything, than each part of a railroad station should have > duplicate web site URL, hours of operation, operator name, and tons of other > info. I don’t know what situation you are referring to, and how it is currently mapped, but if there are different parts mapped, there will usually be a reason for it, and different websites, operation hours (never mapped these myself), operators and other info might be the reason for splitting it. Maybe the parts of the station shouldn’t be mapped as if they were stations on their own, but as parts of a station? Usually tags go on the object they apply to, tags for a station go on the station, tags for a part of a station go on the part, etc. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Part/whole confusion with Wikidata tag, and the need for enveloping parts into a whole
sent from a phone > On 8. Aug 2018, at 00:35, Yuri Astrakhan wrote: > > For this specific case, the railroad stations consumer would probably want a > single raiway station, not multiples, so they are easier to analyze, easier > to query by matching it up with wikidata, etc. For railway stations I would agree that it is desirable to have a single station object for a single station (ignoring for a moment double and triple stations and how to link them, e.g. internally connected metro stations on different lines). My answer is a station area for the whole station, but many mappers are categorically refusing this and advocate nodes only (IMHO strange for something as big as a station). An area would solve a lot of issues. I am not against making our data easier to consume for others, but the priority should be making life easiest for mappers. > Railroad station can have multiple parts, but so do many other things, and we > tend to put common things in a relation for them. Why would you want railroad > stations tagged differently, and duplicate the same wikidata tag on every > part of it? it really depends how wikidata has the individual station represented, is it one or several objects? Do they have a collector object for the parts, etc.? It’s not as if all stations are codified the same in wikidata, or are they? Has wikidata already found a stable structure how they represent railway stations or will it maybe change continuously? Even if everything (wikidata <-> OSM) would be consistent today, tomorrow it would either be inconsistent or outdated ;-) I agree there is room for improvement on all sides, but it cannot be answered once for all. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Part/whole confusion with Wikidata tag, and the need for enveloping parts into a whole
Hi peterkrauss, Am 08.08.2018 um 03:18 schrieb Nelson A. de Oliveira: > On Tue, Aug 7, 2018 at 9:22 PM, Yuri Astrakhan > wrote: >> Nelson, there are several places I have seen in our wiki, e.g. [1], which >> discourage duplication of information if it can be avoided. name is a >> special case - it helps mappers to quickly identify what the object >> represents. If we duplicated everything, than each part of a railroad >> station should have duplicate web site URL, hours of operation, operator >> name, and tons of other info. Having duplicates lead to inconsistencies, >> harder to maintain, etc. For example, if two parts of the station have >> different hours of operation - is that a mistake (someone forgot to update >> both), or is it intentional? Which one of two is correct? Having a rule to >> keep common info in a relation unless it is different makes data more >> valuable and less error-prone. > > I was talking about any object. > And I fail to see what exactly is *wrong* in having multiple parts of > an object with the same wikidata; it's not really duplication. > > We don't create relations to avoid repeating surface, lanes, name, etc > on every part of a highway, for example. > Using relations also has the drawback of creating complexity for most > of the users in OSM (and sometimes even for the data consumers), > specially if the main objective here is to solely avoid non-unique > wikidata values. I second that. Our data model is different from the data model of Wikidata. It is common practice when mapping railway lines to add tags which refer to a railway line (as a infrastructure, not the services using it) to the ways. Example: Tags of a way railway=rail name=Linke Rheinstrecke (English: Left Rhine Railway) wikipedia=de:Linke Rheinstrecke wikidata=Q… operator=DB Netz AG This duplication is common practice in OSM even if it does look wrong to proponents of the pure doctrine how to design a database. OSM is not modified by a frontend application hiding the database model from the user. Instead, it is edited by humans how have to understand the database model. Many of them already struggle with understanding relations at all. That's why we do not create a relation to collect all objects having the same operator. Instead, we add operator= to all the objects. Such relations are called "collective relations" and not welcome. https://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories Route relations for railway lines (infrastructure, not the services) are some of the exceptions from that rule. OSM is a project with a lot of data. If we represented all much more of the information which is currently "duplicated" as tags on individual objects, processing of OSM data would become more difficult, expensive and slower due to the many JOINs (I assume you are more familiar with database terminology). 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 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Part/whole confusion with Wikidata tag, and the need for enveloping parts into a whole
On Wednesday 08 August 2018, peterkrauss wrote: > > > has been an important point of > > critique of the whole 'adding wikidata IDs to OSM' movement. You > > can read this up in the previous discussion here and in talk. > > Can you send the main links? No, i can't. There is a large number of discussions on the topic of adding Wikidata IDs in OSM (which is significantly less invasive than this attempt to shape OSMs data model to the needs of Wikidata) in several channels and i did not keep track of all of them. You can find quite a bit of discussion by searching for subjects containing 'wikidata' in talk in the second half of 2017. Most of this was ultimately non-productive because the Wikidata supporters in the discussion did not make any serious attemts to actually take into account the fundamental critique of their intentions. In most cases the discussion progressed in a similar way as here with Wikidata proponents being firmly set in their world view and having no perception of the fundamental differences between that and the way OSM handles things and as a result attempting to bulldoze over OSM with euphemisms like "pragmatical view". If any Wikidata fan really wants to engage in a productive and balanced discussion on the interrelationship between the projects you would need to approach this on a very basic level and accept that none of the fundamental assumptions Wikidata is founded on is necessarily shared by OSM. And as Martin Koppenhoefer said - if you ignore these things you only have two options: Trying to forcefully change OSM to adjust to the Wikidata world view or adjusting Wikidata to adopt OSMs views. Even if one of those options seems feasible (which i would not necessarily disagree with) it would be an act of imperialism with all the consequences this usually brings with it. > PS: ideal is to summarize a list of topics and its "agreement vs > under-discussion" status... > something like > https://wiki.openstreetmap.org/wiki/Wikidata/Critical_topics I would strongly suggest you do not try to imply that what you state there represents an agreement of any kind. What you have written there seems to indicate a lack of understanding of how OSM works and therefore seems to form an attempt to impose working principles you find desirable onto OSM. Don't do that. If you want to create such a wiki page to describe your subjective perception of the situation that is fine - but you should indicate it as such. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Part/whole confusion with Wikidata tag, and the need for enveloping parts into a whole
On Tue, Aug 7, 2018 at 9:22 PM, Yuri Astrakhan wrote: > Nelson, there are several places I have seen in our wiki, e.g. [1], which > discourage duplication of information if it can be avoided. name is a > special case - it helps mappers to quickly identify what the object > represents. If we duplicated everything, than each part of a railroad > station should have duplicate web site URL, hours of operation, operator > name, and tons of other info. Having duplicates lead to inconsistencies, > harder to maintain, etc. For example, if two parts of the station have > different hours of operation - is that a mistake (someone forgot to update > both), or is it intentional? Which one of two is correct? Having a rule to > keep common info in a relation unless it is different makes data more > valuable and less error-prone. I was talking about any object. And I fail to see what exactly is *wrong* in having multiple parts of an object with the same wikidata; it's not really duplication. We don't create relations to avoid repeating surface, lanes, name, etc on every part of a highway, for example. Using relations also has the drawback of creating complexity for most of the users in OSM (and sometimes even for the data consumers), specially if the main objective here is to solely avoid non-unique wikidata values. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Part/whole confusion with Wikidata tag, and the need for enveloping parts into a whole
On Wed, Aug 8, 2018 at 1:53 AM Nelson A. de Oliveira wrote: > On Tue, Aug 7, 2018 at 7:35 PM, Yuri Astrakhan > wrote: > > Why would you want railroad stations tagged differently > > and duplicate the same wikidata tag on every part of it? > > Having the same "wikidata" on every part representing an object seems > to be as correct as having "name" on every part of a highway, river, > etc. > > Nelson, there are several places I have seen in our wiki, e.g. [1], which discourage duplication of information if it can be avoided. name is a special case - it helps mappers to quickly identify what the object represents. If we duplicated everything, than each part of a railroad station should have duplicate web site URL, hours of operation, operator name, and tons of other info. Having duplicates lead to inconsistencies, harder to maintain, etc. For example, if two parts of the station have different hours of operation - is that a mistake (someone forgot to update both), or is it intentional? Which one of two is correct? Having a rule to keep common info in a relation unless it is different makes data more valuable and less error-prone. [1]: https://wiki.openstreetmap.org/wiki/Relation:route_master#Other_useful_tags ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Part/whole confusion with Wikidata tag, and the need for enveloping parts into a whole
On Tue, Aug 7, 2018 at 7:35 PM, Yuri Astrakhan wrote: > Why would you want railroad stations tagged differently > and duplicate the same wikidata tag on every part of it? Having the same "wikidata" on every part representing an object seems to be as correct as having "name" on every part of a highway, river, etc. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Part/whole confusion with Wikidata tag, and the need for enveloping parts into a whole
Martin, the goal is not to make OSM fit to Wikidata needs (I'm not even sure what those needs are). The goal is to make it easier to consume OSM data. Pretty much every single OSM data consumer I spoke with complained of how difficult it is to use OSM data - let's try to help them. For this specific case, the railroad stations consumer would probably want a single raiway station, not multiples, so they are easier to analyze, easier to query by matching it up with wikidata, etc. Railroad station can have multiple parts, but so do many other things, and we tend to put common things in a relation for them. Why would you want railroad stations tagged differently, and duplicate the same wikidata tag on every part of it? On Wed, Aug 8, 2018 at 12:13 AM Martin Koppenhoefer wrote: > > > sent from a phone > > > On 7. Aug 2018, at 18:36, peterkrauss > wrote: > > > > It seems the basic premise, > > "Wikidata references should be unique as possible", > > I will use your phrase from here. > > > I don’t see the need for this, what is the problem with having 2 osm > objects pointing to the same wikidata object? > The alternative seems to be either modify wikidata so that it suits OSMs > needs, or OSM so that it fits with the existing wikidata structure. > > cheers, > Martin > > > ___ > 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/whole confusion with Wikidata tag, and the need for enveloping parts into a whole
Em 2018-08-07 05:00, Christoph Hormann escreveu: On Monday 06 August 2018, peterkrauss wrote: Seems a commom quality problem of part/whole confusion in the Wikidata attribution or OSM's POI reference... And where there are a need for "enveloping parts into a whole". [...] The fact that there is no agreement on the nature of the relationship between Wikidata objects and OSM objects hum... Is time to do some agreement (!), use of Wikidata is growing, and will be difficult in the future to review the caos. has been an important point of critique of the whole 'adding wikidata IDs to OSM' movement. You can read this up in the previous discussion here and in talk. Can you send the main links? PS: ideal is to summarize a list of topics and its "agreement vs under-discussion" status... something like https://wiki.openstreetmap.org/wiki/Wikidata/Critical_topics OSM aims to map based on local verifiability. Therefore many things we map in OSM have no equivalent in Wikidata (because they do not satisfy the criteria for inclusion there) and many things in Wikidata cannot be mapped verifiably in OSM. The point is to separate things that are delimited and things that are not. We have good definition for 90% of "type=boundary" and 90% of "type=route"... The best is perhaps to begin with a pragmatical view, and only later discuss the problematic ones. And inventing some kind of collector relation that collects all objects that by some wikidata interpretation 'belong to' a certain Wikidata ID and thereby implements a 1:n relationship would not change that (it would just be pointless non-maintainable, non-verifiable dead weight in the database). My favourite example for this is the Amazon rainforest (but you can use other large eco-regions like the Sahara desert as well). You won't be able to verifiably map the Amazon rain forest in OSM as an entity. What we aim to do in OSM is to accurately map the woodlands of South America - which is still a very long way to go. But if this should happen it will happen locally because natural=wood/landuse=forest is locally verifiable while the abstract concept of naming some of this woodland the Amazon rainforest is not. ... All make sense, but my suggestion is only to annotate it for a future debate, after resolved the pragmatical cases, where no ambiguity exist. PS: about "object vs field" debate, see the this 1992's article http://www.geog.ucsb.edu/~good/papers/172.pdf -- Peter Krauss ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Part/whole confusion with Wikidata tag, and the need for enveloping parts into a whole
sent from a phone > On 7. Aug 2018, at 18:36, peterkrauss wrote: > > PS: "type=site" was classified with status "abandoned", at > https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site yes, someone set the proposal to abandoned some months ago, but the site relation is one of the mostly used relations and numbers are still growing, maybe it should be set to in use. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Part/whole confusion with Wikidata tag, and the need for enveloping parts into a whole
sent from a phone > On 7. Aug 2018, at 18:36, peterkrauss wrote: > > It seems the basic premise, > "Wikidata references should be unique as possible", > I will use your phrase from here. I don’t see the need for this, what is the problem with having 2 osm objects pointing to the same wikidata object? The alternative seems to be either modify wikidata so that it suits OSMs needs, or OSM so that it fits with the existing wikidata structure. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Part/whole confusion with Wikidata tag, and the need for enveloping parts into a whole
Il giorno mar 7 ago 2018 alle ore 18:37 peterkrauss < pe...@openstreetmap.com.br> ha scritto: > > > > > Using route or site relations when appropriate is a good solution. > > Ok, lets elect the OSM Map Features that are Wikidata-good-solutions > > * "type=boundary" (6,525,236 elements) > > * "type=route" (30,257,877 elements!) and complements as > "type=route_master". > > * ... more good solutions? > > AssociatedStreet suggests to collect the etymology of the road name https://wiki.openstreetmap.org/wiki/Relation:associatedStreet > > PS: "type=site" was classified with status "abandoned", at > https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Part/whole confusion with Wikidata tag, and the need for enveloping parts into a whole
Em 2018-08-06 20:46, François Lacombe escreveu: Hi Peterkrauss, Thanks François, important topics... I second the need you mention of a relation in a whole. Wikidata references should be unique as possible in the db. It seems the basic premise, "Wikidata references should be unique as possible", I will use your phrase from here. There are more cases in of sample-country DE where it is not unique, https://wiki.openstreetmap.org/wiki/User:Krauss/Wikidata-question2 Using route or site relations when appropriate is a good solution. Ok, lets elect the OSM Map Features that are Wikidata-good-solutions * "type=boundary" (6,525,236 elements) * "type=route" (30,257,877 elements!) and complements as "type=route_master". * ... more good solutions? PS: "type=site" was classified with status "abandoned", at https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site All the best François 2018-08-06 23:10 GMT+02:00 peterkrauss : Hi, Seems a commom quality problem of part/whole confusion in the Wikidata attribution or OSM's POI reference... And where there are a need for "enveloping parts into a whole". Example: * The railway-whole concept, Anhalt Railway https://www.wikidata.org/wiki/Q319837 [1] * The railway-parts concept, a fragment of the Anhalt Railway, https://www.openstreetmap.org/way/539934418 [2] * The error: 197 fragments with the Q319837 concept * The need: a relation to "envelope Anhalt Railway" as a whole Details and more examples at https://wiki.openstreetmap.org/wiki/User:Krauss/Wikidata-question1 [3] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [4] Links: -- [1] https://www.wikidata.org/wiki/Q319837 [2] https://www.openstreetmap.org/way/539934418 [3] https://wiki.openstreetmap.org/wiki/User:Krauss/Wikidata-question1 [4] https://lists.openstreetmap.org/listinfo/tagging -- Peter Krauss ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Part/whole confusion with Wikidata tag, and the need for enveloping parts into a whole
Christoph, you are right that some loosely defined areas like rainforests may not have exact boundaries. We can find limitations and issues in defining/naming/linking pretty much anything, e.g. see discussion for "[Tagging] place nodes for continents". That said, in a large number of cases, it is beneficial to data consumers to have a 1:1 mapping, e.g. for examples presented by Peter and François. We do not have to extend that approach to objects that it won't work well for. So if it makes sense, it is ok to have a "concept-level" relation that defines common properties, such as shared wikidata ID, perhaps a relevant Unesco Heritage ID, a URL, or the hours of operation. It would be a bit silly to repeat that info on every part of the location. And for other types of objects, especially the ones without a clear outline, perhaps it may not make sense to even add wikidata IDs at all. On Tue, Aug 7, 2018 at 11:04 AM Christoph Hormann wrote: > On Monday 06 August 2018, peterkrauss wrote: > > > > Seems a commom quality problem of part/whole confusion in the > > Wikidata attribution or OSM's POI reference... And where there are a > > need for "enveloping parts into a whole". > > > > [...] > > The fact that there is no agreement on the nature of the relationship > between Wikidata objects and OSM objects has been an important point of > critique of the whole 'adding wikidata IDs to OSM' movement. You can > read this up in the previous discussion here and in talk. > > OSM aims to map based on local verifiability. Therefore many things we > map in OSM have no equivalent in Wikidata (because they do not satisfy > the criteria for inclusion there) and many things in Wikidata cannot be > mapped verifiably in OSM. And inventing some kind of collector > relation that collects all objects that by some wikidata > interpretation 'belong to' a certain Wikidata ID and thereby implements > a 1:n relationship would not change that (it would just be pointless > non-maintainable, non-verifiable dead weight in the database). > > My favourite example for this is the Amazon rainforest (but you can use > other large eco-regions like the Sahara desert as well). You won't be > able to verifiably map the Amazon rain forest in OSM as an entity. > What we aim to do in OSM is to accurately map the woodlands of South > America - which is still a very long way to go. But if this should > happen it will happen locally because natural=wood/landuse=forest is > locally verifiable while the abstract concept of naming some of this > woodland the Amazon rainforest is not. > > -- > 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/whole confusion with Wikidata tag, and the need for enveloping parts into a whole
On Monday 06 August 2018, peterkrauss wrote: > > Seems a commom quality problem of part/whole confusion in the > Wikidata attribution or OSM's POI reference... And where there are a > need for "enveloping parts into a whole". > > [...] The fact that there is no agreement on the nature of the relationship between Wikidata objects and OSM objects has been an important point of critique of the whole 'adding wikidata IDs to OSM' movement. You can read this up in the previous discussion here and in talk. OSM aims to map based on local verifiability. Therefore many things we map in OSM have no equivalent in Wikidata (because they do not satisfy the criteria for inclusion there) and many things in Wikidata cannot be mapped verifiably in OSM. And inventing some kind of collector relation that collects all objects that by some wikidata interpretation 'belong to' a certain Wikidata ID and thereby implements a 1:n relationship would not change that (it would just be pointless non-maintainable, non-verifiable dead weight in the database). My favourite example for this is the Amazon rainforest (but you can use other large eco-regions like the Sahara desert as well). You won't be able to verifiably map the Amazon rain forest in OSM as an entity. What we aim to do in OSM is to accurately map the woodlands of South America - which is still a very long way to go. But if this should happen it will happen locally because natural=wood/landuse=forest is locally verifiable while the abstract concept of naming some of this woodland the Amazon rainforest is not. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Part/whole confusion with Wikidata tag, and the need for enveloping parts into a whole
Hi Peterkrauss, I second the need you mention of a relation in a whole. Wikidata references should be unique as possible in the db. Using route or site relations when appropriate is a good solution. All the best François 2018-08-06 23:10 GMT+02:00 peterkrauss : > Hi, > > Seems a commom quality problem of part/whole confusion in the Wikidata > attribution or OSM's POI reference... And where there are a need for > "enveloping parts into a whole". > > Example: > > * The railway-whole concept, Anhalt Railway > https://www.wikidata.org/wiki/Q319837 > > * The railway-parts concept, a fragment of the Anhalt Railway, > https://www.openstreetmap.org/way/539934418 > > * The error: 197 fragments with the Q319837 concept > > * The need: a relation to "envelope Anhalt Railway" as a whole > > Details and more examples at https://wiki.openstreetmap.org > /wiki/User:Krauss/Wikidata-question1 > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
