[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] Issue with UUID's for Core Components and BIE's
Yes, Yes - similar to the way the Getty Art Foundation acts as the authority for the semantic relations embedded in Art & Architecture Thesuarus and ACORD is the authority for Schemas used in Insurance transactions (and eventually the ontology) ... I expect the content of many Registry / Repository services will be organized using 'associations' defined elsewhere and therefore require synchronization on a regular basis. . <quote who="David RR Webber"> > Carl, > > You raise an interesting another point. In BCM we talk about > domains, communities of interest and then authoritive sources. > > Such an authority clearly has to be responsible for managing the > UID values within their domain. > > Using my example - the USPS is managing the semantics > around their address formats. Then this can be crosswalked > to the international authority - the UPU - and their UID set, > and similarly the OASIS CIQ too. > > However - you expect that domain analysts can work > offline - and then later upload or share their work with > both RR servers and co-workers. This is another > critical value - that avoids the need for an RR in order > to be able to do CCTS. If you use UUID - you are almost > mandating that people have to do this with RR - and that > clearly breaks the ebXML need for components to be > self-sufficient. > > The good news is - by decoupling away from UUID values > and using UID as the reference - any registry can happily > import those definitions and assign it own local UUID internal > keys to those entries - without breaking anything. > > Also - by using the UID - you can track groups of related > definitions ( query on "USPS0201*" ) and so on - and > versions and sub-versions (query on "USPS020120:*") - > which is not possible in a UUID based system. > > Notice also that if you want to use something like UDEF id > in addition - or in place of the 6 digit UID - this also > works - for the same reasons - the authoritative source > creates the UDEF ids and these then become the domain > reference system. > > All these behaviours and more is why the reference system > for the semantic building blocks should be using the UID > tied to the registry RIM external ID as the foundation. > > Thanks, DW. > > ----- Original Message ----- > From: "Carl Mattocks" <carlmattocks@checkmi.com> > To: "Chiusano Joseph" <chiusano_joseph@bah.com> > Cc: "Duane Nickull" <dnickull@adobe.com>; <regrep@lists.oasis-open.org> > Sent: Friday, April 09, 2004 11:07 AM > Subject: Re: [regrep] Issue with UUID's for Core Components and BIE's > > >> >> <quote who="Chiusano Joseph"> >> > Duane Nickull wrote: >> >> >> >> Apologize for the cross post in advance, but I feel both of these > groups >> >> need to address this issue. >> >> >> >> The Core Components and Registry specs both mandate a unique >> identifier >> >> to be used in certain places. IN the registry, it is for every >> single >> >> registry object. Each Core Component also must have an identifier. >> >> There were some questions however that do need further discussion >> IMO. >> >> >> >> 1. Should a BIE carry the same UUID as the Core Component it was > derived >> >> from? >> > >> > IMHO, no. They are 2 distinct entities. >> >> Agreed >> >> > >> >> 2. Either in addition to, or alternatively to #1, should a BIE carry >> >> its' own unique UUID? If it is placed into a registry, the UUID will >> > Yes - and we may want to explore the possibility of a BIE's UUID being >> > somehow related to its "base" Core Component's UUID - perhaps by >> > reflecting a part of the Core Component's UUID within the BIE's UUID >> > somehow. But on the other hand this might be too heavyweight... >> >> imho this is too cumbersome >> >> >> >> be >> >> assigned to it by the registry, but it also need to be serialized > inline >> >> into the BIE to be used outside of the registry or in places where >> >> access to the Registry RIM instance data is not possible. (real world >> >> use cases exist for this). >> >> I think this is the crux of the problem that DW referred too. Once the >> RR >> generated contructs are used outside of the RR the urn + uuid + >> associations may have liitle relevance. Most likely a new set of >> 'locally >> generated' (non RR compliant) identifiers will be imposed. Which >> creates >> a synchronization nightmare if a round-trip is ever attempted. OMG folk >> spent a lot of time developing XMI to address this need. >> >> >> >> >> 3. If the BIE does have to have it's own UUID, possibly in addition >> to >> >> the COre COmponents UUID, should this UUID be in the 128 bit >> algorithm > >> >> format OR should it use something akin to the UDEF format that can >> >> convey context variables? This may be crucial to aid business >> mappers >> >> and integration software (rich client applications) to map the BIE to >> >> existing data sources. >> >> agreed on URN + UUID . Additional (extrinsic ?) identifiers can be added >> as required. >> >> >> -- >> Carl Mattocks >> >> co-Chair OASIS (ISO/TS 15000) ebXMLRegistry Semantic Content SC >> CEO CHECKMi >> v/f (usa) 908 322 8715 >> www.CHECKMi.com >> Semantically Smart Compendiums >> (AOL) IM CarlCHECKMi >> >> To unsubscribe from this mailing list (and be removed from the roster of > the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php. >> >> > > -- Carl Mattocks co-Chair OASIS (ISO/TS 15000) ebXMLRegistry Semantic Content SC CEO CHECKMi v/f (usa) 908 322 8715 www.CHECKMi.com Semantically Smart Compendiums (AOL) IM CarlCHECKMi
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]