Open MartinUlrich opened 10 months ago
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)
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.
The LDM shall allow the client to understand which data-scope is currently indexed by LDM.
Solution Proposal:
oslc:serviceProviderCatalog
[0..*] the contributing source-systems shall be provided. (Semantics of this attribute: Additional service provider catalog LDPCs used to organize services.)Note:
oslc:ServiceProviders
is not foreseen. No added value for LDM.