oslc:serviceProvider from non-OSLC resources (was: Summary of Discovery Issues)

[Martin P Pain <martinpain@uk.ibm.com>]

Nick, that approach does seem to make sense.

However, there are some disadvantages
to it too:

• The other resource has to be RDF (the odlc:details link in the other direction could point to a resource that only has a 'plain old XML' representation, depending on how we defined it in the spec/vocab).
• It means modifying the non-OSLC resource, rather than the OSLC resource, when this modification is based on the OSLC spec.

But I don't see either of them as major
problems. It does make sense for the link to go from the one you have the
URI for to the one you don't. Especially as clients without vendor-specific
knowledge can't do anything with the vendor-specific resource so there's
no need for them to discover it from the ServiceProvider.

Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel

E-mail: martinpain@uk.ibm.com Find me on:  and within IBM on:

IBM United Kingdom Limited Registered in
England and Wales with number 741598 Registered office: PO Box 41, North
Harbour, Portsmouth, Hants. PO6 3AU 



From:      
 Nick Crossley <ncrossley@us.ibm.com>
To:      
 Jim Amsden <jamsden@us.ibm.com>
Cc:      
 "OASIS OSLC Core
TC Discussion List" <oslc-core@lists.oasis-open.org>
Date:      
 24/08/2015 18:17
Subject:    
   Re: [oslc-core]
Summary of Discovery Issues
Sent by:    
   <oslc-core@lists.oasis-open.org>

---

In Jim's issue 2, 2. Given a resource,
how would a client discover information about capabilities on that resource?,
Jim stated: "The problem is that if a user has a link to a resource
(e.g., an RTC Project Area) that has OSLC capabilities, there's no way
to navigate from that resource to the Service Provider that describes those
capabilities. For example, if a user had a URL for JKE Banking (Change
Management) Project Area, there is no easy way to find the Service Provider
resource that would provide the URL for the query capability for that project
area."

For resources that are OSLC resources (such as requirement
collections or change requests), as opposed to resources that represent
something that has OSLC capabilities but are not themselves OSLC resources
(such as Jazz project areas), the oslc:serviceProvider
property provides exactly the desired navigation. So, one way to address
this specific issue is to suggest that servers with resources that represent
something that has OSLC capabilities but are not themselves OSLC resources,
they nonetheless add an oslc:serviceProvider
property.  This is the inverse of the other approach described - to
allow oslc:details
to point from the service provider to this non-OSLC resource.

Nick.

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU