[oslc-core] missing oslc query functionality

Michael F Fiedler fiedler at us.ibm.com
Fri Jul 13 11:03:48 EDT 2012


Yes, extensions or alternate syntax can be used.   The OSLC Core spec
states it MAY be used by domain specifications.  The important thing would
be documenting it so that consumers know what syntax the query capability
supports.

Regards,
Mike

Michael Fiedler
IBM Rational Software
fiedler at us.ibm.com
919-254-4170

oslc-core-bounces at open-services.net wrote on 07/13/2012 10:30:44 AM:

> Joe Ross/Austin/IBM at IBMUS
> Sent by: oslc-core-bounces at open-services.net
>
> 07/13/2012 10:30 AM
>
> To
>
> Arthur Ryman <ryman at ca.ibm.com>,
>
> cc
>
> oslc-core at open-services.net
>
> 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
> >
> >
> > _______________________________________________
> 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/20120713/302248fa/attachment-0003.html>


More information about the Oslc-Core mailing list