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).

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"

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.

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

> +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?

Best,

Ruben

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

Received on Wednesday, 20 August 2014 08:33:07 UTC