Could you provide a stripped down file that illustrates the effect?
And what does "riot --pretty TTL FILE" show as output.
One last factor - I presume you use
FusekiServer.create().parseConfigFile(FILE)
URIs should be relative to the config file unless it has a BASE.
On 07/07/2020 07:35, Nouwt, B. (Barry) wrote:
Hi Andy, thanks, I'm indeed using Apache Jena Main (i.e. embedded into a Java
application).
One of our developers uses a Mac with Eclipse and the problem we are
experiencing is that we cannot find a value for the ja:rulesFrom that works
both from Windows Eclipse and on Mac Eclipse (that's why I want to try
classpath, because it might be more consistent between OSs).
On Windows it resolves the relative path relative to the working directory of the JVM (so
it needs a value like <src/test/resources/some.rules>), while on Mac it seems to
resolve it relative to the location of the config.ttl file (so it needs a value like
<some.rules>.
If debugging trace is on, it should show the full URI.
If it is relative after reading the config file, then there wasn't a
base at parse time which I can't understand.
I am not sure what causes this difference, but one of the things I noticed is that
the resource gets translated to <C:some.rules> while I think on a Mac it will
not.
C:foo is relative as a file name, to the current directory on the C:
drive. Jena treats one character URI schemes as Windows drives
(hopefully! I don't have Windows)
If the attempt to read is <C:some.rules> then again it suggests no base URI.
Thanks for the pointers to a custom "cp:" LocationMapper...I'll check it out,
although I do consider this divergence between the Windows and Mac platform undesirable.
Not sure if it's the JVM or Apache Jena code that causes this...though.
Kind regards, Barry
-----Original Message-----
From: Andy Seaborne <[email protected]>
Sent: maandag 6 juli 2020 17:08
To: [email protected]
Subject: Re: load rules file via class loader (as a resource)
Hi Barry,
Plain <some.rules> is a relative URI so it is going to be resolved in parsing
the assembler to file:///.../some.rules before it even looks for the rules.
Finding files will include the classpath but it would need a trick to get round
the resolution.
<cp:some.rules> will ve left alone and the resource looked for should
"cp:some.rules"
I can't remember which packing of Fuseki you use.
If its the Fuseki main, launched from a java app, you can add a Locator to the global
StreamManager and control the interpreation of URI so seeing, e.g.
<file:///../some.rules> look for "some.rules".
It might work with a LocationMapper but if you are taking control of rule file
mgt, maybe its better to have a custom locator as LocationMapper has only a
fixed few rename policies.
On 06/07/2020 13:02, Nouwt, B. (Barry) wrote:
Hi everyone,
I am starting Apache Jena Fuseki with a Turtle configuration file to set up our
services and dataset. We have a problem with loading the separate some.rules
file from the classpath (or via the classloader) using the 'ja:rulesFrom'
predicate of the reasoner.
If we set the 'ja:rulesFrom' predicate to '<some.rules>' (it expects a resource
not a literal), the configuration fails to load because it cannot find this file. If
we look a bit deeper (using the Java debugger), we notice that the 'some.rules' gets
transformed to 'C:some.rules' somewhere internally and it therefore does not look at
the classpath, but at the local file system. Is there a way to reference the
'some.rules' file from the class path if the Turle configuration file is in the same
location of the JAR? Something like: classloader:some.rules...or just '/some.rules'
as would work with the this.getClass().getResourceAsStream('/some/rules'). I've tried
several options, but all fail.
I did notice this in the documentation, which might be what explains
the behaviour: "A resource name with no URI scheme is assumed to be a
local file name."
(https://jena.apache.org/documentation/io/rdf-input.html#api)
That's in the RDFDataMgr etc.
"foo" will be looked up as-is, via the Locators of the StreamManger. The global stream a
manager includes looking in the classpath for "foo" (no URI resolution).
"classpath" counts as "file system".
Andy
Regards, Barry
This message may contain information that is not intended for you. If you are
not the addressee or if this message was sent to you by mistake, you are
requested to inform the sender and delete the message. TNO accepts no liability
for the content of this e-mail, for the manner in which you use it and for
damage of any kind resulting from the risks inherent to the electronic
transmission of messages.
