Re: issues with TriG Test Suite

I have updated the fixed manifest on the mercurial repository.

Ivan

> On 28 Dec 2014, at 01:25 , Gregg Kellogg <gregg@greggkellogg.net> wrote:
> 
>> On Dec 27, 2014, at 8:05 AM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:
>> 
>> Dear all,
>> 
>> I am extending the N3.js JavaScript RDF library [1],
>> with support for TriG, in addition to Turtle.
>> During this process, I ran into the issues below.
>> 
>> 1. The following tests have the wrong title:
>> - trig-syntax-bad-n3-extras-01
>> - trig-syntax-bad-n3-extras-02
>> - trig-syntax-bad-n3-extras-03
>> - trig-syntax-bad-n3-extras-04
>> - trig-syntax-bad-n3-extras-05
>> - trig-syntax-bad-n3-extras-06
>> - trig-syntax-bad-n3-extras-07
>> - trig-syntax-bad-n3-extras-08
>> - trig-syntax-bad-n3-extras-09
>> - trig-syntax-bad-n3-extras-10
>> - trig-syntax-bad-n3-extras-11
>> - trig-syntax-bad-n3-extras-12
>> - trig-syntax-bad-n3-extras-13
>> They are named "X is not / X not in Turtle"
>> but should be named "X is not / X not in TriG".
> 
> Indeed, I'll send a fixed Manifest to Ivan for him to update, as I don't have write access to the repo any longer. Note that it doesn't change anything about processing, just the description of the tests (obviously, simply copied from Turtle).
> 
>> 2. Tests are served from the wrong URL.
>> For instance, if we fetch
>>   http://www.w3.org/2013/TriGTests/trig-subm-27.trig
>> it redirects with a 301 to (note the capitalization difference)
>>   http://www.w3.org/2013/TrigTests/trig-subm-27.trig
>> yet the file itself says (note again the capitalization difference)
>>   # In-scope base URI is <http://www.w3.org/2013/TriGTests/trig-subm-27.trig> at this point
>> This can be fixed by setting the canonical URL to:
>>   http://www.w3.org/2013/TriGTests/{…}
> 
> Where did you find the <http://www.w3.org/2013/TriGTests/> URL? The RDF 1.1 Test Cases document [1] references <http://www.w3.org/2013/TrigTests/>.
> 
>> 3. trig-syntax-minimal-whitespace-01 contains three syntax errors
>> on line 12 and should thus not parse. The line reads:
>>   {_:s:p :o ._:s:p"Alice". _:s:p _:o .}
>> While the first triple is probably intended to be parsed as:
>>   _:s <http://example/a/p> <http://example/a/o>
>> and thus to be lexed as:
>>   PrefixedName(PNAME_LN) PrefixedName(PNAME_LN) PrefixedName(PNAME_LN) '.'
>> it actually needs to be lexed as:
>>   PrefixedName(PNAME_LN) PrefixedName(PNAME_LN) '.'
>> because PNAME_LN consists of PNAME_NS PN_LOCAL, and the latter may contain colons.
>> This behavior is asserted in localname_with_COLON,
>> so I find it strange that implementations exist which pass both tests.
>> To correct this test case, whitespace should be inserted after each '_:s'.
> 
> Not an official response, but _:s is a Blank Node, not a PName, so it is defined as "_:" followed by PN_CHARS_BASE, which doesn't include ':'. PNAME_LN uses PN_LOCAL, which does include ':'. I believe the test is valid.
> 
>> When we find a resolution to the third point,
>> I'll have a new EARL report to share
>> for http://www.w3.org/2013/TrigReports/index.html :-)
> 
> I can certainly create a new report, but I'm not sure about updating that link, as it records what was used to transition.
> 
> Gregg
> 
>> Best,
>> 
>> Ruben
>> 
>> [1] https://github.com/RubenVerborgh/N3.js
> 
> 


----
Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704