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: [email protected] 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 <[email protected]> To: Benjamin Williams/UK/IBM@IBMGB Cc: oslc-core <[email protected]>, [email protected] 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
