From Guillaume Duffes


- Classification series:
** "Subject areas" cardinalities are 1..1 in GSIM, I think that's a mistake, I will open an issue on the GSIM forum.

- StatisticalClassification:
** MaintenanceUnit is 0..1 in GSIM. It is the case in my organisation, however, I can consult on this on the GSIM group.
 

- ClassificationCorrespondenceTable:
** Owners cardinality 0..1 in GSIM is incorrect .I will post an issue.
** MaintenanceUnit is 0..1 in GSIM. It is the case in my organisation, however, I can consult on this on the GSIM group.
  ** SourceClassification cardinality 0..n in GSIM is incorrect .I will post an issue.

- ClassificationIndex:
** MaintenanceUnit is 0..1 in GSIM. It is the case in my organisation, however, I can consult on this on the GSIM group.
** ContactPersons cardinality 0..1 in GSIM is incorrect .I will post an issue.
** Corrections cardinality is 0..n in GSIM, it seems to me that is one field just as you described it .I will post an issue.
** CodingInstructions cardinality is 0..n in GSIM, it seems to me it should simply be 0..1 just as you described it. I will post an issue.
 
- ClassificationItem:

** ExcludedClassificationItems, it is indeed clearer than in GSIM to have two distinct attributes
  ** FutureEvents cardinality is 0..n in GSIM, it seems to me it should simply be 0..1 just as you described it. I will post an issue.
** GSIM SubItems and LinkedItems are indeed very useful in this class. I will post an issue.
** CaseLawName, CaseLawDescription and CaseLawDate cardinalities 0..n in GSIM do not seem correct to me as well. They should be 0..1. I will post an issue.
 

- ClassificationLevel:
  ** The GSIM NumberOfItems attribute is rather the result of a query than a class attribute. I will post an issue.

  • No labels

1 Comment

  1. GSIM Revision Group meeting 25 April 2018


    Object Classification Series

    Attribute "Subject areas": agreed that it does not need to be mandatory (cardinality: 0..1)


    Object Statistical Classification:

    Attribute "Maintenance unit": agreed to make it mandatory (cardinality: 1..n) 

    Object Correspondence Table:
    Attribute "Owners": agreed that it can be many (cardinality: 0..n)

    Attribute "Maintenance unit": agreed to make it mandatory and that it can be many (cardinality: 1..n)

    Attribute "Source": agreed to leave the cardinality as "0..n" but consider changing the word "Statistical Classification" to "Node Set" in clickable (but perhaps keep it in annex document as it is specialisation)

    Object Classification Index:
    Attributes "Maintenance unit" and "Contact person": agreed to change their cardinality from 0..1 to 0..n  is 0..1 in GSIM. It is the case in my organisation, however, I can consult on this on the GSIM group.
    Attribute "Corrections": agreed to remove word "Verbal" in its description and change the cardinality  from 0..n to 0..1 
    Attribute "Coding Instructions": agreed to keep the cardinality as it is (0..n) as it can be many
     
    Object Classification Item:

    Attribute "Future Events": agreed to keep the cardinality as it is 

    Attributes "Case law", "Case law descriptions" and "Case law date": agreed that case law can be many, hence keep the cardinality of these attributes as it is

    Object Level:
    Attribute "Number of items": agreed to remove as it is the result of a query than a class attribute