If I understand correctly 'Riverside Tower' is building name, remaining part is flat , block and etc. I believe you can use the below options.GeographicSubAddress.buildingName for your building nameGeographicSubAddress.subUnitType - for TOWER, FLATGeographicSubAddress.subUnitNumber - for FLAT noGeographicSubAddress.levelType - eg : floor, basementGeographicSubAddress.levelTypeNumber - eg : 2nd floor, basement 2specification pdfHope this helps
@Florin Tene can you share a link where I might find information regarding the upcoming changes within the TMF673?
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:
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.
------------------------------Florin TeneCityFibreOriginal Message:Sent: Oct 20, 2021 03:43From: Steve Ranford-BraggSubject: TMF673 - GeographicAddress - BuildingHi 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-BraggBT Group plcOriginal Message:Sent: Oct 19, 2021 12:03From: Darren WylieSubject: TMF673 - GeographicAddress - BuildingHiI 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 3BTThe 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 addressGeographicSubAddress.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 WylieBT Group plc------------------------------