Define a class EventSpecification (was HypotheticalEvent)

rjyounes commented 1 year ago

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 commented 1 year ago

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 commented 10 months ago

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 commented 9 months ago

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 commented 8 months ago

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 commented 7 months ago

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

rjyounes commented 7 months ago

Probably not.

rjyounes commented 6 months ago

I'm in favor of calling this EventSpecification or EventTemplate, and @mkumba has mentioned this as well in the context of business and financial events in the sub-gists.

uscholdm commented 6 months ago

I approve. I have used EventSpecification in some client ontologies - confirm this with @DanCarey404 for one example.

rjyounes commented 5 months ago

Dave: Specification is ambiguous: it may mean how to make something, or as a conformance criteria. In the case of event specification it's the latter. We've almost never used the former.

Katie: How to is more like a task template.

DECISION:

Add gist:EventSpecification as a subclass of gist:Specification
Update gist:Specification to include event specification
Update gist:Specification to limit to conformance criterion. Add annotation to look at TaskTemplate if you are looking for the concept of a process specification.

rjyounes commented 5 months ago

Changed assignee from @marksem to @uscholdm since the latter has submitted PPR #1077 for it.

semanticarts / gist