[oslc-core] Better name for OSLC indexing profile

[Benjamin Williams]

Thanks Frank

I guess the least efficient of scenarios (that eventually may be end up 
being quite common as we find more interesting applications for the 
indices) is when a service provider creates multiple Query Capabilities 
that include queries for the total set of resources in addition to a 
number of subsets. Still this loss of efficiency through merging graphs 
containing duplicate resources looks like it could be addressed in the 
future via the extension that you and John discussed in a parallel email 
(perhaps by recommending best practice that only one Query Capability (for 
the total set of published resources) have an oslc:usage value of 
http://open-services/ns/core#published, and that any additional Query 
Capabilities for resource subsets have different oslc:usage values)


Regards
 
Benjamin Williams
Rational Reporting Strategy Lead
Senior Product Manager, Rational Reporting
IBM Software, Rational

Phone: 44-118 9793107
E-mail: bwilliams at uk.ibm.com
Find me 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:   Frank Budinsky <frankb at ca.ibm.com>
To:     Benjamin Williams/UK/IBM at IBMGB
Cc:     oslc-core <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net
Date:   04-04-2011 18:03
Subject:        Re: [oslc-core] Better name for OSLC indexing profile



Hi Benjamin,

> A question for my own understanding...if a service provider 
> annotates more than 1 of its Query Capabilities via the oslc:usage 
> parameter, then how does a consumer know which of the (possibly 
> many) Query Capabilities is exposing the "total set of resources"? 

If there is more than 1, then the union of the resources returned by all 
of them is the total set. 

Normally, I would expect multiple Query Capabilities to be used when a 
service provider wants to return different types of resources in separate 
lists. In that case it might have one "published" Query Capability per 
resource type, in which case there would be no overlap between the 
resources in the multiple lists. More generally, however, there could 
conceivably be some overlap between the resources returned by multiple 
"published" Query Capabilities. My feeling is that, although this isn't 
the most efficient way to do it (so we should recommend no overlap), but 
it shouldn't be disallowed since it may be the easiest way for a service 
provider to implement the "Resource Publishing" capability by reusing 
other existing Query Capabilities.

Frank.






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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110405/65607c1b/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 488 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110405/65607c1b/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110405/65607c1b/attachment.gif>