Hi Darius As this is pretty fundamental I want to add this in to our schema Presumably this is intended to be specialized from the ClassifiedIdentification template I believe you discussed this in yesterdays modeling meeting but I missed most of it so please bear with me 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.
1 hasObject Thing 2 valIdentifier ExpressString 3 hasContext ClassOfClassOfIdentification
I noticed that the roles on the template in iring were
hasObject valIdentifier hasIdentificationType
Am I correct in assuming that it is role 3 that you are constraining ? If so what Role Value will you be expecting from the WIP either TAG NUMBER or TAG IDENTIFICATION CODE seem reasonable fits
Yes, IdentificationByTag is specialized from the Part 7 initial set template ClassifiedIdentification.
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.
Onno, do I have the above correct?
As for the specialized roles, we constrained two. 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.
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.