tests should be deployed at a defined location and define BASE

[VladimirAlexiev]

All manifests in https://github.com/w3c/data-shapes/tree/gh-pages/shacl12-test-suite/tests and subfolders look like this:

<> a mf:Manifest ;
	mf:include <core/manifest.ttl> ;
	mf:include <sparql/manifest.ttl> ;
	.

Individual tests look like this, eg https://github.com/w3c/data-shapes/blob/gh-pages/shacl12-test-suite/tests/core/complex/personexample.ttl#L58

<personexample> rdf:type sht:Validate ; mf:action [sht:dataGraph <> ; sht:shapesGraph <>].
<> rdf:type mf:Manifest ; mf:entries (<personexample>) .

<> and <personexample> depend on the location of each of these files.

This should work ok for a test runner since it will use the local file folder where the tests are found.
It is useful for test authors to:

• leverage the folder hierarchy and not have to keep URLs in sync with any reorganizations
• be able to just write sht:dataGraph <> ; sht:shapesGraph <> ; in many of the test files (which means "data and shapes for this test are in THIS file")

However, this means that individual tests don't have defined URLs.

https://w3c.github.io/data-shapes/data-shapes-test-suite/ does not define the root location where the tests will be deployed

• but individual tests are listed as https://github.com/w3c/data-shapes/blob/gh-pages/data-shapes-test-suite/tests/core/complex/personexample.ttl; that URL returns a web page
• the new location that returns a turtle file is https://github.com/w3c/data-shapes/raw/refs/heads/gh-pages/shacl12-test-suite/tests/core/complex/personexample.ttl
• But the actual test (sht:Validate) uses a different semantic URL: it doesn't have .ttl at the end

Why well-defined semantic URLs for individual tests are important? Because:

• We would want to tie them up to SHACL spec clauses.
  See Linked Specifications, Test Suites, and Implementation Reports about this idea.
  Like other W3C specs, SHACL is careful to create stable anchors for its sections and definitions, eg https://w3c.github.io/data-shapes/shacl/#EqualsConstraintComponent is the spec clause about sh:equals
• We may need to tie them up to SHACL's own profiles
• We want conformance reports (EARL) to refer to well-defined tests URLs.
  I have not seen SHACL 1.0 EARL reports; if they used the same test runner then hopefully they reported against the same test URLs.