[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: CCS Context Categories Semantic Classification was [regrep-cc-review] RE: [regrep] Summary: Issue with UUID's for Core Components and BIE's
I fully support the idea of providing 'context values' via explicit references to such things as the Publishing Authority and other Published Subject Identifiers (see Topic Map work) http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tm-pubsubj including the CCS 8 context categories. I am not convinced that the association with CCS context categories should be a mandatory - since it would suggest a blessing on that form of semantic classification. > Should the BIE also know what context value set (as per CCS - 8 context > categories) were used to help constrain it? <quote who="Steve Capell"> > ...the concept of key generator domain and external tModel > key assignment. This does away completely with the concept of registry > generated UUIDs and instead used globally unique identifiers based on the > domain of the publishing authority. The publishing authority for a UDDI > tModel (or regrep extrinsic object) creates the identifier using their > domain name as a prefix and a suffix which is unique within the domain. > Furthermore the publisher is assigned the "keyGenerator domain prefix" by > the registrar and can only publish objects with identifiers than contain > their domain suffix. > > This way we get: > 1 semantically meaningful identifiers > 2 Globally unique identifiers > 3 Interoperable identifiers (different registries will assign the same > ID to the same object) > > So for CC's & BIE's, I would use a key that is the keygenerator domain of > the issuing organization and the CCTS dictionary entry name as the suffix. > Eg something like: > > uri:unece-org:ccts:US_Address.ZIP_PostCode.Text > >> > -----Original Message----- > From: Duane Nickull [mailto:dnickull@adobe.com] > Sent: Tuesday, 13 April 2004 1:52 AM > To: UN/CEFACT Core Component WG; regrep@lists.oasis-open.org; CCRev > Subject: [regrep] Summary: Issue with UUID's for Core Components and BIE's > > Thank you for all the contributions. > > Here is an attempt to summarize what has been said > >> >> 1. Should a BIE carry the same UUID as the Core Component it was >> derived from? > > > The general consensus was "no" since they are two different artifacts. > I support this view and had a feeling that is what would be said. > >> 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 >> 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). > > The general consensus was "yes". There is also a use case that the > schema that constrains the BIE instance (assuming they are represented > in XML) should contain a URI to the registry, along with the UUID and > protocol reference. > > Some of this suggests that a use case exists to have a "Home Registry" > concept for a BIE. Lots to ponder. > >> 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. > > The consensus was that the 128 bit UUID algorythm be used for this. > Reasons stated were that the 128 bit algorythm both meets the > requirements for being unique and is an accepted principle. UDEF is not > currently part of ebXML. David RRR Webber was the lone voice is > dissention and suggested revisiting the concept of the alpha numeric > code values. > > This invites some more questions. First, should a BIE know about which > Core Component it came from. The CCTS specification version 2 of 11 Aug > suggests in figure 4.2 that this is a correct assertion. Figure 4.3 > also supports the view that a BIE can see the UMM Business Information > Entity is came from (Not sure if "came from" is the best term to use > here. Perhaps "Derived from"?). I support this sine it is likely that > there are several use cases to suuport this requirement. > > Business modellers will likely want to reconcile BIE's with CC's during > iterative business modeling. Those responsible for integrating > information or managing instances of information will likely require > additional pointers to metadata (this is what makes the CCTS so > powereful IMO). These are just two two use cases - I know of more. > > This will logically mean that the BIE must contain both its own UUID and > the UUID of the CC it came from. It may optionally (highly probably in > every instance) have to contain the other two critical attributes of the > protocol and location to bind to in order to retreive a copy of the CC. > > Let's assume that we will want a BIE to be able to reference the CC > which it was derived from. > > Should the BIE also know what context value set (as per CCS - 8 context > categories) were used to help constrain it? > I think the answer should be yes since this would help avoid unnatural > proliferation of BIE's. This would place a requirement for a > serialization of the context value set in addition to the BIE and CC's > themselves. The model is fairly easy to work from and I have taken a > crack at it. I think that this wil fall into place fairly easily. > > Aside from that, I believe personally that the CCTS is now 100% > implementable. The methodology has great value for all vertical and > horizontal fields. I do not see any major issues that would prevent it > from being implemented within an ebXML registry. > > I will incorporate this thread into the CC-Review work STC of the OASIS > RegRep TC. > > -- 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]