CMS diff: Jena Full Text Search

2018-01-21 Thread Chris Tomlinson 
Clone URL (Committers only):
https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/documentation%2Fquery%2Ftext-query.mdtext

Chris Tomlinson

Index: trunk/content/documentation/query/text-query.mdtext
===
--- trunk/content/documentation/query/text-query.mdtext (revision 1821823)
+++ trunk/content/documentation/query/text-query.mdtext (working copy)
@@ -1,5 +1,7 @@
 Title: Jena Full Text Search
 
+Title: Jena Full Text Search
+
 This extension to ARQ combines SPARQL and full text search via
 [Lucene](https://lucene.apache.org) 6.4.1 or
 [ElasticSearch](https://www.elastic.co) 5.2.1 (which is built on
@@ -231,7 +233,7 @@
 
 The most general form is:

- (?s ?score ?literal ?g) text:query (property 'query string' limit 
'lang:xx')
+ ( ?s ?score ?literal ?g ) text:query ( property 'query string' limit 
'lang:xx' 'highlight:yy' )
 
  Input arguments:
 
@@ -241,13 +243,13 @@
 | query string  | Lucene query string fragment   |
 | limit | (optional) `int` limit on the number of results   |
 | lang:xx   | (optional) language tag spec   |
-| highlight:xx  | (optional) highlighting options|
+| highlight:yy  | (optional) highlighting options|
 
 The `property` URI is only necessary if multiple properties have been
 indexed and the property being searched over is not the [default field
 of the index](#entity-map-definition).
 
-The `query string` syntax conforms the underlying index 
[Lucene](http://lucene.apache.org/core/6_4_1/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#package_description)
+The `query string` syntax conforms to the underlying index 
[Lucene](http://lucene.apache.org/core/6_4_1/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#package_description)
 or
 
[Elasticsearch](https://www.elastic.co/guide/en/elasticsearch/reference/5.2/query-dsl.html).
 In the case of Lucene the syntax is restricted to `Terms`, `Term modifiers`, 
`Boolean Operators` applied to `Terms`, and `Grouping` of terms. _No use of 
`Fields` within the `query string` is supported._
 
@@ -258,9 +260,9 @@
 indexed with the tag _xx_. Searches may be restricted to field values with no 
 language tag via `"lang:none"`. 
 
-The `highlight:xx` specification is an optional string where _xx_ are options 
that control the highlighting of search result literals. See 
[below](#highlighting) for details.
+The `highlight:yy` specification is an optional string where _yy_ are options 
that control the highlighting of search result literals. See 
[below](#highlighting) for details.
 
-If both `limit` and one or more of `lang:xx` or `highlight:xx` are present, 
then `limit` must precede these arguments.
+If both `limit` and one or more of `lang:xx` or `highlight:yy` are present, 
then `limit` must precede these arguments.
 
 If only the query string is required, the surrounding `( )` _may be_ omitted.
 
@@ -499,7 +501,7 @@
 
  Highlighting
 
-The highlighting option uses the Lucene `Highlighter` and 
`SimpleHTMLFormatter` to insert highlighting markup into the literals returned 
from search results (hence the text dataset must be configured to store the 
literals). The highlighted results are returned via the _literal_ output 
argument.
+The highlighting option uses the Lucene `Highlighter` and 
`SimpleHTMLFormatter` to insert highlighting markup into the literals returned 
from search results (hence the text dataset must be configured to store the 
literals). The highlighted results are returned via the _literal_ output 
argument. This highlighting feature, introduced in version 3.7.0, does not 
require re-indexing by Lucene. 
 
 The simplest way to request highlighting is via `'highlight:'`. This will 
apply all the defaults:
 
@@ -521,7 +523,7 @@
 
 "the quick ↦brown fox↤ jumped over the lazy baboon"
 
-The `RIGHT_ARROW` is Unicode \u21a6 and the `LEFT_ARROW` is Unicode \u21a4. 
These are chosen to be single characters that in most situations will be very 
unlikely to occur in resulting literals. The `fragSize` of 128 is chosen to be 
large enough that in many situations the matches will result in single 
fragments. If the literal is larger than 128 characters and there are several 
matches in the literal then there may be additional fragments separated by the 
`DIVIDES`, Unicode \u2223.
+The `RIGHT_ARROW` is Unicode, \u21a6, and the `LEFT_ARROW` is Unicode, \u21a4. 
These are chosen to be single characters that in most situations will be very 
unlikely to occur in resulting literals. The `fragSize` of 128 is chosen to be 
large enough that in many situations the matches will result in single 
fragments. If the literal is larger than 128 characters and there are several 
matches in the literal then there may be additional fragments separated by the 
`DIVIDES`, Unicode, \u2223.
 
 Depending on the analyzer used and the tokenizer,

CMS diff: Jena Full Text Search

2018-01-21 Thread Chris Tomlinson 
Clone URL (Committers only):
https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/documentation%2Fquery%2Ftext-query.mdtext

Chris Tomlinson

Index: trunk/content/documentation/query/text-query.mdtext
===
--- trunk/content/documentation/query/text-query.mdtext (revision 1821823)
+++ trunk/content/documentation/query/text-query.mdtext (working copy)
@@ -1,5 +1,7 @@
 Title: Jena Full Text Search
 
+Title: Jena Full Text Search
+
 This extension to ARQ combines SPARQL and full text search via
 [Lucene](https://lucene.apache.org) 6.4.1 or
 [ElasticSearch](https://www.elastic.co) 5.2.1 (which is built on
@@ -231,7 +233,7 @@
 
 The most general form is:

- (?s ?score ?literal ?g) text:query (property 'query string' limit 
'lang:xx')
+ ( ?s ?score ?literal ?g ) text:query ( property 'query string' limit 
'lang:xx' 'highlight:yy' )
 
  Input arguments:
 
@@ -241,13 +243,13 @@
 | query string  | Lucene query string fragment   |
 | limit | (optional) `int` limit on the number of results   |
 | lang:xx   | (optional) language tag spec   |
-| highlight:xx  | (optional) highlighting options|
+| highlight:yy  | (optional) highlighting options|
 
 The `property` URI is only necessary if multiple properties have been
 indexed and the property being searched over is not the [default field
 of the index](#entity-map-definition).
 
-The `query string` syntax conforms the underlying index 
[Lucene](http://lucene.apache.org/core/6_4_1/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#package_description)
+The `query string` syntax conforms to the underlying index 
[Lucene](http://lucene.apache.org/core/6_4_1/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#package_description)
 or
 
[Elasticsearch](https://www.elastic.co/guide/en/elasticsearch/reference/5.2/query-dsl.html).
 In the case of Lucene the syntax is restricted to `Terms`, `Term modifiers`, 
`Boolean Operators` applied to `Terms`, and `Grouping` of terms. _No use of 
`Fields` within the `query string` is supported._
 
@@ -258,9 +260,9 @@
 indexed with the tag _xx_. Searches may be restricted to field values with no 
 language tag via `"lang:none"`. 
 
-The `highlight:xx` specification is an optional string where _xx_ are options 
that control the highlighting of search result literals. See 
[below](#highlighting) for details.
+The `highlight:yy` specification is an optional string where _yy_ are options 
that control the highlighting of search result literals. See 
[below](#highlighting) for details.
 
-If both `limit` and one or more of `lang:xx` or `highlight:xx` are present, 
then `limit` must precede these arguments.
+If both `limit` and one or more of `lang:xx` or `highlight:yy` are present, 
then `limit` must precede these arguments.
 
 If only the query string is required, the surrounding `( )` _may be_ omitted.
 
@@ -521,7 +523,7 @@
 
 "the quick ↦brown fox↤ jumped over the lazy baboon"
 
-The `RIGHT_ARROW` is Unicode \u21a6 and the `LEFT_ARROW` is Unicode \u21a4. 
These are chosen to be single characters that in most situations will be very 
unlikely to occur in resulting literals. The `fragSize` of 128 is chosen to be 
large enough that in many situations the matches will result in single 
fragments. If the literal is larger than 128 characters and there are several 
matches in the literal then there may be additional fragments separated by the 
`DIVIDES`, Unicode \u2223.
+The `RIGHT_ARROW` is Unicode, \u21a6, and the `LEFT_ARROW` is Unicode, \u21a4. 
These are chosen to be single characters that in most situations will be very 
unlikely to occur in resulting literals. The `fragSize` of 128 is chosen to be 
large enough that in many situations the matches will result in single 
fragments. If the literal is larger than 128 characters and there are several 
matches in the literal then there may be additional fragments separated by the 
`DIVIDES`, Unicode, \u2223.
 
 Depending on the analyzer used and the tokenizer, the highlighting will result 
in marking each token rather than an entire phrase. The `joinHi` option is by 
default `true` so that entire phrases are highlighted together rather than as 
individual tokens as in:

CMS diff: Jena Full Text Search

2018-01-21 Thread Chris Tomlinson 
Clone URL (Committers only):
https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/documentation%2Fquery%2Ftext-query.mdtext

Chris Tomlinson

Index: trunk/content/documentation/query/text-query.mdtext
===
--- trunk/content/documentation/query/text-query.mdtext (revision 1821823)
+++ trunk/content/documentation/query/text-query.mdtext (working copy)
@@ -1,5 +1,7 @@
 Title: Jena Full Text Search
 
+Title: Jena Full Text Search
+
 This extension to ARQ combines SPARQL and full text search via
 [Lucene](https://lucene.apache.org) 6.4.1 or
 [ElasticSearch](https://www.elastic.co) 5.2.1 (which is built on
@@ -231,7 +233,7 @@
 
 The most general form is:

- (?s ?score ?literal ?g) text:query (property 'query string' limit 
'lang:xx')
+ ( ?s ?score ?literal ?g ) text:query ( property 'query string' limit 
'lang:xx' 'highlight:yy' )
 
  Input arguments:
 
@@ -241,7 +243,7 @@
 | query string  | Lucene query string fragment   |
 | limit | (optional) `int` limit on the number of results   |
 | lang:xx   | (optional) language tag spec   |
-| highlight:xx  | (optional) highlighting options|
+| highlight:yy  | (optional) highlighting options|
 
 The `property` URI is only necessary if multiple properties have been
 indexed and the property being searched over is not the [default field
@@ -258,9 +260,9 @@
 indexed with the tag _xx_. Searches may be restricted to field values with no 
 language tag via `"lang:none"`. 
 
-The `highlight:xx` specification is an optional string where _xx_ are options 
that control the highlighting of search result literals. See 
[below](#highlighting) for details.
+The `highlight:yy` specification is an optional string where _yy_ are options 
that control the highlighting of search result literals. See 
[below](#highlighting) for details.
 
-If both `limit` and one or more of `lang:xx` or `highlight:xx` are present, 
then `limit` must precede these arguments.
+If both `limit` and one or more of `lang:xx` or `highlight:yy` are present, 
then `limit` must precede these arguments.
 
 If only the query string is required, the surrounding `( )` _may be_ omitted.
 
@@ -521,7 +523,7 @@
 
 "the quick ↦brown fox↤ jumped over the lazy baboon"
 
-The `RIGHT_ARROW` is Unicode \u21a6 and the `LEFT_ARROW` is Unicode \u21a4. 
These are chosen to be single characters that in most situations will be very 
unlikely to occur in resulting literals. The `fragSize` of 128 is chosen to be 
large enough that in many situations the matches will result in single 
fragments. If the literal is larger than 128 characters and there are several 
matches in the literal then there may be additional fragments separated by the 
`DIVIDES`, Unicode \u2223.
+The `RIGHT_ARROW` is Unicode, \u21a6, and the `LEFT_ARROW` is Unicode, \u21a4. 
These are chosen to be single characters that in most situations will be very 
unlikely to occur in resulting literals. The `fragSize` of 128 is chosen to be 
large enough that in many situations the matches will result in single 
fragments. If the literal is larger than 128 characters and there are several 
matches in the literal then there may be additional fragments separated by the 
`DIVIDES`, Unicode, \u2223.
 
 Depending on the analyzer used and the tokenizer, the highlighting will result 
in marking each token rather than an entire phrase. The `joinHi` option is by 
default `true` so that entire phrases are highlighted together rather than as 
individual tokens as in:

[GitHub] jena pull request #343: Fixes for JENA-1457

2018-01-21 Thread Claudenw 
GitHub user Claudenw opened a pull request:

https://github.com/apache/jena/pull/343

Fixes for JENA-1457

I had some issues with merging into my branch so I created this pull to 
ensure that only expected files were updated.  

As part of addition ot JENA-1457 this updates junit-contracts to version 
0.2.0

Also added .recommenders directory to RAT exclude. (it was already in 
.gitignore)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Claudenw/jena master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jena/pull/343.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #343


commit 50703b41060227741304d5e6e236ef57c10b6df8
Author: Claude Warren 
Date:   2017-12-29T20:45:33Z

fixed Graph tests

commit 20b78ae0ddc7a2102602a28f9ed3f48a40c99a1b
Author: Andy Seaborne 
Date:   2017-12-18T14:49:40Z

Blank node labels for JSON Result Set reading

commit 30989a54b4aec3453152ce970832eea8e8acc0d3
Author: Claude Warren 
Date:   2018-01-20T10:10:53Z

Merge remote-tracking branch 'apache/master' into 
FixGraphContractTestTransactionUsage

commit fa23c25835247e2586ed37ad491c45322dca45b6
Author: Claude Warren 
Date:   2018-01-20T10:40:33Z

Added .recommenders to RAT exclusion.

commit 185badb543a6290ae533a0142f416ab4f466043b
Author: Claude Warren 
Date:   2018-01-20T21:29:36Z

Updated version number for junit-contracts to 0.2.0

commit 363e95818710ec45352bf8e1330dcf3bf1f59686
Author: Claude Warren 
Date:   2018-01-21T12:13:23Z

Merge branch 'master' into FixGraphContractTestTransactionUsage

commit 554a7dc86a4967a9971354f4d7b19354a9d07402
Author: Claude Warren 
Date:   2018-01-21T13:12:19Z

fixes JENA-1457

Removed incorrect JSONInput.java




---

Re: CMS diff: Jena Full Text Search

2018-01-21 Thread Andy Seaborne 

Thank you!
Changes applied.

Andy

On 20/01/18 21:21, Chris Tomlinson wrote:

Clone URL (Committers only):
https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/documentation%2Fquery%2Ftext-query.mdtext

Chris Tomlinson

Index: trunk/content/documentation/query/text-query.mdtext
===
--- trunk/content/documentation/query/text-query.mdtext (revision 1821724)
+++ trunk/content/documentation/query/text-query.mdtext (working copy)
@@ -2,6 +2,8 @@
  
  Title: Jena Full Text Search
  
+Title: Jena Full Text Search

+
  This extension to ARQ combines SPARQL and full text search via
  [Lucene](https://lucene.apache.org) 6.4.1 or
  [ElasticSearch](https://www.elastic.co) 5.2.1 (which is built on
@@ -80,6 +82,7 @@
  -   [Queries with graphs](#queries-with-graphs)
  -   [Queries across multiple 
`Fields`](#queries-across-multiple-fields)
  -   [Queries with _Boolean Operators_ and _Term 
Modifiers_](#queries-with-boolean-operators-and-term-modifiers)
+-   [Highlighting](#highlighting)
  -   [Good practice](#good-practice)
  -   [Configuration](#configuration)
  -   [Text Dataset Assembler](#text-dataset-assembler)
@@ -242,6 +245,7 @@
  | query string  | Lucene query string fragment   |
  | limit | (optional) `int` limit on the number of results   |
  | lang:xx   | (optional) language tag spec   |
+| highlight:xx  | (optional) highlighting options|
  
  The `property` URI is only necessary if multiple properties have been

  indexed and the property being searched over is not the [default field
@@ -258,8 +262,10 @@
  indexed with the tag _xx_. Searches may be restricted to field values with no
  language tag via `"lang:none"`.
  
-If both `limit` and `lang:xx` are present, then `limit` must precede `lang:xx`.

+The `highlight:xx` specification is an optional string where _xx_ are options 
that control the highlighting of search result literals. See 
[below](#highlighting) for details.
  
+If both `limit` and one or more of `lang:xx` or `highlight:xx` are present, then `limit` must precede these arguments.

+
  If only the query string is required, the surrounding `( )` _may be_ omitted.
  
   Output arguments:

@@ -495,7 +501,52 @@
  **Always surround the query string with `( )` if more than a single term or 
phrase
  are involved.**
  
+ Highlighting
  
+The highlighting option uses the Lucene `Highlighter` and `SimpleHTMLFormatter` to insert highlighting markup into the literals returned from search results (hence the text dataset must be configured to store the literals). The highlighted results are returned via the _literal_ output argument.

+
+The simplest way to request highlighting is via `'highlight:'`. This will 
apply all the defaults:
+
+| Option | Key | Default |
+||-|-|
+| maxFrags | m: | 3 |
+| fragSize | z: |  128 |
+| start | s: | RIGHT_ARROW |
+| end | e: | LEFT_ARROW |
+| fragSep | f: | DIVIDES |
+| joinHi | jh: | true |
+| joinFrags | jf: | true |
+
+to the highlighting of the search results. For example if the query is:
+
+(?s ?sc ?lit) text:query ( "brown fox" "highlight:" )
+
+then a resulting literal binding might be:
+
+"the quick ↦brown fox↤ jumped over the lazy baboon"
+
+The `RIGHT_ARROW` is Unicode \u21a6 and the `LEFT_ARROW` is Unicode \u21a4. 
These are chosen to be single characters that in most situations will be very 
unlikely to occur in resulting literals. The `fragSize` of 128 is chosen to be 
large enough that in many situations the matches will result in single 
fragments. If the literal is larger than 128 characters and there are several 
matches in the literal then there may be additional fragments separated by the 
`DIVIDES`, Unicode \u2223.
+
+Depending on the analyzer used and the tokenizer, the highlighting will result 
in marking each token rather than an entire phrase. The `joinHi` option is by 
default `true` so that entire phrases are highlighted together rather than as 
individual tokens as in:
+
+"the quick ↦brown↤ ↦fox↤ jumped over the lazy baboon"
+
+which would result from:
+
+(?s ?sc ?lit) text:query ( "brown fox" "highlight:jh:n" )
+
+The `jh` and `jf` boolean options are set `false` via `n`. Any other value is 
`true`. The defaults for these options have been selected to be reasonable for 
most applications.
+
+The joining is performed post highlighting via Java `String replaceAll` rather 
than using the Lucene Unified Highlighter facility which requires that term 
vectors and positions be stored. The joining deletes _extra_ highlighting with 
only intervening Unicode separators, `\p{Z}`.
+
+The more conventional output of the Lucene `SimpleHTMLFormatter` with html emphasis markup is 
achieved via, `"highlight:s: | e:"` (highlight options 
are separated by a Unicode vertical line, \u007c. The spaces are

[GitHub] jena issue #343: Fixes for JENA-1457

2018-01-21 Thread afs 
Github user afs commented on the issue:

https://github.com/apache/jena/pull/343
  
Yes - there are problems with JSONInput.  This is visible in the {{.patch}} 
form.  It looks like changes were copied from Jena master and separately 
committed.


---

Re: RDFConnection fetch() issue?

2018-01-21 Thread Andy Seaborne 



On 20/01/18 23:51, Claude Warren wrote:

I am working with an RDFConnection to a Fuseki server.

The server is set up as

DatasetGraph serverdsg = DatasetGraphFactory.createTxnMem();
FusekiServer server = FusekiServer.make( 3030, "/ds", serverdsg );
 server.start();

I have called

ARQ.enableBlankNodeResultLabels(true);

It seems that  the fetch() and query() results for the same graph are
different.

calling

connection.query( "SELECT ?s ?p ?o  WHERE {  ?s ?p ?o }" )

yields different blank node ID from

connection.fetch();

and

connection.queryConstruct( "CONSTRUCT { ?s ?p ?o } WHERE { ?s ?p ?o }" );

yields a different blank nodes from either of the above.


For the latter two, every call returns new blank nodes.




I'm not sure if this is a defect or an undocumented feature, or perhaps a
bit of both.

I can understand that the "fetch" is different as is simply gets a TURTLE
dump of the db and so the blank nodes might be renumbered.  But I would
expect that the construct should return the same node values -- then again,
perhaps not as it is a new model as well.

If this is not a bug (and I am beginning to suspect it isn't) I think the
javadoc should be updated to specify when the
ARQ.enableBlankNodeResultLabels(true); is in play and when it is not.


Correct - this is not a bug.  "Result" here means ResultSet.

Adding round-trip handling to models without skolemization (which 
changes the RDF itself) would have to be done in parallel to result 
sets.  It is more work because there are more syntax combinations to 
consider.


Mapping labels happens twice: once on the way out (writing) to get 
either sort forms like "[:p 123 ; :q 456]" or nice labels _:b0, _:b1, 
and once on the way in, parsing the input.  Note the "[]" case make 
providing blank node labels have a major effect in appearance.


Exposing the iterator versions for CONSTRUCT is possible and non-standard.

For working with remote locations, when you want to round-trip blank 
node labels, and remain with formats that still legal standards,

is best restricted to result sets, failing a full, and non-standard,
log protocol (and ideally binary).  RDF Patch.

Andy





Claude

[GitHub] jena pull request #343: Fixes for JENA-1457

2018-01-21 Thread afs 
Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/343#discussion_r162823649
  
--- Diff: 
jena-core/src/test/java/org/apache/jena/graph/GraphWithPerformContractTest.java 
---
@@ -68,7 +68,13 @@ public void testPerformAdd_Triple() {
g.performAdd(triple("S3 P3 O3"));
txnCommit(g);
GL.assertEmpty();
+   txnRun( g, new Runnable() {
--- End diff --

There is no need to explicitly have a `Runnable` here or in the other uses:
```
txnRun( g, ()->assertTrue(g.contains(triple("S3 P3 O3"))) );
```
makes the tests shorter and clearer.


---

[jira] [Commented] (JENA-1457) Graph contract tests do not properly support transactions

2018-01-21 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on JENA-1457:
--

Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/343#discussion_r162823649
  
--- Diff: 
jena-core/src/test/java/org/apache/jena/graph/GraphWithPerformContractTest.java 
---
@@ -68,7 +68,13 @@ public void testPerformAdd_Triple() {
g.performAdd(triple("S3 P3 O3"));
txnCommit(g);
GL.assertEmpty();
+   txnRun( g, new Runnable() {
--- End diff --

There is no need to explicitly have a `Runnable` here or in the other uses:
```
txnRun( g, ()->assertTrue(g.contains(triple("S3 P3 O3"))) );
```
makes the tests shorter and clearer.


> Graph contract tests do not properly support transactions
> -
>
> Key: JENA-1457
> URL: https://issues.apache.org/jira/browse/JENA-1457
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Core
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> The Contract test for Graphs do not properly support transactions.  
> Specifically, if the graph supports transactions all actions should be 
> enclosed within a transaction.
> The easiest test for this is to test the GraphTxnTDB implementation as it 
> will fail if transactions are not properly used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1457) Graph contract tests do not properly support transactions

2018-01-21 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on JENA-1457:
--

Github user afs commented on the issue:

https://github.com/apache/jena/pull/343
  
Yes - there are problems with JSONInput.  This is visible in the {{.patch}} 
form.  It looks like changes were copied from Jena master and separately 
committed.


> Graph contract tests do not properly support transactions
> -
>
> Key: JENA-1457
> URL: https://issues.apache.org/jira/browse/JENA-1457
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Core
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> The Contract test for Graphs do not properly support transactions.  
> Specifically, if the graph supports transactions all actions should be 
> enclosed within a transaction.
> The easiest test for this is to test the GraphTxnTDB implementation as it 
> will fail if transactions are not properly used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (JENA-1469) GraphTxnTDB does not handle abort() properly

2018-01-21 Thread Andy Seaborne (JIRA) 

 [ 
https://issues.apache.org/jira/browse/JENA-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne reassigned JENA-1469:
---

Assignee: Andy Seaborne

> GraphTxnTDB does not handle abort() properly
> 
>
> Key: JENA-1469
> URL: https://issues.apache.org/jira/browse/JENA-1469
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB
>Affects Versions: Jena 3.7.0
>Reporter: Claude Warren
>Assignee: Andy Seaborne
>Priority: Major
> Attachments: TDBGraphTxnTest.java
>
>
> If, when in a transaction, an instance of GraphTxnTDB calls abort() and 
> subsquently calls begin() an "Existing active write transaction"  
> TDBTransactionException is thrown.
>  
> Example JUnit test is attached.
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1469) GraphTxnTDB does not handle abort() properly

2018-01-21 Thread Andy Seaborne (JIRA) 

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

Andy Seaborne commented on JENA-1469:
-

This isn't directly related to graphs: it's an issue with TDB1 as illustrated 
by:

{noformat}
public static void main(String ... a) {
DatasetGraph dsg = TDBFactory.createDatasetGraph();
// AbstractTestTransactionLifecycle
//Txn.exec(dsg,  TxnType.READ_PROMOTE, ()->g.add( t ));
dsg.begin(TxnType.READ_PROMOTE);
dsg.promote();
dsg.commit();
dsg.end();
dsg.begin(TxnType.WRITE);
dsg.commit();
dsg.end(); 
System.out.println("Done");
System.exit(0);
}
{noformat}

Using {{DatasetGraphTransaction}} and {{GraphTxnTDB}} isn't a good idea - they 
are internal classes and have their own additional (and internal) contract.

> GraphTxnTDB does not handle abort() properly
> 
>
> Key: JENA-1469
> URL: https://issues.apache.org/jira/browse/JENA-1469
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB
>Affects Versions: Jena 3.7.0
>Reporter: Claude Warren
>Priority: Major
> Attachments: TDBGraphTxnTest.java
>
>
> If, when in a transaction, an instance of GraphTxnTDB calls abort() and 
> subsquently calls begin() an "Existing active write transaction"  
> TDBTransactionException is thrown.
>  
> Example JUnit test is attached.
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1457) Graph contract tests do not properly support transactions

2018-01-21 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on JENA-1457:
--

GitHub user Claudenw opened a pull request:

https://github.com/apache/jena/pull/343

Fixes for JENA-1457

I had some issues with merging into my branch so I created this pull to 
ensure that only expected files were updated.  

As part of addition ot JENA-1457 this updates junit-contracts to version 
0.2.0

Also added .recommenders directory to RAT exclude. (it was already in 
.gitignore)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Claudenw/jena master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jena/pull/343.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #343


commit 50703b41060227741304d5e6e236ef57c10b6df8
Author: Claude Warren 
Date:   2017-12-29T20:45:33Z

fixed Graph tests

commit 20b78ae0ddc7a2102602a28f9ed3f48a40c99a1b
Author: Andy Seaborne 
Date:   2017-12-18T14:49:40Z

Blank node labels for JSON Result Set reading

commit 30989a54b4aec3453152ce970832eea8e8acc0d3
Author: Claude Warren 
Date:   2018-01-20T10:10:53Z

Merge remote-tracking branch 'apache/master' into 
FixGraphContractTestTransactionUsage

commit fa23c25835247e2586ed37ad491c45322dca45b6
Author: Claude Warren 
Date:   2018-01-20T10:40:33Z

Added .recommenders to RAT exclusion.

commit 185badb543a6290ae533a0142f416ab4f466043b
Author: Claude Warren 
Date:   2018-01-20T21:29:36Z

Updated version number for junit-contracts to 0.2.0

commit 363e95818710ec45352bf8e1330dcf3bf1f59686
Author: Claude Warren 
Date:   2018-01-21T12:13:23Z

Merge branch 'master' into FixGraphContractTestTransactionUsage

commit 554a7dc86a4967a9971354f4d7b19354a9d07402
Author: Claude Warren 
Date:   2018-01-21T13:12:19Z

fixes JENA-1457

Removed incorrect JSONInput.java




> Graph contract tests do not properly support transactions
> -
>
> Key: JENA-1457
> URL: https://issues.apache.org/jira/browse/JENA-1457
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Core
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> The Contract test for Graphs do not properly support transactions.  
> Specifically, if the graph supports transactions all actions should be 
> enclosed within a transaction.
> The easiest test for this is to test the GraphTxnTDB implementation as it 
> will fail if transactions are not properly used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (JENA-1457) Graph contract tests do not properly support transactions

2018-01-21 Thread Claude Warren (JIRA) 

 [ 
https://issues.apache.org/jira/browse/JENA-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claude Warren reassigned JENA-1457:
---

Assignee: Claude Warren

> Graph contract tests do not properly support transactions
> -
>
> Key: JENA-1457
> URL: https://issues.apache.org/jira/browse/JENA-1457
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Core
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> The Contract test for Graphs do not properly support transactions.  
> Specifically, if the graph supports transactions all actions should be 
> enclosed within a transaction.
> The easiest test for this is to test the GraphTxnTDB implementation as it 
> will fail if transactions are not properly used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1459) add highlighting support to jena-text

2018-01-21 Thread ASF subversion and git services (JIRA) 

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

ASF subversion and git services commented on JENA-1459:
---

Commit 1821786 from [~andy.seaborne] in branch 'site/trunk'
[ https://svn.apache.org/r1821786 ]

JENA-1459: Documentation updates

> add highlighting support to jena-text
> -
>
> Key: JENA-1459
> URL: https://issues.apache.org/jira/browse/JENA-1459
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Jena, Text
>Affects Versions: Jena 3.6.0
>Reporter: Code Ferret
>Assignee: Code Ferret
>Priority: Major
> Fix For: Jena 3.7.0
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> This issue proposes an improvement to jena-text to include optional 
> highlighting of results via:
> {{org.apache.lucene.search.highlight.Highlighter}}
> and 
> {{org.apache.lucene.search.highlight.SimpleHTMLFormatter}}
> The improvement will add an optional input argument to {{TextQueryPF}} that 
> signals that highlighting should be performed on the Lucene search results; 
> optionally indicates the _start_ and _end_ char sequences of a highlighted 
> term; optionally indicates the maximum number of fragments to highlight; and 
> optionally indicates a fragment separator.
> The highlighted results are bound to the {{?literal}} output argument of  
> {{TextQueryPF}}.
> Inclusion of this improvement will introduce a simple extraction of the 
> _highlight_ option string and a single test for the presence of the option 
> string so that the inclusion of the improvement will be of minimal impact 
> when highlighting is not used. The _highlight_ option string is passed 
> directly to {{TextIndex.query(...)}} and so can be used from code other than 
> {{TextQueryPF}}.
> The simplest use of highlighting is like:
> {code}
> select ?s ?lit
> where {
>   (?s ?sc ?lit) text:query (skos:prefLabel "one" 100 "lang:en" "highlight:") .
> }
> {code}
> which will produce results such as:
> {code}
> "another ↦one↤ abc"@en
> {code}
> the right-arrow (\u21a6) and left-arrow (\u21a4) are the default _start_ and 
> _end_ highlighting character sequences. These are chosen to be very unlikely 
> to occur in literals. These can be changed easily via {{"s:"}} and {{"e:"}} 
> in the highlight options, for example:
> {code}
> select ?s ?lit
> where {
>   (?s ?sc ?lit) text:query (skos:prefLabel "one" 100 "lang:en" "highlight: 
> s: | e:") .
> {code}
> which will produce results such as:
> {code}
> "another one abc"@en
> {code}
> Coding of this improvement is complete and a PR can be issued if there is 
> agreement that this improvement should be included in jena-text.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)