Nick, I think we are just talking about an extension in our implementation of the query syntax.
Arthur, thanks for volunteering to review. We'll update the grammar to describe what we are doing, including precedence. Joe ================================================ Joe Ross/Austin/IBM, [email protected] Tivoli Autonomic Computing & Component Technologies 512-286-8311, T/L 363-8311 From: Nick Crossley/Irvine/IBM To: Joe Ross/Austin/IBM@IBMUS, Arthur Ryman <[email protected]>, Cc: [email protected] Date: 07/17/2012 12:57 PM Subject: Re: [oslc-core] missing oslc query functionality Just to be quite clear, are you still talking about a provider or domain specific extension to the query language? I think the bar for extending the query language required by OSLC Core should be very high. Nick. From: Joe Ross/Austin/IBM@IBMUS To: Arthur Ryman <[email protected]>, Cc: [email protected] Date: 07/17/2012 10:36 AM Subject: Re: [oslc-core] missing oslc query functionality Sent by: [email protected] Well a unary "not" operator has more general applicability than a binary "never" operator. For example, someone could say oslc.where=not :topping in [:bacon,:cheese] or oslc.where=not :num < 5 note that this is not the same as oslc.where=:num >= 5 if num is multivalued If we are extending the syntax, seems that adding "not" will be more useful. ================================================ Joe Ross/Austin/IBM, [email protected] Tivoli Autonomic Computing & Component Technologies 512-286-8311, T/L 363-8311 From: Arthur Ryman/Toronto/IBM@IBMCA To: Joe Ross/Austin/IBM@IBMUS, Cc: [email protected] Date: 07/17/2012 12:20 PM Subject: Re: [oslc-core] missing oslc query functionality Joe, How about using "never" instead of "not", like so? oslc.where=:topping never :bacon Using "never" suggests we are looking at all the property values. 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/Austin/IBM@IBMUS To: Arthur Ryman/Toronto/IBM@IBMCA Cc: [email protected] Date: 07/17/2012 11:02 AM Subject: Re: [oslc-core] missing oslc query functionality Yes, that is the answer I would want. However, != operator would not give me that, since all three pizzas have a topping that is not bacon. So, I think we would need the following: oslc.where=not :topping=:bacon this would return all resources except those that have bacon (pizza-1 and pizza-2, but not pizza-3). Joe ================================================ Joe Ross/Austin/IBM, [email protected] Tivoli Autonomic Computing & Component Technologies 512-286-8311, T/L 363-8311 From: Arthur Ryman/Toronto/IBM@IBMCA To: Joe Ross/Austin/IBM@IBMUS, Cc: [email protected] Date: 07/17/2012 09:30 AM Subject: Re: [oslc-core] missing oslc query functionality Joe, Just so I understand, for #1 you only want to return resources in which the specified property value never appears? Suppose we have the following member resources: :pizza-1 :topping :pepperoni , :olives, :mushrooms . :pizza-2 :topping :cheese, :olives, :onion . :pizza-3 :topping :bacon, :cheese, :mushrooms. Then the query oslc.where=:topping!=:bacon would return :pizza-1, :pizza-2. 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/Austin/IBM@IBMUS To: Arthur Ryman <[email protected]> Cc: [email protected] Date: 07/13/2012 10:30 AM Subject: Re: [oslc-core] missing oslc query functionality 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, [email protected] Tivoli Autonomic Computing & Component Technologies 512-286-8311, T/L 363-8311 Arthur Ryman <[email protected]> wrote on 07/13/2012 09:11:06 AM: > From: Arthur Ryman <[email protected]> > To: Joe Ross/Austin/IBM@IBMUS, > Cc: [email protected], [email protected] > 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 <[email protected]> > To: > [email protected] > Date: > 07/12/2012 06:39 PM > Subject: > [oslc-core] missing oslc query functionality > Sent by: > [email protected] > > > > 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, [email protected] > Tivoli Autonomic Computing & Component Technologies > 512-286-8311, T/L 363-8311_______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net > > > _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
