Re: [TF-PP] Property sets in paths

On Wed, 2010-02-03 at 09:55 +0000, Andy Seaborne wrote:
> 
> On 01/02/2010 9:09 AM, Andy Seaborne wrote:
> > Summary:
> >
> > 1/ Use of ! ex:property meaning anything but that property.
> 
> This is like inverted character classes in string regex's --
> [^abc] meaning anything but "a", "b" or "c".  In property paths, IRIs 
> are pattern atoms and the equivalent of characters.
> 
> 
> ---------
> Proposal:
> 
> Add the capability
> 
>    !:property
> 
>    !(:property1|:property2)
> 
> In particular, the "!" operator only applies to a property or a list of 
> properties, and does not apply to a general path expression (in the same 
> way that [^..] only applies to characters).

I can cut&paste two paragraphs from my mail to Douglas Reid:

-----8<-----
It extends the syntax very accurately and looks very similar to, say,
[^A-Z] in regex but for me it would trigger cascading changes in the
optimizer. I did not expect that, absolutely, I've started writing my
first mail intending to vote for this additional operator, but halted at
the middle. OWA is optimizer-unfriendly. If the list of possible
characters is known in advance then [^A-Z] means just a shorthand for
[\x00-\x40\x5D-\xFF]. If predicate set is potentially infinite, !
rdf:type is not a shorthand for a path, it's a shorthand for a subquery
that may in turn be placed into a transitive subquery or cloned into
multiple branches of a union...

Other vendors may have totally different opinions, backed by different
implementation cost estimates for different architectures. So I will not
agitate against these feature, I will only silently vote "-1" in SPARQL
1.1 and probably vote "0" if returned to it in SPARQL 1.2 (because I'm
implementing my macro defs before SPARQL 1.2 and this would become as
cheap as simple syntax sugar).
-----8<-----


> Discussion point:
> The one that I though of is anything starting with a particular 
> namespace IRI - e.g. all foaf: IRIs.
> 
> Maybe a compact form like:
>    foaf:%
> or verbose form like:
>    prefix(foaf:)
>    iriPrefix(foaf:)

For me, this does not add any significant cost if the above mentioned
negation is supported already. But I'd prefer a verbose form, and I'd
prefer to have the verbose form more distinguishable from syntax of
single plain triple. The triple pattern
?s prefix(foaf:) ?o
is, say, only one character away from
?s :prefix (foaf:) ...
i.e. prefix as predicate name and (foaf:) as a list with a single
element. Occupying a new character, like foaf:%, is distinguishable
enough but that's too much for too little feature. (There was one error
in the past --- using (...) for lists, do not want the second one.)

> > and a follow-on from that, not mentioneded by Doug, would be "any"
> > property (but not bound to a variable).

"any" is absolutely cheap so I vote +1.

Best Regards,

Ivan Mikhailov
OpenLink Software
http://virtuoso.openlinksw.com

Received on Thursday, 4 February 2010 10:53:05 UTC