[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep-cc-review] [Fwd: [ubl-lcsc] UBL Result Paper of CC Implementation Verification]
<Quote> 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'. </Quote> Thanks Carl - would you be willing to elaborate on the above point? Joe Carl Mattocks wrote: > > 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)
begin:vcard n:Chiusano;Joseph tel;work:(703) 902-6923 x-mozilla-html:FALSE url:www.bah.com org:Booz | Allen | Hamilton;IT Digital Strategies Team adr:;;8283 Greensboro Drive;McLean;VA;22012; version:2.1 email;internet:chiusano_joseph@bah.com title:Senior Consultant fn:Joseph M. Chiusano end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]