[oslc-core] missing oslc query functionality
Joe Ross
joeross at us.ibm.com
Tue Jul 17 14:22:04 EDT 2012
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, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311
From: Joe Ross/Austin/IBM
To: Arthur Ryman/Toronto/IBM at IBMCA,
Cc: oslc-core at open-services.net
Date: 07/17/2012 01:08 PM
Subject: Re: [oslc-core] missing oslc query functionality
we might need parentheses... :-)
================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311
From: Arthur Ryman/Toronto/IBM at IBMCA
To: Joe Ross/Austin/IBM at IBMUS,
Cc: oslc-core at open-services.net
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 at IBMUS
To:
Arthur Ryman/Toronto/IBM at IBMCA
Cc:
oslc-core at open-services.net
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, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311
From: Arthur Ryman/Toronto/IBM at IBMCA
To: Joe Ross/Austin/IBM at IBMUS,
Cc: oslc-core at open-services.net
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 at IBMUS
To:
Arthur Ryman/Toronto/IBM at IBMCA
Cc:
oslc-core at open-services.net
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, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311
From: Arthur Ryman/Toronto/IBM at IBMCA
To: Joe Ross/Austin/IBM at IBMUS,
Cc: oslc-core at open-services.net
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 at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
oslc-core at open-services.net
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, 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/20120717/3337d157/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120717/3337d157/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120717/3337d157/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120717/3337d157/attachment-0002.gif>
More information about the Oslc-Core
mailing list