Re: [regrep-cc-review] [Fwd: [ubl-lcsc] UBL Result Paper of CC Implementation Verification]

["Carl Mattocks" <CarlMattocks@CHECKMi.com>]

Agreed - the UBL comments echo our own discussions on ensuring the structures enable a '  semantically correct and meaningful information exchange package' .

UBL 1:
The UBL use of 'Adjectives' is a simple extension on the 8 categorizers. However, their use of '-' goes against the approach of 'semantic standardization  done in a syntax-neutral fashion' ... it is the beginning of a 'new syntax'.

UBL 2.. nn:
The UBL focus on (list, identifier) TYPE is a good reference.(but does not affect us)

UBL 8:
The UBL test for semantic packages is very useful.

 

> Team,
> 
> The forwarded e-mail comes from the UBL Library Content Subcommittee
> (LCSC) - it's the results of their recent CCTS Implementation
> Verification. Below I've included a summary of each of the issues, with
> some comments.
> 
> I'm also copying the Registry TC at the request of Monica.
> 
> Thanks,
> Joe
> 
> UBL Comment/Proposal 1: 
> ----------------------
> Relates to our CCTS spec p.12 issue regarding whether "ResidenceAddress.
> Details" is an ACC or an ABIE. We questioned the fact that "Residence"
> (or potentially another qualifier) does not belong to one of the 8
> context categories. 
> 
> UBL suggests that "Qualifiers of Object Class and Property Terms should
> be divided into two, namely "Context Driver" and "Adjective" Qualifiers.
> The "Context Driver" Qualifiers are values from one of the CCTS context
> driver categories. The "Adjective" Qualifier is any other value that
> qualifies the object class or property term noun.". 
> 
> MY COMMENTS: 
> In the CCTS spec p.12 example, "Residence" would be considered an
> "Adjective" Qualifier.
> 
> UBL Comment/Proposal 2: 
> ----------------------
> Addresses how a Data Type is defined. More specifically, gives the
> following example:
> 
> "For example, "Buyer_ Product. Type. Code" has a fixed length of 3
> characters and the "Seller_ Product. Code" has a variable length with a
> minimum of 2 characters and a maximum length of 5 characters. Is it now
> necessary to define a separate "Data Type" for each of these two BBIEs?
> What should the names of such Data Types be?"
> 
> MY COMMENTS: 
> According to the CCTS spec, it would be necessary to define separate
> Data Types for each of these two BBIEs. Each Data Type would be based on
> an "Amount. Type" CCT. The first Data Type would have a Content
> Component Restriction with a Format Restriction of "Length", and a
> Restriction Value of "3". The second Data Type would have a Content
> Component Restriction with a Format Restriction of "Maximum Length", and
> a Restriction Value of "5". These Data Types would be reusable for
> multiple Core Components.
> 
> Regarding naming: The UBL document offers 2 approaches - one is specific
> to the BBIEs that are ultimately produced, the other more generic (ex:
> "3Characters_Code. Type". The CCTS spec is silent on Data Type naming
> conventions, and it is out of the scope of our CC Review work. Hopefully
> a "best practice" document will emerge on this in the future.
> 
> UBL Comment/Proposal 3: 
> ----------------------
> Addresses the use of Data Type qualifiers: "It is nor very clear, how we
> can use the Qualifiers of Data Types in the specific BCCs or BBIEs.".
> 
> MY COMMENTS:
> To date, we've placed the Property Term Qualifier attribute on the BCC
> rather than the Data Type, because the Property Term attribute is on the
> BCC. However, I think there may be scenarios in which a Data Type may
> require a qualifier. I'll be sending a note out about this very soon.
> 
> UBL Comment/Proposal 4: 
> ----------------------
> Addresses the difference between the "Code. Type" and "Identifier. Type"
> CCTs.
> 
> MY COMMENTS:
> Does not affect us, as it is more of an issue of how the Core Components
> methodology is applied.
> 
> UBL Comment/Proposal 5: 
> ----------------------
> Suggests adding new Supplementary Components to CCTs "Code. Type" and
> "Identifier. Type".
> 
> MY COMMENTS:
> Does not affect us in the short term.
> 
> UBL Comment/Proposal 6: 
> ----------------------
> Suggests adding new Core Component Types.
> 
> MY COMMENTS:
> Does not affect us in the short term.
> 
> UBL Comment/Proposal 7: 
> ----------------------
> Suggests adding new Representation Terms to Table 8-3.
> 
> MY COMMENTS:
> Does not affect us in the short term.
> 
> UBL Comment/Proposal 8: 
> ----------------------
> Proposes the concepts of "Semantic Packages" and "List Containers"
> 
> MY COMMENTS:
> Does not affect us in the short term. List Containers are represented by
> us as multiple Associations from an ACC/ABIE to another ACC/ABIE. For
> the naming concepts (ex: "Items. List"), an implementation could require
> the ".List" extension if the Cardinality of an ACC within another ACC
> (or ABIE within another ABIE) is greater than 1.
> 
> UBL Comment/Proposal 9: 
> ----------------------
> Addresses the overlap between Data Types and Representation Terms (ex:
> Data Type of "Text", Representation Term of "Text"). 
> 
> MY COMMENTS:
> Note comments in UBL document:
> 
> "None of this convoluted problems would exist if we simplifed the
> meta-model.  The name of the BIEs gives the semantics to identify a
> consistent, logical piece of information.  The concern about specific
> physical characterics is confusing the real issues of defining semantic,
> syntax-neutral, core components."
> 
> I believe this echoes some of our sentiments.
> 
> UBL Comment/Proposal 10: 
> -----------------------
> Related to Comment/Proposal #1 - addresses the use of qualifiers for
> Object Class Terms and Property Terms.
> 
> MY COMMENTS:
> None.
> 

carl
Carl Mattocks
CEO CHECKMi
e-mail: CarlMattocks@checkmi.com
*******************************************
Business Agent Software that
Secures Knowledge for Reputation:Protection
*******************************************
CHECKMi Compendium the shortcut to Valued & Trusted Knowledge
******************************************* 
www.checkmi.com
(usa)1-908-322-8715
CarlCheckMi (I M)