Hi again,
In our project team, we continued struggling with the topic described in my post above, until we stumbled over following section, on page 8 of the TMF673 v4.0.0 user guide:
Some APIs, like Product Ordering, support providing a GeographicAddress as a polymorphic version of Place, per reference or per value. However, in the case there is a need to provide a specific GeographicSubAddress this cannot be done solely per reference, because the href mechanism doesn't allow this. In that case the GeographicAddress itself can be provided per reference, but the GeographicSubAddress (at least its id) has to be provided per value:
…
"place":
{
"id": "7513180",
"geographicSubAddress":
{
"id": "3"
},
"@type": "GeographicAddress" }
...
So, I wanted to share this finding with other people who might have stumbled over the same problem.
Now, even though this approach allows overcoming the problem of referencing an address with a sub-address, we are still disturbed by using GeographicAddress + GeographicSubAddress as Value to basically communicate GeographicAddress + GeographicSubAddress references.
Thus, we came up with following proposal: as both GeographicAddress & GeographicSubAddress are addressable, we could extend GeographicAddressRef with an optional GeographicSubAddressRef. Here below the extension highlighted in bold:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "GeographicAddressRef.schema.json",
"title": "GeographicAddressRef",
"definitions": {
"GeographicAddressRef": {
"$id": "#GeographicAddressRef",
"description": "The place at which the change request has occurred.",
"type": "object",
"properties": {
"href": {
"type": "string",
"description": "The detail address of the location."
},
"id": {
"type": "string",
"description": "The post code of an address."
},
"geographicSubAddress": {
"$ref": "../Common/GeographicSubAddress.schema.json#GeographicSubAddressRef"
},
"@referredType": {
"type": "string",
"description": "The actual type of the target instance when needed for disambiguation."
}
},
"allOf": [
{
"$ref": "../Common/Entity.schema.json#Entity"
}
]
}
}
}
Happy to hear about your thoughts and comments
BR, Iwan
------------------------------
Iwan Gramatikoff
Edelweiss Service Consulting SàRL
------------------------------
Original Message:
Sent: Aug 18, 2023 14:36
From: Iwan Gramatikoff
Subject: TMF673 Handling of GeographicSubAddress vs. RelatedPlace(RefOrValue)
Hi Lutz,
Good to hear from you too!
I was not aware of the Jira Ticket https://projects.tmforum.org/jira/browse/AP-4215.
I had a look into it... I must say that in my opinion, there is an inconsistency between the rejection argumentation and the current resource model of TMF673. Indeed, if the approach should be to resolve the uniqueness of sub addresses at address level saying that the address id uniquely defines each sub-address, then, as a consequence:
- Address to sub-address should be 0..1 not 0..n
- Sub-address should not be addressable (having its own id / href)
- For each sub-address you need to define / represent at the interface, you have to "repeat" the representation of the (parent)address
I personally still prefer the solution as you already described it in your ticket
And I hope the API architecture team will pick up on the discussion to define a consistent solution.
BR, Iwan
------------------------------
Iwan Gramatikoff
Edelweiss Service Consulting SàRL
------------------------------
Original Message:
Sent: Aug 18, 2023 13:08
From: Lutz Bettge
Subject: TMF673 Handling of GeographicSubAddress vs. RelatedPlace(RefOrValue)
Happy to see this suggestion again - I already proposed that early this year, but my Jira task AP-4215 got rejected.
Nevertheless, we still need a solution to state in which room/buidling/level a Resource or Product needs to be installed, so I suggest to adopt Iwan's proposal.
And relating a SubAddress to a GeographicSite enables to locate a building (e.g. a mobile base station somewhere "in the middle of nowhere", i.e. not having an address) at a GeographicLocation, via the PlaceRefOrValue of the Site.
------------------------------
Lutz Bettge
Deutsche Telekom AG
Original Message:
Sent: Aug 18, 2023 10:04
From: Peter Broucke
Subject: TMF673 Handling of GeographicSubAddress vs. RelatedPlace(RefOrValue)
According to me the GeographicSubAddress is to be interpreted as an optional part of the full address & would be insufficient to describe a place on its own.
We have even more fundamental questions regarding the place object.
For us the EU Inspire model is essential in our FTTH processes. In that context a place can be a building unit or potentially the building ( also depending if you consider a single house as a building with one building unit or not ). An address being the official one, a name or a postal box address is seen as a descriptor, a way to described/identify the place.
We are looking into ways to use TMF673 to rather "point" to the building or building unit, using the address construction in TMF673.
------------------------------
Peter Broucke
Proximus SA