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

On 20 Aug 2014 at 11:23, McBennett, Pat wrote:
> Ruben Verborgh wrote on 20 Aug 2014 at 09:33:
>>> 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)?

It's not consistency, it is, as you say later, to distinguish between IRIs
and prefixed names:

   [135s] iri ::= IRIREF |  PrefixedName


[...]


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

Indeed a good point that I missed myself.


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

Yeah. Considering we (or someone else) *might* introduce full Turtle at a
later point. Do we really want to have two syntaxes that look so similar,
yet are incompatible with each other?

  "Markus"^^<http://www.w3.org/2001/XMLSchema#string>
  "Markus"^^http://www.w3.org/2001/XMLSchema#string

  """Markus"""^^<http://www.w3.org/2001/XMLSchema#string>
  """Markus"""^^http://www.w3.org/2001/XMLSchema#string

I still see that as the source of many hard-to-detect errors, bugs, and
incompatibilities. But if the group thinks this is the way to go, I won't
stand in the way.

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

--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 20 August 2014 10:47:45 UTC