AGOP - Specification

AGLDWG ontology publication

The Australian Government Linked Data Working Group (AGLDWG) provides guidance to ontology publishers that attempt to ensure that their ontologies work well with other Australian Govenment ontologies and are able to be managed in standard ways. This means their ontologies should:

• integrate easily with other Australian Government ontologies
• be able to have automated documentation generated from RDF source
• be able to have IRI assigned to them easily

In practice, this means the ontologies need certain, fairly basic, DCAT2-style metadata supplied with them, and they need certain per-element annotations for the classes and properties they define. There is also a general expectation that OWL modelling is conducted in a fairly common way with "common" being as per the majority of major ontologies available from standards bodies such as the World Wide Web Consortium (W3C) and the Open Geospatial Consortim (OGC).

This document as a specification

This document is part of a formal profile of OWL. OWL is a standard and a profile is also a standard but one whose dependencies on other standards and whose parts are defined. This profile is described using The Profiles Vocabulary (PROF).

The profile this document is part of - the Australian Government Ontology Profile (AGOP) - is defined at https://linked.data.gov.au/def/agop and, by definintion, anything that conforms to this profile also conforms to OWL. Also, this profile is aligned with the AGLDWG's IRI Guidelines which have expectations of metadata for definitional resources, such as ontologies, for which IRIs are requested.

This document plays the role of specification within the AGOP, that it it notmatively defines the rules that the profile contains. It does so in human-redable terms (i.e. in English) and not in machine-readble terms. The role specification is formally defined with respect to profile elements, see it and other profile resource roles at:

• specification - within the context of a Profiles Vocabulary resource role

Validators

There are many possible machine-readable or machine-actional expressions of this specification that can be used to validate if data conforms to this profile. Validators, according to PROF, should be indicated as such with the role validation, also defined in the voabulary linked to above. This profile defines a resource with role validation which is a SHACL Shapes document that can be used with validation tools such as pySHACL. Other resources withrole validation could be defined. This profile's sole validator is at:

• https://linked.data.gov.au/def/agop/validator

This profile happens to define only one resource with role validation but it could define either multiple validation resources in one format - perhaps multiple SHACL files for multiple classes to validate - or multiple standards' validators, such as XML validators, JSON Schema ShEx (another RDF data validator language). This profile could also not define every validator it needs but instead inherit validators from things this profile profiles, e.g. OWL. If we had OWL validators to hand (we don't) we would just define this profile's unique validators and import OWL's. Since we don't have OWL validators, we have included all the rules we want, in total, in this specification and within the accompanying validator.

In addition to using this profile's validation resource directly - with pySHACL or similar, as indicated above - data (instances of ontologies that people want to publish) can be validated against this profile by using tools that offer validatio by profile. Such tools find all the relevant validators for a given profile - whether there's one, many, inherited etc. - and compound them into a single validation resource and use that. There is currently only one such tool available:

• Cheka - an open source, validation by profile, library

Cheka can be used online within the ChekaBox service:

• ChekaBox - a managed instance of Cheka that also contains catalogues of profile for use

That instance of ChekaBox come pre-loaded with this profile and many others so can easily be selected for use.

2.1 Presentation

Ontologies must be presented according to Linked Data principles so that both humans and machine can access them.

2.1.1 An ontology MUST be published online in both human- and machine-readable formats with the human-readable format being HTML, PDF or a textual format readable online within a web browser and the mcahine-readable format being one or many of the commonly used RDF formats, such as Turtle or JSON-LD.

The AGLWD will not test for this requirment directly but may seek assurances from the ontology publisher that this condition is met.

2.1.2 An ontology MUST be available online - resolvable - in accordance with normal Australian Government Internet resource availability expectations and must remain online for the length of time for which the AGLDWG's persistent IRI is expected to resolve to it.

2.1.3 An ontology MUST accord with the publication guidelines of both the Austrlaian Government in general and with the publication guidelines of the publishing organisation.

The AGLWD will not test for this requirment directly but may seek assurances from the ontology publisher that this condition is met.

2.2 Ontology

This subsection lists requriments for basic DCAT-style metadata for the owl:Ontology class instance, i.e. the ontology as a whole.

2.2.1 An ontology MUST have one and only one title indicated by a skos:prefLabel property linking to a textual literal value, in English.

skos:prefLabel is to be used rather than rdfs:label or dcterms:title or other, similar, titling properties. Inferencing rules in SKOS and elsewhere indicate that rdfs:label or dcterms:title may be inferred from skos:prefLabel.

2.2.2 An ontology MUST have one and only one definition indicated by a skos:definition property linking to a text literal value, in English.

skos:definition is to be used rather than rdfs:comment or dcterms:description or other, similar, description properties. Inferencing rules in SKOS and elsewhere indicate that rdfs:comment or dcterms:description may be inferred from skos:definition.

2.2.3 An ontology MUST have one and only one publisher indicated by a dcterms:publisher property that links to a publishing agent, likely a government agency, identified by an IRI that MUST be catalogued by the Australian Government Linked Data Working Group within their /org/ register.

Identifiying publishing agents with literal values, e.g. <x> dcterms:publisher "Some Agency" is prohibited and that IRIs for publishing agents may easily be registered with the AGLDWG. Example of existing registered agent IRIs are:

• https://linked.data.gov.au/org/agldwg - Australian Government Linked Data Working Group
• https://linked.data.gov.au/org/anu - Australian National University
• https://linked.data.gov.au/org/csiro - CSIRO
• https://linked.data.gov.au/org/finance - Department of Finance
• https://linked.data.gov.au/org/ga - Geoscience Australia

2.2.4 An ontology MUST have one or more creator indicated by a dcterms:creator property that links to creating agents, which may be persons or organisations. They MUST be identified by IRI that must either be catalogued by the Australian Government Linked Data Working Group within their /org/ register (for Organisation) or have basic schema.org metadata supplied for it (for Persons) with sdo:name at a minimum and sdo:email suggested.

2.2.5 An ontology MUST have one and only one created date indicated by a dcterms:created property that links to an xsd:date literal or specialised datatype thereof for the date on which the ontology was first created.

2.2.6 An ontology MUST have one and only one modified date indicated by a dcterms:modified property that links to an xsd:date literal or specialised datatype thereof for the date on which the ontology was last modified.

Other date properties, such as dcterms:date should not be used.

2.2.7 An ontology MUST have one and only one license (or licence) indicated by a dcterms:license property that links to a license identified by an IRI.

Any resolvable IRI may be used to identify a license, for instance, the following IRIs provided by Creative Commons for their licenses may be used:

• https://creativecommons.org/licenses/by/4.0/ - CC Attribution 4.0 International (CC BY 4.0)
• https://creativecommons.org/licenses/by-sa/3.0/au/ - CC Attribution-ShareAlike 3.0 Australia (CC BY-SA 3.0 AU)
• https://creativecommons.org/licenses/by/2.5/ - CC Attribution 2.5 Generic (CC BY 2.5)

However, the AGLDWG may publish a catalogue of acceptable licenses that must be used after that point.

2.2.8 An ontology MUST have one and only one rights statement that includes copyright information indicated by a dcterms:rights property that links to a string literal value. The string value SHOULD of the form "© AGENCY NAME, YEAR" or "© Australian Government, YEAR".

2.2.9 An ontology SHOULD have one and only one version identifier indicated by a owl:versionIRI property that links to a unique IRI for the version of the ontology.

2.2.10 An ontology SHOULD have one and only one version information statement indicated by a owl:versionInfo property that links to a string literal value containing notes for the version of the ontology.

2.2.11 An ontology that is presented or managed online using an online version control repository SHOULD indicate the location of that repository with the sdo:codeRepository property that links to the IRI of the online version control repository repsenseted as a literal value of type xsd:anyURI.

2.3 Classes

2.3.1 Each class defined by the ontology MUST indicate that it is defined by it by a rdfs:isDefinedBy property indicating the IRI of the ontology.

2.3.2 Each class described within the ontology MUST have one and only one title indicated by a skos:prefLabel property linking to a textual literal value, in English. the title SHOULD be rendered in natural English and if made of multiple words, spaces should be used between the words.

skos:prefLabel is to be used rather than rdfs:label or dcterms:title or other, similar, titling properties. Inferencing rules in SKOS and elsewhere indicate that rdfs:label or dcterms:title may be inferred from skos:prefLabel.

2.3.3 Each class described within the ontology MUST have one and only one definition indicated by a skos:definition property linking to a text literal value, in English.

skos:definition is to be used rather than rdfs:comment or dcterms:description or other, similar, description properties. Inferencing rules in SKOS and elsewhere indicate that rdfs:comment or dcterms:description may be inferred from skos:definition.

2.3.4 Each class described within the ontology SHOULD indicate any relationships to classes in existing common ontologies or ontologies published by by Australian Government entities with the appropriate RDFS or OWL properties.

Newly-defined classes may not have any natural relationships to other classes however, if they do, they should idicate such relatioships with properties such as rdfs:subClassOf or owl:equivalentClass etc.

2.4 Properties

2.4.1 Each property defined by the ontology MUST indicate that it is defined by it by a rdfs:isDefinedBy property indicating the IRI of the ontology.

2.4.2 Each property described within the ontology MUST have one and only one title indicated by a skos:prefLabel property linking to a textual literal value, in English. the title SHOULD be rendered in natural English and if made of multiple words, spaces should be used between the words.

skos:prefLabel is to be used rather than rdfs:label or dcterms:title or other, similar, titling properties. Inferencing rules in SKOS and elsewhere indicate that rdfs:label or dcterms:title may be inferred from skos:prefLabel.

2.4.3 Each property described within the ontology MUST have one and only one definition indicated by a skos:definition property linking to a text literal value, in English.

skos:definition is to be used rather than rdfs:comment or dcterms:description or other, similar, description properties. Inferencing rules in SKOS and elsewhere indicate that rdfs:comment or dcterms:description may be inferred from skos:definition.

2.4.4 Each property described within the ontology SHOULD indicate any relationships to property in existing common ontologies or ontologies published by by Australian Government entities with the appropriate RDFS or OWL properties.

Newly-defined property may not have any natural relationships to other properties however, if they do, they should idicate such relatioships with properties such as rdfs:subPropertyOf or owl:equivalentProperty etc.

2.5 Namespaces

Ontologies frequently make use of multiple namespaces for the ontology elements that they import, extend, specialise, use as domain or rainge values or in other ways mention.

2.5.1 Each namespace indicated by a short code (QNAME or CURIE etc.) within the ontology, including those in annotation properties' literal values, MUST be defined within a namespaces table within the human-readable version of the ontology and within normal RDF namespace declarations in the machine-readable version.

Tables of namespace short codes and full IRIs are often automatically-generated in HTML versions of ontologies from RDF versions by documentation tooling.