OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[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)

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
v/f (usa) 908 322 8715
Semantically Smart Compendiums

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]