RDF turtle generation of enumerations does not load correctly in protege

[DiegoVinasco]

Using the rule-owl-cls-iso191502Enumeration rule, Shapechange transforms enumerations into :

core:RelativeToWater  a  rdfs:Datatype ;
        rdfs:label       "RelativeToWater"@en ;
        owl:oneOf        ( "entirelyAboveWaterSurface" "substantiallyAboveWaterSurface" "substantiallyAboveAndBelowWaterSurface" "substantiallyBelowWaterSurface" "entirelyBelowWaterSurface" "temporarilyAboveAndBelowWaterSurface" ) ;
        skos:definition  "RelativeToWater enumerates the spatial relations of a city object relative to the water surface in a qualitative way."@en .

But protege does not read datatypes with owl:oneOf declarations unless they are in the form of :

core:RelativeToWater  a  rdfs:Datatype ;
        rdfs:label       "RelativeToWater"@en ;
        owl:equivalentClass     [ a             rdfs:Datatype ;
                                  owl:oneOf        ( "entirelyAboveWaterSurface" "substantiallyAboveWaterSurface" "substantiallyAboveAndBelowWaterSurface" "substantiallyBelowWaterSurface" "entirelyBelowWaterSurface" "temporarilyAboveAndBelowWaterSurface" ) ;
                                ] ;
        skos:definition  "RelativeToWater enumerates the spatial relations of a city object relative to the water surface in a qualitative way."@en .

[nataschake]

Hi @DiegoVinasco , I try to reproduce the generation for CityGML3.0 having the source file test-data/UML/CityGML_3.0-workspaces-documents_shapechange-export.xml. I am particularly interested in enumerations and codelists generation, and I checked that in the source file these data exist. No one enumeration appears in the resulting files, so if to browse in Protege no individuals are there except for + and -. How did you ensure the enumeration conversion?

[DiegoVinasco]

Hi @nataschake,

As stated above, we used the rule-owl-cls-iso191502Enumeration Shapechange rule, which produces an RDF representation of an enumeration using owl:oneOf, however, with a structure that Protégé doesn't know how to read.

When you transform your source files, what Shapechange rules do you use? Also are the enumerations missing from the produced RDF files or are they in the RDF but simply not visible in Protégé?

To visualize these enumerations in Protégé, we usually convert the RDF structure manually or use the ontologyPatcher.py python tool which can automatically fix the enumerations to be visible in Protégé.

Hopefully that makes sense. Let me know if that works for you!

[nataschake]

@DiegoVinasco, thanks for the quick response, I don't see the resulting codelist and enumeration values neither in Protege nor in TTL in a text editor. The classes for codelists and enumerations are created, but they make the ontology inconsistent (subclasses of owl:Nothing). Here are the settings for rules

       <EncodingRule name="CityGML_Lite_RDF_Encoding_Rules_w_union">
          <rule name="rule-owl-pkg-ontologyName-iso191502"/>
          <!-- <rule name="rule-owl-pkg-ontologyName-code"/> -->
          <!-- <rule name="rule-owl-pkg-singleOntologyPerSchema"/> -->
          <rule name="rule-owl-pkg-importISO191502Base"/>
          <rule name="rule-owl-cls-iso191502IsAbstract"/>
          <!-- <rule name="rule-owl-cls-enumerationAsCodelist"/> -->
          <rule name="rule-owl-cls-iso191502Enumeration"/>
          <rule name="rule-owl-cls-encode-featuretypes"/>
          <rule name="rule-owl-cls-encode-objecttypes"/>
          <rule name="rule-owl-cls-encode-mixintypes"/>
          <rule name="rule-owl-cls-encode-datatypes"/>
          <rule name="rule-owl-cls-encode-basictypes"/>
          <!-- <rule name="rule-owl-cls-codelist-external"/> -->
          <rule name="rule-owl-cls-codelist-19150-2"/>
          <!-- <rule name="rule-owl-cls-codelist-19150-2-skos-collection"/>
          <rule name="rule-owl-cls-codelist-19150-2-differentIndividuals"/> -->
          <rule name="rule-owl-cls-generalization"/>
          <rule name="rule-owl-cls-union"/>
          <rule name="rule-owl-prop-general"/>
          <rule name="rule-owl-prop-iso191502-naming"/>
          <rule name="rule-owl-prop-localScopeAll"/> 
          <!-- <rule name="rule-owl-prop-globalScopeAttributes"/> -->
          <!-- <rule name="rule-owl-prop-globalScopeByUniquePropertyName"/> -->
          <!-- <rule name="rule-owl-prop-globalScopeByConversionParameter"/> -->
          <rule name="rule-owl-prop-multiplicityAsQualifiedCardinalityRestriction"/> 
          <!-- <rule name="rule-owl-prop-multiplicityAsUnqualifiedCardinalityRestriction"/> -->
          <!-- <rule name="rule-owl-prop-voidable-as-minCardinality0"/> -->
          <!-- <rule name="rule-owl-prop-range-global"/> -->
          <rule name="rule-owl-prop-range-local-withUniversalQuantification"/>
          <rule name="rule-owl-prop-mapping-compare-specifications"/>
          <!-- <rule name="rule-owl-all-constraints-humanReadableTextOnly"/> -->
          <!-- <rule name="rule-owl-all-constraints-byConstraintMapping"/> -->
        </EncodingRule>
      </rules>

Additionally, I created a file CityGML3.0EnumMapEntries.xml to list enumerations, similar to CityGML3.0CodeListMapEntries.xml available in UD-Graph settings, and mentioned it in <xi:include> as

 <xi:include href="./CityGML3.0EnumMapEntries.xml"/>

<rdfMapEntries xmlns="http://www.interactive-instruments.de/ShapeChange/Configuration/1.1">
  <RdfTypeMapEntry type="RelativeToTerrain" target="core:RelativeToTerrain" />
  <RdfTypeMapEntry type="SpaceType" target="core:SpaceType" />
  <RdfTypeMapEntry type="RelativeToWater" target="core:RelativeToWater" />
  <RdfTypeMapEntry type="RelationToConstruction" target="core:RelationToConstruction" />
  <RdfTypeMapEntry type="ConditionOfConstructionValue" target="core:ConditionOfConstructionValue" />
</rdfMapEntries>

In UD-Graph settings there was no such file, so might be its presence causes the behaviour described above. If you have any clue on how (not manually) to gather values of enumerations and codelists, please share it.

[DiegoVinasco]

@nataschake, I tested your encoding rules without enum map entries and indeed no code lists are generated, however, the enumerations are created in the .ttl files.

For example, this is generated in the core.ttl file:

core:RelativeToWater  rdf:type  rdfs:Datatype;
        rdfs:label       "RelativeToWater"@en;
        owl:oneOf        ( "entirelyAboveWaterSurface" "substantiallyAboveWaterSurface" "substantiallyAboveAndBelowWaterSurface" "substantiallyBelowWaterSurface" "entirelyBelowWaterSurface" "temporarilyAboveAndBelowWaterSurface" );
        skos:definition  "RelativeToWater enumerates the spatial relations of a city object relative to the water surface in a qualitative way."@en .

Unfortunately, Protégé doesn't know how to read this as an enumeration, but if you run the patching tool I mentioned, it should update the structure to work with Protégé.

As for the code lists, we haven't found a way to generate them automatically. We always get the following error message:

...
PF-E java.lang.NullPointerException encountered. Processing was interrupted unexpectedly.
P ... <no exception message available>
java.lang.NullPointerException
        at de.interactive_instruments.ShapeChange.Target.Ontology.OntologyModel.addCodelist(OntologyModel.java:3013)
        at de.interactive_instruments.ShapeChange.Target.Ontology.OntologyModel.createClasses(OntologyModel.java:589)
        at de.interactive_instruments.ShapeChange.Target.Ontology.OWLISO19150.writeAll(OWLISO19150.java:1011)
        at de.interactive_instruments.ShapeChange.Converter.executeTargets(Converter.java:831)
        at de.interactive_instruments.ShapeChange.Converter.executeTransformations(Converter.java:645)
        at de.interactive_instruments.ShapeChange.Converter.convert(Converter.java:321)
        at de.interactive_instruments.ShapeChange.Converter.convert(Converter.java:159)
        at de.interactive_instruments.ShapeChange.Main.main(Main.java:110)

This is probably be due to one of two things, either:

1. The CityGML 3.0 codelists weren't created properly
2. There is a bug in Shapechange when transforming codelists

I've created this issue on the ShapeChange Github to get some help. But in the meantime, you can try to use the code lists we have created manually, available here.

[DiegoVinasco]

Hi @nataschake, I've heard back from the ShapeChange team and it looks like the codelist generation works if you enable the rule-owl-pkg-singleOntologyPerSchema rule!

There is a bug with the rule-owl-pkg-ontologyName-iso191502 that prevents codelists from generating with rule-owl-cls-codelist-19150-2 that should be fixed with ShapeChange 4.0.0. In the meantime, using the rule I mentioned fixes the problem and doesn't change the generated ontologies since CityGML 3.0 only has one schema.

[nataschake]

@DiegoVinasco Many thanks! With the rule-owl-pkg-ontologyName-iso191502 and rule-owl-pkg-singleOntologyPerSchema enabled both enumerations and codelists are generated as expected.