PLCSlib / PLCS templates / #416 OASIS:StateAssertion should not restrict identifiers and descriptors

Phil Spiby - 2019-06-03

We should probably change the names of the attributes to ids, descriptions and names to be consistent with other templates. However, this may cause problems for some implementations.
Could active members respond with advice on this please.

Last edit: Phil Spiby 2019-06-03

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- plcs-ccb-admin - 2019-06-03
  
  I will let others comment on the potential problems for implementations.
  
  The issue here is a classic one:
  
  An ID should keep a bond to the ID-owner.
  
  Requirement, specifications, contract clauses, faults etc should be
  referenced by a persistent ID. The ID of the owner is the primary ID, all
  others should keep that as a foreign key(=ID).
  
  So when two, or more parties, are involved in an exchange - they should all
  use the ID assigned by the owner, and map internally to their own system(s)'
  IDs for the same fault.
  
  Mvh
  
  Tor Arne
  
  Fra: Phil Spiby [mailto:philsp@users.sourceforge.net]
  Sendt: 3. juni 2019 13:23
  Til: [plcslib:plcs-templates]
  Emne: [plcslib:plcs-templates] #416 OASIS:StateAssertion should not restrict
  identifiers and descriptors
  
  We should probably change the names of the attributes to ids, descriptions
  and names to be consistent with other templates. However, this may cause
  problems for some implementations.
  Could active members please respond with advice on this please.
  
  [plcs-templates:#416]
  https://sourceforge.net/p/plcslib/plcs-templates/416/
  OASIS:StateAssertion should not restrict identifiers and descriptors
  
  Status: open
  Group: v1.1
  Created: Mon Jun 03, 2019 10:59 AM UTC by Phil Spiby
  Last Updated: Mon Jun 03, 2019 10:59 AM UTC
  Owner: nobody
  
  On a customer project the customer is using StateAssertion to record faults
  against a system. This works well except for the fact that there are two
  parties involved with the fault. The reporting party uses an id when they
  report the fault, and the repair company use a different id when they are
  assigned the repair task. The fault is the same for both parties, it is just
  that there are two identifiers for the fault. At the PSM level id is [0..*],
  but at the template level the id is restricted to a maximum of 1, i.e.
  [0..1].
  I think the template should allow multiple identifiers as allowed at the PSM
  level.
  This applied for descriptions also on this template and to the
  StateAssessment & StatePredicted templates.
  
  Sent from sourceforge.net because you indicated interest in
  https://sourceforge.net/p/plcslib/plcs-templates/416/
  
  To unsubscribe from further messages, please visit
  https://sourceforge.net/auth/subscriptions/
  
  Related
  
  PLCS templates: #416
  
  alternate
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Mats Nilsson - FMV - 2019-06-05
    
    All,
    
    "At the PSM level id is [0..*], but at the template level the id is restricted to a maximum of 1, i.e. [0..1].
    I think the template should allow multiple identifiers as allowed at the PSM level."
    
    Isn't the intention that you use multiple templates if you need to assign multiple identifiers?!
    
    That way each identifier has a unique classification and organization assignement.
    
    Regards,
    
    Mats Nilsson
    Head of design information architechture, CTO office
    
    FMV - Swedish Defence Materiel Administration
    SE-115 88 Stockholm
    Tel: +46 8 782 47 24 Mobile: +46 70 267 47 24
    E-mail: mats.nilsson@fmv.semats.nilsson@fmv.se
    Web: www.fmv.sehttp://www.fmv.se/
    
    How FMV handles your personal information is described at www.fmv.se.
    
    Från: plcs-ccb-admin plcs-ccb-admin@users.sourceforge.net
    Skickat: den 3 juni 2019 20:11
    Till: [plcslib:plcs-templates] 416@plcs-templates.plcslib.p.re.sourceforge.net
    Ämne: [plcslib:plcs-templates] Re: #416 OASIS:StateAssertion should not restrict identifiers and descriptors
    
    I will let others comment on the potential problems for implementations.
    
    The issue here is a classic one:
    
    An ID should keep a bond to the ID-owner.
    
    Requirement, specifications, contract clauses, faults etc should be
    referenced by a persistent ID. The ID of the owner is the primary ID, all
    others should keep that as a foreign key(=ID).
    
    So when two, or more parties, are involved in an exchange - they should all
    use the ID assigned by the owner, and map internally to their own system(s)'
    IDs for the same fault.
    
    Mvh
    
    Tor Arne
    
    Fra: Phil Spiby [mailto:philsp@users.sourceforge.net]
    Sendt: 3. juni 2019 13:23
    Til: [plcslib:plcs-templates]
    Emne: [plcslib:plcs-templates] #416 OASIS:StateAssertion should not restrict
    identifiers and descriptors
    
    We should probably change the names of the attributes to ids, descriptions
    and names to be consistent with other templates. However, this may cause
    problems for some implementations.
    Could active members please respond with advice on this please.
    
    [plcs-templates:#416]https://sourceforge.net/p/plcslib/plcs-templates/416/
    https://sourceforge.net/p/plcslib/plcs-templates/416/
    OASIS:StateAssertion should not restrict identifiers and descriptors
    
    Status: open
    Group: v1.1
    Created: Mon Jun 03, 2019 10:59 AM UTC by Phil Spiby
    Last Updated: Mon Jun 03, 2019 10:59 AM UTC
    Owner: nobody
    
    On a customer project the customer is using StateAssertion to record faults
    against a system. This works well except for the fact that there are two
    parties involved with the fault. The reporting party uses an id when they
    report the fault, and the repair company use a different id when they are
    assigned the repair task. The fault is the same for both parties, it is just
    that there are two identifiers for the fault. At the PSM level id is [0..*],
    but at the template level the id is restricted to a maximum of 1, i.e.
    [0..1].
    I think the template should allow multiple identifiers as allowed at the PSM
    level.
    This applied for descriptions also on this template and to the
    StateAssessment & StatePredicted templates.
    
    Sent from sourceforge.net because you indicated interest in
    https://sourceforge.net/p/plcslib/plcs-templates/416/
    
    To unsubscribe from further messages, please visit
    https://sourceforge.net/auth/subscriptions/
    
    [plcs-templates:#416]https://sourceforge.net/p/plcslib/plcs-templates/416/ OASIS:StateAssertion should not restrict identifiers and descriptors
    
    Status: open
    Group: v1.1
    Created: Mon Jun 03, 2019 10:59 AM UTC by Phil Spiby
    Last Updated: Mon Jun 03, 2019 11:22 AM UTC
    Owner: nobody
    
    On a customer project the customer is using StateAssertion to record faults against a system. This works well except for the fact that there are two parties involved with the fault. The reporting party uses an id when they report the fault, and the repair company use a different id when they are assigned the repair task. The fault is the same for both parties, it is just that there are two identifiers for the fault. At the PSM level id is [0..*], but at the template level the id is restricted to a maximum of 1, i.e. [0..1].
    I think the template should allow multiple identifiers as allowed at the PSM level.
    This applied for descriptions also on this template and to the StateAssessment & StatePredicted templates.
    
    Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/plcslib/plcs-templates/416/
    
    To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
    
    Related
    
    PLCS templates: #416
    
    alternate
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - Phil Spiby - 2019-06-05
      
      The whole idea of allowing multiple identifiers at the PSM level (and OASIS level for most objects) is to handle the concept that a single object CAN have multiple identifiers and each of these has equal standing. Forcing us to create multiple stateAssertions just to handle multiple identifiers is the wrong way to go! We want to promote the idea of data consolidation not enforce stove-pipes.
      Take the customer example, if we were to create multiple fault states for the same physical fault, one to the reporter since they want to assign their id to it and one to the repairer because they want to assign their id to it. Then we would have to link these fault states together as being equivalent. The activities performed by the repairer to rectify the fault would only be related to the repairers state and when the repairer fixes the fault and sets the end effectivity on the repairers fault the reporters fault would still be effective with nothing being done to fix it.
      
      As far as I see it this is a minor problem where the OASIS template has been developed in a way that does not reflect the intended purpose of the PSM level model. Changing [0..1] into [0..*] to allow multiple identifications of the same StateAssertion.
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Phil Spiby - 2019-06-05
    
    We specifically rejected the concept of primary id and alias identification with AP239 edition 2. We specifically allow multiple identifications for virtually all objects inside PLCS. The identification mechanism provides the idString, the context and role of the identifier. This allows us to manage multiple identification schemes for objects. It allows implementations to show the most relevant identifier based on user preferences.
    We are talking here about the concept of identification, not how the data is implemented in some underlying DB or in memory system, so the last thing we should mention here is Foreign Keys since that is an Relational DB implementation method.
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Phil Spiby - 2019-08-08

status: open --> pending

assigned_to: Phil Spiby

Group: v1.1 --> plcs-plcslib-v1.1-wd01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Phil Spiby - 2019-08-08

Commit
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssertion\StateAssertion.png
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssertion\StateAssertion.xmi
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssertion\Template.png
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssertion\dvlp\OASISStateAssertion.mdxml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssertion\dvlp\StateAssertion.uml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssertion\dvlp\UUIDs.xml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssertion\imagemap.xml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssessment\StateAssessment.png
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssessment\StateAssessment.xmi
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssessment\Template.png
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssessment\dvlp\OASISStateAssessment.mdxml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssessment\dvlp\StateAssessment.uml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssessment\dvlp\UUIDs.xml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssessment\imagemap.xml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StatePrediction\StatePrediction.png
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StatePrediction\StatePrediction.xmi
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StatePrediction\Template.png
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StatePrediction\dvlp\OASISStatePrediction.mdxml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StatePrediction\dvlp\StatePrediction.uml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StatePrediction\dvlp\UUIDs.xml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StatePrediction\imagemap.xml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssertion\imagemap.xml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StatePrediction\StatePrediction.xmi
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StatePrediction\dvlp\UUIDs.xml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssessment\StateAssessment.png
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StatePrediction\Template.png
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssessment\dvlp\OASISStateAssessment.mdxml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssertion\StateAssertion.png
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StatePrediction\dvlp\StatePrediction.uml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssertion\dvlp\OASISStateAssertion.mdxml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssessment\imagemap.xml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssertion\dvlp\UUIDs.xml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssertion\Template.png
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssessment\StateAssessment.xmi
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssertion\StateAssertion.xmi
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssessment\dvlp\StateAssessment.uml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StatePrediction\imagemap.xml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssertion\dvlp\StateAssertion.uml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssessment\dvlp\UUIDs.xml
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StateAssessment\Template.png
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StatePrediction\StatePrediction.png
D:\Users\SVNroot\plcslib\trunk\plcslib\data\contexts\OASIS\templates\StatePrediction\dvlp\OASISStatePrediction.mdxml

At revision: 5075

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

OASIS:StateAssertion should not restrict identifiers and descriptors

Group

Searches

Help

#416 OASIS:StateAssertion should not restrict identifiers and descriptors

Related

Discussion

Related

Related