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] Defining Geograpic areas in UBL - How?


At 2009-08-08 12:02 +0200, Audun Vennesland wrote:
>In the spreadsheet following the 2.0 version of UBL, it seems that 
>there is a 0..1 relationship between Address and LocationCoordinates 
>(line 29) and not 0..n. If this was a 0..n relationship as you refer 
>to Ken, I agree that this problem would be solved.

Forgive my oversight, Audun ... you are of course correct and in my 
haste I overlooked the cardinality of cac:LocationCoordinate as well 
as the other mistakes that I made.

But knowing this would address your issue gives us a direction for 
proposing UBL 2.1 modifications.

>As for a real world example:
>A transport service (as agreed to in the Transport Execution Plan) 
>will deliver a package somewhere at a large harbour terminal. The 
>exact delivery point on this terminal may not be known, but an area 
>within the terminal where the package can be delivered may be specified.
>
>We also have other information packages where this would be 
>relevant. For example the TSD (Transport Service Description). This 
>package is used to announce transport services. A Transport Service 
>Provider could for instance announce that he provides carrier 
>services from one area to another (both named and georeferenced), 
>but without their exact point locations.

Again this morning I am in a rush (I am traveling and teaching this 
week and am about to head to the airport), but I want to keep the 
discussion going.  Perhaps all we need to do for UBL 2.1 to describe 
a polygonal area is change the cardinality of 
cac:Address/cac:LocationCoordinate to "0..n".

At first glance I thought the name would be misleading, but then I 
recalled that in UBL we never use the plural in a name, we only use 
the cardinality to indicate how often the item is used.  Thus, I 
think changing the cardinality to be a multiple does not prevent us 
from re-using the currently named construct.

I'm less clear about adding the ability to specify a point and 
radius, regarding my initial thought of whether we can augment 
cac:LocationCoordinate to satisfy this need.  Having slept on it I 
think not.  I now wonder if this requirement should be a new ASBIE 
cac:Address/cac:LocationDimension with a cardinality of "0..n" where 
the associated object class of cac:LocationDimension is 
cac:Dimension.  Thus, the cac:LocationCoordinate can be used to 
pinpoint the centre and the new cac:LocationDimension can be used to 
describe the radius.  But we keep the new cardinality on 
cac:LocationCoordinate to satisfy the need to describe polygonal areas.

So, then, would the following summarize suitable changes to propose 
to UBL TSC for consideration in UBL 2.1?

  (1) - change ASBIE cac:Address/cac:LocationCoordinate cardinality to "0..n"
  (2) - add ASBIE cac:Address/cac:LocationDimension associated to cac:Dimension
        and with a cardinality of "0..n"

I hope this is considered helpful ... I have found this a useful 
exercise in my own understanding of how to add to UBL to meet new requirements.

. . . . . . . . . . . . . Ken

p.s. thank you for your patience with my mistakes

--
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
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



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