Dragos, Yes, the first two match the oslc.where clause.
I disagree that the server should report an error. The query is run against the graph of triples known to the service, and the service returns the matches on that graph. The meaning of the result set is scoped to what the service knows. It is certainly possible that the third resource could have oslc:shortTitle="Some defect" in another graph (e.g. obtained by referencing the resource and getting its representation) since any service might have triples about any resource in its graph. That is consistent with the Open World assumption behind Linked Data and RDF. The query result must be understood in the context of the graph you are querying. If your application needs more data then you should run the query on a bigger graph, e.g. one created by an indexer. 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: Dragos Cojocari <[email protected]> To: Arthur Ryman/Toronto/IBM@IBMCA Cc: [email protected], [email protected] Date: 01/12/2011 09:25 AM Subject: Re: [oslc-core] Behavior of oslc.where and oslc.sort if resources are not managed by the service provider Hey Arthur, thanks for the reply. The first two resources both have oslc:shortTitle="Some defect" so I assume both will be included. But what if the 3rd one, the one not managed by the service provider also has oslc:shortTitle="Some defect"? The service provider doesn't know that so it won't include that in the result. In my opinion that is incorrect, since the result set is not full. I think that reporting an error if the service provider cannot verify the filter/sort for all the collection members would be more rigorous. What do you think? Regards, Dragos Arthur Ryman <[email protected]> 12/01/2011 16:18 To Dragos Cojocari/Romania/IBM@IBMRO cc [email protected], [email protected] Subject Re: [oslc-core] Behavior of oslc.where and oslc.sort if resources are not managed by the service provider Dragos, BTW, the query result is just the first resource since it matches oslc:shortTitle="Some defect" 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: Dragos Cojocari <[email protected]> To: [email protected] Date: 01/12/2011 08:12 AM Subject: [oslc-core] Behavior of oslc.where and oslc.sort if resources are not managed by the service provider Sent by: [email protected] Hey everyone, and a Happy new year. I'd like to understand what is the defined behaviour if a query specifies in its where/orderBy clause and the collection of resources contains resources not managed by the service provider and the serviceprovider cannot filter/sort them. What should the provider do: - reject the response with an error - include only the resources for which the filter/sort can be calculated - undefined Example data: So for the data above what is the expected result for the following query: http://<server>:<post>/defects?oslc.select=*&oslc.where=oslc:shortTitle="Some defect" Regards, Dragos Exceptand situatiile in care partile au convenit in alt mod: / Unless stated otherwise above: IBM România S.R.L. Bucharest Business Park, Corp A2, Şos. Bucureşti-Ploieşti Nr. 1A, 013681 Bucureşti 1, ROMANIA CIF RO378660, RC J/40/5106/1991 Cap.Soc. 41.670 Lei_______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net Exceptand situatiile in care partile au convenit in alt mod: / Unless stated otherwise above: IBM România S.R.L. Bucharest Business Park, Corp A2, Şos. Bucureşti-Ploieşti Nr. 1A, 013681 Bucureşti 1, ROMANIA CIF RO378660, RC J/40/5106/1991 Cap.Soc. 41.670 Lei
