ubl — archive

RE: [ubl] Defining Geograpic areas in UBL - How?

From: Ken Holman
To: [email protected]
Date: Sat, 08 Aug 2009 14:30:00 -0000

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:[email protected] Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/o/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal