RE: Moving forward with ISSUE-30 (IRI template expansion)

> -----Original Message-----
> From: Ruben Verborgh [mailto:ruben.verborgh@ugent.be]
> Sent: Wednesday, August 20, 2014 9:33 AM
> To: McBennett, Pat
> Cc: Markus Lanthaler; public-hydra@w3.org
> Subject: Re: Moving forward with ISSUE-30 (IRI template expansion)
> 
> Hi Pat,
> 
> > I commented on it - saying +1 for requiring the angle brackets when
> specifying an explicit datatype for a literal, as I also thought that would make
> the syntax more compatible with Turtle.
> 
> But for machines, here is no "more", syntax is either compatible so they can
> parse it, or it's not.
> 
> >> For all IRIs? I don't see the point in that.
> >> It makes things more complicated without adding value.
> >
> > Not as I understand it Ruben, no. This was only applicable for literals (so it
> wasn't intended to address your a) below, only the b)). The angle brackets
> were only to be required for specifying the XSD datatype of a literal, i.e.
> "Markus"^^<http://www.w3.org/2001/XMLSchema#string>.
> 
> Let's look closely at why the angular brackets would need to be there, by
> building this thing from the ground up.
> First of all, is there a parsing necessity why they should be there?
> No, because the IRI is unambiguously located between the ^^ and the end of
> the string.
> Adding angular brackets does not make parsing easier (or much more
> difficult).
> 
> Second, why are the angular brackets there in Turtle?
> The answer is consistency. If we look at the Turtle syntax [1], we see:
> 
>     [128s]	RDFLiteral	::=	String (LANGTAG | '^^' iri)?
> 
> So what this says is: the syntax for a typed literal is "the syntax for a String"
> followed by "the syntax for an iri".
> 
> What is the "syntax for an iri" in Turtle? Relevant case:
> 
>     [18]	IRIREF	::=	'<' ([^#x00-#x20<>"{}|^`\] | UCHAR)* '>'
> 
> So that's why there are angular brackets in Turtle.
> 
> Now what is the "syntax for an IRI" for the template parameters we
> discussed?
> 
>     the IRI itself, without angular brackets
> 
> So we have to be consistent here:
> either we write IRIs without angular brackets, everywhere, or either we write
> them with angular brackets, everywhere.
> But a mixture of both doesn't make sense, given that:
> "syntax for a typed literal" =
> "the syntax for a String" followed by "the syntax for an iri".
> 
> Summarizing: if we decide to use angular brackets, we should be consistent.
> However, we don't have the necessity for angular brackets that Turtle has
> (because it also has prefixed names, without angular brackets).
> 

Yep - I've (slowly!) been coming around to that same conclusion.

> And... the angular brackets alone don't give us Turtle compatibility anyway:
> 
> > So Ruben if we have literals delimited in quotes, and we use '^^' and angle
> brackets around the type, and '@' for languages, *then* would a full-blown
> Turtle parser be able to parse that literal correctly? If so, would
> 'SimplifiedTurtle' now be applicable...?
> 
> No, it would not parse it, because of escaping. Note the difference between
> - Turtle triple: <a> <b> "this literal has a quote \" inside".
> - Hydra parameter:  "this literal has a quote " inside"
> 

Aha - good point.

> Adding escaping would add unnecessary complexity:
> - We would no longer be able to parse the parameter only with a regex.
> - The parameter would be escaped twice: once as Turtle, once as URI
> component.
> 

Agreed.

> And, minor detail, but Turtle parsers only parse triple documents, not literals
> by themselves.
> 

Yeah, I realized that. I was kinda thinking we could allow developers reuse the 'parseLiteral()' method of full-Turtle parsers, but I get your point, probably at bit far-fetched (but they could have just cut-and-pasted that code :) !).

> > +1 (with the addition of angle brackets around the datatype (if that does
> indeed make handling typed literals 'full-Turtle-compatible' (and thereby
> justifying the 'SimplifiedTurtle' name) - if not then further thought and
> consideration required maybe...!)).
> 
> So for the reason given above, it does not. Would that change your answer?
> 

Yeah, I think so. I just dislike the idea of 'something new' when Turtle is so close. But I accept the (admittedly necessary) complexity of full-Turtle will over-complicate things for us here - at least initially (i.e. until Hydra reaches broad adoption and then complex edge-cases start to emerge that maybe do require full-Turtle support - in which case the extensibility here gets us 'out-of-jail').

Thanks!

> Best,
> 
> Ruben
> 
> [1] http://www.w3.org/TR/turtle/#sec-grammar-grammar

Received on Wednesday, 20 August 2014 09:23:42 UTC