OSLC Link Discovery Management - how to describe the data-scope being indexed

[MartinUlrich]

The LDM shall allow the client to understand which data-scope is currently indexed by LDM.

Solution Proposal:

• LDM shall support Discovery
• Via the resource ServiceProviderCatalog -> Property oslc:serviceProviderCatalog [0..*] the contributing source-systems shall be provided. (Semantics of this attribute: Additional service provider catalog LDPCs used to organize services.)

Note:

• Provisioning of further Discovery Information on the level of oslc:ServiceProviders is not foreseen. No added value for LDM.

[MartinUlrich]

This proposal might not be detailed enough, as in a multi-LDM environment we should be flexible to define the scope on Service Provider level rather than Server-level.
Still a LDM Server could not automatically tell from which Service Providers links have been replicated (as e.g. replication via TRS would not deliver Service Provider information).
Therefore it must be assumed, that data sources must be maintained manually by LDM Server admins.
According to the solution proposal the data sources are defined by their servers (serviceProviderCatalog). That seems to be a good balance between the information need and the practical constraints.
In addition if we want to be more detailed regarding the data sources, the shape of the serviceProviderCatalog would need to be enhanced by an new property: contributingServiceProvider (Range oslc:ServiceProvider; zero-or-many)

[DavidJohnHoney]

An oslc:ServiceProvider can have an oslc:details property. The semantics of this is vague. A convention used in IBM Rational ELM for project area specific service provides is for oslc:details to be the URI of the project area. Given the vagueness, it would be in the spirit of OSLC Core to use this for the URI of a tracked resource set where the service provider represented data from such a TRS.