Thank you Jonathan, appreciate your response.
Original Message:
Sent: Aug 21, 2023 07:08
From: Jonathan Goldberg
Subject: TMF673 - GeographicAddress - Building
As per my previous reply on this thread (from April 2023), I don't see that TMF has an interest in modeling all the regional standards in different jurisdictions around the world. So, @Riza Hassan feel free to use the extension mechanism, it was designed for situations such as this.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: Aug 21, 2023 04:56
From: Steve Ranford-Bragg
Subject: TMF673 - GeographicAddress - Building
Hi Riza,
Certainly for Openreach we have done as you have suggested and sub-classed the address to the local UK standard. There is some work going on at the moment with a programme to look at standardisation and we're going to look at some of the other topics here, such as characteristics of a site which hopefully will be adopted into later releases.
------------------------------
Steve Ranford-Bragg
BT Group plc
Original Message:
Sent: Aug 17, 2023 17:27
From: Riza Hassan
Subject: TMF673 - GeographicAddress - Building
Hi,
I know this is an old thread and has not been active since last few months but I have a question that I believe is closely related to this topic. Hence, I will post it here and if someone suggests that I should open a new discussion, I will be happy to do so.
Are there any provisions in the API to cater for the variations in country specific addresses? I would like to know if TMF673 (latest version whether already released or under development) has addressed the issue and solution described in RFC 5774 for country specific civic addresses. If it has not already been done, am I correct in thinking that TMF Open API Sub Classing (@type) is the way to define country specific attributes of a geographic address?<o:p></o:p>
As I am new to TMF Open APIs concepts, I will greatly appreciate any help I can get on the topic. <o:p></o:p>
Thank you.
------------------------------
Riza Hassan
T-Mobile USA
Original Message:
Sent: Apr 18, 2023 07:02
From: Jonathan Goldberg
Subject: TMF673 - GeographicAddress - Building
Some very interesting discussions going on here. The major challenge that the TM Forum has, as a creator of a global standard, is how to address local and regional variations. With around 200 jurisdictions (the number depends how you count countries/governments/etc) worldwide it's going to be difficult to keep everyone happy.
My advice is to take the base GeographicAddress and SubAddress model that we have, and extend it as per your needs.
Hope it helps
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: Apr 14, 2023 09:57
From: Steve Ranford-Bragg
Subject: TMF673 - GeographicAddress - Building
Hi Florin,
I want to split the requirements I have into a couple few different things.
The first is a locale specific address format which and adding some common models for agreed standards could be helpful but also could lead to too many variants which the API consumer has to examine and understand so it's always going to be a balance. If there was some consensus amongst the members for agreeing support for a standard in a market that would be helpful.
The second is company specific information which is needed for our internal process but also sometimes used with customers, the example being the one I gave earlier about gold/silver/bronze markers which give an indication our awareness of the address and if we currently have service there. We could sub-class that but - and I know there are different opinions - personally I prefer something along the lines of support for characteristics which I think are more flexible than a sub-class which has more impact to consumers is changes are made.
Lastly, and sort of related to the second point, are things we need to know about an address. For example, we send engineers to a property to install a service but they need to be aware of any safety or access issues - there is asbestos at a property or security must be contacted before arrival. It could be seen as a delivery address property but in some cases this is persistent data about a location and has it's own lifecycle rather than transitory data for a one off delivery.
Hope that's what you were looking for?
------------------------------
Steve Ranford-Bragg
BT Group plc
Original Message:
Sent: Nov 01, 2021 07:40
From: Florin Tene
Subject: TMF673 - GeographicAddress - Building
Hi,
Thank you all for the inputs and apologies for my late contribution.
@Tomáš Hajný, you are right; there are scenarios, especially in the Shipping context, where you might want to capture a delivery point with details regarding and individual/organization without recording them as "party" in the customer domain. For example, when we have one party playing the role of the customer buying products but wants the items delivered to another individual/organization address - like in your example to his workplace. This scenario is handled inside the ShippingOrder API via the "RelatedPartyWithContactInfo", where we can capture an individual/organization with the Address or any other contact point information. In this case, the information is captured only in the context of the shipping process (Order/Customer/Shipping), not necessarily for the generic context of the Address entity.
@Victor Anfimov articulated the difference between the GeographicAddress and a DeliveryAddress correctly.
GeographicAddress is in theory being managed by the LocationManagement platform:
- TAM -> 7.15 -
- Location Management provides the required functionality to manage the physical and logical attributes of location data for the service provider. It can include addresses (street, city, state/province, & country), geospatial information (lat/long)
On the overall, I agree with you both, it doesn't make sense to capture all the "Organisations" as parties if they are not really parties in your space just for the sake of the address-organization relationship - plus it would be a very tedious process.
In my view (which I think was also raised by @Victor Anfimov above), the organization name can't be considered address information. Still, I understand that in some cases, some CSP might want to capture "additional" information related to an address relevant to them. If they're going to capture "organization-name" or "building color" or whatever else it is up for their internal use-cases - however we need to always keep in mind the bounded context of the "Address" entity and not go wild.
So, maybe a generic approach that will allow capturing additional information for a particular address is something to be brought up for the API Governance; For this i've raise the AP-3006 today.
@Jan Lemmermann, yes, the summary of all the latest changes is available here ( https://projects.tmforum.org/wiki/display/AP/Detail+view+on+TMF673) with a summary of them below:
• AP-2719 - TMF 673 - Geo Address - does not have event for POST address
• AP-2718 - TMF 673 - Geo Address Validation - swagger not aligned with user guide
• AP-2656 - Wrong path for subresource href in examples
• AP-2633 - Conformance update for AddressValidation
• AP-2610 - TMF673 - Geographic Address - Enhance with additional operations (Post, Patch, Delete)
• AP-2485 - TMF673 - Geographic Address - Enhance with countryCode and
• AP-1032 - Geographic Address - discrepancy between spec and conformance document
• AP-2834 - TMF673 - Geographic Address – Enhance with GeographicAddressType
• AP-2790 - Manage an array of SubUnit in GeographicSubAddress
In addition to the above, there is also the AP-2999 (BuildingName) which is pending API Governance call and today i've raise the AP-3006 to see what options are available to capture additional information (scenarios presented above)
@Steve Ranford-Bragg, can you share with us what additional information you want to capture and how your mapping looks like ? I think we need to look at any opportunity to enhance the openAPIs to be a better fit and to keep the level of sub-classing to a minimum. Happy to raise them in the API Governance and get the feedback.
Thank you,
------------------------------
Florin Tene
CityFibre
Original Message:
Sent: Oct 20, 2021 03:43
From: Steve Ranford-Bragg
Subject: TMF673 - GeographicAddress - Building
Hi Darren,
We're beginning work on the address API for Openreach and we have similar issue but also have additional properties which we want to add so will be sub-classing the address property to produce something more specific. The base address model is fairly generic and so we need to extend it to also include things which we use in the UK address such as county and dependent thoroughfare, but also include building name and sub building name. In your example, if you look at the address for Riverside House, that is held in the building name.
------------------------------
Steve Ranford-Bragg
BT Group plc
Original Message:
Sent: Oct 19, 2021 12:03
From: Darren Wylie
Subject: TMF673 - GeographicAddress - Building
Hi
I am trying to model the address below using TMF673 Geographic Address but it does not seem to fit.
Riverside Tower, 5, Lanyon Place, Belfast, BT1 3BT
The part at issue is the building name, 'Riverside Tower'. There appears to be no suitable field in the GeographicAddress resource to hold it. The following have been suggested :-
name - this seems unsuitable as it appears to be some sort of friendly name rather than the official name of the building which constitutes the address
GeographicSubAddress.buildingName - this also seems unsuitable as there is no sense in which 'Riverside Tower' is a property of a sub-address. Rather, it acts as the defining characteristic of the address, equal to (and possibly an alternative to) the street number (5)
I was probably expecting to find something in the GeographicAddress resource like 'building' or 'premisesName' in which to place it.
Any help appreciated, Darren
------------------------------
Darren Wylie
BT Group plc
------------------------------