FOSDEM 2019 report (brief)

[Claude Warren]

I attended FOSDEM and worked the Apache table (as well as attending some
talks).  We had Jena stickers and they were very popular.  When I asked if
people knew what it was the general answer was "No, but I like the look of
the logo".  Ahh well, at least some of the folks I talked to said they
would look into it.

I did come across a talk about graph traversal using Multiplex Graph
analysis.
https://fosdem.org/2019/schedule/event/graph_multiplex_analysis_graphblas/
There was a full graph track.  I think we should try to get Jena included
in graph tracks at various conferences during the year just to keep Jena
(and RDF graphs) in the minds of developers

Claude

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

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

Re: Another extra module

[Claude Warren]

My understanding of Graphana is that they provide charts (aka visual graphs
but just to keep the nomenclature clear I will call them charts) for data.
They are source agnostic and currently talk to a number of databases.  The
idea is to allow a user/admin to create queries that would be charted by
Graphana.  Very early investigation.  I was just wondering if such a module
would be a good fit for the "extras".

I also think that having adapters to make it easy to pull and display data
from Jena/Fuseki might bring an up-tick in adoption.  At one time I thought
about Zeppelin as a frontend.

Claude

On Tue, Feb 5, 2019 at 10:25 PM ajs6f  wrote:

> This would make Graphana metrics appear as RDF in the Jena API?
>
> ajs6f
>
> > On Feb 3, 2019, at 2:40 PM, Claude Warren  wrote:
> >
> > After spending some time at FOSDEM this weekend, i am going to look into
> > creating a Jena adapter for Graphana.  Is this the sort of module we
> might
> > consider for inclusion as an extra module?
> >
> > Claude
>
>

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

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

[jira] [Commented] (JENA-1663) ModelAssembler does not protect prefix manipulation with a transaction.

[Ashley Sommer (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761520#comment-16761520
 ] 

Ashley Sommer commented on JENA-1663:
-


I'm having the same problem with ja:UnionModel assember where subModels are 
tdb2:GraphTDB2 instances.

configuration/union_all.ttl :
{code}
@prefix :   .
@prefix tdb:    .
@prefix rdf:    .
@prefix ja: .
@prefix rdfs:   .
@prefix tdb:    .
@prefix tdb2:   .
@prefix fuseki:  .
##--
:service_union_all  a fuseki:Service ;
rdfs:label"Union of all caches" ;
fuseki:dataset:ds_union_all ;
fuseki:name   "union_all" ;
fuseki:serviceQuery   "query" , "sparql" ;
# READ ONLY, no Update/Upload-enpoints
fuseki:serviceReadGraphStore  "get" .

:union_all_model rdf:type ja:UnionModel ;
ja:subModel :g1 ;
ja:subModel :g2 ; 
ja:subModel :g3 ;
ja:subModel :g4 .

:ds_union_all a ja:RDFDataset ;
ja:defaultGraph :union_all_model .


:ds1_tdb2 a  tdb2:DatasetTDB2 ;
  tdb2:location  "tdb2_1" .

:g1 a tdb2:GraphTDB2 ;
  tdb2:dataset :ds1_tdb2 .

:ds2_tdb2 a tdb2:DatasetTDB2 ;
tdb2:location  "tdb2_2" .

:g2 a tdb2:GraphTDB2 ;
tdb2:dataset :ds2_tdb2 .

:ds3_tdb a tdb:DatasetTDB ;
tdb:location  "tdb_3" .

:g3 a tdb:GraphTDB ;
tdb:dataset :ds3_tdb .

:ds4_tdb2 a tdb2:DatasetTDB2 ;
tdb2:location  "tdb2_4" .

:g4 a tdb2:GraphTDB2 ;
tdb2:dataset :ds4_tdb2 .
## 
{code}

Running any SPARQL query throws this exception:
{code}
 [2019-02-06 15:53:18] Fuseki WARN [12] RC = 500 : Not in a transaction
 org.apache.jena.dboe.transaction.txn.TransactionException: Not in a transaction
 at 
org.apache.jena.dboe.transaction.txn.TransactionalComponentLifecycle.checkTxn(TransactionalComponentLifecycle.java:417)
 at 
org.apache.jena.dboe.trans.bplustree.BPlusTree.getRootRead(BPlusTree.java:159)
 at org.apache.jena.dboe.trans.bplustree.BPlusTree.iterator(BPlusTree.java:348)
 at 
org.apache.jena.tdb2.store.tupletable.TupleIndexRecord.all(TupleIndexRecord.java:251)
 at org.apache.jena.tdb2.store.tupletable.TupleTable.find(TupleTable.java:148)
 at 
org.apache.jena.tdb2.store.nodetupletable.NodeTupleTableConcrete.find(NodeTupleTableConcrete.java:161)
 at 
org.apache.jena.tdb2.store.nodetupletable.NodeTupleTableConcrete.find(NodeTupleTableConcrete.java:150)
 at 
org.apache.jena.tdb2.store.nodetupletable.NodeTupleTableConcrete.findAsNodeIds(NodeTupleTableConcrete.java:141)
 at org.apache.jena.tdb2.store.TripleTable.find(TripleTable.java:64)
 at 
org.apache.jena.tdb2.store.DatasetGraphTDB.findInDftGraph(DatasetGraphTDB.java:104)
 at 
org.apache.jena.sparql.core.DatasetGraphBaseFind.find(DatasetGraphBaseFind.java:47)
 at 
org.apache.jena.sparql.core.DatasetGraphWrapper.find(DatasetGraphWrapper.java:167)
 at org.apache.jena.sparql.core.GraphView.graphBaseFind(GraphView.java:124)
 at org.apache.jena.sparql.core.GraphView.graphBaseFind(GraphView.java:116)
 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.(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.QueryIterSlice.hasNextBinding(QueryIterSlice.java:76)
 at 
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
 at 

Re: Another extra module

[ajs6f]

This would make Graphana metrics appear as RDF in the Jena API?

ajs6f

> On Feb 3, 2019, at 2:40 PM, Claude Warren  wrote:
> 
> After spending some time at FOSDEM this weekend, i am going to look into
> creating a Jena adapter for Graphana.  Is this the sort of module we might
> consider for inclusion as an extra module?
> 
> Claude

Re: CMS diff: Jena Full Text Search

[ajs6f]

I think I left this drop, and I apologize. Vincent, can you resend your patch, 
but this time without the unnecessary assertions (as pointed out by Andy et 
al.)? If not, that's okay, I can reassemble it myself from the mailing list.

Thanks either way!

ajs6f

> On Jan 29, 2019, at 4:42 AM, Andy Seaborne  wrote:
> 
> 
> 
> On 28/01/2019 21:01, vincent ventresque wrote:
>> Hi Ajs6f
>> Thanks for including me in the conversation, but I have to confess I've 
>> never looked at java classes (I only use command line tools).
>> Le 28/01/2019 à 21:05, ajs6f a écrit :
 On Jan 28, 2019, at 2:57 PM, Chris Tomlinson  
 wrote:
 
 Hi Adam,
 
 I haven’t seen that error. What I’ve done in the past is to replace the 
 jena-text doc file with the new contents in Eclipse in an SVN checkout of 
 the jena-doc-site and then committed.
>>> I can definitely do that (and will when we're happy with the patch), but 
>>> see below.
>>> 
 Out of curiosity when is it necessary to use the
 
  [] ja:loadClass "org.apache.jena.tdb.TDB” .
 
 and
 
 [] ja:loadClass   "org.apache.jena.query.text.TextQuery” .
> 
> It's not necessary any more.
> 
> The ServiceLoader Jena initialization does this.
> 
> The other initialization step should also be unnecessary:
> 
> tdb:DatasetTDB  rdfs:subClassOf  ja:RDFDataset .
> tdb:GraphTDBrdfs:subClassOf  ja:Model .
> 
 
 ? I do not use them in the config when running fuseki war in tomcat.
>>> I have no idea whatsoever! :grin: I wouldn't have thought them needed 
>>> either.
>>> 
>>> Vincent-- any comment?
>>> 
>>> ajs6f
>>> 
>>> 
 Regards,
 Chris
 
 
 
> On Jan 28, 2019, at 11:11 AM, ajs6f  wrote:
> 
> Recently Vincent offered a nice patch to our text indexing documentation, 
> as shown below. Oddly, when I now go to merge it (a bit late, sorry!), I 
> get an error: "Can't locate anonymous's tree to clone". Is anyone 
> familiar with that? I know very little about the SVN-based CMS, so I'm 
> not even sure where to start looking...
> 
> ajs6f