Open APIs

We have a concept called ServicePoint in our as-is-architecture and we're trying to find the most appropriate equivalent for our TMF aligned to-be-architecture.

A ServicePoint in our system is linked with a single geographic address, which in turn can have multiple ServicePoints.
ServicePoints pre-exists any service. They are created ahead of time for all households in areas where we build access/metro networks.
It is used in both feasibility check and service orders to answer the question "WHERE do you want the service delivered?"

Can anyone offer any guidance to how this concept is modelled in TMF?
Of course the where-question hints at using a sub type of Place, but which one (including the option to extend with a specific sub type for ServicePoint)?
There have also been suggestions to model it as a resource, but how then to use it in SQM and SOM to answer the where-question?

Hi Torbjørn,

I have seen this concept being represented in multiple ways, so I do not assume to provide here the one and only answer, but what is my opinion and recommendation for a best fit with the TMF semantics.

What you call a ServicePoint is best modelled as a GeographicSite:

• A GeographicSite's  Where is defined by GeographicAddress / SubAddress and or GeographicLocation
• A GeographicSite has siteCategory and siteFeature to qualify it further eg. service capabilities

Resources bound to a ServicePoint can then be linked to GeographicSite using Resource.place relationship

I hope that helps.

Best regards, Iwan

We have a concept called ServicePoint in our as-is-architecture and we're trying to find the most appropriate equivalent for our TMF aligned to-be-architecture.

A ServicePoint in our system is linked with a single geographic address, which in turn can have multiple ServicePoints.
ServicePoints pre-exists any service. They are created ahead of time for all households in areas where we build access/metro networks.
It is used in both feasibility check and service orders to answer the question "WHERE do you want the service delivered?"

Can anyone offer any guidance to how this concept is modelled in TMF?
Of course the where-question hints at using a sub type of Place, but which one (including the option to extend with a specific sub type for ServicePoint)?
There have also been suggestions to model it as a resource, but how then to use it in SQM and SOM to answer the where-question?

Hi Torbjorn, Iwan,

Iwan is correct that your ServicePoint is best modelled as a GeographicSite. GeographicSites are places with a specific relevance for the CSP. It is where Resources can be placed.

I would like to share the siteCategories that I modelled for an FTTH network.

Hi Torbjørn,

I have seen this concept being represented in multiple ways, so I do not assume to provide here the one and only answer, but what is my opinion and recommendation for a best fit with the TMF semantics.

What you call a ServicePoint is best modelled as a GeographicSite:

• A GeographicSite's  Where is defined by GeographicAddress / SubAddress and or GeographicLocation
• A GeographicSite has siteCategory and siteFeature to qualify it further eg. service capabilities

Resources bound to a ServicePoint can then be linked to GeographicSite using Resource.place relationship

I hope that helps.

Best regards, Iwan

We have a concept called ServicePoint in our as-is-architecture and we're trying to find the most appropriate equivalent for our TMF aligned to-be-architecture.

A ServicePoint in our system is linked with a single geographic address, which in turn can have multiple ServicePoints.
ServicePoints pre-exists any service. They are created ahead of time for all households in areas where we build access/metro networks.
It is used in both feasibility check and service orders to answer the question "WHERE do you want the service delivered?"

Can anyone offer any guidance to how this concept is modelled in TMF?
Of course the where-question hints at using a sub type of Place, but which one (including the option to extend with a specific sub type for ServicePoint)?
There have also been suggestions to model it as a resource, but how then to use it in SQM and SOM to answer the where-question?

Thank you both for your replies.

GeographicSite is definitely an option. I think however we would name the siteCategory "ServicePoint", since our ServicePoint is created long before fiber actually enters the building or any optical termination is installed. Do you see any problems with that?

Also we have had suggestions to use polymorphism and define a new place type called "ServicePoint". Is that something either of you have experience with?

place: [
  {
    id: "xxxx-yyyyyyyy-z",
    "@referredType": "ServicePoint",
  },
],

------------------------------
Torbjørn Søiland
Lyse Tele AS

Original Message:
Sent: Oct 08, 2025 03:52
From: Koen Peeters
Subject: TMF equivalent of our concept "ServicePoint"

Hi Torbjorn, Iwan,

Iwan is correct that your ServicePoint is best modelled as a GeographicSite. GeographicSites are places with a specific relevance for the CSP. It is where Resources can be placed.

I would like to share the siteCategories that I modelled for an FTTH network.

------------------------------
Koen Peeters
Ciminko SA

Original Message:
Sent: Oct 07, 2025 03:33
From: Iwan Gramatikoff
Subject: TMF equivalent of our concept "ServicePoint"

Hi Torbjørn,

I have seen this concept being represented in multiple ways, so I do not assume to provide here the one and only answer, but what is my opinion and recommendation for a best fit with the TMF semantics.

What you call a ServicePoint is best modelled as a GeographicSite:

• A GeographicSite's  Where is defined by GeographicAddress / SubAddress and or GeographicLocation
• A GeographicSite has siteCategory and siteFeature to qualify it further eg. service capabilities

Resources bound to a ServicePoint can then be linked to GeographicSite using Resource.place relationship

I hope that helps.

Best regards, Iwan

------------------------------
Iwan Gramatikoff
Edelweiss Service Consulting SàRL

Original Message:
Sent: Oct 06, 2025 07:30
From: Torbjørn Søiland
Subject: TMF equivalent of our concept "ServicePoint"

We have a concept called ServicePoint in our as-is-architecture and we're trying to find the most appropriate equivalent for our TMF aligned to-be-architecture.

A ServicePoint in our system is linked with a single geographic address, which in turn can have multiple ServicePoints.
ServicePoints pre-exists any service. They are created ahead of time for all households in areas where we build access/metro networks.
It is used in both feasibility check and service orders to answer the question "WHERE do you want the service delivered?"

Can anyone offer any guidance to how this concept is modelled in TMF?
Of course the where-question hints at using a sub type of Place, but which one (including the option to extend with a specific sub type for ServicePoint)?
There have also been suggestions to model it as a resource, but how then to use it in SQM and SOM to answer the where-question?

------------------------------
Torbjørn Søiland
Lyse Tele AS
------------------------------

Hi ,

If you want to define ServicePoint as a strongly-typed specialization, I would recommend against defining ServicePoint as a direct specialization of Place and would rather define ServicePoint as a specialization of GeographicSite because:

1. Your servicePoint semantically corresponds to a GeographicSite:
   From TMF674 "This API defines a Site as a convenience class that allows to easily refer to places important to other entities, where a geographic place is the entity that can answer the question "where?", allowing to determine where things are in relation to the earth's surface, and can be represented either in a textual structured way (geographic address) or as a geometry referred to a spatial reference system (geographic location) "
2. You can directly leverage TMF674 API and TMFC014 ODA component

Then your sample would look like that:

place: [
{
id: "xxxx-yyyyyyyy-z",
"@baseType": "GeographicSite",
"@referredType": "ServicePoint",
},
],

Best regards, Iwan

------------------------------
Iwan Gramatikoff
Edelweiss Service Consulting SàRL

Original Message:
Sent: Oct 08, 2025 05:23
From: Torbjørn Søiland
Subject: TMF equivalent of our concept "ServicePoint"

Thank you both for your replies.

GeographicSite is definitely an option. I think however we would name the siteCategory "ServicePoint", since our ServicePoint is created long before fiber actually enters the building or any optical termination is installed. Do you see any problems with that?

Also we have had suggestions to use polymorphism and define a new place type called "ServicePoint". Is that something either of you have experience with?

place: [
  {
    id: "xxxx-yyyyyyyy-z",
    "@referredType": "ServicePoint",
  },
],

------------------------------
Torbjørn Søiland
Lyse Tele AS

Original Message:
Sent: Oct 08, 2025 03:52
From: Koen Peeters
Subject: TMF equivalent of our concept "ServicePoint"

Hi Torbjorn, Iwan,

Iwan is correct that your ServicePoint is best modelled as a GeographicSite. GeographicSites are places with a specific relevance for the CSP. It is where Resources can be placed.

I would like to share the siteCategories that I modelled for an FTTH network.

------------------------------
Koen Peeters
Ciminko SA

Original Message:
Sent: Oct 07, 2025 03:33
From: Iwan Gramatikoff
Subject: TMF equivalent of our concept "ServicePoint"

Hi Torbjørn,

I have seen this concept being represented in multiple ways, so I do not assume to provide here the one and only answer, but what is my opinion and recommendation for a best fit with the TMF semantics.

What you call a ServicePoint is best modelled as a GeographicSite:

• A GeographicSite's  Where is defined by GeographicAddress / SubAddress and or GeographicLocation
• A GeographicSite has siteCategory and siteFeature to qualify it further eg. service capabilities

Resources bound to a ServicePoint can then be linked to GeographicSite using Resource.place relationship

I hope that helps.

Best regards, Iwan

------------------------------
Iwan Gramatikoff
Edelweiss Service Consulting SàRL

Original Message:
Sent: Oct 06, 2025 07:30
From: Torbjørn Søiland
Subject: TMF equivalent of our concept "ServicePoint"

We have a concept called ServicePoint in our as-is-architecture and we're trying to find the most appropriate equivalent for our TMF aligned to-be-architecture.

A ServicePoint in our system is linked with a single geographic address, which in turn can have multiple ServicePoints.
ServicePoints pre-exists any service. They are created ahead of time for all households in areas where we build access/metro networks.
It is used in both feasibility check and service orders to answer the question "WHERE do you want the service delivered?"

Can anyone offer any guidance to how this concept is modelled in TMF?
Of course the where-question hints at using a sub type of Place, but which one (including the option to extend with a specific sub type for ServicePoint)?
There have also been suggestions to model it as a resource, but how then to use it in SQM and SOM to answer the where-question?

------------------------------
Torbjørn Søiland
Lyse Tele AS
------------------------------

when we implemented 645, we were advised by TM forum (I forgot his name but we had a workshop with a French Canadian on this topic) to use polymorphism for place.

The rationale was that PlaceReforValue exist in all TMF APIs that we use and need to represent service points (product inventory, product configurator, cart, order etc)

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS

Original Message:
Sent: Oct 08, 2025 05:33
From: Iwan Gramatikoff
Subject: TMF equivalent of our concept "ServicePoint"

Hi ,

If you want to define ServicePoint as a strongly-typed specialization, I would recommend against defining ServicePoint as a direct specialization of Place and would rather define ServicePoint as a specialization of GeographicSite because:

1. Your servicePoint semantically corresponds to a GeographicSite:
   From TMF674 "This API defines a Site as a convenience class that allows to easily refer to places important to other entities, where a geographic place is the entity that can answer the question "where?", allowing to determine where things are in relation to the earth's surface, and can be represented either in a textual structured way (geographic address) or as a geometry referred to a spatial reference system (geographic location) "
2. You can directly leverage TMF674 API and TMFC014 ODA component

Then your sample would look like that:

place: [
{
id: "xxxx-yyyyyyyy-z",
"@baseType": "GeographicSite",
"@referredType": "ServicePoint",
},
],

Best regards, Iwan

------------------------------
Iwan Gramatikoff
Edelweiss Service Consulting SàRL

Original Message:
Sent: Oct 08, 2025 05:23
From: Torbjørn Søiland
Subject: TMF equivalent of our concept "ServicePoint"

Thank you both for your replies.

GeographicSite is definitely an option. I think however we would name the siteCategory "ServicePoint", since our ServicePoint is created long before fiber actually enters the building or any optical termination is installed. Do you see any problems with that?

Also we have had suggestions to use polymorphism and define a new place type called "ServicePoint". Is that something either of you have experience with?

place: [
  {
    id: "xxxx-yyyyyyyy-z",
    "@referredType": "ServicePoint",
  },
],

------------------------------
Torbjørn Søiland
Lyse Tele AS

Original Message:
Sent: Oct 08, 2025 03:52
From: Koen Peeters
Subject: TMF equivalent of our concept "ServicePoint"

Hi Torbjorn, Iwan,

Iwan is correct that your ServicePoint is best modelled as a GeographicSite. GeographicSites are places with a specific relevance for the CSP. It is where Resources can be placed.

I would like to share the siteCategories that I modelled for an FTTH network.

------------------------------
Koen Peeters
Ciminko SA

Original Message:
Sent: Oct 07, 2025 03:33
From: Iwan Gramatikoff
Subject: TMF equivalent of our concept "ServicePoint"

Hi Torbjørn,

I have seen this concept being represented in multiple ways, so I do not assume to provide here the one and only answer, but what is my opinion and recommendation for a best fit with the TMF semantics.

What you call a ServicePoint is best modelled as a GeographicSite:

• A GeographicSite's  Where is defined by GeographicAddress / SubAddress and or GeographicLocation
• A GeographicSite has siteCategory and siteFeature to qualify it further eg. service capabilities

Resources bound to a ServicePoint can then be linked to GeographicSite using Resource.place relationship

I hope that helps.

Best regards, Iwan

------------------------------
Iwan Gramatikoff
Edelweiss Service Consulting SàRL

Original Message:
Sent: Oct 06, 2025 07:30
From: Torbjørn Søiland
Subject: TMF equivalent of our concept "ServicePoint"

We have a concept called ServicePoint in our as-is-architecture and we're trying to find the most appropriate equivalent for our TMF aligned to-be-architecture.

A ServicePoint in our system is linked with a single geographic address, which in turn can have multiple ServicePoints.
ServicePoints pre-exists any service. They are created ahead of time for all households in areas where we build access/metro networks.
It is used in both feasibility check and service orders to answer the question "WHERE do you want the service delivered?"

Can anyone offer any guidance to how this concept is modelled in TMF?
Of course the where-question hints at using a sub type of Place, but which one (including the option to extend with a specific sub type for ServicePoint)?
There have also been suggestions to model it as a resource, but how then to use it in SQM and SOM to answer the where-question?

------------------------------
Torbjørn Søiland
Lyse Tele AS
------------------------------

Hi Torbjorn, Iwan,

Iwan is correct that your ServicePoint is best modelled as a GeographicSite. GeographicSites are places with a specific relevance for the CSP. It is where Resources can be placed.

I would like to share the siteCategories that I modelled for an FTTH network.

Hi Torbjørn,

I have seen this concept being represented in multiple ways, so I do not assume to provide here the one and only answer, but what is my opinion and recommendation for a best fit with the TMF semantics.

What you call a ServicePoint is best modelled as a GeographicSite:

• A GeographicSite's  Where is defined by GeographicAddress / SubAddress and or GeographicLocation
• A GeographicSite has siteCategory and siteFeature to qualify it further eg. service capabilities

Resources bound to a ServicePoint can then be linked to GeographicSite using Resource.place relationship

I hope that helps.

Best regards, Iwan

We have a concept called ServicePoint in our as-is-architecture and we're trying to find the most appropriate equivalent for our TMF aligned to-be-architecture.

A ServicePoint in our system is linked with a single geographic address, which in turn can have multiple ServicePoints.
ServicePoints pre-exists any service. They are created ahead of time for all households in areas where we build access/metro networks.
It is used in both feasibility check and service orders to answer the question "WHERE do you want the service delivered?"

Can anyone offer any guidance to how this concept is modelled in TMF?
Of course the where-question hints at using a sub type of Place, but which one (including the option to extend with a specific sub type for ServicePoint)?
There have also been suggestions to model it as a resource, but how then to use it in SQM and SOM to answer the where-question?

I can't find a field called siteCategory in the user guide for GeographicSite.
Do you mean to extend GeographicSite with a siteCategory field, or does siteCategory refer to some other concept?

Hi Torbjorn, Iwan,

Iwan is correct that your ServicePoint is best modelled as a GeographicSite. GeographicSites are places with a specific relevance for the CSP. It is where Resources can be placed.

I would like to share the siteCategories that I modelled for an FTTH network.

Hi Torbjørn,

I have seen this concept being represented in multiple ways, so I do not assume to provide here the one and only answer, but what is my opinion and recommendation for a best fit with the TMF semantics.

What you call a ServicePoint is best modelled as a GeographicSite:

• A GeographicSite's  Where is defined by GeographicAddress / SubAddress and or GeographicLocation
• A GeographicSite has siteCategory and siteFeature to qualify it further eg. service capabilities

Resources bound to a ServicePoint can then be linked to GeographicSite using Resource.place relationship

I hope that helps.

Best regards, Iwan

We have a concept called ServicePoint in our as-is-architecture and we're trying to find the most appropriate equivalent for our TMF aligned to-be-architecture.

A ServicePoint in our system is linked with a single geographic address, which in turn can have multiple ServicePoints.
ServicePoints pre-exists any service. They are created ahead of time for all households in areas where we build access/metro networks.
It is used in both feasibility check and service orders to answer the question "WHERE do you want the service delivered?"

Can anyone offer any guidance to how this concept is modelled in TMF?
Of course the where-question hints at using a sub type of Place, but which one (including the option to extend with a specific sub type for ServicePoint)?
There have also been suggestions to model it as a resource, but how then to use it in SQM and SOM to answer the where-question?

Hi Torbjørn,

I was referring to TMF674 v5. But it appears that it is one of the v5 APIs pre-releases which have been unpublished.

In my opinion, it is safe to build on the new v5 resource model, here is the schema copied from the v5 OAS.

BR, Iwan

I can't find a field called siteCategory in the user guide for GeographicSite.
Do you mean to extend GeographicSite with a siteCategory field, or does siteCategory refer to some other concept?

Hi Torbjorn, Iwan,

Iwan is correct that your ServicePoint is best modelled as a GeographicSite. GeographicSites are places with a specific relevance for the CSP. It is where Resources can be placed.

I would like to share the siteCategories that I modelled for an FTTH network.

Hi Torbjørn,

I have seen this concept being represented in multiple ways, so I do not assume to provide here the one and only answer, but what is my opinion and recommendation for a best fit with the TMF semantics.

What you call a ServicePoint is best modelled as a GeographicSite:

• A GeographicSite's  Where is defined by GeographicAddress / SubAddress and or GeographicLocation
• A GeographicSite has siteCategory and siteFeature to qualify it further eg. service capabilities

Resources bound to a ServicePoint can then be linked to GeographicSite using Resource.place relationship

I hope that helps.

Best regards, Iwan

We have a concept called ServicePoint in our as-is-architecture and we're trying to find the most appropriate equivalent for our TMF aligned to-be-architecture.

A ServicePoint in our system is linked with a single geographic address, which in turn can have multiple ServicePoints.
ServicePoints pre-exists any service. They are created ahead of time for all households in areas where we build access/metro networks.
It is used in both feasibility check and service orders to answer the question "WHERE do you want the service delivered?"

Can anyone offer any guidance to how this concept is modelled in TMF?
Of course the where-question hints at using a sub type of Place, but which one (including the option to extend with a specific sub type for ServicePoint)?
There have also been suggestions to model it as a resource, but how then to use it in SQM and SOM to answer the where-question?

We have a concept called ServicePoint in our as-is-architecture and we're trying to find the most appropriate equivalent for our TMF aligned to-be-architecture.

A ServicePoint in our system is linked with a single geographic address, which in turn can have multiple ServicePoints.
ServicePoints pre-exists any service. They are created ahead of time for all households in areas where we build access/metro networks.
It is used in both feasibility check and service orders to answer the question "WHERE do you want the service delivered?"

Can anyone offer any guidance to how this concept is modelled in TMF?
Of course the where-question hints at using a sub type of Place, but which one (including the option to extend with a specific sub type for ServicePoint)?
There have also been suggestions to model it as a resource, but how then to use it in SQM and SOM to answer the where-question?

We have a concept called ServicePoint in our as-is-architecture and we're trying to find the most appropriate equivalent for our TMF aligned to-be-architecture.

A ServicePoint in our system is linked with a single geographic address, which in turn can have multiple ServicePoints.
ServicePoints pre-exists any service. They are created ahead of time for all households in areas where we build access/metro networks.
It is used in both feasibility check and service orders to answer the question "WHERE do you want the service delivered?"

Can anyone offer any guidance to how this concept is modelled in TMF?
Of course the where-question hints at using a sub type of Place, but which one (including the option to extend with a specific sub type for ServicePoint)?
There have also been suggestions to model it as a resource, but how then to use it in SQM and SOM to answer the where-question?

@Matt Beanland

no, a service point is not a role or what you explain.

in a nutshell, a service point is a  customer on-premise equipment to which the fiber optic cable that runs from the street is connected to. on the other side of the service point  equipment we have a LAN or fiber port to which we connect a "home-gateway" that has the WAN port, phone port, routeur, wifi etc

A service point is a hardware, it has an id, a serial number and is managed in a asset management system where we manage deployment, maintenance, upgrade, repair, installation etc.

For me it was supposed to be a tangible resource. For instance, we use the (service point) resource spec to assess service qualification with TMF645.

I'm surprised to read to model a service point as some sort of geographic entity or even a "role"!

in the early days on internet, we had copper and ADSL, the phone plug served as a service point.

Hi Torbjorn,

A place is a place and a service is a service. What I think you mean as a service point is an actually a role a service instance has at a point of time with a place. The TMF placeRef exposed on the service (in the places[] collection) is actually a mashup of the role (a property of the placeRef) and either ref/value of the place itself.

If you have a graph database you might actually have (:Service)-[:ServicePoint]->(:Place), where the role is encoded into the edge (relationship), effectively in this case saying that for this service instance that place is currently acting in the servicePoint role. In property graphs the edges can also be further enriched with properties, but if you need to enrich with other relationships (and we typically do for more complex relationships like service|resource to service|resource, where we can have relationshipCharacteristic[]) then you may model the PlaceRef explicitly, and have something like (:Service) -> (:PlaceRef %{role=:servicePoint}) ->(:Place).

Hope this helps, sometimes the json rendering actually clouds the natural relationships that exist.

Best Regards,

Matt

Matt Beanland, Principal Architect, Telstra

Creator/Maintainer at diffo-dev, https://github.com/diffo-dev

We have a concept called ServicePoint in our as-is-architecture and we're trying to find the most appropriate equivalent for our TMF aligned to-be-architecture.

A ServicePoint in our system is linked with a single geographic address, which in turn can have multiple ServicePoints.
ServicePoints pre-exists any service. They are created ahead of time for all households in areas where we build access/metro networks.
It is used in both feasibility check and service orders to answer the question "WHERE do you want the service delivered?"

Can anyone offer any guidance to how this concept is modelled in TMF?
Of course the where-question hints at using a sub type of Place, but which one (including the option to extend with a specific sub type for ServicePoint)?
There have also been suggestions to model it as a resource, but how then to use it in SQM and SOM to answer the where-question?

Matthieu, you are not the OP here so I don't think you can be so dismissive. Clearly what you are describing is a resource, however I think a nuance here with regard to the OP is that there may yet be no resources installed or planned at the 'ServicePoint' in question, merely an answer is required to the question of whether/which services could be (easily?) provided there. At Telstra we do use the placeRef role exactly for this type of thing and it works well in our ecosystem. The role is meaningless without a connection, in this case between a feasibilityChecked service (which may actually have a negative result) and a Place, Regards Matt.

@Matt Beanland

no, a service point is not a role or what you explain.

in a nutshell, a service point is a  customer on-premise equipment to which the fiber optic cable that runs from the street is connected to. on the other side of the service point  equipment we have a LAN or fiber port to which we connect a "home-gateway" that has the WAN port, phone port, routeur, wifi etc

A service point is a hardware, it has an id, a serial number and is managed in a asset management system where we manage deployment, maintenance, upgrade, repair, installation etc.

For me it was supposed to be a tangible resource. For instance, we use the (service point) resource spec to assess service qualification with TMF645.

I'm surprised to read to model a service point as some sort of geographic entity or even a "role"!

in the early days on internet, we had copper and ADSL, the phone plug served as a service point.

Hi Torbjorn,

A place is a place and a service is a service. What I think you mean as a service point is an actually a role a service instance has at a point of time with a place. The TMF placeRef exposed on the service (in the places[] collection) is actually a mashup of the role (a property of the placeRef) and either ref/value of the place itself.

If you have a graph database you might actually have (:Service)-[:ServicePoint]->(:Place), where the role is encoded into the edge (relationship), effectively in this case saying that for this service instance that place is currently acting in the servicePoint role. In property graphs the edges can also be further enriched with properties, but if you need to enrich with other relationships (and we typically do for more complex relationships like service|resource to service|resource, where we can have relationshipCharacteristic[]) then you may model the PlaceRef explicitly, and have something like (:Service) -> (:PlaceRef %{role=:servicePoint}) ->(:Place).

Hope this helps, sometimes the json rendering actually clouds the natural relationships that exist.

Best Regards,

Matt

Matt Beanland, Principal Architect, Telstra

Creator/Maintainer at diffo-dev, https://github.com/diffo-dev

We have a concept called ServicePoint in our as-is-architecture and we're trying to find the most appropriate equivalent for our TMF aligned to-be-architecture.

A ServicePoint in our system is linked with a single geographic address, which in turn can have multiple ServicePoints.
ServicePoints pre-exists any service. They are created ahead of time for all households in areas where we build access/metro networks.
It is used in both feasibility check and service orders to answer the question "WHERE do you want the service delivered?"

Can anyone offer any guidance to how this concept is modelled in TMF?
Of course the where-question hints at using a sub type of Place, but which one (including the option to extend with a specific sub type for ServicePoint)?
There have also been suggestions to model it as a resource, but how then to use it in SQM and SOM to answer the where-question?