Great guide!

Fantastic work!

Could you post the code somewhere? It could be in the gist itself. It is shared as an image.

Okay, I just had one idea which might help mitigate issues for any local group, existing or future, which is allowed to seek money with the trademark: every organization with explicitly rights to use the trademark have contact point to work as Ombudsman mechanisms on how they operate as local chapter, and such mechanism be a contact point which go directly to OSMF (or any relevant working group). This must be near places that ask for donations and requirement if either the donation campaign uses OpenStreetMap trademark or the organization have OpenStreetMap trademarks on its name (so it implies have relation).

The rationale here is either corruption-related complains (e.g. like a organization saying that done something for their public, but the actual work was by others) or abuse of the trademark rights to antagonize valid initiatives in the region (special if are truly volunteer based, but (in case of being the first in a region) a official chapter could start kick members from own organization or simply block then on any communication channel from the country).

Such a complaint mechanism could be more than good enough as a deterrent. Any organization with explicitly trademark rights (even if it starts democratic, it could still have a takeover) would have a realistic fear of losing trademark rights. It also would make it easier to accept new chapters for regions without one when it is implied that it can be revoked, because if the intent already starts to profit on the trademark without any meaningful impact, then eventually complaints would arise. The rationale for explicitly revoking a local chapter is worse than being an informal local chapter, so yes, this is why I think it is a good deterrent.

Like I implied in the previous comment, it must be reasonable why a local chapter (or, in this case, an organization which I suppose is not looking to be a local chapter) could be somewhat “economic operator” in Europe while it would be not allowed in Africa. The fear here is not average disputes between mappers of a region, but the single official representative in a region abusing its powers like already happened with informal ones for pure financial gains. One direct consequence would be organizations or local chapters be conservative on their promises of making impact to seek donations, because doing it with others’ work (including those not members of the organization) could make them have rights revoked.

PS: Looking at https://fposm.fr/ (archive page https://web.archive.org/web/20230326052609/https://fposm.fr/ ) and aware that already exist an OSMF approved local chapter in France (which use different wording on https://www.openstreetmap.fr/) the fear of the diary post of use of “OSM” on term makes even more sense to me. I do understand it might contradict my saying to avoid exclusive rights in a region while focusing on the new group, however the way the FPOSM explains itself could easily be confused as a local chapter! However, the nature of say itself as “experts” likely soon also imply services, might soon or later be a organization allowed by OSMF to have trademark use that will use OpenStreetMap data from others in France while saying it is “fixing it” and investing massive effort on marketing to get more money, which deviate from the community (as OpenStreetMap mappers and open source software developers, not mere “community data users”). To be clear, I cannot discuss this case in particular (I’m less interested in Europe than the global south), but OSMF could try to investigate better with the local French community the context behind this. Maybe there’s more going on.

Greetings from the lusophony community!

I think I got the idea of what he fears on formalization of exclusive ^{see PS2} rights for the OpenStreetMap trademark on France itself.

For context, see this eye opening report on what happened with the francophone community , which goes in detail with the disastrous consequences it had in Haiti https://lists.openstreetmap.org/pipermail/osmf-talk/2020-December/007515.html , to quote part of the text:

“(….) “Haiti provided an example of how bad things can go when one association (COSMHA - Communauté OSM Haiti mostly based in Port-Au-Prince area) had been active as a de facto LC and a de facto “economic operator” providing paid services around OSM. Over time, volunteerism tended to disappear or be very limited to the extent that the association operated solely under a business logic for the only benefits of some of its members. In parallel, tensions grew within the membership resulting into its shrinking and its control by a few. Entry in the association was made difficult. The internal democracy was limited. The association through its de facto OSMF chapter role seeked control over all OSM activities (community, association and business) in the island. This resulted into violent relations with individuals and other groups (in Port-Au-Prince, Saint-Marc or North/North-East) around any community volunteering activities as well as around economic opportunities. Tensions were such that certain mappers stopped their OSM activity or left the island in 2013. The overall resulted into less volunteer community-based activities, a dependence on economic project for any activity and a shrinking of the number of active local mappers (…)

While (despite massive money from international aid on projects) there’s no Haiti community anymore, considering the francophone Africa, despite from time to time well marketed projects and call to actions to make easier to allow creation of local chapters, the transparency is minimal and not volunteering focused, but mostly around economic incentives to bootstrapping add data without care on the impacts that it crowding out volunteers. So, is unclear if is a matter of time to also francophone Africa have only outsiders doing as volunteering, without any true envolvien from people in the region because the existing groups have incentives to antagonize any perceived “competition” which can be better and the real threat is it includes local doing improving the map because want the map be better, not by mere payment (if no money is deliver better results than paying , then become a threat when justifying donations).

So, with all this said, if a group in France will have any special right to explore the trademark and talk in name of OpenStreetMap as local representative on a very official level, then OSMF, for sake of consistency, would need to review status, including the very comercial ones not already allowed, on for example Africa.

Whatever happens if the group in France has such a right (which now it seems to want explicitly), then must be clear what makes it different from others.

PS.: I’m not too extreme to say no local group could use “OpenStreetMap” or closely related terms of OSMF trademarks. However, the fact of being able to seek money while using the OpenStreetMap trademark must have minimal safeguards.

PS2.: I just noticed that there’s already a local chapter in France, which, different from the organization mentioned to be presented in the next OSMF board meeting, does not use focus like “experts” or “services”. So, I’m sorry if my comments here may be perceived to target the wrong, older group, but it must be said that yes, attempts as economic operators are known to cause harm on existing contributors.

Quick update here: I’m drafting https://eticaai.github.io/openstreetmap-semantic-conventions-2023/ (repository at https://github.com/EticaAI/openstreetmap-semantic-conventions-2023) as an first attempt to make an a quick example-based reference to convert between some file formats and their encodings to RDF.

While some initial examples are not more than Sophox used in the Wiki (I think mostly based on work from @nyuriks ? Thanks!) with different formatting (trivia: its based on rdflib longturtle format which is decent for git diffs using only text) there’s far more things missing how to encode.

For now I’m just leaving it on @EticaAI and leaving the thing public domain, but no problem to me to move to something else. Also, the folks already working on the Data Items in last years and already active on Wiki things (aka for example Minh Nguyen or Mateusz Konieczny) could be editors later. The respec from W3C is quite fantastic to create this type of thing, including cross-reference, author/editors retired date, etc.

I didn’t know about this OSHDB. Nice! Thank you, rtnf! Also, this https://osmlab.github.io/osm-deep-history/ interface is quite helpful to check the tags changes over time. I will start using it!

Anyway, something I sort of miss from being a first-class citizen (sense: having better support out of the box) are queries based on things inside other things how things touch each other (e.g. sort of spatial operations). However, even administrative boundaries (which are quite common requests, because it is generic, even if boundaries can be disputed) have poor support. Yes, I do understand that because the way the data is stored in SQL databases the bboxs filter as highly optimized for performance, but in some aspects, even if via query rewriting (e.g. user try some name for a region, then is rewritten in something that the underlying storage can work with) is quite limited.

I mean, I’m not saying the full GeoSPARQL (here the preview of GeoSPARQL 1.1, which by the way cite more than one implementation using OpenStreetMap), but for example PostGIS 3.3 does have support for Spatial Relationships, so in theory, even if not the main database, might have some way to make it viable 😐

Thank you, @pangoSE, for your comments!

Also, anyone more already on OpenStreetMap using Wikidata or any other ontology or semantic integration, feel free to comment here, even months or years after.

1. Maybe eventually we some channel for people interested in discussing the subject?

If we have sufficient people, maybe we could set up some Telegram group, then eventually one subforum on the community.openstreetmap.org for not already tagging schemas, but ontology and semantic integration. If something like this goes ahead, instead of focusing on Sophox, LinkedGeoData, OSM Semantic Network, OSMonto, etc (projects of OSM) be more generic.

Beyond some chat, I think something like https://www.wikidata.org/wiki/Wikidata:WikiProject_Ontology (which @Mateusz Konieczny proposed here osm.wiki/Talk:Data_items#Broken_Wikidata_ontology) but for OpenStreetMap and already considering that more than one frontend (such as iD editor) consumes the multilingual terminologies / ontologies.

This idea is not for now. Maybe at least a few weeks.

1.1. It’s clear already do exist people in OpenStreetMap already working with semantic integration

@rtnf said: In short, do you have any short-term / long-term goal to accomplish (and its related roadmap)? Introducing semantic technology into OSM is quite an interesting research topic to me (but i simply don’t know where to start).

I do already have some opinions, and like I said I’m new to OpenStreetMap, however since few days before this post I start to notice that you here already have people working on it, but they’re on several projects (that would be edict from stricter encoding than raw tags) or are sort of lone-wolfs that neither can use Wikidata or OpenStreetMap. Actually even the people not happy with Wikibase integration on the Wiki are great candidates to be interested in this.

2. [Argument] ontology (information science) still like Ontology: abstract enough to allow reusability

Call me dogmatic, however neither Wikidata (Wikibase) nor any conversion of OpenStreetMap data into RDF is the ontology.

Something such as Wikibase is a tool. Something such as RDF flavor is a way to store data. And a RDF triplestore can often be an abstraction that actually uses just SQL databases (often command line tools use SQLite in memory). So, even the already considered reference strategies for semantic encode are flexible.

I’m not saying everyone needs to go deeper into mereology (but is good have people around able to explain in more abstract level the relations of things, these don’t need care about how is encoded) but it would be too restrictive assume ontology engineering on OpenStreetMap is any particular implementation.

So, if we start from the idea of why ontology engineering exists, we focus on data integration, data interoperability, we focus on things that people already care about.

2.1 Well encoded information into traditional formats (JSON, CSV, …) can allow semantic reasoning VERSUS dumping data into RDF because is RDF don’t make it reasonable

Simply storing data into RDF doesn’t not allow semantic reasoning. RDF accepts nearly everything very fast. And similar to SQL (think unrestricted CREATE TABLE ALTER TABLE), by default someone can not just insert data, but could change the schema with global level effect. Such small mistakes might not break SPARQL, but can cause chaos in semantic reasoning. And for performance reasons, something such as Wikidata never would work with semantic reasoning enabled.

Data Items currently have OpenStreetMap tags, however I’m not as sure if they already have abstract concepts which would be one or more tags combinations. I think the closest we could get such information already would be to start with how popular tools organize tags to show icons on maps. There May already exist common schemes, just not converted to RDF/OWL.

My argument here is that as long as any other non linked-data format, like JSON or  map styles encode concepts, doesn’t have illogical information, they still feasible to be upgraded to RDF/OWL plus some post processing (like skip know inconsistencies that will fail in later stages). And nor just this, this approach might actually be safer to not break schema at world level, because the controls become scripts that upgrade the data. Actually, it is better to have a predictable non-RDF format that can be upgraded predictably than to be too focused on always using the entire RDF-like toolchain in every part.

So, this thinking could make the “bug” of data not immediately RDF/OWL become “a feature” (e.g. alternative more prone to become inconsistent)

2.2 Dump RDF triples is simple after the before vs after example is documented

For those not aware of RDF tooling, while things can get very complicated (because often tools comes what all the features) the export to RDF (which if inserted into an ontology, could give full meaning) is likely one of the easiest and very optimized for massive speed.

If we have a source file (something already updated by the community) that is possible to loop over each item in a language like python, it is somewhat trivial to make print line by line the easiest format, triples. RDF even doesn’t care about insert order, tolerate repeated insertion, etc. More complex stages like validation and/or formatting is better done by compiled code by someone else’s standard tool. I cited JSON, but whatever is used could be done.

This is one reason why I believe it makes sense we get people already using OpenStreetMap with semantic integration, so they could help decide the before/after of existing data not already in RDF/OWL. However, soon or later the discussions also become very abstract (what is a hospital?, is a pharmacy a type of hospital, or both are part of something else we explicitly don’t use on map styles?). Another complicated, very human task is what to do with two or more sources of encoding  that conflict with each other (let’s say, there’s a generic map style for OpenStreetMap, however something like Hiking is more specific, who should have preference for Hiking related concepts?) because whatever end result break reasoning, they cannot co-exist on sort of reference ontology.

1. About natural language use

Second, regarding reusable ontologies, I think we can start to work on it in a “technology-agnostic” fashion. At some point, ontology representation format, such as RDF, cannot model everything succinctly. So, it’s better for us to start drafting the ontologies by using natural language instead.

I think you and others might like this this heavy cited article on the idea of what is ontology (in comparison to Ontology): https://iaoa.org/isc2012/docs/Guarino2009_What_is_an_Ontology.pdf

I’m not against the use of natural language (and I mean not just as drafting). Actually, well written explanations can easily be more well understood than programming language implementation, and good practices of how to encode formal ontologies recommended that the elucidation (something such as short description) must be good enough as a minimal viable product.

1.1. Example of natural language reusable beyond the formal ontology encoding (iD editor short descriptions)

Regardless of how the ontology is encoded, at minimum it helps to implement reuse of the terminology.

It would take way too much time here try explain good practices of elucidation, however if user have a select box (let’s say, tag surface) then is presented with options that are suggested, at very minimum is expected that the options: - don’t have circular reference:   - term: “Acme” ; elucidation : “data about acme” - at minimum disambiguate about other terms in the same context   - This sometimes is hard, however the descriptions should alone help the user not confuse two options.

 There’s other good practices, however, as soon as someone knows some formal language, it might be far easier to write fast in that formal language than to write natural descriptions. I’m not sure if iD editors actually use the Data Items, however for everyone reading: ontology engineering is more than just optimized for the software reading the formal specifications, it MUST help implementations that at minimum should be able to reuse the labels.

2. Proposals for properties vs formal specification

The conversion from the proposal to the underlying semantics shouldn’t require everyone to understand the details. This can be done by non-experts of the area of that tag (but who know the encoding the explanation into the formal ontology), then the collaborators validate the final result by comparing if the software delivers the expected results. If what’s requested is not feasible (creates conflict, or the person which implements simply can’t understand) then the situation gets stuck.

For starter, you can read OSM tag proposal archives here (https://osm-proposals.push-f.com/) to understand how OSM design their own ontologies. As a fellow Wikidata contributor, the OSM’s tag proposal discussion section is very similar to Wikidata’s property proposal discussion.

So yes, your example is a great baseline. And it is a good thing to make the more philosophical contributors feel welcomed. The discussion here might expose some low level (for those more philosophical) about encoding, however if we really go deep into the whole Ontology thing, the discussions about implicit details could be far more complex than the ones about tag proposals.

Likely one major difference between the existing proposals for OpenStreetMap Tags and the make easier to make formal ontology is the following: is necessary formalize more structural concepts (implicitly) which are discussed and if they’re not created, this inviabilize create formal encoding. Often this means that (at least for things notable enough), it is necessary to differentiate the tag from the idea the tag represents, otherwise systems break. This might be more obvious if we start having examples everyone can run, so we start seeing what “variables” already not relevant OpenStreetMap are so recorrent that they need their own code. I need to explain this point better later.

3. About use of custom formats: perfectly okay we do it!

The idea of not writing rules directly into the exchange format is not absurd. In fact, there’s a file format popular on ontologies, the OBO format, which is still used today, which the documentation is http://owlcollab.github.io/oboformat/doc/obo-syntax.html.

So, I see no problem in having one or several formats, as long as they can be converted. In the worst case scenario (e.g. not create a mapping specification from one format to another) then the script that converts something that already has a good workflow in place becomes an ad-hoc reference between automated conversion. I meant: let’s assume different projects already use relevant information (for example, JSON), as long as the information makes sense (e.g. do not cause logical errors, this is very important) then it is far easier just to create conversor than convince people to change.

However: in general, the encoding is likely to be more powerful than existing formats, so the very few people who understand either the logic or the language will have more advantage. After more and more parts of OpenStreetMap become formal ontology, these persons can compute the previous decisions without needing to be experts in that area of all tags.

4. About custom abstraction: I really recommend we stay under the realm of description logics (don’t matter the “file format”)

Second, regarding reusable ontologies, I think we can start to work on it in a “technology-agnostic” fashion. At some point, ontology representation format, such as RDF, cannot model everything succinctly. So, it’s better for us to start drafting the ontologies by using natural language instead

There’s more than one way to create formal ontologies (e.g. that computers can understand). But I believe we should still stay in something viable with description logics (this is the one which differentiate TBox and ABox). First-Order Logic, or FOL, includes everything possible with descriptive logic, however has less tooling and is hard to write the rules.

Under description logics, the exchange format with better support is OWL. RDFS (RDF Schema) , while there exist some reasoners, is “too weak”. I’m not going into full details, but some tools even make the constructors like owl:SymmetricProperty actually hardcoded, and they recommend not import https://www.w3.org/2002/07/owl#.

So, when we define one ontology with OWL2 then any tool which reads the rules we define, actually will work as expected. OWL2 does not include everything in description logics (but does include most useful features), but if the strategy used to document an ontology can be expressed with description logics, then it can be converted to OWL, and from there is can for the rest.

The first minutes from this video https://open.hpi.de/courses/semanticweb2015/items/6WC6rQkWVYT0D9KapRNHEh comments that First-Order Logic being too expressive (it’s close to a programming language), but follows the trend to recommend Description Logic when necessary.

4.1 Why don’t I just say “let’s use OWL”?

Well, if we’re discussing willing to even create tooling, “description logics” helps with the motivation. It is sort of assembler language at a logical level, yet not full mereology/philosophy.

And the example with OBO format they even cited in the past attempts to use first-order logic to export their custom formats, but it was hard to generalize.

And this also explains that we cannot simply convert data arbitrarily to RDF triples and assume that the thing is now semantic.

So, while this is oversimplification, people trying to go down from mereology to description logics, despite several times might hear “RDF” or “Turtle” (one encoding of RDF), I recommended either look for OWL, or read basic tutoriais of interfaces using OWL, and one open source one is Protége (but try tutorials that explain how semantic reasoner’s work).

5. On the focus about Tbox

Assuming people here agree that the foundation for formal ontology uses description logics (again, don’t matter if the file format is edited by humans, but if it is possible to convert to another format), the differentiation of TBox vs ABox becomes relevant, both for data storage and optimization. Actually, some semantic reasoner (there’s more than one) will be faster in some scenarios than others.

In general, I believe a good focus is the TBox (even if we could store ABox with TBox, like Wikidata does, we optimize for having a more powerful TBox). This means not just go further on at least the most common OpenStreetMap Tags and their values (this sort of is the Data Items), but other things which are implicitly, but doesn’t have unique identifier and without this, we could have formal language, we could have people know how to make the calcs with such formal language (without depend on someone else), but if we would need permanent nomenclature for these implicit structural codes, otherwise would the rules for each new proposal either too complex or impractical.

PS: Okay, this sort of comment turned out overlong and still not wrote everything I would about the comments! I’m doing some tests with the dumps. The osm.wiki/User:EmericusPetro/sandbox/Poor_mans_OpenStreetMap_Data_Items_dumper was generating some incomplete data, so after the https://github.com/openstreetmap/operations/issues/779, now we have RDF dumps at osm.wiki/dump/wikibase-rdf.ttl.gz !

Comment: where was written “Except for translations (which by the way are going great) the actual (number of) non-bot editing on OpenStreetMap Data items was not healthy considering the importance” was about the low number of of people involved, not the interactions.

This also applies to the number of people here also fixing (when necessary) Wikidata items that are not edited by automation.

This compilation osm.wiki/User:Minh_Nguyen/Wikidata_discussions is fantastic! I’m reading everything (and also putting on Watching for changes). Might take some days, but I already perceived additional points from the links:

1. One (which I think is actually worse than the interface issues) is the following: seems that the idea of something such as OpenStreetMap Data Items was turn OpenStreetMap data into an ontology by using Wikibase to store the formal specifications of what people are tagging the data. This precedes the de facto Wikibase install on the Wiki and Sophox. So the goals already were higher.
2. There’s another (https://lists.openstreetmap.org/pipermail/talk/2020-May/084637.html) issue which I believe actually where meanining rdfs:seeAlso (but hoping to be owl:sameAs) on the Infoboxes for each OpenStreetMap tag to point to Wikidata, but then get frustrated. I’m likely to create another diary just for this point. Not giving spoilers, but searching by complaints around “owl:sameAs” even on formal ontologies which people don’t test integration (but rdfs:seeAlso is still useful).
3. Except for translations (which by the way are going great) the actual non-bot editing on OpenStreetMap Data items was not healthy considering the importance. This needs to change.
4. Someone (even if a small minority) complained about the fact of sending people to Wikidata for things that are for OpenStreetMap. I think that considering there already exist organized editing by humans and it works for areas of their expertise, even for specific features (roads), moving even structural Q to Wikidata (e.g. Universals very specific to OpenStreetMap) would lose their willingness to update. Not saying this must be Wikibase, but at least still under OpenStreetMap (worst case a GitHub repository)

I know we’re mostly discussing Data Items/Wikibase install issues, regardless of the outcome of this, I already think that fixing the bot for synchronizing Infoboxes would not fulfill the general idea because not just the tags are necessary. For example, the Universal for the tag building=fire_station is not the same as the Universal for a concept it represents in the map. This is just an example, but explains why do exist things that cannot be outsourced for Wikidata nor rely on the tag documentation alone, because it is relevant at least for most common tools helping with OpenStreetMap.