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.
