[RESOLVED] Re: Awkward TriG compatibility with N3


Thanks for your comments.  One or two responses inline.

Sandro Hawke wrote (quoting me):

>> If fixing this is considered desirable, requiring a '.' 
>> after the closing '}' of the native (i.e. non-SPARQL) 
>> syntax would do this.  [...]
> I don't think this will work because old-style TriG 
> parsers don't expect that period, and (more importantly) 
> and old-style TriG content doesn't include it. I haven't 
> actually researched this, but I note that the example in 
> the original TriG spec [1] does not include a period.  So 
> if we require the period, old content wont be parsable by 
> new parsers.

That would be far worse than a near-incompatibilty than with 
N3, so, yes, I agree you're right not to attempt to align 
with N3 in this case.  'RESOLVED' in the subject, as 

> That is, if people start to use the GRAPH keyword and 
> leave off the curly braces around default graph triples, 
> then we'll have a language that can be evolved toward N3.

What is the W3C's view on N3, insofar as it has one?  Is it 
considered an experimental language that never really gained 
much real-world traction?  Because focusing on the SPARQL 
syntax would allow the language to evolve towards the 
semantics of N3, but not the syntax of it.

> Note also that the semantics of N3 are radically different 
> from the semantics of TriG.  In N3 (without variables), a 
> {...} expression is an RDF term that denotes a graph.  In 
> contrast, in TriG, {...} expressions never occur in RDF, 
> but instead signal a name-graph pairing that accompanies 
> the default graph in a dataset.

Any they not just two ways of looking at the same thing?  A 
name-graph pairing followed by a statement about that name, 
isn't fundamentally any different to an anonymous formulae 
which is used in a statement.  But probably this is not the 
place for such a discussion.


Received on Wednesday, 20 November 2013 17:54:51 UTC