Re: [UnionModel] question about unexpected behaviour

2019-09-30 Thread Claude Warren 
Barry,

You could create a union graph that is used for an InfModel.  Not sure why
you want a UnionGraph but ...

I think you want to start with a TDB Model and wrap that as a SecuredModel
(See comments in permissions re: SecuredModel vs SecuredGraph)

Using a SecuredModel as the basis for an InfModel is probably not what you
want to do.  The InfModel will create new triples based on the data it
reads from the underlying graph.  Different users will have different
security model results (there really is not a language to describe this).
So the inference engine for the first user will be correct for that user,
but if the second user is a user with less access the inference engine will
contain reasoned triples that the second user should not see because they
can not see the underlying data.

One way you might resolve this is to make the InfModel a secured model and
perform checks based on the reasoning you add.  This is not a space I have
explored so I fear you are on your own here.  However, there were a couple
of papers about 4 years ago concerning different approaches to securing
graphs.  There might be something in there about how to do this in a way
that will actually work.

On the other hand, if you have a limited number of groups (N) you could use
the SecuredModel to drive N different datasets in Fuseki and let Fuseki
determine which graph(s) a user can see.  In this case you would have N
InfModels running against the same underlying TDB model.  Each InfModel
would write its derived data to its own graph.  This solution will have
problem if you need to update the underlying TDB model.

While I don't have time to properly investigate this question, if you want
to explore it I would be happy to provide pointers and perhaps we can
develop an extension to work with the InfModel.

Claude

On Mon, Sep 30, 2019 at 3:52 PM Nouwt, B. (Barry)
 wrote:

> Hi Claude,
>
> Thanks for your analysis! It was (of course) not my intention to get a
> dataset with 4 graphs , but is sure explains the strange behavior.
>
> I wanted to replicate the behavior of defaultUnionGraph option that is
> available in TDB. The reason I cannot use TDB's defaultUnionGraph option,
> is because in that case I do not have access to the actual default graph
> object. I need this object, because I want to wrap it with a SecuredModel
> and an InfModel.
>
> So, I want to combine the defaultUnionGraph behavior of TDB and the
> SecuredModel with a custom SecurityEvaluator from Jena Permissions and the
> InfModel with the GenericRuleReasoner. This was my attempt at doing so, but
> apparently it does not work. Do you think it is possible to construct such
> a dataset via an Assembler .ttl file?
>
> Regards, Barry
>
> -Original Message-
> From: Claude Warren 
> Sent: maandag 30 september 2019 16:33
> To: users@jena.apache.org
> Subject: Re: [UnionModel] question about unexpected behaviour
>
> Barry,
>
> You create a dataset that is comprised of the following:
>
> defaultGraph -> unionModel
> namedGraph(https://www.tno.nl/agrifood/graph/pizza/data)
> namedGraph(https://www.tno.nl/agrifood/graph/pizza/onto)
> 
>
>
> https://www.tno.nl/agrifood/graph/pizza/data is loaded from
> file:src/main/resources/dummy1.ttl
> https://www.tno.nl/agrifood/graph/pizza/onto is loaded from
> file:src/main/resources/dummy2.ttl
>
> defaultGraph is the union of two graphs
> defaultGraph.root is loaded from file:src/main/resources/dummy1.ttl
> defaultGraph.sub1 is loaded from file:src/main/resources/dummy2.ttl
>
> writing triples into the dataset will write to the defaultGraph.  The
> defaultGraph being a uniongraph will write to the first graph
> (default.Graph.root).  While they are initialized with the same data
> (file:src/main/resources/dummy1.ttl), this is not the same as the
> https://www.tno.nl/agrifood/graph/pizza/data  named graph.
>
> Your example basically has 4 graphs, 2 in defaultGraph and 2 named graphs.
>
> Claude
>
> On Fri, Sep 27, 2019 at 3:57 PM Nouwt, B. (Barry)
>  wrote:
>
> > Hi Claude, thanks for the explanation: from the dataset-as-quads
> > perspective it does indeed sound logical that empty graphs do not exist.
> >
> > Regarding your second answer, I've added some additional information
> > below (i.e. these can also be found on the github repo:
> > https://github.com/barrynl/jena-example). The SPARQL is executed on
> > the dataset described by the conf.ttl below. It does not have a GRAPH
> > specified in the query and it would indeed go into the default graph,
> > which is a UnionModel of the two in-memory named graphs. Of which the
> > rootGraph should store this new data. The details of how I inspect the
> > different graphs can be found in the Java code in the link above. If
> > you run this example and inspect the output log and 'dataset' variable
> > (and the inner models and
> > graphs) with a debugger, the data sometimes shows up and sometimes
> doesn't.
> > I am trying to understand

RE: [UnionModel] question about unexpected behaviour

2019-09-30 Thread Nouwt, B. (Barry) 
Hi Claude, 

Thanks for your analysis! It was (of course) not my intention to get a dataset 
with 4 graphs , but is sure explains the strange behavior.
 
I wanted to replicate the behavior of defaultUnionGraph option that is 
available in TDB. The reason I cannot use TDB's defaultUnionGraph option, is 
because in that case I do not have access to the actual default graph object. I 
need this object, because I want to wrap it with a SecuredModel and an InfModel.

So, I want to combine the defaultUnionGraph behavior of TDB and the 
SecuredModel with a custom SecurityEvaluator from Jena Permissions and the 
InfModel with the GenericRuleReasoner. This was my attempt at doing so, but 
apparently it does not work. Do you think it is possible to construct such a 
dataset via an Assembler .ttl file?

Regards, Barry

-Original Message-
From: Claude Warren  
Sent: maandag 30 september 2019 16:33
To: users@jena.apache.org
Subject: Re: [UnionModel] question about unexpected behaviour

Barry,

You create a dataset that is comprised of the following:

defaultGraph -> unionModel
namedGraph(https://www.tno.nl/agrifood/graph/pizza/data)
namedGraph(https://www.tno.nl/agrifood/graph/pizza/onto)



https://www.tno.nl/agrifood/graph/pizza/data is loaded from 
file:src/main/resources/dummy1.ttl
https://www.tno.nl/agrifood/graph/pizza/onto is loaded from 
file:src/main/resources/dummy2.ttl

defaultGraph is the union of two graphs
defaultGraph.root is loaded from file:src/main/resources/dummy1.ttl
defaultGraph.sub1 is loaded from file:src/main/resources/dummy2.ttl

writing triples into the dataset will write to the defaultGraph.  The 
defaultGraph being a uniongraph will write to the first graph 
(default.Graph.root).  While they are initialized with the same data 
(file:src/main/resources/dummy1.ttl), this is not the same as the 
https://www.tno.nl/agrifood/graph/pizza/data  named graph.

Your example basically has 4 graphs, 2 in defaultGraph and 2 named graphs.

Claude

On Fri, Sep 27, 2019 at 3:57 PM Nouwt, B. (Barry)  
wrote:

> Hi Claude, thanks for the explanation: from the dataset-as-quads 
> perspective it does indeed sound logical that empty graphs do not exist.
>
> Regarding your second answer, I've added some additional information 
> below (i.e. these can also be found on the github repo:
> https://github.com/barrynl/jena-example). The SPARQL is executed on 
> the dataset described by the conf.ttl below. It does not have a GRAPH 
> specified in the query and it would indeed go into the default graph, 
> which is a UnionModel of the two in-memory named graphs. Of which the 
> rootGraph should store this new data. The details of how I inspect the 
> different graphs can be found in the Java code in the link above. If 
> you run this example and inspect the output log and 'dataset' variable 
> (and the inner models and
> graphs) with a debugger, the data sometimes shows up and sometimes doesn't.
> I am trying to understand why... Any more ideas?
>
> Regards, Barry
>
>  SPARQL
> 
> INSERT DATA {
> :test rdf:type pizza:Pizza .
> :test pizza:hasCountryOfOrigin < 
> http://192.168.99.100/pizza/Italy> .
> :test pizza:hasBase 
> 
> .
> :test pizza:hasSpiciness < 
> http://192.168.99.100/pizza/23_flauw> .
> :test pizza:hasTopping :18-Tomaat .
> :test pizza:hasTopping :18-mozzerella .
> :test pizza:hasTopping :18-rundergehakt .
> }
>
>  conf.ttl
> 
>
> @prefix : <#> .
> @prefix fuseki:  http://jena.apache.org/fuseki>> .
> @prefix rdf:  http://www.w3.org/1999/02/22-rdf-syntax-ns>> .
> @prefix rdfs:  http://www.w3.org/2000/01/rdf-schema>> .
> @prefix ja:  http://jena.hpl.hp.com/2005/11/Assembler>> .
> @prefix xsd:  http://www.w3.org/2001/XMLSchema>>  .
>
> :service1 rdf:type fuseki:Service ;
> fuseki:name "test" ;
> fuseki:serviceQuery "query" ; # SPARQL query service
> fuseki:serviceUpdate "update" ;
> fuseki:serviceUpload "upload" ; # Non-SPARQL upload service
> fuseki:serviceReadWriteGraphStore "data" ; # SPARQL Graph 
> store protocol (read and write)
> # A separate read-only graph store endpoint:
> fuseki:serviceReadGraphStore "get" ; # SPARQL Graph store 
> protocol (read only)
> fuseki:dataset :dataset .
>
> :dataset rdf:type ja:RDFDataset ;
> ja:defaultGraph :unionModel ;
> ja:namedGraph
> [ ja:graphName  
> ;
>

Re: [UnionModel] question about unexpected behaviour

2019-09-30 Thread Claude Warren 
Barry,

You create a dataset that is comprised of the following:

defaultGraph -> unionModel
namedGraph(https://www.tno.nl/agrifood/graph/pizza/data)
namedGraph(https://www.tno.nl/agrifood/graph/pizza/onto)



https://www.tno.nl/agrifood/graph/pizza/data is loaded from
file:src/main/resources/dummy1.ttl
https://www.tno.nl/agrifood/graph/pizza/onto is loaded from
file:src/main/resources/dummy2.ttl

defaultGraph is the union of two graphs
defaultGraph.root is loaded from file:src/main/resources/dummy1.ttl
defaultGraph.sub1 is loaded from file:src/main/resources/dummy2.ttl

writing triples into the dataset will write to the defaultGraph.  The
defaultGraph being a uniongraph will write to the first graph
(default.Graph.root).  While they are initialized with the same data
(file:src/main/resources/dummy1.ttl), this is not the same as the
https://www.tno.nl/agrifood/graph/pizza/data  named graph.

Your example basically has 4 graphs, 2 in defaultGraph and 2 named graphs.

Claude

On Fri, Sep 27, 2019 at 3:57 PM Nouwt, B. (Barry)
 wrote:

> Hi Claude, thanks for the explanation: from the dataset-as-quads
> perspective it does indeed sound logical that empty graphs do not exist.
>
> Regarding your second answer, I've added some additional information below
> (i.e. these can also be found on the github repo:
> https://github.com/barrynl/jena-example). The SPARQL is executed on the
> dataset described by the conf.ttl below. It does not have a GRAPH specified
> in the query and it would indeed go into the default graph, which is a
> UnionModel of the two in-memory named graphs. Of which the rootGraph should
> store this new data. The details of how I inspect the different graphs can
> be found in the Java code in the link above. If you run this example and
> inspect the output log and 'dataset' variable (and the inner models and
> graphs) with a debugger, the data sometimes shows up and sometimes doesn't.
> I am trying to understand why... Any more ideas?
>
> Regards, Barry
>
>  SPARQL
> 
> INSERT DATA {
> :test rdf:type pizza:Pizza .
> :test pizza:hasCountryOfOrigin <
> http://192.168.99.100/pizza/Italy> .
> :test pizza:hasBase 
> .
> :test pizza:hasSpiciness <
> http://192.168.99.100/pizza/23_flauw> .
> :test pizza:hasTopping :18-Tomaat .
> :test pizza:hasTopping :18-mozzerella .
> :test pizza:hasTopping :18-rundergehakt .
> }
>
>  conf.ttl
> 
>
> @prefix : <#> .
> @prefix fuseki:  http://jena.apache.org/fuseki>> .
> @prefix rdf:  http://www.w3.org/1999/02/22-rdf-syntax-ns>> .
> @prefix rdfs:  http://www.w3.org/2000/01/rdf-schema>> .
> @prefix ja:  http://jena.hpl.hp.com/2005/11/Assembler>> .
> @prefix xsd:  http://www.w3.org/2001/XMLSchema>>  .
>
> :service1 rdf:type fuseki:Service ;
> fuseki:name "test" ;
> fuseki:serviceQuery "query" ; # SPARQL query service
> fuseki:serviceUpdate "update" ;
> fuseki:serviceUpload "upload" ; # Non-SPARQL upload service
> fuseki:serviceReadWriteGraphStore "data" ; # SPARQL Graph store
> protocol (read and write)
> # A separate read-only graph store endpoint:
> fuseki:serviceReadGraphStore "get" ; # SPARQL Graph store protocol
> (read only)
> fuseki:dataset :dataset .
>
> :dataset rdf:type ja:RDFDataset ;
> ja:defaultGraph :unionModel ;
> ja:namedGraph
> [ ja:graphName  
> ;
>   ja:graph  :itemGraph ] ;
> ja:namedGraph
> [ ja:graphName  
> ;
>   ja:graph  :ontoGraph ]
>  .
>
> :unionModel rdf:type ja:UnionModel ;
> ja:rootModel :itemGraph ;
> ja:subModel :ontoGraph .
>
> :itemGraph rdf:type ja:MemoryModel ;
> ja:content [ ja:externalContent
>  ] .
>
> :ontoGraph rdf:type ja:MemoryModel ;
> ja:content [ ja:externalContent
>  ] .
>
>
>
>
> -Original Message-
> From: Claude Warren 
> Sent: donderdag 26 september 2019 12:10
> To: users@jena.apache.org
> Subject: Re: [UnionModel] question about unexpected behaviour
>
> Empty graphs in Fuseki simply don't exist.  They no more exist than a
> predicate that has not been used.  Named graphs only come into existence
> when there is at least one triple added to it.  If you think about datasets
> as collections of quads (   ) then you can see that the dataset
> can only locate graphs that have data.  The only other