Fantástico!

Dados de endereço são muito úteis!

By the way, looking at the https://github.com/Zverik/cli-oauth2/blob/main/src/oauthcli/providers.py is clear there’s some providers.

Did you know if OpenStreetMap Wiki (mediawiki) and Wikidata (the mediawiki/wikibase) have Oauth2? If yes, maybe consider implementing it.

Have things kind of thing already done is helpful, in special if the same programming language the dev like me would likely to do cli tools.

(All my tools still read-only and, if any, they export files to be used with OSM editors)

Que legal, tchê.

Como você fez para coletar os números?

Oh, permaneça aqui! Sem problema descansar um pouco.

Você é uma das pessoas mais fantásticas que conheço dentro da OpenStreetMap, e é super ativo. É preciso mais gente como você.

Wikitext is only one of the page content models that MediaWiki supports.

Good to know other content models! Maybe I also create some syntax sugar (e.g. instead of raw string , return something else).

But for data-like content, beyond wikitext (in special the tabular data) Wikibase JSON could be abstracted to return at least the labels, which would later be used, for example, for translations. Note that it is complex to convert from/to a RDF-like dataset to other datasets, but the translation part of items might be so common that it could be worth an abstraction.

(…) you can write a wiki page using simple wikitext syntax as long as you avoid breaking several lightly documented tools that place arbitrary constraints on exactly how you write (e.g., whitespace and capitalization) it due to assumptions they make. Writing for the renderer, in other words. ^(new emphasis mine)

Yes, the challenging part of parsing wikitext is exactly this. This is one of the reasons (at least if using the tool to extract data) it is more forgiving for who writes, and strict on what output generates.

(…) I also appreciate your emphasis on reusing existing content without creating extra maintenance overhead. However, we should view this kind of tooling as being complementary to structured data, not in competition with it.

I agree with the complementary. In fact, the implementation cited here is intentionally lower level, without the database part (it does have a sqlite, but for cache requests). The fun part is done outside.

On the reusing existing content without creating extra maintenance overhead, this is really a focus. While the tool is not self-sufficient for a full solution, by making it it focused on the parsing (and allowing be reusable with other wikis) could increase some extra conventions where wikitext alone is insufficient.

Humm, interesting the first comment is about how Wikibase abstractes the data! And yes, I found it relevant to explain this internal part, because it really depends on external storage to add the “true” linked data storage.

I mean, when Wikibase stores items data as JSON on a single page, these pages are on a big textarea, so by default, the SQL database cannot really understand its internals. And I mean, it is not even MongoDB where there’s native support for JSON fields.

Another trivia is that if trying to do data mining using MediaWiki with Wikibase API, it’s likely to be item by item (maybe it can allow pre-fetch related, so still very useful) however if somewhat brute force the wikitext (which will be JSON) with vanilla MediaWiki API, then even without special user account (admins or bots) is possible to fetch 50 pages at once. I know this may sound a bit low level, but if we’re talking about synchronizing content, as long as the content stored on the MediaWiki can be exported without need to always work with Full wikidumps available here https://wiki.openstreetmap.org/dump/.

About your comment comparing with VisualEditor, I guess the Wikibase interface is more a form-like interface (enforces some structure, not very advanced integrity check, but does some checks). I have not fully tested the alternatives, but I’m sure there’s other MediaWiki extensions which could enforce a form-like entry, to restrict what users can do. So, the analogy with VisualEditor is not perfect, because the link you passed about the VisualEditor, it still allows more freedom for the user with higher challenges to parse (compared to any form-like interface).

Maybe closer analogy than the MediaWiki VisualEditor, the Wikibase editing page is similar to how iD editor allows users to edit an already well detailed item (depending on the tag, the field changes appearance, suggest different values, etc).

(…) It’s JSON, which explains just how disconnected it actually is to the MediaWiki experience. That’s why it feels so foreign and disorienting, and functions like the completely tacked-onto experience it provides.

I think that from a perspective of a “MediaWiki experience”, even trying to not break the mental flow of editing as text (while still fully machine readable) at least some types of trade offs are necessary. The Wikibase (and any other MediaWiki with a form-like UI) explicitly enforce (sometimes too much, or sometimes not allowing for a full strict validation; I know, both ideals are contradictory) how to add/edit data, but even if we parse wikitext directly, the parser could still benefit from hints (such as suggested filename of a code sample) which might not worth show for the user who only cares about visual text, not metadata.

This part is briefly commented on in the dairy, but both conversion tables (e.g. {{yes}} => true) and explanations of what the parameters on most important infoboxes are may not be in the same page (also, would be too redundant) but would still be in some place (preferable in the same wiki). And the syntax where these instructions may not be possible is only natural language.

But it isn’t a duck.

Yes, I also liked the analogy! But again, “Wikidata” is the project (formal explanation: https://www.wikidata.org/wiki/Wikidata:Introduction, “Wikibase” is an extension for MediaWiki (see also: https://wikiba.se/). So the Wikidata as a project actually is a full linked data. Another interesting fact is that Wikibase (even without triplestore) somewhat still linked data, because it does expose persistent URLs and still fast. So the self description on wikiba.se, “Wikibase is open-source software for creating collaborative knowledge bases, opening the door to the Linked Open Data web.” still very true.

The diary could get more complex, but in theory, a future proxy for each page on OSM.wiki could still somewhat be linked data as soon as the person request some format like RDF/Turtle. Same principle could apply for the main API, which today returns XML, but a pull request started in 2019 by the Overpass main developer added JSON output (link: https://github.com/openstreetmap/openstreetmap-website/pull/2485), so in theory, even the main API, rails-port, could also be explicitly “linked data”. I started a early draft for that 2022 here https://wiki.openstreetmap.org/wiki/User:EmericusPetro/sandbox/RFC_OpenStreetMap_RDF_2023_conventions_(proof_of_concept) which do a very rudimentar conversion from the XML to RDF/Turtle as a proxy (if person request XML or JSON, it does noting, just output the true output of the de faco API). That was the very easy part, the true challenge (beyond the slow process of how to agree on a schema good enough) would be start to build the endpoints for every tag, so if a tool try to fetch PREFIX osmt: <https://wiki.openstreetmap.org/wiki/Key:>, it would work

Opa, ainda que você não tenha parado por tanto tempo assim, seja bem vindo de novo.

Sou do Brasil também. Comecei há menos de um ano.

Nem todos os herois usam capas.

Parabéns!!!

Usa ESRI. Maxar costumava não exibir metadados e qual dada era a foto (Bing e ESRI dizem) mas as vezes ESRI e Maxar era perceptível serem o mesmo fundo (porém Maxar não citava data.

E dependendo do estado em que você mora, pode ter secretaria estadual que tenha camadas de fundo on-line.

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.