Re: Ontology Imports

[Lorenz B.]

Good catch!

As Adam pointed out, you're using the read() method with a wrong second
argument, i.e. when you use

model.read(String url,
   String base)

the second argument is the base IRI. What you probably want is to use
the read() method with three arguments having the signature

model.read(String url,
   String base,
   String lang)

and the language beeing the third argument:

model.read("http://example.com/ExampleOntology.owl;, null, "TURTLE");

See Javadoc [1] for more information.

[1]
https://jena.apache.org/documentation/javadoc/jena/org/apache/jena/rdf/model/Model.html#read-java.io.InputStream-java.lang.String-

> I cannot find a method read(InputStream stream, String Lang) on Model (from 
> which OntModel inherits its "read" methods). Are you by chance using 
> read(InputStream in, String base), which is a very different semantic?
>
> ---
> A. Soroka
> The University of Virginia Library
>
>> On Mar 31, 2017, at 2:38 PM, Donald Smith  wrote:
>>
>> RDFDataMgr does fine while loading a given RDF file, but what I'm trying to 
>> do is to use OntModel to read an ontology from local disk which would intern 
>> fetch the imported ontologies. For any imported ontology that is fetched via 
>> HTTP that is returned as RDF/XML works fine. For any imported ontology that 
>> is of any other type, such as turtle, it fails.
>>
>> Does OntModel.read(InputStream stream, String Lang) not use RDFDataMgr 
>> itself to load imported ontologies?
>>
>> -Original Message-
>> From: Dave Reynolds [mailto:dave.e.reyno...@gmail.com]
>> Sent: Thursday, March 30, 2017 2:57 AM
>> To: users@jena.apache.org
>> Subject: Re: Ontology Imports
>>
>> On 29/03/17 20:54, Donald Smith wrote:
>>> Given I have an ontology that imports one or more other ontologies, when I 
>>> read that ontology:
>>>
>>> model.read("http://example.com/ExampleOntology.owl;, "TURTLE");
>> That should be "Turtle" or, better, RDFLanguages.strLangTurtle or better 
>> still use RDFDataMgr and let it work out the language.
>>
>> Dave
>> --- Confidentiality Notice: 
>> This electronic mail transmission is confidential, may be privileged and 
>> should be read or retained only by the intended recipient. If you have 
>> received this transmission in error, please immediately notify the sender 
>> and delete it from your system.
>
>
-- 
Lorenz Bühmann
AKSW group, University of Leipzig
Group: http://aksw.org - semantic web research center

Re: [!!Mass Mail]Re: Ontology Imports

[Donald Smith]

Thanks for helping. Let me get an example in place that demonstrates what I'm 
seeing.

> On Apr 2, 2017, at 10:15 AM, Andy Seaborne  wrote:
>
>
>
>> On 31/03/17 23:53, Martynas Jusevičius wrote:
>> Some of the code (at least OntDocumentManager) is still using
>> FileManager I believe.
>
> It does go through to RIOT -
>
> org.apache.jena.riot.lang.LangRDFXML.parse
>
> is on the stacktrace.
>
> But "http://example.com/ExampleOntology.owl; is an HTML page generated by 
> example.com for the 404.
>
> If http://example.com/ExampleOntology.owl is in the document manage cache, 
> the code may be confused and using ".owl" as the syntax indicator (that gets 
> to RDF/XML).
>
> Or it may be processing the HTML 404 error page and "Content-Type: text/html" 
> is taken as definitive.
>
>Andy
>
>>
>> The proper way IMO is to have a location-mapping and read ontology
>> (namespace) URI, not physical file URIs, and let LocationMapper take
>> care of the rest.
>> https://jena.apache.org/documentation/notes/file-manager.html
>>
>>> On Fri, Mar 31, 2017 at 8:38 PM, Donald Smith  
>>> wrote:
>>> RDFDataMgr does fine while loading a given RDF file, but what I'm trying to 
>>> do is to use OntModel to read an ontology from local disk which would 
>>> intern fetch the imported ontologies. For any imported ontology that is 
>>> fetched via HTTP that is returned as RDF/XML works fine. For any imported 
>>> ontology that is of any other type, such as turtle, it fails.
>>>
>>> Does OntModel.read(InputStream stream, String Lang) not use RDFDataMgr 
>>> itself to load imported ontologies?
>>>
>>> -Original Message-
>>> From: Dave Reynolds [mailto:dave.e.reyno...@gmail.com]
>>> Sent: Thursday, March 30, 2017 2:57 AM
>>> To: users@jena.apache.org
>>> Subject: Re: Ontology Imports
>>>
 On 29/03/17 20:54, Donald Smith wrote:

 Given I have an ontology that imports one or more other ontologies, when I 
 read that ontology:

 model.read("http://example.com/ExampleOntology.owl;, "TURTLE");
>>>
>>> That should be "Turtle" or, better, RDFLanguages.strLangTurtle or better 
>>> still use RDFDataMgr and let it work out the language.
>>>
>>> Dave
>>> --- Confidentiality Notice: 
>>> This electronic mail transmission is confidential, may be privileged and 
>>> should be read or retained only by the intended recipient. If you have 
>>> received this transmission in error, please immediately notify the sender 
>>> and delete it from your system.
--- Confidentiality Notice: 
This electronic mail transmission is confidential, may be privileged and should 
be read or retained only by the intended recipient. If you have received this 
transmission in error, please immediately notify the sender and delete it from 
your system.

Re: Ontology Imports

[Andy Seaborne]

On 31/03/17 23:53, Martynas Jusevičius wrote:

Some of the code (at least OntDocumentManager) is still using
FileManager I believe.


It does go through to RIOT -

org.apache.jena.riot.lang.LangRDFXML.parse

is on the stacktrace.

But "http://example.com/ExampleOntology.owl; is an HTML page generated 
by example.com for the 404.


If http://example.com/ExampleOntology.owl is in the document manage 
cache, the code may be confused and using ".owl" as the syntax indicator 
(that gets to RDF/XML).


Or it may be processing the HTML 404 error page and "Content-Type: 
text/html" is taken as definitive.


Andy



The proper way IMO is to have a location-mapping and read ontology
(namespace) URI, not physical file URIs, and let LocationMapper take
care of the rest.
https://jena.apache.org/documentation/notes/file-manager.html

On Fri, Mar 31, 2017 at 8:38 PM, Donald Smith  wrote:

RDFDataMgr does fine while loading a given RDF file, but what I'm trying to do 
is to use OntModel to read an ontology from local disk which would intern fetch 
the imported ontologies. For any imported ontology that is fetched via HTTP 
that is returned as RDF/XML works fine. For any imported ontology that is of 
any other type, such as turtle, it fails.

Does OntModel.read(InputStream stream, String Lang) not use RDFDataMgr itself 
to load imported ontologies?

-Original Message-
From: Dave Reynolds [mailto:dave.e.reyno...@gmail.com]
Sent: Thursday, March 30, 2017 2:57 AM
To: users@jena.apache.org
Subject: Re: Ontology Imports

On 29/03/17 20:54, Donald Smith wrote:


Given I have an ontology that imports one or more other ontologies, when I read 
that ontology:

model.read("http://example.com/ExampleOntology.owl;, "TURTLE");


That should be "Turtle" or, better, RDFLanguages.strLangTurtle or better still 
use RDFDataMgr and let it work out the language.

Dave
--- Confidentiality Notice: 
This electronic mail transmission is confidential, may be privileged and should 
be read or retained only by the intended recipient. If you have received this 
transmission in error, please immediately notify the sender and delete it from 
your system.

Re: Fuseki prefixes

[Andy Seaborne]

Hi Chris,

Your right.  Apparently, I don't know how to call grep correctly!

Andy

On 02/04/17 14:58, Chris Tomlinson wrote:

Andy,

In at least one configuration qonsole-config.js is loaded.

We’re using fuseki.war from apache-jena-fuseki-2.5.0.tar.gz in Tomcat 8 and we 
update the qoncole-config.js in tomcat/webapps/fuseki/js/app/ with the various 
prefixes used in our application. In this configuration it is loaded in the 
query tab.

Chris



On Apr 2, 2017, at 5:20 AM, Andy Seaborne  wrote:


Is qonsole-config.js evenloaded? It comes from qonsole which the UI does not 
currently use [*].

Re: Ontology Imports

[A. Soroka]

I cannot find a method read(InputStream stream, String Lang) on Model (from 
which OntModel inherits its "read" methods). Are you by chance using 
read(InputStream in, String base), which is a very different semantic?

---
A. Soroka
The University of Virginia Library

> On Mar 31, 2017, at 2:38 PM, Donald Smith  wrote:
> 
> RDFDataMgr does fine while loading a given RDF file, but what I'm trying to 
> do is to use OntModel to read an ontology from local disk which would intern 
> fetch the imported ontologies. For any imported ontology that is fetched via 
> HTTP that is returned as RDF/XML works fine. For any imported ontology that 
> is of any other type, such as turtle, it fails.
> 
> Does OntModel.read(InputStream stream, String Lang) not use RDFDataMgr itself 
> to load imported ontologies?
> 
> -Original Message-
> From: Dave Reynolds [mailto:dave.e.reyno...@gmail.com]
> Sent: Thursday, March 30, 2017 2:57 AM
> To: users@jena.apache.org
> Subject: Re: Ontology Imports
> 
> On 29/03/17 20:54, Donald Smith wrote:
>> 
>> Given I have an ontology that imports one or more other ontologies, when I 
>> read that ontology:
>> 
>> model.read("http://example.com/ExampleOntology.owl;, "TURTLE");
> 
> That should be "Turtle" or, better, RDFLanguages.strLangTurtle or better 
> still use RDFDataMgr and let it work out the language.
> 
> Dave
> --- Confidentiality Notice: 
> This electronic mail transmission is confidential, may be privileged and 
> should be read or retained only by the intended recipient. If you have 
> received this transmission in error, please immediately notify the sender and 
> delete it from your system.

Re: Fuseki prefixes

[Chris Tomlinson]

Andy,

In at least one configuration qonsole-config.js is loaded.

We’re using fuseki.war from apache-jena-fuseki-2.5.0.tar.gz in Tomcat 8 and we 
update the qoncole-config.js in tomcat/webapps/fuseki/js/app/ with the various 
prefixes used in our application. In this configuration it is loaded in the 
query tab.

Chris


> On Apr 2, 2017, at 5:20 AM, Andy Seaborne  wrote:
> 
> 
> Is qonsole-config.js evenloaded? It comes from qonsole which the UI does not 
> currently use [*].

Re: persistent inference on named graphs in Fuseki

[A. Soroka]

Datasets are covered very nicely in the RDF core recommendations:

https://www.w3.org/TR/rdf11-concepts/#section-dataset

---
A. Soroka
The University of Virginia Library

> On Apr 2, 2017, at 5:38 AM, Dave Reynolds  wrote:
> 
> On 02/04/17 10:25, Laura Morales wrote:
 - no inference over the whole graph, only inference on a single graph
>>> 
>>> No inference support over the whole *Dataset*.
>> 
>> "whole graph" I mean 2 or more graphs loaded into the server, that together 
>> make a larger graph. Isn't this the same thing as "dataset"? Or am I missing 
>> something?
>> 
> 
> A Dataset is a collection of graph comprising one default graph and zero or 
> more named graphs.
> 
> The default graph in a dataset may be completely distinct from the named 
> graphs or may contain some precomputed combination of them or (e.g. with TDB 
> union default) you can arrange for the default graph to give the appearance 
> of being the union of all the triples in all the named graphs. These are all 
> choices, the notion of a dataset doesn't enforce any particular 
> implementation for the default graph
> 
> My point is that Jena's rule-based inference engines don't know anything 
> about datasets, just about graphs.
> 
> However, you can point an inference engine at any graph in TDB including the 
> union graph (either by using union default and pointing to the default graph 
> or by pointing to the pseudo named graph urn:x-arq:UnionGraph). Then you are 
> indeed performing inference over the union of the data it's just that the 
> inference engine doesn't know that or care.
> 
> Dave
> 

Re: Fuseki prefixes

[Claude Warren]

Sorry for the confusion, yes it is in the UI that I want to add the
prefixes.

we = my development team + customer.

Customer adds data to a graph, enhancing data produced by the application.
They can specify any namespace they wish for the enhancing data.

I want to collect those namespaces (for simplicity assume that each
namespace is only associated with one prefix) and modify the fuseki query
page to present the prefixes to the user in order to reduce the complexity
of typing queries.

if the qonsole-config.js is not used where does the UI load the default
prefixes that it displays on startup?

Claude


On Sun, Apr 2, 2017 at 11:20 AM, Andy Seaborne  wrote:

> Claude,
>
> Do you mean prefixes in the UI?
>
> At one point you seem to be talking about sending the query by API.
>
> On 01/04/17 12:20, Claude Warren wrote:
>
>> I see that the qonsole-config.js where the prefixes for the queries is
>> defined.
>>
>
> Is qonsole-config.js evenloaded? It comes from qonsole which the UI does
> not currently use [*].
>
> However, I want to know if there is a configuration option that
>> would allow me to change the list without modification of the source code.
>>
>
> For the UI, no.
>
> Specifically we have a data-driven problem whereby the prefixes are not
>> known until query time.  Is there a method that will allow us to set them
>> for the fuseki queries?
>>
>
> So changing the prefixes used by the UI aren't going to help anyway.
>
> (who is "we"?)
>
> A mechanism to gather prefixes over time and persist them would be
>> sufficient I think, provided we could add prefixes programatically.
>>
>
> This bit makes me think it is not about the UI.
> If programmatically is involved, what's the relationship to the UI?
>
> All queries are self-contained with PREFIX on the front.
>
> yasqe makes the query sticky so the prefixes are sticky.
>
> No UI can be universal to all use cases - maybe you need to have your own
> with features that are specific to your needs. Maybe some features turn out
> to be sufficiently general to migrate to the open source code.
>
>
>> Claude
>>
>>
>
> [*] I'd like to see qonsole return - first as an alternative "query2"
> interface, along side the "query" tab.
>
> The storage-sticky yasqe query pane is nice. My usage is as a dev-admin is
> to jump from dataset to dataset though and its stickiness is at best no
> help and needs to be avoided.  I'd like a query UI that is more neutral to
> the dataset. A browser-side history mechanism would be really helpful.
>



-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren

Re: Config file for standalone Fuseki server

[Andy Seaborne]

On 02/04/17 09:26, Laura Morales wrote:

My question is: how do I specify the "--port" and "--localhost" parameters in 
the config file?


That isn't possible.  Port and locking to the localhost interface are 
aspects of the jetty server and that starts up before the Fuseki 
servlets/webapp runs at all.


You can run Fuseki as a WAR file in Tomcat (etc).  That would mean the 
tomcat server, and it's pot and the network interface it responses to, 
are already and externally decided.


Standalone is using Jetty as the webapp framework, otherwise the code is 
the same.


When in production on, say AWS, there are other, better ways to get the 
"localhost" effect.  Cloud/AM services allow the ports to be locked down 
in a much more robust way.


Andy

Re: How to load RDF dump

[Andy Seaborne]

On 02/04/17 02:50, Stian Soiland-Reyes wrote:

You can either use jena distribution's tdbloader script into the folder
"db" (but stop fuseki first), or if the nt file is small enough (e.g. 50
MB) then you can also upload it in the browser interface (but make sure you
run fuseki 2 for this).


Or programmatically upload it with the "s-post" script.

Or use curl or wget.

Just POST to the dataset URL (http://host:/db) with the correct MIME 
type.


Andy



If you run Linux and "dB" is blank, then tdbloader2 can be faster for very
large files.

On 1 Apr 2017 10:21 pm, "Laura Morales"  wrote:


I've downloaded Fuseki and I'm running it as a standalone server

./fuseki-server --loc=db --port  --localhost --timeout=1 /db

now... what's the correct way to load an RDF dump (.nt file) into Fuseki?

Re: Fuseki prefixes

[Andy Seaborne]

Claude,

Do you mean prefixes in the UI?

At one point you seem to be talking about sending the query by API.

On 01/04/17 12:20, Claude Warren wrote:

I see that the qonsole-config.js where the prefixes for the queries is
defined.


Is qonsole-config.js evenloaded? It comes from qonsole which the UI does 
not currently use [*].



However, I want to know if there is a configuration option that
would allow me to change the list without modification of the source code.


For the UI, no.


Specifically we have a data-driven problem whereby the prefixes are not
known until query time.  Is there a method that will allow us to set them
for the fuseki queries?


So changing the prefixes used by the UI aren't going to help anyway.

(who is "we"?)


A mechanism to gather prefixes over time and persist them would be
sufficient I think, provided we could add prefixes programatically.


This bit makes me think it is not about the UI.
If programmatically is involved, what's the relationship to the UI?

All queries are self-contained with PREFIX on the front.

yasqe makes the query sticky so the prefixes are sticky.

No UI can be universal to all use cases - maybe you need to have your 
own with features that are specific to your needs. Maybe some features 
turn out to be sufficiently general to migrate to the open source code.




Claude




[*] I'd like to see qonsole return - first as an alternative "query2" 
interface, along side the "query" tab.


The storage-sticky yasqe query pane is nice. My usage is as a dev-admin 
is to jump from dataset to dataset though and its stickiness is at best 
no help and needs to be avoided.  I'd like a query UI that is more 
neutral to the dataset. A browser-side history mechanism would be really 
helpful.

Re: persistent inference on named graphs in Fuseki

[Dave Reynolds]

On 02/04/17 10:25, Laura Morales wrote:

- no inference over the whole graph, only inference on a single graph


No inference support over the whole *Dataset*.


"whole graph" I mean 2 or more graphs loaded into the server, that together make a larger 
graph. Isn't this the same thing as "dataset"? Or am I missing something?



A Dataset is a collection of graph comprising one default graph and zero 
or more named graphs.


The default graph in a dataset may be completely distinct from the named 
graphs or may contain some precomputed combination of them or (e.g. with 
TDB union default) you can arrange for the default graph to give the 
appearance of being the union of all the triples in all the named 
graphs. These are all choices, the notion of a dataset doesn't enforce 
any particular implementation for the default graph


My point is that Jena's rule-based inference engines don't know anything 
about datasets, just about graphs.


However, you can point an inference engine at any graph in TDB including 
the union graph (either by using union default and pointing to the 
default graph or by pointing to the pseudo named graph 
urn:x-arq:UnionGraph). Then you are indeed performing inference over the 
union of the data it's just that the inference engine doesn't know that 
or care.


Dave

Re: persistent inference on named graphs in Fuseki

[Laura Morales]

>> - no inference over the whole graph, only inference on a single graph
>
> No inference support over the whole *Dataset*.

"whole graph" I mean 2 or more graphs loaded into the server, that together 
make a larger graph. Isn't this the same thing as "dataset"? Or am I missing 
something?

Re: persistent inference on named graphs in Fuseki

[Dave Reynolds]

On 02/04/17 09:31, Laura Morales wrote:

There's no built in support for inference over a dataset as a
whole. There's no support for rules which test which graph a triple is
in or which assert results into difference graphs etc.


- no inference over the whole graph, only inference on a single graph


No inference support over the whole *Dataset*.


- no support to test which graph a triple is in

Is this by design, or are there technical limitations to not have these, or 
simply nobody has implemented them yet?


The latter. The inference system was designed before Sparql and Datasets 
and named graphs existed. Over the years Datasets, rather than single 
Graphs, have been the central concept for a lot of RDF processing and if 
you were designing an inference system now you would take that into account.


Dave

Re: persistent inference on named graphs in Fuseki

[Dave Reynolds]

On 02/04/17 10:04, Élie Roux wrote:

Hello,


Jena's inference is purely in memory so running over a TDB store is
possible but doesn't give you any scalability and is slower than
running over an in-memory copy of the same data. Plus, as you already
know, it's not named-graphs-aware.


Thank you for your clarifying answer! I really think this should be made
clear somewhere in the documentation, as it would have saved us a few
days of tests trying to understand why fuseki didn't behave as we
expected...


Sorry about that!


also maybe a few warning or error messages when fuseki reads
the docs and sees inference on tdb or unionDefaultGraph?


It should be possible to create an inference graph over TDB with union 
default (that's my option 2) so there's no need for a warning. It's 
"just" that performance may be poor and the inference results won't be 
persisted.


Not sure why it wasn't working for you.


Assuming modest data sizes and static data then you could either:


Well, it's fairly large (a few million triples) and very dynamic... but
we ended up with the following solution, I explain it here in case it
can help people with the same needs:

In the code that transfers data to fuseki, we run a reasoner and add the
inferred triples in the corresponding named graph, and then transfer all
the triples (our data + inferred) to fuseki which stores it into TDB.
This is doable for us because we only need limitted forward chaining
inference that doesn't cross named graphs, but this would certainly not
work for very large inferences such as the OWL full reasoner across the
union graph...


Sounds like option 1, glad you have something working.

Dave

Re: persistent inference on named graphs in Fuseki

[Élie Roux]

Hello,

> Jena's inference is purely in memory so running over a TDB store is
> possible but doesn't give you any scalability and is slower than
> running over an in-memory copy of the same data. Plus, as you already
> know, it's not named-graphs-aware.

Thank you for your clarifying answer! I really think this should be made
clear somewhere in the documentation, as it would have saved us a few
days of tests trying to understand why fuseki didn't behave as we
expected... also maybe a few warning or error messages when fuseki reads
the docs and sees inference on tdb or unionDefaultGraph? Because right
now it just silently misbehave, which is quite painful for users...

> Assuming modest data sizes and static data then you could either:

Well, it's fairly large (a few million triples) and very dynamic... but
we ended up with the following solution, I explain it here in case it
can help people with the same needs:

In the code that transfers data to fuseki, we run a reasoner and add the
inferred triples in the corresponding named graph, and then transfer all
the triples (our data + inferred) to fuseki which stores it into TDB.
This is doable for us because we only need limitted forward chaining
inference that doesn't cross named graphs, but this would certainly not
work for very large inferences such as the OWL full reasoner across the
union graph...

Thank you,
-- 
Elie

Re: persistent inference on named graphs in Fuseki

[Laura Morales]

> There's no built in support for inference over a dataset as a
> whole. There's no support for rules which test which graph a triple is
> in or which assert results into difference graphs etc.

- no inference over the whole graph, only inference on a single graph
- no support to test which graph a triple is in

Is this by design, or are there technical limitations to not have these, or 
simply nobody has implemented them yet?

Re: persistent inference on named graphs in Fuseki

[Dave Reynolds]

On 02/04/17 09:18, Laura Morales wrote:

Plus, as you already know, it's not named-graphs-aware.


what does this mean?



The rule-based inference engines only know about Graphs/Models, not 
Datasets. There's no built in support for inference over a dataset as a 
whole. There's no support for rules which test which graph a triple is 
in or which assert results into difference graphs etc.


Dave

Config file for standalone Fuseki server

[Laura Morales]

So far I've always started Fuseki like this

$ ./fuseki-server --loc=db --port  --localhost --timeout=1 /db

but I'm trying to setup a config file such that I no longer have to type in all 
those arguments.
This is my config so far:
 
@prefix fuseki:   .
@prefix rdf:  .
@prefix rdfs:     .
@prefix tdb:  .
@prefix ja:   .
@prefix :    <#> .

<#service1> rdf:type fuseki:Service ;
    fuseki:name    "db" ;
    fuseki:serviceQuery    "sparql" ;
    fuseki:serviceQuery    "query" ;
    # fuseki:serviceUpdate "update" ;
    # fuseki:serviceUpload "upload" ;
    #fuseki:serviceReadWriteGraphStore "data" ;
    # A separate read-only graph store endpoint:
    fuseki:serviceReadGraphStore   "get" ;
    fuseki:dataset     <#dataset> ;
<#dataset> rdf:type tdb:DatasetTDB ;
    tdb:location "/home/myself/db" ;
    # Query timeout on this dataset (1s, 1000 milliseconds)
    ja:context [ ja:cxtName "arq:queryTimeout" ;  ja:cxtValue "1" ] ;
    # Make the default graph be the union of all named graphs.
    tdb:unionDefaultGraph true ;

My question is: how do I specify the "--port" and "--localhost" parameters in 
the config file?

Re: persistent inference on named graphs in Fuseki

[Laura Morales]

> Plus, as you already know, it's not named-graphs-aware.

what does this mean?

Re: persistent inference on named graphs in Fuseki

[Dave Reynolds]

[Sorry to be slow to respond, I was hoping someone who understands 
assemblers might take this.]


On 31/03/17 08:10, Élie Roux wrote:

Hello,

I am currently setting up a Fuseki server with the following specs in mind:
 - everything persistent in TDB (it works)
 - many different named graph, with the default graph being the union of
them (it works, but without inference)
 - very simple inferencing (works but not with named graphs)
 - inferenced triples stored in TDB

 The first question is the following: is it realistic?


Sorry, not really.

Whether it's practical at all depends on the size of your data and how 
dynamic it is.


Jena's inference is purely in memory so running over a TDB store is 
possible but doesn't give you any scalability and is slower than running 
over an in-memory copy of the same data. Plus, as you already know, it's 
not named-graphs-aware.


Assuming modest data sizes and static data then you could either:

1. Have all your base data in named graphs in TDB. Externally run a 
reasoner over the union of that data (either raw from the TDB or by 
materializing an in-memory copy of the union). Then materialize all the 
inferred triples add them as another graph in the TDB - either directly 
to the TDB before you run fuseki or via fuseki using the graph API.


2. Set up the inference as a separate in-memory dataset within Fuseki 
which reasons over the union of your TDB graphs and provides a view of 
that union + inferences but doesn't store the results back into TDB.


Option 1 means using some external process to do the inference and is no 
use if your data is dynamic. However, for static data is does mean that 
once the data has been created you can query at full speed without 
inference slow downs and you can restart fuseki without losing anything.


Option 2 avoids the need for external processing but will be slow to 
start up (the inferences aren't being persisted) and slow to query (some 
inferences will performed on-demand). Sadly it wouldn't support dynamic 
data either. You could submit changes to the in-memory inference graph 
but when it tries to store those into the base model that will fail 
because it's a union instead of an actual graph. You could submit 
changes to the TDB store but the in-memory inference won't notice those 
automatically and you would have to restart fuseki to see them.


Dave