Need ability to represent general concept of an Event #541
Comments
|
@sbarnum : Can you please clarify, with respect to For context, I ask in consideration of potential UCO alignments with other ontologies that have explored either temporal interval or event representation:
|
|
Also, @sbarnum , thank you for working through some examples. May I transcribe them to the CASE-Examples repository so they can be SHACL-reviewed and have some queries run against them? (I also noticed a few typos, just minor object-reference fixes.) |
|
@plbt5 - Can you please contextualize your feedback on the Pull Request w.r.t. |
The temporal aspect of Event can definitely be either instantaneous (liftoff of SpaceX Mission XYZ) or an interval of time (2016 Summer Olympics). It requires this flexibility and cannot be restricted to only be one or the other. |
Sure. |
That would be! Would you mind emailing it to me? |
|
I interpret an Event as something that expands and/or develops over time, a Perdurant. Furthermore, in the definition of the UcoObject I cannot find any reference to something that is not an Endurant. In this interpretation we do realize, don't we, that by subclassing the Event from the UcoObject we cannot make a distinction anymore between Endurants and Perdurants, let alone make them disjoint?! In my professional opinion, such distinction is a necessary feature for an interoperability standard to provide. As the ontologist in CDO, I don't approve of this design. A simple resolution would be to subclass the Event from the UcoThing, like the UcoObject and UcoInherentCharacterizationThing, and make those three disjoint from each other. Perdurant and endurants are related as: 'Perd has-participants End'; implying that each and every relation that exist between their individuals are grounded in this one.
(Italic concepts are abstract, i.e., cannot be instantiated but subclassed only. Colors show disjoint parts of the taxonomy.) |
Duly noted, of course we shouldn't discuss such broad feedback on the PR. I should have known better. See my copy of it here. An Action would be a particular perdurant involving persons and, potentially, a causal pattern. In that view, an Action is disjoint with objects. |
|
About the Requirements / Suggested solution concepts:
For example, the This would make for a rather simple design without more classes than necessary to specify the required distinctions. It would also diminish the identified risk by its clear separation (disjointness) between an |
The temporal aspect of If anything, these temporal aspects should be addressed separately, disjoint from the |
|
@plbt5 : If you were not aware, edits to comments on GitHub do not generate email notices. I didn't know until you mentioned it in this morning's meeting that there is now a figure accompanying your earlier remarks. Your figure uses a diagramming scheme that I don't think anyone else in CDO is familiar with. (I say that because I'm not sure how many of the terms in there stem from gUFO built-in concepts, and how many are invented for UCO.) It also seems to miss some of the current implementation state of UCO, namely that
core:UcoObject
rdfs:subClassOf core:UcoThing ;
owl:disjointWith core:UcoInherentCharacterizationThing ;
.
core:UcoInherentCharacterizationThing
rdfs:subClassOf core:UcoThing ;
owl:disjointWith core:UcoObject ;
.
core:Endurant
rdfs:subClassOf core:UcoObject ;
owl:disjointWith core:Perdurant ;
.
core:Perdurant
rdfs:subClassOf core:UcoObject ;
owl:disjointWith core:Endurant ;
.
action:Action
rdfs:subClassOf core:Perdurant ;
.
core:Event
rdfs:subClassOf core:Perdurant ;
.
# There might be a higher class than ObservableObject that could be an Endurant subclass.
observable:ObservableObject
rdfs:subClassOf core:Endurant ;
.I think a good example of the endurant-vs-perdurant divide is seeing how Can you please draft a proposal to introduce |
AJN: For `git-blame` purposes, I'm designating Sean the author of this commit, exactly as provided (only modified by `pre-commit` adjusting JSON formatting). References: * ucoProject/UCO#541 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
References: * ucoProject/UCO#541 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
@ajnelson-nist - Indeed I didn't know that git did not generate a ping when adding comments here. But no harm was done.
The diagram, just a UML class diagram, doesn't apply any gUFO concepts, although I've been applying a similar pattern.
Indeed I used the name
If I read the description of
If we can agree that:
then we've already achieved the objective of the very proposal that you refer to, and in a design that is more simple (and, hence, easier to understand and maintain) since it doesn't require the additional taxonomy introduced by your example. In turtle: Whether one would like to subclass the |
|
(This comment ended up having a bit of scope creep. Let us please remember this Issue is about @plbt5 , we need to adhere to I suggested you review flowchart LR
action_Action -->|subclass| observable_ObservableAction[**observable_ObservableAction**]
core_Item -->|subclass| observable_ObservableObject[**observable_ObservableObject**]
core_UcoObject -->|subclass| action_Action
core_UcoObject -->|subclass| core_Item
core_UcoObject -->|subclass| identity_Identity
core_UcoObject -->|subclass| observable_Observable
identity_Identity -->|subclass| identity_Person
observable_Observable -->|subclass| observable_ObservableAction
observable_Observable -->|subclass| observable_ObservableObject
@sbarnum : I've never understood from the English in the IRI or its documentation comment why I wouldn't be raising this question if UCO used For reference, see this diagram, which starts at flowchart LR
action_Action -->|subclass| observable_ObservableAction
core_Item -->|subclass| observable_ObservableObject
core_Relationship -->|subclass| observable_ObservableRelationship
core_UcoObject -->|subclass| action_Action
core_UcoObject -->|subclass| core_Item
core_UcoObject -->|subclass| core_Relationship
core_UcoObject -->|subclass| observable_Observable
core_UcoObject -->|subclass| pattern_Pattern
observable_Observable[**observable_Observable**]
observable_Observable -->|subclass| observable_ObservableAction
observable_Observable -->|subclass| observable_ObservableObject
observable_Observable -->|subclass| observable_ObservablePattern
observable_Observable -->|subclass| observable_ObservableRelationship
(I noticed when making this diagram there might be an oversight on My confusion now stems from the definition comment of
Written like that, it looks like the English-adhering implementation of observable:Observable
a owl:Class ;
owl:disjointUnionOf (
observable:ObservableAction
observable:ObservableObject
) ;
.Because I doubt that's the intention:
With the above sketches, here is my current thinking on the subclass hierarchy if flowchart LR
core_UcoObject -->|subclass| core_Endurant[**NEW** core_Endurant]
core_UcoObject -->|subclass| core_Perdurant[**NEW** core_Perdurant]
action_Action -->|subclass| action_ActionPattern
action_Action -->|subclass| observable_ObservableAction
core_Endurant -->|subclass| core_Item
core_Endurant -->|subclass| core_Relationship
core_Endurant -->|subclass| identity_Identity
core_Endurant -->|subclass| pattern_LogicalPattern
core_Item -->|subclass| observable_ObservableObject
core_Perdurant -->|subclass| action_Action
core_Perdurant -->|subclass| core_Event[**NEW** core_Event]
core_Relationship -->|subclass| observable_ObservableRelationship
core_UcoObject -->|subclass| observable_Observable
core_UcoObject -->|subclass| pattern_Pattern
identity_Identity -->|subclass| identity_Person
observable_Observable -->|subclass| observable_ObservableAction
observable_Observable -->|subclass| observable_ObservableObject
observable_Observable -->|subclass| observable_ObservablePattern
observable_Observable -->|subclass| observable_ObservableRelationship
pattern_Pattern -->|subclass| action_ActionPattern
pattern_Pattern -->|subclass| pattern_LogicalPattern
I didn't see anything inconsistent about this Issue's proposed For the coming proposal on |
|
An update: I've transcribed the example @sbarnum provided me to CASE-Examples, here. To keep this Issue moving towards resolution:
|
This patch also regenerates Make-managed files. References: * ucoProject/UCO#541 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
|
This change proposal is now scheduled for a Requirements Review vote on August 29th. @sbarnum , there are requests for replies from you in this comments thread. |
No effects were observed on Make-managed files. References: * ucoProject/UCO#541 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
|
@sbarnum : Is the
Again, this is not a suggestion that UCO align with BFO. However, seeing this distinction made in another ontology makes me suspect it is something that UCO needs to be explicit about, and the Is |
|
I am concerned with You gave this example: {
"@id": "kb:event-d4a5a009-7b4d-445d-8d06-9dc85f263b3e",
"@type": "core:Event",
"core:name": "user logged in",
"core:eventType": "Authentication"
}Why would we not define this? {
"@id": "kb:event-d4a5a009-7b4d-445d-8d06-9dc85f263b3e",
"@type": "observable:AuthenticationEvent",
"core:name": "user logged in"
}I appreciate that this looks like another instance of the design pattern where UCO exchanges ontological functionality for the sake of ease of use of non-ontological users. (I.e., "Semi-open vocabularies", but no vocabulary accompanies this proposal.) But we should be aware that untyped strings' weakness mean some classes of events would be extremely difficult to correlate. Take for instance these strings:
I hope it is clear that there is some hierarchy behind those events, at least in that "Successful authentications" would be a subset of "Authentications"; "Successful authentications" is disjoint with "Unsuccessful authentications"; and some unsuccessful authentication subclasses are "Security events", potentially leading to a reportable incident if there were some sequence of them (like, 1,000 correlated authentications, 999 failed followed by 1 successful). I think I don't wish to hold up adding |
|
Wow. Lots of comments to respond to. Sorry, I was also not getting notifications of these comments. First, the intent for Event as a a noteworthy occurrence (something that happens or might happen) is that while it has an inherent temporal aspect, it itself is not simply a temporal specification (instantaneous or interval). Second, this proposal intentionally proposes introducing the concept of Event in as simple a manner as possible and intentionally avoids complex ontological discussions such as perduant vs endurant. Any such discussions should be handled separately in other proposals after the simple introduction of Event as a Third, Event MUST be a subclass of Fourth, I will intentionally avoid going down the rabbit hole here on the question of potentially introducing perduant & endurant concepts as the should be more fully discussed in a separate proposal but it should be noted that this is another example of where we should be careful to balance how much ontological rigor we should introduce (sometimes because we can rather than necessarily that we should) with actualy practicality and flexibility of use. 
Fifth, on the question of where Sixth, in response to @ajnelson-nist question about alignment of the proposed Event with BFO's |
|
Please note that Event Start may change to an earlier time as an investigation proceeds. Several seemingly independent Events can also end up being related as investigations proceed.
Pat Maroney - AT&T
…________________________________
From: Sean Barnum ***@***.***>
Sent: Monday, August 21, 2023 2:26:20 PM
To: ucoProject/UCO ***@***.***>
Cc: Subscribed ***@***.***>
Subject: Re: [ucoProject/UCO] Need ability to represent general concept of an Event (Issue #541)
Wow. Lots of comments to respond to. Sorry, I was also not getting notifications of these comments. First, the intent for Event as a a noteworthy occurrence (something that happens or might happen) is that while it has an inherent temporal
Wow. Lots of comments to respond to. Sorry, I was also not getting notifications of these comments.
First, the intent for Event as a a noteworthy occurrence (something that happens or might happen) is that while it has an inherent temporal aspect, it itself is not simply a temporal specification (instantaneous or interval).
It is more than that and can include who, what, why, where, etc. in addition to the when.
The temporal specification would be one aspect of the Event expressed via startTime and endTime properties. It is very intentional that an Event could be either a point-in-time (instantaneous) or a bounded (startTime and endTime known) or unbounded (only one end of the interval known) interval, or temporally untethered such that a particular Event can be described without knowing its temporal dimension. This could be situations where something is known to have occurred but not when or where something could potentially occur sometime in the future and it is not known when.
It is critical that Event support this level of flexibility as all of these scenarios are real-world and need ability to express.
Second, this proposal intentionally proposes introducing the concept of Event in as simple a manner as possible and intentionally avoids complex ontological discussions such as perduant vs endurant. Any such discussions should be handled separately in other proposals after the simple introduction of Event as a UcoObject. Such complexities should not prevent or delay the intitial introduction of Event.
Third, Event MUST be a subclass of UcoObject. It is a domain object within the CDO/UCO ontology and graph. It must be possible to cleanly relate Event to other UcoObjects as specified in Requirement #6<https://urldefense.com/v3/__https://github.com/ucoProject/UCO/issues/6__;!!BhdT!mU_XFBhtt7ZQazSwuy5X-ynMSXjLbbQredaNwGAlXOYggs535Ymu9XQ8C7OrFmQOKOBKHUEPIwjYGLcA7vgeJvwpKL0$>. The purpose of UcoObject is for exactly this sort of situation. UcoObject is definitely NOT limited to EITHER perduant OR endurant. It is absolutely intended to be able to handle either of them.
Fourth, I will intentionally avoid going down the rabbit hole here on the question of potentially introducing perduant & endurant concepts as the should be more fully discussed in a separate proposal but it should be noted that this is another example of where we should be careful to balance how much ontological rigor we should introduce (sometimes because we can rather than necessarily that we should) with actualy practicality and flexibility of use.
Reserving deeper discussion to occur in a separate discussion, core:Item is intended to represent a "thing" (yeah, I know that is pretty ambiguous) that would certainly fall into the endurant bucket if we ever go there but would be a particular subclass of endurant rather than the whole bucket and would be separate from things like Identity/Person/Organization, Pattern, Relationship, etc.
Understanding that this is NOT a final conclusion from me and reserving the right to discuss further and potentially change my mind in a separate discussion regarding potentially incorporating perduant & endurant, this diagram from @ajnelson-nist<https://urldefense.com/v3/__https://github.com/ajnelson-nist__;!!BhdT!mU_XFBhtt7ZQazSwuy5X-ynMSXjLbbQredaNwGAlXOYggs535Ymu9XQ8C7OrFmQOKOBKHUEPIwjYGLcA7vgeBmgK30k$> is likely the closest thing to what would make sense to me except that Relationship should not be a subclass of Endurant as it often has a temporal dimension and could be considered perdurant in nature. I believe Relationship would either be a subclass of Perdurant or potentially more likely would be a subclass of UcoObject outside of Endurant or Perduant like Observable and Pattern are. You may want to include Location in this diagram as well as a subclass of Endurant.:
[Endurant_and_Perduant_subclassing_Alex]<https://urldefense.com/v3/__https://user-images.githubusercontent.com/2760288/262107646-bc1dd56e-a63f-4e0e-baa7-75b968992cf0.png__;!!BhdT!mU_XFBhtt7ZQazSwuy5X-ynMSXjLbbQredaNwGAlXOYggs535Ymu9XQ8C7OrFmQOKOBKHUEPIwjYGLcA7vge1eVHpio$>
Fifth, on the question of where eventType should be a string or only conveyed via subclassing of Event this is definitely a situation where real-world practicality must trump a desire for hard restrictive ontological rigor. This is exactly the same situation as vocabularies. In fact, it is VERY likely that there should be one of more vocabularies for eventType defined in the future but they are not currently defined and should not hold up the introduction of Event for use. The key here is that like many other vocabulary scopes it is not at all possible for CDO/UCO to identify and define all possible types of event (they will be continuously growing/changing and particular corners of the community will always need to identify types of Events that are only relevant to themselves. Like with vocabularies it is not practical or acceptable to expect end users to define such event types not covered in CDO/UCO via formal ontological specification means. Such restrictions would a death knell for adoption. This does not mean that subclassing of Events cannot occur as desired and appropriate after the initial introduction of Event. They would simply be in addition to the eventType field (and could specify the exact eventType string as a constraint within the subclass) rather than a replacement for the eventType field. It would be simple for an adopter to utilize specific subclasses where desired or to analyze generic Event objects using their eventType property to derive particular subclassing if such subclasses have been defined sometime in the future. Having eventType as a string property does not prevent any of this from being possible in the future but it does protect flexibility for adopter practicality for the real world.
Sixth, in response to @ajnelson-nist<https://urldefense.com/v3/__https://github.com/ajnelson-nist__;!!BhdT!mU_XFBhtt7ZQazSwuy5X-ynMSXjLbbQredaNwGAlXOYggs535Ymu9XQ8C7OrFmQOKOBKHUEPIwjYGLcA7vgeBmgK30k$> question about alignment of the proposed Event with BFO's temporal region, spatiotemporal region, and spatial region, I think this illustrates part of my frustration with BFO and ontological overrigidity in general. In BFO, temporal region is an occurrent region in time and is purely a "when", spatial region is a location in space and is purely a "where", and spatiotemporal region is a location in space at a particular time and is therefore a pure restrictive combination of "where" and "when". These are all disjoint from each other which is not practical for real-world characterizations of events, especially as used in the cyber domain. In the cyber domain, events are something that occurred, is occurring or may occur in the future and may have associated details about "when" (potentially without "where" or could have multiple "where"s), may have associated details about "where" (potentially without "when"), and possibly all sorts of other contextual details (who, why, how, with, etc.). They do not fall purely within the BFO buckets. In CDO/UCO they must remain flexible enough to support practical use.
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/ucoProject/UCO/issues/541*issuecomment-1686819689__;Iw!!BhdT!mU_XFBhtt7ZQazSwuy5X-ynMSXjLbbQredaNwGAlXOYggs535Ymu9XQ8C7OrFmQOKOBKHUEPIwjYGLcA7vgeiwB16B0$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AAYSFYMAYMQETK4EKB2GOEDXWOR4ZANCNFSM6AAAAAA2QJYQ7A__;!!BhdT!mU_XFBhtt7ZQazSwuy5X-ynMSXjLbbQredaNwGAlXOYggs535Ymu9XQ8C7OrFmQOKOBKHUEPIwjYGLcA7vge715I9HM$>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
|
@packet-rat - Agreed. One example is a reportable cybersecurity incident that ends up becoming comprised of more and more events that are realized to be associated - e.g., a set of authentication attempts. This leads us to discuss an encoding and logical-enforcement matter: Say we have an attack event, A, originally believed to start at time T0. We record a start time of T0 on A. Later we realize a more technically-narrow event E was part of the attack, and it started at time T1 well before T0. I think some of what @sbarnum suggested in Requirements 4 and 6 suggest UCO is required to be able to support "Batching" the event E into the attack A. But, if we do, is it a data error for E's start time to be before A's start time? I'm not sure if we need to discuss this as I'll have more replies for @sbarnum's remark coming soon. |
References: * #541 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
|
First, let's please consider Endurants and Perdurants as out of scope of this proposal on Events. Another proposal (with revised figures) is under draft, on Issue 544. @sbarnum, you have agreement from @plbt5 and me that Second, on Third, @sbarnum, is this the case: action:Action
rdfs:subClassOf core:Event ;
.If not, can you give an Fourth, @sbarnum, thank you for the response on However, I need to urge against a particular practice you suggested, my own emphasis added:
UCO should never propose such a tie of string-literal value to an |
No effects were observed on Make-managed files. References: * ucoProject/UCO#541 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
No effects were observed on Make-managed files. References: * ucoProject/UCO#541 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
A follow-on patch will regenerate Make-managed files. References: * ucoProject/UCO#541 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
References: * ucoProject/UCO#541 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
No effects were observed on Make-managed files. References: * ucoProject/UCO#541 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
No effects were observed on Make-managed files. References: * ucoProject/UCO#541 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
No effects were observed on Make-managed files. References: * ucoProject/UCO#541 * ucoProject/UCO#544 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
References: * ucoProject/UCO#541 * ucoProject/UCO#544 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
No effects were observed on Make-managed files. References: * ucoProject/UCO#541 * ucoProject/UCO#544 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
No effects were observed on Make-managed files. References: * ucoProject/UCO#541 * ucoProject/UCO#544 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
No effects were observed on Make-managed files. References: * ucoProject/UCO#541 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
No effects were observed on Make-managed files. References: * ucoProject/UCO#541 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
No effects were observed on Make-managed files. References: * ucoProject/UCO#541 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
No effects were observed on Make-managed files. References: * ucoProject/UCO#541 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
A follow-on patch will regenerate Make-managed files. References: * ucoProject/UCO#541 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
References: * ucoProject/UCO#541 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
No effects were observed on Make-managed files. References: * ucoProject/UCO#541 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
No effects were observed on Make-managed files. References: * ucoProject/UCO#541 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
References: * ucoProject/UCO#541 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
No effects were observed on Make-managed files. References: * ucoProject/UCO#541 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
Background
The ability of UCO to express any sort of temporal occurrences is currently limited to active contexts in the form of Actions where some agent (Person, Organization, Tool, Software, Application, Process, etc.) is, has or might dynamically perform some action.
For many contexts there is a need to also be able to express a passive temporal occurrence in the form of an event as a noteworthy occurrence (something that happens or might happen). The context of an event could be completely independent of any known action(s) (e.g., Fukashima reactor meltdown) or could involve one or more actions potentially along with relevant locations, persons, organizations, observable objects, etc. (e.g., event of "account logged (passive not active) into application" along with the Application, the Account, the Person, the Action of browser requesting login screen (along with Location where this occurred), the Action of Application responding with login screen, the Action of Person entering credentials, the Action of browser submitting credentials, the Action of the Application vetting credentials, the action of the Application presenting interface to browser, etc.).
NOTE: This general concept of an event is distinct from the existing UCO concept of an EventRecord which represents a digital record of some event that occurred in a digital context (the sort of log events you would find in a syslog). It is also distinct from the existing UCO concept of an EventLog which represents a collection of EventRecords.
The general concept of event as a structured UcoObject is useful for a range of cyber application domains including cyber operations, cyber threat intelligence, adversary engagement, cyber investigation, etc.
Requirements
Requirement 1
An event can be specified with a simple name and no further context
Requirement 2
An event can be specified with time bounds for its temporal beginning and end
Requirement 3
An event may be characterized with any categorizing event type label
Requirement 4
An event can be specified with context details for the event specified as
core:UcoObjectRequirement 5
An event can be specified with context details for the event specified as simple strings
Requirement 6
An event can be related to any other
core:UcoObjectRisk / Benefit analysis
Benefits
Risks
Solution suggestion
Implementation of the proposed solution is available in #542
Within the
corenamespace:core:UcoObjectwith definition of "An Event is a noteworthy occurrence (something that happens or might happen)."core:eventTypedatatype property asxsd:stringcore:eventContextobject property ascore:UcoObjectcore:eventAttributeobject property astypes:Dictionarycore:eventType,core:eventContext,core:eventAttribute,core:startTime, andcore:endTimeSolution discussion
The proposed new
core:Eventclass provides a simple mechanism for expressing general temporal occurrences with varying levels of detail (Requirements 1-5) and relating them to other CDO content (Requirement 6).The proposed new
core:eventTypeproperty provides capability to support Requirement 3.The proposed new
core:eventContextproperty provides capability to support Requirement 4.The proposed new
core:eventAttributeproperty provides capability to support Requirement 5.The proposed property shapes on
core:Eventfor the currently existingcore:startTimeandcore:endTimeproperties provides capability to support Requirement 2.This scope of this proposal is additive in nature to the current UCO and does not introduce any significant new complexity or affect existing capabilities.
Coordination
developfor the next releasedevelopstate with backwards-compatible implementation merged intodevelop-2.0.0develop-2.0.0(N/A)The text was updated successfully, but these errors were encountered: