On 18/01/2011 20:27, Grahame Grieve wrote: > >> type: String - The identifier type, such as ?prescription?, or ?SSN?. One >> day a controlled vocabulary might be possible for this. >> >> I don't think the 'type' is confused modelling; it just indicates what kind >> of identifier it is. > the identifier is a pointer to a thing. The thing has a type. The pointer > to the type shouldn't carry the type of the thing it points to. (though I > often think that debugging/troubleshooting would be simpler if it did!)
Although the type information is redundant, it can be reasonable to have it in the reference. Consider that the 'thing pointed to' may be buried in the state motor vehicle database, or some other inaccessible (to you) system... > You say that the type is the *type of the identifier*. Well, that's > interesting. > How can a pointer have a type? in the common understanding of the term, most people would understand the question 'what id is that you are giving me', and the answer would 'that's my drivers license number' (DVLA) or social security number (SSN) or whatever. Most real world entity identifiers around today are not Oids, but some custom id system, like your license number, veterans number and so on, and it is usually helpful to know what kind of id it is. I agree that this field might overlap with the 'issuer' and / or 'assigner', and maybe one day it will never be needed. But there appear to be uses for it now. > In the ISO datatypes, we added two properties to the II data type, "scope" > and "reliability". Reliability is under appreciated, but adding scope has > had a series of interesting consequences. Possible values for scope: > BUSN : Business identifier > OBJ : Object identifier > VER : Version identifier > VW : View specific identifier > The really interesting one here is "BUSN". Here's the full definition: > > An identifier whose scope is defined by business practices > associated with the object. In contrast to the other scope > identifiers, the scope of the use of the id is not necessarily > restricted to a single object, but may be re-used for other > objects closely associated with the object due to business > practice. this is related to the openEHR distinction between real world entity (RWE) identifiers, and Instance Identifiers (IIs) - see http://www.openehr.org/releases/1.0.2/architecture/rm/support_im.pdf - OBJ & VER are part of Instance Ids (i.e. system internal ids) while BUSN is a RWE id. I don't know what a VW corresponds to... The various types in the Identification package in this PDF plus the DV_IDENTIFIER cover all of these types I think. > Making this property explicit has forced everyone to re-evaluate > their use of identifiers, and some interesting things have emerged. > Firstly, we are crucially interested in two different types of identifier > usage: what you might call "direct" and "indirect". (At one time you > referred to this division as "real world identifier" and "technical > identifier", but this isn't obvious in the tools, and I'm too lazy to look > it up again). We have come to recognise that this is the same as > a "business identifier" vs one of the other types. On further examination, > we've found that business identifiers are almost exclusively linked > with "roles" (RIM speak, sorry), and then where there are external > registration authorities for the roles (patients, people, doctors, > companies, etc) that may be true in reality, but it isn't often a useful thing to record. E.g. if someone comes along with a Driver's license, you normally just record the id, and what kind of id it is, e.g. UK drivers license; you don't want to model any role connection between the patient and the DVLA or DMV or whatever. > If by "type", you mean things like "scope" or "reliability", then ok. > But the possible values need to be enumerated to make them > useful to implementers. I agree. I think it may emerge that 'scope' is the most useful thing to use it for. I expect its utility to be better defined in the future. * * - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110118/5facce6c/attachment.html>
