MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ubl] Question from TBG17
From: Tim McGrath <>
To:
Date: Wed, 11 Aug 2004 10:00:25 +0800
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.
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
