Changes between Version 2 and Version 3 of SigMmt/Templates/IdentificationByTag

Show
Ignore:
Timestamp:
09/09/10 22:21:43 (14 years ago)
Author:
dkanga (IP: 38.109.155.98)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SigMmt/Templates/IdentificationByTag

    v2 v3  
    33As this is pretty fundamental I want to add this in to our schema 
    44  
    5 Presumably this is intended to be specialized from the ClassifiedIdentification template 
     5Presumably this is intended to be specialized from the !ClassifiedIdentification template 
    66  
    77I believe you discussed this in yesterdays modeling meeting but I missed most of it so please bear with me 
    88  
    9 ClassifiedIdentification(a, b, c) means that b is a string and c a type of name assignment, and that b is a c-type name for a.  
     9!ClassifiedIdentification(a, b, c) means that b is a string and c a type of name assignment, and that b is a c-type name for a.  
    1010 
    1111Roles:  
     
    3737Hi Keith, 
    3838 
    39 Yes, IdentificationByTag is specialized from the Part 7 initial set template ClassifiedIdentification. 
     39Yes, !IdentificationByTag is specialized from the Part 7 initial set template !ClassifiedIdentification. 
    4040 
    41 The difference in the third role name (hasIdentificationTypevs. hasContext) is not from specialization. My understanding is that role names must be preserved when specializing. I changed the role name from Context to IdentificationType in both templates because in a discussion some time ago it was stated (I think by Onno?) that the term Context is vague, and IdentificationType better describes the role purpose. As I remember, all in the meeting agreed – I certainly did. I thought that the name was to be changed eventually in Part 7, and the “has” and “val” prefixes would be added as well. In the meantime we used the “new” names. 
     41The difference in the third role name (hasIdentificationTypevs. hasContext) is not from specialization. My understanding is that role names must be preserved when specializing. I changed the role name from Context to !IdentificationType in both templates because in a discussion some time ago it was stated (I think by Onno?) that the term Context is vague, and !IdentificationType better describes the role purpose. As I remember, all in the meeting agreed – I certainly did. I thought that the name was to be changed eventually in Part 7, and the “has” and “val” prefixes would be added as well. In the meantime we used the “new” names. 
    4242 
    4343Onno, do I have the above correct? 
    4444 
    4545As for the specialized roles, we constrained two. 
    46 We constrained hasIdentificationType to the TAG NAME class, because the definition and especially the note seemed the match the tag we all know and love. However, in the Instrument SIG workshop we discussed TAG NAME and TAG IDENTIFICATION CODE. Magne agreed that they seem like synonyms, and also have the wrong entity type (DocumentDefinition). He said that we should use TAG IDENTIFICATION CODE and deprecate TAG NAME as part of the eventual reference data cleanup., so we will change to TAG IDENTIFICATION CODE. 
     46We constrained !hasIdentificationType to the TAG NAME class, because the definition and especially the note seemed the match the tag we all know and love. However, in the Instrument SIG workshop we discussed TAG NAME and TAG IDENTIFICATION CODE. Magne agreed that they seem like synonyms, and also have the wrong entity type (!DocumentDefinition). He said that we should use TAG IDENTIFICATION CODE and deprecate TAG NAME as part of the eventual reference data cleanup., so we will change to TAG IDENTIFICATION CODE. 
    4747 
    48 We also constrained the hasObject role from Thing to PossibleIndividual. We originally planned to constrained it to a class we created called TAGGED ITEM, with the intention of making TAGGED ITEM a parent of PUMP, PIPING NETWORK SYSTEM, VALVE, etc., but dropped that idea as too messy. 
     48We also constrained the hasObject role from Thing to !PossibleIndividual. We originally planned to constrained it to a class we created called TAGGED ITEM, with the intention of making TAGGED ITEM a parent of PUMP, PIPING NETWORK SYSTEM, VALVE, etc., but dropped that idea as too messy. 
    4949 
    5050Darius Kanga 
Home
About PCA
Reference Data Services
Projects
Workgroups