Ontology Publishing

[Sveino]

As we are improving the CGMES and NC ontology, and added ontology information is not available in Sparx Enterprise Architect it is very important that we find a good way to make it possible to domain architects to be able to navigate in the ontology. Related but not the same, it the ability to resolve the URL.

Publishing the ontologies on GitHub makes it possible for machine-to-machine integration. It is advantage that the domain architect interface is provided on top of the RDFS and SHACL so that we are not having any versioning/synchronisation issues.

There are many tools out there, and currently we have CIM published on the following ontologies viewers
• CIM Ontology | The Common Information Model Ontology (puffinsemantics.com)
• Ontology Documentation (tno.nl)

The second we know the source and it is not maintained. That is a big problem, but if we, ENTSO-E and the general CIM community, is not providing similar support they will use these sources.

At UCA we have started the work with making CIM namespace resolvable:

• https://github.com/cimug-org/cim-profiles/tree/master/grid - download the rdf artifacts
• https://github.com/cimug-org/artifacts - plan to be the resolvable host
• https://github.com/cimug-org/cpsm-docs https://cpsm-docs.ucaiug.io/ using LinkML

For ENTSO-E we are plannig to use the following:

• The www.model4powersystem.eu domain intends at referencing the power system models, or Individual Grid Model (IGM) and Common Grid Model (CGM) as stated in the network code.

• The www.cim4.eu domain is though to refer structure metadata that describe classes, attributes and association and organisation and relationship within a dataset to form an information model or ontology.

• The www.referencedata.eu will be used for referencing instance data that is common for one or more business process in a semantic web structure and format (e.g., referencing the electrical market bidding zone).

Only https://energy.referencedata.eu/ is currently in use. It needs however to be moved to an ENTSO-E GitHub.

[VladimirAlexiev]

• let's turn this into a task?
• an ontology must be accessible from its semantic URL, with content negotiation. See https://vocab.getty.edu/doc/#Semantic_Resolution for guidance that we provided to the Getty Trust many years ago (it's still valid)
  • By default, serve HTML
  • Support RDF serialization formats, at least rdfxml, turtle, jsonld
  • Optionally, implement file extensions
  • Implement semantic redirects (303)
  • Validate with Vapor
• github is a bad choice of hosting platform since it cannot do content negotiation and doesn't return appropriate content type
  • Github Pages might be able to serve content types, I don't know
  • rawgit2.com serves Github files with content type, but I think doesn't have content negotiation
• Many people do it with https://w3id.org. This is managed on github (you
  • Eg https://w3id.org/lbd/aec3po/ is an AECO ontology I participated in. It should do content negotiation, which is handled by redirecting to https://ci.mines-stetienne.fr/aec3po/
• How to produce HTML reference documentation?
  • Many people use LODE or PyLODE, or the wider WIDOCO tools. Eg AEC3PO is done with pyLODE (I think)
  • EDMC uses their own tooling for publishing FIBO. https://github.com/Sveino/Inst4CIM-KG/blob/develop/rdfs-improved/README.md#edmc-tools-for-serialization-diff-hygiene-checks-publication: is a link to a paper that describes their tools
  • (https://vocab.getty.edu/ontology was published with Parrot, it's a nice colorful thing but I think not supported anymore)

Also:

• Each term is supposed to be accessible from its semantic URL
• Part of its metadata should be rdfs:seeAlso allowing semantic web crawlers to find its ontology, and all its "sibling" terms
• But Duplication Between Ontologies #5 makes this very hard to achieve: most terms are in the cim: eu: namespaces, and some of them are redundantly defined in 20-30 ontologies.

[VladimirAlexiev]

if you want to use Github Pages:

Github Pages might be able to serve content types

It does, eg

curl -vI https://ekgf.github.io/dprod/dprod.jsonld

shows the appropriate content-type:

content-type: application/ld+json

cannot do content negotiation and doesn't return appropriate content type

EKGF/dprod#52 is relevant here.