[oslc-core] Better name for OSLC indexing profile

[Arthur Ryman]

Ben/Frank,

I agree that for simplicity, the lists of resources should not overlap. 
However, it wouldn't be fatal if they did.

There should not be a need to merge graphs when there are overlaps in the 
resources. The index should be organized as a set of named graphs, with 
the resource URI being the name. This organization makes updates easy. 
Queries are run against a special URI that identifies the union of all 
graphs.

The indexer should maintain some metadata about each named graph, 
including its modification date. When the indexer gets a list of URIs, it 
should determine if the resource is already up-to-date and only update it 
if necessary.

Regards, 
___________________________________________________________________________ 

Arthur Ryman, PhD, DE

Chief Architect, Project and Portfolio Management
IBM Software, Rational
Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063





From:
Benjamin Williams <bwilliams at uk.ibm.com>
To:
Frank Budinsky/Toronto/IBM at IBMCA
Cc:
oslc-core <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net
Date:
04/05/2011 09:29 AM
Subject:
Re: [oslc-core] Better name for OSLC indexing profile
Sent by:
oslc-core-bounces at open-services.net



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 





_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net