On 15/04/16 21:41, Woodward, Arthur E CTR (US) wrote:
Thank you all for your help with this. You've clarified a good bit for me in 
terms of Jena and Fuseki's inner workings. Just to confirm what you are saying.

It would be possible to take two persistent graphs, combine them into a single 
in-memory graph, run a in-memory reasoner over that graph, and then perform 
queries through this reasoner. These graph combinations and reasoners wouldn't 
be persistent, but that may actually be a boon for our use case. This type of 
functionality isn't supported by the assembly language, and in order to achieve 
those goals I would be looking at writing java classes to handle the necessary 
transforms.

Am I correct in this summary?

Pretty much.

When combining the graphs you do have the option to create a dynamic union of them - which doesn't copy the data into memory. However, given the way the reasoners make lots of small queries then materializing the union in memory may be higher performance.

Would there be a way to inject this custom work-flow back into Fuseki, or would 
this be a use-case more tailored to Jena without the front-end?

It is possible to plug things into Fuseki (e.g. create a new dataset implementation to support your use case, write assembler support for it and use the ability to dynamically load code from an assembler to add that support to a fuseki instance).

However, (a) that's a fair amount of work and (b) it's not clear to me how you are going to specify which graphs are going to be in your dynamic unions - you may be thinking of some custom API for this, which wouldn't just plug in via an assembler.

My advice would be to get this working in some simple form, directly over TDB first. Check out if it actually meets your needs. If it does you look at different ways of creating a server to support it. I think it should be possible to run fuseki as a servlet within a larger web application which may be one way to go. [I've done that with fuseki 1 some time ago, not looked at the structure of fuseki 2 in enough detail to know how easy that would be.]

Dave

________________________________________
From: Dave Reynolds [[email protected]]
Sent: Thursday, April 14, 2016 8:00 PM
To: [email protected]
Subject: [Non-DoD Source] Re: Fuseki issue - Reasoner over Unioned Graph

All active links contained in this email were disabled.  Please verify the 
identity of the sender, and confirm the authenticity of all links contained 
within the message prior to copying and pasting the address to a Web browser.




----

On 14/04/16 20:35, Jonathan Camilleri wrote:
What is a unionized graph, is it a graph that joins two data sets which are
common in set theory?

Yes. An RDF graph is a set of RDF triples (in the set theoretic sense),
a union graph is a union of those triple sets.

Dave

On 28 March 2016 at 19:46, Woodward, Arthur E CTR (US) <
[email protected]> wrote:

Hello Users,



I have been having difficulty finding a solution to the problem of
building a modular system for ontological query expansion in Fuseki.



My goal is to be able to run a query over a unionized default graph, while
maintaining the ability to edit the individual named graphs either from the
same dataset or a different dataset.



I have tried many variations of the Fuseki assembler, and after combing
through the documentation and previous e-mails I believe I have constructed
an assembler specification that should be working, but it is not. From an
e-mail by Rohana Rajapakse on Jan 24, 2014 1:52 am it was indicated that a
structure like the one in my file below should allow for an inference
engine to be run over a unionized default graph.



Data added via Fuseki GUI::

DID NOT WORK

Dataset -- Data

Graphs -- default -- (empty, with unionDefaultGraph:true in the Data.ttl
and Reasoner.ttl assembler files)

                Entities --

                              @prefix ex:    <Caution-http://example.org/> .
                              @prefix owl:   
<Caution-http://www.w3.org/2002/07/owl#>
.
                              @prefix rdf:   <
Caution-http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
                              @prefix rdfs:  <
Caution-http://www.w3.org/2000/01/rdf-schema#> .
                              @prefix zoo:   <Caution-http://example.org/zoo/> .



                              ex:dog1  a      ex:animal .

                              ex:cat1  a      ex:cat .

                              ex:zoo1  zoo:host  ex:cat2 .

                              ex:cat3  owl:sameAs  ex:cat2 .



              Ontology --

                              @prefix ex:    <Caution-http://example.org/> .
                              @prefix owl:   
<Caution-http://www.w3.org/2002/07/owl#>
.
                              @prefix rdf:   <
Caution-http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
                              @prefix rdfs:  <
Caution-http://www.w3.org/2000/01/rdf-schema#> .
                              @prefix zoo:   <Caution-http://example.org/zoo/> .



                              ex:cat  rdfs:subClassOf  ex:animal .

                              zoo:host  rdfs:range  ex:animal .

Dataset -- Reasoner

              default - (no manually entered data)



Query -- Run over the Reasoner Dataset

PREFIX ex: <Caution-http://example.org/>
PREFIX owl: <Caution-http://www.w3.org/2002/07/owl#>
PREFIX rdf: <Caution-http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <Caution-http://www.w3.org/2000/01/rdf-schema#>
PREFIX xsd: <Caution-http://www.w3.org/2001/XMLSchema#>
PREFIX : <Caution-http://localhost:3030/Test/data/>
PREFIX http: <Caution-http://www.w3.org/2011/http#>

SELECT ?animal
WHERE {
    ?animal a ex:animal .
}
LIMIT 10



0 Results.



If the data in the "Data" dataset is moved from the named graphs to the
default graph and the unionDefaultGraph:true option is commented out from
the Data.ttl file, and the same query above is run, there are 4 results.

{
    "head": {
      "vars": [ "animal" ]
    } ,
    "results": {
      "bindings": [
        {
          "animal": { "type": "uri" , "value": 
"Caution-http://example.org/dog1"; }
        } ,
        {
          "animal": { "type": "uri" , "value": 
"Caution-http://example.org/cat1"; }
        } ,
        {
          "animal": { "type": "uri" , "value": 
"Caution-http://example.org/cat2"; }
        } ,
        {
          "animal": { "type": "uri" , "value": 
"Caution-http://example.org/cat3"; }
        }
      ]
    }
}



Data.ttl::

        1 @prefix :      <Caution-http://base/#> .
        2 @prefix tdb:   <Caution-http://jena.hpl.hp.com/2008/tdb#> .
        3 @prefix rdf:   <Caution-http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
        4 @prefix ja:    <Caution-http://jena.hpl.hp.com/2005/11/Assembler#> .
        5 @prefix rdfs:  <Caution-http://www.w3.org/2000/01/rdf-schema#> .
        6 @prefix fuseki: <Caution-http://jena.apache.org/fuseki#> .
        7
        8 :service_tdb_all  a                   fuseki:Service ;
        9         rdfs:label                    "TDB Data" ;
       10         fuseki:dataset                :tdb_dataset_readwrite ;
       11         fuseki:name                   "Data" ;
       12         fuseki:serviceQuery           "query" , "sparql" ;
       13         fuseki:serviceReadGraphStore  "get" ;
       14         fuseki:serviceReadWriteGraphStore
       15                 "data" ;
       16         fuseki:serviceUpdate          "update" ;
       17         fuseki:serviceUpload          "upload" .
       18
       19 :tdb_dataset_readwrite
       20         a             tdb:DatasetTDB ;
       21         tdb:location
"/home/evan/Documents/apache-jena-fuseki-2.3.1/run/databases/Data" ;
       22        tdb:unionDefaultGraph true ;
       23         .
       24



Reasoner.ttl::

@prefix :      <Caution-http://base/#> .
        2 @prefix tdb:   <Caution-http://jena.hpl.hp.com/2008/tdb#> .
        3 @prefix rdf:   <Caution-http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
        4 @prefix ja:    <Caution-http://jena.hpl.hp.com/2005/11/Assembler#> .
        5 @prefix rdfs:  <Caution-http://www.w3.org/2000/01/rdf-schema#> .
        6 @prefix fuseki: <Caution-http://jena.apache.org/fuseki#> .
        7
        8 :service1  a                          fuseki:Service ;
        9         fuseki:dataset                :tdb_dataset_readwrite ;
       10         fuseki:name                   "Reasoner" ;
       11         fuseki:serviceQuery           "query" , "sparql" ;
       12         fuseki:serviceReadGraphStore  "get" ;
       13         fuseki:serviceReadWriteGraphStore
       14                 "data" ;
       15         fuseki:serviceUpdate          "update" ;
       16         fuseki:serviceUpload          "upload" .
       17
       18 tdb:GraphTDB rdfs:subClassOf ja:Model .
       19 tdb:DatasetTDB rdfs:subClassOf ja:RDFDataset .
       20
       21 :tdb_dataset_readwrite  a          ja:RDFDataset ;
       22         ja:defaultGraph :model2 ;
       23         ja:namedGraph
       24            [ ja:graphName "Data" ;
       25              ja:graph     :graph ] ;
       26         .
       27
       28 :tdb_intermediate_dataset a tdb:DatasetTDB ;
       29     tdb:location
"/home/evan/Documents/apache-jena-fuseki-2.3.1/run/databases/Data";
       30     tdb:unionDefaultGraph true ;
       31     .
       32
       33 :graph rdf:type tdb:GraphTDB ;
       34     tdb:dataset :tdb_intermediate_dataset
       35     .
       36
       37 :model2 a ja:InfModel ;
       38         ja:reasoner  [ ja:reasonerURL <
Caution-http://jena.hpl.hp.com/2003/OWLFBRuleReasoner> ] ;
       39         ja:baseModel :graph ;
       40         .
       41
       42



What I have found is that if data is entered into the default graph in the
"Data" dataset without the unionDefaultGraph option, this "Reasoner"
dataset (above) will find the information and perform inferences over it.
However, if the data is instead entered into two named graphs, with the
unionDefaultGraph:true option selected, the "Reasoner" dataset is unable to
find the information in "Data". Additionally, the "Reasoner" dataset has no
access to read or write to the "Data" dataset, which is why I set up a
separate end-point to be able to manipulate the data in "Data".



The goal of this experiment is to be able to run different Owl ontologies
over the same entity data, so ideally there would be a way to create a
unionized graph from two named graphs in "Data" and query time, and then
run the inference engine over this graph. So my questions are,



1) Is there a way to create a unionized graph at query time? If yes, is
there a way to run an inference engine over this query-time-created
unionized graph?



2) If the above is not an option, is there a way have an inference engine
run over the unionized default graph from a set of named graphs?



If you have any questions or need more information please feel free to
reach out to me at any time.





Thank you for your help,

Evan Woodward









Reply via email to