Feature/new issue 831 add event specification

[uscholdm]

Fixes #831

• Added EventSpecification.
• Added and updated annotations for Specification.

OPEN QUESTION: there is now an incorrect subclass relationship.

Requirement: gist 12.0:

• "A documented physical or functional need that a particular design, product, or process must be able to perform. Alternately, the obligation of a person or organization to behave in a certain way (i.e., drive on the right side of the road)."

Updated definition of Specification:

• "One or more characteristics that specify what it means to be a particular type of thing such as a material, product, service or event. A specification is sufficiently precise to allow conformance of something to the specification to be tested."

A Specification is often not a need to be performed, so Specification cannot be a subclass of Requirement. It includes the idea of a law or regulation which is outside the scope of a specification.

Options include:

1. Broaden the definition of Requirement to include Specification so the subclass relationship can remain. Easier said than done.
2. Remove the class Requirement, it's never been use in my experience, if anyone want to represent a law or regulation, they can create a separate subclass.

[rjyounes]

@uscholdm Is this PR ready for review? You've requested my review but it's still in draft state.

[uscholdm]

@uscholdm Is this PR ready for review? You've requested my review but it's still in draft state.

An open question arose that I need your opinion on as to how to proceed. See first PR comment

[rjyounes]

You could tweak the definition of Requirement to include the sense of Specification that includes EventSpecification. This makes perfect semantic sense to me: a certain weather event is required to have certain characteristics in order to be a hail storm and thus covered under insurance policy XYZ.

What I really don't like is that - as acknowledged in the current definition - Requirement merges two entirely separate concepts, presumably because they use the same English word - that's a trap we shouldn't fall into. Is this what you are suggesting? - to remove Requirement and promote Specification and Restriction to direct subclasses of Intention? Thus not combining the two different meanings of "requirement" into one class?

That might be the right thing to do, but that is too large a change to be rolled into this PR without group consideration. So for right now I would choose the first option I mentioned, and add a new issue for the second, to be considered for version 13.1.0.

[uscholdm]

What I really don't like is that - as acknowledged in the current definition - Requirement merges two entirely separate concepts, presumably because they use the same English word - that's a trap we shouldn't fall into. Is this what you are suggesting? - to remove Requirement and promote Specification and Restriction to direct subclasses of Intention? Thus not combining the two different meanings of "requirement" into one class?

Yes exactly!

That might be the right thing to do, but that is too large a change to be rolled into this PR without group consideration.

agreed

So for right now I would choose the first option I mentioned, and add a new issue for the second, to be considered for version 13.1.0.

I tried a bunch of wording tweaks and failed to find something much better. I propose to just leave it for now and add an issue. It's only by chance I happened to notice anyway, and its only an annotation for a class that as far as I know rarely gets used.

[rjyounes]

Looks good. I've proposed some wording tweaks.

[rjyounes]

How about something like:

An insurance company defines the characteristics of a weather event that must be satisfied for it to qualify as a hail storm covered in its homeowner's policy. Defaulting on a loan.

[rjyounes]

@uscholdm I've created issue #1087 for the Requirement proposal.

[uscholdm]

@rjyounes This is ready for review again.

[uscholdm]

I don't know why I am being asked to review my own PR