Open APIs

For some Products, it is necessary to be linked to a Place (Address, Building, Room, ...), e.g. a fixed line access, for others like e.g. a mobile phone this os not needed. Similarly, for some Products we need to link information on a person playing a specific role in context of the Product, e.g. a Technician being an Employee of the business Customer that ordered the Product; for other Products, this is not needed, or some other role is needed.

So it should be possible to model in the ProductCatalog (and probably also in Resource Catalog etc) that for the Products instantiated from a ProductSpecification or ProductOffering, a Place and/or a Party(Role) might be needed.

A nearby solution would be to add an attribute "needsPlace" to the PS and/or PO, and also to have PartyRoleSpecifications linked to the PS and/or PO.

Does that make sense? Or is there already some other means to express what is needed?

Hello Lutz,

Don't we have it already in TMF 637 (Place and RelatedParty)?

For some Products, it is necessary to be linked to a Place (Address, Building, Room, ...), e.g. a fixed line access, for others like e.g. a mobile phone this os not needed. Similarly, for some Products we need to link information on a person playing a specific role in context of the Product, e.g. a Technician being an Employee of the business Customer that ordered the Product; for other Products, this is not needed, or some other role is needed.

So it should be possible to model in the ProductCatalog (and probably also in Resource Catalog etc) that for the Products instantiated from a ProductSpecification or ProductOffering, a Place and/or a Party(Role) might be needed.

A nearby solution would be to add an attribute "needsPlace" to the PS and/or PO, and also to have PartyRoleSpecifications linked to the PS and/or PO.

Does that make sense? Or is there already some other means to express what is needed?

Hi Igor

It's certainly true that you have these properties in the Product inventory (TMF637). But Lutz' concern is - how do you know that at ordering time you need to populate these properties. The Spec/Instance pattern with characteristics works very well for the dynamic aspects of the model. But it does not help for concrete properties, so Lutz is looking for some metadata at specification level which will instruct the software to verify that (say) an installation address is supplied at ordering time.

It's worthwhile considering as a potential enhancement in future versions of TMF620. It's not simple, since there are multiple address roles (installation, shipping, primary place of use), and similarly multiple party roles. Somehow we'd need to leave instructions for each role as to which needs to be populated.

Hello Lutz,

Don't we have it already in TMF 637 (Place and RelatedParty)?

For some Products, it is necessary to be linked to a Place (Address, Building, Room, ...), e.g. a fixed line access, for others like e.g. a mobile phone this os not needed. Similarly, for some Products we need to link information on a person playing a specific role in context of the Product, e.g. a Technician being an Employee of the business Customer that ordered the Product; for other Products, this is not needed, or some other role is needed.

So it should be possible to model in the ProductCatalog (and probably also in Resource Catalog etc) that for the Products instantiated from a ProductSpecification or ProductOffering, a Place and/or a Party(Role) might be needed.

A nearby solution would be to add an attribute "needsPlace" to the PS and/or PO, and also to have PartyRoleSpecifications linked to the PS and/or PO.

Does that make sense? Or is there already some other means to express what is needed?

Hi Jonathan,

but TMF 620 contains PlaceRef (*...0), can it be used? I think today we use polices to assign proper address types.

For multiple Party (or PartyRole) - agree.

Hi Igor

It's certainly true that you have these properties in the Product inventory (TMF637). But Lutz' concern is - how do you know that at ordering time you need to populate these properties. The Spec/Instance pattern with characteristics works very well for the dynamic aspects of the model. But it does not help for concrete properties, so Lutz is looking for some metadata at specification level which will instruct the software to verify that (say) an installation address is supplied at ordering time.

It's worthwhile considering as a potential enhancement in future versions of TMF620. It's not simple, since there are multiple address roles (installation, shipping, primary place of use), and similarly multiple party roles. Somehow we'd need to leave instructions for each role as to which needs to be populated.

Hello Lutz,

Don't we have it already in TMF 637 (Place and RelatedParty)?

For some Products, it is necessary to be linked to a Place (Address, Building, Room, ...), e.g. a fixed line access, for others like e.g. a mobile phone this os not needed. Similarly, for some Products we need to link information on a person playing a specific role in context of the Product, e.g. a Technician being an Employee of the business Customer that ordered the Product; for other Products, this is not needed, or some other role is needed.

So it should be possible to model in the ProductCatalog (and probably also in Resource Catalog etc) that for the Products instantiated from a ProductSpecification or ProductOffering, a Place and/or a Party(Role) might be needed.

A nearby solution would be to add an attribute "needsPlace" to the PS and/or PO, and also to have PartyRoleSpecifications linked to the PS and/or PO.

Does that make sense? Or is there already some other means to express what is needed?