Re: Lee's feature proposal

Seaborne, Andy wrote:
>> [edit] Negation
>> 
>> Question: For those arguing strongly for it? Would you be fine with
>>  seeing this as part of surface syntax?
> 
> What is the proposal here?
 >
>> Rationale: I think it is easy enough to specify, but strictly
>> speaking, a redundant feature.
> 
> I would like to see the specification to understand that.
> 
> Try testing for the absence of <s> <p> <o> using OPTIONAL/!BOUND,
> which relies on a free variable so it has to be introduced and then
> removed.  (That one is easier with a pattern and a filter of != 's.)
> So if there is a translation, it is non-trivial.

It is known well enough, but I agree that it is not nice.

> It can't just be a sub-ASK-query because you want the negation of the
> answer unless the ASK is in a FILTER - which is effectively just
> moving the negation work into the subQuery feature as discussed and
> then we have to consider the interaction of BGP and filters. It does
> not make it easier, it's just been moved around.

I think the ASK subquery in FILTER solution is more intuitive than the
OPTIONAL/!BOUND or OPTIONAL/boundchecker.ttl
  I personally would be perfectly fine with moving it there.
Now my question should rather be: If we had ASK subqueries in FILTERs, 
would we still need some extra surface syntax UNSAID or isn't FILTER( 
!ASK ) sufficient alone?

>> [edit] FullText
>> 
>> Question: Is a surface syntax for regular expression sufficient, or
>> at least could we reach consensus on treating only that?
> 
> It is not surface syntax for a regex.

Not all of it, I agree. I was rather asking whether it would be 
consensual to only treat the part of it, that is.

>> [edit] SurfaceSyntax
>> 
>> Question1: What would this involve?
>> 
>> Question2: How should we prioritize subfeatures?
>> 
> 
> Surface syntax is in danger of becoming a magic dumping ground!

Indeed, in order to avoid that, I am trying to identify concrete parts 
of the currently discussed features that could be subsumed here.
I think before we agree about the feature "surface syntax" we should 
have these "sub-features" clearly identified and prioritised, that is 
where I am trying to get.

At the moment I think we have the following candidates, seen from the 
discussions and from the feature description:

  - Surface syntax for Negation (translated into subqueries)
  - Surface syntax for LimitPerReseource (translated into subqueries)
  - Surface syntax for ProjectExpressions (translated into assignments)
  - Surface Syntax for disjunctions in FILTERs (IN ( ... ), BETWEEN  )
  - Surface Syntax for paths (operators for concatentation "/", reverse
    path "^" and alternation "|")
  - Surface Syntax for expression lists (commas in SELECT ?a, ?b, ?c)

If we opt for Surface syntax we should agree on whether and which of 
these we want. Are there more candidates I forgot here?


-- 
Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland,
Galway
email: axel.polleres@deri.org  url: http://www.polleres.net/

Received on Tuesday, 5 May 2009 13:23:46 UTC