Re: in...of syntax Re: Turtle Last Call: Request for Review

On Mon, 2012-07-30 at 11:45 +0100, Nathan wrote:
> Ivan Herman wrote:
> > (Sorry for the late reaction, I was on vacations...)
> > 
> > 
> > The ^P formalism and syntax is already part of the SPARQL 1.1 query language, part of the property path features. Ie, if adopted in Turtle, it would not create any compatibility problems with SPARQL 1.1 (which would not be the case with the 'is ... of' syntax).
> > 
> > RDFa has the @rev attribute that is used for the same purpose. In my own practice @rev is not used very often; however, when it is, it is damn useful, that is for sure...
> > 
> > _Personally_, I would be in favour adding ^P to Turtle.
> 
> +1

I have been considering this change, and while I am extremely resistant
to complicating Turtle and making the mapping of the syntax to the model
"fuzzier", some of the arguments for already mentioned are compelling.
For my pet use case of high performance streaming abbreviated
serialization, it will make life more difficult, but I *think* it is not
a show-stopper (I have not yet attempted to implement this).

On the down side:

 * It raises questions about serialization and normalization, which I
suspect in practice will mean it simply disappears whenever the data has
travelled via a model, since this concept is not in the model.  "Deeply"
supporting this concept means augmenting statements stored in the model,
however one could argue that, just as in syntax, this is preferable to
defining every property twice.  Since implementations can simply
eliminate 'inverseness' immediately upon parsing nobody is forced to
deal with these deeper implications.  The only unavoidable deeper
repercussion is that triple order gets wacky when streaming.  If you're
transmitting abbreviated subject-oriented descriptions that need to
remain whole, you either have to augment your model with an inverse
flag, or forbid inverse properties in that context.

* It is certainly ugly and completely non-obvious, but being from SPARQL
no alternative would be considered anyway.  For what it's worth, in my
opinion Tim's original proposal is much clearer.  When
teaching/advocating I would not make mention of this feature at all:
while useful, it is not very elegant and makes the language less clear.

* More fancifully, one might imagine a more powerful general mechanism
to annotate any segment with any triple ordering.  This would make it
possible, for example, to serialize abbreviated PSO in Turtle, which for
some data sets makes a huge difference.  For example:

@PSO .
doap:name <http://drobilla.net/drobilla#me> "David" ;
          <http://plugin.org.uk/swh.xrdf#me> "Steve" ;
          <http://www.w3.org/People/Berners-Lee/card#i> "Tim" .

(or perhaps @order 2 1 3 . to go *really* general and avoid English)

This makes it possible to much more efficiently store certain data sets
(or indices) in Turtle.  I am not seriously proposing this, but it is an
idea that seemed worth mentioning if we're going to tinker with triple
ordering.

Anyway, all that said, unlike the other changes from SPARQL which seem
to automatically make it in without discussion, this one actually has
tangible value for tersely publishing linked data, which is what Turtle
is for.  That it reduces incentive to make inverse properties, and makes
possible certain streaming serialization use cases, are certainly much
stronger arguments than crippling the pname syntax for copy paste
compatibility with a path syntax that doesn't even make sense in Turtle
in the first place.

Accordingly, I support this addition more than I support the other junk
from SPARQL that has already been included.  In particular, since this
is a *useful* adoption of path syntax, which addresses real (i.e. not
superficial) issues, and makes sense when considering Turtle as a
language unto itself, personally I think it is vastly more appropriate
addition than the mangled PN_ rules.

In short, I am not sure I actively support the feature, but the
arguments for are convincing and I would happily implement it, at least
for parsing.

Thank you,

-dr