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 > > >
