Hi Lutz,
The cardinality is left flexible but that doesn't mean that you can make it more strict for your use case.
I see two options:
1. GeographicSite.relatedPlace references one (and only one) GeographicSubAddress. The datamodel of the GeographicSubAddress is extended with a reference to its GeographicAddress. I believe it was a mistake to make the relationship from GeographicAddress to GeographicSubAddress. Instead it should have been a unique relationship from GeographicSubAddress to GeographicAddress.
2. GeographicSite.relatedPlace reference 2 items. One is the GeographicSubAddress, the other is the GeographicAddress.
This fits the current model.
Although option 2 can be done without changes to the model, I would prefer the first option as it is a cleaner solution.
------------------------------
Koen Peeters
OryxGateway
------------------------------
Original Message:
Sent: Apr 28, 2022 07:35
From: Lutz Bettge
Subject: TMF674 GeographicSite
We are using Geographic Site to link the addresses (incl. subaddress information, like room number) to the customer, so that we can find out all sites of the customer where we could install e.g. a router, and when the user of the order capture system selects one of them, in the ProductOrder we need to express where the router should be placed, i.e. we need exactly one address incl. subaddress. For that we use the RelatedPlace in the ProductOrder, which then refers to a GeograpgicSite. But the association GeographicSite to GeographicAddress (referred by GeographicSite.RelatedPlace) is 0..*, and also the association GeographicAdress to SubAddress is also 0..*, so it is not possible to umabiguously identify the correct Subaddress (i.e. the server room).
Any idea how this should be handled?
------------------------------
Lutz Bettge
Deutsche Telekom AG
------------------------------