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>. 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. 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. >
