Talk:Collective Database Guideline
Additional attributes
Wouldn't the following sentence: "adding additional attributes by means of such a reference is not considered modifying the existing attributes of the referenced OpenStreetMap element." create a loophole in the license? Imagine some road tagged like this:
Now someone could come, verify the data, and add additional tags, e.g. oneway:proprietary_verification=not_a_oneway, and would modify the meaning of the existing tagging withour modifying existing attributes. --Dieterdreist (talk) 08:37, 22 September 2015 (UTC)
- I can't see how your example would not be considered modifying/overriding an existing attribute. SimonPoole (talk) 09:29, 23 September 2015 (UTC)
Understanding the Guideline
I am trying to understand the essence of this guideline in practical application, especially how this relates to the existing Horizontal Layers and Regional Cuts guidelines.
- The Horizontal Layers guideline is centered around the concepts of Feature Types and essentially says mixing data of the same feature type from OSM and other sources triggers share-alike but as long as the feature types are separate (i.e. either from OSM or another source but not mixed) it does not.
- The Regional Cuts guideline in addition clarifies that mixing feature types does not trigger share-alike if it is based on a geometric cutline which meets certain topological requirements.
Now it seems to me this guideline in addition says share-alike does not apply if you combine geometry data from OSM with attributes from other sources or the other way round. For example you practically could use all the road geometries in OSM but you do not find the highway tags of OSM fit your ideas of classification and want to apply your own classification system. Or you use the highway classes but find the OSM oneway tagging unreliable and use extensive GPS track data you have to determine oneway roads. It seems this guideline draft means to allow this universally without share-alike as long as each attribute is either from OSM or another source and you do not mix the data sources within the individual attributes.
What i am asking myself here is
- Is this a correct interpretation? If not it would be great if someone could point out my error.
- If this is correct, does this correctly represent the spirit of the license and the interests of the OSM community? I have serious doubts about this. The central idea behind share-alike is to ensure improvements and corrections of the data can be integrated back. It seems by allowing data users to freely discard individual attributes and replace them with their own assessment without share-alike this is prevented in a lot of cases, especially in cases where certain attributes are just starting to make it into OSM and where external contributions would be most useful. The most significant counteracting mechanism seems to be the volatile nature of feature identities in OSM which makes permanent references to features in OSM difficult. But this is just a hurdle to overcome by technical means for data users who want to do without share-alike. It hardly ever will be a serious obstacle. Or in other words this will open up OSM much further than current guidelines to an embrace, extend, and extinguish-approach.
- If this guideline is approved with this meaning it should probably be clarified if it can be combined with regional cuts, i.e. if you can for example combine OSM geometries with a combination of OSM and other source attributes based on a geometric cutline without triggering share-alike.
--Imagico (talk) 11:56, 7 October 2015 (UTC)
- In general I would agree with your conclusions. The original, non-published, text of the guideline referred to the original data elements, however that was not based on the text of the ODbL and would have been at odds with the horizontal layers guideline. The basic underlying issue is that the ODbL does not restrict which operations you can perform on a derivative database, so theorectically you can pair down and reduce such a database as much as you want. The horizontal layer, the regional cuts and the metadata guideline try to limit in how far you can combine such a reduced database with third party data and still claim "independce". SimonPoole (talk) 13:47, 7 October 2015 (UTC)
I'm not comfortable with this
The restaurant / phone number example rang the bell to me: What if the attribute is even more of interest to OSM than phone numbers? Cuisine, address, ... While I'm ok with 'horizontal layer guideline', I'm not with this one.--Yvecai (talk) 09:45, 18 June 2016 (UTC)
- The way the guideline works, OSM data is always subject to ODbL terms, so even if you somehow moved the cusine values to a third party dataset the cusine data would still be subject to the ODbL. And the other way around: if the hypothetical thrid party wanted to use their cusine data they can, but then cannot use any of the OSM values.SimonPoole (talk) 16:32, 18 June 2016 (UTC)
In a perfect world, if they find OSM good enough for the rest, they should contribute their cuisine tag back. That's the value in share-alike for us OSM, no? At least I would like to put the border closer to OSM benefit here. --Yvecai (talk) 06:49, 19 June 2016 (UTC)
how big is a region?
How big is a "region"? Can this be as small as a few square centimeters? Could we imagine a collective database of billions of microdatabases? --Dieterdreist (talk) 07:58, 22 June 2016 (UTC)