[jira] [Updated] (JENA-1276) "loading remote context failed" reading JSON-LD

2017-01-11 Thread JIRA 

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

François-Paul Servant updated JENA-1276:

Description: 
getting org.apache.jena.riot.RiotException: loading remote context failed: 
http://schema.org/ reading json-ld with an @context set to schema.org

see https://github.com/apache/jena/pull/203

the exception occurs here:
com.github.jsonldjava.core.DocumentLoader.loadDocument(String) line 29

where I get:
org.apache.http.ConnectionClosedException: Premature end of Content-Length 
delimited message body (expected: 124346; received: 0

public class TestJsonLDReader {
@Test public final void simpleReadTest() {
try {
String jsonld = someSchemaDorOrgJsonld();
Model m = ModelFactory.createDefaultModel();
try (StringReader reader = new StringReader(jsonld)) {
m.read(reader, null, "JSON-LD");  
}
assertJohnDoeIsOK(m);
} catch (RiotException e) {
// org.apache.jena.riot.RiotException: loading remote context 
failed: http://schema.org/
e.printStackTrace();
}
}

/** Example data */
private String someSchemaDorOrgJsonld() {
return "{\"@id\":\"_:b0\",\"@type\":\"Person\",\"name\":\"John 
Doe\",\"@context\":\"http://schema.org/\"};;
}

/** Checking that the data loaded from someSchemaDorOrgJsonld into a model, 
is OK */
private void assertJohnDoeIsOK(Model m) {
assertTrue(m.contains(null, RDF.type, 
m.createResource("http://schema.org/Person;)));
assertTrue(m.contains(null, m.createProperty("http://schema.org/name;), 
"John Doe"));   
}
}


  was:
getting org.apache.jena.riot.RiotException: loading remote context failed: 
http://schema.org/ reading json-ld with an @context set to schema.org

see https://github.com/apache/jena/pull/203

public class TestJsonLDReader {
@Test public final void simpleReadTest() {
try {
String jsonld = someSchemaDorOrgJsonld();
Model m = ModelFactory.createDefaultModel();
try (StringReader reader = new StringReader(jsonld)) {
m.read(reader, null, "JSON-LD");  
}
assertJohnDoeIsOK(m);
} catch (RiotException e) {
// org.apache.jena.riot.RiotException: loading remote context 
failed: http://schema.org/
e.printStackTrace();
}
}

/** Example data */
private String someSchemaDorOrgJsonld() {
return "{\"@id\":\"_:b0\",\"@type\":\"Person\",\"name\":\"John 
Doe\",\"@context\":\"http://schema.org/\"};;
}

/** Checking that the data loaded from someSchemaDorOrgJsonld into a model, 
is OK */
private void assertJohnDoeIsOK(Model m) {
assertTrue(m.contains(null, RDF.type, 
m.createResource("http://schema.org/Person;)));
assertTrue(m.contains(null, m.createProperty("http://schema.org/name;), 
"John Doe"));   
}
}



> "loading remote context failed" reading JSON-LD
> ---
>
> Key: JENA-1276
> URL: https://issues.apache.org/jira/browse/JENA-1276
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.1.1
> Environment: mac osx 10.11, eclipse mars
>Reporter: François-Paul Servant
>
> getting org.apache.jena.riot.RiotException: loading remote context failed: 
> http://schema.org/ reading json-ld with an @context set to schema.org
> see https://github.com/apache/jena/pull/203
> the exception occurs here:
> com.github.jsonldjava.core.DocumentLoader.loadDocument(String) line 29
> where I get:
> org.apache.http.ConnectionClosedException: Premature end of Content-Length 
> delimited message body (expected: 124346; received: 0
> public class TestJsonLDReader {
> @Test public final void simpleReadTest() {
> try {
> String jsonld = someSchemaDorOrgJsonld();
> Model m = ModelFactory.createDefaultModel();
> try (StringReader reader = new StringReader(jsonld)) {
> m.read(reader, null, "JSON-LD");  
> }
> assertJohnDoeIsOK(m);
> } catch (RiotException e) {
> // org.apache.jena.riot.RiotException: loading remote context 
> failed: http://schema.org/
> e.printStackTrace();
> }
> }
> /** Example data */
> private String someSchemaDorOrgJsonld() {
> return "{\"@id\":\"_:b0\",\"@type\":\"Person\",\"name\":\"John 
> Doe\",\"@context\":\"http://schema.org/\"};;
> }
> /** Checking that the data loaded from someSchemaDorOrgJsonld into a 
> model, is OK */
> private void assertJohnDoeIsOK(Model m) {
> assertTrue(m.contains(null, RDF.type, 
> m.createResource("http://schema.org/Person;)));
>

[jira] [Created] (JENA-1276) "loading remote context failed" reading JSON-LD

2017-01-11 Thread JIRA 
François-Paul Servant created JENA-1276:
---

 Summary: "loading remote context failed" reading JSON-LD
 Key: JENA-1276
 URL: https://issues.apache.org/jira/browse/JENA-1276
 Project: Apache Jena
  Issue Type: Bug
  Components: ARQ
Affects Versions: Jena 3.1.1
 Environment: mac osx 10.11, eclipse mars
Reporter: François-Paul Servant


getting org.apache.jena.riot.RiotException: loading remote context failed: 
http://schema.org/ reading json-ld with an @context set to schema.org

see https://github.com/apache/jena/pull/203

public class TestJsonLDReader {
@Test public final void simpleReadTest() {
try {
String jsonld = someSchemaDorOrgJsonld();
Model m = ModelFactory.createDefaultModel();
try (StringReader reader = new StringReader(jsonld)) {
m.read(reader, null, "JSON-LD");  
}
assertJohnDoeIsOK(m);
} catch (RiotException e) {
// org.apache.jena.riot.RiotException: loading remote context 
failed: http://schema.org/
e.printStackTrace();
}
}

/** Example data */
private String someSchemaDorOrgJsonld() {
return "{\"@id\":\"_:b0\",\"@type\":\"Person\",\"name\":\"John 
Doe\",\"@context\":\"http://schema.org/\"};;
}

/** Checking that the data loaded from someSchemaDorOrgJsonld into a model, 
is OK */
private void assertJohnDoeIsOK(Model m) {
assertTrue(m.contains(null, RDF.type, 
m.createResource("http://schema.org/Person;)));
assertTrue(m.contains(null, m.createProperty("http://schema.org/name;), 
"John Doe"));   
}
}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena issue #203: JsonLDReader: possibility to override the @context

2017-01-11 Thread fpservant 
Github user fpservant commented on the issue:

https://github.com/apache/jena/pull/203
  
Hi,

there are very different points in the discussion, all around one test that 
attempts to connect to an external resource.

1) It must first be noted that the test in question actually doesn't have 
anything to do with the functionality that the PR proposes. It can as well be 
removed, and that wouldn't change anything about the object of the PR (the 
functionality that it proposes to add), nor about the completeness of the 
testing of that functionality.

If you want, I can remove it.

2) this test attempts to parse some JSON-LD whose @context contains the URI 
of schema.org - probably the most obvious use-case for reading JSON-LD

- BTW, I didn't see any test about reading JSON-LD. Are there any?

 - If this test cannot connect to schema.org because there are no 
external connection, (or for whatever reason) the test won't fail, because the 
RiotException is catched. Just one line is written to the console (and it is 
not by the test itself, but by the code that it calls). So this test with this 
external connection doesn't really cause trouble to the integration process 
(maybe a few seconds delay - the time for the HTTP client to stop trying to 
connect)

 - it shows me that I'm not able to read such JSON-LD on my machine (I 
get on the console: ```org.apache.jena.riot.RiotException: loading remote 
context failed: http://schema.org/```) - this, in a setting where it should 
work (standard jena 3.1.1, run from eclipse where I can connect to external 
resources from java, for instance using jersey client)

So: as far as I can tell (thanks to this test), current jena has a problem 
reading JSON-LD with @context set to a URI (at least, I have such a problem 
using current jena)

- it is probably possible to write a test that simulates connecting to an 
external resource without connecting to it (cf. "cache" mechanism in JSON-LD 
java), but
- such a test would probably not detect a problem such as the one we 
seem to have here
- it's out of the scope of current PR 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-1230) Proxy authentication via NTLM does not work

2017-01-11 Thread A. Soroka (JIRA) 

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

A. Soroka commented on JENA-1230:
-

[~sperber], where did you get the type 
{{com.sun.security.auth.module.NTSystem}}? Thanks!

> Proxy authentication via NTLM does not work
> ---
>
> Key: JENA-1230
> URL: https://issues.apache.org/jira/browse/JENA-1230
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Reporter: Michael Sperber
>Assignee: A. Soroka
> Attachments: NTLMProxyAuthenticator.scala
>
>
> Here:
> http://stackoverflow.com/questions/22461562/jena-proxy-authentication
> ... someones is trying to make Jena work with a proxy that requires NTLM 
> authentication.
> As a result,
> https://issues.apache.org/jira/browse/JENA-658
> was created, which resulted in SimpleNTAuthenticator.
> However, that does work for proxy authentication, as the authenticator is 
> scoped to the target host, not the proxy.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (JENA-1230) Proxy authentication via NTLM does not work

2017-01-11 Thread A. Soroka (JIRA) 

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

A. Soroka reassigned JENA-1230:
---

Assignee: A. Soroka

> Proxy authentication via NTLM does not work
> ---
>
> Key: JENA-1230
> URL: https://issues.apache.org/jira/browse/JENA-1230
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Reporter: Michael Sperber
>Assignee: A. Soroka
> Attachments: NTLMProxyAuthenticator.scala
>
>
> Here:
> http://stackoverflow.com/questions/22461562/jena-proxy-authentication
> ... someones is trying to make Jena work with a proxy that requires NTLM 
> authentication.
> As a result,
> https://issues.apache.org/jira/browse/JENA-658
> was created, which resulted in SimpleNTAuthenticator.
> However, that does work for proxy authentication, as the authenticator is 
> scoped to the target host, not the proxy.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena issue #202: Formatting rampage

2017-01-11 Thread ajs6f 
Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/202
  
Fixed (reverted)  the additional autogen files.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [GitHub] jena issue #204: One writable graph per thread/transaction dataset

2017-01-11 Thread A. Soroka 
Sure, that would be natural. Let me put the question this way: is a per-graph 
arrangement of this kind interesting to anyone who isn't interested in LDP? 

The other direction here is forward with respect to locking. Claude and others 
(including me) have thrown around ideas on the list about how we could 
introduce more finely-grained locking for datasets, and I definitely think of 
this as a first tiny baby step in that direction.

---
A. Soroka
The University of Virginia Library

> On Jan 11, 2017, at 2:58 PM, Claude Warren  wrote:
> 
> perhaps in extras?
> 
> On Wed, Jan 11, 2017 at 7:39 PM, ajs6f  wrote:
> 
>> Github user ajs6f commented on the issue:
>> 
>>https://github.com/apache/jena/pull/204
>> 
>>`pergraph`: Just thought that `core` was getting awfully crowded. I
>> don't care one way or the other-- happy to put them anywhere.
>> 
>>`jena-ldp`: One of the questions I'm trying to raise with this PR is
>> exactly that-- is this useful only for LDP-type workloads (in which case
>> maybe it belongs outside ARQ entirely) or not (in which case it has more
>> claim to be in ARQ)?
>> 
>> 
>> ---
>> If your project is set up for it, you can reply to this email and have your
>> reply appear on GitHub as well. If your project does not have this feature
>> enabled and wishes so, or if the feature is enabled but not working, please
>> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
>> with INFRA.
>> ---
>> 
> 
> 
> 
> -- 
> I like: Like Like - The likeliest place on the web
> 
> LinkedIn: http://www.linkedin.com/in/claudewarren

Re: [GitHub] jena issue #204: One writable graph per thread/transaction dataset

2017-01-11 Thread Claude Warren 
perhaps in extras?

On Wed, Jan 11, 2017 at 7:39 PM, ajs6f  wrote:

> Github user ajs6f commented on the issue:
>
> https://github.com/apache/jena/pull/204
>
> `pergraph`: Just thought that `core` was getting awfully crowded. I
> don't care one way or the other-- happy to put them anywhere.
>
> `jena-ldp`: One of the questions I'm trying to raise with this PR is
> exactly that-- is this useful only for LDP-type workloads (in which case
> maybe it belongs outside ARQ entirely) or not (in which case it has more
> claim to be in ARQ)?
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>



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

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

[GitHub] jena issue #204: One writable graph per thread/transaction dataset

2017-01-11 Thread ajs6f 
Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/204
  
`pergraph`: Just thought that `core` was getting awfully crowded. I don't 
care one way or the other-- happy to put them anywhere.

`jena-ldp`: One of the questions I'm trying to raise with this PR is 
exactly that-- is this useful only for LDP-type workloads (in which case maybe 
it belongs outside ARQ entirely) or not (in which case it has more claim to be 
in ARQ)?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena issue #204: One writable graph per thread/transaction dataset

2017-01-11 Thread afs 
Github user afs commented on the issue:

https://github.com/apache/jena/pull/204
  
Immediate reaction: Why are the tests in "pergraph"?

If this is the beginning of "jena-ldp", do we want a package under src/main?




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena issue #202: Formatting rampage

2017-01-11 Thread afs 
Github user afs commented on the issue:

https://github.com/apache/jena/pull/202
  
Modified but is generated:
JSON_Parser, SPARQLParser10,  SPARQLParser11, SSE_ParserCore

OpVisitorBase is modified.

Various uses of "disjoint" have had the static import removed.

I have not checked:
testing_framework
jena-csv
jena-jdbc




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-1274) Support a writer-per-graph in-memory dataset

2017-01-11 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on JENA-1274:
--

GitHub user ajs6f opened a pull request:

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

One writable graph per thread/transaction dataset

A pass at:

https://issues.apache.org/jira/browse/JENA-1274

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

$ git pull https://github.com/apache/jena ThreadPerGraphDataset

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

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


commit eb252e96c51830eb3f786395c784f7020b82c0a6
Author: ajs6f 
Date:   2017-01-07T20:33:01Z

Trialing a per-graph writer dataset

commit 24bcf7940296b0535483d67f1fec93eb6592dbd0
Author: ajs6f 
Date:   2017-01-07T20:44:06Z

Adding correct license headers

commit ecdbd4c934dec40cb841b48ef6b1c67041ba7d99
Author: ajs6f 
Date:   2017-01-07T21:18:10Z

Integrate tests into ARQ test suite

commit c532719ce631abfa4f373a142d5c39a1207defc8
Author: ajs6f 
Date:   2017-01-07T21:24:08Z

Use constants in tests

commit 3ff7999b70dcada96e9f10033318dfea86773c2e
Author: ajs6f 
Date:   2017-01-07T21:42:13Z

Provide an assembler for WPG dataset

commit 64de6d3dfd7a71ac2d3183f3c8ef7c902c298670
Author: ajs6f 
Date:   2017-01-07T23:29:37Z

Parallelize assembler for WPG datasets

commit af7365565e4ea188e4d7bb9adb79698b110a7b00
Author: ajs6f 
Date:   2017-01-08T02:14:30Z

Cleaner layout for assembler

commit 38facad6a5db32e3758d417edd8a92d140fc7af8
Author: ajs6f 
Date:   2017-01-08T12:00:10Z

Correcting license headers

commit 29d5c64a284c1bbe2cc3ba1a67b7b59a3e0d2fd9
Author: ajs6f 
Date:   2017-01-08T14:22:47Z

Remove timeout

commit e309095cfb8a42e54289f5fbb7bd206beeccd213
Author: ajs6f 
Date:   2017-01-08T16:56:09Z

More tests, renaming central type more accurately

commit 78522e2d884a4b6e06228b5748825edec8e254cf
Author: ajs6f 
Date:   2017-01-08T18:09:30Z

More tests

commit f4b2b84e5071fa793131ee5c42b75cc4be85f27f
Author: ajs6f 
Date:   2017-01-08T19:02:37Z

Remove polling and extra flagging from tests, add read-committed isolation 
level test

commit aa703b908ce6e095b4e6c8138923547f780aa6a9
Author: ajs6f 
Date:   2017-01-11T16:42:34Z

Better wording in test message




> Support a writer-per-graph in-memory dataset
> 
>
> Key: JENA-1274
> URL: https://issues.apache.org/jira/browse/JENA-1274
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ, Jena
>Reporter: A. Soroka
>Assignee: A. Soroka
>Priority: Minor
>  Labels: ldp, multithreading, named_graphs
>
> Without too much work we could support a writer-per-graph in-memory dataset. 
> The target use case here is LDP-style interaction or other RESTful 
> architectures, where it is normal for updates to occur centered on one 
> resource.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena pull request #204: One writable graph per thread/transaction dataset

2017-01-11 Thread ajs6f 
GitHub user ajs6f opened a pull request:

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

One writable graph per thread/transaction dataset

A pass at:

https://issues.apache.org/jira/browse/JENA-1274

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

$ git pull https://github.com/apache/jena ThreadPerGraphDataset

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

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


commit eb252e96c51830eb3f786395c784f7020b82c0a6
Author: ajs6f 
Date:   2017-01-07T20:33:01Z

Trialing a per-graph writer dataset

commit 24bcf7940296b0535483d67f1fec93eb6592dbd0
Author: ajs6f 
Date:   2017-01-07T20:44:06Z

Adding correct license headers

commit ecdbd4c934dec40cb841b48ef6b1c67041ba7d99
Author: ajs6f 
Date:   2017-01-07T21:18:10Z

Integrate tests into ARQ test suite

commit c532719ce631abfa4f373a142d5c39a1207defc8
Author: ajs6f 
Date:   2017-01-07T21:24:08Z

Use constants in tests

commit 3ff7999b70dcada96e9f10033318dfea86773c2e
Author: ajs6f 
Date:   2017-01-07T21:42:13Z

Provide an assembler for WPG dataset

commit 64de6d3dfd7a71ac2d3183f3c8ef7c902c298670
Author: ajs6f 
Date:   2017-01-07T23:29:37Z

Parallelize assembler for WPG datasets

commit af7365565e4ea188e4d7bb9adb79698b110a7b00
Author: ajs6f 
Date:   2017-01-08T02:14:30Z

Cleaner layout for assembler

commit 38facad6a5db32e3758d417edd8a92d140fc7af8
Author: ajs6f 
Date:   2017-01-08T12:00:10Z

Correcting license headers

commit 29d5c64a284c1bbe2cc3ba1a67b7b59a3e0d2fd9
Author: ajs6f 
Date:   2017-01-08T14:22:47Z

Remove timeout

commit e309095cfb8a42e54289f5fbb7bd206beeccd213
Author: ajs6f 
Date:   2017-01-08T16:56:09Z

More tests, renaming central type more accurately

commit 78522e2d884a4b6e06228b5748825edec8e254cf
Author: ajs6f 
Date:   2017-01-08T18:09:30Z

More tests

commit f4b2b84e5071fa793131ee5c42b75cc4be85f27f
Author: ajs6f 
Date:   2017-01-08T19:02:37Z

Remove polling and extra flagging from tests, add read-committed isolation 
level test

commit aa703b908ce6e095b4e6c8138923547f780aa6a9
Author: ajs6f 
Date:   2017-01-11T16:42:34Z

Better wording in test message




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena pull request #202: Formatting rampage

2017-01-11 Thread ajs6f 
Github user ajs6f commented on a diff in the pull request:

https://github.com/apache/jena/pull/202#discussion_r95613311
  
--- Diff: 
jena-base/src/main/java/org/apache/jena/atlas/lib/CollectionUtils.java ---
@@ -22,12 +22,7 @@
 
 public class CollectionUtils
 {   
-public static  boolean disjoint(Collection c1, Collection c2)
-{
-   return c1.stream().noneMatch(c2::contains);
-}
-
-/** Test for same elements, regarless of cardinality */ 
+/** Test for same elements, regardless of cardinality */ 
 public static  boolean sameElts(Collection left, Collection 
right) {
--- End diff --

Ah, got it-- okay, I will pull out the changes to the `OpVisitor` type and 
then I think we are good?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena pull request #202: Formatting rampage

2017-01-11 Thread afs 
Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/202#discussion_r95606345
  
--- Diff: 
jena-base/src/main/java/org/apache/jena/atlas/lib/CollectionUtils.java ---
@@ -22,12 +22,7 @@
 
 public class CollectionUtils
 {   
-public static  boolean disjoint(Collection c1, Collection c2)
-{
-   return c1.stream().noneMatch(c2::contains);
-}
-
-/** Test for same elements, regarless of cardinality */ 
+/** Test for same elements, regardless of cardinality */ 
 public static  boolean sameElts(Collection left, Collection 
right) {
--- End diff --

I was responding to the suggested of dropping it (in 8/Jan 15:33 GMT).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Listeners and remote Graphs.

2017-01-11 Thread Claude Warren 
To be honest, I was thinking that if the graph notification for the
cassandra graph needed to notify all the attached graph implementations of
changes I would use Kafka or other similar pluggable Queue to do the
notification.

Claude

On Wed, Jan 11, 2017 at 2:48 PM, A. Soroka  wrote:

> > Perhaps we should look at a design for distributed update notification?
>
> If this is something that seems interesting, it's worth noting that there
> is a bunch of work on which to rely for this kind of problem. For example,
> colleagues of mine have had success with Apache Kafka. No need for Jena to
> reinvent any wheels.
>
> ---
> A. Soroka
> The University of Virginia Library
>
> > On Jan 11, 2017, at 7:24 AM, Claude Warren  wrote:
> >
> > Cassandra does not support transactions.  However, I can see the use for
> a
> > bounding construct that indicates "all these triples were added/deleted."
> >
> > The original driver for the Cassandra implementation was that we needed
> one
> > for a use case at work.  However, Cassandra is generally about speed of
> > writes and scale. So expect that the Cassandra implementation will be
> > viewed as large scale.  This leads me to some concerns about hash joins
> but
> > that is a side issue to be addressed in the Op stuff for the Cassandra
> > implementation.
> >
> > Perhaps we should look at a design for distributed update notification?
> >
> > Claude
> >
> > On Wed, Jan 11, 2017 at 11:53 AM, Andy Seaborne  wrote:
> >
> >> Hi Claude,
> >>
> >> On 09/01/17 19:22, Claude Warren wrote:
> >>
> >>> Greetings,
> >>>
> >>> Given that  the Cassandra server can host multiple client and  those
> >>> clients can open the same graph on the server simultaneously.
> Basically
> >>> two updatable synchronized views on one data set.
> >>>
> >>> Assume graph A is opened on client X and client Y and applications at X
> >>> and
> >>> Y both register listeners on the graph.
> >>>
> >>> If application at X deletes a triple should the listener at Y be
> notified?
> >>>
> >>> I have been thinking about adding a queue based (JMS 1.1?) listener
> >>> implementation so that distributed system would be notified of changes
> >>> from
> >>> remote systems.
> >>>
> >>
> >>
> >> The second question deals with reasoners.  If the reasoners are using
> the
> >>> distributed graph store then I don't think there is an issue so perhaps
> >>> this one goes away but.
> >>>
> >>> Reasoners do not like it  (don't respond to) data that is written into
> the
> >>> graph behind the scenes.  In a distributed environment does it make
> sense
> >>> to somehow utilize the graph listen messages (as noted above) to fire
> >>> update rules?
> >>>
> >>
> >> The current reasoners are written assuming changes happen via their API.
> >>
> >>
> >>> Are there other issues that I have missed?
> >>>
> >>
> >> The current event mechanism provides synchronous events - when the "add"
> >> has returned the event has been fired.
> >>
> >>
> >> The Cassandra graph is about scale?
> >>
> >> Per triple events are very fine grained - what if a million triples are
> >> added - will there be a million events?  And the whole update is sent to
> >> all listeners by JMS?
> >>
> >> 100 million triples?
> >>
> >>
> >> Where I'm going with Delta is that changes get recorded (RDF Patch) so
> >> that they can be applied elsewhere but also inspected. The granularity
> is
> >> different - the grain size is the transaction - a bunch of adds and
> deletes.
> >>
> >> So a different design is that an even on change at the end of
> transaction
> >> and that event is just notification something has happened and the event
> >> listeners can choose to inspect the inspect the change or not.
> >>
> >> I've also done where the patch drives sending an SPARQL Update to a
> remote
> >> copy - generally pure-push systems rather ones that pull the bulk
> changes
> >> because of issues like whether the client is ready to process the
> event, is
> >> actually running, there is a comms glitch or whether the client is
> actually
> >> interested in the content - they may, like the reasoners, be interested
> >> that a change has happened but their action is not simply on the
> content of
> >> just the change.
> >>
> >>Andy
> >>
> >
> >
> >
> > --
> > I like: Like Like - The likeliest place on the web
> > 
> > LinkedIn: http://www.linkedin.com/in/claudewarren
>
>


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

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

[GitHub] jena pull request #202: Formatting rampage

2017-01-11 Thread ajs6f 
Github user ajs6f commented on a diff in the pull request:

https://github.com/apache/jena/pull/202#discussion_r95585136
  
--- Diff: 
jena-base/src/main/java/org/apache/jena/atlas/lib/CollectionUtils.java ---
@@ -22,12 +22,7 @@
 
 public class CollectionUtils
 {   
-public static  boolean disjoint(Collection c1, Collection c2)
-{
-   return c1.stream().noneMatch(c2::contains);
-}
-
-/** Test for same elements, regarless of cardinality */ 
+/** Test for same elements, regardless of cardinality */ 
 public static  boolean sameElts(Collection left, Collection 
right) {
--- End diff --

It has been left. It is not deleted. (?!)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena pull request #202: Formatting rampage

2017-01-11 Thread ajs6f 
Github user ajs6f commented on a diff in the pull request:

https://github.com/apache/jena/pull/202#discussion_r95584988
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/algebra/OpVisitor.java ---
@@ -23,53 +23,53 @@
 public interface OpVisitor
 {
 // Op0
-public void visit(OpBGP opBGP) ;
-public void visit(OpQuadPattern quadPattern) ;
-public void visit(OpQuadBlock quadBlock) ;
-public void visit(OpTriple opTriple) ;
-public void visit(OpQuad opQuad) ;
-public void visit(OpPath opPath) ;
-public void visit(OpTable opTable) ;
-public void visit(OpNull opNull) ;
+default void visit(OpBGP opBGP) {}
--- End diff --

I figured the general implementation of `visit` is NOOP, but I will pull 
this out.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-1230) Proxy authentication via NTLM does not work

2017-01-11 Thread A. Soroka (JIRA) 

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

A. Soroka commented on JENA-1230:
-

Okay, I'll take a look at the Scala and put on my translating hat.

> Proxy authentication via NTLM does not work
> ---
>
> Key: JENA-1230
> URL: https://issues.apache.org/jira/browse/JENA-1230
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Reporter: Michael Sperber
> Attachments: NTLMProxyAuthenticator.scala
>
>
> Here:
> http://stackoverflow.com/questions/22461562/jena-proxy-authentication
> ... someones is trying to make Jena work with a proxy that requires NTLM 
> authentication.
> As a result,
> https://issues.apache.org/jira/browse/JENA-658
> was created, which resulted in SimpleNTAuthenticator.
> However, that does work for proxy authentication, as the authenticator is 
> scoped to the target host, not the proxy.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena issue #203: JsonLDReader: possibility to override the @context

2017-01-11 Thread ajs6f 
Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/203
  
@afs I think the point that @stain and I are making is that there is no 
need for an external resource linkage at all.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (JENA-1275) TransformScopeRename does the wrong thing with FILTER NOT EXISTS

2017-01-11 Thread Rob Vesse (JIRA) 
Rob Vesse created JENA-1275:
---

 Summary: TransformScopeRename does the wrong thing with FILTER NOT 
EXISTS
 Key: JENA-1275
 URL: https://issues.apache.org/jira/browse/JENA-1275
 Project: Apache Jena
  Issue Type: Bug
  Components: ARQ
Affects Versions: Jena 3.1.1
Reporter: Rob Vesse


I have produced the following minimal query from an originally much larger 
query. When the optimise is applied to this it incorrectly double renames the 
variables inside of the {{FILTER NOT EXISTS}} clause leading to incorrect 
algebra.

Query:

{noformat}
SELECT ?triangles ?openTriplets
  {
{
  #subQ2: calculate #open-triplets
  SELECT (COUNT(?x) as ?openTriplets)
  WHERE {
?x ?a ?y .
?y ?b ?z .
FILTER NOT EXISTS {?z ?c ?x}
  }
}
  }
{noformat}

Output:

{noformat}
(project (?triangles ?openTriplets)
  (project (?openTriplets)
(extend ((?openTriplets ?/.0))
  (group () ((?/.0 (count ?/x)))
(filter (notexists
   (quadpattern (quad  ?//z ?//c 
?//x)))
  (quadpattern
(quad  ?/x ?/a ?/y)
(quad  ?/y ?/b ?/z)
  ))
{noformat}

Note that we apply the quad transformation prior to applying the optimiser. 

Strangely enough I cannot reproduce the problem using pure Jena command line 
tools i.e. {{qparse}} although I note from the code that it applies quad 
transformation after applying optimisation. This suggests that it is a bug in 
how TransformScopeRename applies to quad form algebra.

I can reproduce it with a unit test like so:

{noformat}
@Test
public void filter_not_exists_scoping_03() {
//@formatter:off
Op orig = SSE.parseOp(StrUtils.strjoinNL("(project (?triangles 
?openTriplets)",
   "  (project (?openTriplets)",
   "(extend ((?openTriplets ?.0))",
   "  (group () ((?.0 (count ?x)))",
   "(filter (notexists",
   "   (quadpattern (quad 
 ?z ?c ?x)))",
   "  (quadpattern",
   "(quad 
 ?x ?a ?y)",
   "(quad 
 ?y ?b ?z)",
   "  ))"));
Op expected = SSE.parseOp(StrUtils.strjoinNL("(project (?triangles 
?openTriplets)",
"  (project (?openTriplets)",
"(extend ((?openTriplets ?/.0))",
"  (group () ((?/.0 (count ?/x)))",
"(filter (notexists",
"   (quadpattern (quad 
 ?/z ?/c ?/x)))",
"  (quadpattern",
"(quad  ?/x ?/a ?/y)",
"(quad  ?/y ?/b ?/z)",
"  ))"));
//@formatter:on

Op transformed = TransformScopeRename.transform(orig);

Assert.assertEquals(transformed, expected);
}

@Test
public void filter_not_exists_scoping_04() {
//@formatter:off
Op orig = SSE.parseOp(StrUtils.strjoinNL(
   "  (project (?openTriplets)",
   "(extend ((?openTriplets ?.0))",
   "  (group () ((?.0 (count ?x)))",
   "(filter (notexists",
   "   (quadpattern (quad 
 ?z ?c ?x)))",
   "  (quadpattern",
   "(quad 
 ?x ?a ?y)",
   "(quad 
 ?y ?b ?z)",
   "  )"));
Op expected = SSE.parseOp(StrUtils.strjoinNL(
"  (project (?openTriplets)",
"(extend ((?openTriplets ?.0))",
"  (group () ((?.0 (count ?x)))",
"(filter (notexists",
"   (quadpattern (quad 
 ?z ?c ?x)))",
"  (quadpattern",
"(quad  ?x ?a ?y)",
"(quad  ?y ?b ?z)",
"  )"));
//@formatter:on

Op transformed = TransformScopeRename.transform(orig);

Assert.assertEquals(transformed, expected);
}
{noformat}

The first test fails while the second passes. This implies that you need 2 
levels of projection to hit the bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Listeners and remote Graphs.

2017-01-11 Thread Claude Warren 
Cassandra does not support transactions.  However, I can see the use for a
bounding construct that indicates "all these triples were added/deleted."

The original driver for the Cassandra implementation was that we needed one
for a use case at work.  However, Cassandra is generally about speed of
writes and scale. So expect that the Cassandra implementation will be
viewed as large scale.  This leads me to some concerns about hash joins but
that is a side issue to be addressed in the Op stuff for the Cassandra
implementation.

Perhaps we should look at a design for distributed update notification?

Claude

On Wed, Jan 11, 2017 at 11:53 AM, Andy Seaborne  wrote:

> Hi Claude,
>
> On 09/01/17 19:22, Claude Warren wrote:
>
>> Greetings,
>>
>> Given that  the Cassandra server can host multiple client and  those
>> clients can open the same graph on the server simultaneously.  Basically
>> two updatable synchronized views on one data set.
>>
>> Assume graph A is opened on client X and client Y and applications at X
>> and
>> Y both register listeners on the graph.
>>
>> If application at X deletes a triple should the listener at Y be notified?
>>
>> I have been thinking about adding a queue based (JMS 1.1?) listener
>> implementation so that distributed system would be notified of changes
>> from
>> remote systems.
>>
>
>
> The second question deals with reasoners.  If the reasoners are using the
>> distributed graph store then I don't think there is an issue so perhaps
>> this one goes away but.
>>
>> Reasoners do not like it  (don't respond to) data that is written into the
>> graph behind the scenes.  In a distributed environment does it make sense
>> to somehow utilize the graph listen messages (as noted above) to fire
>> update rules?
>>
>
> The current reasoners are written assuming changes happen via their API.
>
>
>> Are there other issues that I have missed?
>>
>
> The current event mechanism provides synchronous events - when the "add"
> has returned the event has been fired.
>
>
> The Cassandra graph is about scale?
>
> Per triple events are very fine grained - what if a million triples are
> added - will there be a million events?  And the whole update is sent to
> all listeners by JMS?
>
> 100 million triples?
>
>
> Where I'm going with Delta is that changes get recorded (RDF Patch) so
> that they can be applied elsewhere but also inspected. The granularity is
> different - the grain size is the transaction - a bunch of adds and deletes.
>
> So a different design is that an even on change at the end of transaction
> and that event is just notification something has happened and the event
> listeners can choose to inspect the inspect the change or not.
>
> I've also done where the patch drives sending an SPARQL Update to a remote
> copy - generally pure-push systems rather ones that pull the bulk changes
> because of issues like whether the client is ready to process the event, is
> actually running, there is a comms glitch or whether the client is actually
> interested in the content - they may, like the reasoners, be interested
> that a change has happened but their action is not simply on the content of
> just the change.
>
> Andy
>



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

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

[jira] [Commented] (JENA-1230) Proxy authentication via NTLM does not work

2017-01-11 Thread Andy Seaborne (JIRA) 

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

Andy Seaborne commented on JENA-1230:
-

A java one would be good. (java because the majority of users are java 
programmers ... and scala programmers can read java).  Or both.

> Proxy authentication via NTLM does not work
> ---
>
> Key: JENA-1230
> URL: https://issues.apache.org/jira/browse/JENA-1230
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Reporter: Michael Sperber
> Attachments: NTLMProxyAuthenticator.scala
>
>
> Here:
> http://stackoverflow.com/questions/22461562/jena-proxy-authentication
> ... someones is trying to make Jena work with a proxy that requires NTLM 
> authentication.
> As a result,
> https://issues.apache.org/jira/browse/JENA-658
> was created, which resulted in SimpleNTAuthenticator.
> However, that does work for proxy authentication, as the authenticator is 
> scoped to the target host, not the proxy.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JENA-893) Elephas IO should split BZip2 inputs

2017-01-11 Thread Rob Vesse (JIRA) 

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

Rob Vesse updated JENA-893:
---
Assignee: (was: Rob Vesse)

> Elephas IO should split BZip2 inputs
> 
>
> Key: JENA-893
> URL: https://issues.apache.org/jira/browse/JENA-893
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Elephas
>Reporter: Rob Vesse
>
> As noted on the mailing lists currently Elephas does not split BZip2 inputs 
> even though BZip2 inputs are actually splittable
> Code exists within Hadoop core for splitting BZip2 inputs so it is mostly a 
> case of cribbing from that code and then expanding the test coverage to 
> ensure that we explicitly check splitting of BZip2 inputs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JENA-644) Jena Text documentation needs better examples

2017-01-11 Thread Rob Vesse (JIRA) 

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

Rob Vesse updated JENA-644:
---
Assignee: (was: Rob Vesse)

> Jena Text documentation needs better examples
> -
>
> Key: JENA-644
> URL: https://issues.apache.org/jira/browse/JENA-644
> Project: Apache Jena
>  Issue Type: Documentation
>  Components: Text
>Reporter: Rob Vesse
>Priority: Minor
>
> A question at 
> http://stackoverflow.com/questions/21858451/jenatext-working-example-for-querying-rdf-xml-files
>  highlights that the Jena Text documentation is somewhat lacking.
> There is no complete example of building and accessing a text index in code 
> (the current examples use placeholders instead of any real values).  Complete 
> examples in the documentation or code examples in the SVN repository would 
> likely be helpful for users



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JENA-648) Make TDB datasets harder to corrupt

2017-01-11 Thread Rob Vesse (JIRA) 

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

Rob Vesse updated JENA-648:
---
Assignee: (was: Rob Vesse)

> Make TDB datasets harder to corrupt
> ---
>
> Key: JENA-648
> URL: https://issues.apache.org/jira/browse/JENA-648
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: TDB
>Reporter: Rob Vesse
> Attachments: JENA-648-lock-files.patch
>
>
> This RFE comes out of discussions I had in person with Andy earlier this 
> week.  On the mailing lists and Q sites we see a steady stream of questions 
> from people who have corrupted TDB databases and it would be nice if we could 
> put in place features that make this harder to do.
> There are two main things we should do in the long term as I see it:
> # Make using TDB non-transactonally more difficult
> # Put in place some mechanism to make it difficult for multiple JVMs to 
> access the same TDB dataset simultaneously
> Me and Andy think the first could be achieved by making TDB datasets 
> operation in auto-commit more rather than non-transactional mode by default.  
> In order to allow this we likely need upgradeable read transactions to be 
> supported.  As part of this change non-transactional mode would still be 
> supported but users would have to explicitly set some "Here be Dragons" style 
> flag in order to do this.  Users who aren't using transactions currently 
> would likely merely see performance drop since suddenly they are getting 
> auto-commits on every operation but when they complain we can tell them they 
> should be using transactions properly to ensure their TDB databases remain 
> uncorrupted.
> As far as the second point goes we could likely do this the way a lot of 
> other applications do by having the code write a lock file to disk when a 
> database is opened which contains the owning processes PID.  Whenever you go 
> to open a database the presence of the lock file is checked for and if 
> present the PID validated with the code refusing to open the database if the 
> PIDs do not match.  There would likely need to be some code to cope with the 
> case where the lock file gets left around and the owning PID is not alive but 
> that shouldn't be too complicated.
> Since these may be considered as substantial behavioural changes to TDB these 
> may likely go into Jena 3



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Listeners and remote Graphs.

2017-01-11 Thread Andy Seaborne 

Hi Claude,

On 09/01/17 19:22, Claude Warren wrote:

Greetings,

Given that  the Cassandra server can host multiple client and  those
clients can open the same graph on the server simultaneously.  Basically
two updatable synchronized views on one data set.

Assume graph A is opened on client X and client Y and applications at X and
Y both register listeners on the graph.

If application at X deletes a triple should the listener at Y be notified?

I have been thinking about adding a queue based (JMS 1.1?) listener
implementation so that distributed system would be notified of changes from
remote systems.




The second question deals with reasoners.  If the reasoners are using the
distributed graph store then I don't think there is an issue so perhaps
this one goes away but.

Reasoners do not like it  (don't respond to) data that is written into the
graph behind the scenes.  In a distributed environment does it make sense
to somehow utilize the graph listen messages (as noted above) to fire
update rules?


The current reasoners are written assuming changes happen via their API.



Are there other issues that I have missed?


The current event mechanism provides synchronous events - when the "add" 
has returned the event has been fired.



The Cassandra graph is about scale?

Per triple events are very fine grained - what if a million triples are 
added - will there be a million events?  And the whole update is sent to 
all listeners by JMS?


100 million triples?


Where I'm going with Delta is that changes get recorded (RDF Patch) so 
that they can be applied elsewhere but also inspected. The granularity 
is different - the grain size is the transaction - a bunch of adds and 
deletes.


So a different design is that an even on change at the end of 
transaction and that event is just notification something has happened 
and the event listeners can choose to inspect the inspect the change or not.


I've also done where the patch drives sending an SPARQL Update to a 
remote copy - generally pure-push systems rather ones that pull the bulk 
changes because of issues like whether the client is ready to process 
the event, is actually running, there is a comms glitch or whether the 
client is actually interested in the content - they may, like the 
reasoners, be interested that a change has happened but their action is 
not simply on the content of just the change.


Andy

[GitHub] jena pull request #202: Formatting rampage

2017-01-11 Thread afs 
Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/202#discussion_r95558509
  
--- Diff: 
jena-base/src/main/java/org/apache/jena/atlas/lib/CollectionUtils.java ---
@@ -22,12 +22,7 @@
 
 public class CollectionUtils
 {   
-public static  boolean disjoint(Collection c1, Collection c2)
-{
-   return c1.stream().noneMatch(c2::contains);
-}
-
-/** Test for same elements, regarless of cardinality */ 
+/** Test for same elements, regardless of cardinality */ 
 public static  boolean sameElts(Collection left, Collection 
right) {
--- End diff --

Please leave.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena pull request #202: Formatting rampage

2017-01-11 Thread afs 
Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/202#discussion_r95557264
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/algebra/OpVisitor.java ---
@@ -23,53 +23,53 @@
 public interface OpVisitor
 {
 // Op0
-public void visit(OpBGP opBGP) ;
-public void visit(OpQuadPattern quadPattern) ;
-public void visit(OpQuadBlock quadBlock) ;
-public void visit(OpTriple opTriple) ;
-public void visit(OpQuad opQuad) ;
-public void visit(OpPath opPath) ;
-public void visit(OpTable opTable) ;
-public void visit(OpNull opNull) ;
+default void visit(OpBGP opBGP) {}
--- End diff --

I don't know about this change. 

There are `OpVisitor` impls that do not use `OpVisitorBase` and that has 
the desirable (and intended) effect that a change in `OpVisitor` forces 
implementation. e.g. `OpVisitorByType` e.g. `ExecutionDispatch`

Having default methods masks this so it makes things less robust. There is 
rarely a general implementation of an `visit` that will work for everything.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena issue #203: JsonLDReader: possibility to override the @context

2017-01-11 Thread afs 
Github user afs commented on the issue:

https://github.com/apache/jena/pull/203
  
External linkages in the tests is, in the long term, not good. At some 
point, the remote resource will be uncontactable. Sometimes people need to run 
the test offline as well. So for the long term robustness of the tests suite, I 
think the level of need for an external resource needs to be quite high. At 
least make the test respond to different errors - uncontactable vs a failure 
with the expected actions after the content is fetched. Even the latter is hard 
- the remote contents may change.

(this is what `StreamManager` is good for).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena issue #203: JsonLDReader: possibility to override the @context

2017-01-11 Thread stain 
Github user stain commented on the issue:

https://github.com/apache/jena/pull/203
  
For unit tests you can use a JAR-cached context by using the 
[jarcache.json](https://github.com/jsonld-java/jsonld-java#loading-contexts-from-classpathjar)
 approach and put it together with the JSON schema file in 
`src/test/resources/` - that would override the specified URL.

A similar approach can be used with `src/main/resources` - but then of 
course you would have to keep the schema cache up to date, so that's more for 
the end application to do to avoid external network dependencies.

Note that the actual [schema.org context 
file](http://schema.org/docs/jsonldcontext.json) is [licensed as CC BY 
SA](http://schema.org/docs/terms.html), but you could make a minimal version 
made just for the test which would not infringe copyright.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---