RE: adding inline graphs to TriG

+1

----------- Original Message ---------
From: Sandro Hawke [mailto:sandro@w3.org] 
Sent: Wednesday, July 17, 2013 2:54 AM
To: W3C RDF WG
Subject: adding inline graphs to TriG

I know this is going to seem to some people like it's going too far, but it
seems to me like such a good idea, in good conscience I have to at least
seriously propose it.    If there aren't at least three +1's for this email,
I wont mention it again.

Right now, in TriG, you can say things like:
[ a :Patch;
  :deletes _:g1;
  :inserts _:g2 ].
GRAPH _:g1 { ... }
GRAPH _:g2 { ... }
I think it would make a whole lot of sense to allow a little syntactic
sugar.  I'd like to allow this:
[ a :Patch;
   :delete { ... };
   :inserts { ... } ].
The mechanism for this would be exactly like the mechanism for
square-bracket [ ... ] expressions.  Just like [ ... ] is syntactic sugar
for a blank node that is "used" once, inline graphs would be syntactic sugar
for a named graph that is "used" once.    Any TriG document with inline
graphs could be re-written to not have inline graphs by just replacing the
inline graph with a new blank node label, then adding to the end of the
document a name-graph pair of that label and that graph.     Nested inline
graphs work fine by this rule, with no special handling.

For example:
:alice :said { :bob :said { :charlie said { :spot a :Dog } } } }
is syntactic sugar for:
:alice :said _:u1.
GRAPH _:u1 { :bob :said _:u2 }
GRAPH _:u2 { :charlie said _:u3 }
GRAPH _:u3 { :spot a :Dog }
I'm unsure about whether to allow this in the subject position or just the
object position.  It's probably hard to parse in the subject position; I'm
not sure it can be done with an LL(1) grammar.   (Consider that "{s p o} s p
o" is currently valid TriG, distinguishing that from "{s p o} p o" is
tricky.)   I don't think it's hard in just the object position, and most of
my use cases are fine with the object position.  If people like this idea in
general, I'll investigate the grammar more.

People familiar with N3 will note this makes TriG even more like N3.  I'd
say it brings TriG from being 85% of N3 to maybe 95% of N3.  This is
probably a good thing.   (I'm measuring in terms of feature
usage/importance, and excluding features that are really just RDF
vocabulary.)  

So, anyone else think it's worth fully spec'ing this and adding it as a TriG
"Feature At Risk" for last call?   

If not, I can just put it on my wishlist for the next turtle-like dataset
syntax, someday.

      -- Sandro

Received on Wednesday, 17 July 2013 13:21:25 UTC