W3C home > Mailing lists > Public > public-rdf-comments@w3.org > April 2013

[RESOLVED] Re: normalization issues with Turtle spec tests

From: Ruben Verborgh <ruben.verborgh@ugent.be>
Date: Sun, 7 Apr 2013 21:16:46 +0200
Cc: public-rdf-comments@w3.org, Gregg Kellogg <gregg@greggkellogg.net>, gavin@carothers.name
Message-Id: <08FBDF74-63CB-4A95-91E9-CC4E396721FA@ugent.be>
To: Eric Prud'hommeaux <eric@w3.org>
Dear Eric,

> I believe it's been this way going back to the first model and syntax REC in 1999.
>  http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/#glossary

My bad, I was influenced by the behavior of cwm.

> Hmm, I bet that those three "1"s are the three variants you provided as input, but normalized by the serializer.

You’re right, it’s the serializer. The rule
   { <a> <b> 1 } => { <a> <b> <c> }.
triggers with <a> <b> "1"^^xsd:integer. but not with <a> <b> "+1"^^xsd:integer.

> They are. The point, we decided eventually, is that language tags be compared insensitively.
> Another comment has produced some proposed text to be incorporated into RDF Concepts.
>  http://www.w3.org/mid/OF191FDF83.9AD29A20-ONC1257B41.002BECC9-C1257B41.003030AC@agfa.com
> If this text is adopted, would that satisfy your comment?

Yes, then it would be fine.
If, however, the “must be normalized to lowercase” stays in,
I would suggest changing the test result of langtagged_LONG_with_subtag to lowercase.

> I'm guessing that that's like the SPARQL pattern { ?a ?b 1 } which would match the first two (‘1' and ‘”1"^^xsd:integer’), presuming the single quotes are not in the actual Turtle document.
> 
> The SPARQL test suite as a bunch of tests in this area. Don't be thrown off by the difference between the lexically-sensitive term equivalence in graph pattern:
>  { ?x :p 1 . } — Equality 1-1 -- graph <http://www.w3.org/2001/sw/DataAccess/tests/r2#eq-graph-1>
> vs. the value-sensitive tests in the SPARQL Operator Mapping <http://www.w3.org/TR/sparql11-query/#OperatorMapping>:
>  { ?x :p ?v . FILTER ( ?v = 1 ) . }  — Equality 1-1 <http://www.w3.org/2001/sw/DataAccess/tests/r2#eq-1>

This totally makes sense. I will implement it that way in the library, thanks very much.

> Let me know if you run into trouble with that. I can't remember if --compare was in the last version I uploaded. Linux will be the easiest for me to release if not.

It works on the latest released Linux version:
$ ./sparql --version
sparql version 1.0 .
Revision 1728 modified 2012-05-30 09:05:34 -0400 (Wed, 30 May 2012) by ericprud.
https://swobjects.svn.sourceforge.net/svnroot/swobjects/branches/sparql11
$ ./sparql -d temp.ttl --compare temp.ttl
matched

But fails on the latest released OSX version:
$ ./Sparql --version
sparql version 1.0 .
Revision 1759 modified 2012-08-04 16:23:35 -0400 (Sat, 04 Aug 2012) by ericprud.
https://swobjects.svn.sourceforge.net/svnroot/swobjects/branches/sparql11
$ ./Sparql -d temp.ttl --compare temp.ttl
{
  </a> </b> </c> .
}
!=
+-+
| |
+-+

So somewhere between 1728 and 1759, something must have been broken.

Best,

Ruben
Received on Sunday, 7 April 2013 19:17:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:55 UTC