[oslc-core] v1 Service Descriptions vs v2 Services

[Jim des Rivieres]

Doing a side-by-side comparison of the upper-level superstructure of the 
v1 and v2 OSLC CM specs, I noticed two things.

(1) In v1 Service Provider Catalog representation, the 
oslc_disc:ServiceProvider element has an oslc_disc:details with a 
rdf:resource attribute giving "the URI of a browsable resource providing 
details of the service provider or catalog." For RTC, this was the URI of 
a particular project area. 

I couldn't find any counterpart to this in the v2 CM or Core specs. Was 
this an intentional omission? I.e., do we believe that it's no longer 
needed?

(2) In a v1 Service Provider Catalog, the catalog entries reference v1 
Service Provider resources as local, inline resources; these v1 Service 
Provider resources reference v1 Service Description resources as regular 
resources. In v1, a particular Service Description resource is associated 
with a particular domain. E.g., it will be a CM Service Description 
resource.

In a v2 Service Provider Catalog, the catalog entries reference v2 Service 
Provider resources as regular resources; these v2 Service Provider 
resources reference v2 Service resources as local, inline resources. In 
v2, a particular Service resource is associated with a particular domain. 
A v2 Service Provider resource is designed to reference multiple and 
heterogenous v2 Services.

Selecting from a v1 Service Provider Catalog yields the URI of a v1 
Service Description resource. The analogous selection from a v2 Service 
Provider Catalog would yield the URI of a v2 Service resource. However, 
since v2 Service resources are inlined into the v2 Service Provider 
document, the only available URIs for these are ones with fragment '#' 
identifiers that select a node based on its rdf:nodeID.

Two issues I can see with this:

(a) It means that all clients that dereference v2 Service resources are 
responsible for interpreting the fragment identifier and using it to 
locate the element with that rdf:nodeID. This is clunky for clients of the 
v2 protocol.

(b) It's impossible to claim that the URI of a v1 Service Description 
resource is also the URI of a v2 Service resource - the latter has a 
fragment identifier; the former does not. A cross-application "project 
links" that starts off referencing a v1 CM Service Description resource 
would end up referencing a v2 Service Provider resource, rather than a v2 
Service resource, once the target server is upgraded to add support for CM 
v2 under the existing CM v1 URIs.

---jim