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
