Changes between Version 2 and Version 3 of SigMmt/Templates/IdentificationByTag
- Timestamp:
- 09/09/10 22:21:43 (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
SigMmt/Templates/IdentificationByTag
v2 v3 3 3 As this is pretty fundamental I want to add this in to our schema 4 4 5 Presumably this is intended to be specialized from the ClassifiedIdentification template5 Presumably this is intended to be specialized from the !ClassifiedIdentification template 6 6 7 7 I believe you discussed this in yesterdays modeling meeting but I missed most of it so please bear with me 8 8 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. 10 10 11 11 Roles: … … 37 37 Hi Keith, 38 38 39 Yes, IdentificationByTag is specialized from the Part 7 initial set templateClassifiedIdentification.39 Yes, !IdentificationByTag is specialized from the Part 7 initial set template !ClassifiedIdentification. 40 40 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, andIdentificationType 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.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. 42 42 43 43 Onno, do I have the above correct? 44 44 45 45 As 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.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. 47 47 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.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. 49 49 50 50 Darius Kanga