RDF graphs tend to include a mechanism for declaring namespace prefixes. JSON-LD context dictionaries are one way of specifying a set of prefixes to be used within individual graph files.
@kfairbanks, in developing context dictionaries for UCO, has had to make an assumption about how to pick the prefixes for namespaces (i.e. uco-action for https://ontology.unifiedcyberontology.org/uco/action/). This means a decision implemented in the scope of JSON-LD context construction is the authoritative set of prefixes for UCO JSON and JSON-LD users. This feels (to the submitter) like not quite the right scope, and UCO should instead make an encoding on the ontologies as the authoritative prefix.
By luck, each of the ontologies where this is relevant (i.e. supplies a class, property, or datatype) already kind of has that encoding, in an rdfs:label. However, rdfs:label doesn't quite fit the needs:
It is optionally a xsd:string (without language label) or rdf:langString (bearing language label).
UCO currently has its ontology labels as rdf:langStrings.
The RDF spec provides no upper cardinality or uniqueness limit, so it could be used any number of times and would be inappropriate to constrain.
Nothing formally constrains whether rdfs:label should be written for people or written for automated consumption. "UCO Action Ontology"@en is a legitimate label style.
To support at least the context dictionaries, UCO should add one or both of these features to each ontology in UCO (and likewise for CASE):
A skos:notation that contains the authoritative prefix, datatyped xsd:string.
A SHACL sh:declare is another mechanism that enables a prefix declaration.
However, by a consequence of the SHACL spec, this appears to be ... "virally" authoritative.
The scope of a SHACL sh:PrefixDeclaration expands beyond the ontology file in which it's declared, and is instead the entirety of importers' OWL transitive closure. SHACL Spec, 5.2.1:
"A SHACL processor collects a set of prefix mappings as the union of all individual prefix mappings that are values of the SPARQL property pathsh:prefixes/owl:imports*/sh:declare of the SPARQL-based constraint or validator. If such a collection of prefix declarations contains multiple namespaces for the same value of sh:prefix, then the shapes graph is ill-formed."
sh:PrefixDeclarations are optional mechanisms that assist with SHACL-SPARQL. It is possible to avoid their use, and instead use PREFIX SPARQL statements in any SHACL-SPARQL constraints.
The proposed UCO MIME Taxonomy includes SHACL shapes that enact constraints on skos:notation. Interpretations of SHACL severity are based on informal language from the SKOS Reference document. From [Section 6.5.2], it appears there should only be one skos:notation on a concept per datatype on the notation's literal---but, the descriptive language falls short of making this a "MUST"-level requirement.
Requirements
Requirement 1
CDO ontologies (that is, each owl:Ontology) must each declare a namespace prefix for its usage.
Requirement 2
CDO ontologies must not create sh:PrefixDeclarations for any namespaces over which they do not have authority (i.e. not having domain *.unifiedcyberontology.org, *.caseontology.org, etc.).
Risk / Benefit analysis
Benefits
skos:notation is meant to bear only one value per datatype.
A. However, this is not a "MUST"-level requirement.
sh:PrefixDeclaration makes an expansive stake to a prefix among downstream adopters of UCO. The expansiveness of this greatly assists with UCO settling the question of whether its prefixes could eschew the "uco-" pre-prefix: No, they shouldn't, because of conflicts with existing ontologies (such as UCO's time vs. OWL time).
sh:PrefixDeclaration mimics the effect of needing to do chaining imports of JSON-LD context dictionaries.
sh:PrefixDeclaration and skos:notation embrace mechanisms from existing standards, saving on design. Combining the two leads to a stronger UCO review mechanism (illustrated in Competency Question 1.2 below).
Risks
Usage of skos:notation could entail UCO needing a skos:ConceptScheme in uco.ttl. This ConceptScheme would have each UCO-developed ontology as a member.
A. While this would give the benefit of a SKOS-based uniqueness test, it would be an additional piece of technical debt passed to downstream ontologies (e.g. CASE) that would need their own ConceptScheme, largely duplicative, due to scope of authority.
Adoption of a single SKOS concept does not necessarily entail that we need to import all of SKOS. Instead, the SHACL shape pertaining to skos:notation, currently housed in the UCO MIME Taxonomy, can be brought into UCO, without necessitating a owl:import of all of SKOS.
Per SHACL Spec section 5.2.1, adoption of sh:declare would make any importer (using owl:imports) of UCO need to not use any prefix UCO uses for a different namespace. This led to Requirement 2.
A risk not necessarily scoped to this proposal is there is now another review step for using owl:imports statements: The OWL transitive closure needs to be reviewed for sh:declares causing conflicting prefixes. Theoretically SHACL-SHACL (SHACL used to review a SHACL graph) would handle this review of a monolithic ontology build.
Competencies demonstrated
Competency 1
A knowledge base has imported an ontology that imported CASE (which imports UCO). The knowledge base includes these statements:
As a development aid, sh:prefix was used in the OWL SHACL review mechanism. This proposal would nix those shapes.
Competency Question 1.2
A user is interested in knowing what ontology prefixes are defined authoritatively in the knowledge base, by merit of having a skos:notation matching a prefix.
SELECT DISTINCT ?lOntologyPrefix ?nOntology ?lOntologyNamespace
WHERE {
?nOntology
skos:notation ?lOntologyPrefix ;
.
?nPrefixDeclaration
sh:prefix ?lOntologyPrefix ;
sh:namespace ?lOntologyNamespace ;
.
}
ORDER BY ?lOntologyPrefix ?nOntology ?lOntologyIRI
Result 1.2
With the current state of UCO's develop, these would be the results:
Note that namespaces that do not provide concepts (classes, properties, or datatypes) currently do not seem like they would need a prefix declared. Hence, uco-master would not be given a sh:PrefixDeclaration. uco-co and uco-owl also do not provide concepts, but instead provide only shapes for existing concepts, so it's debatable whether they should be given a sh:PrefixDeclaration.
Solution suggestion
Remove the sh:declare block from /ontology/owl/owl.ttl.
For each UCO owl:Ontology that defines a class, property, or datatype (this would not include uco-co, uco-master, or uco-owl):
Add a sh:PrefixDeclaration, binding the prefix currently housed in rdfs:label but without the language tag.
(If also adopting skos:notation) Add a skos:notation, bearing the contents currently housed in rdfs:label but without the language tag.
Retain rdfs:label.
(If also adopting skos:notation) Import the skos:notation shape from the UCO MIME Taxonomy.
(If also adopting skos:notation) Add to UCO CI a test that sh:PrefixDeclarations within UCO are only used in "authoritative" scope.
Background
RDF graphs tend to include a mechanism for declaring namespace prefixes. JSON-LD context dictionaries are one way of specifying a set of prefixes to be used within individual graph files.
@kfairbanks, in developing context dictionaries for UCO, has had to make an assumption about how to pick the prefixes for namespaces (i.e.
uco-action
forhttps://ontology.unifiedcyberontology.org/uco/action/
). This means a decision implemented in the scope of JSON-LD context construction is the authoritative set of prefixes for UCO JSON and JSON-LD users. This feels (to the submitter) like not quite the right scope, and UCO should instead make an encoding on the ontologies as the authoritative prefix.By luck, each of the ontologies where this is relevant (i.e. supplies a class, property, or datatype) already kind of has that encoding, in an
rdfs:label
. However,rdfs:label
doesn't quite fit the needs:xsd:string
(without language label) orrdf:langString
(bearing language label).rdf:langString
s.rdfs:label
should be written for people or written for automated consumption."UCO Action Ontology"@en
is a legitimate label style.To support at least the context dictionaries, UCO should add one or both of these features to each ontology in UCO (and likewise for CASE):
skos:notation
that contains the authoritative prefix, datatypedxsd:string
.sh:declare
is another mechanism that enables a prefix declaration. However, by a consequence of the SHACL spec, this appears to be ... "virally" authoritative.The scope of a SHACL
sh:PrefixDeclaration
expands beyond the ontology file in which it's declared, and is instead the entirety of importers' OWL transitive closure. SHACL Spec, 5.2.1:sh:PrefixDeclaration
s are optional mechanisms that assist with SHACL-SPARQL. It is possible to avoid their use, and instead usePREFIX
SPARQL statements in any SHACL-SPARQL constraints.The proposed UCO MIME Taxonomy includes SHACL shapes that enact constraints on
skos:notation
. Interpretations of SHACL severity are based on informal language from the SKOS Reference document. From [Section 6.5.2], it appears there should only be oneskos:notation
on a concept per datatype on the notation's literal---but, the descriptive language falls short of making this a "MUST"-level requirement.Requirements
Requirement 1
CDO ontologies (that is, each
owl:Ontology
) must each declare a namespace prefix for its usage.Requirement 2
CDO ontologies must not create
sh:PrefixDeclaration
s for any namespaces over which they do not have authority (i.e. not having domain*.unifiedcyberontology.org
,*.caseontology.org
, etc.).Risk / Benefit analysis
Benefits
skos:notation
is meant to bear only one value per datatype. A. However, this is not a "MUST"-level requirement.sh:PrefixDeclaration
makes an expansive stake to a prefix among downstream adopters of UCO. The expansiveness of this greatly assists with UCO settling the question of whether its prefixes could eschew the "uco-" pre-prefix: No, they shouldn't, because of conflicts with existing ontologies (such as UCO'stime
vs. OWLtime
).sh:PrefixDeclaration
mimics the effect of needing to do chaining imports of JSON-LD context dictionaries.sh:PrefixDeclaration
andskos:notation
embrace mechanisms from existing standards, saving on design. Combining the two leads to a stronger UCO review mechanism (illustrated in Competency Question 1.2 below).Risks
skos:notation
could entail UCO needing askos:ConceptScheme
inuco.ttl
. ThisConceptScheme
would have each UCO-developed ontology as a member. A. While this would give the benefit of a SKOS-based uniqueness test, it would be an additional piece of technical debt passed to downstream ontologies (e.g. CASE) that would need their ownConceptScheme
, largely duplicative, due to scope of authority.skos:notation
, currently housed in the UCO MIME Taxonomy, can be brought into UCO, without necessitating aowl:import
of all of SKOS.sh:declare
would make any importer (usingowl:imports
) of UCO need to not use any prefix UCO uses for a different namespace. This led to Requirement 2.A risk not necessarily scoped to this proposal is there is now another review step for using
owl:imports
statements: The OWL transitive closure needs to be reviewed forsh:declare
s causing conflicting prefixes. Theoretically SHACL-SHACL (SHACL used to review a SHACL graph) would handle this review of a monolithic ontology build.Competencies demonstrated
Competency 1
A knowledge base has imported an ontology that imported CASE (which imports UCO). The knowledge base includes these statements:
Competency Question 1.1
A user is interested in knowing what ontology prefixes are in the knowledge base.
Result 1.1
With the current state of UCO's
develop
, these would be the results:As a development aid,
sh:prefix
was used in the OWL SHACL review mechanism. This proposal would nix those shapes.Competency Question 1.2
A user is interested in knowing what ontology prefixes are defined authoritatively in the knowledge base, by merit of having a
skos:notation
matching a prefix.Result 1.2
With the current state of UCO's
develop
, these would be the results:(Note also the difference in trailing slash.)
On adoption of this proposal, these could be the results:
Note that namespaces that do not provide concepts (classes, properties, or datatypes) currently do not seem like they would need a prefix declared. Hence,
uco-master
would not be given ash:PrefixDeclaration
.uco-co
anduco-owl
also do not provide concepts, but instead provide only shapes for existing concepts, so it's debatable whether they should be given ash:PrefixDeclaration
.Solution suggestion
sh:declare
block from/ontology/owl/owl.ttl
.owl:Ontology
that defines a class, property, or datatype (this would not includeuco-co
,uco-master
, oruco-owl
):sh:PrefixDeclaration
, binding the prefix currently housed inrdfs:label
but without the language tag.skos:notation
) Add askos:notation
, bearing the contents currently housed inrdfs:label
but without the language tag.rdfs:label
.skos:notation
) Import theskos:notation
shape from the UCO MIME Taxonomy.skos:notation
) Add to UCO CI a test thatsh:PrefixDeclaration
s within UCO are only used in "authoritative" scope.Coordination