Steve,

Thx. I agree it could get complex.

Correction: Below, I meant to write "and NOT too difficult to implement."

Regards,
___________________________________________________________________________
                                                                       
 Arthur Ryman, PhD, DE                                                 
                                                                       
 Chief Architect, Project and Portfolio Management                     
                                                                       
 IBM Software, Rational                                                
                                                                       
 Markham, ON, Canada | Office: 905-413-3077, Cell:       Twitter | Facebook |
 416-939-5063                                                         YouTube
                                                                       
                                                                       
                                                                       




|------------>
| From:      |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Steve K Speicher/Raleigh/IBM@IBMUS                                           
                                                                     |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman <[email protected]>                                              
                                                                     |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |[email protected]                                                  
                                                                     |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |03/03/2010 04:14 PM                                                          
                                                                     |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] Adding "or" to the Simple Query Syntax                       
                                                                     |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|





Arthur Ryman wrote on 03/03/2010 04:00:03 PM:

> I'd like to do a little poll on adding the boolean operator "or". It was

> previously omitted so I left it out. However, several people have asked
> why, and have claimed  that it is useful and too difficult to implement.

>
> If people feel strongly that we should include "or", I'll take the TO DO

> of investigating the complexity, i.e. is there a simple translation to
> SPARQL and SQL? This could get complex if we allow arbitrarily nested
> and/or expressions.


I think that if you'd include "or" you'd have to remove the word "simple"
from the spec ;)  This opens up not just the semantic mapping issues, we
now have have to worry about complexities of grouping.  In CM we were able
to accomplish most needed use cases for "or" by introducing "in".

The original thinking CM was that if there was a need for something more
complex then a query service that needed this level of detail, a
POST-based approach may be needed.

So I'd recommend that if we can get away with avoiding "or" in simple, we
do that.  Instead look at a "complex" query service that may take full SQL
or SPARQL syntax, then consumers would just need to discovery which one to
use.

I'll pull the CM workgroup on this to see if there are any scenarios
needed that need this, though I haven't heard any requests to date.

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645

Reply via email to