[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Junkmail: Re: [ubl] Question from TBG17
Tim McGrath (UBL) Wrote: Firstly, this issue does depend on your definition of 'address' and 'location'. we have chosen not to separate them. we define 'address' as "the particulars that identify and locate the place where someone lives or is situated, or where an organisation is situated." So, in fact, our definition covers location as well. You can think of this as "an address describes a location". We do have some additional properties where a location may not be expressed using address-like properties (the classic oil-platform example). we call this 'location co-ordinates' and it is defined as "contains information that enables location (of something) by a system of coordinates." So your question does not apply to UBL - these properties already belong to the location object. it is just that we call it address. [MC] - It absolutely does apply to UBL. We have chosen to build a library without due consideration to the underlying core components. We could get away with this and claim CCTS conformance because we were waiting for UN/CEFACT to build the library of CCs. That is now underway and we need to be involved in that process. If our BIEs in their current form are not mappable to the CEFACT Core Components, then we either align our BIEs or loose any claim of conformance and compatibility with UN/CEFACT. For my part, that alignment is critical to UBL legitimacy and adoption. In working to create the CEFACT Core Components library, We must give sound business case justifications for our positions and avoid justifications like "it is just that we call it address" because we think it is simpler. That kind of thinking is wrongheaded and must be avoided. TBG17 is working to build a very logical object class suite using the principles of UML and CCTS. The attributes for each class must be logical, and must recognize the relationships to other classes. If attributes are allowed to be added ad nauseum to a class, then the class becomes unmanageable and reuse is significantly degraded. I would much rather see logical subclasses that are reusable than too many attributes. Tim wrote: If we modeled this component fully we would find that several object classes are involved. Things like Building, Street, City, Country, Region, District, Timezone and so forth. These are all separate object classes with their own properites like Street Number, Region Name, District Code, Country Code, Timezone Offset, etc. The Street Number depends on the Street (not the Address), the name of the Region depends on the Region (not the Address) and the TimeZone Offset depends on the TimeZone (not the Address). So, in fact, there are more than the three you identifed. So technically we should have ABIEs for Building, Street, City, Country, Region, District, Timezone and so on.... This would resolve your issue. These things could belong in other object classes - but not necessarily the ones you propose. Because Address. Region. Text would become a BBIE called Region. Text and within an ABIE called Region. Address. District. Text would become a BBIE called District. Text with an ABIE called District. Address. Timezone Offset. Text would become a BBIE Timezone. Text with the ABIE Timezone. Any or all of these new ABIEs could be associated with Address or Location. [MC] You seem to be missing the point with your examples by going from one extreme to the other, oversimplifying the use of subclasses, and not recognizing there are an optimum number of classes as reusable logical containers with reasonable levels of attributes. Tim wrote: However, this 'correct' way to model our required component is rather more complex than most of us feel is practical. So, in UBL we chose to 'flatten' these into one structure and call it address (it could have been called location - but that is an ontological issue not a structural one). [MC} And for the reasons above, this approach is wrong. Mark
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]