section sorting

[VladimirAlexiev]

In RDFLib/rdflib#2880 I wrote some requirements for a pretty-printer.
One of them is about the major sections of an (ontology) file.
I would like them in this order:

• prefixes
• ### Ontology: owl:Ontology
  • also creator/contributor info (eg foaf:Person, schema:Organization etc) and any other subsidiary nodes describing the ontology: but how do you discover them reliably? Tracing from owl:Ontology?
• ### Classes: rdfs:Class, owl:Class
• ### Datatypes: rdfs:Datatype
• ### Properties: rdf:Property, owl:ObjectProperty, owl:DatatypeProperty, owl:AnnotationProperty, owl:FunctionalProperty, owl:InverseFunctionalProperty, owl:ReflexiveProperty, owl:IrreflexiveProperty, owl:SymmetricProperty, owl:AsymmetricProperty, owl:TransitiveProperty
  • The same prop may carry several of these classes, be careful not to list it multiple times
• ### Individuals: owl:NamedIndividual, skos:ConceptScheme, skos:Concept
• ### Axioms: owl:Axiom
• ### Disjointness: owl:AllDisjointClasses, owl:AllDisjointProperties, owl:AllDifferent
• ### External Terms: Sort external terms last #20
  • Do we want to make 5-6 sections per external ontology? NO
  • Since there are usually few external terms, better to keep them all in one section, ordered alphabetically by prefix
• Print the above ### comments as section headers (to delineate them).
  • Use two empty lines before a header, and one empty line after it.
  • If a section is empty, do not print its header.

The sources of the above list are:

• add more sorting options in longturtle serializer RDFLib/rdflib#2880
• https://www.w3.org/TR/owl2-quick-reference/
• https://atextor.de/owl-cli/main/snapshot/usage.html#write-options`--subjectOrder` Sort order for subjects by type

This library nearly does it with the --subjectOrder option, with default value: [rdfs:Class, owl:Ontology, owl:Class, rdf:Property, owl:ObjectProperty, owl:DatatypeProperty, owl:AnnotationProperty, owl:NamedIndividual, owl:AllDifferent, owl:Axiom].

However:

• move rdfs:Class next to owl:Class (after owl:Ontology)
• The list needs to be subdivided into sublists. As you see above, there are 11 types that identify a "Property". All properties should be sorted alphabetically because:
  • The user won't be able to comprehend or recognize 11 subsections
  • Some AnnotationProperties are often used as regular properties (eg rdfs:label of a business object)
  • Many props carry several of these types, eg AnnotationProperty+DatatypeProperty or ObjectProperty+FunctionalProperty
  • Good naming conventions name related props in a related way, eg
    • status: ObjectProperty with values from a certain ConceptScheme
    • statusOther DatatypeProperty string
• The list needs to be extended with more types, as shown above.

[atextor]

Hi @VladimirAlexiev ,
I understand the point of your proposal, however I think it's very OWL-specific. I'd prefer keeping the formatter implementation itself agnostic to certain vocabularies, including OWL, but instead make things like this configurable. My takeaway is that we need:

• multiple sections, each of which contains the statements for elements of certain types
• to be able to name each section
• an option to add header comments to sections
• to clarify how elements should be handled that happen to be part of multiple sections

The second-to-last point I don't get, I think naming conventions used in an RDF document or OWL ontology (should) have nothing to do with how the document is formatted.

[VladimirAlexiev]

I agree, we need flexible configurations. - Eg the above says nothing about formatting SHACL. Do we put NodeShape into a section like "Classes" and PropertyShapes into a section like "Properties"?

• A further complication is that people often put RDFS, OWL and SHACL into one file. So it makes sense for the configuration (section definitions) to he more universal.

My point about prop naming is this:

• I want "status" and "statusOther" to sort next to each other (ie alphabetically)
• even though the former is an ObjectProperty and the latter is a DataProperty

[atextor]

I see. That would happen automatically if both are assigned to the "Properties" section. However, if you have both a "DataProperties" and an "ObjectProperties" section I wouldn't know how you'd configure that. We probably would need a separate configuration option à la "namingOverridesSections" or similar, but you'd need to set this flag for separate elements ("status" and "statusOther" in this case), or by (regex) pattern, or..?

But if this issue introduces the concept of sections that would already valuable, a separate issue on how to do or configure the assignment of elements to sections could be created.

[VladimirAlexiev]

Let's have just one way to configure sorting. The command-line syntax could be something like this:

-section "Classes=rdfs:Class, owl:Class, sh:NodeShape"
-section "Properties=rdf:Property, owl:ObjectProperty, owl:DatatypeProperty, owl:AnnotationProperty, owl:FunctionalProperty, owl:InverseFunctionalProperty, owl:ReflexiveProperty, owl:IrreflexiveProperty, owl:SymmetricProperty, owl:AsymmetricProperty, owl:TransitiveProperty, sh:PropertyShape"

The java structure should be a hash of arrays.

[VladimirAlexiev]

@atextor Can you please make this quick fix:
move rdfs:Class next to owl:Class (after owl:Ontology)

[atextor]

@atextor Can you please make this quick fix: move rdfs:Class next to owl:Class (after owl:Ontology)

You mean in the default settings? Would it help you for your current use case to use the existing --subjectOrder switch? I.e.:

--subjectOrder owl:Ontology --subjectOrder rdfs:Class --subjectOrder owl:Class --subjectOrder rdf:Property --subjectOrder owl:ObjectProperty --subjectOrder owl:DatatypeProperty --subjectOrder owl:AnnotationProperty --subjectOrder owl:NamedIndividual --subjectOrder owl:AllDifferent --subjectOrder owl:Axiom

[VladimirAlexiev]

Yes, i mean the default

[atextor]

Changed the default subjectOrder: 6765eaa

Update: The change is in 1.2.12

[VladimirAlexiev]

• I want to try the new release but I'm ashamed to admit I can't build java, especially between two projects. Could you do make frequent binary releases owl-cli#21 ?
• Custom sorting gave me trouble: prefixes trouble when using --subjectOrder #27

[VladimirAlexiev]

• I built owl-cli from source (had some trouble on windows: how to build on Windows (troubles with Cygwin) owl-cli#22)
• But because the source release of turtle-formatter is not rolled into owl-cli, that had no effect
• So I'm awaiting the merge of the two projects eagerly

>d:\graalvm\bin\java -jar c:\prog\bin\owl-cli-snapshot.jar --version
owl-cli version: snapshot build date: 2024-09-17 19:15:41

>d:\graalvm\bin\java -jar c:\prog\bin\owl-cli-snapshot.jar write -i rdfxml ../source/CGMES-NC/r2.3/ap-voc/rdf/SensitivityMatrix-AP-Voc-RDFS2020.rdf CGMES-NC/ttl/SensitivityMatrix-AP-Voc-RDFS2020.ttl

>grep "^[a-z]" CGMES-NC/ttl/SensitivityMatrix-AP-Voc-RDFS2020.ttl
cim:Contingency a rdfs:Class ;
cim:Date a rdfs:Class ;
cim:DateTime a rdfs:Class ;
cim:Float a rdfs:Class ;
cim:IdentifiedObject a rdfs:Class ;
cim:String a rdfs:Class ;
nc:AssessedElement a rdfs:Class ;
nc:ControllableQuantity a rdfs:Class ;
nc:GridStateAlteration a rdfs:Class ;
nc:ObservableQuantity a rdfs:Class ;
nc:ObservableQuantityKind a rdfs:Class ;
nc:RemedialAction a rdfs:Class ;
nc:SensitivityFactor a rdfs:Class ;
nc:SensitivityMatrix a rdfs:Class ;
nc:SensitivityMatrixKind a rdfs:Class ;
profcim:IRI a rdfs:Class ;
profcim:StringFixedLanguage a rdfs:Class ;
profcim:StringIRI a rdfs:Class ;
profcim:URL a rdfs:Class ;
sm:Ontology a owl:Ontology ;  <<<<<<<<
cim:IdentifiedObject.description a rdf:Property ;
cim:IdentifiedObject.mRID a rdf:Property ;
cim:IdentifiedObject.name a rdf:Property ;
nc:AssessedElement.ObservableQuantity a rdf:Property ;
nc:Contingency.ObservableQuantity a rdf:Property ;
nc:ControllableQuantity.GridStateAlteration a rdf:Property ;
nc:ControllableQuantity.RemedialAction a rdf:Property ;
nc:ControllableQuantity.SensitivityFactor a rdf:Property ;
nc:ControllableQuantity.value a rdf:Property ;
nc:GridStateAlteration.ControllableQuantity a rdf:Property ;
nc:ObservableQuantity.AssessedElement a rdf:Property ;
nc:ObservableQuantity.Contingency a rdf:Property ;
nc:ObservableQuantity.SensitivityFactor a rdf:Property ;
nc:ObservableQuantity.observableQuantityKind a rdf:Property ;
nc:RemedialAction.ControllableQuantity a rdf:Property ;
nc:SensitivityFactor.ControllableQuantity a rdf:Property ;
nc:SensitivityFactor.ObservableQuantity a rdf:Property ;
nc:SensitivityFactor.SensitivityMatrix a rdf:Property ;
nc:SensitivityFactor.value a rdf:Property ;
nc:SensitivityMatrix.SensitivityFactor a rdf:Property ;
nc:SensitivityMatrix.kind a rdf:Property ;
nc:ObservableQuantityKind.activePower a nc:ObservableQuantityKind ;
nc:ObservableQuantityKind.reactivePower a nc:ObservableQuantityKind ;
nc:ObservableQuantityKind.voltageAngle a nc:ObservableQuantityKind ;
nc:ObservableQuantityKind.voltageMagnitude a nc:ObservableQuantityKind ;
nc:SensitivityMatrixKind.other a nc:SensitivityMatrixKind ;
nc:SensitivityMatrixKind.uniformLoad a nc:SensitivityMatrixKind ;
nc:SensitivityMatrixKind.uniformNode a nc:SensitivityMatrixKind ;
nc:SensitivityMatrixKind.zoneToSlack a nc:SensitivityMatrixKind ;
sm:Package_DocSensitivityMatrixProfile a cims:ClassCategory ;
sm:Package_SensitivityMatrixProfile a cims:ClassCategory ;