W3C home > Mailing lists > Public > public-rdf-comments@w3.org > November 2013

Re: TriG compatibility with N-Quads

From: Andy Seaborne <andy@apache.org>
Date: Sat, 23 Nov 2013 19:49:02 +0000
Message-ID: <529106AE.1080008@apache.org>
To: Richard Smith <richard@ex-parrot.com>
CC: public-rdf-comments@w3.org

Thank you for your comment regarding aligning TriG with N-Quads.

The group has had lengthy discussions on the syntax for TriG throughout 
the life time of the current working group, which included discussion of 
integrating in N-Quads.  The group has decided not pursue that and this 
is recorded in a negative syntax test for TriG: 

Several members of the working group are interested in future syntax but 
that is not for this round of standardisation in the current working group.

If this addresses your comment, albeit not to accept the proposal,
please reply with the subject prefixed by "[RESOLVED]".

      on behalf of the RDF Working Group

On 20/11/13 18:41, Richard Smith wrote:
> Andy Seaborne wrote:
>> Changing rule [3g] in the way you suggest would create something that
>> is much more than N-Quads because predicateObjectList includes the
>> abbreviation forms for ";", "," and also the [] and () constructs, not
>> just enable 4-tuple N-Quads style lines.
>> :s :p 123 ;
>>   :q "foo" , "bar"  , (7 8 9) ;
>>   :r [ :z 18 ]
>>   :graph .
> Yes, that was what I had in mind.  Is that so confusing? (Well, I would
> have indented it differently to have made the actual meaning more
> apparent.  But I don't think the potential of misleading indentation is
> grounds for rejecting it as an idea.)
> Certainly it would be possible to make a more involved alteration to the
> grammar so that the N-Quads-style graph label is only permitted in
> simple statements of the form ':sub :pred :obj :graph .', and not in any
> more complex case.  But the simpler specification seems to me to win,
> even though it allows more things.
> The main advantage of including N-Quads within TriG seems to me to be
> that it facilities producing TriG with non-TriG-aware tools.  For
> example, I currently have an application that generates TriG using XSLT
> (which doesn't understand TriG and has relatively poor string parsing
> facilities).  The XSLT retrives data from multiple sources, which are in
> a mixture of N-Quads and Turtle.  Were N-Quads a subset of TriG, I could
> just compose them.  As it is, I'm doing some rather naive (and buggy)
> text processing to rewrite the N-Quads as ':graph { :sub :pred :obj }
> .'. Wanting to convert N-Quads to TriG in a language with relatively
> poor text processing facilities doesn't seem an unreasonable desire.
>> There has been discussion of a form of TriG that is :
>> :graph { triple }
>> as a canonical form. This is already legal TriG so applications are
>> free to generate it.
> True, though it doesn't help with the existing body of N-Quads data.
> And the fact that the W3C is about to standardise N-Quads suggests it
> will stay the preferred dump format for some time.
> Richard
Received on Saturday, 23 November 2013 19:49:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:58 UTC