- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Tue, 19 Aug 2014 09:58:28 -0700
- To: Ruben Verborgh <ruben.verborgh@ugent.be>
- Cc: Markus Lanthaler <markus.lanthaler@gmx.net>, public-hydra@w3.org
On Aug 19, 2014, at 3:42 AM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote: > Hi Markus, > >> No, but you were actively involved in these discussions and provided a lot >> of very valuable thoughts. So I want to make sure to get your feedback >> before sending out another call for consensus. > > Shout out to you for doing a great job listening to everybody here! > >> Yeah, that's true. That's also what worries me about this approach but >> apparently that's what the majority of the group wants. So my idea was to >> explicitly mention that it is *simplified* Turtle (and thus not standard >> Turtle) and explicitly call out the differences to the Turtle spec. > > The strange thing about "simplified Turtle" is that > it is *incompatible* with “full Turtle”, which is unexpected. > Sure, “simplified Turtle” parsers would not be able to parse “full Turtle”, > but the other way around is non-intuitive. The name is therefore inappropriate. +1. The only "Simplified" Turtle I'm aware of is the variety used in Freebase dumps, which has a very constrained format. My thought is that we should be using specific constructs from Turtle, where it makes sense (i.e., literal encodings). > The proper term would actually be > “non-escaped N-Triples literal syntax with bracketless IRIs” Yes, but I wonder what the advantage of leaving brackets out for typed literals is; I can see it for non-literal values. As long as we can unambigiously distinguish between IRIs, plain literals, typed literals, and language-tagged literals. It's in the literal encoding that I think Turtle compatibility is most useful. > “The corresponding RDF lexical form is the characters between the delimiters, > <del>after processing any escape sequences</del>. > If present, the language tag is preceded by a '@'. > If there is no language tag, there may be a datatype IRI, preceded by '^^'.” [1] > > I would just maybe non-normatively refer in the spec that the meaning of '@' and '^^' > has been borrowed from Turtle/N-Triples, but call it something else. > > Bear in mind that this could also be very confusing to readers: > “Do my parameters have to be simplified Turtle is my document is JSON-LD?” > >>> - TypedRepresentation (because we distinguish between literals and URIs) >> >> I don't like this as much as I fear people will have a quick look, recognize >> it as Turtle and move on. > > Even worse with “simplified Turtle”. > >> I personally feel better to explicitly acknowledge >> that it is *based* on Turtle but not truly Turtle. Does this makes sense to you? > > Not too much. The only thing it borrows is the meaning of '@' and '^^', > there is no other relationship whatsoever. Use Turtle literal-syntax only (other than the lack of prefix support). Gregg > Best, > > Ruben > > [1] http://www.w3.org/TR/n-triples/
Received on Tuesday, 19 August 2014 16:59:10 UTC