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

Members of this thread should be aware of:
  http://lists.w3.org/Archives/Public/public-rdf-comments/2012Aug/0032.html

Regards,
Dave




On Aug 10, 2012, at 10:45, David Robillard <d@drobilla.net> wrote:

> 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

Received on Friday, 10 August 2012 20:52:13 UTC