Hi Pierre,
Good luck with tracking down the issues.
It's certainly the case that the rule system can be slow even over
memory based stores, so when running over a TDB store then performance
can definitely be an issue and could make some queries look like they'll
never finish.
There was a recent report of a transaction error with the rule systems:
https://issues.apache.org/jira/projects/JENA/issues/JENA-1719
That instance has been fixed for 3.13.0 so if you continue to run into
those "in transaction" messages then try a nightly build. However, as it
says in that Jira, the underlying issue runs fairly deep (due to the age
of the rules systems which were build in an era of in memory stores and
less clear transaction management) so there may be other manifestations
of the problem with haven't been caught.
Regards,
Dave
On 22/07/2019 17:55, Pierre Grenon wrote:
Hi Dave,
Thanks so much for your detailed reply, it helped.
I’ve looked into 1 so far (using @include) and I seem to have some good results
whether using <RDFS> or some file with the rule set. (In fact I tried different
variants of the rdfs rule set and it seemed to be doing about the same.) Yes, indeed,
it has to be all config based I’m afraid as java isn’t the way to go in the context.
However, I haven’t ironed out yet my config and I ran into a few crippling
inconveniences with Fuseki 3.12 (some apparently non terminating queries – you
need to hit ‘enter’ in the fuseki-server prompt to get a response, some
annoying white space issues in the file names -- %20 doesn’t help – and I had
some ‘in transaction’ message erratically at some point – no clue and I’m sorry
that I can’t reproduce this now.)
I need to look more into https://jena.apache.org/documentation/inference/#rules
I suppose as this is all a bit too much shooting in the dark.
I’m trying again from scratch with a clean example, sticking with Fuseki 3.10.
I’ll post my config file if I manage.
I have not looked at 2 yet.
With many thanks and kind regards,
Pierre
THIS E-MAIL MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED INFORMATION.
IF YOU ARE NOT THE INTENDED RECIPIENT (OR HAVE RECEIVED THIS E-MAIL
IN ERROR) PLEASE NOTIFY THE SENDER IMMEDIATELY AND DESTROY THIS
E-MAIL. ANY UNAUTHORISED COPYING, DISCLOSURE OR DISTRIBUTION OF THE
MATERIAL IN THIS E-MAIL IS STRICTLY FORBIDDEN.
IN ACCORDANCE WITH MIFID II RULES ON INDUCEMENTS, THE FIRM'S EMPLOYEES
MAY ATTEND CORPORATE ACCESS EVENTS (DEFINED IN THE FCA HANDBOOK AS
"THE SERVICE OF ARRANGING OR BRINGING ABOUT CONTACT BETWEEN AN INVESTMENT
MANAGER AND AN ISSUER OR POTENTIAL ISSUER"). DURING SUCH MEETINGS, THE
FIRM'S EMPLOYEES MAY ON NO ACCOUNT BE IN RECEIPT OF INSIDE INFORMATION
(AS DESCRIBED IN ARTICLE 7 OF THE MARKET ABUSE REGULATION (EU) NO 596/2014).
(https://www.handbook.fca.org.uk/handbook/glossary/G3532m.html)
COMPANIES WHO DISCLOSE INSIDE INFORMATION ARE IN BREACH OF REGULATION
AND MUST IMMEDIATELY AND CLEARLY NOTIFY ALL ATTENDEES. FOR INFORMATION
ON THE FIRM'S POLICY IN RELATION TO ITS PARTICIPATION IN MARKET SOUNDINGS,
PLEASE SEE https://www.horizon-asset.co.uk/market-soundings/.
HORIZON ASSET LLP IS AUTHORISED AND REGULATED
BY THE FINANCIAL CONDUCT AUTHORITY.
From: Dave Reynolds [mailto:dave.e.reyno...@gmail.com]
Sent: 21 July 2019 09:54
To: users@jena.apache.org
Subject: Re: Combining inferences from GRR and RDFS or OWL reasoner
Hi Pierre,
You've two options for combining a GRR rule set and RDFS inference
either combine the rules into a single rule set and use a GRR
configuration or, as you say, layer the GRR reasoner over the top of an
RDFS reasoner.
1. To combine the rules then in your GRR rule set use the directive:
@include <RDFS>.
to include the rules for RDFS inference before your own rules. There are
some restrictions here though. Firstly, the default RDFS rules which are
included by this method need the transitive reasoner enabled.
Programmatically that's easy:
reasoner.setTransitiveClosureCaching(true);
However, I'm not sure if the assembler notation supports that. I'm not
really familiar with the assembler machinery but a quick glance through
the documentation and schema didn't turn up any obvious way to set this.
If there really is no way to set this flag in assemblers, and if you are
restricted to using assemblers, then a workaround (other than option 2,
below) would be to use an RDFS rule set which doesn't need the
transitive reasoner. Jena includes such a rule set:
https://github.com/apache/jena/blob/master/jena-core/src/main/resources/etc/rdfs-fb.rules<https://github.com/apache/jena/blob/master/jena-core/src/main/resources/etc/rdfs-fb.rules>
You could copy those somewhere visible to your application and @include
them from there.
The other limitation of the single ruleset approach is that, because the
RDFS rules using a mix of forward and backward chaning, the rules you
add on top all[*] need to be written as backward chaining rules.
Otherwise they won't "see" the results of the RDFS backward chaining rules.
2. The alternative is, as you say, to configure an RDFS reasoner, then
configure a GRR instances whose base model is your RDFS reasoner. You
wouldn't then need a union as well - all the triples visible in the RDFS
InfGraph would be visible through the GRR InfGraph.
Dave
[*] Well, at least those that might be affected by the results of RDFS
inference.
On 19/07/2019 22:36, Pierre Grenon wrote:
apologies for piecemeal post -- didn't copy the whole file at first, so the
RDFS reasoner, in particular, wasn't there.
I'm wondering if I need to have an inf model with the GRR reasoner with an RDFS
reasoner submodel and also the reverse and then union these... sounds a bit
weird.
With many thanks,
Pierre
*Rest of config file*
THIS E-MAIL MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED INFORMATION.
IF YOU ARE NOT THE INTENDED RECIPIENT (OR HAVE RECEIVED THIS E-MAIL
IN ERROR) PLEASE NOTIFY THE SENDER IMMEDIATELY AND DESTROY THIS
E-MAIL. ANY UNAUTHORISED COPYING, DISCLOSURE OR DISTRIBUTION OF THE
MATERIAL IN THIS E-MAIL IS STRICTLY FORBIDDEN.
IN ACCORDANCE WITH MIFID II RULES ON INDUCEMENTS, THE FIRM'S EMPLOYEES
MAY ATTEND CORPORATE ACCESS EVENTS (DEFINED IN THE FCA HANDBOOK AS
"THE SERVICE OF ARRANGING OR BRINGING ABOUT CONTACT BETWEEN AN INVESTMENT
MANAGER AND AN ISSUER OR POTENTIAL ISSUER"). DURING SUCH MEETINGS, THE
FIRM'S EMPLOYEES MAY ON NO ACCOUNT BE IN RECEIPT OF INSIDE INFORMATION
(AS DESCRIBED IN ARTICLE 7 OF THE MARKET ABUSE REGULATION (EU) NO 596/2014).
(https://www.handbook.fca.org.uk/handbook/glossary/G3532m.html<https://www.handbook.fca.org.uk/handbook/glossary/G3532m.html>)
COMPANIES WHO DISCLOSE INSIDE INFORMATION ARE IN BREACH OF REGULATION
AND MUST IMMEDIATELY AND CLEARLY NOTIFY ALL ATTENDEES. FOR INFORMATION
ON THE FIRM'S POLICY IN RELATION TO ITS PARTICIPATION IN MARKET SOUNDINGS,
PLEASE SEE
https://www.horizon-asset.co.uk/market-soundings/<https://www.horizon-asset.co.uk/market-soundings/>.
HORIZON ASSET LLP IS AUTHORISED AND REGULATED
BY THE FINANCIAL CONDUCT AUTHORITY.
<#theModel_RDFS> a ja:InfModel ;
ja:baseModel <#theGraph> ;
ja:reasoner [
ja:reasonerURL
<http://jena.hpl.hp.com/2003/RDFSExptRuleReasoner<http://jena.hpl.hp.com/2003/RDFSExptRuleReasoner>>
] ;
.
<#theGraph> rdf:type tdb2:GraphTDB ;
tdb2:dataset :theTDB2Dataset .
:theTDB2Dataset
a tdb2:DatasetTDB2 ;
tdb2:location "C:\\dev\\apache-jena-fuseki-3.10.0\\run/databases/Conference1" ;
tdb2:unionDefaultGraph true.
-----Original Message-----
From: Pierre Grenon
Sent: 19 July 2019 17:48
To: 'users@jena.apache.org'
Subject: Combining inferences from GRR and RDFS or OWL reasoner
Hello,
(I apologise for I am not sure if this has been addressed before and I have
not found the right thread or documentation.)
The configuration file below seems to allow reasoning with either a GRR or
an out of the box reasoner on the same dataset.
However, I don't think it allows combining inferences from both reasoners at
the same time. I am not sure how to achieve this through configuration.
(Happy to provide an example of data and rule for the GRR. I've noticed this
when adding a rule to classify undeclared individuals, i.e., individuals
appearing in the subject position of a triple. The rule to the effect that if
they do, they are instances of a class A. It is possible to derive the
instantiation. However, it is not possible to combine it with type inheritance
from a reasoner. If class A is a subclass of class B, there is no inference to
the
effect that the individual is also an instance of class B.)
With many thanks and kind regards,
Pierre
-----
@prefix : <http://base/#> .
@prefix rdf:
<http://www.w3.org/1999/02/22-rdf-syntax-ns#<http://www.w3.org/1999/02/22-rdf-syntax-ns#>>
.
@prefix tdb2:
<http://jena.apache.org/2016/tdb#<http://jena.apache.org/2016/tdb#>> .
@prefix ja:
<http://jena.hpl.hp.com/2005/11/Assembler#<http://jena.hpl.hp.com/2005/11/Assembler#>>
.
@prefix rdfs:
<http://www.w3.org/2000/01/rdf-schema#<http://www.w3.org/2000/01/rdf-schema#>> .
@prefix fuseki:
<http://jena.apache.org/fuseki#<http://jena.apache.org/fuseki#>> .
:theService a fuseki:Service ;
rdfs:label "Service with update and query to test minimal
dataset with inference using an instance of generic rule reasoner and
RDFSExptRuleReasoner" ;
fuseki:dataset :theDataset ;
#:tdb_dataset_readwrite ;
fuseki:name "Conference2" ;
fuseki:serviceQuery "query" , "sparql" ;
fuseki:serviceReadGraphStore "get" ;
fuseki:serviceReadWriteGraphStore
"data" ;
fuseki:serviceUpdate "update" ;
fuseki:serviceUpload "upload" .
:theDataset a ja:RDFDataset ;
ja:defaultGraph <#theUnionModel>
.
<#theUnionModel> a ja:UnionModel ;
ja:rootModel <#theRootModel> ;
ja:subModel <#theModel_GRR> , <#theModel_RDFS> .
<#theRootModel> a ja:Model ;
ja:baseModel <#theGraph> ;
.
<#theModel_GRR> a ja:InfModel ;
ja:baseModel <#theGraph> ;
ja:reasoner [
ja:reasonerURL
<http://jena.hpl.hp.com/2003/GenericRuleReasoner<http://jena.hpl.hp.com/2003/GenericRuleReasoner>>
;
ja:rulesFrom <file:///C:/dev/apache-jena-fuseki-
3.10.0/data/conference/conference1.rules>
] ;
.
