Open APIs

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

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

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

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

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

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

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

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

@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

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

In our internal enterprise data model we use the notion of network installation point which is connected to the notion of network termination point .
In case of fiber there is an ONTP which connects via another optical fiber cable to an ONT (optical modem) with one or more UTP based L2 ethernet ports.
The ONTP (one resource) could have 2 fiber outlets which represent 2 network installation points.
We don't have service point. I fear we need a better definition or description of the concept.
Would you consider each of the physical ports of the ONT which represent potentially a resource and a RFS (L2 ethernet access?) as a service point?

In our internal enterprise data model we use the notion of network installation point which is connected to the notion of network termination point .
In case of fiber there is an ONTP which connects via another optical fiber cable to an ONT (optical modem) with one or more UTP based L2 ethernet ports.
The ONTP (one resource) could have 2 fiber outlets which represent 2 network installation points.
We don't have service point. I fear we need a better definition or description of the concept.
Would you consider each of the physical ports of the ONT which represent potentially a resource and a RFS (L2 ethernet access?) as a service point?

In our internal enterprise data model we use the notion of network installation point which is connected to the notion of network termination point .
In case of fiber there is an ONTP which connects via another optical fiber cable to an ONT (optical modem) with one or more UTP based L2 ethernet ports.
The ONTP (one resource) could have 2 fiber outlets which represent 2 network installation points.
We don't have service point. I fear we need a better definition or description of the concept.
Would you consider each of the physical ports of the ONT which represent potentially a resource and a RFS (L2 ethernet access?) as a service point?

------------------------------
Peter Broucke
Proximus SA
------------------------------