@prefix headers coming out-of-order

@markwilkinson: It was my uid/pwd which needed to be dav:dav , then I was able to run the ruby program against a local Virtuoso instance.

With the local test the prefixes are also mixed with between lines of data ie

@prefix rdf:    <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix ns1:    <http://localhost:8890/DAV/ldp/> .
@prefix ldp:    <http://www.w3.org/ns/ldp#> .
ns1:obs_1-19e1  rdf:type        ldp:Resource ,
                ldp:RDFSource .
@prefix rdfs:   <http://www.w3.org/2000/01/rdf-schema#> .
ns1:obs_1-19e1  rdf:type        rdfs:Resource .
@prefix ns4:    <http://www.w3.org/ns/posix/stat#> .
ns1:obs_1-19e1  ns4:mtime       1560460142 ;
        ns4:size        103 .
ns1:obs_2-130d  rdf:type        ldp:Resource ,
                ldp:RDFSource ,
                rdfs:Resource ;
        ns4:mtime       1560460142 ;
        ns4:size        103 .

But adding the data snippet to a Turtle validator like http://ttl.summerofcode.be it is reported as being valid, thus is seems it is not a requirement for all prefixes to be specified at the beginning of the file ?

I see… ok, it must be a bug in the rdf-raptor parser (I get a segfault when I try to parse that turtle). I agree - I just read the Turtle spec, and it doesn’t explicitly say that the prefix headers can appear anywhere, but it implies that they can, because it says that a prefix can be redefined.

I’ll send a bug report to the rdf-raptor people. in the meantime, I’ve patched my code to reorder the lines returned from Virtuoso so that I can get on with my project. :slightly_smiling_face:

Sorry to bother you!

That URI doesn’t resolve at the current time.

curl -ILH "Accept: text/turtle" http://training.fairdata.solutions/DAV/home/LDP/
HTTP/1.1 404 Not Found
Date: Thu, 05 Sep 2019 20:35:41 GMT
Server: Virtuoso/07.20.3230 (Linux) x86_64-generic_glibc25-linux-gnu
X-Frame-Options: SAMEORIGIN
Content-Type: text/html; charset=UTF-8
Accept-Ranges: bytes
Content-Length: 205

Yeah, it is a bit of an old conversation :slight_smile:

In any case, it seems that the problem is not with Virtuoso, but rather with the Raptor parser, so we can probably close the conversation as “resolved”.