-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RDF turtle generation of enumerations does not load correctly in protege #15
Comments
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. |
Hi @nataschake, As stated above, we used the 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! |
@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). <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 <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. |
@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: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:
This is probably be due to one of two things, either:
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. |
Hi @nataschake, I've heard back from the ShapeChange team and it looks like the codelist generation works if you enable the There is a bug with the |
@DiegoVinasco Many thanks! With the |
Using the
rule-owl-cls-iso191502Enumeration
rule, Shapechange transforms enumerations into :But protege does not read datatypes with
owl:oneOf
declarations unless they are in the form of :The text was updated successfully, but these errors were encountered: