[jira] [Commented] (JENA-1430) Quad loading for in-memory assemblers

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1430:
--

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

https://github.com/apache/jena/pull/314#discussion_r154233681
  
--- Diff: 
jena-arq/src/test/java/org/apache/jena/sparql/core/assembler/TestDatasetAssembler.java
 ---
@@ -0,0 +1,122 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.jena.sparql.core.assembler;
+
+import static java.nio.file.Files.createTempFile;
+import static org.apache.jena.assembler.JA.data;
+import static org.apache.jena.assembler.Mode.DEFAULT;
+import static org.apache.jena.rdf.model.ModelFactory.createDefaultModel;
+import static org.apache.jena.riot.Lang.NQUADS;
+import static org.apache.jena.riot.RDFDataMgr.write;
+import static org.apache.jena.vocabulary.RDF.type;
+
+import java.io.*;
+import java.nio.file.Path;
+
+import org.apache.jena.assembler.JA;
+import org.apache.jena.assembler.exceptions.CannotConstructException;
+import org.apache.jena.query.Dataset;
+import org.apache.jena.rdf.model.*;
+import org.apache.jena.sparql.core.*;
+import org.apache.jena.sparql.sse.SSE;
+import org.apache.jena.sparql.util.IsoMatcher;
+import org.apache.jena.system.Txn;
+import org.junit.Assert;
+import org.junit.Test;
+
+public class TestDatasetAssembler extends Assert {
--- End diff --

I was lookign for tests that do both `ja:data` and `ja:defaultGraph`, which 
should be an error. I saw someone asking recently trying with `ja:defaultGraph` 
and TIM assemble, which just ignores unknown properties.  Easy confusion to 
make - so deliberately testing making an error seems sensible.


> Quad loading for in-memory assemblers
> -
>
> Key: JENA-1430
> URL: https://issues.apache.org/jira/browse/JENA-1430
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Reporter: A. Soroka
>Assignee: A. Soroka
>
> In-memory dataset Assemblers should support loading quad files.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] jena pull request #314: JENA-1430

[afs]

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

https://github.com/apache/jena/pull/314#discussion_r154233681
  
--- Diff: 
jena-arq/src/test/java/org/apache/jena/sparql/core/assembler/TestDatasetAssembler.java
 ---
@@ -0,0 +1,122 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.jena.sparql.core.assembler;
+
+import static java.nio.file.Files.createTempFile;
+import static org.apache.jena.assembler.JA.data;
+import static org.apache.jena.assembler.Mode.DEFAULT;
+import static org.apache.jena.rdf.model.ModelFactory.createDefaultModel;
+import static org.apache.jena.riot.Lang.NQUADS;
+import static org.apache.jena.riot.RDFDataMgr.write;
+import static org.apache.jena.vocabulary.RDF.type;
+
+import java.io.*;
+import java.nio.file.Path;
+
+import org.apache.jena.assembler.JA;
+import org.apache.jena.assembler.exceptions.CannotConstructException;
+import org.apache.jena.query.Dataset;
+import org.apache.jena.rdf.model.*;
+import org.apache.jena.sparql.core.*;
+import org.apache.jena.sparql.sse.SSE;
+import org.apache.jena.sparql.util.IsoMatcher;
+import org.apache.jena.system.Txn;
+import org.junit.Assert;
+import org.junit.Test;
+
+public class TestDatasetAssembler extends Assert {
--- End diff --

I was lookign for tests that do both `ja:data` and `ja:defaultGraph`, which 
should be an error. I saw someone asking recently trying with `ja:defaultGraph` 
and TIM assemble, which just ignores unknown properties.  Easy confusion to 
make - so deliberately testing making an error seems sensible.


---

[jira] [Commented] (JENA-1430) Quad loading for in-memory assemblers

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1430:
--

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

https://github.com/apache/jena/pull/314#discussion_r154233274
  
--- Diff: 
jena-arq/src/test/java/org/apache/jena/sparql/core/assembler/TestDatasetAssembler.java
 ---
@@ -0,0 +1,122 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.jena.sparql.core.assembler;
+
+import static java.nio.file.Files.createTempFile;
+import static org.apache.jena.assembler.JA.data;
+import static org.apache.jena.assembler.Mode.DEFAULT;
+import static org.apache.jena.rdf.model.ModelFactory.createDefaultModel;
+import static org.apache.jena.riot.Lang.NQUADS;
+import static org.apache.jena.riot.RDFDataMgr.write;
+import static org.apache.jena.vocabulary.RDF.type;
+
+import java.io.*;
+import java.nio.file.Path;
+
+import org.apache.jena.assembler.JA;
+import org.apache.jena.assembler.exceptions.CannotConstructException;
+import org.apache.jena.query.Dataset;
+import org.apache.jena.rdf.model.*;
+import org.apache.jena.sparql.core.*;
+import org.apache.jena.sparql.sse.SSE;
+import org.apache.jena.sparql.util.IsoMatcher;
+import org.apache.jena.system.Txn;
+import org.junit.Assert;
+import org.junit.Test;
+
+public class TestDatasetAssembler extends Assert {
--- End diff --

Generally, tests are loaded from a `testing/` directory, not the classpath. 
 Some tests need to read real, normal files and also the W3C SPARQL tests run 
from on-disk files and manifests.  Once some tests do need files, there isn't 
much value in classpath loading as its extra, not instead of.  Assemblers need 
to read from files, it being the common usecase.




> Quad loading for in-memory assemblers
> -
>
> Key: JENA-1430
> URL: https://issues.apache.org/jira/browse/JENA-1430
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Reporter: A. Soroka
>Assignee: A. Soroka
>
> In-memory dataset Assemblers should support loading quad files.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] jena pull request #314: JENA-1430

[afs]

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

https://github.com/apache/jena/pull/314#discussion_r154233274
  
--- Diff: 
jena-arq/src/test/java/org/apache/jena/sparql/core/assembler/TestDatasetAssembler.java
 ---
@@ -0,0 +1,122 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.jena.sparql.core.assembler;
+
+import static java.nio.file.Files.createTempFile;
+import static org.apache.jena.assembler.JA.data;
+import static org.apache.jena.assembler.Mode.DEFAULT;
+import static org.apache.jena.rdf.model.ModelFactory.createDefaultModel;
+import static org.apache.jena.riot.Lang.NQUADS;
+import static org.apache.jena.riot.RDFDataMgr.write;
+import static org.apache.jena.vocabulary.RDF.type;
+
+import java.io.*;
+import java.nio.file.Path;
+
+import org.apache.jena.assembler.JA;
+import org.apache.jena.assembler.exceptions.CannotConstructException;
+import org.apache.jena.query.Dataset;
+import org.apache.jena.rdf.model.*;
+import org.apache.jena.sparql.core.*;
+import org.apache.jena.sparql.sse.SSE;
+import org.apache.jena.sparql.util.IsoMatcher;
+import org.apache.jena.system.Txn;
+import org.junit.Assert;
+import org.junit.Test;
+
+public class TestDatasetAssembler extends Assert {
--- End diff --

Generally, tests are loaded from a `testing/` directory, not the classpath. 
 Some tests need to read real, normal files and also the W3C SPARQL tests run 
from on-disk files and manifests.  Once some tests do need files, there isn't 
much value in classpath loading as its extra, not instead of.  Assemblers need 
to read from files, it being the common usecase.




---

[jira] [Commented] (JENA-1427) Add nextOrElse() method in ExtendedIterator

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1427:
--

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/323
  
That's my point-- I don't think you can do a good fluent API for this 
without narrowing the `Iterator` contract to exclude `null`s, because you can't 
distinguish. We can do that (narrow the contact)-- we own `ExtendedIterator` 
and as you say, we aren't pushing `null`s through it for the `Model` API.

So my vote is that we do what you have here, but _also_ add a note to 
`ExtendedIterator` guaranteeing that `next()` must not return `null`.


> Add nextOrElse() method in ExtendedIterator
> ---
>
> Key: JENA-1427
> URL: https://issues.apache.org/jira/browse/JENA-1427
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.5.0
>Reporter: Adam Jacobs
>Priority: Trivial
>  Labels: easytask
>
> Allow a functional approach for returning a default value or throwing a 
> custom exception from a Jena iterator.
> The following method may be added to the ExtendedIterator interface.
> {noformat}
> /**
>  Answer the next object, if it exists, otherwise invoke the 
> _supplier_.
>  */
> public default T nextOrElse( Supplier supplier ) {
> return hasNext() ? next() : supplier.get();
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] jena issue #323: JENA-1427: ExtendedIterator.nextOptional

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/323
  
That's my point-- I don't think you can do a good fluent API for this 
without narrowing the `Iterator` contract to exclude `null`s, because you can't 
distinguish. We can do that (narrow the contact)-- we own `ExtendedIterator` 
and as you say, we aren't pushing `null`s through it for the `Model` API.

So my vote is that we do what you have here, but _also_ add a note to 
`ExtendedIterator` guaranteeing that `next()` must not return `null`.


---

[jira] [Commented] (JENA-1427) Add nextOrElse() method in ExtendedIterator

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1427:
--

Github user afs commented on the issue:

https://github.com/apache/jena/pull/323
  
This does not make sense to me - how can one tell from 
`nextOptional().orElseThrow()` when at the end without having to drop out of 
fluent? (or functional `first` is fluent in a functional sense).

That's why I banned nulls from iterators when using `nextOptional`; I don't 
know of a case where `ExtendedIterator` can return nulls when used in the model 
API. 

If `nextOptional` can have two different uses, we would be better off with 
`nextOr*` which do differentiate the two cases.



> Add nextOrElse() method in ExtendedIterator
> ---
>
> Key: JENA-1427
> URL: https://issues.apache.org/jira/browse/JENA-1427
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.5.0
>Reporter: Adam Jacobs
>Priority: Trivial
>  Labels: easytask
>
> Allow a functional approach for returning a default value or throwing a 
> custom exception from a Jena iterator.
> The following method may be added to the ExtendedIterator interface.
> {noformat}
> /**
>  Answer the next object, if it exists, otherwise invoke the 
> _supplier_.
>  */
> public default T nextOrElse( Supplier supplier ) {
> return hasNext() ? next() : supplier.get();
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] jena issue #323: JENA-1427: ExtendedIterator.nextOptional

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/323
  
This does not make sense to me - how can one tell from 
`nextOptional().orElseThrow()` when at the end without having to drop out of 
fluent? (or functional `first` is fluent in a functional sense).

That's why I banned nulls from iterators when using `nextOptional`; I don't 
know of a case where `ExtendedIterator` can return nulls when used in the model 
API. 

If `nextOptional` can have two different uses, we would be better off with 
`nextOr*` which do differentiate the two cases.



---

[jira] [Commented] (JENA-1427) Add nextOrElse() method in ExtendedIterator

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1427:
--

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/323
  
I'm saying we don't do `orElseThrow` or any other `orElseX`, we leave that 
to `nextOptional().orElseThrow()`, etc. Then at iterator end, `nextOptional()` 
returns `empty` forever. If there are `null`s, it returns `empty`. If you want 
to know whether that is because there are many `null`s or because the iterator 
is done, you call `hasNext()`.

Another way to put it: we shouldn't try to eliminate needing `hasNext()` 
with this-- if we want to do that, we should do something like 
`Spliterator::tryAdvance`, which is a whole different story. You can se how 
that would work a little with `Iterator::forEachRemaining`. You don't need 
`hasNext()` with that.


> Add nextOrElse() method in ExtendedIterator
> ---
>
> Key: JENA-1427
> URL: https://issues.apache.org/jira/browse/JENA-1427
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.5.0
>Reporter: Adam Jacobs
>Priority: Trivial
>  Labels: easytask
>
> Allow a functional approach for returning a default value or throwing a 
> custom exception from a Jena iterator.
> The following method may be added to the ExtendedIterator interface.
> {noformat}
> /**
>  Answer the next object, if it exists, otherwise invoke the 
> _supplier_.
>  */
> public default T nextOrElse( Supplier supplier ) {
> return hasNext() ? next() : supplier.get();
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] jena issue #323: JENA-1427: ExtendedIterator.nextOptional

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/323
  
I'm saying we don't do `orElseThrow` or any other `orElseX`, we leave that 
to `nextOptional().orElseThrow()`, etc. Then at iterator end, `nextOptional()` 
returns `empty` forever. If there are `null`s, it returns `empty`. If you want 
to know whether that is because there are many `null`s or because the iterator 
is done, you call `hasNext()`.

Another way to put it: we shouldn't try to eliminate needing `hasNext()` 
with this-- if we want to do that, we should do something like 
`Spliterator::tryAdvance`, which is a whole different story. You can se how 
that would work a little with `Iterator::forEachRemaining`. You don't need 
`hasNext()` with that.


---

Re: CMS diff: Jena Full Text Search

[Chris Tomlinson]

This commit updates the jena-text documentation to be consistent with the 
resolved JENA-1437 and JENA-1438 issues.

Regards,
Chris

> On Nov 30, 2017, at 5:00 PM, 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 
> 1816662)
> +++ 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
> @@ -64,7 +66,21 @@
> ## Table of Contents
> 
> -   [Architecture](#architecture)
> +-   [External content](#external-content)
> +-   [External applications](#external-applications)
> +-   [Document structure](#document-structure)
> -   [Query with SPARQL](#query-with-sparql)
> +-   [Syntax](#syntax)
> +-   [Input arguments](#input-arguments)
> +-   [Output arguments](#output-arguments)
> +-   [Query strings](#query-strings)
> +-   [Simple queries](#simple-queries)
> +-   [Queries with language tags](#queries-with-language-tags)
> +-   [Queries that retrieve literals](#queries-that-retrieve-literals)
> +-   [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)
> +-   [Good practice](#good-practice)
> -   [Configuration](#configuration)
> -   [Text Dataset Assembler](#text-dataset-assembler)
> -   [Configuring an analyzer](#configuring-an-analyzer)
> @@ -108,6 +124,7 @@
> 
> The text index uses the native query language of the index:
> [Lucene query 
> language](http://lucene.apache.org/core/6_4_1/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#package_description)
> +(with [restrictions](#input-arguments))
> or
> [Elasticsearch query 
> language](https://www.elastic.co/guide/en/elasticsearch/reference/5.2/query-dsl.html).
> 
> @@ -134,6 +151,64 @@
> By using Elasticsearch, other applications can share the text index with
> SPARQL search.
> 
> +### Document structure
> +
> +As mentioned above, text indexing of a triple involves associating a Lucene
> +document with the triple. How is this done?
> +
> +Lucene documents are composed of `Field`s. Indexing and searching are 
> performed 
> +over the contents of these `Field`s. For an RDF triple to be indexed in 
> Lucene the 
> +_property_ of the triple must be 
> +[configured in the entity map of a TextIndex](#entity-map-definition).
> +This associates a Lucene analyzer with the _`property`_ which will be used
> +for indexing and search. The _`property`_ becomes the _searchable_ Lucene 
> +`Field` in the resulting document.
> +
> +A Lucene index includes a _default_ `Field`, which is specified in the 
> configuration, 
> +that is the field to search if not otherwise named in the query. In 
> jena-text 
> +this field is configured via the `text:defaultField` property which is then 
> mapped 
> +to a specific RDF property via `text:predicate` (see [entity 
> map](#entity-map-definition) 
> +below).
> +
> +There are several additional `Field`s that will be included in the
> +document that is passed to the Lucene `IndexWriter` depending on the
> +configuration options that are used. These additional fields are used to
> +manage the interface between Jena and Lucene and are not generally 
> +searchable per se.
> +
> +The most important of these additional `Field`s is the `text:entityField`.
> +This configuration property defines the name of the `Field` that will contain
> +the _URI_ or _blank node id_ of the _subject_ of the triple being indexed. 
> This property does
> +not have a default and must be specified for most uses of `jena-text`. This
> +`Field` is often given the name, `uri`, in examples. It is via this `Field`
> +that `?s` is bound in a typical use such as:
> +
> +select ?s
> +where {
> +?s text:query "some text"
> +}
> +
> +Other `Field`s that may be configured: `text:uidField`, `text:graphField`,
> +and so on are discussed below.
> +
> +Given the triple:
> +
> +ex:SomeOne skos:prefLabel "zorn protégé a prés"@fr ;
> +
> +The following is an abbreviated illustration a Lucene document that Jena 
> will create and
> +request Lucene to index:
> +
> +Document<
> + 
> + 
> + 
> + 
> +
>  
> +>
> +
> +It may 

CMS diff: Jena Full Text Search

[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 1816662)
+++ 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
@@ -64,7 +66,21 @@
 ## Table of Contents
 
 -   [Architecture](#architecture)
+-   [External content](#external-content)
+-   [External applications](#external-applications)
+-   [Document structure](#document-structure)
 -   [Query with SPARQL](#query-with-sparql)
+-   [Syntax](#syntax)
+-   [Input arguments](#input-arguments)
+-   [Output arguments](#output-arguments)
+-   [Query strings](#query-strings)
+-   [Simple queries](#simple-queries)
+-   [Queries with language tags](#queries-with-language-tags)
+-   [Queries that retrieve literals](#queries-that-retrieve-literals)
+-   [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)
+-   [Good practice](#good-practice)
 -   [Configuration](#configuration)
 -   [Text Dataset Assembler](#text-dataset-assembler)
 -   [Configuring an analyzer](#configuring-an-analyzer)
@@ -108,6 +124,7 @@
 
 The text index uses the native query language of the index:
 [Lucene query 
language](http://lucene.apache.org/core/6_4_1/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#package_description)
+(with [restrictions](#input-arguments))
 or
 [Elasticsearch query 
language](https://www.elastic.co/guide/en/elasticsearch/reference/5.2/query-dsl.html).
 
@@ -134,6 +151,64 @@
 By using Elasticsearch, other applications can share the text index with
 SPARQL search.
 
+### Document structure
+
+As mentioned above, text indexing of a triple involves associating a Lucene
+document with the triple. How is this done?
+
+Lucene documents are composed of `Field`s. Indexing and searching are 
performed 
+over the contents of these `Field`s. For an RDF triple to be indexed in Lucene 
the 
+_property_ of the triple must be 
+[configured in the entity map of a TextIndex](#entity-map-definition).
+This associates a Lucene analyzer with the _`property`_ which will be used
+for indexing and search. The _`property`_ becomes the _searchable_ Lucene 
+`Field` in the resulting document.
+
+A Lucene index includes a _default_ `Field`, which is specified in the 
configuration, 
+that is the field to search if not otherwise named in the query. In jena-text 
+this field is configured via the `text:defaultField` property which is then 
mapped 
+to a specific RDF property via `text:predicate` (see [entity 
map](#entity-map-definition) 
+below).
+
+There are several additional `Field`s that will be included in the
+document that is passed to the Lucene `IndexWriter` depending on the
+configuration options that are used. These additional fields are used to
+manage the interface between Jena and Lucene and are not generally 
+searchable per se.
+
+The most important of these additional `Field`s is the `text:entityField`.
+This configuration property defines the name of the `Field` that will contain
+the _URI_ or _blank node id_ of the _subject_ of the triple being indexed. 
This property does
+not have a default and must be specified for most uses of `jena-text`. This
+`Field` is often given the name, `uri`, in examples. It is via this `Field`
+that `?s` is bound in a typical use such as:
+
+select ?s
+where {
+?s text:query "some text"
+}
+
+Other `Field`s that may be configured: `text:uidField`, `text:graphField`,
+and so on are discussed below.
+
+Given the triple:
+
+ex:SomeOne skos:prefLabel "zorn protégé a prés"@fr ;
+
+The following is an abbreviated illustration a Lucene document that Jena will 
create and
+request Lucene to index:
+
+Document<
+ 
+ 
+ 
+ 
+ 
+>
+
+It may be instructive to refer back to this example when considering the 
various
+points below.
+
 ## Query with SPARQL
 
 The URI of the text extension property function is
@@ -143,63 +218,292 @@
 
 ...   text:query ...
 
+### Syntax
 
 The following forms are all legal:
 
-?s text:query 'word'   # query
-?s text:query (rdfs:label 'word')  # query specific property if 
multiple
-?s text:query ('word' 10)  

[jira] [Commented] (JENA-1427) Add nextOrElse() method in ExtendedIterator

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1427:
--

Github user afs commented on the issue:

https://github.com/apache/jena/pull/323
  
This seems to be arguing for NoSuchElementException for end of iterator and 
Optional.empty for null?

(There needs to be a way to distinguish end-of-iterator from 
iterator-returns-null.)




> Add nextOrElse() method in ExtendedIterator
> ---
>
> Key: JENA-1427
> URL: https://issues.apache.org/jira/browse/JENA-1427
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.5.0
>Reporter: Adam Jacobs
>Priority: Trivial
>  Labels: easytask
>
> Allow a functional approach for returning a default value or throwing a 
> custom exception from a Jena iterator.
> The following method may be added to the ExtendedIterator interface.
> {noformat}
> /**
>  Answer the next object, if it exists, otherwise invoke the 
> _supplier_.
>  */
> public default T nextOrElse( Supplier supplier ) {
> return hasNext() ? next() : supplier.get();
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] jena issue #323: JENA-1427: ExtendedIterator.nextOptional

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/323
  
This seems to be arguing for NoSuchElementException for end of iterator and 
Optional.empty for null?

(There needs to be a way to distinguish end-of-iterator from 
iterator-returns-null.)




---

[GitHub] jena pull request #321: Just doing some syntax cleanup by using the new Grap...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Commented] (JENA-1438) rdf:langString argument to text:query silently ignored

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1438:
--

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

https://github.com/apache/jena/pull/320#discussion_r154112909
  
--- Diff: 
jena-text/src/main/java/org/apache/jena/query/text/TextQueryPF.java ---
@@ -319,13 +311,13 @@ private StrMatch objectToStruct(PropFuncArg 
argObject, boolean executionTime) {
 
 String lang = o.getLiteralLanguage();
 RDFDatatype dt = o.getLiteralDatatype() ;
-if (noLang(lang)) {
+if (lang.isEmpty()) {
 if (dt != null && dt != XSDDatatype.XSDstring) {
 log.warn("Object to text query is not a string") ;
 return null ;
 }
 }
-lang = fixLang(lang);
+lang = lang.isEmpty() ? null : lang;
--- End diff --

Agreed and changed. Thanks


> rdf:langString argument to text:query silently ignored
> --
>
> Key: JENA-1438
> URL: https://issues.apache.org/jira/browse/JENA-1438
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Jena
>Affects Versions: Jena 3.5.0
> Environment: N/A
>Reporter: Code Ferret
>Priority: Minor
>
> Queries of the form:
> {{?s text:query "some string"@lang-code}}
> return no results even when there are matches found by the _equivalent_:
> {{?s text:query ("some string" "lang:lang-code")}}
> {quote}
> Note the above _equivalent_ form is currently valid only if 
> {{text:multilingualSupport false}}.
> {quote} See [JENA-1437|https://issues.apache.org/jira/browse/JENA-1437]
> A reasonable fix is to recognize the {{rdf:langString}} case and treat it as 
> the _equivalent_ form referring to the {{text:defautlField}}; otherwise, at 
> least an error should be indicated.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] jena pull request #320: JENA-1438 rdf:langString args

[xristy]

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

https://github.com/apache/jena/pull/320#discussion_r154112909
  
--- Diff: 
jena-text/src/main/java/org/apache/jena/query/text/TextQueryPF.java ---
@@ -319,13 +311,13 @@ private StrMatch objectToStruct(PropFuncArg 
argObject, boolean executionTime) {
 
 String lang = o.getLiteralLanguage();
 RDFDatatype dt = o.getLiteralDatatype() ;
-if (noLang(lang)) {
+if (lang.isEmpty()) {
 if (dt != null && dt != XSDDatatype.XSDstring) {
 log.warn("Object to text query is not a string") ;
 return null ;
 }
 }
-lang = fixLang(lang);
+lang = lang.isEmpty() ? null : lang;
--- End diff --

Agreed and changed. Thanks


---

[jira] [Commented] (JENA-1438) rdf:langString argument to text:query silently ignored

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1438:
--

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

https://github.com/apache/jena/pull/320#discussion_r154109219
  
--- Diff: 
jena-text/src/main/java/org/apache/jena/query/text/TextQueryPF.java ---
@@ -319,13 +311,13 @@ private StrMatch objectToStruct(PropFuncArg 
argObject, boolean executionTime) {
 
 String lang = o.getLiteralLanguage();
 RDFDatatype dt = o.getLiteralDatatype() ;
-if (noLang(lang)) {
+if (lang.isEmpty()) {
 if (dt != null && dt != XSDDatatype.XSDstring) {
 log.warn("Object to text query is not a string") ;
 return null ;
 }
 }
-lang = fixLang(lang);
+lang = lang.isEmpty() ? null : lang;
--- End diff --

I like 
[`emptyToNull`](https://google.github.io/guava/releases/19.0/api/docs/com/google/common/base/Strings.html#emptyToNull(java.lang.String))
 for this, but this isn't a problem or anything.


> rdf:langString argument to text:query silently ignored
> --
>
> Key: JENA-1438
> URL: https://issues.apache.org/jira/browse/JENA-1438
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Jena
>Affects Versions: Jena 3.5.0
> Environment: N/A
>Reporter: Code Ferret
>Priority: Minor
>
> Queries of the form:
> {{?s text:query "some string"@lang-code}}
> return no results even when there are matches found by the _equivalent_:
> {{?s text:query ("some string" "lang:lang-code")}}
> {quote}
> Note the above _equivalent_ form is currently valid only if 
> {{text:multilingualSupport false}}.
> {quote} See [JENA-1437|https://issues.apache.org/jira/browse/JENA-1437]
> A reasonable fix is to recognize the {{rdf:langString}} case and treat it as 
> the _equivalent_ form referring to the {{text:defautlField}}; otherwise, at 
> least an error should be indicated.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] jena pull request #320: JENA-1438 rdf:langString args

[ajs6f]

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

https://github.com/apache/jena/pull/320#discussion_r154109219
  
--- Diff: 
jena-text/src/main/java/org/apache/jena/query/text/TextQueryPF.java ---
@@ -319,13 +311,13 @@ private StrMatch objectToStruct(PropFuncArg 
argObject, boolean executionTime) {
 
 String lang = o.getLiteralLanguage();
 RDFDatatype dt = o.getLiteralDatatype() ;
-if (noLang(lang)) {
+if (lang.isEmpty()) {
 if (dt != null && dt != XSDDatatype.XSDstring) {
 log.warn("Object to text query is not a string") ;
 return null ;
 }
 }
-lang = fixLang(lang);
+lang = lang.isEmpty() ? null : lang;
--- End diff --

I like 
[`emptyToNull`](https://google.github.io/guava/releases/19.0/api/docs/com/google/common/base/Strings.html#emptyToNull(java.lang.String))
 for this, but this isn't a problem or anything.


---

[jira] [Commented] (JENA-1427) Add nextOrElse() method in ExtendedIterator

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1427:
--

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/323
  
Do we want to return `empty` for `null`? I ask because the "ergonomics" are 
different. The way we have it now:
```
try {
iterator.nextOptional().ifPresent(this::doStuff);
}
catch (NullPointerException e) { worry about that; }
```
vs. just `iterator.nextOptional().ifPresent(this::doStuff);` where 
`doStuff` is responsible for testing for `null`. I actually like the latter 
because `null` might be a legitimate value, but I may be misunderstanding the 
contract of `ExtendedIterator`-- is it guaranteed that `next()` never returns 
`null`? Is `null` actually not ever legit?



> Add nextOrElse() method in ExtendedIterator
> ---
>
> Key: JENA-1427
> URL: https://issues.apache.org/jira/browse/JENA-1427
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.5.0
>Reporter: Adam Jacobs
>Priority: Trivial
>  Labels: easytask
>
> Allow a functional approach for returning a default value or throwing a 
> custom exception from a Jena iterator.
> The following method may be added to the ExtendedIterator interface.
> {noformat}
> /**
>  Answer the next object, if it exists, otherwise invoke the 
> _supplier_.
>  */
> public default T nextOrElse( Supplier supplier ) {
> return hasNext() ? next() : supplier.get();
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] jena issue #323: JENA-1427: ExtendedIterator.nextOptional

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/323
  
Do we want to return `empty` for `null`? I ask because the "ergonomics" are 
different. The way we have it now:
```
try {
iterator.nextOptional().ifPresent(this::doStuff);
}
catch (NullPointerException e) { worry about that; }
```
vs. just `iterator.nextOptional().ifPresent(this::doStuff);` where 
`doStuff` is responsible for testing for `null`. I actually like the latter 
because `null` might be a legitimate value, but I may be misunderstanding the 
contract of `ExtendedIterator`-- is it guaranteed that `next()` never returns 
`null`? Is `null` actually not ever legit?



---

Re: Fwd: [GitHub] jena pull request #321: Just doing some syntax cleanup by using the new Grap...

[Andy Seaborne]

Go ahead.  The build isn't until next week (as/when I can find the time) 
and there are whole bunch of PRs.


For things like this, either it gets in ... or it doesn't.  To the 
users, it does not make much of a difference.


We have tests ...

Andy

On 29/11/17 17:56, ajs6f wrote:

Andy-- this is so trivial I would have just committed it, but I didn't want to 
bump into anything you might be doing to prep for a release.

ajs6f


Begin forwarded message:

From: ajs6f 
Subject: [GitHub] jena pull request #321: Just doing some syntax cleanup by 
using the new Grap...
Date: November 29, 2017 at 12:55:26 PM EST
To: dev@jena.apache.org
Reply-To: dev@jena.apache.org
Reply-To: dev@jena.apache.org

GitHub user ajs6f opened a pull request:

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

Just doing some syntax cleanup by using the new Graph::find method



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

$ git pull https://github.com/ajs6f/jena FindANYtoFind

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

https://github.com/apache/jena/pull/321.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 #321






---

[jira] [Commented] (JENA-1427) Add nextOrElse() method in ExtendedIterator

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1427:
--

Github user afs commented on the issue:

https://github.com/apache/jena/pull/323
  
Just the `nextOptional` part for JENA-1427.

Adding the other methods discussed there continues.



> Add nextOrElse() method in ExtendedIterator
> ---
>
> Key: JENA-1427
> URL: https://issues.apache.org/jira/browse/JENA-1427
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.5.0
>Reporter: Adam Jacobs
>Priority: Trivial
>  Labels: easytask
>
> Allow a functional approach for returning a default value or throwing a 
> custom exception from a Jena iterator.
> The following method may be added to the ExtendedIterator interface.
> {noformat}
> /**
>  Answer the next object, if it exists, otherwise invoke the 
> _supplier_.
>  */
> public default T nextOrElse( Supplier supplier ) {
> return hasNext() ? next() : supplier.get();
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] jena issue #323: JENA-1427: ExtendedIterator.nextOptional

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/323
  
Just the `nextOptional` part for JENA-1427.

Adding the other methods discussed there continues.



---

[jira] [Commented] (JENA-1427) Add nextOrElse() method in ExtendedIterator

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1427:
--

GitHub user afs opened a pull request:

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

JENA-1427: ExtendedIterator.nextOptional



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

$ git pull https://github.com/afs/jena next-optional

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

https://github.com/apache/jena/pull/323.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 #323


commit 1a8e270fc48b5b5b3eefe24314fb75174723ab43
Author: Andy Seaborne 
Date:   2017-11-30T10:46:41Z

JENA-1427: ExtendedIterator.nextOptional




> Add nextOrElse() method in ExtendedIterator
> ---
>
> Key: JENA-1427
> URL: https://issues.apache.org/jira/browse/JENA-1427
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.5.0
>Reporter: Adam Jacobs
>Priority: Trivial
>  Labels: easytask
>
> Allow a functional approach for returning a default value or throwing a 
> custom exception from a Jena iterator.
> The following method may be added to the ExtendedIterator interface.
> {noformat}
> /**
>  Answer the next object, if it exists, otherwise invoke the 
> _supplier_.
>  */
> public default T nextOrElse( Supplier supplier ) {
> return hasNext() ? next() : supplier.get();
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] jena pull request #323: JENA-1427: ExtendedIterator.nextOptional

[afs]

GitHub user afs opened a pull request:

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

JENA-1427: ExtendedIterator.nextOptional



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

$ git pull https://github.com/afs/jena next-optional

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

https://github.com/apache/jena/pull/323.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 #323


commit 1a8e270fc48b5b5b3eefe24314fb75174723ab43
Author: Andy Seaborne 
Date:   2017-11-30T10:46:41Z

JENA-1427: ExtendedIterator.nextOptional




---

[jira] [Commented] (JENA-1426) jena-text documentation corrections and clarifications

[Andy Seaborne (JIRA)]

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

Andy Seaborne commented on JENA-1426:
-

See thread on dev@, which has this as CMS changes.

https://lists.apache.org/thread.html/708639f761d1ec5ee5dc95c4abdd78d93c28d5c177a13196db30d162@%3Cdev.jena.apache.org%3E


> jena-text documentation corrections and clarifications
> --
>
> Key: JENA-1426
> URL: https://issues.apache.org/jira/browse/JENA-1426
> Project: Apache Jena
>  Issue Type: Documentation
>  Components: Jena
>Affects Versions: Jena 3.5.0
>Reporter: Code Ferret
>Priority: Minor
>  Labels: documentation
> Attachments: text-query.mdtext.zip
>
>
> Upon reviewing [JENA-1388|https://issues.apache.org/jira/browse/JENA-1388], I 
> realized that the updates to the 
> [jena-text|https://jena.apache.org/documentation/query/text-query.html] 
> documentation that I prepared for 
> [JENA-1326|https://issues.apache.org/jira/browse/JENA-1326] were rather 
> incomplete and in one case incorrect. I'm opening this issue so that updated 
> documentation can be attached.
> The attached update to text-query.mdtext attempts to clarify how to use the 
> jena-text integration of Lucene as well as to demonstrate that there is no 
> loss of functionality of the integration versus direct Lucene queries, which 
> should obviate any need for extensions of the sort contemplated in 
> [JENA-1388|https://issues.apache.org/jira/browse/JENA-1388].



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JENA-1438) rdf:langString argument to text:query silently ignored

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1438:
--

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

https://github.com/apache/jena/pull/320#discussion_r154031380
  
--- Diff: 
jena-text/src/main/java/org/apache/jena/query/text/TextQueryPF.java ---
@@ -295,6 +295,14 @@ private String chooseGraphURI(ExecutionContext 
execCxt) {
 return results;
 }
 
+private boolean noLang(String lang) {
+return (lang == null || lang.isEmpty() || " ".equals(lang));
--- End diff --

Other than this issue (" " for lang tag), the rest looks good.


> rdf:langString argument to text:query silently ignored
> --
>
> Key: JENA-1438
> URL: https://issues.apache.org/jira/browse/JENA-1438
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Jena
>Affects Versions: Jena 3.5.0
> Environment: N/A
>Reporter: Code Ferret
>Priority: Minor
>
> Queries of the form:
> {{?s text:query "some string"@lang-code}}
> return no results even when there are matches found by the _equivalent_:
> {{?s text:query ("some string" "lang:lang-code")}}
> {quote}
> Note the above _equivalent_ form is currently valid only if 
> {{text:multilingualSupport false}}.
> {quote} See [JENA-1437|https://issues.apache.org/jira/browse/JENA-1437]
> A reasonable fix is to recognize the {{rdf:langString}} case and treat it as 
> the _equivalent_ form referring to the {{text:defautlField}}; otherwise, at 
> least an error should be indicated.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] jena pull request #320: JENA-1438 rdf:langString args

[afs]

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

https://github.com/apache/jena/pull/320#discussion_r154031380
  
--- Diff: 
jena-text/src/main/java/org/apache/jena/query/text/TextQueryPF.java ---
@@ -295,6 +295,14 @@ private String chooseGraphURI(ExecutionContext 
execCxt) {
 return results;
 }
 
+private boolean noLang(String lang) {
+return (lang == null || lang.isEmpty() || " ".equals(lang));
--- End diff --

Other than this issue (" " for lang tag), the rest looks good.


---

[jira] [Commented] (JENA-1438) rdf:langString argument to text:query silently ignored

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1438:
--

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

https://github.com/apache/jena/pull/320#discussion_r154028330
  
--- Diff: 
jena-text/src/main/java/org/apache/jena/query/text/TextQueryPF.java ---
@@ -295,6 +295,14 @@ private String chooseGraphURI(ExecutionContext 
execCxt) {
 return results;
 }
 
+private boolean noLang(String lang) {
+return (lang == null || lang.isEmpty() || " ".equals(lang));
--- End diff --

Yes - no lang tag is a return of empty string.  If you get ``, there 
is a bug somewhere.


> rdf:langString argument to text:query silently ignored
> --
>
> Key: JENA-1438
> URL: https://issues.apache.org/jira/browse/JENA-1438
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Jena
>Affects Versions: Jena 3.5.0
> Environment: N/A
>Reporter: Code Ferret
>Priority: Minor
>
> Queries of the form:
> {{?s text:query "some string"@lang-code}}
> return no results even when there are matches found by the _equivalent_:
> {{?s text:query ("some string" "lang:lang-code")}}
> {quote}
> Note the above _equivalent_ form is currently valid only if 
> {{text:multilingualSupport false}}.
> {quote} See [JENA-1437|https://issues.apache.org/jira/browse/JENA-1437]
> A reasonable fix is to recognize the {{rdf:langString}} case and treat it as 
> the _equivalent_ form referring to the {{text:defautlField}}; otherwise, at 
> least an error should be indicated.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] jena pull request #320: JENA-1438 rdf:langString args

[afs]

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

https://github.com/apache/jena/pull/320#discussion_r154028330
  
--- Diff: 
jena-text/src/main/java/org/apache/jena/query/text/TextQueryPF.java ---
@@ -295,6 +295,14 @@ private String chooseGraphURI(ExecutionContext 
execCxt) {
 return results;
 }
 
+private boolean noLang(String lang) {
+return (lang == null || lang.isEmpty() || " ".equals(lang));
--- End diff --

Yes - no lang tag is a return of empty string.  If you get ``, there 
is a bug somewhere.


---

[jira] [Commented] (JENA-1441) jena-text tracing for development

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1441:
--

Github user afs commented on the issue:

https://github.com/apache/jena/pull/318
  
FYI: On a PR branch, you can do all sorts of git stuff on your local repo 
like reset to remove a commit, rebasing, and squashing.  Then do a force push 
to your PR branch at GH and it will all appear here with the updated state. GH 
even tracks revisions and hides comments no longer relevant.  (Use all this 
with care!)


> jena-text tracing for development
> -
>
> Key: JENA-1441
> URL: https://issues.apache.org/jira/browse/JENA-1441
> Project: Apache Jena
>  Issue Type: New Feature
>  Components: Jena
>Affects Versions: Jena 3.6.0
>Reporter: Code Ferret
>Priority: Trivial
>
> This issue is for the addition of some log4j tracing and a configuration item 
> associated with development in  jena-text. The tracing is in TextQueryPF and 
> TextIndexLucene to track calls to exec and the subsequent processing as well 
> as the add, update and delete of Lucene documents.
> The _trace-level_ is used so as to not interfere with the current 
> _debug-level_ items that are familiar  to developers.
> The configuration item {{text:cacheQueries false ;}} on 
> {{text:TextIndexLucene}} allows to bypass use of the {{queryCache}} in 
> TextQueryPF.query(...) during development. This configuration item is not for 
> general use and need not be documented further.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] jena issue #318: JENA-1441 jena-text tracing for development

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/318
  
FYI: On a PR branch, you can do all sorts of git stuff on your local repo 
like reset to remove a commit, rebasing, and squashing.  Then do a force push 
to your PR branch at GH and it will all appear here with the updated state. GH 
even tracks revisions and hides comments no longer relevant.  (Use all this 
with care!)


---