OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[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]