Re: [regrep] CCS Context Categories Semantic Classification was [regrep-cc-review] RE: [regrep] Summary: Issue with UUID's for Core Components and BIE's

["David RR Webber" <david@drrw.info>]

Carl,

I agree on the context mechanism.  I've looked at what
Duane has implemented - and its useful in demonstrating
the CCTS 8 categories context approach.

However - the work elsewhere on context in OASIS
such as BCM, ebBP and CAM have taken a more
general approach not limited to 8 categories.

I'd support allowing either both mechanisms, or
providing a general mechanism that can
accommodate a broad range of context setting
approaches - by pointing to a context XML instance
that provides the context values to be used -
would be one approach.

Thanks, DW.

----- Original Message ----- 
From: "Carl Mattocks" <carlmattocks@checkmi.com>
To: "Steve Capell" <steve.capell@redwahoo.com>
Cc: "'Duane Nickull'" <dnickull@adobe.com>; "'UN/CEFACT Core Component WG'"
<uncefact-tmg-ccwg@listman.disa.org>; <regrep@lists.oasis-open.org>;
"'CCRev'" <regrep-cc-review@lists.oasis-open.org>
Sent: Tuesday, April 13, 2004 1:37 PM
Subject: [regrep] 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
>
> 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.
>
>