Open APIs

Hello experts,

I am working on modeling parts of our network as Resources and Resource Specifications, and encountered the following need:

There are sets of multiple Resource Specifications that share a sizeable list of common Characteristic Specifications. For example, different models of a product, that have many types of characteristics in common (but also many other characteristics that are unique to each model).

We would strongly prefer to avoid the need to duplicate the list of common Characteristic Specifications in each Resource Specification that needs it. This is where the idea of a Resource Specification Template comes to mind, but I could not identify in the Resource Specification model a natural mechanism to do it.

I believe this need is also relevant to Service Specifications and Product Specifications, so might have already been considered and addressed by members of this community.

Any ideas and feedback will be much appreciated.

Sincerely,

------------------------------
Opher Yaron
Proximus SA
------------------------------

Hello experts,

I am working on modeling parts of our network as Resources and Resource Specifications, and encountered the following need:

There are sets of multiple Resource Specifications that share a sizeable list of common Characteristic Specifications. For example, different models of a product, that have many types of characteristics in common (but also many other characteristics that are unique to each model).

We would strongly prefer to avoid the need to duplicate the list of common Characteristic Specifications in each Resource Specification that needs it. This is where the idea of a Resource Specification Template comes to mind, but I could not identify in the Resource Specification model a natural mechanism to do it.

I believe this need is also relevant to Service Specifications and Product Specifications, so might have already been considered and addressed by members of this community.

Any ideas and feedback will be much appreciated.

Sincerely,

another approach is to group specifications (CompositeProductSpecification). You can also group characteristics (ProductSpecCharRelationship) to create a composite although I have a little doubt about characteristics because xxxxRelationship in the information framework is normally used to create dependencies between characteristics.

at least, that 's one recommended approach described in GB922 - Product. I suspect the same exist for service and resource since they use the same entitySpec pattern.

Hello experts,

I am working on modeling parts of our network as Resources and Resource Specifications, and encountered the following need:

There are sets of multiple Resource Specifications that share a sizeable list of common Characteristic Specifications. For example, different models of a product, that have many types of characteristics in common (but also many other characteristics that are unique to each model).

We would strongly prefer to avoid the need to duplicate the list of common Characteristic Specifications in each Resource Specification that needs it. This is where the idea of a Resource Specification Template comes to mind, but I could not identify in the Resource Specification model a natural mechanism to do it.

I believe this need is also relevant to Service Specifications and Product Specifications, so might have already been considered and addressed by members of this community.

Any ideas and feedback will be much appreciated.

Sincerely,

Hello Matthieu,

Thank you.

The challenge I have with the approach you propose is that when instantiating a CompositeResource, I would need to also instantiate additional Resources - one for each ProductSpecification that is grouped under the CompositeResourceSpecification. Is that correct? This is something I would really like to avoid.

Also, when looking in "GB922 - Resource" I find the following note:

So it's back to ResourceSpecificationRelationship...

Best regards,

another approach is to group specifications (CompositeProductSpecification). You can also group characteristics (ProductSpecCharRelationship) to create a composite although I have a little doubt about characteristics because xxxxRelationship in the information framework is normally used to create dependencies between characteristics.

at least, that 's one recommended approach described in GB922 - Product. I suspect the same exist for service and resource since they use the same entitySpec pattern.

Hello experts,

I am working on modeling parts of our network as Resources and Resource Specifications, and encountered the following need:

There are sets of multiple Resource Specifications that share a sizeable list of common Characteristic Specifications. For example, different models of a product, that have many types of characteristics in common (but also many other characteristics that are unique to each model).

We would strongly prefer to avoid the need to duplicate the list of common Characteristic Specifications in each Resource Specification that needs it. This is where the idea of a Resource Specification Template comes to mind, but I could not identify in the Resource Specification model a natural mechanism to do it.

I believe this need is also relevant to Service Specifications and Product Specifications, so might have already been considered and addressed by members of this community.

Any ideas and feedback will be much appreciated.

Sincerely,

Ah! I didn't know about this note in GB922 resource, good catch.

I also checked the API for product (620) and resource (634) and I see the same. bundle and relationship for productspecs but only relationship for resourcespec.

For product, it does make sense to instantiate the composite and the bundled productspec (the composite productspec doesn't have any characteristic, it's only a container), it's exactly what we want.

If you create multiple distinct resourceSpecs and then for most of them create a relationship towards the commonResourceSpec, would that not work?

regarding Frederic's solution, I have, a long time ago, used a CRM that offered inheritance between productSpecs (and versioning) but I had a complicated experience with this solution. It was simple for the first setup but after a few months, when the first changes, exceptions etc. came around, it became increasingly difficult to manage.

Hello Matthieu,

Thank you.

The challenge I have with the approach you propose is that when instantiating a CompositeResource, I would need to also instantiate additional Resources - one for each ProductSpecification that is grouped under the CompositeResourceSpecification. Is that correct? This is something I would really like to avoid.

Also, when looking in "GB922 - Resource" I find the following note:

So it's back to ResourceSpecificationRelationship...

Best regards,

another approach is to group specifications (CompositeProductSpecification). You can also group characteristics (ProductSpecCharRelationship) to create a composite although I have a little doubt about characteristics because xxxxRelationship in the information framework is normally used to create dependencies between characteristics.

at least, that 's one recommended approach described in GB922 - Product. I suspect the same exist for service and resource since they use the same entitySpec pattern.

Hello experts,

I am working on modeling parts of our network as Resources and Resource Specifications, and encountered the following need:

There are sets of multiple Resource Specifications that share a sizeable list of common Characteristic Specifications. For example, different models of a product, that have many types of characteristics in common (but also many other characteristics that are unique to each model).

We would strongly prefer to avoid the need to duplicate the list of common Characteristic Specifications in each Resource Specification that needs it. This is where the idea of a Resource Specification Template comes to mind, but I could not identify in the Resource Specification model a natural mechanism to do it.

I believe this need is also relevant to Service Specifications and Product Specifications, so might have already been considered and addressed by members of this community.

Any ideas and feedback will be much appreciated.

Sincerely,

Hello Matthieu,

Thanks again.

I do not understand what the difference is between what you propose ("create multiple distinct resourceSpecs and then for most of them create a relationship towards the commonResourceSpec") and Frederic's solution.

To the best of my understanding Frederic suggests the same mechanism, but with one further detail - to assign to the "relationshipType" a special value, e.g. "inheritsFrom".

Another question is about instantiation. As you pointed out, for products it is the desired behavior to instantiate both the composite and the bundled productspec. For resourceSpecs with common characteristicSpecs I find this behavior undesirable.

Best regards,

Ah! I didn't know about this note in GB922 resource, good catch.

I also checked the API for product (620) and resource (634) and I see the same. bundle and relationship for productspecs but only relationship for resourcespec.

For product, it does make sense to instantiate the composite and the bundled productspec (the composite productspec doesn't have any characteristic, it's only a container), it's exactly what we want.

If you create multiple distinct resourceSpecs and then for most of them create a relationship towards the commonResourceSpec, would that not work?

regarding Frederic's solution, I have, a long time ago, used a CRM that offered inheritance between productSpecs (and versioning) but I had a complicated experience with this solution. It was simple for the first setup but after a few months, when the first changes, exceptions etc. came around, it became increasingly difficult to manage.

Hello Matthieu,

Thank you.

The challenge I have with the approach you propose is that when instantiating a CompositeResource, I would need to also instantiate additional Resources - one for each ProductSpecification that is grouped under the CompositeResourceSpecification. Is that correct? This is something I would really like to avoid.

Also, when looking in "GB922 - Resource" I find the following note:

So it's back to ResourceSpecificationRelationship...

Best regards,

another approach is to group specifications (CompositeProductSpecification). You can also group characteristics (ProductSpecCharRelationship) to create a composite although I have a little doubt about characteristics because xxxxRelationship in the information framework is normally used to create dependencies between characteristics.

at least, that 's one recommended approach described in GB922 - Product. I suspect the same exist for service and resource since they use the same entitySpec pattern.

Hello experts,

I am working on modeling parts of our network as Resources and Resource Specifications, and encountered the following need:

There are sets of multiple Resource Specifications that share a sizeable list of common Characteristic Specifications. For example, different models of a product, that have many types of characteristics in common (but also many other characteristics that are unique to each model).

We would strongly prefer to avoid the need to duplicate the list of common Characteristic Specifications in each Resource Specification that needs it. This is where the idea of a Resource Specification Template comes to mind, but I could not identify in the Resource Specification model a natural mechanism to do it.

I believe this need is also relevant to Service Specifications and Product Specifications, so might have already been considered and addressed by members of this community.

Any ideas and feedback will be much appreciated.

Sincerely,

example of inheritance:

I create entity "ProdSpecEntityA" with 2 characteristics:

colour

size

I create entity "ProdSpecEntityB" which 1 characteristic:

weight

If I connect SpecEntityB as a "child" (for lack of better word) of ProdSpecEntityA, ProdSpecEntityBautomatically inherits ProdSpecEntityB characteristics

I create a product offering and I assign product spec: ProdSpecEntityB

that product offering, when presented through UI, API etc would have 3 characteristics

colour

size

weight

product offering is not aware of ProdSpecEntityA

composite

routerSpecEntityC has 2 characteristics:

speed

port

shiptoSpecEntityD has 4 characteristics:

address line 1

post code

etc

I bundle the above 2 specs into a composite productspec: bundleSpecEntityE

I create a product offering and I assign product spec: bundleSpecEntityE

the product offering is aware that there are 2 distinct productspecs, which I can use in the UI to construct a different user experience during order capture.

sorry I couln't help you.

Hello Matthieu,

Thanks again.

I do not understand what the difference is between what you propose ("create multiple distinct resourceSpecs and then for most of them create a relationship towards the commonResourceSpec") and Frederic's solution.

To the best of my understanding Frederic suggests the same mechanism, but with one further detail - to assign to the "relationshipType" a special value, e.g. "inheritsFrom".

Another question is about instantiation. As you pointed out, for products it is the desired behavior to instantiate both the composite and the bundled productspec. For resourceSpecs with common characteristicSpecs I find this behavior undesirable.

Best regards,

Ah! I didn't know about this note in GB922 resource, good catch.

I also checked the API for product (620) and resource (634) and I see the same. bundle and relationship for productspecs but only relationship for resourcespec.

For product, it does make sense to instantiate the composite and the bundled productspec (the composite productspec doesn't have any characteristic, it's only a container), it's exactly what we want.

If you create multiple distinct resourceSpecs and then for most of them create a relationship towards the commonResourceSpec, would that not work?

regarding Frederic's solution, I have, a long time ago, used a CRM that offered inheritance between productSpecs (and versioning) but I had a complicated experience with this solution. It was simple for the first setup but after a few months, when the first changes, exceptions etc. came around, it became increasingly difficult to manage.

Hello Matthieu,

Thank you.

The challenge I have with the approach you propose is that when instantiating a CompositeResource, I would need to also instantiate additional Resources - one for each ProductSpecification that is grouped under the CompositeResourceSpecification. Is that correct? This is something I would really like to avoid.

Also, when looking in "GB922 - Resource" I find the following note:

So it's back to ResourceSpecificationRelationship...

Best regards,

another approach is to group specifications (CompositeProductSpecification). You can also group characteristics (ProductSpecCharRelationship) to create a composite although I have a little doubt about characteristics because xxxxRelationship in the information framework is normally used to create dependencies between characteristics.

at least, that 's one recommended approach described in GB922 - Product. I suspect the same exist for service and resource since they use the same entitySpec pattern.

Hello experts,

I am working on modeling parts of our network as Resources and Resource Specifications, and encountered the following need:

There are sets of multiple Resource Specifications that share a sizeable list of common Characteristic Specifications. For example, different models of a product, that have many types of characteristics in common (but also many other characteristics that are unique to each model).

We would strongly prefer to avoid the need to duplicate the list of common Characteristic Specifications in each Resource Specification that needs it. This is where the idea of a Resource Specification Template comes to mind, but I could not identify in the Resource Specification model a natural mechanism to do it.

I believe this need is also relevant to Service Specifications and Product Specifications, so might have already been considered and addressed by members of this community.

Any ideas and feedback will be much appreciated.

Sincerely,

Hello Matthieu,

Thank you.

The challenge I have with the approach you propose is that when instantiating a CompositeResource, I would need to also instantiate additional Resources - one for each ProductSpecification that is grouped under the CompositeResourceSpecification. Is that correct? This is something I would really like to avoid.

Also, when looking in "GB922 - Resource" I find the following note:

So it's back to ResourceSpecificationRelationship...

Best regards,

another approach is to group specifications (CompositeProductSpecification). You can also group characteristics (ProductSpecCharRelationship) to create a composite although I have a little doubt about characteristics because xxxxRelationship in the information framework is normally used to create dependencies between characteristics.

at least, that 's one recommended approach described in GB922 - Product. I suspect the same exist for service and resource since they use the same entitySpec pattern.

Hello experts,

I am working on modeling parts of our network as Resources and Resource Specifications, and encountered the following need:

There are sets of multiple Resource Specifications that share a sizeable list of common Characteristic Specifications. For example, different models of a product, that have many types of characteristics in common (but also many other characteristics that are unique to each model).

We would strongly prefer to avoid the need to duplicate the list of common Characteristic Specifications in each Resource Specification that needs it. This is where the idea of a Resource Specification Template comes to mind, but I could not identify in the Resource Specification model a natural mechanism to do it.

I believe this need is also relevant to Service Specifications and Product Specifications, so might have already been considered and addressed by members of this community.

Any ideas and feedback will be much appreciated.

Sincerely,

Hi Opher,

As a simpler alternative to using polymorphism and the composite pattern, in alvatross we decided to extend the catalog with characteristic templates so that you can manage these entities independently and reuse them in all catalog specifications. Furthermore, in the last versions of the catalog APIs they introduced the concept of feature, which are groups of characteristics. I think it would be interesting, in terms of reusability, to manage feature templates as well.

Hope it helps,

Hello Matthieu,

Thank you.

The challenge I have with the approach you propose is that when instantiating a CompositeResource, I would need to also instantiate additional Resources - one for each ProductSpecification that is grouped under the CompositeResourceSpecification. Is that correct? This is something I would really like to avoid.

Also, when looking in "GB922 - Resource" I find the following note:

So it's back to ResourceSpecificationRelationship...

Best regards,

another approach is to group specifications (CompositeProductSpecification). You can also group characteristics (ProductSpecCharRelationship) to create a composite although I have a little doubt about characteristics because xxxxRelationship in the information framework is normally used to create dependencies between characteristics.

at least, that 's one recommended approach described in GB922 - Product. I suspect the same exist for service and resource since they use the same entitySpec pattern.

Hello experts,

I am working on modeling parts of our network as Resources and Resource Specifications, and encountered the following need:

There are sets of multiple Resource Specifications that share a sizeable list of common Characteristic Specifications. For example, different models of a product, that have many types of characteristics in common (but also many other characteristics that are unique to each model).

We would strongly prefer to avoid the need to duplicate the list of common Characteristic Specifications in each Resource Specification that needs it. This is where the idea of a Resource Specification Template comes to mind, but I could not identify in the Resource Specification model a natural mechanism to do it.

I believe this need is also relevant to Service Specifications and Product Specifications, so might have already been considered and addressed by members of this community.

Any ideas and feedback will be much appreciated.

Sincerely,

Hi Abel,

Thank you.

Indeed, my initial thought was also of templates. However, I did not see how to do it in a way that is compliant to the TMF634 API. Have you found a way to make it compliant?

One note - the use of a new type AbstractResourceSpecification is not full polymorphism, but rather mostly to distinguish between the two types. They are both stored in the same DB table, with the same structure, and no new JSON schema is necessary.

Best regards,

Hi Opher,

As a simpler alternative to using polymorphism and the composite pattern, in alvatross we decided to extend the catalog with characteristic templates so that you can manage these entities independently and reuse them in all catalog specifications. Furthermore, in the last versions of the catalog APIs they introduced the concept of feature, which are groups of characteristics. I think it would be interesting, in terms of reusability, to manage feature templates as well.

Hope it helps,

Hello Matthieu,

Thank you.

The challenge I have with the approach you propose is that when instantiating a CompositeResource, I would need to also instantiate additional Resources - one for each ProductSpecification that is grouped under the CompositeResourceSpecification. Is that correct? This is something I would really like to avoid.

Also, when looking in "GB922 - Resource" I find the following note:

So it's back to ResourceSpecificationRelationship...

Best regards,

another approach is to group specifications (CompositeProductSpecification). You can also group characteristics (ProductSpecCharRelationship) to create a composite although I have a little doubt about characteristics because xxxxRelationship in the information framework is normally used to create dependencies between characteristics.

at least, that 's one recommended approach described in GB922 - Product. I suspect the same exist for service and resource since they use the same entitySpec pattern.

Hello experts,

I am working on modeling parts of our network as Resources and Resource Specifications, and encountered the following need:

There are sets of multiple Resource Specifications that share a sizeable list of common Characteristic Specifications. For example, different models of a product, that have many types of characteristics in common (but also many other characteristics that are unique to each model).

We would strongly prefer to avoid the need to duplicate the list of common Characteristic Specifications in each Resource Specification that needs it. This is where the idea of a Resource Specification Template comes to mind, but I could not identify in the Resource Specification model a natural mechanism to do it.

I believe this need is also relevant to Service Specifications and Product Specifications, so might have already been considered and addressed by members of this community.

Any ideas and feedback will be much appreciated.

Sincerely,

Hi Yaron,

Extending an API does not necessarily imply that it is no longer compliant. In fact, we have extended ours and all of them are compliant and certified. To be compliant you just need to manage some entities, which should have some attributes, operations, etc. Adding and managing a new entity does not prevent you from continuing to be compliant.
About your note, you are right, and I think that this is a valid approach to implementing specification templates. We decided to use separated templates because in our case this entity is shared by the three catalogs (product, service, and resource). 

There are many options. Depending on your specific needs, some will fit you better than others.

Best regards,

Hi Abel,

Thank you.

Indeed, my initial thought was also of templates. However, I did not see how to do it in a way that is compliant to the TMF634 API. Have you found a way to make it compliant?

One note - the use of a new type AbstractResourceSpecification is not full polymorphism, but rather mostly to distinguish between the two types. They are both stored in the same DB table, with the same structure, and no new JSON schema is necessary.

Best regards,

Hi Opher,

As a simpler alternative to using polymorphism and the composite pattern, in alvatross we decided to extend the catalog with characteristic templates so that you can manage these entities independently and reuse them in all catalog specifications. Furthermore, in the last versions of the catalog APIs they introduced the concept of feature, which are groups of characteristics. I think it would be interesting, in terms of reusability, to manage feature templates as well.

Hope it helps,

Hello Matthieu,

Thank you.

The challenge I have with the approach you propose is that when instantiating a CompositeResource, I would need to also instantiate additional Resources - one for each ProductSpecification that is grouped under the CompositeResourceSpecification. Is that correct? This is something I would really like to avoid.

Also, when looking in "GB922 - Resource" I find the following note:

So it's back to ResourceSpecificationRelationship...

Best regards,

another approach is to group specifications (CompositeProductSpecification). You can also group characteristics (ProductSpecCharRelationship) to create a composite although I have a little doubt about characteristics because xxxxRelationship in the information framework is normally used to create dependencies between characteristics.

at least, that 's one recommended approach described in GB922 - Product. I suspect the same exist for service and resource since they use the same entitySpec pattern.

Hello experts,

I am working on modeling parts of our network as Resources and Resource Specifications, and encountered the following need:

There are sets of multiple Resource Specifications that share a sizeable list of common Characteristic Specifications. For example, different models of a product, that have many types of characteristics in common (but also many other characteristics that are unique to each model).

We would strongly prefer to avoid the need to duplicate the list of common Characteristic Specifications in each Resource Specification that needs it. This is where the idea of a Resource Specification Template comes to mind, but I could not identify in the Resource Specification model a natural mechanism to do it.

I believe this need is also relevant to Service Specifications and Product Specifications, so might have already been considered and addressed by members of this community.

Any ideas and feedback will be much appreciated.

Sincerely,

Hi Abel,

Thank you for the discussion. It is very helpful.

I am curious, how do you represent and store the link between a specification and a template? Is it evident in the specification which template it uses?

Best regards,

Hi Yaron,

Extending an API does not necessarily imply that it is no longer compliant. In fact, we have extended ours and all of them are compliant and certified. To be compliant you just need to manage some entities, which should have some attributes, operations, etc. Adding and managing a new entity does not prevent you from continuing to be compliant.
About your note, you are right, and I think that this is a valid approach to implementing specification templates. We decided to use separated templates because in our case this entity is shared by the three catalogs (product, service, and resource). 

There are many options. Depending on your specific needs, some will fit you better than others.

Best regards,

Hi Abel,

Thank you.

Indeed, my initial thought was also of templates. However, I did not see how to do it in a way that is compliant to the TMF634 API. Have you found a way to make it compliant?

One note - the use of a new type AbstractResourceSpecification is not full polymorphism, but rather mostly to distinguish between the two types. They are both stored in the same DB table, with the same structure, and no new JSON schema is necessary.

Best regards,

Hi Opher,

As a simpler alternative to using polymorphism and the composite pattern, in alvatross we decided to extend the catalog with characteristic templates so that you can manage these entities independently and reuse them in all catalog specifications. Furthermore, in the last versions of the catalog APIs they introduced the concept of feature, which are groups of characteristics. I think it would be interesting, in terms of reusability, to manage feature templates as well.

Hope it helps,

Hello Matthieu,

Thank you.

The challenge I have with the approach you propose is that when instantiating a CompositeResource, I would need to also instantiate additional Resources - one for each ProductSpecification that is grouped under the CompositeResourceSpecification. Is that correct? This is something I would really like to avoid.

Also, when looking in "GB922 - Resource" I find the following note:

So it's back to ResourceSpecificationRelationship...

Best regards,

another approach is to group specifications (CompositeProductSpecification). You can also group characteristics (ProductSpecCharRelationship) to create a composite although I have a little doubt about characteristics because xxxxRelationship in the information framework is normally used to create dependencies between characteristics.

at least, that 's one recommended approach described in GB922 - Product. I suspect the same exist for service and resource since they use the same entitySpec pattern.

Hello experts,

I am working on modeling parts of our network as Resources and Resource Specifications, and encountered the following need:

There are sets of multiple Resource Specifications that share a sizeable list of common Characteristic Specifications. For example, different models of a product, that have many types of characteristics in common (but also many other characteristics that are unique to each model).

We would strongly prefer to avoid the need to duplicate the list of common Characteristic Specifications in each Resource Specification that needs it. This is where the idea of a Resource Specification Template comes to mind, but I could not identify in the Resource Specification model a natural mechanism to do it.

I believe this need is also relevant to Service Specifications and Product Specifications, so might have already been considered and addressed by members of this community.

Any ideas and feedback will be much appreciated.

Sincerely,

Hi Opher,

When we want to maintain the reference between the specification and the template (sometimes we don't want this, i.e. you just want to copy the template in the specification), we use a characteristicSpecificationRef object, following the same pattern used throughout all the TM Forum APIs,

Best regards,

Hi Abel,

Thank you for the discussion. It is very helpful.

I am curious, how do you represent and store the link between a specification and a template? Is it evident in the specification which template it uses?

Best regards,

Hi Yaron,

Extending an API does not necessarily imply that it is no longer compliant. In fact, we have extended ours and all of them are compliant and certified. To be compliant you just need to manage some entities, which should have some attributes, operations, etc. Adding and managing a new entity does not prevent you from continuing to be compliant.
About your note, you are right, and I think that this is a valid approach to implementing specification templates. We decided to use separated templates because in our case this entity is shared by the three catalogs (product, service, and resource). 

There are many options. Depending on your specific needs, some will fit you better than others.

Best regards,

Hi Abel,

Thank you.

Indeed, my initial thought was also of templates. However, I did not see how to do it in a way that is compliant to the TMF634 API. Have you found a way to make it compliant?

One note - the use of a new type AbstractResourceSpecification is not full polymorphism, but rather mostly to distinguish between the two types. They are both stored in the same DB table, with the same structure, and no new JSON schema is necessary.

Best regards,

Hi Opher,

As a simpler alternative to using polymorphism and the composite pattern, in alvatross we decided to extend the catalog with characteristic templates so that you can manage these entities independently and reuse them in all catalog specifications. Furthermore, in the last versions of the catalog APIs they introduced the concept of feature, which are groups of characteristics. I think it would be interesting, in terms of reusability, to manage feature templates as well.

Hope it helps,

Hello Matthieu,

Thank you.

The challenge I have with the approach you propose is that when instantiating a CompositeResource, I would need to also instantiate additional Resources - one for each ProductSpecification that is grouped under the CompositeResourceSpecification. Is that correct? This is something I would really like to avoid.

Also, when looking in "GB922 - Resource" I find the following note:

So it's back to ResourceSpecificationRelationship...

Best regards,

another approach is to group specifications (CompositeProductSpecification). You can also group characteristics (ProductSpecCharRelationship) to create a composite although I have a little doubt about characteristics because xxxxRelationship in the information framework is normally used to create dependencies between characteristics.

at least, that 's one recommended approach described in GB922 - Product. I suspect the same exist for service and resource since they use the same entitySpec pattern.

Hello experts,

I am working on modeling parts of our network as Resources and Resource Specifications, and encountered the following need:

There are sets of multiple Resource Specifications that share a sizeable list of common Characteristic Specifications. For example, different models of a product, that have many types of characteristics in common (but also many other characteristics that are unique to each model).

We would strongly prefer to avoid the need to duplicate the list of common Characteristic Specifications in each Resource Specification that needs it. This is where the idea of a Resource Specification Template comes to mind, but I could not identify in the Resource Specification model a natural mechanism to do it.

I believe this need is also relevant to Service Specifications and Product Specifications, so might have already been considered and addressed by members of this community.

Any ideas and feedback will be much appreciated.

Sincerely,