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: [ubl] Question from TBG17


As i won't be at the meeting next week I will put my views in email.  

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.  

As a general principle, i would caution against simply moving properties 
from one object to another without a formal basis for doing so.  This 
can become an exercise that goes on forever.  I would have thought that 
TBG17 would be more interested in identifying why Address. Region. Text, 
Address. District. Text and Address. Timezone Offset. Text are different 
from the other properties in this object?  

The rule UBL tries to follow is that of functional dependency.  if the 
value of something depends on the instances of the object class - they 
are properties of the object class.  However, experience has taught us 
to recognize that in practice this needs to be guided by a 
reasonableness test.

The address ABIE is a good example of this compromise.  

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.

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).

PS another guiding factor was the work of the OASIS CIQ TC and their xAL 
vocabulary.  A partial class diagram of xAL is attached - just to show 
how detailed you can get with these things.


marion.royal@gsa.gov wrote:

>1.  I am attending TBG17 this week and have come across questions regarding
>Address. Region. Text, Address. District. Text and Address. Timezone
>Offset. Text
>I haven't succussfully defended the business requirement to have those a
>part of an address object (they might fit in a Location Object).  Can
>someone help me out.
>
>2. Should this be the place for me to ask these questions this week?
>
>marion
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php.
>
>  
>

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160


GIF image



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]