[OSM-talk] You are still free to continue to use or interpret this tag as you see fit since OpenStreetMap does not have “banned features”

[Sören Reinecke]

I like warm e-mails like yours. It is a contrast to my always cold 
emails I write. And nice to see that you're sharing your vision with us. 
But your topic is broader and does not fit into my proposal sadly. But 
good that you speak up.

> The technology I am talking about is RDF. The graph database model,  > based on ontology and data triples. The OSM database backend is a > 
Conventional SQL data store, PostgreSQL. But we can store triples in > a 
relational database, the technology, with translators, schema > etc... 
is already there, developed and used. Even more, RDF is (or is > 
becoming) a W3C standard. The base for the new semantic web, isn't > OSM 
the semantic web for the mapping world of applications ?


Wiki link: https://en.wikipedia.org/wiki/Resource_Description_Framework
See also Wikidata (Wiki Data Items). That technology is used there (if I 
am not terribly wrong).


You're right and data customers already use that, components of it or 
just some ideas of it to tweak OSM data according to their needs what 
they will always need to do no matter what we do/how good the database 
is. We translate whole schemes to our own scheme for the sake of 
normalization, abstraction and reuse. E.g.we might translate 
Key:contact:phone and Key:phone to a column "phone"

E.g. The translation part. I think osm2pgsql provides a Lua interface to 
do exactly that:

contact:phone=+49 157 45345 --> 004915745345
phone=+49 157 45345 --> 004915745345

contact:phone=+4915745345 --> 004915745345
phone=+4915745345 --> 004915745345

contact:phone=+49-157-45345 --> 004915745345
phone=+49-157-45345 --> 004915745345

contact:phone=049-157-45345 --> 004915745345
phone=049-157-45345 --> 004915745345


We know that this POI is in Germany (this kind of scheme is discouraged 
on the wiki but few mappers tag like they want (not always a positive 
thing) and do not follow conventions)
contact:phone=0157 45345 --> 004915745345
phone=0157 45345 --> 004915745345

We know that this POI is in Germany (this kind of scheme is discouraged 
on the wiki but few mappers tag like they want (not always a positive 
thing) and do not follow conventions)
contact:phone=157 45345 --> 004915745345
phone=157 45345 --> 004915745345


E.g. the scheme part:

In the 'phone' column: `00<country code><dialing code (if 
present)><numerical identification code>` and clients for e.g. Italian 
numbers can simply add a '0' after <country code> before <dialing code 
(if present)>
Still this is not a good schema, let's do another one


| Country | phone number |

| de?????????????????? | 15745345?????????????? | clients convert it to --> 004915745345

| it?????????????????????? | 15745345?????????????? | clients convert it to --> 0031015745345

But still not ideal since harder to maintain. Better is a pipeline which 
preprocesses data before it gets its way into the database. This is also 
the usual way of how imports are carried out:

| phone ?? ?? ?? ?? ?? ?? ?????? |

| 004915745345???? | Before the pipeline --> contact:phone=+49 157 45345

| 0031015745345 | Before the pipeline --> phone=+31-157-45345

Much better. The conversion has been done by the import pipeline/process 
and clients don't need to interpret it because different clients lead to 
change of code in different places (e.g. in client A and in client B = 
harder maintainability). They will just need to fetch the phone number 
and call it straight now without the need of conversion definitions use 
inside the client, without any intermediate step. This is the way we 
work or are supposed to work.

As you see translations and schemes come together. Scheme is the syntax 
and translation is the way to get into the scheme (in case of imports).





On 17.03.21 00:10, Bert -Araali- Van Opstal wrote:
>  > Lots of good ideas and conservatism, all for good reasons in this > 
thread. > > S??ren has identified some points, in his own young rebel-ish 
style, > which concerns many, especially the data consumers and the 
renderers. > And I like his ideas, young and new visions is what drives 
 > innovation, brings creativeness and progress. > > Some more 
traditional, conservative or non-database specialist > mappers opinions. 
I also like many of those ideas, free as literally > free, any mapper 
can do whatever he wants, which creates for some > chaos, but also has 
driven OSM for what it is today. > > And although I am an ambassador for 
everything free and open source, > it would be not a good tactic to 
continue a campaign against > everything the big companies are doing. In 
the contrary, they have > proven that there commercial inspired "closed 
source" tactics, have > worked, reached masses. In the recent years what 
we generally see is > that they also embraced a concept of more open 
source politics. I > think we should embrace this, use their approaches, 
embrace them and > learn lessons from their successes and failures. > > 
It will be very hard, very likely impossible, to find a consensus > 
between both visions. My advise would be to look at a solution, > 
incorporating technology that is already gaining world wide support > 
and applications. Incorporate them in an OSM 2.0, with full > 
compatibility to OSM 1.0, the current philosophy. > > Let it be clear, I 
am not a database specialist, I do have yearlong > IT related 
professional experience, but I don't call myself an IT > expert. I am a 
mapper, an OSM contributor and try to be an ambassador > for it. SO in 
the following more technical context I might use some > less accurate 
statements, feel free to shoot at them or correct me. > > The technology 
I am talking about is RDF. The graph database model, > based on ontology 
and data triples. The OSM database backend is a > Conventional SQL data 
store, PostgreSQL. But we can store triples in > a relational database, 
the technology, with translators, schema > etc... is already there, 
developed and used. Even more, RDF is (or is > becoming) a W3C standard. 
The base for the new semantic web, isn't > OSM the semantic web for the 
mapping world of applications ? > > OSM 2.0 could just be a parallel 
triples store in our database. > Established tagging (thru the 
guidleines) will have their equivalent > in the triples store. Even 
competing schemes can have their place > their, like landcover/landuse 
versus natural/landuse. But it can > exist next to the completely open 
and free model we have at this > time, with all it's non-structured 
quirks, abandoned, freely invented > or consensus tagging. Database 
consumers or renderers have the free > choice, use OSM 1.0 or OSM 2.0, 
where 2.0 comes at a much lower cost. > Supported triples are defined in 
a flexible but clearly defined > ontology/schema. Every consensus tag 
has it's RDF reference and > integration described in it's corresponding 
wiki page. Mappers who > want their tag to be integrated in the RDF 
model, used by database > consumers or renders, will be "forced" to 
comply with the schema. > > I believe this could be the future, not only 
to sustain our initial > freedoms, but also as the future for a more 
usable OSM, a tool also > to better structure our data for 
documentation, and resolve issues in > competing applications and 
schemes which hinders us from > progressing. > > I am very keen to know 
your opinions on this, especially from S??ren. > > Greetings, > > > Bert 
Araali > > On 17/03/2021 00:41, Jannis Achstetter wrote: >> I tend to 
agree with what Roland Olbricht wrote. >> >> However, I would like to 
answer to the "roadmap" below. Yes, the >> majority of people don't care 
what Facebook, Apple, Amazon, Google, >> bla, bla are doing. I do care. 
I don't use Facebook and WhatsApp, I >> don't have any closed-source 
Google-Apps on my Smartphone and it's >> my choice not to use Apple's 
products. >> >> It's not always true that a minority cannot change 
anything. As >> you said, OSM "creators" / "contributors" might not be 
too many >> people. But think about how the world of open map data would 
look >> like if OSM had not been started in the first place. >> >> And 
this is why I want OSM to be as open as possible. I do want to >> be 
able to invent tags that no one yet uses. This is how OSM >> started: 
There were no rules on which tags exist. People started >> inventing 
them whenever they thought it makes sense to have this >> information in 
OSM. And slowly, schemes and "most commonly used >> tags" were worked 
out. If someone wants to tag feature XYZ in the >> future, let them :) 
Even if this information is not used at the >> moment, we might be happy 
to have it at some point of time. >> >> Jannis >> >> >> Am 16.03.21 um 
16:41 schrieb S??ren Reinecke via talk: >>>> then they are in breach of 
our license, because everybody >>>> interacting >>> with a work based on 
OpenStreetMap data must be made aware that >>> the data is from 
openstreetmap and available under the odbl. >>> >>> It is not about 
proper attribution, it is the fact that most >>> people (Mainstream) do 
not care. But that is getting off topic. >>> >>> _Let me give you a 
roadmap:_ >>> >>> Facebook brought WhatsApp and will now combine 
WhatsApp user data >>> with Facebook user data. Reaction from 
Mainstream: I don't care, >>> not even about my own property. >>> >>> 
Google & other Smartphone OS vendors disallow the removal of >>> 
so-called "system apps". Reaction from Mainstream: I don't care >>> 
because I like dictatorship And since my E-Mail app is a system >>> app 
and gets no updates anymore (modern e-mail providers begin to >>> change 
their login systems), I have just another unusable app on >>> my phone 
costing me space. >>> >>> Apple traps you in there ******** universe of 
no standardization >>> and bad practice. Reaction from Mainstream: I 
don't care, please >>> let me be hostage. >>> >>> Amazon does not pay 
taxes. Reaction from Mainstream: I don't >>> care, I will support them 
anyway no matter what they do. >>> >>> Lieferando runs shadow websites. 
That's literally speaking faking >>> real existing websites. That's 
legal and also supported by >>> issuers of SSL certificates. Reaction 
from Mainstream: I don't >>> care, I let them trick me. >>> >>> . . . 
 >>> >>> >>> So why should the Mainstream be interested in the source of 
the >>> data they use. Most don't even care about their own data :( Only 
 >>> a small portion of open-minded people mainly organized in >>> 
Communities will care and notice the great work we have done. >>> Most 
people will "just don't care" and raising awareness won't >>> get the 
desired effect (yet). >>> >>> That is sad but the Mainstream is like 
that. Humanity is weak >>> >>> >>> >>> On 16.03.21 14:50, Martin 
Koppenhoefer wrote: >>>> then they are in breach of our license, because 
everybody >>>> interacting with a work based on OpenStreetMap data must 
be >>>> made aware that the data is from openstreetmap and available 
 >>>> under the odbl. >>> 
_______________________________________________ talk mailing >>> list 
talk at openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk 
 >>> >> _______________________________________________ talk mailing 
list >> talk at openstreetmap.org >> 
https://lists.openstreetmap.org/listinfo/talk > > 
_______________________________________________ talk mailing list > 
talk at openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20210317/128a2082/attachment-0001.htm>