RE: Fuskei2 configuration, TDB2 data, Inferencing with ontologies, Persisting named graphs upon server restart

[Pierre Grenon <pg...@horizon-asset.co.uk>]

Hi Andy,

picking up the prefatory questions first, in line below.

> Hi Pierre,
>
> A few points to start with:
>
> 1/ For my general understanding of how we might take the inferene
> provision further in jena, what inferences are you particularly
> interested in?

I noticed you like to ask :) I'm not sure what level of details is useful so it'd probably be more informative to have some sort of sticky thread about that or a poll if you know how to categorise what would be useful to know.

In the present context, ANY inference is good over writing specific SPARQL look up queries.

The present context is:
- a few small OWL ontologies where the most complicated axioms are various class restrictions and property chains
- some amount of rather qualitative data (pizzas and toppings kind of things) with a lot of n-ary relations reification and where basic ontology traversal combining predicate composition and transitivity is useful
- some large amount of quantitative data for which the main problems are i) navigating reified relations and ii) aggregating quantities but I'm not sure that second use case is inferencing rather than some form of computation
- some pervasive reliance on labels with queries where some variables are labels
- a lot of the data is temporal too (one of the reasons for reification and for named graphs)

So as a first answer, in this context, at this stage, transitivity and RDFS type of inference are a very minimum. (Although, rdfs:domain type of inference is not really desired because these are better interpreted as constraints and SHACL might be preferred for handling this.) This bare minimum is just to be able to query with a hierarchy of predicates, for example. Another typical use case is class instantiation and subsumption (so again, rdfs:subPropertyOf and rdfs:subClassOf being transitive...) This is usually not enough and OWL property chains are useful.

At another stage, backward and/or forward rules but I don't have clear use cases in mind at this point in this context.


> 2/ It is not possible in an assembler/Fuseki configuration file, to
> create a new named graph and have a another inference graph put around
> that new graph at runtime.

I will follow up on this further down the threads.

> 3/ The union graph can't be updated. It's a read-only union.

I'm not sure what this means. It can't add new graphs to the union?
Also more below re. Attempt 1 question.

> 4/ "ERROR Exception in initialization: caught: Not in tramsaction"
> Do you have the stacktrace for this?

I saw you found it -- yes, typo, sorry, I typed the error message before pasting the whole trace.

Noted the bug. Not sure that would make the config do it's intended job though.


> Inline questions about attempt 1.
>
> Andy

<...>

> > Outcome: This allows me to load data into named graphs and to perform inferemce. However, it does not persist upon restarting the server.
>
> Did you enable tdb:unionDefaultGraph as well, load the named graph and
the access the union?

Here I might be confused. Documentation says to either use union graph or update but not both, is that because of the static character of the union graph? I haven't realised that there is any issue having both, i.e., have an update service where the TDB2 dataset is defaultUnionGraph true.

I *think* I tried both. I'm not sure it changed anything to the behaviour I was trying to check (i.e., persistence of named graphs created with SPARQL update).

My basic process is:

1. Terminal$ fuseki-server
2. Run bunch of: LOAD <myfile> INTO <myNamedGraph>
3. Query triples in union graph or {GRAPH <myNamedGraph> {?i ?like ?trains}}.
4. Terminal$ CTRL+C CTRL+C Y
5. Terminal$ fuseki-server
6. Query triples in union graph or {GRAPH <myNamedGraph> {?i ?like ?trains}}.


> What isn't persisted? Inferences or base data?

This is about the data stored in the named graph during 2.

When I have a single TDB2 dataset with no inference engine in my configuration file:
3 succeeds and 6 succeeds

The data is persisted, including in named graphs.

When I also have a set up for an inference engine in my configuration file,
3 succeeds and 6 fails.

I'm not entirely sure I managed to explain myself very clearly. But hope this helps.

Also, I will probably try to redo everything I have done to better address your questions. I will follow up down the thread on 2/ as I think some clarity is needed on the named graphs. I have tried naming graphs in the configuration file but this didn't seem to help, however, I think I wasn't linking to the inference model. SO I'll follow up on this and try to provide clear config examples for that.

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.