Re: evaluating SPARQL w.r.t an RDF query language survey

Dan Connolly wrote:
> On Wed, 2005-04-06 at 22:13 +0200, wrote:
>> picking out just one case.. (have tested 11 cases a while back)
>>> 10 Namespace
>>> Return all resources whose namespace starts with
>>> "".
>>> seems to have a typo in the question...
>>> missing www.
>>> select ?R where
>>>  { ?R ?x ?y.
>>>    FILTER regex(str(?R), "")
>>> }
>> why not simply
>> WHERE {?R a rdfs:Class;
>>           log:uri ?S.
>>        ?S str:matches "http://www\.aifb\.uni-karlsruhe\.de/.*"}
> That basically involves changing the way DataSets and background
> graphs work so that they always include "axiomatic" triples
> such as
>   <> log:uri
> "".
> and
>   "a" str:matches "a".
> That was not a popular design when it was discussed in Helsinki
> under issue useMentionOp
>  <-
> Let's see... no, you weren't there for that one. You might
> want to look over the record of that item and see if the
> rationale/discussion there satisfies you. (I think I meant
> to abstain but was too busy chairing to get my abstention
> recorded.)

OK, I read record and would certainly have liked the discussion
(but had other f2f's at that time) and all I can really add
is that we use that design of "treating mathematical inferences
like RDFS and other inferences" since 5 years it really works.

> If not, you can ask to re-open the issue.

An implementation can convert pieces of WHERE triple patterns
into certain internal (FILTER) expressions and they could
behave much like traditional programming language expressions
and I think it is best to keep that for the implementation
instead of prescibing it (just being delarative is fine).
Also given the position below, I would ask to re-open and
drop FILTER.

>> or some such (I don't have enough regex experience)
>> I'm even more convinced after reading
>> [[
>> Built-in Functions and operators: Use RDF Properties
>> ... All this speaks against built-in functions being
>> brought out as special syntax, and supports the use of
>> RDF properties for them.
>> ]]
> That's new information since the Helsinki meeting, I suppose.

very much indeed and since

> Another thing that's sorta new information is that triple
> patterns can have literal subjects.
> I'm not yet convinced the issue should be re-opened, but
> everything is negotiable.
>> The point is also about that separate FILTER, I'm not
>> convinced at all and basically a query is already a
>> filter rule
>> {where-triple-pattern} => {construct-or-select-triple-pattern}
>> I just don't see the benefit of having FILTER in filter..
> FILTER expressions behave much more like traditional programming
> language expressions. While there are some "unknown" cases in
> the corners, most expressions are closed over negation, unlike
> triple patterns.
> Oops... I slipped into arguing... I really shouldn't do much
> of that for issues that are closed.


> -- 
> Dan Connolly, W3C
> D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Jos De Roo, AGFA

Received on Wednesday, 6 April 2005 23:30:42 UTC