[oslc-core] missing oslc query functionality

[Joe Ross]

Thanks, Arthur. So, it sounds like these were intentional simplifications, 
and we could implement our own extensions or SPARQL if we want.

> 1. Correct. What semantics do you want for multi-value properties? Are 
you 
> looking for the existence of one value that does not equal the given 
> value? 
In this particular case we are looking for resources that don't have a 
particular value for a multi-valued property. If we were simply looking 
for the existence of a value that doesn't equal the give value, I think != 
would handle that.

> 2. Correct. However, you could approximate this effect by comparing the 
> property to a value that you are sure does not exist. e.g. if 
ex:estimate 
> is always non-negative, then ex:estimate > -1 would return resource that 

> had any value for ex:estimate.

That is actually how we are doing it now . Using != with a value we know 
won't ever exist.

Joe

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311

Arthur Ryman <ryman at ca.ibm.com> wrote on 07/13/2012 09:11:06 AM:

> From: Arthur Ryman <ryman at ca.ibm.com>
> To: Joe Ross/Austin/IBM at IBMUS, 
> Cc: oslc-core at open-services.net, oslc-core-bounces at open-services.net
> Date: 07/13/2012 09:11 AM
> Subject: Re: [oslc-core] missing oslc query functionality
> 
> Joe,
> 
> The query language was scoped to be simple to implement. It is not 
> intended to be a fully general query language. For more complex 
> requirements, services can implement a standard query language. SPARQL 
is 
> recommended.
> 
> 1. Correct. What semantics do you want for multi-value properties? Are 
you 
> looking for the existence of one value that does not equal the given 
> value?
> 
> 2. Correct. However, you could approximate this effect by comparing the 
> property to a value that you are sure does not exist. e.g. if 
ex:estimate 
> is always non-negative, then ex:estimate > -1 would return resource that 

> had any value for ex:estimate.
> 
> Regards, 
> 
___________________________________________________________________________ 

> 
> Arthur Ryman 
> 
> DE, Chief Architect, Reporting &
> Portfolio Strategy and Management
> IBM Software, Rational 
> 
> Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 
> 
> 
> 
> 
> 
> From:
> Joe Ross <joeross at us.ibm.com>
> To:
> oslc-core at open-services.net
> Date:
> 07/12/2012 06:39 PM
> Subject:
> [oslc-core] missing oslc query functionality
> Sent by:
> oslc-core-bounces at open-services.net
> 
> 
> 
> We've had a couple of scenarios that don't seem to be addressable using 
> the OSLC core 2.0 query syntax: 
> 
> 1. Finding all resources that don't have a particular value for a 
> property. 
> The != operator won't work for this, because in the case of multi-valued 

> properties, records will be returned as long as there is a value that is 

> not equal, even if there is also a value that is equal. This would 
require 
> a unary "not" logical operator. 
> 
> 2. Finding all resources that have any value for a particular property 
> (matching on predicate, regardless of value). 
> This is probably would probably be best handled by a unary "exists" 
> operator, or support for wildcard as the value in oslc.where clauses. 
> Currently the grammar seems to only allow for wildcard for the 
predicate. 
> 
> So, am I correct in this assessment? If so, was this omission 
intentional 
> (and if so what was the reason), or an oversight? 
> 
> ================================================
> Joe Ross/Austin/IBM, joeross at us.ibm.com
> Tivoli Autonomic Computing & Component Technologies
> 512-286-8311, T/L 
363-8311_______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120713/a1c2a145/attachment-0003.html>