Define a class EventSpecification (was HypotheticalEvent)

[rjyounes]

This would be a subclass of Event for dateless events - I.e., max 0 start and end dates. Note that unlike PlannedEvents, which remain PlannedEvents even when they have occurred, a HypotheticalEvent must cease to be one as soon as it gets dates, either planned or actual.

Related to the removal of date restrictions in version 12.0.0; see issue #760 and PR #777.

[uscholdm]

I upport this idea, I have used if for several clients in various industries. I created the following 10 year ago at a consumer products client who did risk assessment, it was updated many years later at a global financial organization. We would do this differently now. I now think that a hypothetical event is not an event, but rather a specification of a possible future event. Hypothetical events are generated by computer simulations (e.g. an oil spill).

gist:HypotheticalEvent
	a owl:Class ;
	rdfs:subClassOf
		gist:Event ,
		[
			a owl:Restriction ;
			owl:onProperty gist:hasA ;
			owl:onClass gist:AssessedLiklihood ;
			owl:minQualifiedCardinality "0"^^xs:nonNegativeInteger ;
		]
		;
	rdfs:label "HypotheticalEvent"^^xs:string ;
	rdfs:comment "An event that may never happen; useful e.g. for planning or risk assessment; may involve computer simulation."^^xs:string ;
	.

Here is the version for an insurance company:

eo:HypotheticalEvent
	a owl:Class ;
	rdfs:subClassOf gist:Specification ;
	skos:definition "A characterization of an event that might happen. It is useful for risk assessment and insurance contracts."^^xsd:string ;
	skos:prefLabel "Hypothetical Event"^^xsd:string ;
	.

eo:Incident
	a owl:Class ;
	rdfs:subClassOf gist:Event ;
	skos:definition "An undesirable event that occurred."^^xsd:string ;
	skos:prefLabel "Incident"^^xsd:string ;
	.

[uscholdm]

We had an internal disucsssion on this. Here are the notes

Key elements

• degree of impact
• likelihood over a time period (frequency of occurrence)
• risk rating

What is it a subclass of?

• agreement that it is a subclass of specification
• emerging consensus that it should NOT be a subclass of Event even though logical allowed now
• suggestion to make Specification and Event disjoint

What to call it:

• having 'Event' in the name suggests linguistically that it is a kind of event, slightly confusing.
• maybe call it Scenario - maybe not, its often a series of events
• maybe call it PotentialEvent
• maybe call it EventSpecification
• Avoid the ambiguous term, 'Risk' if possible, specify variations/kinds of risk.

Comparing PlannedEvent/Event with HypotheticalEvent/Event

• a gist:PlannedEvent unfolds into an Event with same IRI. That will not work here, because a HypotheticalEvent can have many different events that conform to it.
• A PlannedEvent should not also be a specification
• in the risk world,
  • a HypotheticalEvent is always a bad thing
  • a HypotheticalEvent is often called just Risk, or a RiskScenario
  • a HypotheticalEvent that happens is called an Incident.
  • assessing the likelihood of an incident is hugely important
  • An incident conforms to the specification that is the HypotheticalEvent.
  • Incidents are carefully tracked

Granularity

• most hypothetical events can unfold as many incidents over different times and places and circumstances
• it is possible to create a hypothetical event that is so specific that it can only unfold into a single actual event. E.g. a narrow time frame, location, set of circumstances.
• there may well be higher level groupings of hypothetical events which are too broad to be called specifications. There may be a hierarchy of hypothetical event categories. This is true in the risk world.

[rjyounes]

Rebecca: Hypothetical Event should not be related strictly to risk.

We agreed that it would be a specification? Should we call it EventSpecification rather than HypotheticalEvent.

Michael: gist has EventSpecification, client ontologies could define HypotheticalEvent related to risk if needed.

Rebecca: We must distinguish it from a PlannedEvent.

Dan: A PlannedEvent could have dates attached to it, EventSpecification would not, just like a ProductSpecification never has a serial number or is not located in space.

Michael: They should not be disjoint.

Rebecca: They should be disjoint, otherwise the two will be confused.

Rebecca: Is any event that hasn't occurred in some sense hypothetical?

Jamie: A hypothetical event may have dates.

Rebecca: Leave hypothetical event out of it, since we don't want to define it.

Rebecca: Let's drop it because we don't know what it is.

Jamie: But this is a common concept that many clients need.

Rebecca: But we don't know what it is, perhaps clients will want to define it in different ways, leave it up to client. Cyber-risk can be in gistCyber.

Michael: I created EventSpecification for many clients, propose defining it in gist.

Dan: A client uses in the context of risk.

Rebecca: The notion of event specification in gist does not accord with this concept of "event specification."

Peter: Specific event specifications like "hurricane" are really classes that are instantiated. I might have a party, which is a hypothetical event. Some aspects of a hypothetical event becoming a real event ...

Michael: Fuzzy boundary between specifications that real things are based on and classes that are instantiated. iPhone 15 could be a specification, or it could be a class that is instantiated by individual iPhones.

Rebecca: Events have a lifecycle, from hypothetical to planned to planned with dates to ongoing to historical (not all events go through every phase).

Jamie: As soon as you start thinking about an event it's a planned event. A specification, like "birthday party," is a specification of what a birthday party is.

Rebecca: A hypothetical event is not a planned event. Do we ever need to include it in the graph?

Rebecca: Current definition of gist:Specification: "A set of requirements to be satisfied by a material, design, product, or service." The concept of event specification does not conform to this. This is a useful concept and extending it will render it less useful. And Dave has not been in favor of extending the concept of specification to things like process specifications.

[rjyounes]

One use case I've come across for an event specification: we want to analyze how closely an actual event came to what was initially specified/planned. For dates you can use planned vs actual, but not for other features, such as participants, venue, etc. Obviously this cannot be a single event that starts as a planned event and ends as an actual one, which gives no means of comparison.

[uscholdm]

This is interesting. Do you think it is broad enough to warrant having in gist?

[rjyounes]

Probably not.