Re: [ubl] Review of spreadsheet hover annotations

[Tim McGrath <tim.mcgrath@documentengineeringservices.com>]

The one thing we have changed is this one

=========Candidate CC ID=========

Candidate CC ID

Core Component UID:

This is the UID of the correlated core component in those cases where a
direct correlation exists. This information is found in the current Core
Component Library spreadsheet model.

It should be:

=========CCL Dictionary Entry Name=========

CCL Dictionary Entry Name

Core Component Dictionary Entry Name:

This is the Dictionary Entry Name of the correlated core component in
the UN/CEFACT Core Component Library 08B (in those cases where a direct
correlation exists).


G. Ken Holman wrote:
> Would UBL TC members please review the "hover annotations" below? 
> These are the annotations that are exposed when one hovers over the 
> column heading cell of each of the columns of the UBL spreadsheets.
>
> The ones below are derived from the UBL 2.0 spreadsheets, originated 
> by Tim, edited by Jon, and then by me where I've filled in some 
> missing definitions.
>
> Note the definitions of property term possessive noun and property 
> term primary noun are meant to be identical as the wording defines 
> both terms in relation to each other.
>
> Note also that the cell heading has been copied into the annotation so 
> that there is no ambiguity as to what is being documented (some of the 
> arrows pointing to the cells are difficult to follow).
>
> If I don't hear any suggested edits, these will be the hover 
> annotations in all spreadsheets produced for UBL 2.1.
>
> I can take edits off-list ... this is just posted on-list for 
> distribution purposes.
>
> Thanks!
>
> . . . . . . . . . . . . Ken
>
>
> =========UBL Name=========
>
> UBL Name
>
> The UBL name is derived from the Dictionary Entry Name according to 
> the UBL Naming and Design Rules.
>
> If any disparity exists between the UBL Name listed here and the 
> corresponding UBL Name in the schemas, the version in the schemas 
> should be considered the correct one.
>
> (N.B.: Columns with grey headings are not part of the normative schemas.)
>
> =========Dictionary Entry Name=========
>
> Dictionary Entry Name
>
> Dictionary Entry Names are assigned according to the rules of the 
> ebXML Core Component Technical Specification, Version 2.01.
>
> The DEN is the unique official name of the Business Information Entity 
> in the data dictionary.
>
> =========Object Class Qualifier=========
>
> Object Class Qualifier
>
> A qualifier is a word or words which help define and differentiate one 
> Business Information Entity from another -- for example, when the BIE 
> is used in another context.
>
> =========Object Class=========
>
> Object Class
>
> Object Class is metadata specified by the ebXML CCTS on the basis of 
> ISO 11179 naming rules. An Object Class represents the logical data 
> grouping or aggregation (in a logical data model) to which a Property 
> belongs. Object Classes have explicit boundaries and meaning, and 
> their Properties and behaviour follow the same rules.
>
> Each Object Class is an ABIE. Object classes are also referred to as 
> Re-usable Types. They are called Classes in UML and Tables/Entities in 
> database contexts.
>
> =========Property Term Qualifier=========
>
> Property Term Qualifier
>
> Property Term Qualifier is metadata specified by the ebXML CCTS on the 
> basis of ISO 11179 naming rules.
>
> A qualifier is a word or words which help define and differentiate one 
> Business Information Entity from another -- for example, when the BIE 
> is used in another context.
>
> Property Term Qualifiers specialize or modify the Property Term. For 
> example, when the BIE is used in another context.
>
> If the word (or words) express "a type of" or specialization 
> relationship to the property term, then the word (or words) are 
> qualifiers. This implies that adjectives are likely to be qualifiers. 
> For example: Postal is a type of Zone used in an Address.
>
> =========Property Term Possessive Noun=========
>
> Property Term Possessive Noun
>
> To improve consistency in naming property terms, UBL explicitly 
> identifies possessive nouns. This is an extension of the ebXML CCTS.
>
> A Property Term may consist of one or more possessive nouns preceding 
> the primary noun. This principle refines the Property Term to make it 
> a more meaningful and consistent business name.
>
> A guide for use is to take any multi-word Property Term and try and 
> form a statement that says "PropertyTermPrimaryNoun OF THE 
> PropertyTermPossessive" or "PropertyTermPossessive's 
> PropertyTermPrimaryNoun". If this makes grammatical sense then the 
> word is a possessive noun. If not then the word is likely to be a 
> Qualifier. This suggests that non-nouns (such as adjectives) are 
> likely to be qualifiers.
>
> For example, the phrase "Name OF THE Street" or "Street's Name" makes 
> sense for an Address.StreetName. So Street is the called the 
> Possessive Noun and Name is the Primary Noun.
>
> =========Property Term Primary Noun=========
>
> Property Term Primary Noun
>
> To improve consistency in naming property terms, UBL explicitly 
> identifies possessive nouns. This is an extension of the ebXML CCTS.
>
> A Property Term may consist of one or more possessive nouns preceding 
> the primary noun. This principle refines the Property Term to make it 
> a more meaningful and consistent business name.
>
> A guide for use is to take any multi-word Property Terms and try and 
> form a statement that says "PropertyTermPrimaryNoun OF THE 
> PropertyTermPossessive" or "PropertyTermPossessive's 
> PropertyTermPrimaryNoun". If this makes grammatical sense then the 
> word is a possessive noun. If not then the word is likely to be a 
> Qualifier. This suggests that non-nouns (such as adjectives) are 
> likely to be qualifiers.
>
> For example, the statement "Name OF THE Street" or "Street's Name" 
> makes sense for an Address.StreetName. So Street is the called the 
> Possessive Noun and Name is the Primary Noun.
>
> =========Property Term=========
>
> Property Term
>
> Property Term is metadata specified by the ebXML CCTS on the basis of 
> ISO 11179 naming rules.
>
> Property Term represents the distinguishing characteristic or Property 
> of the Object Class and "shall occur naturally in the definition." It 
> is also known as an attribute (to database designers). The combination 
> of Object Class and its Property Term should give the basic semantic 
> meaning of the item.
>
> In UBL's implementation, the Property Term is constructed from the 
> Primary Noun preceded by any Possessive Nouns.
>
> =========Representation Term=========
>
> Representation Term
>
> Representation Term is metadata specified by the ebXML CCTS on the 
> basis of ISO 11179 naming rules.
>
> A Representation Term is an element of the name that describes the 
> form in which the property is represented.
>
> =========Data Type Qualifier=========
>
> Data Type Qualifier
>
> A qualifier is a word or words which help define and differentiate one 
> data type from another of the same type -- for example, to distinguish 
> those items constrained by particular code lists
>
> =========Data Type=========
>
> Data Type
>
> The data type distinguishes the lexical constraints on an item's 
> value, plus any supplemental pieces of distinguishing information.
>
> Unqualified data types in UBL are based on UN/CEFACT core component 
> types.
>
> =========Associated Object Class Qualifier=========
>
> Associated Object Class Qualifier
>
> A qualifier is a word or words which help define and differentiate one 
> Business Information Entity from another -- for example, when the BIE 
> is used in another context.
>
> Associated Object Class Qualifiers describe the "context" of the 
> relationship with another ABIE. That is, it is the role this Object 
> Class plays within its association with another Object Class. As such, 
> they duplicate the representation term.
>
> =========Associated Object Class=========
>
> Associated Object Class
>
> This is the object class at the other end of this association. It is 
> an ABIE in this model.
>
> =========Alternative Business Terms=========
>
> Alternative Business Terms
>
> Business Terms (optional) consists of one or more synonyms by which 
> the Business Information Entity is commonly known and used in a 
> specific Context. A Business Information Entity may have several 
> Business Terms or synonyms. These may be used to map BIEs to a 
> controlled vocabulary, to other vocabularies, or to labels for forms 
> presentation.
>
> =========Cardinality=========
>
> Cardinality
>
> The optionality and potential occurrences of the BIE.
>
> 0..1 – optional and only one
>
> 1 – mandatory and only one
>
> 0..n – optional and maximum of n
>
> 1..n - mandatory and maximum of n
>
> where the letter 'n' represents an unlimited number, and an actual 
> number in place of the letter 'n' is the maximum.
>
> =========Component Type=========
>
> Component Type
>
> There are three BIE Types:
>
> Basic BIE (BBIE -- white rows),
>
> Associate BIE (ASBIE -- green rows; “an association”), and
>
> Aggregate BIE (ABIE -- pink rows; “an aggregate”).
>
> =========Definition=========
>
> Definition
>
> This is the unique semantic business meaning of the Business 
> Information Entity.
>
> =========Examples=========
>
> Examples
>
> These are illustrative values that a typical user might utilize, but 
> is under no obligation to to so.
>
> =========UN/TDED Code=========
>
> UN/TDED Code
>
> The UN Trade Data Element Dictionary (ISO 7372) code for this BIE.
>
> =========Current Version=========
>
> Current Version
>
> The version number of this BIE. Can be used to generate change logs.
>
> =========Analyst Notes=========
>
> Analyst Notes
>
> This is a list of comments, queries, and notes made during data 
> modeling. It is not part of the normative schemas.
>
> =========Candidate CC ID=========
>
> Candidate CC ID
>
> Core Component UID:
>
> This is the UID of the correlated core component in those cases where 
> a direct correlation exists. This information is found in the current 
> Core Component Libray spreadsheet model.
>
> =========Context: Business Process=========
>
> =========Context: Region (Geopolitical)=========
>
> =========Context: Official Constraints=========
>
> =========Context: Product=========
>
> =========Context: Industry=========
>
> =========Context: Role=========
>
> =========Context: Supporting Role=========
>
> =========Context: System Constraint=========
>
> =========Editor's Notes=========
>
> =========Change from UBL 1.0=========
>
> =========Change for UBL 2.0 Update Package=========
>
> ==================
>
> -- 
> XSLT/XQuery training: after http://XMLPrague.cz 2010-03-15/19
> XSLT/XQuery training: San Carlos, California 2010-04-26/30
> Principles of XSLT for XQuery Writers: San Francisco,CA 2010-05-03
> XSLT/XQuery training: Ottawa, Canada 2010-05-10/14
> XSLT/XQuery/UBL/Code List training: Trondheim,Norway 2010-06-02/11
> Vote for your XML training: http://www.CraneSoftwrights.com/o/i/
> Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/
> G. Ken Holman mailto:gkholman@CraneSoftwrights.com
> Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/o/bc
> Legal business disclaimers: http://www.CraneSoftwrights.com/legal
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>

begin:vcard
fn:Tim McGrath
n:McGrath;Tim
org:Document Engineering Services Ltd.
email;internet:tim.mcgrath@documentengineeringservices.com
title:Managing Director
tel;work:+45 36 95 33 58
tel;cell:+61 438 352228
url:www.documentengineeringservices.com
version:2.1
end:vcard