NTriplesReader does not resolve relative uris with the base provided to it

[reederz]

Here you can see that even though the read function is provided with base, it is not used: https://github.com/w3c/banana-rdf/blob/series/0.8.x/io/ntriples/common/src/main/scala/org/w3/banana/io/NTriplesReader.scala#L41-42 .

[bblfish]

yes, that is normal as NTriples documents contain no relative URLs. That is one of the reasons why they are so easy to parse, aside that all the triples are on one line. It is also a reason why they are so horrible for humans to read :-). On the other hand you have a good point and that is that it is confusing to still have to provide a base for a format that always ignores it. So it's worth keeping this issue open.

[reederz]

I'm requesting the resource through https://github.com/read-write-web/rww-play server. Here's how requesting an n-triples resource works via CORS proxy vs normally. via CORS proxy:

[  2:36PM ]  [ justas@choedankal:~/Source/scala/workspace/jolocom/rww-play/test_www(jolocom✗) ]
 $ curl -k -i -H "Accept: application/n-triples" -X GET \
   --cert ../eg/test-localhost.pem:test "https://localhost:8443/srv/cors?url=https%3A%2F%2Flocalhost%3A8443%2F2013%2Fcouch"
HTTP/1.1 200 OK
Accept: application/n-triples
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Content-Type: application/n-triples
Host: localhost:8443
User-Agent: curl/7.40.0
Content-Length: 1985

<https://localhost:8443/2013/couch#mycouch> <http://purl.org/goodrelations/v1#description> "Comfortable couch in Artist Stables"^^<http://www.w3.org/2001/XMLSchema#string> .
_:genid-6382c443ca2c43778040cc45991c56d2-genid-5669fc7e1dc84e8c860d396866d6c2af-node19fn63u4nx2 <http://www.w3.org/2000/10/swap/pim/contact#city> "Fontainebleau"^^<http://www.w3.org/2001/XMLSchema#string> .
_:genid-6382c443ca2c43778040cc45991c56d2-genid-5669fc7e1dc84e8c860d396866d6c2af-node19fn63u4nx2 <http://www.w3.org/2000/10/swap/pim/contact#postalCode> "77300"^^<http://www.w3.org/2001/XMLSchema#string> .
_:genid-6382c443ca2c43778040cc45991c56d2-genid-5669fc7e1dc84e8c860d396866d6c2af-node19fn63u4nx2 <http://www.w3.org/2000/10/swap/pim/contact#country> "France"^^<http://www.w3.org/2001/XMLSchema#string> .
<https://localhost:8443/2013/couch> <http://www.w3.org/ns/ldp#contains> <https://localhost:8443/2013/couch> .
<https://localhost:8443/2013/couch#mycouch> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://bblfish.net/2013/05/10/couch#Surf> .
_:genid-6382c443ca2c43778040cc45991c56d2-genid-5669fc7e1dc84e8c860d396866d6c2af-node19fn63u4nx1 <http://www.w3.org/2000/10/swap/pim/contact#address> _:genid-6382c443ca2c43778040cc45991c56d2-genid-5669fc7e1dc84e8c860d396866d6c2af-node19fn63u4nx2 .
<https://localhost:8443/2013/couch#mycouch> <http://purl.org/goodrelations/v1#color> "Red"^^<http://www.w3.org/2001/XMLSchema#string> .
<https://localhost:8443/2013/couch#mycouch> <http://purl.org/goodrelations/v1#location> _:genid-6382c443ca2c43778040cc45991c56d2-genid-5669fc7e1dc84e8c860d396866d6c2af-node19fn63u4nx1 .
_:genid-6382c443ca2c43778040cc45991c56d2-genid-5669fc7e1dc84e8c860d396866d6c2af-node19fn63u4nx2 <http://www.w3.org/2000/10/swap/pim/contact#street> "21 rue Saint Honoré"^^<http://www.w3.org/2001/XMLSchema#string> .
<https://localhost:8443/2013/couch#mycouch> <http://purl.org/goodrelations/v1#name> "Very Unstable Couch"^^<http://www.w3.org/2001/XMLSchema#string> .

nomal:

[  2:38PM ]  [ justas@choedankal:~/Source/scala/workspace/jolocom/rww-play/test_www(jolocom✗) ]
 $ curl -k -i -H "Accept: application/n-triples" -X GET \
   --cert ../eg/test-localhost.pem:test https://localhost:8443/2013/couch                                                  
HTTP/1.1 200 OK
Accept-Patch: application/sparql-update
Access-Control-Allow-Origin: *
Allow: OPTIONS, GET, HEAD, SEARCH, PUT, DELETE, PUT, PATCH
Content-Type: application/n-triples
ETag: "1425638154104|Success(857)"
Last-Modified: Fri, 06 Mar 2015 10:35:54 GMT
Link: <http://www.w3.org/ns/ldp#Resource>; rel=type, <couch.acl>; rel=acl
Content-Length: 1481

<#mycouch> <http://purl.org/goodrelations/v1#description> "Comfortable couch in Artist Stables"^^<http://www.w3.org/2001/XMLSchema#string> .
_:genid-5669fc7e1dc84e8c860d396866d6c2af-node19fn63u4nx2 <http://www.w3.org/2000/10/swap/pim/contact#city> "Fontainebleau"^^<http://www.w3.org/2001/XMLSchema#string> .
_:genid-5669fc7e1dc84e8c860d396866d6c2af-node19fn63u4nx2 <http://www.w3.org/2000/10/swap/pim/contact#postalCode> "77300"^^<http://www.w3.org/2001/XMLSchema#string> .
_:genid-5669fc7e1dc84e8c860d396866d6c2af-node19fn63u4nx2 <http://www.w3.org/2000/10/swap/pim/contact#country> "France"^^<http://www.w3.org/2001/XMLSchema#string> .
<> <http://www.w3.org/ns/ldp#contains> <> .
<#mycouch> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://bblfish.net/2013/05/10/couch#Surf> .
_:genid-5669fc7e1dc84e8c860d396866d6c2af-node19fn63u4nx1 <http://www.w3.org/2000/10/swap/pim/contact#address> _:genid-5669fc7e1dc84e8c860d396866d6c2af-node19fn63u4nx2 .
<#mycouch> <http://purl.org/goodrelations/v1#color> "Red"^^<http://www.w3.org/2001/XMLSchema#string> .
<#mycouch> <http://purl.org/goodrelations/v1#location> _:genid-5669fc7e1dc84e8c860d396866d6c2af-node19fn63u4nx1 .
_:genid-5669fc7e1dc84e8c860d396866d6c2af-node19fn63u4nx2 <http://www.w3.org/2000/10/swap/pim/contact#street> "21 rue Saint Honoré"^^<http://www.w3.org/2001/XMLSchema#string> .
<#mycouch> <http://purl.org/goodrelations/v1#name> "Very Unstable Couch"^^<http://www.w3.org/2001/XMLSchema#string> .

See that in the second example, we have relative URLs.

[bblfish]

Well spotted. The problem is that the graphs currently are what we call "relative graphs" which can contain relative URLs. If we could distinguish between "relative graphs" and rdf graphs then my point above would be correct that the base would be unecessary. ( see issue #41 "new types for relative uris and relative graphs" ). But as it is the base is always important. So that needs to be fixed.

[bblfish]

No, that's wrong. The problem is not with the parser but with the serialiser. But the same point holds.

[bblfish]

This is not a problem with the serialiser but with the parser. One could add something to test that the the URLs are not relative. That would be potentially solved with fixing issue #41

[bblfish]

It looks like I accepted a patch on the fork of banana-rdf on read-write-web https://github.com/read-write-web/banana-rdf/commit/fed75c4dd5020a00cf3093fe1ad386802c68b72a

[bblfish]

I think I have fixed this in PR https://github.com/w3c/banana-rdf/pull/287

[bblfish]

Ok, so this issue is now fixed.

[bblfish]

Ah no, that only fixes it on 0.7 series branch. The 0.8.x series perhaps also needs adapting.