[jira] [Commented] (JENA-2272) Split out GSP extensions for dataset operations into companion class DSP
[
https://issues.apache.org/jira/browse/JENA-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486638#comment-17486638
]
Adam Soroka commented on JENA-2272:
---
Haven't looked at the PR yet, but I'm sure it's good. :)
Does this connect to any W3C work or are we introducing it ourselves as the
natural and obvious extension?
> Split out GSP extensions for dataset operations into companion class DSP
>
>
> Key: JENA-2272
> URL: https://issues.apache.org/jira/browse/JENA-2272
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ
>Affects Versions: Jena 4.4.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
>
> This task is to create a new {{DSP}} which has the dataset-extension
> operations of {{GSP}}.
> Mark the original functions for dataset in {{GSP}} as "deprecated".
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (JENA-1956) ResultSet should implement Iterable
[
https://issues.apache.org/jira/browse/JENA-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205602#comment-17205602
]
Adam Soroka commented on JENA-1956:
---
Yes, that is why wrote "similar" :). In both cases, a change that is positive
in itself might have unintended consequences wrt user experience (binary-compat
or not, warnings appear or no). I would also be a little cautious about the
fact that you might get only one iterator from a {{ResultSet}} (it might be
remote). That's completely within the contract, but how do we want to signal
that we can't re-iterate? Throw an exception after the first call to
{{iterator()}}? Just return an empty {{Iterator}}?
> ResultSet should implement Iterable
> ---
>
> Key: JENA-1956
> URL: https://issues.apache.org/jira/browse/JENA-1956
> Project: Apache Jena
> Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
>
> The class {{ResultSet}} should implement {{Iterable}}. That
> would significantly ease query result processing. It would allow to write
> {code:java}
> for (QuerySolution result : QueryExecutionFactory.create(query,
> model).execSelect()) {
> …
> }
> {code}
> instead of
> {code:java}
> ResultSet results = QueryExecutionFactory.create(query, model).execSelect();
> while (results.hasNext()) {
> QuerySolution result = results.next();
> …
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JENA-1894) Insert-order preserving dataset
[
https://issues.apache.org/jira/browse/JENA-1894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205538#comment-17205538
]
Adam Soroka commented on JENA-1894:
---
[~Aklakan] and [~andy], I apologize for having been nowhere to be found for
this discussion. Long story involving ${work} and ${family}, but I should be
able to participate more usefully going forward, at least for a few weeks.
Luckily, it turns out that I would have had little to offer! What Claus has
here is already better and more general than TIM's undergirding (which was not
well-designed and was really a "get 'er done" approach.)
To (finally) answer a particular question Andy asked, yes, TIM does use a
selected index to quickly answer graph names, but it is a hacky design that
relies on special knowledge, not the nicely-planned version that Claus shows
here.
I need to read the paper that Claus linked (sounds fascinating, I have been
intrigued by tensor-based approaches for years but I don't really know the math
well enough to do anything novel and I don't have time to learn right now-- I'd
also be really curious if [~rvesse] had any thoughts about it). I will try to
look carefully at Claus' PR soon.
One last thing: I think that if we take up the general framework as Claus
offers, we should start with the desideratum that it be impled in DBOE. I think
we should be moving as hard as we can to unify storage abstractions (modulo
technical reality that impl details matter) because one of the difficult things
about learning Jena right now seems to me to be that we have so many very
independent impls of {{DatasetGraph}}.
> Insert-order preserving dataset
> ---
>
> Key: JENA-1894
> URL: https://issues.apache.org/jira/browse/JENA-1894
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ
>Affects Versions: Jena 3.14.0
>Reporter: Claus Stadler
>Priority: Major
>
> To the best of my knowledge, there is no backend for datasets that retains
> insert order.
> This feature is particularly useful when changing RDF files in a git
> repository, as it makes for nice commits. An insert-order preserving
> Triple/QuadTable implementation enables:
> * Writing (subject-grouped) RDF files or events from an RDF stream out in
> nearly the same way they were read in - this makes it easier to compare
> outputs of data transformations
> * Combining ORDER BY with CONSTRUCT queries:
> {code:java}
> Dataset ds = DatasetFactory.createOrderPreservingDataset();
> QueryExecutionFactory.create("CONSTRUCT WHERE { ?s ?p ?o } ORDER BY ?s ?p
> ?o", ds);
> RDFDataMgr.write(System.out, ds, RDFFormat.TURTLE_BLOCKS);
> {code}
> I have created an implementation for this some time ago with the main classes
> of the machinery being:
> *
> [QuadTableFromNestedMaps.java|https://github.com/SmartDataAnalytics/jena-sparql-api/blob/a18b069e963bdef6cc9e8915f3e8f766893bab15/jena-sparql-api-rx/src/main/java/org/aksw/jena_sparql_api/rx/QuadTableFromNestedMaps.java#L26]
> * In addition, I created a lazy (but adequate?) wrapper for re-using a quad
> table as a triple table:
>
> [TripleTableFromQuadTable.java|https://github.com/SmartDataAnalytics/jena-sparql-api/blob/a18b069e963bdef6cc9e8915f3e8f766893bab15/jena-sparql-api-rx/src/main/java/org/aksw/jena_sparql_api/rx/TripleTableFromQuadTable.java#L30]
> * The DatasetGraph wapper:
>
> [DatasetGraphQuadsImpl.java|https://github.com/SmartDataAnalytics/jena-sparql-api/blob/a18b069e963bdef6cc9e8915f3e8f766893bab15/jena-sparql-api-rx/src/main/java/org/aksw/jena_sparql_api/rx/DatasetGraphQuadsImpl.java#L32]
> The actual factory code then uses:
> {code:java}
> public static DatasetGraph createOrderPreservingDatasetGraph() {
> QuadTable quadTable = new QuadTableFromNestedMaps();
> TripleTable tripleTable = new TripleTableFromQuadTable(quadTable);
> DatasetGraph result = new DatasetGraphInMemory(quadTable,
> tripleTable);
> return result;
> }
> {code}
> Note, that DatasetGraphQuadsImpl at present falsly claims that it is
> transaction aware - because otherwise any SPARQL insert caused an exception
> (I have not tried with the latest fixes for 3.15.0-SNAPSHOT yet). In any
> case, for the use cases of writing out RDF transactions may not even be
> necessary, but if there is an easy way to add them, then it should be done.
> An example of the above code in action is here: [Git Diff based on ordered
> turtle-blocks output
> |https://github.com/SmartDataAnalytics/lodservatory/commit/ec50cd33230a771c557c1ed2751799401ea3fd89]
> The downside of using this kind of order preserving dataset is, that
> essentially it only features an gspo index. Hence, the performance
> characteristics of this kind of order preserving dataset - which is intended
> mostly for serialization or
[jira] [Commented] (JENA-1956) ResultSet should implement Iterable
[
https://issues.apache.org/jira/browse/JENA-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205533#comment-17205533
]
Adam Soroka commented on JENA-1956:
---
See JENA-1601 for a similar case.
> ResultSet should implement Iterable
> ---
>
> Key: JENA-1956
> URL: https://issues.apache.org/jira/browse/JENA-1956
> Project: Apache Jena
> Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
>
> The class {{ResultSet}} should implement {{Iterable}}. That
> would significantly ease query result processing. It would allow to write
> {code:java}
> for (QuerySolution result : QueryExecutionFactory.create(query,
> model).execSelect()) {
> …
> }
> {code}
> instead of
> {code:java}
> ResultSet results = QueryExecutionFactory.create(query, model).execSelect();
> while (results.hasNext()) {
> QuerySolution result = results.next();
> …
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JENA-1859) TIM can return dataset sizes directly but doesn't
Adam Soroka created JENA-1859:
-
Summary: TIM can return dataset sizes directly but doesn't
Key: JENA-1859
URL: https://issues.apache.org/jira/browse/JENA-1859
Project: Apache Jena
Issue Type: Improvement
Components: TIM
Affects Versions: Jena 3.14.0
Reporter: Adam Soroka
Assignee: Adam Soroka
TIM currently requires counting graph label nodes to answer
{{DatasetGraph::size}}. In fact the underlying quad storage is nested maps and
the maps involved (from the Dexx library) know their sizes, so it should be
possible to get that number more directly, by adding a method to {{QuadTable}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JENA-1857) DatasetGraphInMemory.listGraphNodes causes exception outside a transaction
[
https://issues.apache.org/jira/browse/JENA-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056087#comment-17056087
]
Adam Soroka commented on JENA-1857:
---
The actual data structures are each a bunch of nested maps, as you may
remember, so really, this info should be available from the indexes and the
method should be overridden at {{DatasetGraphInMemory}}. I don't know why I
didn't. I will get on this in the next few days, if that works for you.
> DatasetGraphInMemory.listGraphNodes causes exception outside a transaction
> --
>
> Key: JENA-1857
> URL: https://issues.apache.org/jira/browse/JENA-1857
> Project: Apache Jena
> Issue Type: Task
> Components: TIM
>Affects Versions: Jena 3.14.0
>Reporter: Andy Seaborne
>Priority: Major
>
> Test case:
> {code:java}
> public static void main(String ... a) {
> DatasetGraph dsg = DatasetGraphFactory.createTxnMem();
> Quad q = SSE.parseQuad("(:g :s :p :o)");
> dsg.add(q);
> try {
> System.out.println(dsg.size());
> } catch (Exception ex) {
> ex.printStackTrace();
> }
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JENA-1783) Clean up use of Class.newInstance
[ https://issues.apache.org/jira/browse/JENA-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16981597#comment-16981597 ] Adam Soroka commented on JENA-1783: --- Is this mostly in the assembler subsystem, or are we using it much elsewhere that you are thinking of? > Clean up use of Class.newInstance > -- > > Key: JENA-1783 > URL: https://issues.apache.org/jira/browse/JENA-1783 > Project: Apache Jena > Issue Type: Task >Affects Versions: Jena 3.13.1 >Reporter: Andy Seaborne >Assignee: Andy Seaborne >Priority: Minor > > Class ::newIntance() is "deprecated" at Java9. > The migration is to replace "class.newInstance()" with > "class.getConstructor().newInstance()". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JENA-1667) Union graph does not fully handle read-transactions.
[
https://issues.apache.org/jira/browse/JENA-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16930622#comment-16930622
]
A. Soroka commented on JENA-1667:
-
Related thread:
https://lists.apache.org/thread.html/ea87ca3eff5bfac3fa4c723b9bf02c0908d7146c161f9820b1b8b526@%3Cusers.jena.apache.org%3E
> Union graph does not fully handle read-transactions.
>
>
> Key: JENA-1667
> URL: https://issues.apache.org/jira/browse/JENA-1667
> Project: Apache Jena
> Issue Type: Bug
>Affects Versions: Jena 3.10.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
>
> See discussion on JENA-1663.
> {noformat}
> :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 .
> {noformat}
> that is, graph from different TDB2 datasets, causes:
> {noformat}
> [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
>
[jira] [Updated] (JENA-1693) Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
[
https://issues.apache.org/jira/browse/JENA-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Soroka updated JENA-1693:
Component/s: ARQ
> Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
> --
>
> Key: JENA-1693
> URL: https://issues.apache.org/jira/browse/JENA-1693
> Project: Apache Jena
> Issue Type: New Feature
> Components: ARQ
>Affects Versions: Jena 3.12.0
> Environment: general
>
>Reporter: Marco Neumann
>Priority: Minor
> Labels: features
> Fix For: Jena 3.13.0
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> As briefly mentioned to Andy Seaborne I'd like to see the aggregate function
> MEDIAN in the ARQ SPARQL syntax.
> "Median is the value that separates lower half from the higher half when the
> values are ordered in ascending or descending order. It is the middle value
> in a given dataset. Medians are helpful in understanding the distribution of
> data. This can be done by comparing mean and median values. By observing the
> difference between these values we can understand whether the data is left
> skewed or right skewed. The formula for median is: Median = ((n + 1)/2) th
> number in the series where the numbers are ordered. Here, n denotes the
> number of values for the given variable."
> DIVYA SPANDANA MARNEN, SPARQL-R: EXTENDED SPARQL FOR STATISTICAL COMPUTATIONS.
>
> example
>
> SELECT agg:median(?age) AS ?median
> WHERE
> { ?x ex:age ?age }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JENA-1693) Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
[
https://issues.apache.org/jira/browse/JENA-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Soroka updated JENA-1693:
Fix Version/s: Jena 3.13.0
> Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
> --
>
> Key: JENA-1693
> URL: https://issues.apache.org/jira/browse/JENA-1693
> Project: Apache Jena
> Issue Type: New Feature
>Affects Versions: Jena 3.12.0
> Environment: general
>
>Reporter: Marco Neumann
>Priority: Minor
> Labels: features
> Fix For: Jena 3.13.0
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> As briefly mentioned to Andy Seaborne I'd like to see the aggregate function
> MEDIAN in the ARQ SPARQL syntax.
> "Median is the value that separates lower half from the higher half when the
> values are ordered in ascending or descending order. It is the middle value
> in a given dataset. Medians are helpful in understanding the distribution of
> data. This can be done by comparing mean and median values. By observing the
> difference between these values we can understand whether the data is left
> skewed or right skewed. The formula for median is: Median = ((n + 1)/2) th
> number in the series where the numbers are ordered. Here, n denotes the
> number of values for the given variable."
> DIVYA SPANDANA MARNEN, SPARQL-R: EXTENDED SPARQL FOR STATISTICAL COMPUTATIONS.
>
> example
>
> SELECT agg:median(?age) AS ?median
> WHERE
> { ?x ex:age ?age }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (JENA-1693) Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
[
https://issues.apache.org/jira/browse/JENA-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Soroka closed JENA-1693.
---
Resolution: Fixed
> Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
> --
>
> Key: JENA-1693
> URL: https://issues.apache.org/jira/browse/JENA-1693
> Project: Apache Jena
> Issue Type: New Feature
> Components: ARQ
>Affects Versions: Jena 3.12.0
> Environment: general
>
>Reporter: Marco Neumann
>Priority: Minor
> Labels: features
> Fix For: Jena 3.13.0
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> As briefly mentioned to Andy Seaborne I'd like to see the aggregate function
> MEDIAN in the ARQ SPARQL syntax.
> "Median is the value that separates lower half from the higher half when the
> values are ordered in ascending or descending order. It is the middle value
> in a given dataset. Medians are helpful in understanding the distribution of
> data. This can be done by comparing mean and median values. By observing the
> difference between these values we can understand whether the data is left
> skewed or right skewed. The formula for median is: Median = ((n + 1)/2) th
> number in the series where the numbers are ordered. Here, n denotes the
> number of values for the given variable."
> DIVYA SPANDANA MARNEN, SPARQL-R: EXTENDED SPARQL FOR STATISTICAL COMPUTATIONS.
>
> example
>
> SELECT agg:median(?age) AS ?median
> WHERE
> { ?x ex:age ?age }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JENA-1693) Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
[
https://issues.apache.org/jira/browse/JENA-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Soroka updated JENA-1693:
Affects Version/s: Jena 3.12.0
> Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
> --
>
> Key: JENA-1693
> URL: https://issues.apache.org/jira/browse/JENA-1693
> Project: Apache Jena
> Issue Type: New Feature
>Affects Versions: Jena 3.12.0
> Environment: general
>
>Reporter: Marco Neumann
>Priority: Minor
> Labels: features
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> As briefly mentioned to Andy Seaborne I'd like to see the aggregate function
> MEDIAN in the ARQ SPARQL syntax.
> "Median is the value that separates lower half from the higher half when the
> values are ordered in ascending or descending order. It is the middle value
> in a given dataset. Medians are helpful in understanding the distribution of
> data. This can be done by comparing mean and median values. By observing the
> difference between these values we can understand whether the data is left
> skewed or right skewed. The formula for median is: Median = ((n + 1)/2) th
> number in the series where the numbers are ordered. Here, n denotes the
> number of values for the given variable."
> DIVYA SPANDANA MARNEN, SPARQL-R: EXTENDED SPARQL FOR STATISTICAL COMPUTATIONS.
>
> example
>
> SELECT agg:median(?age) AS ?median
> WHERE
> { ?x ex:age ?age }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1693) Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
[
https://issues.apache.org/jira/browse/JENA-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864177#comment-16864177
]
A. Soroka commented on JENA-1693:
-
Fixed via [https://github.com/apache/jena/pull/568] with
[https://github.com/apache/jena/commit/7ad20b8bf037b6b697d5666c11cf8a0cfe8964d2]
.
> Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
> --
>
> Key: JENA-1693
> URL: https://issues.apache.org/jira/browse/JENA-1693
> Project: Apache Jena
> Issue Type: New Feature
> Environment: general
>
>Reporter: Marco Neumann
>Priority: Minor
> Labels: features
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> As briefly mentioned to Andy Seaborne I'd like to see the aggregate function
> MEDIAN in the ARQ SPARQL syntax.
> "Median is the value that separates lower half from the higher half when the
> values are ordered in ascending or descending order. It is the middle value
> in a given dataset. Medians are helpful in understanding the distribution of
> data. This can be done by comparing mean and median values. By observing the
> difference between these values we can understand whether the data is left
> skewed or right skewed. The formula for median is: Median = ((n + 1)/2) th
> number in the series where the numbers are ordered. Here, n denotes the
> number of values for the given variable."
> DIVYA SPANDANA MARNEN, SPARQL-R: EXTENDED SPARQL FOR STATISTICAL COMPUTATIONS.
>
> example
>
> SELECT agg:median(?age) AS ?median
> WHERE
> { ?x ex:age ?age }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1693) Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
[
https://issues.apache.org/jira/browse/JENA-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864179#comment-16864179
]
A. Soroka commented on JENA-1693:
-
Thank you for this contribution [~neumarcx]!
> Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
> --
>
> Key: JENA-1693
> URL: https://issues.apache.org/jira/browse/JENA-1693
> Project: Apache Jena
> Issue Type: New Feature
> Environment: general
>
>Reporter: Marco Neumann
>Priority: Minor
> Labels: features
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> As briefly mentioned to Andy Seaborne I'd like to see the aggregate function
> MEDIAN in the ARQ SPARQL syntax.
> "Median is the value that separates lower half from the higher half when the
> values are ordered in ascending or descending order. It is the middle value
> in a given dataset. Medians are helpful in understanding the distribution of
> data. This can be done by comparing mean and median values. By observing the
> difference between these values we can understand whether the data is left
> skewed or right skewed. The formula for median is: Median = ((n + 1)/2) th
> number in the series where the numbers are ordered. Here, n denotes the
> number of values for the given variable."
> DIVYA SPANDANA MARNEN, SPARQL-R: EXTENDED SPARQL FOR STATISTICAL COMPUTATIONS.
>
> example
>
> SELECT agg:median(?age) AS ?median
> WHERE
> { ?x ex:age ?age }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JENA-1721) Assemblers for DyadicDatasetGraphs
A. Soroka created JENA-1721:
---
Summary: Assemblers for DyadicDatasetGraphs
Key: JENA-1721
URL: https://issues.apache.org/jira/browse/JENA-1721
Project: Apache Jena
Issue Type: Improvement
Components: ARQ
Affects Versions: Jena 3.12.0
Reporter: A. Soroka
Assignee: A. Soroka
There should be assemblers for the subclasses of {{DyadicDatasetGraph}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1720) Apache commons-io needs to be added as dependency
[
https://issues.apache.org/jira/browse/JENA-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861413#comment-16861413
]
A. Soroka commented on JENA-1720:
-
Looking at [the
code|https://github.com/apache/jena/blob/master/jena-arq/src/main/java/org/apache/jena/riot/writer/JsonLDWriter.java#L180],
it appears that the error is thrown out of {{jsonld-java}}, the library that
Jena uses to read and write JSON-LD. I'm not sure why that would happen--
[~andy.seaborne], do you think it might be connected with [this
PR|https://github.com/apache/jena/pull/549] where we upgraded {{jsonld-java}}?
> Apache commons-io needs to be added as dependency
> -
>
> Key: JENA-1720
> URL: https://issues.apache.org/jira/browse/JENA-1720
> Project: Apache Jena
> Issue Type: Bug
> Components: Jena
>Affects Versions: Jena 3.12.0
>Reporter: Erich Bremer
>Priority: Minor
>
> In using RDFDataMgr.write(out, m, RDFFormat.JSONLD_PRETTY)
> to write out a Model as jsonld, an error was generated for a missing library
> found in apache commons-io. Adding
>
> commons-io
> commons-io
> 2.6
>
> to my maven project resolved the issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1720) Apache commons-io needs to be added as dependency
[ https://issues.apache.org/jira/browse/JENA-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861382#comment-16861382 ] A. Soroka commented on JENA-1720: - Can you show the whole stacktrace as well? > Apache commons-io needs to be added as dependency > - > > Key: JENA-1720 > URL: https://issues.apache.org/jira/browse/JENA-1720 > Project: Apache Jena > Issue Type: Bug > Components: Jena >Affects Versions: Jena 3.12.0 >Reporter: Erich Bremer >Priority: Minor > > In using RDFDataMgr.write(out, m, RDFFormat.JSONLD_PRETTY) > to write out a Model as jsonld, an error was generated for a missing library > found in apache commons-io. Adding > > commons-io > commons-io > 2.6 > > to my maven project resolved the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1720) Apache commons-io needs to be added as dependency
[
https://issues.apache.org/jira/browse/JENA-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861381#comment-16861381
]
A. Soroka commented on JENA-1720:
-
Incidentally, you'd do better to rely on {{apache-jena-libs}}, which doesn't
include CLI apparatus and other things an application using Jena as a library
needn't depend on.
> Apache commons-io needs to be added as dependency
> -
>
> Key: JENA-1720
> URL: https://issues.apache.org/jira/browse/JENA-1720
> Project: Apache Jena
> Issue Type: Bug
> Components: Jena
>Affects Versions: Jena 3.12.0
>Reporter: Erich Bremer
>Priority: Minor
>
> In using RDFDataMgr.write(out, m, RDFFormat.JSONLD_PRETTY)
> to write out a Model as jsonld, an error was generated for a missing library
> found in apache commons-io. Adding
>
> commons-io
> commons-io
> 2.6
>
> to my maven project resolved the issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1720) Apache commons-io needs to be added as dependency
[ https://issues.apache.org/jira/browse/JENA-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861379#comment-16861379 ] A. Soroka commented on JENA-1720: - When will that error be thrown? > Apache commons-io needs to be added as dependency > - > > Key: JENA-1720 > URL: https://issues.apache.org/jira/browse/JENA-1720 > Project: Apache Jena > Issue Type: Bug > Components: Jena >Affects Versions: Jena 3.12.0 >Reporter: Erich Bremer >Priority: Minor > > In using RDFDataMgr.write(out, m, RDFFormat.JSONLD_PRETTY) > to write out a Model as jsonld, an error was generated for a missing library > found in apache commons-io. Adding > > commons-io > commons-io > 2.6 > > to my maven project resolved the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1720) Apache commons-io needs to be added as dependency
[
https://issues.apache.org/jira/browse/JENA-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861365#comment-16861365
]
A. Soroka commented on JENA-1720:
-
What Jena dependency are you using? Can you attach your {{pom.xml}} to this
ticket?
> Apache commons-io needs to be added as dependency
> -
>
> Key: JENA-1720
> URL: https://issues.apache.org/jira/browse/JENA-1720
> Project: Apache Jena
> Issue Type: Bug
> Components: Jena
>Affects Versions: Jena 3.12.0
>Reporter: Erich Bremer
>Priority: Minor
>
> In using RDFDataMgr.write(out, m, RDFFormat.JSONLD_PRETTY)
> to write out a Model as jsonld, an error was generated for a missing library
> found in apache commons-io. Adding
>
> commons-io
> commons-io
> 2.6
>
> to my maven project resolved the issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1712) Update POMs to use https where appropriate.
[
https://issues.apache.org/jira/browse/JENA-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846893#comment-16846893
]
A. Soroka commented on JENA-1712:
-
{quote}The official URI (the concept) is currently
[http://|http://issues.apache.org/].
{quote}
[~andy.seaborne], you mean the URI for the concept in the RDF sense? (As
opposed to just a convenient URL for a link.)
> Update POMs to use https where appropriate.
> ---
>
> Key: JENA-1712
> URL: https://issues.apache.org/jira/browse/JENA-1712
> Project: Apache Jena
> Issue Type: Task
>Affects Versions: Jena 3.11.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.12.0
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1693) Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
[
https://issues.apache.org/jira/browse/JENA-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16839785#comment-16839785
]
A. Soroka commented on JENA-1693:
-
Narf. Shall I file an INFRA ticket to get our old users/roles scheme back? Do
you remember what it's called?
> Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
> --
>
> Key: JENA-1693
> URL: https://issues.apache.org/jira/browse/JENA-1693
> Project: Apache Jena
> Issue Type: New Feature
> Environment: general
>
>Reporter: Marco Neumann
>Priority: Minor
> Labels: features
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> As briefly mentioned to Andy Seaborne I'd like to see the aggregate function
> MEDIAN in the ARQ SPARQL syntax.
> "Median is the value that separates lower half from the higher half when the
> values are ordered in ascending or descending order. It is the middle value
> in a given dataset. Medians are helpful in understanding the distribution of
> data. This can be done by comparing mean and median values. By observing the
> difference between these values we can understand whether the data is left
> skewed or right skewed. The formula for median is: Median = ((n + 1)/2) th
> number in the series where the numbers are ordered. Here, n denotes the
> number of values for the given variable."
> DIVYA SPANDANA MARNEN, SPARQL-R: EXTENDED SPARQL FOR STATISTICAL COMPUTATIONS.
>
> example
>
> SELECT agg:median(?age) AS ?median
> WHERE
> { ?x ex:age ?age }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1693) Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
[
https://issues.apache.org/jira/browse/JENA-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16839778#comment-16839778
]
A. Soroka commented on JENA-1693:
-
m, still not able to assign to him. Maybe some time needs to pass for an update
to percolate. I'll try tomorrow. And as [~andy.seaborne] says, the record will
be clear.
> Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
> --
>
> Key: JENA-1693
> URL: https://issues.apache.org/jira/browse/JENA-1693
> Project: Apache Jena
> Issue Type: New Feature
> Environment: general
>
>Reporter: Marco Neumann
>Priority: Minor
> Labels: features
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> As briefly mentioned to Andy Seaborne I'd like to see the aggregate function
> MEDIAN in the ARQ SPARQL syntax.
> "Median is the value that separates lower half from the higher half when the
> values are ordered in ascending or descending order. It is the middle value
> in a given dataset. Medians are helpful in understanding the distribution of
> data. This can be done by comparing mean and median values. By observing the
> difference between these values we can understand whether the data is left
> skewed or right skewed. The formula for median is: Median = ((n + 1)/2) th
> number in the series where the numbers are ordered. Here, n denotes the
> number of values for the given variable."
> DIVYA SPANDANA MARNEN, SPARQL-R: EXTENDED SPARQL FOR STATISTICAL COMPUTATIONS.
>
> example
>
> SELECT agg:median(?age) AS ?median
> WHERE
> { ?x ex:age ?age }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1693) Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
[
https://issues.apache.org/jira/browse/JENA-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16839736#comment-16839736
]
A. Soroka commented on JENA-1693:
-
I'm afraid that our Jira instance doesn't work that way-- all assignees are
committers. Don't worry, we won't lose track of your contribution!
The PR machinery isn't part of Git, but of GitHub, so the easiest way for you
to do this will be to go to GitHub. The UI there features easy-to-use screens
that walk you through the process-- just start at your branch and let me know
if you run into any problems!
> Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
> --
>
> Key: JENA-1693
> URL: https://issues.apache.org/jira/browse/JENA-1693
> Project: Apache Jena
> Issue Type: New Feature
> Environment: general
>
>Reporter: Marco Neumann
>Priority: Minor
> Labels: features
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> As briefly mentioned to Andy Seaborne I'd like to see the aggregate function
> MEDIAN in the ARQ SPARQL syntax.
> "Median is the value that separates lower half from the higher half when the
> values are ordered in ascending or descending order. It is the middle value
> in a given dataset. Medians are helpful in understanding the distribution of
> data. This can be done by comparing mean and median values. By observing the
> difference between these values we can understand whether the data is left
> skewed or right skewed. The formula for median is: Median = ((n + 1)/2) th
> number in the series where the numbers are ordered. Here, n denotes the
> number of values for the given variable."
> DIVYA SPANDANA MARNEN, SPARQL-R: EXTENDED SPARQL FOR STATISTICAL COMPUTATIONS.
>
> example
>
> SELECT agg:median(?age) AS ?median
> WHERE
> { ?x ex:age ?age }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1693) Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
[
https://issues.apache.org/jira/browse/JENA-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16838861#comment-16838861
]
A. Soroka commented on JENA-1693:
-
[~neumarcx] the next step couldn't be simpler, just fire your PR at
{{apache/jena}} on GitHub and I'll review immediately!
> Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
> --
>
> Key: JENA-1693
> URL: https://issues.apache.org/jira/browse/JENA-1693
> Project: Apache Jena
> Issue Type: New Feature
> Environment: general
>
>Reporter: Marco Neumann
>Priority: Minor
> Labels: features
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> As briefly mentioned to Andy Seaborne I'd like to see the aggregate function
> MEDIAN in the ARQ SPARQL syntax.
> "Median is the value that separates lower half from the higher half when the
> values are ordered in ascending or descending order. It is the middle value
> in a given dataset. Medians are helpful in understanding the distribution of
> data. This can be done by comparing mean and median values. By observing the
> difference between these values we can understand whether the data is left
> skewed or right skewed. The formula for median is: Median = ((n + 1)/2) th
> number in the series where the numbers are ordered. Here, n denotes the
> number of values for the given variable."
> DIVYA SPANDANA MARNEN, SPARQL-R: EXTENDED SPARQL FOR STATISTICAL COMPUTATIONS.
>
> example
>
> SELECT agg:median(?age) AS ?median
> WHERE
> { ?x ex:age ?age }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1693) Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
[
https://issues.apache.org/jira/browse/JENA-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16837416#comment-16837416
]
A. Soroka commented on JENA-1693:
-
I'd be very happy to help you with a PR.
> Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
> --
>
> Key: JENA-1693
> URL: https://issues.apache.org/jira/browse/JENA-1693
> Project: Apache Jena
> Issue Type: New Feature
> Environment: general
>
>Reporter: Marco Neumann
>Priority: Minor
> Labels: features
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> As briefly mentioned to Andy Seaborne I'd like to see the aggregate function
> MEDIAN in the ARQ SPARQL syntax.
> "Median is the value that separates lower half from the higher half when the
> values are ordered in ascending or descending order. It is the middle value
> in a given dataset. Medians are helpful in understanding the distribution of
> data. This can be done by comparing mean and median values. By observing the
> difference between these values we can understand whether the data is left
> skewed or right skewed. The formula for median is: Median = ((n + 1)/2) th
> number in the series where the numbers are ordered. Here, n denotes the
> number of values for the given variable."
> DIVYA SPANDANA MARNEN, SPARQL-R: EXTENDED SPARQL FOR STATISTICAL COMPUTATIONS.
>
> example
>
> SELECT agg:median(?age) AS ?median
> WHERE
> { ?x ex:age ?age }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1693) Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
[
https://issues.apache.org/jira/browse/JENA-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833885#comment-16833885
]
A. Soroka commented on JENA-1693:
-
I'm not sure I want to do any cut-and-paste coding. :)
I should be able to take a look at this sometime late this week or next, but in
the meantime, if you have a good idea of how you would implement this as a
keyword, feel free to send a PR via GitHub.
> Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
> --
>
> Key: JENA-1693
> URL: https://issues.apache.org/jira/browse/JENA-1693
> Project: Apache Jena
> Issue Type: New Feature
> Environment: general
>
>Reporter: Marco Neumann
>Priority: Minor
> Labels: features
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> As briefly mentioned to Andy Seaborne I'd like to see the aggregate function
> MEDIAN in the ARQ SPARQL syntax.
> "Median is the value that separates lower half from the higher half when the
> values are ordered in ascending or descending order. It is the middle value
> in a given dataset. Medians are helpful in understanding the distribution of
> data. This can be done by comparing mean and median values. By observing the
> difference between these values we can understand whether the data is left
> skewed or right skewed. The formula for median is: Median = ((n + 1)/2) th
> number in the series where the numbers are ordered. Here, n denotes the
> number of values for the given variable."
> DIVYA SPANDANA MARNEN, SPARQL-R: EXTENDED SPARQL FOR STATISTICAL COMPUTATIONS.
>
> example
>
> SELECT agg:median(?age) AS ?median
> WHERE
> { ?x ex:age ?age }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1693) Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
[
https://issues.apache.org/jira/browse/JENA-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833854#comment-16833854
]
A. Soroka commented on JENA-1693:
-
[~neumarcx] it looks like you are just ignoring IRIs and bnodes. I'm not sure
that's the right choice here. If I remember correctly, out-of-domain values
should throw an error and eliminate that group from the solution set.
([~andy.seaborne] is that right?) Is there some particular reason that you
needed to ignore them instead, and would a design that errors out instead be
useful for you?
> Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
> --
>
> Key: JENA-1693
> URL: https://issues.apache.org/jira/browse/JENA-1693
> Project: Apache Jena
> Issue Type: New Feature
> Environment: general
>
>Reporter: Marco Neumann
>Priority: Minor
> Labels: features
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> As briefly mentioned to Andy Seaborne I'd like to see the aggregate function
> MEDIAN in the ARQ SPARQL syntax.
> "Median is the value that separates lower half from the higher half when the
> values are ordered in ascending or descending order. It is the middle value
> in a given dataset. Medians are helpful in understanding the distribution of
> data. This can be done by comparing mean and median values. By observing the
> difference between these values we can understand whether the data is left
> skewed or right skewed. The formula for median is: Median = ((n + 1)/2) th
> number in the series where the numbers are ordered. Here, n denotes the
> number of values for the given variable."
> DIVYA SPANDANA MARNEN, SPARQL-R: EXTENDED SPARQL FOR STATISTICAL COMPUTATIONS.
>
> example
>
> SELECT agg:median(?age) AS ?median
> WHERE
> { ?x ex:age ?age }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1693) Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
[
https://issues.apache.org/jira/browse/JENA-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16832605#comment-16832605
]
A. Soroka commented on JENA-1693:
-
I don't know quite what you mean-- there is no implementation, so I'm not using
anything for it, yet. I would be happy to use Commons Math, but I don't really
care as long as the implementation has reasonable characteristics and doesn't
widen our dependency footprint.
> Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
> --
>
> Key: JENA-1693
> URL: https://issues.apache.org/jira/browse/JENA-1693
> Project: Apache Jena
> Issue Type: New Feature
> Environment: general
>
>Reporter: Marco Neumann
>Priority: Minor
> Labels: features
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> As briefly mentioned to Andy Seaborne I'd like to see the aggregate function
> MEDIAN in the ARQ SPARQL syntax.
> "Median is the value that separates lower half from the higher half when the
> values are ordered in ascending or descending order. It is the middle value
> in a given dataset. Medians are helpful in understanding the distribution of
> data. This can be done by comparing mean and median values. By observing the
> difference between these values we can understand whether the data is left
> skewed or right skewed. The formula for median is: Median = ((n + 1)/2) th
> number in the series where the numbers are ordered. Here, n denotes the
> number of values for the given variable."
> DIVYA SPANDANA MARNEN, SPARQL-R: EXTENDED SPARQL FOR STATISTICAL COMPUTATIONS.
>
> example
>
> SELECT agg:median(?age) AS ?median
> WHERE
> { ?x ex:age ?age }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1693) Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
[
https://issues.apache.org/jira/browse/JENA-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16832572#comment-16832572
]
A. Soroka commented on JENA-1693:
-
I'm totally cool with that. [~neumarcx], does that meet your use case? (I would
think it would-- just checking.)
> Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
> --
>
> Key: JENA-1693
> URL: https://issues.apache.org/jira/browse/JENA-1693
> Project: Apache Jena
> Issue Type: New Feature
> Environment: general
>
>Reporter: Marco Neumann
>Priority: Minor
> Labels: features
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> As briefly mentioned to Andy Seaborne I'd like to see the aggregate function
> MEDIAN in the ARQ SPARQL syntax.
> "Median is the value that separates lower half from the higher half when the
> values are ordered in ascending or descending order. It is the middle value
> in a given dataset. Medians are helpful in understanding the distribution of
> data. This can be done by comparing mean and median values. By observing the
> difference between these values we can understand whether the data is left
> skewed or right skewed. The formula for median is: Median = ((n + 1)/2) th
> number in the series where the numbers are ordered. Here, n denotes the
> number of values for the given variable."
> DIVYA SPANDANA MARNEN, SPARQL-R: EXTENDED SPARQL FOR STATISTICAL COMPUTATIONS.
>
> example
>
> SELECT agg:median(?age) AS ?median
> WHERE
> { ?x ex:age ?age }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1704) Enable Apache Sonar reports
[ https://issues.apache.org/jira/browse/JENA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16832536#comment-16832536 ] A. Soroka commented on JENA-1704: - Ok, I'll take a look at our hook-points for doing this off of CI. I might take a look at Jenkins before Travis, just because Jenkins is Apache real estate and that's often a good thing. > Enable Apache Sonar reports > --- > > Key: JENA-1704 > URL: https://issues.apache.org/jira/browse/JENA-1704 > Project: Apache Jena > Issue Type: Improvement > Components: Build >Reporter: A. Soroka >Assignee: A. Soroka >Priority: Trivial > > Apache offers a Sonar service at [https://builds.apache.org/analysis.] We > should take advantage of it in a non-intrusive way. Enabling Sonar analysis > must not annoy anyone working on the codebase or make development less > pleasant, so it must be done carefully. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1693) Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
[
https://issues.apache.org/jira/browse/JENA-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16832534#comment-16832534
]
A. Soroka commented on JENA-1693:
-
Nope! Have you had a chance to take a crack at it?
I'm still not sure what our plan is here (see my question above as to whether
we are adding a keyword or a custom extension function).
> Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
> --
>
> Key: JENA-1693
> URL: https://issues.apache.org/jira/browse/JENA-1693
> Project: Apache Jena
> Issue Type: New Feature
> Environment: general
>
>Reporter: Marco Neumann
>Priority: Minor
> Labels: features
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> As briefly mentioned to Andy Seaborne I'd like to see the aggregate function
> MEDIAN in the ARQ SPARQL syntax.
> "Median is the value that separates lower half from the higher half when the
> values are ordered in ascending or descending order. It is the middle value
> in a given dataset. Medians are helpful in understanding the distribution of
> data. This can be done by comparing mean and median values. By observing the
> difference between these values we can understand whether the data is left
> skewed or right skewed. The formula for median is: Median = ((n + 1)/2) th
> number in the series where the numbers are ordered. Here, n denotes the
> number of values for the given variable."
> DIVYA SPANDANA MARNEN, SPARQL-R: EXTENDED SPARQL FOR STATISTICAL COMPUTATIONS.
>
> example
>
> SELECT agg:median(?age) AS ?median
> WHERE
> { ?x ex:age ?age }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1704) Enable Apache Sonar reports
[ https://issues.apache.org/jira/browse/JENA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16825232#comment-16825232 ] A. Soroka commented on JENA-1704: - What's being proposed is that a regularly-run process get data to Sonar, so that we can see how the analysis there changes over time. Manually running analysis when someone remembers doesn't accomplish that. I couldn't possibly care less where it happens (although I would be astonished if it noticeably delayed our build compared to the Elephas tests). I'm happy for it to come from CI. > Enable Apache Sonar reports > --- > > Key: JENA-1704 > URL: https://issues.apache.org/jira/browse/JENA-1704 > Project: Apache Jena > Issue Type: Improvement > Components: Build >Reporter: A. Soroka >Assignee: A. Soroka >Priority: Trivial > > Apache offers a Sonar service at [https://builds.apache.org/analysis.] We > should take advantage of it in a non-intrusive way. Enabling Sonar analysis > must not annoy anyone working on the codebase or make development less > pleasant, so it must be done carefully. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1704) Enable Apache Sonar reports
[ https://issues.apache.org/jira/browse/JENA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16825193#comment-16825193 ] A. Soroka commented on JENA-1704: - I'm not sure we're talking about the same thing, here, [~andy.seaborne]. I'm talking about adding a build step to send the data to Sonar (at Apache) and that's it. I'm not talking about failing builds or giving anyone any feedback at all. If anyone is interested in Sonar's opinions, they would have to actually go to [https://builds.apache.org/analysis] themselves and look for it. Does that seem less problematic? The interest of [~acoburn]'s advice is that if a module has problems running Sonar we don't have to fix them to use it for other modules. > Enable Apache Sonar reports > --- > > Key: JENA-1704 > URL: https://issues.apache.org/jira/browse/JENA-1704 > Project: Apache Jena > Issue Type: Improvement > Components: Build >Reporter: A. Soroka >Assignee: A. Soroka >Priority: Trivial > > Apache offers a Sonar service at [https://builds.apache.org/analysis.] We > should take advantage of it in a non-intrusive way. Enabling Sonar analysis > must not annoy anyone working on the codebase or make development less > pleasant, so it must be done carefully. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1704) Enable Apache Sonar reports
[
https://issues.apache.org/jira/browse/JENA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821153#comment-16821153
]
A. Soroka commented on JENA-1704:
-
On
[dev@jena|https://lists.apache.org/thread.html/3d41d82bbe5307346059e0cb03723e3e6da3d1681b412341ac881a2a@%3Cdev.jena.apache.org%3E]
[~acoburn] remarked:
{quote}{color:#00}It is possible to exclude specific modules from Sonar's
analysis (I do this{color}
{color:#00}with some of my own projects). The documentation for this is
here:{color}
[https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+Maven#AnalyzingwithSonarQubeScannerforMaven-ExcludingamodulefromSonarQubeanalysis]
{color:#00}Basically, you define this property in the module you want to
skip:{color}
{color:#00}true{color}
{color:#00}Aaron{color}
{quote}
> Enable Apache Sonar reports
> ---
>
> Key: JENA-1704
> URL: https://issues.apache.org/jira/browse/JENA-1704
> Project: Apache Jena
> Issue Type: Improvement
> Components: Build
>Reporter: A. Soroka
>Assignee: A. Soroka
>Priority: Trivial
>
> Apache offers a Sonar service at [https://builds.apache.org/analysis.] We
> should take advantage of it in a non-intrusive way. Enabling Sonar analysis
> must not annoy anyone working on the codebase or make development less
> pleasant, so it must be done carefully.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JENA-1704) Enable Apache Sonar reports
A. Soroka created JENA-1704: --- Summary: Enable Apache Sonar reports Key: JENA-1704 URL: https://issues.apache.org/jira/browse/JENA-1704 Project: Apache Jena Issue Type: Improvement Components: Build Reporter: A. Soroka Assignee: A. Soroka Apache offers a Sonar service at [https://builds.apache.org/analysis.] We should take advantage of it in a non-intrusive way. Enabling Sonar analysis must not annoy anyone working on the codebase or make development less pleasant, so it must be done carefully. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1703) Slim Fuseki combined artifacts NOTICE inclusions.
[ https://issues.apache.org/jira/browse/JENA-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816555#comment-16816555 ] A. Soroka commented on JENA-1703: - Excellent, thanks! > Slim Fuseki combined artifacts NOTICE inclusions. > - > > Key: JENA-1703 > URL: https://issues.apache.org/jira/browse/JENA-1703 > Project: Apache Jena > Issue Type: Task >Affects Versions: Jena 3.10.0 >Reporter: Andy Seaborne >Assignee: Andy Seaborne >Priority: Major > Fix For: Jena 3.11.0 > > Time Spent: 40m > Remaining Estimate: 0h > > The current jena-fuseki2 LICENSE and NOTICE setup is putting more than is > necessary. A combined NOTICE (which ends up being called `meta-inf/notice` > after the shader transformer has run) should only have required content (e.g. > acknwledgement for bianaries, especially forBSD and MIT with links to the > license). > Apache Lucene already produces a suitable "notice" and this gets rolled up > automatically (as do other Apache project dependencies). 3rd par ones tend > not to have anything in their binary jar files so we ought to put in the > required items in NOTICE at the point of shading. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1695) Refactory database storage for TDB2.
[
https://issues.apache.org/jira/browse/JENA-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816527#comment-16816527
]
A. Soroka commented on JENA-1695:
-
When this drops I will try to bring TIM over to it ASAP.
> Refactory database storage for TDB2.
>
>
> Key: JENA-1695
> URL: https://issues.apache.org/jira/browse/JENA-1695
> Project: Apache Jena
> Issue Type: Improvement
> Components: DBOE
>Affects Versions: Jena 3.11.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.12.0
>
>
> This ticket is for a new module (provisionally called "jena-db-storage") that
> is a framework for building RDF databases. It abstracts the database in to
> "triples+quads", "prefixes" and transactional control.
> {noformat}
> public interface DatabaseRDF {
> // Triples and Quads
> public StorageRDF getData();
> // Prefixes
> public StoragePrefixes getPrefixes();
> //Transactional} for this database.
> public Transactional getTransactional();
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1702) InputStream for HTTP constructModel queries are not closed
[
https://issues.apache.org/jira/browse/JENA-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816392#comment-16816392
]
A. Soroka commented on JENA-1702:
-
No prob [~trueg]! Always better to file and we can sort out dupes. If you don't
file, we may not have a chance to catch something new.
> InputStream for HTTP constructModel queries are not closed
> --
>
> Key: JENA-1702
> URL: https://issues.apache.org/jira/browse/JENA-1702
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.10.0
>Reporter: Sebastian Trüg
>Priority: Major
> Fix For: Jena 3.11.0
>
>
> I am accessing a Fuseki installation as follows:
> {code:java}
> String uri = fusekiHost + "/" + dataset;
> RDFConnection conn = RDFConnectionFuseki.create().destination(uri).build();
> try(RDFConnection conn = createConnection(dataModelDs)) {
> Model model = conn.queryConstruct("construct { ?s ?p ?o . } where { ?s ?p
> ?o . }");
> return model;
> }{code}
> The problem is that after 5 of these requests the Spring boot application
> this code runs in blocks due to the PoolingHttpClientConnectionManager
> running out of free routes.
> After lots of debugging I noticed that the InputStream that is used to read
> the data is never closed.
> InputStreams from "select" requests are closed in QueryEngineHTTP::close due
> to "retainedConnection" being set.
> The same is not true for "construct" queries since their results are parsed
> via RDFDataMgr which does not close the InputStream.
> I do not understand the code well enough to propose a proper solution but
> maybe just setting "retainedConnection" for construct queries would be
> enough? Either way, I think the stream needs to be closed somehow.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1702) InputStream for HTTP constructModel queries are not closed
[
https://issues.apache.org/jira/browse/JENA-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816382#comment-16816382
]
A. Soroka commented on JENA-1702:
-
Ha! Thanks, [~rvesse], the fix for JENA-1657 was exactly at the place I was
asking [~trueg] to look! No wonder I didn't see anything wrong there.
> InputStream for HTTP constructModel queries are not closed
> --
>
> Key: JENA-1702
> URL: https://issues.apache.org/jira/browse/JENA-1702
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.10.0
>Reporter: Sebastian Trüg
>Priority: Major
> Fix For: Jena 3.11.0
>
>
> I am accessing a Fuseki installation as follows:
> {code:java}
> String uri = fusekiHost + "/" + dataset;
> RDFConnection conn = RDFConnectionFuseki.create().destination(uri).build();
> try(RDFConnection conn = createConnection(dataModelDs)) {
> Model model = conn.queryConstruct("construct { ?s ?p ?o . } where { ?s ?p
> ?o . }");
> return model;
> }{code}
> The problem is that after 5 of these requests the Spring boot application
> this code runs in blocks due to the PoolingHttpClientConnectionManager
> running out of free routes.
> After lots of debugging I noticed that the InputStream that is used to read
> the data is never closed.
> InputStreams from "select" requests are closed in QueryEngineHTTP::close due
> to "retainedConnection" being set.
> The same is not true for "construct" queries since their results are parsed
> via RDFDataMgr which does not close the InputStream.
> I do not understand the code well enough to propose a proper solution but
> maybe just setting "retainedConnection" for construct queries would be
> enough? Either way, I think the stream needs to be closed somehow.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1703) Slim Fuseki combined artifacts NOTICE inclusions.
[
https://issues.apache.org/jira/browse/JENA-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816358#comment-16816358
]
A. Soroka commented on JENA-1703:
-
[~andy.seaborne] am I correct in understanding that one thing you are doing
here is moving all such material into the modules that build actual deployable
artifacts (as opposed to {{jena-fuseki2}}, {{jena-fuseki-core}}, etc.)?
> Slim Fuseki combined artifacts NOTICE inclusions.
> -
>
> Key: JENA-1703
> URL: https://issues.apache.org/jira/browse/JENA-1703
> Project: Apache Jena
> Issue Type: Task
>Affects Versions: Jena 3.10.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.11.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The current jena-fuseki2 LICENSE and NOTICE setup is putting more than is
> necessary. A combined NOTICE (which ends up being called `meta-inf/notice`
> after the shader transformer has run) should only have required content (e.g.
> acknwledgement for bianaries, especially forBSD and MIT with links to the
> license).
> Apache Lucene already produces a suitable "notice" and this gets rolled up
> automatically (as do other Apache project dependencies). 3rd par ones tend
> not to have anything in their binary jar files so we ought to put in the
> required items in NOTICE at the point of shading.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JENA-1702) InputStream for HTTP constructModel queries are not closed
[
https://issues.apache.org/jira/browse/JENA-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816327#comment-16816327
]
A. Soroka edited comment on JENA-1702 at 4/12/19 2:53 PM:
--
Hi, [~trueg]! Thanks for the report.
It could be that we're looking in two different code paths, but my tracing of
{{RDFConnection.queryConstruct(String)}} leads me (via
{{QueryExecution.execConstruct() => QueryEngineHTTP.execConstruct() =>
QueryEngineHTTP.execConstruct(Model)}} ) to
[this|https://github.com/apache/jena/blob/master/jena-arq/src/main/java/org/apache/jena/sparql/engine/http/QueryEngineHTTP.java#L440]
method:
{code:java}
private Model execModel(Model model) {
Pair p = execConstructWorker(modelContentType) ;
try(InputStream in = p.getLeft()) {
Lang lang = p.getRight() ;
RDFDataMgr.read(model, in, lang);
} catch (IOException ex) { IO.exception(ex); }
finally { this.close(); }
return model;
}
{code}
in which it seems that the {{InputStream}} is indeed being closed via
{{try-with-resource}} at line 440. Can you describe the code path you found in
which it is not?
Another question: are you closing the connection between each request (it looks
like that from your code)? I think that's not ideal-- I believe you can safely
reuse {{RDFConnection}} for a multi-request "conversation".
was (Author: ajs6f):
Hi, [~trueg]! Thanks for the report.
It could be that we're looking in two different code paths, but my tracing of
{{RDFConnection.queryConstruct(String)}} leads me (via
{{QueryExecution.execConstruct() => QueryEngineHTTP.execConstruct() =>
QueryEngineHTTP.execConstruct(Model)}}} ) to
[this|https://github.com/apache/jena/blob/master/jena-arq/src/main/java/org/apache/jena/sparql/engine/http/QueryEngineHTTP.java#L440]
method:
{code:java}
private Model execModel(Model model) {
Pair p = execConstructWorker(modelContentType) ;
try(InputStream in = p.getLeft()) {
Lang lang = p.getRight() ;
RDFDataMgr.read(model, in, lang);
} catch (IOException ex) { IO.exception(ex); }
finally { this.close(); }
return model;
}
{code}
in which it seems that the {{InputStream}} is indeed being closed via
{{try-with-resource}} at line 440. Can you describe the code path you found in
which it is not?
Another question: are you closing the connection between each request (it looks
like that from your code)? I think that's not ideal-- I believe you can safely
reuse {{RDFConnection}} for a multi-request "conversation".
> InputStream for HTTP constructModel queries are not closed
> --
>
> Key: JENA-1702
> URL: https://issues.apache.org/jira/browse/JENA-1702
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.10.0
>Reporter: Sebastian Trüg
>Priority: Major
>
> I am accessing a Fuseki installation as follows:
> {code:java}
> String uri = fusekiHost + "/" + dataset;
> RDFConnection conn = RDFConnectionFuseki.create().destination(uri).build();
> try(RDFConnection conn = createConnection(dataModelDs)) {
> Model model = conn.queryConstruct("construct { ?s ?p ?o . } where { ?s ?p
> ?o . }");
> return model;
> }{code}
> The problem is that after 5 of these requests the Spring boot application
> this code runs in blocks due to the PoolingHttpClientConnectionManager
> running out of free routes.
> After lots of debugging I noticed that the InputStream that is used to read
> the data is never closed.
> InputStreams from "select" requests are closed in QueryEngineHTTP::close due
> to "retainedConnection" being set.
> The same is not true for "construct" queries since their results are parsed
> via RDFDataMgr which does not close the InputStream.
> I do not understand the code well enough to propose a proper solution but
> maybe just setting "retainedConnection" for construct queries would be
> enough? Either way, I think the stream needs to be closed somehow.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1702) InputStream for HTTP constructModel queries are not closed
[
https://issues.apache.org/jira/browse/JENA-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816327#comment-16816327
]
A. Soroka commented on JENA-1702:
-
Hi, [~trueg]! Thanks for the report.
It could be that we're looking in two different code paths, but my tracing of
{{RDFConnection.queryConstruct(String)}} leads me (via
{{QueryExecution.execConstruct() => QueryEngineHTTP.execConstruct() =>
QueryEngineHTTP.execConstruct(Model)}}} ) to
[this|https://github.com/apache/jena/blob/master/jena-arq/src/main/java/org/apache/jena/sparql/engine/http/QueryEngineHTTP.java#L440]
method:
{code:java}
private Model execModel(Model model) {
Pair p = execConstructWorker(modelContentType) ;
try(InputStream in = p.getLeft()) {
Lang lang = p.getRight() ;
RDFDataMgr.read(model, in, lang);
} catch (IOException ex) { IO.exception(ex); }
finally { this.close(); }
return model;
}
{code}
in which it seems that the {{InputStream}} is indeed being closed via
{{try-with-resource}} at line 440. Can you describe the code path you found in
which it is not?
Another question: are you closing the connection between each request (it looks
like that from your code)? I think that's not ideal-- I believe you can safely
reuse {{RDFConnection}} for a multi-request "conversation".
> InputStream for HTTP constructModel queries are not closed
> --
>
> Key: JENA-1702
> URL: https://issues.apache.org/jira/browse/JENA-1702
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.10.0
>Reporter: Sebastian Trüg
>Priority: Major
>
> I am accessing a Fuseki installation as follows:
> {code:java}
> String uri = fusekiHost + "/" + dataset;
> RDFConnection conn = RDFConnectionFuseki.create().destination(uri).build();
> try(RDFConnection conn = createConnection(dataModelDs)) {
> Model model = conn.queryConstruct("construct { ?s ?p ?o . } where { ?s ?p
> ?o . }");
> return model;
> }{code}
> The problem is that after 5 of these requests the Spring boot application
> this code runs in blocks due to the PoolingHttpClientConnectionManager
> running out of free routes.
> After lots of debugging I noticed that the InputStream that is used to read
> the data is never closed.
> InputStreams from "select" requests are closed in QueryEngineHTTP::close due
> to "retainedConnection" being set.
> The same is not true for "construct" queries since their results are parsed
> via RDFDataMgr which does not close the InputStream.
> I do not understand the code well enough to propose a proper solution but
> maybe just setting "retainedConnection" for construct queries would be
> enough? Either way, I think the stream needs to be closed somehow.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1693) Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
[
https://issues.apache.org/jira/browse/JENA-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814675#comment-16814675
]
A. Soroka commented on JENA-1693:
-
Hey, [~andy.seaborne], {{CustomAggregate}} seems to work fine, so I can use it
as a model, but is the idea here to adopt {{MEDIAN}} as a new keyword (so that
I might look to the guys in {{oaj.sparql.expr.aggregate}} as examples to
follow, or as an custom extension (a la {{CustomAggregate)}} in which case, how
would we distribute it? As an example next to {{CustomAggregate}}? I'm cool any
which way-- I'm just not sure if we have a policy for when we go beyond the
spec.
> Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
> --
>
> Key: JENA-1693
> URL: https://issues.apache.org/jira/browse/JENA-1693
> Project: Apache Jena
> Issue Type: New Feature
> Environment: general
>
>Reporter: Marco Neumann
>Priority: Minor
> Labels: features
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> As briefly mentioned to Andy Seaborne I'd like to see the aggregate function
> MEDIAN in the ARQ SPARQL syntax.
> "Median is the value that separates lower half from the higher half when the
> values are ordered in ascending or descending order. It is the middle value
> in a given dataset. Medians are helpful in understanding the distribution of
> data. This can be done by comparing mean and median values. By observing the
> difference between these values we can understand whether the data is left
> skewed or right skewed. The formula for median is: Median = ((n + 1)/2) th
> number in the series where the numbers are ordered. Here, n denotes the
> number of values for the given variable."
> DIVYA SPANDANA MARNEN, SPARQL-R: EXTENDED SPARQL FOR STATISTICAL COMPUTATIONS.
>
> example
>
> SELECT agg:median(?age) AS ?median
> WHERE
> { ?x ex:age ?age }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1693) Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
[
https://issues.apache.org/jira/browse/JENA-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808726#comment-16808726
]
A. Soroka commented on JENA-1693:
-
So there's one question: do we currently make any assumptions or guarantees
around {{Aggregator}} that I will need to honor? I think a {{MEDIAN}} that
builds up state could still be useful with appropriate documentation.
Is
[CustomAggregate|https://github.com/apache/jena/blob/master/jena-arq/src-examples/arq/examples/aggregates/CustomAggregate.java]
a good example of registering a custom aggregator?
> Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
> --
>
> Key: JENA-1693
> URL: https://issues.apache.org/jira/browse/JENA-1693
> Project: Apache Jena
> Issue Type: New Feature
> Environment: general
>
>Reporter: Marco Neumann
>Priority: Minor
> Labels: features
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> As briefly mentioned to Andy Seaborne I'd like to see the aggregate function
> MEDIAN in the ARQ SPARQL syntax.
> "Median is the value that separates lower half from the higher half when the
> values are ordered in ascending or descending order. It is the middle value
> in a given dataset. Medians are helpful in understanding the distribution of
> data. This can be done by comparing mean and median values. By observing the
> difference between these values we can understand whether the data is left
> skewed or right skewed. The formula for median is: Median = ((n + 1)/2) th
> number in the series where the numbers are ordered. Here, n denotes the
> number of values for the given variable."
> DIVYA SPANDANA MARNEN, SPARQL-R: EXTENDED SPARQL FOR STATISTICAL COMPUTATIONS.
>
> example
>
> SELECT agg:median(?age) AS ?median
> WHERE
> { ?x ex:age ?age }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1693) Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
[
https://issues.apache.org/jira/browse/JENA-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808116#comment-16808116
]
A. Soroka commented on JENA-1693:
-
Well, this is timely: a [W3C Community
Group|https://www.w3.org/community/sparql-12/] has formed to document user
needs and make and organize suggestions for new SPARQL features for a 1.2 spec.
You should definitely bring ideas for new aggregation functions!
> Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
> --
>
> Key: JENA-1693
> URL: https://issues.apache.org/jira/browse/JENA-1693
> Project: Apache Jena
> Issue Type: New Feature
> Environment: general
>
>Reporter: Marco Neumann
>Priority: Minor
> Labels: features
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> As briefly mentioned to Andy Seaborne I'd like to see the aggregate function
> MEDIAN in the ARQ SPARQL syntax.
> "Median is the value that separates lower half from the higher half when the
> values are ordered in ascending or descending order. It is the middle value
> in a given dataset. Medians are helpful in understanding the distribution of
> data. This can be done by comparing mean and median values. By observing the
> difference between these values we can understand whether the data is left
> skewed or right skewed. The formula for median is: Median = ((n + 1)/2) th
> number in the series where the numbers are ordered. Here, n denotes the
> number of values for the given variable."
> DIVYA SPANDANA MARNEN, SPARQL-R: EXTENDED SPARQL FOR STATISTICAL COMPUTATIONS.
>
> example
>
> SELECT agg:median(?age) AS ?median
> WHERE
> { ?x ex:age ?age }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1693) Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
[
https://issues.apache.org/jira/browse/JENA-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804329#comment-16804329
]
A. Soroka commented on JENA-1693:
-
[~andy.seaborne], if you can give me a pointer to the right extension point I
might try to knock this off.
> Add Aggregate Function MEDIAN To SPARQL ARQ Syntax
> --
>
> Key: JENA-1693
> URL: https://issues.apache.org/jira/browse/JENA-1693
> Project: Apache Jena
> Issue Type: New Feature
> Environment: general
>
>Reporter: Marco Neumann
>Priority: Minor
> Labels: features
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> As briefly mentioned to Andy Seaborne I'd like to see the aggregate function
> MEDIAN in the ARQ SPARQL syntax.
> "Median is the value that separates lower half from the higher half when the
> values are ordered in ascending or descending order. It is the middle value
> in a given dataset. Medians are helpful in understanding the distribution of
> data. This can be done by comparing mean and median values. By observing the
> difference between these values we can understand whether the data is left
> skewed or right skewed. The formula for median is: Median = ((n + 1)/2) th
> number in the series where the numbers are ordered. Here, n denotes the
> number of values for the given variable."
> DIVYA SPANDANA MARNEN, SPARQL-R: EXTENDED SPARQL FOR STATISTICAL COMPUTATIONS.
>
> example
>
> SELECT agg:median(?age) AS ?median
> WHERE
> { ?x ex:age ?age }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1695) Refactory database storage for TDB2.
[
https://issues.apache.org/jira/browse/JENA-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16803084#comment-16803084
]
A. Soroka commented on JENA-1695:
-
Looks like {{StorageRDF}} is pretty similar to current {{DatasetGraph}} , eh?
> Refactory database storage for TDB2.
>
>
> Key: JENA-1695
> URL: https://issues.apache.org/jira/browse/JENA-1695
> Project: Apache Jena
> Issue Type: Improvement
> Components: DBOE
>Affects Versions: Jena 3.11.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.12.0
>
>
> This ticket is for a new module (provisionally called "jena-db-storage") that
> is a framework for building RDF databases. It abstracts the database in to
> "triples+quads", "prefixes" and transactional control.
> {noformat}
> public interface DatabaseRDF {
> // Triples and Quads
> public StorageRDF getData();
> // Prefixes
> public StoragePrefixes getPrefixes();
> //Transactional} for this database.
> public Transactional getTransactional();
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1687) Precise return types of NodeFactory methods
[
https://issues.apache.org/jira/browse/JENA-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798958#comment-16798958
]
A. Soroka commented on JENA-1687:
-
[~jmkeil], I'm trying to understand why you are using the SPI (which is
normally meant for implementation by new backends or the like) instead of the
API. That is to say, why are you manipulating {{Graph}}s and not {{Model}}s,
{{Node}}s and not {{Resource}}s, etc.?
> Precise return types of NodeFactory methods
> ---
>
> Key: JENA-1687
> URL: https://issues.apache.org/jira/browse/JENA-1687
> Project: Apache Jena
> Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I propose to precise the return types of the NodeFactory methods, e.g. to set
> NodeFactory#createURI return type to Node_URI. This makes the developers life
> easier, as there is no longer a need to cast after creating a Node, if one
> need a specific node type. I can not see any disadvantages and it should be
> backward compatible (except of classes that override these methods).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JENA-1687) Precise return types of NodeFactory methods
[
https://issues.apache.org/jira/browse/JENA-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798958#comment-16798958
]
A. Soroka edited comment on JENA-1687 at 3/22/19 12:18 PM:
---
[~jmkeil], I'm trying to understand why you are using the SPI (which is
normally meant for implementation by new backends or the like) instead of the
API. That is to say, why are you manipulating \{{Graph}} s and not \{{Model}}
s, \{{Node}} s and not \{{Resource}} s, etc.?
was (Author: ajs6f):
[~jmkeil], I'm trying to understand why you are using the SPI (which is
normally meant for implementation by new backends or the like) instead of the
API. That is to say, why are you manipulating {{Graph}}s and not {{Model}}s,
{{Node}}s and not {{Resource}}s, etc.?
> Precise return types of NodeFactory methods
> ---
>
> Key: JENA-1687
> URL: https://issues.apache.org/jira/browse/JENA-1687
> Project: Apache Jena
> Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I propose to precise the return types of the NodeFactory methods, e.g. to set
> NodeFactory#createURI return type to Node_URI. This makes the developers life
> easier, as there is no longer a need to cast after creating a Node, if one
> need a specific node type. I can not see any disadvantages and it should be
> backward compatible (except of classes that override these methods).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1687) Precise return types of NodeFactory methods
[
https://issues.apache.org/jira/browse/JENA-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798261#comment-16798261
]
A. Soroka commented on JENA-1687:
-
Hi, [~jmkeil], can you explain a bit about your own use case for this change?
I'm not nearly as experienced as [~andy.seaborne], but I've often found that
when people are writing code that needs to distinguish efficiently between the
subtypes of {{Node}}, it's sometimes because they're doing something that might
be more easily done in the ({{Dataset/Model/Statement/RDFNode}}) API and not
the ({{DatasetGraph/Graph/Triple/Node}}) SPI.
> Precise return types of NodeFactory methods
> ---
>
> Key: JENA-1687
> URL: https://issues.apache.org/jira/browse/JENA-1687
> Project: Apache Jena
> Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I propose to precise the return types of the NodeFactory methods, e.g. to set
> NodeFactory#createURI return type to Node_URI. This makes the developers life
> easier, as there is no longer a need to cast after creating a Node, if one
> need a specific node type. I can not see any disadvantages and it should be
> backward compatible (except of classes that override these methods).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JENA-1675) Simple typo
[ https://issues.apache.org/jira/browse/JENA-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Soroka updated JENA-1675: Fix Version/s: (was: Jena 3.11.0) > Simple typo > --- > > Key: JENA-1675 > URL: https://issues.apache.org/jira/browse/JENA-1675 > Project: Apache Jena > Issue Type: Bug > Components: Documentation >Reporter: Kofi shango >Assignee: A. Soroka >Priority: Trivial > Labels: documentation, newbie > > On the page [https://jena.apache.org/tutorials/sparql_datasets.html] > There is a line "Datasets don't have to created just for the lifetime of the > query." > That should be "Datasets don't have to be created just for the lifetime of > the query." -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (JENA-1675) Simple typo
[ https://issues.apache.org/jira/browse/JENA-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Soroka resolved JENA-1675. - Resolution: Fixed Assignee: A. Soroka Fix Version/s: Jena 3.11.0 > Simple typo > --- > > Key: JENA-1675 > URL: https://issues.apache.org/jira/browse/JENA-1675 > Project: Apache Jena > Issue Type: Bug > Components: Documentation >Reporter: Kofi shango >Assignee: A. Soroka >Priority: Trivial > Labels: documentation, newbie > Fix For: Jena 3.11.0 > > > On the page [https://jena.apache.org/tutorials/sparql_datasets.html] > There is a line "Datasets don't have to created just for the lifetime of the > query." > That should be "Datasets don't have to be created just for the lifetime of > the query." -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1675) Simple typo
[ https://issues.apache.org/jira/browse/JENA-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779989#comment-16779989 ] A. Soroka commented on JENA-1675: - Thank you very much, [~shangok], committed with [https://svn.apache.org/viewvc?view=revision=1854492] . The change will appear the next time we publish the documentation site, which we do with every release and sometimes in between. > Simple typo > --- > > Key: JENA-1675 > URL: https://issues.apache.org/jira/browse/JENA-1675 > Project: Apache Jena > Issue Type: Bug > Components: Documentation >Reporter: Kofi shango >Priority: Trivial > Labels: documentation, newbie > > On the page [https://jena.apache.org/tutorials/sparql_datasets.html] > There is a line "Datasets don't have to created just for the lifetime of the > query." > That should be "Datasets don't have to be created just for the lifetime of > the query." -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1675) Simple typo
[ https://issues.apache.org/jira/browse/JENA-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779783#comment-16779783 ] A. Soroka commented on JENA-1675: - [~shangok], thanks very much for the report! Would you like to try fixing it yourself? If you look in the upper-right corner of that page, you will see a button marked "Improve this page". Clicking it will take you to a form which will allow you to send us a correction. We can then commit it. Let me know if that seems do-able for you. > Simple typo > --- > > Key: JENA-1675 > URL: https://issues.apache.org/jira/browse/JENA-1675 > Project: Apache Jena > Issue Type: Bug > Components: Documentation >Reporter: Kofi shango >Priority: Trivial > Labels: documentation, newbie > > On the page [https://jena.apache.org/tutorials/sparql_datasets.html] > There is a line "Datasets don't have to created just for the lifetime of the > query." > That should be "Datasets don't have to be created just for the lifetime of > the query." -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1601) Make ClosableIterator extend AutoCloseable
[
https://issues.apache.org/jira/browse/JENA-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16778158#comment-16778158
]
A. Soroka commented on JENA-1601:
-
I suspect that adding Jena-specific methods might be useful, but not nearly to
same degree. it's not the usual idiom.
> Make ClosableIterator extend AutoCloseable
> -
>
> Key: JENA-1601
> URL: https://issues.apache.org/jira/browse/JENA-1601
> Project: Apache Jena
> Issue Type: Improvement
> Components: Jena
>Affects Versions: Jena 3.8.0
>Reporter: David Schwingenschlögl
>Assignee: Andy Seaborne
>Priority: Minor
>
> The interface org.apache.jena.util.iterator.ClosableIterator defines a
> method public void close(), so the concept of closing is already baked into
> it. The only barrier to using a ClosableIterator (and thus, ExtendedIterator)
> in a try-with-resource block is the missing extension of
> java.lang.AutoCloseable.
> According to API documentation of ClosableIterator, an iterator should be
> closed when not completely exhausted, which may be the case when the block
> consuming the iterator throws an exception, effectively making constructs
> such as this necessary:
> {code:java}
> final ExtendedIterator iterator = someGraph.find();
> try {
> while (iterator.hasNext()) {
> // consume iterator, might throw in here
> }
> } finally {
> // Prevent resource leaks
> iterator.close();
> }
> {code}
> This would be better expressed in a try-with-resource-construct:
> {code:java}
> try (final ExtendedIterator itrator = someGraph.find()) {
> // consume iterator, might throw in here
> }
> {code}
> From what I can tell, making a ClosableIterator also extend AutoCloseable
> only adds to the usability of Jena's API while keeping source backwards
> compatibility intact.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JENA-1669) Load TIM indexes in parallel
A. Soroka created JENA-1669: --- Summary: Load TIM indexes in parallel Key: JENA-1669 URL: https://issues.apache.org/jira/browse/JENA-1669 Project: Apache Jena Issue Type: Improvement Components: TIM Affects Versions: Jena 3.10.0 Reporter: A. Soroka Assignee: A. Soroka In theory, it should be possible to load the individual indexes in TIM in parallel for bulk loading speed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1666) Securing TDB dataset with SecurityEvaluator
[
https://issues.apache.org/jira/browse/JENA-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16766348#comment-16766348
]
A. Soroka commented on JENA-1666:
-
Pinging [~claudenw], who is most expert with {{jena-permissions}}…
> Securing TDB dataset with SecurityEvaluator
> ---
>
> Key: JENA-1666
> URL: https://issues.apache.org/jira/browse/JENA-1666
> Project: Apache Jena
> Issue Type: Question
> Components: Fuseki, Jena, Permissions, Security, TDB2
>Reporter: Vasyl Danyliuk
>Assignee: Claude Warren
>Priority: Minor
>
> Hi guys,
> Can someone take a look if approach used in [this
> repository|https://github.com/linked-solutions/fuseki-auth] can be
> incorporated into Jena Permission project? Also, there is a question on
> [StackOverflow|https://stackoverflow.com/questions/54268950/how-to-secure-all-newly-created-graphs-in-apache-fuseki-with-securityevaluator]
> The main idea is to apply SecurityEvaluator to whole dataset instead of one
> graph.
> This repository, of course, is not ready to be incorporated just now, but if
> it's possible in general and does not conflict with the
> structure/architecture of the project I will refactor it to be more
> consistent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1608) different output when processing json-ld in the playground and in riot - solved in
[ https://issues.apache.org/jira/browse/JENA-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630152#comment-16630152 ] A. Soroka commented on JENA-1608: - The JSON-LD playground is _not_ authoritative (although of course it is extremely useful). The specifications are, and Jena relies on [json-ld-java|https://github.com/jsonld-java/jsonld-java] to implement them. We can check to see if there is an error here or in how Jena is moving information to json-ld-java, but the code that is generating JSON-LD is not part of Jena's codebase so there may be a limited amount we can do. > different output when processing json-ld in the playground and in riot - > solved in > --- > > Key: JENA-1608 > URL: https://issues.apache.org/jira/browse/JENA-1608 > Project: Apache Jena > Issue Type: Bug > Components: RIOT >Affects Versions: Jena 3.6.0, Jena 3.8.0 >Reporter: andrew u frank >Priority: Minor > Labels: newbie > Attachments: problem.jsonld, problem.ttl, > problem_output_playground.txt > > > I have the json-ld document [^problem.jsonld] processed on the json-ld > playground (which I assume is authoritative) and get the result > [^problem_output_playground.txt]. if I process the same file with RIOT the > result is different, namely [^problem.ttl]. > The difference is simply that RIOT does not include the rdf-objects which are > not using a blank node as identifier. If a line > "@base": "http://gerastree.at/lit_2014#" > is added to the context, the output seems to conform to what is produced by > the playground. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1608) different output when processing json-ld in the playground and in riot - solved in
[ https://issues.apache.org/jira/browse/JENA-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630147#comment-16630147 ] A. Soroka commented on JENA-1608: - Not before JSON-LD 1.1. is actually released as a W3C recommendation: [https://www.w3.org/2018/03/jsonld-wg-charter.html] I am a Jena committer and a member of that working group, so Jena is fully apprised of what is happening there. > different output when processing json-ld in the playground and in riot - > solved in > --- > > Key: JENA-1608 > URL: https://issues.apache.org/jira/browse/JENA-1608 > Project: Apache Jena > Issue Type: Bug > Components: RIOT >Affects Versions: Jena 3.6.0, Jena 3.8.0 >Reporter: andrew u frank >Priority: Minor > Labels: newbie > Attachments: problem.jsonld, problem.ttl, > problem_output_playground.txt > > > I have the json-ld document [^problem.jsonld] processed on the json-ld > playground (which I assume is authoritative) and get the result > [^problem_output_playground.txt]. if I process the same file with RIOT the > result is different, namely [^problem.ttl]. > The difference is simply that RIOT does not include the rdf-objects which are > not using a blank node as identifier. If a line > "@base": "http://gerastree.at/lit_2014#" > is added to the context, the output seems to conform to what is produced by > the playground. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (JENA-1605) spatialindexer doesn't use transactions
[
https://issues.apache.org/jira/browse/JENA-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Soroka resolved JENA-1605.
-
Resolution: Fixed
> spatialindexer doesn't use transactions
> ---
>
> Key: JENA-1605
> URL: https://issues.apache.org/jira/browse/JENA-1605
> Project: Apache Jena
> Issue Type: Bug
> Components: Spatial
>Affects Versions: Jena 3.8.0
>Reporter: A. Soroka
>Assignee: A. Soroka
>Priority: Minor
> Fix For: Jena 3.9.0
>
>
> The {{spatialindexer}} does not use a transaction to work with the
> {{Dataset}} it is indexing, which causes problems with TDB2 datasets.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JENA-1605) spatialindexer doesn't use transactions
A. Soroka created JENA-1605:
---
Summary: spatialindexer doesn't use transactions
Key: JENA-1605
URL: https://issues.apache.org/jira/browse/JENA-1605
Project: Apache Jena
Issue Type: Bug
Components: Spatial
Affects Versions: Jena 3.8.0
Reporter: A. Soroka
Assignee: A. Soroka
Fix For: Jena 3.9.0
The {{spatialindexer}} does not use a transaction to work with the {{Dataset}}
it is indexing, which causes problems with TDB2 datasets.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (JENA-1604) Add request hook for HTTP query execution
[ https://issues.apache.org/jira/browse/JENA-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Soroka closed JENA-1604. --- > Add request hook for HTTP query execution > - > > Key: JENA-1604 > URL: https://issues.apache.org/jira/browse/JENA-1604 > Project: Apache Jena > Issue Type: Improvement > Components: ARQ, Jena >Affects Versions: Jena 3.8.0 >Reporter: Niraj Patel >Assignee: A. Soroka >Priority: Minor > Labels: http > Fix For: Jena 3.9.0 > > > I am using Jena's QueryEngineHTTP for queries and RemoteUpdateRequest for > updates. I would like to send a custom header that will differ on each > request. Our database, Allegrograph, allows us to pass down custom headers > while querying or updating in order to store that information in access logs. > For each SPARQL request we want to send down unique request markers and > usernames in order to be able to trace from a UI click to backend calls to > queries that were performed in the graph. I did some digging around and it > seems like it's not possible. Using default headers when configuring Apache's > Http Client wouldn't work in this case. The suggestion [~andy.seaborne] made > was to create a request hook in HttpOp where we could add additional headers > as necessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JENA-1604) Add request hook for HTTP query execution
[ https://issues.apache.org/jira/browse/JENA-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Soroka updated JENA-1604: Priority: Minor (was: Critical) > Add request hook for HTTP query execution > - > > Key: JENA-1604 > URL: https://issues.apache.org/jira/browse/JENA-1604 > Project: Apache Jena > Issue Type: Improvement > Components: ARQ, Jena >Affects Versions: Jena 3.8.0 >Reporter: Niraj Patel >Assignee: A. Soroka >Priority: Minor > Labels: http > Fix For: Jena 3.9.0 > > > I am using Jena's QueryEngineHTTP for queries and RemoteUpdateRequest for > updates. I would like to send a custom header that will differ on each > request. Our database, Allegrograph, allows us to pass down custom headers > while querying or updating in order to store that information in access logs. > For each SPARQL request we want to send down unique request markers and > usernames in order to be able to trace from a UI click to backend calls to > queries that were performed in the graph. I did some digging around and it > seems like it's not possible. Using default headers when configuring Apache's > Http Client wouldn't work in this case. The suggestion [~andy.seaborne] made > was to create a request hook in HttpOp where we could add additional headers > as necessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JENA-1604) Add request hook for HTTP query execution
[ https://issues.apache.org/jira/browse/JENA-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Soroka updated JENA-1604: Issue Type: Improvement (was: Task) > Add request hook for HTTP query execution > - > > Key: JENA-1604 > URL: https://issues.apache.org/jira/browse/JENA-1604 > Project: Apache Jena > Issue Type: Improvement > Components: ARQ, Jena >Affects Versions: Jena 3.8.0 >Reporter: Niraj Patel >Assignee: A. Soroka >Priority: Critical > Labels: http > Fix For: Jena 3.9.0 > > > I am using Jena's QueryEngineHTTP for queries and RemoteUpdateRequest for > updates. I would like to send a custom header that will differ on each > request. Our database, Allegrograph, allows us to pass down custom headers > while querying or updating in order to store that information in access logs. > For each SPARQL request we want to send down unique request markers and > usernames in order to be able to trace from a UI click to backend calls to > queries that were performed in the graph. I did some digging around and it > seems like it's not possible. Using default headers when configuring Apache's > Http Client wouldn't work in this case. The suggestion [~andy.seaborne] made > was to create a request hook in HttpOp where we could add additional headers > as necessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (JENA-1604) Add request hook for HTTP query execution
[ https://issues.apache.org/jira/browse/JENA-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Soroka resolved JENA-1604. - Resolution: Fixed > Add request hook for HTTP query execution > - > > Key: JENA-1604 > URL: https://issues.apache.org/jira/browse/JENA-1604 > Project: Apache Jena > Issue Type: Improvement > Components: ARQ, Jena >Affects Versions: Jena 3.8.0 >Reporter: Niraj Patel >Assignee: A. Soroka >Priority: Minor > Labels: http > Fix For: Jena 3.9.0 > > > I am using Jena's QueryEngineHTTP for queries and RemoteUpdateRequest for > updates. I would like to send a custom header that will differ on each > request. Our database, Allegrograph, allows us to pass down custom headers > while querying or updating in order to store that information in access logs. > For each SPARQL request we want to send down unique request markers and > usernames in order to be able to trace from a UI click to backend calls to > queries that were performed in the graph. I did some digging around and it > seems like it's not possible. Using default headers when configuring Apache's > Http Client wouldn't work in this case. The suggestion [~andy.seaborne] made > was to create a request hook in HttpOp where we could add additional headers > as necessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (JENA-1604) Add request hook for HTTP query execution
[ https://issues.apache.org/jira/browse/JENA-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Soroka reopened JENA-1604: - > Add request hook for HTTP query execution > - > > Key: JENA-1604 > URL: https://issues.apache.org/jira/browse/JENA-1604 > Project: Apache Jena > Issue Type: Task > Components: ARQ, Jena >Affects Versions: Jena 3.8.0 >Reporter: Niraj Patel >Assignee: A. Soroka >Priority: Critical > Labels: http > Fix For: Jena 3.9.0 > > > I am using Jena's QueryEngineHTTP for queries and RemoteUpdateRequest for > updates. I would like to send a custom header that will differ on each > request. Our database, Allegrograph, allows us to pass down custom headers > while querying or updating in order to store that information in access logs. > For each SPARQL request we want to send down unique request markers and > usernames in order to be able to trace from a UI click to backend calls to > queries that were performed in the graph. I did some digging around and it > seems like it's not possible. Using default headers when configuring Apache's > Http Client wouldn't work in this case. The suggestion [~andy.seaborne] made > was to create a request hook in HttpOp where we could add additional headers > as necessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (JENA-1604) Add request hook for HTTP query execution
[ https://issues.apache.org/jira/browse/JENA-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Soroka resolved JENA-1604. - Resolution: Fixed > Add request hook for HTTP query execution > - > > Key: JENA-1604 > URL: https://issues.apache.org/jira/browse/JENA-1604 > Project: Apache Jena > Issue Type: Task > Components: ARQ, Jena >Affects Versions: Jena 3.8.0 >Reporter: Niraj Patel >Assignee: A. Soroka >Priority: Critical > Labels: http > Fix For: Jena 3.9.0 > > > I am using Jena's QueryEngineHTTP for queries and RemoteUpdateRequest for > updates. I would like to send a custom header that will differ on each > request. Our database, Allegrograph, allows us to pass down custom headers > while querying or updating in order to store that information in access logs. > For each SPARQL request we want to send down unique request markers and > usernames in order to be able to trace from a UI click to backend calls to > queries that were performed in the graph. I did some digging around and it > seems like it's not possible. Using default headers when configuring Apache's > Http Client wouldn't work in this case. The suggestion [~andy.seaborne] made > was to create a request hook in HttpOp where we could add additional headers > as necessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JENA-1604) Add request hook for HTTP query execution
[ https://issues.apache.org/jira/browse/JENA-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Soroka updated JENA-1604: Affects Version/s: Jena 3.8.0 > Add request hook for HTTP query execution > - > > Key: JENA-1604 > URL: https://issues.apache.org/jira/browse/JENA-1604 > Project: Apache Jena > Issue Type: Task > Components: ARQ, Jena >Affects Versions: Jena 3.8.0 >Reporter: Niraj Patel >Assignee: A. Soroka >Priority: Critical > Labels: http > Fix For: Jena 3.9.0 > > > I am using Jena's QueryEngineHTTP for queries and RemoteUpdateRequest for > updates. I would like to send a custom header that will differ on each > request. Our database, Allegrograph, allows us to pass down custom headers > while querying or updating in order to store that information in access logs. > For each SPARQL request we want to send down unique request markers and > usernames in order to be able to trace from a UI click to backend calls to > queries that were performed in the graph. I did some digging around and it > seems like it's not possible. Using default headers when configuring Apache's > Http Client wouldn't work in this case. The suggestion [~andy.seaborne] made > was to create a request hook in HttpOp where we could add additional headers > as necessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (JENA-1604) Add request hook for HTTP query execution
[ https://issues.apache.org/jira/browse/JENA-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Soroka closed JENA-1604. --- > Add request hook for HTTP query execution > - > > Key: JENA-1604 > URL: https://issues.apache.org/jira/browse/JENA-1604 > Project: Apache Jena > Issue Type: Task > Components: ARQ, Jena >Affects Versions: Jena 3.8.0 >Reporter: Niraj Patel >Assignee: A. Soroka >Priority: Critical > Labels: http > Fix For: Jena 3.9.0 > > > I am using Jena's QueryEngineHTTP for queries and RemoteUpdateRequest for > updates. I would like to send a custom header that will differ on each > request. Our database, Allegrograph, allows us to pass down custom headers > while querying or updating in order to store that information in access logs. > For each SPARQL request we want to send down unique request markers and > usernames in order to be able to trace from a UI click to backend calls to > queries that were performed in the graph. I did some digging around and it > seems like it's not possible. Using default headers when configuring Apache's > Http Client wouldn't work in this case. The suggestion [~andy.seaborne] made > was to create a request hook in HttpOp where we could add additional headers > as necessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JENA-1604) Add request hook for HTTP query execution
[ https://issues.apache.org/jira/browse/JENA-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Soroka updated JENA-1604: Labels: http (was: ) > Add request hook for HTTP query execution > - > > Key: JENA-1604 > URL: https://issues.apache.org/jira/browse/JENA-1604 > Project: Apache Jena > Issue Type: Task > Components: ARQ, Jena >Affects Versions: Jena 3.8.0 >Reporter: Niraj Patel >Assignee: A. Soroka >Priority: Critical > Labels: http > Fix For: Jena 3.9.0 > > > I am using Jena's QueryEngineHTTP for queries and RemoteUpdateRequest for > updates. I would like to send a custom header that will differ on each > request. Our database, Allegrograph, allows us to pass down custom headers > while querying or updating in order to store that information in access logs. > For each SPARQL request we want to send down unique request markers and > usernames in order to be able to trace from a UI click to backend calls to > queries that were performed in the graph. I did some digging around and it > seems like it's not possible. Using default headers when configuring Apache's > Http Client wouldn't work in this case. The suggestion [~andy.seaborne] made > was to create a request hook in HttpOp where we could add additional headers > as necessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (JENA-1604) Add request hook for HTTP query execution
[ https://issues.apache.org/jira/browse/JENA-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Soroka reopened JENA-1604: - Changing Jira fields > Add request hook for HTTP query execution > - > > Key: JENA-1604 > URL: https://issues.apache.org/jira/browse/JENA-1604 > Project: Apache Jena > Issue Type: Task > Components: ARQ, Jena >Affects Versions: Jena 3.8.0 >Reporter: Niraj Patel >Assignee: A. Soroka >Priority: Critical > Labels: http > Fix For: Jena 3.9.0 > > > I am using Jena's QueryEngineHTTP for queries and RemoteUpdateRequest for > updates. I would like to send a custom header that will differ on each > request. Our database, Allegrograph, allows us to pass down custom headers > while querying or updating in order to store that information in access logs. > For each SPARQL request we want to send down unique request markers and > usernames in order to be able to trace from a UI click to backend calls to > queries that were performed in the graph. I did some digging around and it > seems like it's not possible. Using default headers when configuring Apache's > Http Client wouldn't work in this case. The suggestion [~andy.seaborne] made > was to create a request hook in HttpOp where we could add additional headers > as necessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JENA-1604) Add request hook for HTTP query execution
[ https://issues.apache.org/jira/browse/JENA-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Soroka updated JENA-1604: Component/s: ARQ > Add request hook for HTTP query execution > - > > Key: JENA-1604 > URL: https://issues.apache.org/jira/browse/JENA-1604 > Project: Apache Jena > Issue Type: Task > Components: ARQ, Jena >Affects Versions: Jena 3.8.0 >Reporter: Niraj Patel >Assignee: A. Soroka >Priority: Critical > Labels: http > Fix For: Jena 3.9.0 > > > I am using Jena's QueryEngineHTTP for queries and RemoteUpdateRequest for > updates. I would like to send a custom header that will differ on each > request. Our database, Allegrograph, allows us to pass down custom headers > while querying or updating in order to store that information in access logs. > For each SPARQL request we want to send down unique request markers and > usernames in order to be able to trace from a UI click to backend calls to > queries that were performed in the graph. I did some digging around and it > seems like it's not possible. Using default headers when configuring Apache's > Http Client wouldn't work in this case. The suggestion [~andy.seaborne] made > was to create a request hook in HttpOp where we could add additional headers > as necessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (JENA-1604) Add request hook for HTTP query execution
[ https://issues.apache.org/jira/browse/JENA-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Soroka closed JENA-1604. --- > Add request hook for HTTP query execution > - > > Key: JENA-1604 > URL: https://issues.apache.org/jira/browse/JENA-1604 > Project: Apache Jena > Issue Type: Task > Components: Jena >Reporter: Niraj Patel >Assignee: A. Soroka >Priority: Critical > Fix For: Jena 3.9.0 > > > I am using Jena's QueryEngineHTTP for queries and RemoteUpdateRequest for > updates. I would like to send a custom header that will differ on each > request. Our database, Allegrograph, allows us to pass down custom headers > while querying or updating in order to store that information in access logs. > For each SPARQL request we want to send down unique request markers and > usernames in order to be able to trace from a UI click to backend calls to > queries that were performed in the graph. I did some digging around and it > seems like it's not possible. Using default headers when configuring Apache's > Http Client wouldn't work in this case. The suggestion [~andy.seaborne] made > was to create a request hook in HttpOp where we could add additional headers > as necessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (JENA-1604) Add request hook for HTTP query execution
[ https://issues.apache.org/jira/browse/JENA-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Soroka resolved JENA-1604. - Resolution: Fixed Fix Version/s: Jena 3.9.0 > Add request hook for HTTP query execution > - > > Key: JENA-1604 > URL: https://issues.apache.org/jira/browse/JENA-1604 > Project: Apache Jena > Issue Type: Task > Components: Jena >Reporter: Niraj Patel >Assignee: A. Soroka >Priority: Critical > Fix For: Jena 3.9.0 > > > I am using Jena's QueryEngineHTTP for queries and RemoteUpdateRequest for > updates. I would like to send a custom header that will differ on each > request. Our database, Allegrograph, allows us to pass down custom headers > while querying or updating in order to store that information in access logs. > For each SPARQL request we want to send down unique request markers and > usernames in order to be able to trace from a UI click to backend calls to > queries that were performed in the graph. I did some digging around and it > seems like it's not possible. Using default headers when configuring Apache's > Http Client wouldn't work in this case. The suggestion [~andy.seaborne] made > was to create a request hook in HttpOp where we could add additional headers > as necessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1604) Add request hook for HTTP query execution
[ https://issues.apache.org/jira/browse/JENA-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16615203#comment-16615203 ] A. Soroka commented on JENA-1604: - [~nirajpatel], can you take a look at the above PR? Would that suit your use case? You would need to define one transformer object that is used on all requests, but it would have full access to each request and could tap into other state or computation as needed. > Add request hook for HTTP query execution > - > > Key: JENA-1604 > URL: https://issues.apache.org/jira/browse/JENA-1604 > Project: Apache Jena > Issue Type: Task > Components: Jena >Reporter: Niraj Patel >Assignee: A. Soroka >Priority: Critical > > I am using Jena's QueryEngineHTTP for queries and RemoteUpdateRequest for > updates. I would like to send a custom header that will differ on each > request. Our database, Allegrograph, allows us to pass down custom headers > while querying or updating in order to store that information in access logs. > For each SPARQL request we want to send down unique request markers and > usernames in order to be able to trace from a UI click to backend calls to > queries that were performed in the graph. I did some digging around and it > seems like it's not possible. Using default headers when configuring Apache's > Http Client wouldn't work in this case. The suggestion [~andy.seaborne] made > was to create a request hook in HttpOp where we could add additional headers > as necessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (JENA-1604) Add request hook for HTTP query execution
[ https://issues.apache.org/jira/browse/JENA-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Soroka reassigned JENA-1604: --- Assignee: A. Soroka > Add request hook for HTTP query execution > - > > Key: JENA-1604 > URL: https://issues.apache.org/jira/browse/JENA-1604 > Project: Apache Jena > Issue Type: Task > Components: Jena >Reporter: Niraj Patel >Assignee: A. Soroka >Priority: Critical > > I am using Jena's QueryEngineHTTP for queries and RemoteUpdateRequest for > updates. I would like to send a custom header that will differ on each > request. Our database, Allegrograph, allows us to pass down custom headers > while querying or updating in order to store that information in access logs. > For each SPARQL request we want to send down unique request markers and > usernames in order to be able to trace from a UI click to backend calls to > queries that were performed in the graph. I did some digging around and it > seems like it's not possible. Using default headers when configuring Apache's > Http Client wouldn't work in this case. The suggestion [~andy.seaborne] made > was to create a request hook in HttpOp where we could add additional headers > as necessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1597) Split module jena-fuseki-core into the engine and separate webapp.
[
https://issues.apache.org/jira/browse/JENA-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16599824#comment-16599824
]
A. Soroka commented on JENA-1597:
-
So the idea is that {{jena-fuseki-engine}} would, so to speak, accept datasets
and support HTTP, whereas {{jena-fuseki-webapp}} would add to that
configuration and management to decide _which_ datasets are being served?
My one point of confusion is how the admin API/UI will distribute out. It's got
to understand the specifics of different backends to create datasets, doesn't
it? Or do we have some service by which dataset implementations can advertise
their availability?
> Split module jena-fuseki-core into the engine and separate webapp.
> --
>
> Key: JENA-1597
> URL: https://issues.apache.org/jira/browse/JENA-1597
> Project: Apache Jena
> Issue Type: Improvement
> Components: Fuseki
>Affects Versions: Jena 3.8.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
>
> The module jena-fuseki-core has both the core of Fuseki (data registries,
> service servlets, the servlet filter) and the webapp code needed for the full
> server with UI.
> The embedded Fuseki does not need the webapp.
> Separating the two aspects into separate modules is cleaner and avoids the
> risk of webapp assumptions leaking into the non-webapp embedded server.
>
> The key difference is that the embedded/base server makes no assumptions
> about disk, it is given datasets to manage, where as the webapp full/UI
> server has an on-disk configuration and database area.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1568) Don't use JUnit3 TestCase for in SSE tests
[ https://issues.apache.org/jira/browse/JENA-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526333#comment-16526333 ] A. Soroka commented on JENA-1568: - [~andy.seaborne], is this an example of a larger program of migration we'd like to make? JUnit5 is out, and while I'm _not_ suggesting we tangle with that now, it might be nice to uniformly use 4. > Don't use JUnit3 TestCase for in SSE tests > --- > > Key: JENA-1568 > URL: https://issues.apache.org/jira/browse/JENA-1568 > Project: Apache Jena > Issue Type: Improvement >Affects Versions: Jena 3.8.0 >Reporter: Andy Seaborne >Assignee: Andy Seaborne >Priority: Minor > Fix For: Jena 3.9.0 > > > Follows on from JENA-1566. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1553) Can't Backup data - java.io.IOException: Illegal UTF-8: 0xFFFFFFB1
[
https://issues.apache.org/jira/browse/JENA-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498023#comment-16498023
]
A. Soroka commented on JENA-1553:
-
I'm not really sure what to suggest at this point. It's possible that there is
a bug going on here, but it doesn't appear so. That exception looks very much
like what a genuine bad Unicode problem would throw. It's not obvious to me how
it wold have gotten in (I would have thought that update would have been
rejected by Fuseki, but [~andy.seaborne] (TDB-meister) might be able to say
more.
How far back was your last successful backup?
> Can't Backup data - java.io.IOException: Illegal UTF-8: 0xFFB1
> --
>
> Key: JENA-1553
> URL: https://issues.apache.org/jira/browse/JENA-1553
> Project: Apache Jena
> Issue Type: Bug
> Components: Jena
> Environment: Ubuntu 16.04 running Docker. Running stain/jena-fuseki
> from the official Docker Hub.
>Reporter: Brian Mullen
>Priority: Major
>
> Attempting to backup through Fuseki, TDB 500M+ triples, breaking with error:
>
> {code:java}
> [2018-06-01 13:25:46] Log4jLoggerAdapter WARN Exception in backup
> org.apache.jena.atlas.RuntimeIOException: java.io.IOException: Illegal UTF-8:
> 0xFFB1
> at org.apache.jena.atlas.io.IO.exception(IO.java:233)
> at org.apache.jena.atlas.io.BlockUTF8.exception(BlockUTF8.java:275)
> at
> org.apache.jena.atlas.io.BlockUTF8.toCharsBuffer(BlockUTF8.java:150)
> at org.apache.jena.atlas.io.BlockUTF8.toChars(BlockUTF8.java:73)
> at org.apache.jena.atlas.io.BlockUTF8.toString(BlockUTF8.java:95)
> at
> org.apache.jena.tdb.store.nodetable.NodecSSE.decode(NodecSSE.java:101)
> at org.apache.jena.tdb.lib.NodeLib.decode(NodeLib.java:105)
> at org.apache.jena.tdb.lib.NodeLib.fetchDecode(NodeLib.java:81)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableNative.readNodeFromTable(NodeTableNative.java:186)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableNative._retrieveNodeByNodeId(NodeTableNative.java:111)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableNative.getNodeForNodeId(NodeTableNative.java:70)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableCache._retrieveNodeByNodeId(NodeTableCache.java:128)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableCache.getNodeForNodeId(NodeTableCache.java:82)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableWrapper.getNodeForNodeId(NodeTableWrapper.java:50)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableInline.getNodeForNodeId(NodeTableInline.java:67)
> at org.apache.jena.tdb.lib.TupleLib.triple(TupleLib.java:107)
> at org.apache.jena.tdb.lib.TupleLib.triple(TupleLib.java:84)
> at
> org.apache.jena.tdb.lib.TupleLib.lambda$convertToTriples$2(TupleLib.java:54)
> at org.apache.jena.atlas.iterator.Iter$2.next(Iter.java:270)
> at org.apache.jena.atlas.iterator.Iter$2.next(Iter.java:270)
> at org.apache.jena.atlas.iterator.Iter.next(Iter.java:891)
> at
> org.apache.jena.riot.system.StreamOps.sendQuadsToStream(StreamOps.java:140)
> at
> org.apache.jena.riot.writer.NQuadsWriter.write$(NQuadsWriter.java:62)
> at
> org.apache.jena.riot.writer.NQuadsWriter.write(NQuadsWriter.java:45)
> at
> org.apache.jena.riot.writer.NQuadsWriter.write(NQuadsWriter.java:91)
> at org.apache.jena.riot.RDFWriter.write$(RDFWriter.java:208)
> at org.apache.jena.riot.RDFWriter.output(RDFWriter.java:165)
> at org.apache.jena.riot.RDFWriter.output(RDFWriter.java:112)
> at
> org.apache.jena.riot.RDFWriterBuilder.output(RDFWriterBuilder.java:149)
> at org.apache.jena.riot.RDFDataMgr.write$(RDFDataMgr.java:1269)
> at org.apache.jena.riot.RDFDataMgr.write(RDFDataMgr.java:1162)
> at org.apache.jena.riot.RDFDataMgr.write(RDFDataMgr.java:1153)
> at org.apache.jena.fuseki.mgt.Backup.backup(Backup.java:115)
> at org.apache.jena.fuseki.mgt.Backup.backup(Backup.java:75)
> at
> org.apache.jena.fuseki.mgt.ActionBackup$BackupTask.run(ActionBackup.java:58)
> at
> org.apache.jena.fuseki.async.AsyncPool.lambda$submit$0(AsyncPool.java:55)
> at org.apache.jena.fuseki.async.AsyncTask.call(AsyncTask.java:100)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: Illegal UTF-8: 0xFFB1
> ... 40 more
> [2018-06-01 13:25:46] Log4jLoggerAdapter INFO
[jira] [Commented] (JENA-1553) Can't Backup data - java.io.IOException: Illegal UTF-8: 0xFFFFFFB1
[
https://issues.apache.org/jira/browse/JENA-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498014#comment-16498014
]
A. Soroka commented on JENA-1553:
-
Sorry, I think our comments must have crossed. Since you did make updates to
the data via Fuseki, do you have some record of the data that was used to do
that?
> Can't Backup data - java.io.IOException: Illegal UTF-8: 0xFFB1
> --
>
> Key: JENA-1553
> URL: https://issues.apache.org/jira/browse/JENA-1553
> Project: Apache Jena
> Issue Type: Bug
> Components: Jena
> Environment: Ubuntu 16.04 running Docker. Running stain/jena-fuseki
> from the official Docker Hub.
>Reporter: Brian Mullen
>Priority: Major
>
> Attempting to backup through Fuseki, TDB 500M+ triples, breaking with error:
>
> {code:java}
> [2018-06-01 13:25:46] Log4jLoggerAdapter WARN Exception in backup
> org.apache.jena.atlas.RuntimeIOException: java.io.IOException: Illegal UTF-8:
> 0xFFB1
> at org.apache.jena.atlas.io.IO.exception(IO.java:233)
> at org.apache.jena.atlas.io.BlockUTF8.exception(BlockUTF8.java:275)
> at
> org.apache.jena.atlas.io.BlockUTF8.toCharsBuffer(BlockUTF8.java:150)
> at org.apache.jena.atlas.io.BlockUTF8.toChars(BlockUTF8.java:73)
> at org.apache.jena.atlas.io.BlockUTF8.toString(BlockUTF8.java:95)
> at
> org.apache.jena.tdb.store.nodetable.NodecSSE.decode(NodecSSE.java:101)
> at org.apache.jena.tdb.lib.NodeLib.decode(NodeLib.java:105)
> at org.apache.jena.tdb.lib.NodeLib.fetchDecode(NodeLib.java:81)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableNative.readNodeFromTable(NodeTableNative.java:186)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableNative._retrieveNodeByNodeId(NodeTableNative.java:111)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableNative.getNodeForNodeId(NodeTableNative.java:70)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableCache._retrieveNodeByNodeId(NodeTableCache.java:128)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableCache.getNodeForNodeId(NodeTableCache.java:82)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableWrapper.getNodeForNodeId(NodeTableWrapper.java:50)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableInline.getNodeForNodeId(NodeTableInline.java:67)
> at org.apache.jena.tdb.lib.TupleLib.triple(TupleLib.java:107)
> at org.apache.jena.tdb.lib.TupleLib.triple(TupleLib.java:84)
> at
> org.apache.jena.tdb.lib.TupleLib.lambda$convertToTriples$2(TupleLib.java:54)
> at org.apache.jena.atlas.iterator.Iter$2.next(Iter.java:270)
> at org.apache.jena.atlas.iterator.Iter$2.next(Iter.java:270)
> at org.apache.jena.atlas.iterator.Iter.next(Iter.java:891)
> at
> org.apache.jena.riot.system.StreamOps.sendQuadsToStream(StreamOps.java:140)
> at
> org.apache.jena.riot.writer.NQuadsWriter.write$(NQuadsWriter.java:62)
> at
> org.apache.jena.riot.writer.NQuadsWriter.write(NQuadsWriter.java:45)
> at
> org.apache.jena.riot.writer.NQuadsWriter.write(NQuadsWriter.java:91)
> at org.apache.jena.riot.RDFWriter.write$(RDFWriter.java:208)
> at org.apache.jena.riot.RDFWriter.output(RDFWriter.java:165)
> at org.apache.jena.riot.RDFWriter.output(RDFWriter.java:112)
> at
> org.apache.jena.riot.RDFWriterBuilder.output(RDFWriterBuilder.java:149)
> at org.apache.jena.riot.RDFDataMgr.write$(RDFDataMgr.java:1269)
> at org.apache.jena.riot.RDFDataMgr.write(RDFDataMgr.java:1162)
> at org.apache.jena.riot.RDFDataMgr.write(RDFDataMgr.java:1153)
> at org.apache.jena.fuseki.mgt.Backup.backup(Backup.java:115)
> at org.apache.jena.fuseki.mgt.Backup.backup(Backup.java:75)
> at
> org.apache.jena.fuseki.mgt.ActionBackup$BackupTask.run(ActionBackup.java:58)
> at
> org.apache.jena.fuseki.async.AsyncPool.lambda$submit$0(AsyncPool.java:55)
> at org.apache.jena.fuseki.async.AsyncTask.call(AsyncTask.java:100)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: Illegal UTF-8: 0xFFB1
> ... 40 more
> [2018-06-01 13:25:46] Log4jLoggerAdapter INFO
> Backup(/fuseki/backups/PDE_PROD_2018-06-01_13-24-00):2{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1553) Can't Backup data - java.io.IOException: Illegal UTF-8: 0xFFFFFFB1
[
https://issues.apache.org/jira/browse/JENA-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498011#comment-16498011
]
A. Soroka commented on JENA-1553:
-
# Did you or did you not make updates to the data via Fuseki?
# When you last loaded the data, did you have any warnings or errors then?
> Can't Backup data - java.io.IOException: Illegal UTF-8: 0xFFB1
> --
>
> Key: JENA-1553
> URL: https://issues.apache.org/jira/browse/JENA-1553
> Project: Apache Jena
> Issue Type: Bug
> Components: Jena
> Environment: Ubuntu 16.04 running Docker. Running stain/jena-fuseki
> from the official Docker Hub.
>Reporter: Brian Mullen
>Priority: Major
>
> Attempting to backup through Fuseki, TDB 500M+ triples, breaking with error:
>
> {code:java}
> [2018-06-01 13:25:46] Log4jLoggerAdapter WARN Exception in backup
> org.apache.jena.atlas.RuntimeIOException: java.io.IOException: Illegal UTF-8:
> 0xFFB1
> at org.apache.jena.atlas.io.IO.exception(IO.java:233)
> at org.apache.jena.atlas.io.BlockUTF8.exception(BlockUTF8.java:275)
> at
> org.apache.jena.atlas.io.BlockUTF8.toCharsBuffer(BlockUTF8.java:150)
> at org.apache.jena.atlas.io.BlockUTF8.toChars(BlockUTF8.java:73)
> at org.apache.jena.atlas.io.BlockUTF8.toString(BlockUTF8.java:95)
> at
> org.apache.jena.tdb.store.nodetable.NodecSSE.decode(NodecSSE.java:101)
> at org.apache.jena.tdb.lib.NodeLib.decode(NodeLib.java:105)
> at org.apache.jena.tdb.lib.NodeLib.fetchDecode(NodeLib.java:81)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableNative.readNodeFromTable(NodeTableNative.java:186)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableNative._retrieveNodeByNodeId(NodeTableNative.java:111)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableNative.getNodeForNodeId(NodeTableNative.java:70)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableCache._retrieveNodeByNodeId(NodeTableCache.java:128)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableCache.getNodeForNodeId(NodeTableCache.java:82)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableWrapper.getNodeForNodeId(NodeTableWrapper.java:50)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableInline.getNodeForNodeId(NodeTableInline.java:67)
> at org.apache.jena.tdb.lib.TupleLib.triple(TupleLib.java:107)
> at org.apache.jena.tdb.lib.TupleLib.triple(TupleLib.java:84)
> at
> org.apache.jena.tdb.lib.TupleLib.lambda$convertToTriples$2(TupleLib.java:54)
> at org.apache.jena.atlas.iterator.Iter$2.next(Iter.java:270)
> at org.apache.jena.atlas.iterator.Iter$2.next(Iter.java:270)
> at org.apache.jena.atlas.iterator.Iter.next(Iter.java:891)
> at
> org.apache.jena.riot.system.StreamOps.sendQuadsToStream(StreamOps.java:140)
> at
> org.apache.jena.riot.writer.NQuadsWriter.write$(NQuadsWriter.java:62)
> at
> org.apache.jena.riot.writer.NQuadsWriter.write(NQuadsWriter.java:45)
> at
> org.apache.jena.riot.writer.NQuadsWriter.write(NQuadsWriter.java:91)
> at org.apache.jena.riot.RDFWriter.write$(RDFWriter.java:208)
> at org.apache.jena.riot.RDFWriter.output(RDFWriter.java:165)
> at org.apache.jena.riot.RDFWriter.output(RDFWriter.java:112)
> at
> org.apache.jena.riot.RDFWriterBuilder.output(RDFWriterBuilder.java:149)
> at org.apache.jena.riot.RDFDataMgr.write$(RDFDataMgr.java:1269)
> at org.apache.jena.riot.RDFDataMgr.write(RDFDataMgr.java:1162)
> at org.apache.jena.riot.RDFDataMgr.write(RDFDataMgr.java:1153)
> at org.apache.jena.fuseki.mgt.Backup.backup(Backup.java:115)
> at org.apache.jena.fuseki.mgt.Backup.backup(Backup.java:75)
> at
> org.apache.jena.fuseki.mgt.ActionBackup$BackupTask.run(ActionBackup.java:58)
> at
> org.apache.jena.fuseki.async.AsyncPool.lambda$submit$0(AsyncPool.java:55)
> at org.apache.jena.fuseki.async.AsyncTask.call(AsyncTask.java:100)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: Illegal UTF-8: 0xFFB1
> ... 40 more
> [2018-06-01 13:25:46] Log4jLoggerAdapter INFO
> Backup(/fuseki/backups/PDE_PROD_2018-06-01_13-24-00):2{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1553) Can't Backup data - java.io.IOException: Illegal UTF-8: 0xFFFFFFB1
[
https://issues.apache.org/jira/browse/JENA-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498001#comment-16498001
]
A. Soroka commented on JENA-1553:
-
Sure, a simple way would be to take your original data (the data you loaded)
and use Jena's {{riot}}command-line tool. Do you have a complete set of the
data you loaded, or was some of it created by sending updates to Fuseki?
> Can't Backup data - java.io.IOException: Illegal UTF-8: 0xFFB1
> --
>
> Key: JENA-1553
> URL: https://issues.apache.org/jira/browse/JENA-1553
> Project: Apache Jena
> Issue Type: Bug
> Components: Jena
> Environment: Ubuntu 16.04 running Docker. Running stain/jena-fuseki
> from the official Docker Hub.
>Reporter: Brian Mullen
>Priority: Major
>
> Attempting to backup through Fuseki, TDB 500M+ triples, breaking with error:
>
> {code:java}
> [2018-06-01 13:25:46] Log4jLoggerAdapter WARN Exception in backup
> org.apache.jena.atlas.RuntimeIOException: java.io.IOException: Illegal UTF-8:
> 0xFFB1
> at org.apache.jena.atlas.io.IO.exception(IO.java:233)
> at org.apache.jena.atlas.io.BlockUTF8.exception(BlockUTF8.java:275)
> at
> org.apache.jena.atlas.io.BlockUTF8.toCharsBuffer(BlockUTF8.java:150)
> at org.apache.jena.atlas.io.BlockUTF8.toChars(BlockUTF8.java:73)
> at org.apache.jena.atlas.io.BlockUTF8.toString(BlockUTF8.java:95)
> at
> org.apache.jena.tdb.store.nodetable.NodecSSE.decode(NodecSSE.java:101)
> at org.apache.jena.tdb.lib.NodeLib.decode(NodeLib.java:105)
> at org.apache.jena.tdb.lib.NodeLib.fetchDecode(NodeLib.java:81)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableNative.readNodeFromTable(NodeTableNative.java:186)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableNative._retrieveNodeByNodeId(NodeTableNative.java:111)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableNative.getNodeForNodeId(NodeTableNative.java:70)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableCache._retrieveNodeByNodeId(NodeTableCache.java:128)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableCache.getNodeForNodeId(NodeTableCache.java:82)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableWrapper.getNodeForNodeId(NodeTableWrapper.java:50)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableInline.getNodeForNodeId(NodeTableInline.java:67)
> at org.apache.jena.tdb.lib.TupleLib.triple(TupleLib.java:107)
> at org.apache.jena.tdb.lib.TupleLib.triple(TupleLib.java:84)
> at
> org.apache.jena.tdb.lib.TupleLib.lambda$convertToTriples$2(TupleLib.java:54)
> at org.apache.jena.atlas.iterator.Iter$2.next(Iter.java:270)
> at org.apache.jena.atlas.iterator.Iter$2.next(Iter.java:270)
> at org.apache.jena.atlas.iterator.Iter.next(Iter.java:891)
> at
> org.apache.jena.riot.system.StreamOps.sendQuadsToStream(StreamOps.java:140)
> at
> org.apache.jena.riot.writer.NQuadsWriter.write$(NQuadsWriter.java:62)
> at
> org.apache.jena.riot.writer.NQuadsWriter.write(NQuadsWriter.java:45)
> at
> org.apache.jena.riot.writer.NQuadsWriter.write(NQuadsWriter.java:91)
> at org.apache.jena.riot.RDFWriter.write$(RDFWriter.java:208)
> at org.apache.jena.riot.RDFWriter.output(RDFWriter.java:165)
> at org.apache.jena.riot.RDFWriter.output(RDFWriter.java:112)
> at
> org.apache.jena.riot.RDFWriterBuilder.output(RDFWriterBuilder.java:149)
> at org.apache.jena.riot.RDFDataMgr.write$(RDFDataMgr.java:1269)
> at org.apache.jena.riot.RDFDataMgr.write(RDFDataMgr.java:1162)
> at org.apache.jena.riot.RDFDataMgr.write(RDFDataMgr.java:1153)
> at org.apache.jena.fuseki.mgt.Backup.backup(Backup.java:115)
> at org.apache.jena.fuseki.mgt.Backup.backup(Backup.java:75)
> at
> org.apache.jena.fuseki.mgt.ActionBackup$BackupTask.run(ActionBackup.java:58)
> at
> org.apache.jena.fuseki.async.AsyncPool.lambda$submit$0(AsyncPool.java:55)
> at org.apache.jena.fuseki.async.AsyncTask.call(AsyncTask.java:100)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: Illegal UTF-8: 0xFFB1
> ... 40 more
> [2018-06-01 13:25:46] Log4jLoggerAdapter INFO
> Backup(/fuseki/backups/PDE_PROD_2018-06-01_13-24-00):2{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JENA-1554) Support bz2 compression for parsing and loading.
[ https://issues.apache.org/jira/browse/JENA-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Soroka updated JENA-1554: Labels: newbie (was: ) > Support bz2 compression for parsing and loading. > > > Key: JENA-1554 > URL: https://issues.apache.org/jira/browse/JENA-1554 > Project: Apache Jena > Issue Type: Improvement >Reporter: Andy Seaborne >Priority: Major > Labels: newbie > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1553) Can't Backup data - java.io.IOException: Illegal UTF-8: 0xFFFFFFB1
[
https://issues.apache.org/jira/browse/JENA-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16497991#comment-16497991
]
A. Soroka commented on JENA-1553:
-
Please verify that your data is okay using {{riot}} or a similar tool. This
doesn't seem to be a bug in Jena-- it looks like bad data.
> Can't Backup data - java.io.IOException: Illegal UTF-8: 0xFFB1
> --
>
> Key: JENA-1553
> URL: https://issues.apache.org/jira/browse/JENA-1553
> Project: Apache Jena
> Issue Type: Bug
> Components: Jena
> Environment: Ubuntu 16.04 running Docker. Running stain/jena-fuseki
> from the official Docker Hub.
>Reporter: Brian Mullen
>Priority: Major
>
> Attempting to backup through Fuseki, TDB 500M+ triples, breaking with error:
>
> {code:java}
> [2018-06-01 13:25:46] Log4jLoggerAdapter WARN Exception in backup
> org.apache.jena.atlas.RuntimeIOException: java.io.IOException: Illegal UTF-8:
> 0xFFB1
> at org.apache.jena.atlas.io.IO.exception(IO.java:233)
> at org.apache.jena.atlas.io.BlockUTF8.exception(BlockUTF8.java:275)
> at
> org.apache.jena.atlas.io.BlockUTF8.toCharsBuffer(BlockUTF8.java:150)
> at org.apache.jena.atlas.io.BlockUTF8.toChars(BlockUTF8.java:73)
> at org.apache.jena.atlas.io.BlockUTF8.toString(BlockUTF8.java:95)
> at
> org.apache.jena.tdb.store.nodetable.NodecSSE.decode(NodecSSE.java:101)
> at org.apache.jena.tdb.lib.NodeLib.decode(NodeLib.java:105)
> at org.apache.jena.tdb.lib.NodeLib.fetchDecode(NodeLib.java:81)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableNative.readNodeFromTable(NodeTableNative.java:186)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableNative._retrieveNodeByNodeId(NodeTableNative.java:111)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableNative.getNodeForNodeId(NodeTableNative.java:70)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableCache._retrieveNodeByNodeId(NodeTableCache.java:128)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableCache.getNodeForNodeId(NodeTableCache.java:82)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableWrapper.getNodeForNodeId(NodeTableWrapper.java:50)
> at
> org.apache.jena.tdb.store.nodetable.NodeTableInline.getNodeForNodeId(NodeTableInline.java:67)
> at org.apache.jena.tdb.lib.TupleLib.triple(TupleLib.java:107)
> at org.apache.jena.tdb.lib.TupleLib.triple(TupleLib.java:84)
> at
> org.apache.jena.tdb.lib.TupleLib.lambda$convertToTriples$2(TupleLib.java:54)
> at org.apache.jena.atlas.iterator.Iter$2.next(Iter.java:270)
> at org.apache.jena.atlas.iterator.Iter$2.next(Iter.java:270)
> at org.apache.jena.atlas.iterator.Iter.next(Iter.java:891)
> at
> org.apache.jena.riot.system.StreamOps.sendQuadsToStream(StreamOps.java:140)
> at
> org.apache.jena.riot.writer.NQuadsWriter.write$(NQuadsWriter.java:62)
> at
> org.apache.jena.riot.writer.NQuadsWriter.write(NQuadsWriter.java:45)
> at
> org.apache.jena.riot.writer.NQuadsWriter.write(NQuadsWriter.java:91)
> at org.apache.jena.riot.RDFWriter.write$(RDFWriter.java:208)
> at org.apache.jena.riot.RDFWriter.output(RDFWriter.java:165)
> at org.apache.jena.riot.RDFWriter.output(RDFWriter.java:112)
> at
> org.apache.jena.riot.RDFWriterBuilder.output(RDFWriterBuilder.java:149)
> at org.apache.jena.riot.RDFDataMgr.write$(RDFDataMgr.java:1269)
> at org.apache.jena.riot.RDFDataMgr.write(RDFDataMgr.java:1162)
> at org.apache.jena.riot.RDFDataMgr.write(RDFDataMgr.java:1153)
> at org.apache.jena.fuseki.mgt.Backup.backup(Backup.java:115)
> at org.apache.jena.fuseki.mgt.Backup.backup(Backup.java:75)
> at
> org.apache.jena.fuseki.mgt.ActionBackup$BackupTask.run(ActionBackup.java:58)
> at
> org.apache.jena.fuseki.async.AsyncPool.lambda$submit$0(AsyncPool.java:55)
> at org.apache.jena.fuseki.async.AsyncTask.call(AsyncTask.java:100)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: Illegal UTF-8: 0xFFB1
> ... 40 more
> [2018-06-01 13:25:46] Log4jLoggerAdapter INFO
> Backup(/fuseki/backups/PDE_PROD_2018-06-01_13-24-00):2{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1550) Bulk loader for TDB2.
[ https://issues.apache.org/jira/browse/JENA-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16481946#comment-16481946 ] A. Soroka commented on JENA-1550: - Do you think it's worth investigating (e.g. I could run the same task locally)? I suppose we can just see what people are getting once the code is released. > Bulk loader for TDB2. > - > > Key: JENA-1550 > URL: https://issues.apache.org/jira/browse/JENA-1550 > Project: Apache Jena > Issue Type: Improvement > Components: TDB2 >Affects Versions: Jena 3.7.0 >Reporter: Andy Seaborne >Assignee: Andy Seaborne >Priority: Major > > Provide a bulk loader for TDB2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1550) Bulk loader for TDB2.
[
https://issues.apache.org/jira/browse/JENA-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16481195#comment-16481195
]
A. Soroka commented on JENA-1550:
-
The OS cache efficiency may be an issue, but it's cutting the time in thirds
out of the gate-- you got to call that promising. {{grin}} Do you think the
speed jumps are due to earlier stages ending and freeing resources, or
something more subtle?
> Bulk loader for TDB2.
> -
>
> Key: JENA-1550
> URL: https://issues.apache.org/jira/browse/JENA-1550
> Project: Apache Jena
> Issue Type: Improvement
> Components: TDB2
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
>
> Provide a bulk loader for TDB2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JENA-1549) Javadoc improvements for null-as-wildcard in SPI
[
https://issues.apache.org/jira/browse/JENA-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Soroka updated JENA-1549:
Component/s: Core
> Javadoc improvements for null-as-wildcard in SPI
>
>
> Key: JENA-1549
> URL: https://issues.apache.org/jira/browse/JENA-1549
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ, Core
>Affects Versions: Jena 3.7.0
>Reporter: A. Soroka
>Assignee: A. Soroka
>Priority: Trivial
>
> Methods in the {{Triple/Graph/DatasetGraph}} SPI that accept null-as-wildcard
> often don't mention or explain this in their Javadocs. It would be helpful if
> they did.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JENA-1549) Javadoc improvements for null-as-wildcard in SPI
A. Soroka created JENA-1549:
---
Summary: Javadoc improvements for null-as-wildcard in SPI
Key: JENA-1549
URL: https://issues.apache.org/jira/browse/JENA-1549
Project: Apache Jena
Issue Type: Improvement
Components: ARQ
Affects Versions: Jena 3.7.0
Reporter: A. Soroka
Assignee: A. Soroka
Methods in the {{Triple/Graph/DatasetGraph}} SPI that accept null-as-wildcard
often don't mention or explain this in their Javadocs. It would be helpful if
they did.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1544) FROM handling is inconsistent
[ https://issues.apache.org/jira/browse/JENA-1544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16465941#comment-16465941 ] A. Soroka commented on JENA-1544: - Is this work that needs to be done in the dataset impls, or in the SPARQL machinery? > FROM handling is inconsistent > - > > Key: JENA-1544 > URL: https://issues.apache.org/jira/browse/JENA-1544 > Project: Apache Jena > Issue Type: Bug >Affects Versions: Jena 3.7.0 >Reporter: Andy Seaborne >Assignee: Andy Seaborne >Priority: Major > Fix For: Jena 3.8.0 > > > Dataset description (FROM and FROM NAMED) handling seems to be missing for > memory datasets. > For persistent ones, the action is to take graph from the dataset itself. > The proposal is to add this for memory datasets. > The ability to load graphs from the web or from files using FROM / FROM NAMED > will be available when a query is executed with no dataset. > Executing a query with no dataset and no dataset description is an error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1541) Jena Eyeball - ant test fails with TestCase Error
[
https://issues.apache.org/jira/browse/JENA-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464202#comment-16464202
]
A. Soroka commented on JENA-1541:
-
Right, I'll let [~edward18] do the asking. There is also a [ShEx implementation
with Jena bindings|https://github.com/iovka/shex-java] and [a project that
intends to support both ShEx and SHACL with Jena
bindings|https://github.com/labra/shaclex].
> Jena Eyeball - ant test fails with TestCase Error
> -
>
> Key: JENA-1541
> URL: https://issues.apache.org/jira/browse/JENA-1541
> Project: Apache Jena
> Issue Type: Question
> Components: Eyeball, Jena
>Reporter: Edward
>Priority: Major
> Labels: ant, eyeball, fail, jena, test
>
> Hello,
> I'm trying to get Jena Eyeball running. I wanted to do the Tutorial on
> [https://jena.apache.org/documentation/tools/eyeball-getting-started.html]
> but it failed with following error:
> {code:java}
> [junit] Testcase: warning(junit.framework.TestSuite$1): FAILED
> [junit] Class
> com.hp.hpl.jena.eyeball.inspectors.test.TestMoreOwlSyntaxInspector has no
> public constructor TestCase(String name) or TestCase()
> [junit] junit.framework.AssertionFailedError: Class
> com.hp.hpl.jena.eyeball.inspectors.test.TestMoreOwlSyntaxInspector has no
> public constructor TestCase(String name) or TestCase()
> [junit]
> [junit]
> BUILD FAILED
> /**/Downloads/eyeball-2.3/build.xml:146: Test
> com.hp.hpl.jena.eyeball.inspectors.test.TestMoreOwlSyntaxInspector failed
> {code}
> The tutorial says if the ant test doesn't pass, I should file a Jira Issue.
> So that's what I am doing.
> Help would be much appreciated!
>
> Greetings,
> Edward
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1542) Allow addition of transaction components after initial setup.
[
https://issues.apache.org/jira/browse/JENA-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464191#comment-16464191
]
A. Soroka commented on JENA-1542:
-
Okay, cool, and definitely that sounds like a good constraint to start with.
> Allow addition of transaction components after initial setup.
> -
>
> Key: JENA-1542
> URL: https://issues.apache.org/jira/browse/JENA-1542
> Project: Apache Jena
> Issue Type: Improvement
> Components: TDB, TDB2
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
>
> Currently:
> * TDB1: the set of {{TransactionLifecycle}} components is fixed
> * TDB2: the set of {{TransactionComponents}} is frozen during creation of a
> dataset.
> In order to be able to add a text index into the transaction handling, allow
> new items to be added (carefully) into the transaction subsystem for a
> dataset.
> This is necessary for JENA-1302.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1542) Allow addition of transaction components after initial setup.
[
https://issues.apache.org/jira/browse/JENA-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464150#comment-16464150
]
A. Soroka commented on JENA-1542:
-
Is the goal of this ticket to be able to add components to a transaction in
progress, or only to be able to add transaction components to a dataset after
the dataset has been created, but not necessarily while a transaction is in
progress?
> Allow addition of transaction components after initial setup.
> -
>
> Key: JENA-1542
> URL: https://issues.apache.org/jira/browse/JENA-1542
> Project: Apache Jena
> Issue Type: Improvement
> Components: TDB, TDB2
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
>
> Currently:
> * TDB1: the set of {{TransactionLifecycle}} components is fixed
> * TDB2: the set of {{TransactionComponents}} is frozen during creation of a
> dataset.
> In order to be able to add a text index into the transaction handling, allow
> new items to be added (carefully) into the transaction subsystem for a
> dataset.
> This is necessary for JENA-1302.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1541) Jena Eyeball - ant test fails with TestCase Error
[
https://issues.apache.org/jira/browse/JENA-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16463911#comment-16463911
]
A. Soroka commented on JENA-1541:
-
I'm not sure whether Eyeball is maintained at all any more (it is _not_ part of
the Apache Jena releases). But let's see what we can do. Can you tell us where
you got the source code with which you are working? Did a plain build (using
{{ant}}) work? It looks a bit like you have a problem with your build
classpath.
[~andy.seaborne] do you know know if there are any active committers left with
expertise in Eyeball?
> Jena Eyeball - ant test fails with TestCase Error
> -
>
> Key: JENA-1541
> URL: https://issues.apache.org/jira/browse/JENA-1541
> Project: Apache Jena
> Issue Type: Question
> Components: Eyeball, Jena
>Reporter: Edward
>Priority: Major
> Labels: ant, eyeball, fail, jena, test
>
> Hello,
> I'm trying to get Jena Eyeball running. I wanted to do the Tutorial on
> [https://jena.apache.org/documentation/tools/eyeball-getting-started.html]
> but it failed with following error:
> {code:java}
> [junit] Testcase: warning(junit.framework.TestSuite$1): FAILED
> [junit] Class
> com.hp.hpl.jena.eyeball.inspectors.test.TestMoreOwlSyntaxInspector has no
> public constructor TestCase(String name) or TestCase()
> [junit] junit.framework.AssertionFailedError: Class
> com.hp.hpl.jena.eyeball.inspectors.test.TestMoreOwlSyntaxInspector has no
> public constructor TestCase(String name) or TestCase()
> [junit]
> [junit]
> BUILD FAILED
> /**/Downloads/eyeball-2.3/build.xml:146: Test
> com.hp.hpl.jena.eyeball.inspectors.test.TestMoreOwlSyntaxInspector failed
> {code}
> The tutorial says if the ant test doesn't pass, I should file a Jira Issue.
> So that's what I am doing.
> Help would be much appreciated!
>
> Greetings,
> Edward
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (JENA-1536) unsynchronized collection in jena.atlas.lib.SinkToCollection causes ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/JENA-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Soroka closed JENA-1536.
---
Resolution: Not A Problem
Assignee: A. Soroka
See [https://github.com/trellis-ldp/trellis/issues/119] for downstream
resolution.
> unsynchronized collection in jena.atlas.lib.SinkToCollection causes
> ArrayIndexOutOfBoundsException
> --
>
> Key: JENA-1536
> URL: https://issues.apache.org/jira/browse/JENA-1536
> Project: Apache Jena
> Issue Type: Bug
> Components: Base
>Reporter: Christopher Johnson
>Assignee: A. Soroka
>Priority: Major
> Attachments: AtlasSinkNonSynchronizedCollectionException.txt
>
>
> Attached is a stack trace that shows the issue.
> [^AtlasSinkNonSynchronizedCollectionException.txt]
> This is produced by a repeated client test through
> {noformat}
> RDFConnection.update{noformat}
> via this [Trellis
> method|https://github.com/trellis-ldp/trellis/blob/master/components/triplestore/src/main/java/org/trellisldp/triplestore/TriplestoreResourceService.java#L212-L227]
> that streams quads quite fast.
> Changing the method signature to this:
> {code:java}
> @Override
> public synchronized void send(T item) { c.add(item); }{code}
> Solves the problem for me.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1536) unsynchronized collection in jena.atlas.lib.SinkToCollection causes ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/JENA-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16457687#comment-16457687
]
A. Soroka commented on JENA-1536:
-
{{synchronized}} seems much too strong here-- it makes everyone (including
single-threaded applications) pay the cost. I think the right approach here is
to pass a thread-safe {{Collection}} into the constructor.
In your example, that would occur if {{TriplestoreResourceService}} used the
constructor {{QuadDataAcc(List)}} with an appropriate thread-safe {{List}}.
> unsynchronized collection in jena.atlas.lib.SinkToCollection causes
> ArrayIndexOutOfBoundsException
> --
>
> Key: JENA-1536
> URL: https://issues.apache.org/jira/browse/JENA-1536
> Project: Apache Jena
> Issue Type: Bug
> Components: Base
>Reporter: Christopher Johnson
>Priority: Major
> Attachments: AtlasSinkNonSynchronizedCollectionException.txt
>
>
> Attached is a stack trace that shows the issue.
> [^AtlasSinkNonSynchronizedCollectionException.txt]
> This is produced by a repeated client test through
> {noformat}
> RDFConnection.update{noformat}
> via this [Trellis
> method|https://github.com/trellis-ldp/trellis/blob/master/components/triplestore/src/main/java/org/trellisldp/triplestore/TriplestoreResourceService.java#L212-L227]
> that streams quads quite fast.
> Changing the method signature to this:
> {code:java}
> @Override
> public synchronized void send(T item) { c.add(item); }{code}
> Solves the problem for me.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1528) HttpQuery does not set the readTimeout
[
https://issues.apache.org/jira/browse/JENA-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16450259#comment-16450259
]
A. Soroka commented on JENA-1528:
-
[~nithril] can you please open a new ticket to discuss default HTTP
configuration? I think you are asking for a more clear pattern of overrides,
but I'm not sure...
> HttpQuery does not set the readTimeout
> --
>
> Key: JENA-1528
> URL: https://issues.apache.org/jira/browse/JENA-1528
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.7.0
>Reporter: Nicolas Labrot
>Assignee: A. Soroka
>Priority: Minor
> Fix For: Jena 3.8.0
>
>
> {{org.apache.jena.sparql.engine.http.HttpQuery#contextualizeTimeoutSettings}}
> sets the connectTimeout but not the readTimeout
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (JENA-1528) HttpQuery does not set the readTimeout
[
https://issues.apache.org/jira/browse/JENA-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Soroka resolved JENA-1528.
-
Resolution: Implemented
> HttpQuery does not set the readTimeout
> --
>
> Key: JENA-1528
> URL: https://issues.apache.org/jira/browse/JENA-1528
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.7.0
>Reporter: Nicolas Labrot
>Assignee: A. Soroka
>Priority: Minor
> Fix For: Jena 3.8.0
>
>
> {{org.apache.jena.sparql.engine.http.HttpQuery#contextualizeTimeoutSettings}}
> sets the connectTimeout but not the readTimeout
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1528) HttpQuery does not set the readTimeout
[
https://issues.apache.org/jira/browse/JENA-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16448368#comment-16448368
]
A. Soroka commented on JENA-1528:
-
I can "Resolve" it. I have been in the habit of waiting for the reporter to
confirm that the issue is, in fact, resolved, but I can be a bit more
aggressive.
> HttpQuery does not set the readTimeout
> --
>
> Key: JENA-1528
> URL: https://issues.apache.org/jira/browse/JENA-1528
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.7.0
>Reporter: Nicolas Labrot
>Assignee: A. Soroka
>Priority: Minor
> Fix For: Jena 3.8.0
>
>
> {{org.apache.jena.sparql.engine.http.HttpQuery#contextualizeTimeoutSettings}}
> sets the connectTimeout but not the readTimeout
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1528) HttpQuery does not set the readTimeout
[
https://issues.apache.org/jira/browse/JENA-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16446830#comment-16446830
]
A. Soroka commented on JENA-1528:
-
[~nithril] please verify that this commit meets your needs when you have a
chance. You can use {{HttpQuery::setReadTimeout}} to set the new timeout.
Thanks!
> HttpQuery does not set the readTimeout
> --
>
> Key: JENA-1528
> URL: https://issues.apache.org/jira/browse/JENA-1528
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.7.0
>Reporter: Nicolas Labrot
>Assignee: A. Soroka
>Priority: Minor
>
> {{org.apache.jena.sparql.engine.http.HttpQuery#contextualizeTimeoutSettings}}
> sets the connectTimeout but not the readTimeout
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
