Joe, Agreed. If you go ahead with this extension, I'd be happy to review your spec, both from a syntax and a semantics viewpoint. I suggest you extend the ANTLT grammar as a way to precisely document the precedence rules. [1]
[1] http://open-services.net/bin/view/Main/MetricsOslcQueryImplementation 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: Joe Ross/Austin/IBM@IBMUS Cc: Arthur Ryman/Toronto/IBM@IBMCA, [email protected] Date: 07/17/2012 02:22 PM Subject: Re: [oslc-core] missing oslc query functionality Whether we call the operator "not" or "never", the precedence would have to be lower than comparison operators, so that never :topping = :bacon is interpreted as never (:topping = :bacon), rather than (never :topping) = :bacon We would also need to define whether precedence of "not" should be higher or lower than precedence of "and". Precedence should be defined to satisfy the most common usage and expectations. Joe ================================================ Joe Ross/Austin/IBM, [email protected] Tivoli Autonomic Computing & Component Technologies 512-286-8311, T/L 363-8311 From: Joe Ross/Austin/IBM To: Arthur Ryman/Toronto/IBM@IBMCA, Cc: [email protected] Date: 07/17/2012 01:08 PM Subject: Re: [oslc-core] missing oslc query functionality we might need parentheses... :-) ================================================ 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 01:05 PM Subject: Re: [oslc-core] missing oslc query functionality Joe, Unary "not" has a well-known meaning, so people might expect "not :topping = :bacon" to be equivalent to ":topping != :bacon". On the other hand, "never" implies quantification over a set of values. How about using "never" as unary: "never :topping = :bacon"? 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 01:34 PM Subject: Re: [oslc-core] missing oslc query functionality 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 > > >
