[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Review of spreadsheet hover annotations
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]