Workshop CityOWL with relevant SWGS

[rob-metalinkage]

also note the Spatial Data on the Web WG recharter.. https://w3c.github.io/charter-drafts/2024/sdw-wg.html

[nataschake]

Hi @rob-metalinkage!
I found this place to inform the team responsible for keeping all CityGML-3.0Encodings together.
They say: post issues here: CityGML3.0-GML-Encoding

[rob-metalinkage]

Proposed text to send to SWGs:

#CityGML OWL representation

There are multiple reasons to reference and describe specific elements of the CityGML data model in machine-readable forms. These include:

• Defining business rules for the objects described in CityGML (e.g. planning regulations)
• Defining data requirements for subsets (e.g. profiles to support such business rules)
• Defining mappings and translations between CityGML and other formats
• Semantic integration of CityGML data into wider scoped information models

All the above increases data and application interoperability with GIS and other types of information systems via CityGML implemented using Semantic Web Standards.

To enable these requirements to be implemented in machine-executable fashion it is necessary to translate the visual paradigm of UML models into a canonical machine readable form - hence the proposal for a CityGML OWL representation. To achieve interoperability this requires a published, canonical version.

CityGML however is not a "pure conceptual model" - it has UML and XML centric design patterns that complicate the derivation of an OWL representation. A straightforward translation leads to an inelegant representation with much duplication and idiosyncratic extension points (ADE) that are much more elegantly handled by the inherent extensibility of OWL and RDF models.

The ACCORD project has undertaken a task to create a repeatable process to convert the canonical UML model into an elegant machine-readable representation. The details of this conversion may be found at the working repository README.

Further work is underway to wrap the CityGML model classes in a FAIR way, as a "Feature Type Catalog", suitable for use with the OGC API Features. The OGC Building Blocks documentation methodology will be used to bundle examples and validators with the derived data model and provide translators to related formats for individual CityGML object classes. (This will avoid the complexity of full-model mapping to alternative forms that do not have exactly the same scope as CityGML, such as CityJSON and various INSPIRE or BIM data sources)

(updated after comments below)

[ar-chad]

It looks good. I would add after the bullet list: All the above increases data and application interoperability with GIS and other types of information systems via CityGML implemented using Semantic Web Standards.

[nataschake]

I propose to rewrite this paragraph:
A simple translation leads to an inelegant and semantically incomplete representation with much duplication and idiosyncratic extension points (ADE) that are much more elegantly handled by the inherent extensibility of OWL and RDF models.
into
A straightforward translation leads to an inelegant representation with much duplication and idiosyncratic extension points (ADE) that are much more elegantly handled by the inherent extensibility of OWL and RDF models.
The reason is that when I checked what Diego did in UD-Graph, his result available on the Web was coherent and consistent wrt reasoning. Semantic incompleteness for me equals to some logical pitfalls. His translation is more to "straightforward", than to "semantically incomplete". He fighted with errors of ShapeChange conversions, which were for version 3.0. I fighted with other errors of ShapeChange but in version 3.1.1, so when apply conversion tuned for version 3.0, easily we can get errors caused by the same conversion in version 3.1.1.

[ar-chad]

"Completeness: Measures if the domain of interest is appropriately covered. All questions the ontology should be able to
answer can be answered." https://www.semantic-web-journal.net/system/files/swj657.pdf

Does straightforward translation lead to representation that is complete in this sense?

[rob-metalinkage]

I updated the text with the suggestion provided.

[rob-metalinkage]

"Completeness: Measures if the domain of interest is appropriately covered. All questions the ontology should be able to answer can be answered." https://www.semantic-web-journal.net/system/files/swj657.pdf

Does straightforward translation lead to representation that is complete in this sense?

If the "domain of interest" is defined to be the scope of CityGML, and the translation is lossless and automated then completeness can be acheived.

From a specification perspective completeness should mean defining an extension mechanism to cover related domain concepts.

[ar-chad]

This extension mechanism is already built into Semantic Web Technologies. This is why ADEs are no longer needed in CityRDF.