reaching 100% CityGML 3.0 conformance

[DiegoVinasco]

tl;dr: add rule-owl-prop-iso191502AssociationName and rule-owl-prop-iso191502Aggregation to the proposed Shapechange configuration files, update the proposed data models with the new config.

In order to be officially 100% conformant to the CityGML 3.0 standard ALL conformance requirements must be satisfied (CityGML Implementation Specification conformance statement):

The Abstract Test suite contains a list of all requirements for every module and potential ADE, including example conformance tests and test methods.

For example Abstract Test A.1 states:

Requirement	/req/core/classes
Test purpose	To validate that the Implementation Specification correctly implements the UML Classes defined in the Conceptual Model.
Test method type	Manual Inspection
Test method	For each UML class defined or referenced in the Core Package: Validate that the Implementation Specification contains a data element which represents the same concept as that defined for the UML class. Validate that the data element has the same relationships with other elements as those defined for the UML class. Validate that those relationships have the same source, target, direction, roles, and multiplicies as those documented in the Conceptual Model. Validate that the data element has the same properties (attributes) as those specified for the UML class. Validate that those properties have the same name, definition, type, and multiplicity of those documented in the Conceptual Model. Validate that the properties of the data element include those of all superclasses of the UML class as documented in the Conceptual Model. Validate that those properties have the same name, definition, type, and multiplicity of those documented in the Conceptual Model. Validate that the associations represented for the data element include those of all superclasses of the UML class as documented in the Conceptual Model. Validate that those representations have the same source, target, roles, and multiplicity of those documented in the Conceptual Model. Validate that the Implementation Specification enforces all constraints imposed on the UML class by the Conceptual Model.

Although the current proposed CityGML OWL model meets most of these test requirements, we are not currently transforming association roles to OWL. According to ISO19150-2, associations should be transformed into rdfs:Properties (which we currently do). However association roles - such as aggregations and compositions - do not exist in OWL. ISO 19150-2 suggests storing the semantics of these roles as annotations properties iso19150-2:aggregationType and iso19150-2:associationName.

These can be fixed by adding the shapechange rules rule-owl-prop-iso191502AssociationName and rule-owl-prop-iso191502Aggregation to the proposed configuration.

[nataschake]

Hi, @DiegoVinasco!
I use this issue due to its title.
In CityGML3.0-ConceptualModel file the feature type AbstractFeatureWithLifespan has four datatype properties ranging in DateTime: creationDate, terminationDate,valiedFrom, validTo. In one of your scripts, update-triples.sh one of actions is to remove exactly the statements about it:

python update_graph.py ../CityOWL/core.ttl ../CityOWL/core.ttl \
   'PREFIX owl:  <http://www.w3.org/2002/07/owl#>
    PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
    PREFIX xsd:  <http://www.w3.org/2001/XMLSchema#>
    PREFIX core: <https://www.opengis.net/ont/citygml/core/>

    DELETE DATA {
        core:AbstractFeatureWithLifespan.validFrom a owl:DatatypeProperty ;
            rdfs:range xsd:dateTime .
        core:AbstractFeatureWithLifespan.validTo a owl:DatatypeProperty ;
            rdfs:range xsd:dateTime .
        core:AbstractFeatureWithLifespan.creationDate a owl:DatatypeProperty ;
            rdfs:range xsd:dateTime .
        core:AbstractFeatureWithLifespan.terminationDate a owl:DatatypeProperty ;
            rdfs:range xsd:dateTime .
    }'

At the same time in alignments.ttl file the definition is different

core:validFrom a owl:ObjectProperty ;
    rdfs:subPropertyOf time:hasBeginning ;
    rdfs:range time:Instant .
core:validTo a owl:ObjectProperty ;
    rdfs:subPropertyOf time:hasEnd ;
    rdfs:range time:Instant .
core:creationDate a owl:ObjectProperty ;
    rdfs:subPropertyOf time:hasBeginning ;
    rdfs:range time:Instant .
core:terminationDate a owl:ObjectProperty ;
    rdfs:subPropertyOf time:hasEnd ;
    rdfs:range time:Instant .

so opening core.ttl in Protege results in errors (punning):
Illegal redeclarations of entities: reuse of entity https://www.opengis.net/ont/citygml/core/terminationDate in punning not allowed [Declaration(ObjectProperty(<https://www.opengis.net/ont/citygml/core/terminationDate>)), Declaration(DataProperty(<https://www.opengis.net/ont/citygml/core/terminationDate>))]

Why do you decide to align these properties to OWL-Time? And don't you plan to return to initial encoding where the properties mentioned above are Datatype Properties?
I found also VCityTeam/UD-Reproducibility#43, so I guess the decision is already made.

[DiegoVinasco]

Hi @nataschake,

tl;dr: our more lightweight proposed interpretation of the CityGML 3.0 model doesn't use OWL-Time. If you need a more constrained CityGML ontology for your work, perhaps we can propose an interpretation of CityGML OWL without OWL-Time.

Thanks for this comment! We've actually been looking for external input on this work and we haven't had much feed back yet.

From our reasoning, there's pros and cons to both approaches.

Pros	Cons
More interoperable with many existing geospatial linked data that model temporal properties as entities such as [Tran et al. 2020]	Not conformant with CityGML 3.0 according to ISO 19150-2
Permits inferring temporal relations (through approaches like [Batsakis et al. 2017]) with CityGML entities with lifespans	More complex and less lightweight representation of entity lifespans

We argue that this interpretation of the CityGML 3.0 may be more interoperable with exiting geospatial ontologies (at least in the works we have encountered in our research).
However, we we only use OWL-Time in the more constrained interpretation of the CityGML model. Our less constrained interpretation, uses the original datatype properties.

We wanted to propose multiple interpretations as we didn't want to impose a specific interpretation of the CityGML model in OWL. Your comment raises a good point! Perhaps there two more interpretations of the CityGML model we should have considered, giving us 4:

Interpretation	Constrained	with Temporal entities
100% conformant CityGML CWA	👍
CityGML CWA	👍	👍
CityGML OWA
CityGML OWA with OWL-Time		👍

I think these wouldn't be very hard to create either. If that's useful to you and your team, I would be happy to take a look at that in the coming weeks.

[nataschake]

Hi @DiegoVinasco, thanks!
I support the decision to have CityGML3.0 transformed fully conformant while benefiting from OWL and SemWeb's ability to make CityGML more OWL-friendly. So, in my case, I followed the initial datatypes transformation; I just removed the part in alignments.ttl defining AbstractFeatureWithLifespan with OWL-Time concepts and changed the update-triples script.
I think that all the proposed solutions you and your team have so far should be presented to the CItyGML standardization body (and possibly ISO due to 19150-2 specifics). Unfortunately, I don't have a use case to play with the necessity to reason over the lifespans of building objects, but let's see.