[RFU-STR-001] Life cycle of CLD

[Certiman]

Original remark from CW [13/01/2025]

2.	Core Use Cases / Issue new CLD: Public data, with Shape: Shape page not available (404), what is it?
3.	"The issuing of a new CLD with an existing ERADIS ID and version should be prohibited."
  a.	What is the ERADIS ID of a CLD?
  b.	Note that current RFU-STR-001 CLD numbering requires the version to be a part of the number: “NNNN/.../Vnn”, this is problematic
4.	"Issue a new version of a CLD (update)"
  a.	Naming conflict: "update" is called "amend" in RFU-STR-001
  b.	"SHALL NOT contain properties which MAY NOT be changed according to RFU-STR-001": Any data may be changed if they were just wrong in the original CLD
  c.	"The user must first search for and select the CLD to update (from the collection of Issued but not any other CLD's)": Why should a refused certificate not be updated? Maybe there was a simple type in the data?
5.	"Restrict" will probably never be used because the existing CLD will be suspended and replaced by a new one (see RFU-STR-001)
6.	"Withdraw", why search "but not the Amended CLD's"? An amended CLD may also be withdrawn later.

Meeting 2025-01-13

For final review as a decision:

• The ERADIS Identifier is a string literal, stored under the rdfs:label property. It's shape can be a regular expression since the string conforms to one.
• However, all individual substrings of this Literal should be stored also on individual properties, and the consistency SHOULD be checked using SHACL:
  • NNNN, the NoBo identifier, is linked via dct:creator.
  • M(.N), the CLD type, see this issue: [RFU-STR-001] Core Class for CLD does not need subClass Certiman/automate-va#5, is linked via dct:type.
  • the module, see the same issue, is linked via dct:requires.
  • the year is determined via the dct:issued issue date.
  • the subsystem is determined via the legislation (TSI), linked via dct:subject.
  • the languages could be confirmed by analysing the language tags of the literal strings describing the topic of the CLD (the string describing the IC/SS in scope).
  • the NoBo's identification code for the CLD is not stored in a separate property.
  • the version is stored under dct:hasVersion. The issuing of a CLD leads to version 1.
• Difference between amend and update. The proposal remains to have both editing processes. NBRail members present confirm to use 'update' only, which is an amendment of more properties of the CLD than the process amend allows. In other words, the amend process will only allow editing a reduced set of properties, while update was previously only done by the Agency. To be cross-checked with FC from NBRail.
• Updating a refused certificate and witdrawing an amended one: to be examined based on the state diagram.
• As long as restrict is mentioned in RFU-STR-001, we propose to keep it.

[Interoperable-data]

The state diagram should clarify cw remarks 5 & 6 (mdh)