You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Laura Morales <la...@mail.com> on 2019/06/12 06:25:25 UTC

Fuseki union of two TDB(2) datasets

Can I configure Fuseki to use the union of two TDB or TDB2 datasets as the default union graph?

Re: Fuseki union of two TDB(2) datasets

Posted by Andy Seaborne <an...@apache.org>.

On 13/06/2019 12:14, Laura Morales wrote:
>> JENA-1667
> 
> I think my problem is exactly the same one described by Ashley Sommer in JENA-1663.
> 

See the comment

https://issues.apache.org/jira/browse/JENA-1663#comment-16764175


Re: Fuseki union of two TDB(2) datasets

Posted by Laura Morales <la...@mail.com>.
> JENA-1667

I think my problem is exactly the same one described by Ashley Sommer in JENA-1663.

Re: Fuseki union of two TDB(2) datasets

Posted by Andy Seaborne <an...@apache.org>.
JENA-1667

On 13/06/2019 04:42, Laura Morales wrote:
>>> PS: this only works with TDB1 right? Any way to make it work with TDB2?
>>
>> No. Works for anything and mixtures:
>>
>> Change the tdb:GraphTDB and tdb:DatasetTDB
>> to tdb2:GraphTDB2 and tdb2:DatasetTDB2
> 
> TDB1 works, but with TDB2 all I get is a waning: "500 : Not in a transaction".
> This is the assembler:
> 
> <#dataset> a ja:RDFDataset;
>      ja:graph <#all> ;
>      .
> 
> <#all> a ja:UnionModel ;
>      ja:subModel <#graph1> ;
>      ja:subModel <#graph2> ;
>      .
> 
> <#graph1> a tdb2:GraphTDB2 ;
>      tdb2:dataset <#ds1> ;
>      #tdb2:graphName <urn:x-arq:UnionGraph> ;
>      .
> 
> <#graph2> a tdb2:GraphTDB2 ;
>      tdb2:dataset <#ds2> ;
>      #tdb2:graphName <urn:x-arq:UnionGraph> ;
>      .
> 
> <#ds1> a tdb2:DatasetTDB2 ;
>      tdb2:location "../DB1" ;
>      .
> 
> <#ds2> a tdb2:DatasetTDB2 ;
>      tdb2:location "../DB2" ;
>      .
> 
> And output, with or without <urn:x-arq:UnionGraph>:
> 
> $ ./fuseki-server --verbose --debug
> [2019-06-13 05:29:06] QueryIteratorCheck WARN  Open iterator: TripleMapper/83
> [2019-06-13 05:29:06] Fuseki     WARN  [4] RC = 500 : Not in a transaction
> org.apache.jena.dboe.transaction.txn.TransactionException: Not in a transaction
> 	at org.apache.jena.tdb2.store.DatasetGraphTDB.requireTxn(DatasetGraphTDB.java:168)
> 	at org.apache.jena.tdb2.store.DatasetGraphTDB.findInDftGraph(DatasetGraphTDB.java:101)
> 	at org.apache.jena.sparql.core.DatasetGraphBaseFind.find(DatasetGraphBaseFind.java:47)
> 	at org.apache.jena.sparql.core.DatasetGraphWrapper.find(DatasetGraphWrapper.java:181)
> 	at org.apache.jena.sparql.core.GraphView.graphBaseFind(GraphView.java:121)
> 	at org.apache.jena.sparql.core.GraphView.graphBaseFind(GraphView.java:113)
> 	at org.apache.jena.graph.impl.GraphBase.find(GraphBase.java:241)
> 	at org.apache.jena.graph.compose.MultiUnion.multiGraphFind(MultiUnion.java:170)
> 	at org.apache.jena.graph.compose.MultiUnion.graphBaseFind(MultiUnion.java:147)
> 	at org.apache.jena.graph.impl.GraphBase.find(GraphBase.java:241)
> 	at org.apache.jena.graph.impl.GraphBase.graphBaseFind(GraphBase.java:258)
> 	at org.apache.jena.graph.impl.GraphBase.find(GraphBase.java:255)
> 	at org.apache.jena.sparql.engine.iterator.QueryIterTriplePattern$TripleMapper.<init>(QueryIterTriplePattern.java:75)
> 	at org.apache.jena.sparql.engine.iterator.QueryIterTriplePattern.nextStage(QueryIterTriplePattern.java:49)
> 	at org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.makeNextStage(QueryIterRepeatApply.java:108)
> 	at org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:65)
> 	at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
> 	at org.apache.jena.sparql.engine.iterator.QueryIterBlockTriples.hasNextBinding(QueryIterBlockTriples.java:63)
> 	at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
> 	at org.apache.jena.sparql.engine.iterator.QueryIterConvert.hasNextBinding(QueryIterConvert.java:58)
> 	at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
> 	at org.apache.jena.sparql.engine.iterator.QueryIterDistinct.getInputNextUnseen(QueryIterDistinct.java:104)
> 	at org.apache.jena.sparql.engine.iterator.QueryIterDistinct.hasNextBinding(QueryIterDistinct.java:70)
> 	at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
> 	at org.apache.jena.sparql.engine.iterator.QueryIterSlice.hasNextBinding(QueryIterSlice.java:76)
> 	at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
> 	at org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:39)
> 	at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
> 	at org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:39)
> 	at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
> 	at org.apache.jena.sparql.engine.ResultSetStream.hasNext(ResultSetStream.java:74)
> 	at org.apache.jena.sparql.engine.ResultSetCheckCondition.hasNext(ResultSetCheckCondition.java:55)
> 	at org.apache.jena.fuseki.servlets.SPARQL_Query.executeQuery(SPARQL_Query.java:341)
> 	at org.apache.jena.fuseki.servlets.SPARQL_Query.execute(SPARQL_Query.java:290)
> 	at org.apache.jena.fuseki.servlets.SPARQL_Query.executeWithParameter(SPARQL_Query.java:239)
> 	at org.apache.jena.fuseki.servlets.SPARQL_Query.perform(SPARQL_Query.java:224)
> 	at org.apache.jena.fuseki.servlets.ActionService.executeLifecycle(ActionService.java:266)
> 	at org.apache.jena.fuseki.servlets.ActionService.execCommonWorker(ActionService.java:155)
> 	at org.apache.jena.fuseki.servlets.ActionBase.doCommon(ActionBase.java:74)
> 	at org.apache.jena.fuseki.servlets.FusekiFilter.doFilter(FusekiFilter.java:73)
> 	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1642)
> 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
> 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
> 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
> 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
> 	at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
> 	at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
> 	at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
> 	at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
> 	at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
> 	at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
> 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> 	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1642)
> 	at org.apache.jena.fuseki.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:285)
> 	at org.apache.jena.fuseki.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:248)
> 	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
> 	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
> 	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
> 	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> 	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> 	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
> 	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
> 	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> 	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1340)
> 	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
> 	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
> 	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
> 	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
> 	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1242)
> 	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
> 	at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:690)
> 	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> 	at org.eclipse.jetty.server.Server.handle(Server.java:503)
> 	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)
> 	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
> 	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
> 	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> 	at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
> 	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
> 	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
> 	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
> 	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
> 	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
> 	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
> 	at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)
> 	at java.lang.Thread.run(Thread.java:748)
> 

Re: Fuseki union of two TDB(2) datasets

Posted by Laura Morales <la...@mail.com>.
> > PS: this only works with TDB1 right? Any way to make it work with TDB2?
>
> No. Works for anything and mixtures:
>
> Change the tdb:GraphTDB and tdb:DatasetTDB
> to tdb2:GraphTDB2 and tdb2:DatasetTDB2

TDB1 works, but with TDB2 all I get is a waning: "500 : Not in a transaction".
This is the assembler:

<#dataset> a ja:RDFDataset;
    ja:graph <#all> ;
    .

<#all> a ja:UnionModel ;
    ja:subModel <#graph1> ;
    ja:subModel <#graph2> ;
    .

<#graph1> a tdb2:GraphTDB2 ;
    tdb2:dataset <#ds1> ;
    #tdb2:graphName <urn:x-arq:UnionGraph> ;
    .

<#graph2> a tdb2:GraphTDB2 ;
    tdb2:dataset <#ds2> ;
    #tdb2:graphName <urn:x-arq:UnionGraph> ;
    .

<#ds1> a tdb2:DatasetTDB2 ;
    tdb2:location "../DB1" ;
    .

<#ds2> a tdb2:DatasetTDB2 ;
    tdb2:location "../DB2" ;
    .

And output, with or without <urn:x-arq:UnionGraph>:

$ ./fuseki-server --verbose --debug
[2019-06-13 05:29:06] QueryIteratorCheck WARN  Open iterator: TripleMapper/83
[2019-06-13 05:29:06] Fuseki     WARN  [4] RC = 500 : Not in a transaction
org.apache.jena.dboe.transaction.txn.TransactionException: Not in a transaction
	at org.apache.jena.tdb2.store.DatasetGraphTDB.requireTxn(DatasetGraphTDB.java:168)
	at org.apache.jena.tdb2.store.DatasetGraphTDB.findInDftGraph(DatasetGraphTDB.java:101)
	at org.apache.jena.sparql.core.DatasetGraphBaseFind.find(DatasetGraphBaseFind.java:47)
	at org.apache.jena.sparql.core.DatasetGraphWrapper.find(DatasetGraphWrapper.java:181)
	at org.apache.jena.sparql.core.GraphView.graphBaseFind(GraphView.java:121)
	at org.apache.jena.sparql.core.GraphView.graphBaseFind(GraphView.java:113)
	at org.apache.jena.graph.impl.GraphBase.find(GraphBase.java:241)
	at org.apache.jena.graph.compose.MultiUnion.multiGraphFind(MultiUnion.java:170)
	at org.apache.jena.graph.compose.MultiUnion.graphBaseFind(MultiUnion.java:147)
	at org.apache.jena.graph.impl.GraphBase.find(GraphBase.java:241)
	at org.apache.jena.graph.impl.GraphBase.graphBaseFind(GraphBase.java:258)
	at org.apache.jena.graph.impl.GraphBase.find(GraphBase.java:255)
	at org.apache.jena.sparql.engine.iterator.QueryIterTriplePattern$TripleMapper.<init>(QueryIterTriplePattern.java:75)
	at org.apache.jena.sparql.engine.iterator.QueryIterTriplePattern.nextStage(QueryIterTriplePattern.java:49)
	at org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.makeNextStage(QueryIterRepeatApply.java:108)
	at org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:65)
	at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
	at org.apache.jena.sparql.engine.iterator.QueryIterBlockTriples.hasNextBinding(QueryIterBlockTriples.java:63)
	at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
	at org.apache.jena.sparql.engine.iterator.QueryIterConvert.hasNextBinding(QueryIterConvert.java:58)
	at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
	at org.apache.jena.sparql.engine.iterator.QueryIterDistinct.getInputNextUnseen(QueryIterDistinct.java:104)
	at org.apache.jena.sparql.engine.iterator.QueryIterDistinct.hasNextBinding(QueryIterDistinct.java:70)
	at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
	at org.apache.jena.sparql.engine.iterator.QueryIterSlice.hasNextBinding(QueryIterSlice.java:76)
	at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
	at org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:39)
	at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
	at org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:39)
	at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
	at org.apache.jena.sparql.engine.ResultSetStream.hasNext(ResultSetStream.java:74)
	at org.apache.jena.sparql.engine.ResultSetCheckCondition.hasNext(ResultSetCheckCondition.java:55)
	at org.apache.jena.fuseki.servlets.SPARQL_Query.executeQuery(SPARQL_Query.java:341)
	at org.apache.jena.fuseki.servlets.SPARQL_Query.execute(SPARQL_Query.java:290)
	at org.apache.jena.fuseki.servlets.SPARQL_Query.executeWithParameter(SPARQL_Query.java:239)
	at org.apache.jena.fuseki.servlets.SPARQL_Query.perform(SPARQL_Query.java:224)
	at org.apache.jena.fuseki.servlets.ActionService.executeLifecycle(ActionService.java:266)
	at org.apache.jena.fuseki.servlets.ActionService.execCommonWorker(ActionService.java:155)
	at org.apache.jena.fuseki.servlets.ActionBase.doCommon(ActionBase.java:74)
	at org.apache.jena.fuseki.servlets.FusekiFilter.doFilter(FusekiFilter.java:73)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1642)
	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
	at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
	at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
	at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
	at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
	at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
	at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1642)
	at org.apache.jena.fuseki.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:285)
	at org.apache.jena.fuseki.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:248)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1340)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1242)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
	at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:690)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
	at org.eclipse.jetty.server.Server.handle(Server.java:503)
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
	at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)
	at java.lang.Thread.run(Thread.java:748)


Re: Fuseki union of two TDB(2) datasets

Posted by Laura Morales <la...@mail.com>.
Thank you!

> Sent: Thursday, June 13, 2019 at 1:05 AM
> From: "ajs6f" <aj...@apache.org>
> To: users@jena.apache.org
> Subject: Re: Fuseki union of two TDB(2) datasets
>
> Filed as https://issues.apache.org/jira/browse/JENA-1721.
>
> ajs6f

Re: Fuseki union of two TDB(2) datasets

Posted by ajs6f <aj...@apache.org>.
Filed as https://issues.apache.org/jira/browse/JENA-1721.

ajs6f

> On Jun 12, 2019, at 6:49 PM, Andy Seaborne <an...@apache.org> wrote:
> 
> 
> 
> On 12/06/2019 20:07, Laura Morales wrote:
>>>> The reason why I would like to be able to do this, instead of merging one dataset into another, is simply because the two datasets come from different origins.
>>> 
>>> With an overlap of named graphs?
>> Potentially yes, but for my particular case I can work around it by renaming my graphs if it makes any difference.
>> I've done a quick test using your assembler with ja:UnionModel, and using 2 TDB datasets that I've created like this: tdbloader2 --loc dataset-1 data.nt (data.nt contains only 1 unnamed graph). SELECT..WHERE queries return an empty results set, but it *does* seem to work if I remove the tdb:graphName <urn:x-arq:UnionGraph> properties.
> 
> And presumable turned on union mode.
> 
> <urn:x-arq:UnionGraph> is the union model and means the dtabases don't need tdb:unionDefaultGraph
> 
>> Where can I find more documentation about ja:UnionModel?
> 
> Its a bit cryptic TBH:
> https://jena.apache.org/documentation/assembler/assembler-howto.html#union-models
> 
> A union dataset would be better but there is no assembler as Adam said.
> 
>> I've never used it before and I don't really understand what's going on...
> 
> It creates an in-memory stateless union model.
> 
> Union models (which are used a lot in OWL) calculate the graph-union-find over several submodels.
> 
> Classes UnionModelAssembler and MultiUnion.
> 
>> PS: this only works with TDB1 right? Any way to make it work with TDB2?
> 
> No. Works for anything and mixtures:
> 
> Change the tdb:GraphTDB and tdb:DatasetTDB
> to tdb2:GraphTDB2 and tdb2:DatasetTDB2
> 
> 


Re: Fuseki union of two TDB(2) datasets

Posted by Andy Seaborne <an...@apache.org>.

On 12/06/2019 20:07, Laura Morales wrote:
>>> The reason why I would like to be able to do this, instead of merging one dataset into another, is simply because the two datasets come from different origins.
>>
>> With an overlap of named graphs?
> 
> Potentially yes, but for my particular case I can work around it by renaming my graphs if it makes any difference.
> 
> I've done a quick test using your assembler with ja:UnionModel, and using 2 TDB datasets that I've created like this: tdbloader2 --loc dataset-1 data.nt (data.nt contains only 1 unnamed graph). SELECT..WHERE queries return an empty results set, but it *does* seem to work if I remove the tdb:graphName <urn:x-arq:UnionGraph> properties.

And presumable turned on union mode.

<urn:x-arq:UnionGraph> is the union model and means the dtabases don't 
need tdb:unionDefaultGraph

> 
> Where can I find more documentation about ja:UnionModel?

Its a bit cryptic TBH:
https://jena.apache.org/documentation/assembler/assembler-howto.html#union-models

A union dataset would be better but there is no assembler as Adam said.

> I've never used it before and I don't really understand what's going on...

It creates an in-memory stateless union model.

Union models (which are used a lot in OWL) calculate the 
graph-union-find over several submodels.

Classes UnionModelAssembler and MultiUnion.

> 
> PS: this only works with TDB1 right? Any way to make it work with TDB2?

No. Works for anything and mixtures:

Change the tdb:GraphTDB and tdb:DatasetTDB
to tdb2:GraphTDB2 and tdb2:DatasetTDB2



Re: Fuseki union of two TDB(2) datasets

Posted by Laura Morales <la...@mail.com>.
> > The reason why I would like to be able to do this, instead of merging one dataset into another, is simply because the two datasets come from different origins.
>
> With an overlap of named graphs?

Potentially yes, but for my particular case I can work around it by renaming my graphs if it makes any difference.

I've done a quick test using your assembler with ja:UnionModel, and using 2 TDB datasets that I've created like this: tdbloader2 --loc dataset-1 data.nt (data.nt contains only 1 unnamed graph). SELECT..WHERE queries return an empty results set, but it *does* seem to work if I remove the tdb:graphName <urn:x-arq:UnionGraph> properties.

Where can I find more documentation about ja:UnionModel? I've never used it before and I don't really understand what's going on...

PS: this only works with TDB1 right? Any way to make it work with TDB2?


Re: Fuseki union of two TDB(2) datasets

Posted by Andy Seaborne <an...@apache.org>.
> 
> The reason why I would like to be able to do this, instead of merging one dataset into another, is simply because the two datasets come from different origins.

With an overlap of named graphs?



On 12/06/2019 15:31, Laura Morales wrote:
>>  From the Java side, there is UnionDatasetGraph, which would be able to give you a view over two datasets, but I'm not sure we ever wrote an assembler for that. I don't see one in the codebase, although it shouldn't be too hard. There are DatasetDescriptionAssembler and UnionModelAssembler and you might be able to cobble something together from them.
> 
> Changing Jena/Fuseki Java source code is way above what I'm capable of doing. Reading the documentation, I might assemble an ja:RDFDataset but does it support any property like tdb:unionDefaultGraph?
> 
>      <#dataset> rdf:type ja:RDFDataset ;
>          tdb:unionDefaultGraph true ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
No - tdb: applies to DatasetTDB.
>          ja:namedGraph
>              [ ja:graphName <http://example.org/name1> ;
>                ja:graph     <#graph1> ] ;
>          ja:namedGraph
>              [ ja:graphName <http://example.org/name2> ;
>                ja:graph     <#graph2> ] ;
>          .
> 
>      <#graph1> rdf:type tdb:GraphTDB ;
>          tdb:location "DB-1" ;
>          .
> 
>      <#graph2> rdf:type tdb:GraphTDB ;
>          tdb:location "DB-2" ;
>          .

Union the models.  This gets the cardinality right. (Not trivially cheap 
though)

More like (untried ATM):

# General dataset, default model.
<#dataset> rdf:type ja:RDFDataset;
    ja:graph <#all> ;
    .

# Union model.
<#all> a ja:UnionModel ;
    ja:subModel <#graph1> ;
    ja:subModel <#graph2> ;
    .


<#graph1> rdf:type tdb:GraphTDB ;
     tdb:dataset <#tdb1> ;
     ## NB graph name.
     tdb:graphName <urn:x-arq:UnionGraph> ;
     .

<#graph2>  rdf:type tdb:GraphTDB ;
     tdb:dataset <#tdb2> ;
     tdb:graphName <urn:x-arq:UnionGraph> ;
     .

<#tdb1> rdf:type      tdb:DatasetTDB ;
     tdb:location "DB1" ;
    .

<#tdb2> rdf:type      tdb:DatasetTDB ;
     tdb:location "DB2" ;
    .

Re: Fuseki union of two TDB(2) datasets

Posted by Laura Morales <la...@mail.com>.
> From the Java side, there is UnionDatasetGraph, which would be able to give you a view over two datasets, but I'm not sure we ever wrote an assembler for that. I don't see one in the codebase, although it shouldn't be too hard. There are DatasetDescriptionAssembler and UnionModelAssembler and you might be able to cobble something together from them.

Changing Jena/Fuseki Java source code is way above what I'm capable of doing. Reading the documentation, I might assemble an ja:RDFDataset but does it support any property like tdb:unionDefaultGraph?

    <#dataset> rdf:type ja:RDFDataset ;
        tdb:unionDefaultGraph true ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
        ja:namedGraph
            [ ja:graphName <http://example.org/name1> ;
              ja:graph     <#graph1> ] ;
        ja:namedGraph
            [ ja:graphName <http://example.org/name2> ;
              ja:graph     <#graph2> ] ;
        .

    <#graph1> rdf:type tdb:GraphTDB ;
        tdb:location "DB-1" ;
        .

    <#graph2> rdf:type tdb:GraphTDB ;
        tdb:location "DB-2" ;
        .

Re: Fuseki union of two TDB(2) datasets

Posted by ajs6f <aj...@apache.org>.
From the Java side, there is UnionDatasetGraph, which would be able to give you a view over two datasets, but I'm not sure we ever wrote an assembler for that. I don't see one in the codebase, although it shouldn't be too hard. There are DatasetDescriptionAssembler and UnionModelAssembler and you might be able to cobble something together from them.

ajs6f

> On Jun 12, 2019, at 8:10 AM, Laura Morales <la...@mail.com> wrote:
> 
> Basically I have a Fuseki server with 1 TDB dataset containing multiple graphs, like this (stripped down configuration):
> 
> 
>    <#service> rdf:type fuseki:Service ;
>        fuseki:dataset <#dataset> ;
>        .
> 
>    <#dataset> rdf:type tdb:DatasetTDB ;
>        tdb:location "DB" ;
>        tdb:unionDefaultGraph true ;
>        .
> 
> 
> So the default graph is a graph with tuples from all the named graphs in the same dataset. What I would like to do is simply extend the default graph to include tuples from another dataset, if it's possible. Something like this (pseudo configuration):
> 
> 
>    <#service> rdf:type fuseki:Service ;
>        fuseki:dataset <#dataset-1> ;
>        fuseki:dataset <#dataset-2> ;
>        ja:defaultGraph <#dataset-1>, <#dataset-2> ;
>        .
> 
>    <#dataset-1> rdf:type tdb:DatasetTDB ;
>        tdb:location "DB-1" ;
>        .
> 
>    <#dataset-2> rdf:type tdb:DatasetTDB ;
>        tdb:location "DB-2" ;
>        .
> 
> 
> The reason why I would like to be able to do this, instead of merging one dataset into another, is simply because the two datasets come from different origins. I control one dataset, but I'm importing the other; however I would like to SELECT..WHERE over all graphs combined. Merging the 3rd party dataset into my dataset is something that I would like to avoid because it adds a lot of complexity, so I was wondering if I can configure Fuseki to automatically use two distinct datasets as a union default graph.
> Is this possible with either TDB or TDB2? I hope my question is clear and makes sense. Thank you.
> 
> 
> 
> 
>> Sent: Wednesday, June 12, 2019 at 1:08 PM
>> From: "Andy Seaborne" <an...@apache.org>
>> To: users@jena.apache.org
>> Subject: Re: Fuseki union of two TDB(2) datasets
>> 
>> What's the use case here?
>> 
>> You can have a general dataset which has a default graph being the union
>> of two graphs, each from a TDB1/TSDB2 dataset.
>> 
>> But maybe there is a better way for the use case.
>> 
>>     Andy


Re: Fuseki union of two TDB(2) datasets

Posted by Laura Morales <la...@mail.com>.
Basically I have a Fuseki server with 1 TDB dataset containing multiple graphs, like this (stripped down configuration):


    <#service> rdf:type fuseki:Service ;
        fuseki:dataset <#dataset> ;
        .

    <#dataset> rdf:type tdb:DatasetTDB ;
        tdb:location "DB" ;
        tdb:unionDefaultGraph true ;
        .


So the default graph is a graph with tuples from all the named graphs in the same dataset. What I would like to do is simply extend the default graph to include tuples from another dataset, if it's possible. Something like this (pseudo configuration):


    <#service> rdf:type fuseki:Service ;
        fuseki:dataset <#dataset-1> ;
        fuseki:dataset <#dataset-2> ;
        ja:defaultGraph <#dataset-1>, <#dataset-2> ;
        .

    <#dataset-1> rdf:type tdb:DatasetTDB ;
        tdb:location "DB-1" ;
        .

    <#dataset-2> rdf:type tdb:DatasetTDB ;
        tdb:location "DB-2" ;
        .


The reason why I would like to be able to do this, instead of merging one dataset into another, is simply because the two datasets come from different origins. I control one dataset, but I'm importing the other; however I would like to SELECT..WHERE over all graphs combined. Merging the 3rd party dataset into my dataset is something that I would like to avoid because it adds a lot of complexity, so I was wondering if I can configure Fuseki to automatically use two distinct datasets as a union default graph.
Is this possible with either TDB or TDB2? I hope my question is clear and makes sense. Thank you.




> Sent: Wednesday, June 12, 2019 at 1:08 PM
> From: "Andy Seaborne" <an...@apache.org>
> To: users@jena.apache.org
> Subject: Re: Fuseki union of two TDB(2) datasets
>
> What's the use case here?
>
> You can have a general dataset which has a default graph being the union
> of two graphs, each from a TDB1/TSDB2 dataset.
>
> But maybe there is a better way for the use case.
>
>      Andy

Re: Fuseki union of two TDB(2) datasets

Posted by Andy Seaborne <an...@apache.org>.
What's the use case here?

You can have a general dataset which has a default graph being the union 
of two graphs, each from a TDB1/TSDB2 dataset.

But maybe there is a better way for the use case.

     Andy

On 12/06/2019 07:25, Laura Morales wrote:
> Can I configure Fuseki to use the union of two TDB or TDB2 datasets as the default union graph?
>