Re: adding inline graphs to TriG

+1
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group




From:   Pat Hayes <phayes@ihmc.us>
To:     Sandro Hawke <sandro@w3.org>, 
Cc:     W3C RDF WG <public-rdf-wg@w3.org>
Date:   07/17/2013 08:36 AM
Subject:        Re: adding inline graphs to TriG



Well, I don't have to write the parsers, but it seeems like a very good 
idea to me. 

Pat

On Jul 16, 2013, at 7:53 PM, Sandro Hawke wrote:

> 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

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973 
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes