[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]
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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]