Re: ExternalIdentifier overlap with external classifications

[Len Gallagher <LGallagher@nist.gov>]

Farrukh,

I don't think that the ClassificationScheme mechanism is quite ready yet to 
use in the way you describe below. I think there's an implicit assumption 
that a classification scheme definition (whether external or internal) will 
include a finite list of all possible node code's. Until we extend the 
notion of classification scheme to include "USER_INPUT", or some other 
notion of a node code taking on an arbitrary value, it could not 
conveniently be used to define an external identifier.

If we allow USER_INPUT as the defined type of a node in a classification 
scheme definition (cf Section 7.5 of the Dec 2000 OASIS Reg/Rep 
specification, Semantic Rule #2),  then one could define a new 
classification scheme with a single node defined as USER_INPUT and one 
could use a copy of that classification scheme (each with a different name) 
for each different kind of external identifier. For example, we could 
define DUNSnumber as such a one-node classification scheme, or Employer 
Identification Number (EIN) as a separate one-node classification scheme, etc.

But, I don't think we're quite ready to go there for RIM version 2. And 
even if we do, some people think that ExternalIdentifier is important 
enough to merit its own Class and explicit support in the model. I'd favor 
adding a single new attribute to that class, e.g. Role, to be used to 
distinguish among the various kinds of external identifiers. The values for 
Role could then be drawn from a published Enumeration domain (e.g. DUNS, 
EIN, UUID, SSN, etc) which will likely be registered as a "dynamic 
compatible" classification scheme in some ebXML Registry.

NOTE: I'm taking the liberty to copy this email to the entire "regrep" list 
to see what kind of support there is for adding a new "Role" attribute to 
the ExternalIdentifier class. I propose a new attribute instead of using 
the existing "name" attribute even though I think the "name" attribute is 
superfluous in this class. I'd also propose dropping the "name" attribute 
from RegistryObject and instead put it in each of RegistryEntry, 
ClassificationNode, User, ExternalLink and Organization. It has real 
meaning in each of those places, but has no well-understood meaning in 
Classification, Association, ExternalIdentifier or AuditableEvent.

-- Len



At 12:39 PM 9/1/01, Farrukh Najmi wrote:

>In retrospect an ExternalIdentifier is just like an external
>classification where the taxonomy is an identification taxonomy instead
>of a classification taxonomy. Another way to look at it is that
>identification is a form of classification. Imagine DUNS being a
>classification scheme and all the companies (Iona, Stirling Commerce,
>...) are just nodes in a classification tree rooted under DUNS scheme.
>
>By treating external identification by re-using classification we can
>remove ExternalIdentifier all together but keep a separate method for
>getting identifiers in RegistryObject. Alternatively we could keep it
>but make it 2 empty sub-classes of Classification and
>ExternalClassification propose in a previous email. See:
>
>
>http://lists.oasis-open.org/archives/regrep-ex-scheme/200109/msg00000.html
>
>for details.
>
>Other Problems with current ExternalIdentifier
>-----------------------------------------------
>A related matter is that the ExternalIdentifier class currently does not
>have adequate attributes. An external identifier needs to have its
>identification scheme defined by a ClassificationScheme (internal or
>external). Currently the name attribute provides that info. But we need
>a
>human friendly name for each external identifier. Take the example where
>Sun is identified under DUNS with name Sun and value "123". Current
>ExternalIdentifier witll use its name attribute for "DUNS" to identofy
>scheme and value would be "123" leaving no place for user friendly name
>"Sun".
>
>Summary
>----------
>By removing or sub-classing ExternalIdentifier we not only make it
>possibloy for an external id to be based on an internal or external
>coding scheme we also fix some bugs with current model.
>
>--
>Regards,
>Farrukh
>

**************************************************************
Len Gallagher                             LGallagher@nist.gov
NIST                                      Work: 301-975-3251
Bldg 820  Room 562                        Home: 301-424-1928
Gaithersburg, MD 20899-8970 USA           Fax: 301-948-6213
**************************************************************