Update ess incident model

[birgitZF]

Description

Update of essincident model to version 2.0.0. Changes due to discussions within Environment and Social Standards (ESS) team about the ESS incident process. Some changes were necessary to version 1.0.0.
Issue #255 was created to organize the changes.

MS2 Criteria

(to be filled out by PR reviewer)

• the model validates with the BAMM SDS SDK in the version specified in the Readme.md of this repository by the time of the MS2 check (e.g., 'java -jar bamm-cli.jar -i <path-to-aspect-model> -v ). The BAMM CLI is available here and in GitHub
• use Camel-Case (e.g., "MyModelElement" or "TimeDifferenceGmtId", when in doubt follow https://google.github.io/styleguide/javaguide.html#s5.3-camel-case)
• the identifiers for all model elements start with a capital letter except for properties
• the identifier for properties starts with a small letter
• all model elements at least contain the fields "preferred name" and "description" in English language. The description must be comprehensible. It is not required to write full sentences but style should be consistent over the whole model
• Property and the referenced Characteristic should not have the same name
• the versioning in the URN follows semantic versioning, where minor version bumps are backwards compatible and major version bumps are not backwards compatible.
• use abbreviations only when necessary and if these are sufficiently common
• avoid redundant prefixes in property names (consider adding properties to an enclosing Entity or even adapt the namespace of the model elements, e.g., instead of having two properties DismantlerId and DismantlerName use an Entity Dismantler with the properties name and id or use a URN like io.catenax.dismantler:0.0.1)
• fields preferredName and description are not the same
• preferredName should be human readable and follow normal orthography (e.g., no camel case but normal word separation)
• name of aspect is singular except if it only has one property which is a Collection, List or Set. In theses cases, the aspect name is plural.
• units are referenced from the BAMM unit catalog whenever possible
• use constraints to make known constraints from the use case explicit in the aspect model
• when relying on external standards, they are referenced through a "see" element
• all properties with an simple type have an example value
• metadata.json exists with status "release"
• generated json schema validates against example json payload
• file RELEASE_NOTES.md exists and contains entries for proposed model changes
• all contributors to this model are mentioned in copyright header of model file

MS3 Criteria

(to be filled out by semantic modeling team before merge to main-branch)

• All required reviewers have approved this PR (see reviewers section)
• The new aspect (version) will be implemented by at least one data provider
• The new aspect (version) will be consumed by at least one data consumer
• There exists valid test data
• In case of a new (incompatible) major version to an existing version, a migration strategy has been developed
• The model has at least version '1.0.0'
• The release date in the Release Note is set to the date of the MS3 approval

[github-actions]

Validation Report for io.catenax.essincident/2.0.0/EssIncident.ttl

Validation failed:

[agg3fe]

this reference statement is giving error. Reason: the referenced object is still written in the 'bamm' and not 'samm'. hence this model is giving error in validation.
Suggestion would be to create a new referenced model (io.catenax.shared.address_characteristic:2.0.0) with 3.0.0 version which is written in 'samm'.

[agg3fe]

PR #267 is merged now.
Please revalidate the model and we can do the MS2 check further.

[github-actions]

Validation Report for io.catenax.essincident/2.0.0/EssIncident.ttl

Validation failed:

[github-actions]

Validation Report for io.catenax.essincident/2.0.0/EssIncident.ttl

Validation failed:

[github-actions]

Validation Report for io.catenax.essincident/2.0.0/EssIncident.ttl

Validation failed:

[birgitZF]

reference to address 3.0.0 is ok now, additionally I had to change some more fields according to ESS use case team. now the model should be final. hope no more changes will come up. validation with BAMM (check locally) was ok

[github-actions]

Validation Report for io.catenax.essincident/2.0.0/EssIncident.ttl

Validation failed:

[bs-jokri]

@birgitZF @agg3fe and me checked you model. It seems there are problems in some regexes. We found the BPNs, the email and the longitude rule not validating agains the provided example value. For the BPN and email rule there where superfluous backslashes in the rule, which where easy to fix (fix provided in commit b686ce3) but in the latitude and longitude rule there seem some conceptual problems. @agg3fe is investigating and can probably provide more details. Anyway, I think those rules need some adjustments.

[agg3fe]

@birgitZF @agg3fe and me checked you model. It seems there are problems in some regexes. We found the BPNs, the email and the longitude rule not validating agains the provided example value. For the BPN and email rule there where superfluous backslashes in the rule, which where easy to fix (fix provided in commit b686ce3) but in the latitude and longitude rule there seem some conceptual problems. @agg3fe is investigating and can probably provide more details. Anyway, I think those rules need some adjustments.

Checking the regex for 'LatitudeConstraint', i think you either need to adjust the regex pattern.
If example value is correct then, regex should be something like: ^(\+|-)?(?:90(?:(?:\.0{1,6})?)|(?:[0-9]|[1-8][0-9])(?:(?:.[0-9]{1,7})?))$

For longitude, it should be: ^(\+|-)?(?:180(?:(?:\.0{1,6})?)|(?:[0-9]|[1-9][0-9]|1[0-7][0-9])(?:(?:.[0-9]{1,6})?))$

[birgitZF]

I think the example value for latitude was not correct, it should be -5.422077 instead of -5.4220777, anyway I will check with the implementation team first

[bs-jokri]

LGTM

[bs-jokri]

@birgitZF with your fix to the example value the model is ok now

[bs-jokri]

@birgitZF we should not forget about deprecating v1.0.0 of the model as soon as this one is released

[birgitZF]

@birgitZF we should not forget about deprecating v1.0.0 of the model as soon as this one is released

What does the process look like? Another issue / pull request or just change the "metadata.json" - file for the old version?

[bs-jokri]

@birgitZF. we need to create a new issue to deprecatewith

https://github.com/eclipse-tractusx/sldt-semantic-models/issues/new?assignees=&labels=deprecate&projects=&template=model_deprecation_request.md&title=%5BModel+Deprecation%5D%3A+

[bs-jokri]

can we put the model to MS3 review today?

[birgitZF]

yes, thanks, to put it to MS3 would be fine for me

[birgitZF]

shall I create the issue for the deprecation of the old version?

[birgitZF]

issue created [Model Deprecation]: essincident version 1.0.0 st to deprecate #282