<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    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.<br>
    <br>
    <span style="white-space: pre-wrap; display: block; width: 98vw;">> 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 ?
</span>
    <p><br>
    </p>
    <p>Wiki link:
      <a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Resource_Description_Framework">https://en.wikipedia.org/wiki/Resource_Description_Framework</a><br>
      See also Wikidata (Wiki Data Items). That technology is used there
      (if I am not terribly wrong).</p>
    <br>
    <p>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"<br>
      <br>
      E.g. The translation part. I think osm2pgsql provides a Lua
      interface to do exactly that:<br>
    </p>
    <p>contact:phone=+49 157 45345 --> 004915745345<br>
      phone=+49 157 45345 --> 004915745345</p>
    <p>contact:phone=+4915745345 --> 004915745345<br>
      phone=+4915745345 --> 004915745345</p>
    <p>contact:phone=+49-157-45345 --> 004915745345<br>
      phone=+49-157-45345 --> 004915745345</p>
    <p>contact:phone=049-157-45345 --> 004915745345<br>
      phone=049-157-45345 --> 004915745345</p>
    <p><br>
      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)<br>
      contact:phone=0157 45345 --> 004915745345<br>
      phone=0157 45345 --> 004915745345<br>
      <br>
      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)<br>
      contact:phone=157 45345 --> 004915745345<br>
      phone=157 45345 --> 004915745345</p>
    <p><br>
    </p>
    <p>E.g. the scheme part:</p>
    <p>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)><br>
      Still this is not a good schema, let's do another one</p>
    <p><br>
    </p>
    <p>| Country | phone number |</p>
    <p>| de?????????????????? | 15745345?????????????? | clients convert it to -->
      004915745345</p>
    <p>| it?????????????????????? | 15745345?????????????? | clients convert it to -->
      0031015745345<br>
      <br>
      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:<br>
      <br>
      | phone ?? ?? ?? ?? ?? ?? ?????? |<br>
    </p>
    <p>| 004915745345???? | Before the pipeline --> contact:phone=+49
      157 45345</p>
    <p>| 0031015745345 | Before the pipeline --> phone=+31-157-45345<br>
      <br>
      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.<br>
      <br>
      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).<br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <br>
    <br>
    On 17.03.21 00:10, Bert -Araali- Van Opstal wrote:<br>
    <span style="white-space: pre-wrap; display: block; width: 98vw;">> 
> 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 <a class="moz-txt-link-abbreviated" href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a> 
>>> <a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk">https://lists.openstreetmap.org/listinfo/talk</a>
>>> 
>> _______________________________________________ talk mailing list 
>> <a class="moz-txt-link-abbreviated" href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a> 
>> <a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk">https://lists.openstreetmap.org/listinfo/talk</a>

> _______________________________________________ talk mailing list 
> <a class="moz-txt-link-abbreviated" href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a> <a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk">https://lists.openstreetmap.org/listinfo/talk</a></span><br>
  </body>
</html>