|
Some of the tests in the W3 Conformance suite appear to have relative URIs with no base URI supplied. I'm assuming I need to provide a default. As best I can tell, the specification states that a default base URI is "application-dependent", as per RFC3986, section 5.1.4. I interpreted this as meaning it could be dependent on the triple-store, and since the store in question here is one I'm not only creating specifically to run tests on, but am also implementing, I figured it was appropriate to set its default base URI to whatever I wanted; namely, something it could interpret specifically as a test-related URI, and therefore look in a special location for the data files it's supposed to load. For example, the query: Would go to the server practically as-is, and the server would see <data-g1.ttl> as a relative URI. Seeing no base URI, would assign its default base URI - e.g. "http://testing.mycompany.com/" - combine that with the relative, resulting in "http://testing.mycompany.com/data-g1.ttl", and then interpret that as "go to this special folder of Turtle files on the server's hard drive, find 'data-g1.ttl', and load it". Am I doing this even close to correctly? (One of the problems I'm running into involves a translation step between receiving the SPARQL query and processing it. To process it, it needs to be expressed in a different language, and we're using OpenRDF's Sesame library plus our own custom visitor code to handle that. While the query above validates fine according to sparql.org's validator, Sesame considers it a malformed query, precisely because of that relative URI. We can't tell Sesame what the default base URI should be, at the point we need to translate it, at least not without some nontrivial and inappropriate-looking redesign.) |
|
The Base URI for each test should be the URI of the manifest file The simplest way to add this would be to prepend a BASE declaration to each query e.g. Thanks for the answer... it feels mildly skeezy to me, though, and I'm not sure why, which makes me think I'm missing something:
To be honest it sounds like you are trying to test too much in one go. The point of the suite is to test your implementation of the SPARQL language which ideally should not require you to test your full server infrastructure as well (there are separate portions of the test suite for checking conformance with the SPARQPL protocol). Do you not have a way of producing a test harness which runs directly against your store? Well, not really testing the whole thing... but the "OBE" I hinted at in a comment earlier refers to something similar. I think I needed to just reexamine where I was drawing the line between client and server, such that the default base IRI can be known earlier. |
Not an answer to your question but perhaps a good workaround: since you are using Sesame's parser, have you considered using a BaseDeclProcessor? This is a syntax tree visitor implementation that can resolve any relative URIs in the syntax tree with a supplied base URI. It depends on whether you know the base URI at the point where you activate this processor of course... See http://www.openrdf.org/doc/sesame2/api/index.html?org/openrdf/query/parser/sparql/BaseDeclProcessor.html
From what I understand of BaseDeclProcessor, all it does is conveniently resolve relative IRIs given the relative IRI and a base IRI - which means I still have to provide that base IRI, and at a time where I don't necessarily know that (although this micro-problem might be OBE now in my case). That said, it seems a fine way to do that resolution; beats picking the IRI string apart manually.