Separate Appearance Ontology from CityRDF

[ar-chad]

At the moment the Appearance ontology is part of CityRDF. Its IRI is https://www.opengis.net/ont/citygml/appearance

It also imports https://www.opengis.net/ont/citygml/common and https://www.opengis.net/ont/citygml/core

Following classes from Core are used in axioms of Appearance

core:AbstractAppearance
core:TransformationMatrix2x2
core:TransformationMatrix3x4
core:DoubleList
core:DoubleBetween0and1
core:MimeTypeValue
core:AbstractFeature

There is also proposal for texture support in GeoSPARQL opengeospatial/ogc-geosparql#611 (comment)

If Appearance ontology was separated from CityRDF, it would be possible to apply textures to geospatial objects from other domains outside of cities independently. GeoSPARQL could still be as a query language wherever textures are applied and without dependency on cities specific clases. This new Appearance ontology could be also imported by the CityRDF Appearance module.

@nataschake @avillar let's investigate how to proceed with this separation on our next meeting.
@rob-metalinkage please let us know, if you see anything in this that could be not very well aligned with CityRDF.

[nataschake]

Total usages of Core package classes mentioned in Appearance package:

class	mentioned in packages
core:AbstractAppearance	appearance, core, dynamizer
core:TransformationMatrix2x2	appearance, core
core:TransformationMatrix3x4	appearance, core
core:DoubleList	appearance, core
core:DoubleBetween0and1	appearance, core
core:MimeTypeValue	appearance, core, dynamizer, pointcloud
core:AbstractFeature	appearance, core, dynamizer, document, versioning

Either Core classes are mentioned in triples like

?s rdfs:subClassOf core:Class

Or in triples like

?s rdfs:subClassOf [ a owl:Restriction ;
            owl:allValuesFrom core:MimeTypeValue ;
            owl:onProperty ?prop ],
            [ a owl:Restriction ;
            owl:maxQualifiedCardinality "1"^^xsd:nonNegativeInteger ;
            owl:onClass core:MimeTypeValue ;
            owl:onProperty ?prop ],
...

I can create "isolated of Core" Appearance package, and rebalance the rest of packages (=add necessary axioms to the other relevant packages) with the sequence of steps:

• remove triples ?s rdfs:subClassOf ?coreClass. filter (?coreClass in (list of classes mentioned in the table above)) from Appearance package
• add triples ?s rdfs:subClassOf ?coreClass. filter (?coreClass in (list of classes mentioned in the table above)) to packages from the table above
• remove triples ?s owl:allValuesFrom|owl:onClass ?coreClass from Appearance package
• add those triples to packages from the table above.

If the whole CityRDF ontology is put to a knowledge graph such isolation does not make sense, since all the triples are in the same named graph.
So it only makes sense if someone wants to use solely Appearance package without any other CityRDF stuff. It will require definition of classes like app:MimeTypeValue duplicating coreMimeTypeValue and adding clauses like

core:MimeTypeValue owl:equivalentClass app:MimeTypeValue .

into Core package ontology.
What do you think?

[ar-chad]

Generally this is the line of thinking that I also had in mind. That what is in core and not used by any other modules can be in CityRDF appearance module. It would be the first step in refactoring.

I have noticed that inheriting from core:AbstractAppearance reduces to inheriting form core:AbstractFeature, which is a subclass of iso19109:AnyFeature. CityRDF Appearance module can still keep those AbstractClasses, but the new Appearance ontology can be done without them.

Further refactoring along those lines could be done following way:

Appearance Ontology:

@prefix app: <https://www.opengis.net/ont/appearance/> .
...
<https://www.opengis.net/ont/appearance/> a owl:Ontology ;
...

app:Appearance a owl:Class ;
    rdfs:label "Appearance"@en ;
    rdfs:subClassOf [ a owl:Restriction ;
            owl:allValuesFrom app:SurfaceData ;
            owl:onProperty app:surfaceData ],
        [ a owl:Restriction ;
            owl:allValuesFrom xsd:string ;
            owl:onProperty app:theme ],
        [ a owl:Restriction ;
            owl:maxQualifiedCardinality "1"^^xsd:nonNegativeInteger ;
            owl:onDataRange xsd:string ;
            owl:onProperty app:theme ],
        iso19109:AnyFeature .

app:SurfaceData a owl:Class ;
    rdfs:label "SurfaceData"@en ;
    rdfs:subClassOf [ a owl:Restriction ;
            owl:allValuesFrom xsd:boolean ;
            owl:onProperty app:isFront ],
        [ a owl:Restriction ;
            owl:maxQualifiedCardinality "1"^^xsd:nonNegativeInteger ;
            owl:onDataRange xsd:boolean ;
            owl:onProperty app:isFront ],
        iso19109:AnyFeature .

...

CityRDF Appearance module:

@prefix appont: <https://www.opengis.net/ont/appearance/> .
@prefix app: <https://www.opengis.net/ont/citygml/appearance/> .
@prefix core: <https://www.opengis.net/ont/citygml/core/> .
<https://www.opengis.net/ont/citygml/appearance/> rdf:type owl:Ontology ;
owl:imports <https://www.opengis.net/ont/appearance/> 
...

app:Appearance rdf:type owl:Class ;
               rdfs:subClassOf core:AbstractAppearance ,
 	       appont:Appearance ,
               rdfs:label "Appearance"@en .

...

app:AbstractSurfaceData a owl:Class ;
    rdfs:label "AbstractSurfaceData"@en ;
    iso19150-2:isAbstract true ;
    rdfs:subClassOf  core:AbstractFeature ,
    appont:SurfaceData .