Orphan Classes in ArtifactOntology.ttl

[Skreen5hot]

https://www.commoncoreontologies.org/ont00000170

cco:ont00000170 rdf:type owl:Class .

https://www.commoncoreontologies.org/ont00000205

cco:ont00000205 rdf:type owl:Class .

https://www.commoncoreontologies.org/ont00000253

cco:ont00000253 rdf:type owl:Class .

https://www.commoncoreontologies.org/ont00000686

cco:ont00000686 rdf:type owl:Class .

https://www.commoncoreontologies.org/ont00000958

cco:ont00000958 rdf:type owl:Class .

https://www.commoncoreontologies.org/ont00000965

cco:ont00000965 rdf:type owl:Class .

https://www.commoncoreontologies.org/ont00001341

cco:ont00001341 rdf:type owl:Class .

[johnbeve]

On/in what branch/file are you seeing this?

[Skreen5hot]

Master and Dev, ArtifactOntology.ttl

It appears that these are classes coming from imported ontologies (or imports of imports).
e.g. Common Core Ontologies Geospatial Ontology
Object Track Point
https://www.commoncoreontologies.org/ont00000170

If I materialize all imports, there is no problem. However, I am intentionally not materializing the full import closure for this project (that’s the point of using modules).

The current structure assumes full import closure. In a single working graph without that closure, these classes are effectively orphaned—i.e., they have no locally accessible superclass or grounding axioms—and this breaks in partial-closure scenarios.

[johnbeve]

@Skreen5hot Thank you for pointing this out. Looks like there are dangling orphans as you said and that should have a proper home. @mark-jensen @neilotte @APCox

[johnbeve]

@Skreen5hot
The current release structure assumes users will load declared imports. If we want to support import-free or partial-closure use cases, we need - I maintain - an additional release artifact rather than a change to the class hierarchy itself. I think this points to a legitimate packaging/documentation issue, which deserves discussion of options (and so not yet ready for the issue tracker). I seed some below. I'm also reproducing - further below - the parallel issue concerning the Agent Ontology, so we can track this in discussion.

Please weigh in: @alanruttenberg @APCox @mark-jensen @neilotte @CarterBeauBenson @cameronmore

Possible options:

• Provide standalone module releases that include the minimal scaffold needed to prevent apparent orphaning: external class declarations, relevant superclass axioms, and perhaps selected relation hierarchy axioms.
• Provide module-specific dependency-closure files, so a user can materialize only the closure needed for Geospatial, Event, Agent, etc., rather than all of CCO.

Same issue from Agent Ontology:
There is an orphan Class that should either be specified or removed:

https://www.commoncoreontologies.org/ont00000207
cco:ont00000207 rdf:type owl:Class .

https://www.commoncoreontologies.org/ont00000472
cco:ont00000472 rdf:type owl:Class .

https://www.commoncoreontologies.org/ont00000487
cco:ont00000487 rdf:type owl:Class .

https://www.commoncoreontologies.org/ont00000958
cco:ont00000958 rdf:type owl:Class .

https://www.commoncoreontologies.org/ont00000965
cco:ont00000965 rdf:type owl:Class .

https://www.commoncoreontologies.org/ont00001341
cco:ont00001341 rdf:type owl:Class .

https://www.commoncoreontologies.org/ont00001836
cco:ont00001836 rdf:type owl:ObjectProperty .

https://www.commoncoreontologies.org/ont00001809
cco:ont00001809 rdf:type owl:ObjectProperty .

https://www.commoncoreontologies.org/ont00001907
cco:ont00001907 rdf:type owl:ObjectProperty .

https://www.commoncoreontologies.org/ont00001920
cco:ont00001920 rdf:type owl:ObjectProperty .

https://www.commoncoreontologies.org/ont00001942
cco:ont00001942 rdf:type owl:ObjectProperty .