CommonCoreOntologies
CommonCoreOntologies copied to clipboard
DIA Ontology team issues and recommendations
This list is provided to capture the majority of issues and recommendations we have regarding CCO. Some of these points have been made in other threads, but are included here to provide a full list from our perspective.
-
We would like to request that the entity TARGET ROLE be made a sub-class of ROLE. Rationale provided in thread on TARGET #84 . a. We recommend that the definition be something like: "A Role that inheres in an entity by virtue of that entity having been designated by some appropriate authority against which some action is to be taken." Justification- this structure aligns with the DoD concept of some entity being designated a target of some action. However, the action is general so anyone could target the entity for any reason.
-
We recommend that an entity for COMPUTER PROGRAM be created as a Directive ICE, and that the concretized version of the program, currently labeled as COMPUTER PROGRAM be given the label something like "COMPUTER PROGRAM ARTIFACT." In other words, we understand the entity currently labeled as COMPUTER PROGRAM that exists in that place in the taxonomy should be there, but it should be relabeled as an artifact of some type since the program is the set of instructions which could be coded on any artifact (similar to a story that could be contained in a book, disk, etc).
-
We recommend that any term with a definition from wikipedia be annotated with a definition from a more authoritative source if possible.
-
We suggest that the term SYSTEM be added under OBJECT AGGREGATE. Addressed in Issue 87 as well.
-
We recommend that only the Core module be called "Common Core" and that the other modules be called just "Common X module" or follow a similar convention. For example, "Common Cyber domain module" could be the name of the module for cyber operations built according to BFO and CCO. Rationale- this would reduce confusion between modules developed according to CCO and the Core Ontology itself. Would also allow for more flexibility for working on the modules that are no codified in the standard, and allow for more development of "common modules" that are created by other organizations following BFO/CCO (the core part thereof).
-
In the mil ops domain, we recommend renaming "OBJECTIVE" to "OBJECTIVE STATEMENT" since it is an ICE regarding the articulation of a desired end state. An OBJECTIVE would then be the "picture" of the desired end state itself and probably some kind of ontology module like a state of an object at a future time T. Thank you, The DICO Team
I'm a third party in this discussion, but I have a few thoughts:
Re: 1. I'm not opposed in principle to representing a target as an entity with a target role, but that wouldn't translate to moving the CCO Target class (the entity that is the target) under BFO role. That'd be a "category mistake," to borrow Ryle's phrase. So wouldn't the recommendation be, rather, to add Target Role as a type of role, and then to define Target as something having that role? IIRC, an older version of CCO did just that, and this was replaced by "is object of some Act of Targeting" due to concerns that this would lead, in principle, to an explosion of role types.
Re: 2. This is really a broader and much-discussed issue of how to understand ICEs generally: Are they "thin" (pure content, irrespective of any form that information might take) or "thick" (content plus form)? Is a report in English and Russian the same content entity across the translations, or different content entities that are simply about the same portion of reality? To my knowledge, CCO and IAO adopt different approaches. But given the way CCO does model ICEs, I don't see how the recommended change to Computer Program would be possible. (Though your recommendation would make sense in the IAO approach.)
@bdonohue29 you make a great point regarding the entity TARGET. In fact, we do actually use the term TARGET ROLE in DICO so I have updated this thread accordingly. Additionally, your comment would suggest that at TARGET might best be captured as a defined class representing something like "an ENTITY that has been given the role of TARGET ROLE." This might actually resolve Alan R's original concern about the placement of TARGET at such a high level in a taxonomy.
I also edited point 2 to be a bit clearer. I think that might resolve your point there as well.
Agree that addition of Target Role
is the correct solution. And it is consistent with our recent additions of Part Role
and System Role
.
@harefb Computer Program
is curated in the Cyber Ontology, where we also have Computer Program Artifact Model
.
It's probably best to move the discussion over to the Cyber repo tracker. Unless you'd also like to see those terms moved into the CCO mid-level?
And to clarify: Is the concern more of a labeling issue, e.g., just keep all other things the way they are and change the labeling schema? Or, are you suggesting to move/redefine all the current subclasses of Computer Program
to be subs of Artifact Model
? In other words, do all the work of differentiating types of "Computer Programs" as types of Directive Information Content Entities? If that is the case, then @bdonohue29 comment is quite relevant and the resolution of that request will require a lot more discussion.
we recommend renaming "OBJECTIVE" to "OBJECTIVE STATEMENT"
'Statement' can be ambiguous. Perhaps changing the label to "Objective Specification" is more clear?
My responses after “>>”
Agree that addition of Target Role is the correct solution. And it is consistent with our recent additions of Part Role and System Role.
noted. Thank you.
@harefbhttps://github.com/harefb Computer Program is curated in the Cyber Ontology, where we also have Computer Program Artifact Model.
It's probably best to move the discussion over to the Cyber repo tracker. Unless you'd also like to see those terms moved into the CCO mid-level?
That is fine. We are not requesting that the term be moved to CCO core.
And to clarify: Is the concern more of a labeling issue, e.g., just keep all other things the way they are and change the labeling schema? Or, are you suggesting to move/redefine all the current subclasses of Computer Program to be subs of Artifact Model? In other words, do all the work of differentiating types of "Computer Programs" as types of Directive Information Content Entities? If that is the case, then @bdonohue29https://github.com/bdonohue29 comment is quite relevant and the resolution of that request will require a lot more discussion.
I think it is more of a labeling issue on the current term but we would also recommend creation of a new ICE. As I stated, we concur there is definitely a concretized version of the program on some artifact. That would be the existing entity. But the program is like a story. It exists independent of the physical medium upon which it is encoded/concretized. Therefore, changing the existing term label would drive codification of the old label as an ICE. So if these two changes are made (change to current label and creation of corresponding ICE), then the DICO will decrement terms accordingly.
we recommend renaming "OBJECTIVE" to "OBJECTIVE STATEMENT"
'Statement' can be ambiguous. Perhaps changing the label to "Objective Specification" is more clear?
That is fine. We could then just have an alternate term if the Defense Intel or JADC2 communities request it.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/CommonCoreOntology/CommonCoreOntologies/issues/114#issuecomment-802292123, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARLCKT3GVBEOR5LXTA5DIMLTEJSGHANCNFSM4ZJQHHOA.
This communication (including any attachments) may contain information that is proprietary, confidential or exempt from disclosure. If you are not the intended recipient, please note that further dissemination, distribution, use or copying of this communication is strictly prohibited. Anyone who received this message in error should notify the sender immediately by telephone or by return email and delete it from his or her computer.