On 20/10/17 10:34, Laura Morales wrote:
While that is a simple change it is a breaking change behaviourally. You go
from a situation where a user gets an explicit error message that they can do
something about to a situation where some aspects of invalid configurations are
silently ignored. For complex configurations this may lead to all sorts of
subtle and invisible errors which uses could waste far more time trying to
track down than if they had just received an error as they do currently.
Or it could show a log message?
if (m != null)
print (m + " not a valid model. Skipping graph " + gName);
Then it's the responsibility of HDT (or any other custom assembler) to decide
what to do:
- print "file not found" and throw an exception, or
- return null (that in turn will trigger the "invalid model" message), or
- return a DefaultModel
I'm failing to see how this is workable - surly, you want the entire
service to not be there if it has some/all data missing? I can see lots
of different variations being reasonable in different situations -
hence, don't put policy in Fuseki core.
One option is to use that fact that service configurations can go in
run/configuration, one file per service. No need to put all in config.ttl.
Then switch them in and out depending on the availability of HDT files -
some scripting around launching the Fuseki server.
Andy
