Make manifest bases not include the file extension

[gkellogg]

(e.g., <https://w3c.github.io/rdf-star/tests/sparql/eval/manifest#sparql-star-update-3>).

Required a bit of post-serialization hackery of the manifest.jsonld contexts.

Also, includes building the JSON-LD manifests in the Makefile target.

cc/ @afs

[gkellogg]

We could run make just for CI purposes, or have a different action to run make an commit any updated files, to ensure that they get built on any change. This might be expensive if extended to reports without improved dependency checks.

Certainly, for now, running it as part of CI might be useful. It might even be considered an error if any files are out of date.

[afs]

My tests run extremely slowly now :-)

If BASE changes, then the file locations change to be the web. I think we want them local.

If PREFIX : changes, only the URL of tests (that goes into earl:test) changes and the suite runs off local files.

That leaves a separate issue about the URL of the manifests file itself. It is <> currently, while tests are :some-test. This is what the "rdf-tests" are like. The fact the manifest starts <> a mf:Manifest does not get in the way because only the test URL matters.

Example: https://github.com/w3c/rdf-tests/blob/main/sparql11/data-sparql11/bind/manifest.ttl

PREFIX :       <https://w3c.github.io/rdf-star/tests/sparql/syntax/manifest#>

Greggs right it is less portable and needs updating if moved . Only relative URi give that and we need to use them for local files.

I'm happy to do the PR .

There are other more elaborate ways (not a proposal!):

PREFIX local:   <.>
BASE <https://w3c.github.io/rdf-star/tests/sparql/syntax/manifest>
PREFIX : <#>

and all files are local:sparql.rq but this isn't supposed to be a resolver test suite!

[gkellogg]

My own runner intercepts remote load requests that match the repository location and attempts to satisfy them locally.

But, one advantage of the previous BASE <manifest> would be to maintain the directory relative nature of file loading. That is the pattern we used for jsonld tests.

[afs]

There are two aspects - file location and test URIs. Having absolute BASE and relative prefix fixes both.

I don't think we want the test URIs if the directory structure changes because the test URIs are in the EARL reports.

BASE <manifest> is fine if that helps the HTML generation.

The suggestion is to have fixed URI for the tests entries (not the files for the tests).

PREFIX :       <https://w3c.github.io/rdf-star/tests/sparql/syntax/manifest#>

is not dependent on base.

[ rdf:type         earl:Assertion ;
  earl:assertedBy  <http://jena.apache.org/#arq> ;
  earl:mode        earl:automatic ;
  earl:result      [ rdf:type      earl:TestResult ;
                     dc:date       "2021-03-18+00:00"^^xsd:date ;
                     earl:outcome  earl:passed
                   ] ;
  earl:subject     <http://jena.apache.org/#arq> ;
  earl:test        <https://w3c.github.io/rdf-star/tests/sparql/eval/manifest#sparql-star-pattern-7>
] .

[gkellogg]

The PREFIX : solution works in Turtle, but not so well in JSON-LD. Basically, @id is evaluated relative to the base location (@base in the context, or the actual file location). And, JSON-LD does not support (for historical reasons) and empty prefix. Generally, you'd like to see something like "@id": "#ntriples-star-4" to continue to be relative to <https://w3c.github.io/rdf-star/tests/n3/syntax/manifest> along with "action": "ntriples-star-syntax-4.nt" to locate the test file. We could create something like a local prefix to get to local files such as "action": "local:ntriples-star-syntax-4.nt", but it looks odd.

Using a relative base, works for both JSON-LD and Turtle, and is pretty equivalent to not having an explicit BASE / @base specified from a processing point. It's unfortunate that file extension becomes part of the base calculation, but RFC3986 doesn't know about this, and content negotiation to remove format considerations from resources hasn't proved to be practical. IMO, overriding the tail portion of the base calculation is the best solution available that preserves the formatting people typically expect.

That said, BASE <manifest> doesn't really affect HTML generation, AFAIK.

Typically, a README (or the HTML version of the manifest) would instruct implementors to run the tests as if they were located relative to <https://w3c.github.io/rdf-star/tests/> so that we don't need to use absolute URLs in the manifests, themselves. This can simplify running from a local copy, as long as provisions are taken to use the actual location when reporting. SHACL even goes so far as to use a URN as the manifest base.

[afs]

I'm happy to accomodate JSON-LD.

Can we have a non-empty prefix? Does that fix the issue for jSON-LD:

PREFIX test: <https://w3c.github.io/rdf-star/tests/n3/syntax#>
...
test:sparql-star-basic-2
...

(no manifest, no BASE needed - seems to work). This makes the location of files relative and the suite can be moved around as you want.

[gkellogg]

Why don’t you do a PR with the Turtle bits and I’ll add a comimit to update jsonld.

[afs]

OK