[jira] [Commented] (JENA-999) Poor jena-text query performance when a bound subject is used

[ASF subversion and git services (JIRA)]

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

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

Commit d6adcc17712a3b44cfe6d4264f75fb44ddcc7f67 in jena's branch 
refs/heads/master from [~sallen]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=d6adcc1 ]

JENA-999 - Fix performance of jena-text when subject variable is bound


> Poor jena-text query performance when a bound subject is used
> -
>
> Key: JENA-999
> URL: https://issues.apache.org/jira/browse/JENA-999
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Stephen Allen
>Assignee: Stephen Allen
>Priority: Minor
> Attachments: jena-text benchmarks.png
>
>
> When executing a jena-text query, the performance is terrible if the subject 
> is already bound to a variable.  This is because the current code will 
> execute a new lucene query that does not have the subject/entity bound on 
> every iteration and then iterate through the lucene results to join against 
> the subject.  This is quite inefficient.
> Example query:
> {code}
> select *
> where {
>   ?s rdf:type  .
>   ?s text:query ( rdfs:label "test" ) .
> }
> {code}
> This would be quite slow if there were a lot of entities in the system.
> Two potential solutions present themselves:
> # Craft a more explicit lucene query that specifies the entity URI, so that 
> the results coming back from lucene are much smaller.  However, this would 
> cause problems with the score not being correct across multiple iterations.  
> Additionally we are still potentially running a lot of lucene queries, each 
> of which has a probably non-negligble constant cost (parsing the query 
> string, etc).
> # Execute the more general lucene query the first time it is encountered, 
> then caching the results somewhere.  From there, we can then perform a hash 
> table lookup against those cached results.
> I would like to pursue option 2, but there is a problem.  Because jena-text 
> is implemented as a property function instead of a query op in and of itself 
> (like QueryIterMinus is for example), we have to find a place to stash the 
> lucene results.  I believe this can be done by placing it in the 
> ExecutionContext object, using the lucene query as a cache key.  Updates 
> provide a slightly troubling case because you could have an update request 
> like:
> {code}
> insert data {  rdf:type  ; rdfs:label 
> "test" } ;
> delete { ?s ?p ?o }
> where { ?s rdf:type  ; text:query ( rdfs:label 
> "test" ) . ?p ?o . } ;
> insert data {  rdf:type  ; rdfs:label 
> "test" } ;
> delete { ?s ?p ?o }
> where { ?s rdf:type  ; text:query ( rdfs:label 
> "test" ) ; ?p ?o . }
> {code}
> And then the end result should be an empty database.  But if the 
> ExecutionContext was the same for both delete queries, you would be using the 
> cached results from the first delete query in the second delete query, which 
> would result in {{}} not being deleted properly.
> If the ExecutionContext is indeed shared between the two update queries in 
> the situation above, I think this can be solved by making the cache key for 
> the lucene resultset be a combination of both the lucene query and the 
> QueryIterRoot or BindingRoot.  I need to investigate this.  An alternative, 
> if there was a way to be notified when a query has finished executing, we 
> could clear the cache in the ExecutionContext.



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

[jira] [Created] (JENA-1003) tdbloader2 reports df: `': No such file or directory

[Donald Pellegrino (JIRA)]

Donald Pellegrino created JENA-1003:
---

 Summary: tdbloader2 reports df: `': No such file or directory
 Key: JENA-1003
 URL: https://issues.apache.org/jira/browse/JENA-1003
 Project: Apache Jena
  Issue Type: Bug
  Components: Cmd line tools
Affects Versions: Jena 3.0.0
 Environment: CentOS release 6.3 (Final)
java -version
openjdk version "1.8.0_25"
OpenJDK Runtime Environment (build 1.8.0_25-b17)
OpenJDK 64-Bit Server VM (build 25.20-b23, mixed mode)
Reporter: Donald Pellegrino
Priority: Minor


A tdbloader2 run seems to throw some errors from the df command:

] tdbloader2 --loc pubchemdb 
/home/irkmoo/pubchem/RDF/compound/general/pc_compound_type.ttl.gz
 15:37:51 INFO -- TDB Bulk Loader Start
 15:37:51 INFO Data Load Phase
 15:37:51 INFO Got 1 data files to load
 15:37:51 INFO Data file 1: 
/home/irkmoo/pubchem/RDF/compound/general/pc_compound_type.ttl.gz
INFO  Load: /home/irkmoo/pubchem/RDF/compound/general/pc_compound_type.ttl.gz 
-- 2015/07/30 15:37:52 EDT
INFO  Add: 50,000 Data (Batch: 23,969 / Avg: 23,969)
INFO  Total: 76,778 tuples : 3.75 seconds : 20,452.32 tuples/sec [2015/07/30 
15:37:56 EDT]
 15:37:56 INFO Data Load Phase Completed
 15:37:56 INFO Index Building Phase
df: `': No such file or directory
df: no file systems processed
 15:37:56 ERROR Failed to get drive information for
 15:37:56 ERROR Failed during data phase




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

[GitHub] jena pull request: Richer Javadocs for Iter and ExtendedIterator

[ajs6f]

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

https://github.com/apache/jena/pull/90#discussion_r35871940
  
--- Diff: jena-base/src/main/java/org/apache/jena/atlas/iterator/Iter.java 
---
@@ -29,6 +29,14 @@
 import org.apache.jena.atlas.lib.Closeable ;
 import org.apache.jena.atlas.lib.Sink ;
 
+/**
+ * Iter provides utilities for working with {@link Iterator}s.
+ *
+ * Iter should never be used as a return type or parameter type in the 
public contract of a class. It is only to be used
+ * inside implementation code and is instantiated only to allow 
method-chaining as part of a calculation.
--- End diff --

This is exactly what I needed. Sorry to have bugged you so much about it, 
but I really think this deserves to be written down. I will correct this PR to 
advise just what you just did.

I am a little surprised that Jena's policy is that once a type is exposed, 
it can never be changed. That seems extraordinarily restrictive. But that's a 
completely different question.


---
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: Richer Javadocs for Iter and ExtendedIterator

[afs]

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

https://github.com/apache/jena/pull/90#discussion_r35871606
  
--- Diff: jena-base/src/main/java/org/apache/jena/atlas/iterator/Iter.java 
---
@@ -29,6 +29,14 @@
 import org.apache.jena.atlas.lib.Closeable ;
 import org.apache.jena.atlas.lib.Sink ;
 
+/**
+ * Iter provides utilities for working with {@link Iterator}s.
+ *
+ * Iter should never be used as a return type or parameter type in the 
public contract of a class. It is only to be used
+ * inside implementation code and is instantiated only to allow 
method-chaining as part of a calculation.
--- End diff --

IMO `Iter` is better than `ExtendedIterator` (more general, separated out) 
and should be used on general iterators. `ExtendedIterator` exists in jena-core 
and Graph API only and as a Triple iterator. 

As ExtendedIterator is exposed, it can't be changed. 

So if and where working on triple iterators out of Graph, use 
ExtendedIterator, else Iter.




---
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: Journaling DatasetGraph

[aj...@virginia.edu]

I think I understand the problem now. Assuming I do, I see two cases:

1) The underlying dataset has locking that is _more_ restrictive that MRSW, in 
which case DatasetGraphWithRecord must expose that locking, lest it break the 
underlying impl.

2) The underlying dataset has locking that is _less_ restrictive that MRSW, in 
which case DatasetGraphWithRecord must eclipse that locking, lest it break 
DatasetGraphWithRecord's impl.

So my task is to adopt some careful meaning for "more" and "less" as used above 
and use it to make DatasetGraphWithRecord's locking more intelligent. I do not 
see anything in Jena that would answer to the purpose, but maybe I am missing 
something. {fingers-crossed}

---
A. Soroka
The University of Virginia Library

On Jul 29, 2015, at 5:04 PM, Andy Seaborne  wrote:

> The lock provided by the underlying dataset may matter.  DatasetGraphs 
> support critical sections.  DatasetGraphWithLock uses critical sections of 
> the underlying dataset.
> 
> I gave an (hypothetical) example where the lock must be more restrictive than 
> ReentrantReadWriteLock (LockMRSW is a ReentrantReadWriteLock + counting 
> support to catch application errors).
> 
> DatasetGraphWithRecord is relying on single-W for its own datastructures.
> 
>   Andy
> 
> On 29/07/15 21:22, aj...@virginia.edu wrote:
>> I'm not sure I understand this advice-- are you saying that because no 
>> DatasetGraph can be assumed to support MR, there isn't any point in trying 
>> to support MR at the level of DatasetGraphWithRecord? That would seem to 
>> make my whole effort a bit pointless.
>> 
>> Or are you saying that because, in practice, all DatasetGraphs _do_ support 
>> MR, there's no need to enforce it at the level of DatasetGraphWithRecord?
>> 
>> ---
>> A. Soroka
>> The University of Virginia Library
>> 
>> On Jul 29, 2015, at 4:14 PM, Andy Seaborne  wrote:
>> 
>>> On 27/07/15 18:06, aj...@virginia.edu wrote:
> Is there some specific reason as to why you override the 
> DatasetGraphWithLock lock?
 Yes, because DatasetGraphWithLock has no Lock that I could find, and it 
 inherits getLock() from DatasetGraphTrackActive, which just pulls the lock 
 from the wrapped DatasetGraph. I wanted to make sure that a MRSW Lock is 
 in play. But maybe I am misunderstanding the interaction here? (No 
 surprise! {grin})
 
>>> 
>>> A DatasetGraph provides whatever lock is suitable to meet the contract of 
>>> concurrency [1]
>>> 
>>> Some implementations (there aren't any) may not even be able to support 
>>> true parallel readers (for example, datastructures that they may make 
>>> internal changes even in read operations like moving recently accessed 
>>> items to the top or caching computation needed for read).
>>> 
>>> There aren't any (the rules are R-safe) - locks are always LockMRSW.
>>> 
>>> [1] http://jena.apache.org/documentation/notes/concurrency-howto.html
>>> 
>>> Andy
>>> 
>> 
> 

[jira] [Commented] (JENA-491) Extend CONSTRUCT to build quads

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-491:
-

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

https://github.com/apache/jena/pull/89#discussion_r35870389
  
--- Diff: 
jena-arq/src-examples/arq/examples/constructquads/ExampleConstructQuads.java ---
@@ -0,0 +1,141 @@
+/*
+ * 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 arq.examples.constructquads;
+
+import java.util.Iterator;
+
+import org.apache.jena.graph.Triple;
+import org.apache.jena.query.Dataset;
+import org.apache.jena.query.DatasetFactory;
+import org.apache.jena.query.Query;
+import org.apache.jena.query.QueryExecution;
+import org.apache.jena.query.QueryExecutionFactory;
+import org.apache.jena.query.QueryFactory;
+import org.apache.jena.query.Syntax;
+import org.apache.jena.rdf.model.Model;
+import org.apache.jena.rdf.model.ModelFactory;
+import org.apache.jena.rdf.model.Property;
+import org.apache.jena.rdf.model.Resource;
+import org.apache.jena.sparql.core.Quad;
+import org.apache.jena.util.PrintUtil;
+
+public class ExampleConstructQuads {
+   public static void main(String[] args) {
+
+   // create testing data :
+   // 1) default graph data
+   Model model = ModelFactory.createDefaultModel();
+   Resource s = model.createResource("http://eg.com/s";);
+   Property p = model.createProperty("http://eg.com/p";);
+   Resource o = model.createResource("http://eg.com/o";);
+   model.add(s, p, o);
+   Dataset dataset = DatasetFactory.create(model);
+   // 2) named graph data
+   Model model1 = ModelFactory.createDefaultModel();
+   Resource s1 = model.createResource("http://eg.com/s1";);
+   Property p1 = model.createProperty("http://eg.com/p1";);
+   Resource o1 = model.createResource("http://eg.com/o1";);
+   model1.add(s1, p1, o1);
+   dataset.addNamedModel("", model1);
+
+
+   // construct named graph
+   System.out.println("construct named graph:");
+   String queryString = "CONSTRUCT { GRAPH ?g { 
 ?o} } WHERE{ GRAPH ?g {  
?o} }";
+   Query query = QueryFactory.create(queryString, 
Syntax.syntaxARQ);
+   QueryExecution qexec = QueryExecutionFactory.create(query, 
dataset);
--- End diff --

You may have them turned off. Check Preferences > Java > Compiler > 
Errors/Warnings. There is a serried host of settings there and amongst them, 
under Code Style, you will find `Resource not managed via try-with-resource 
(1.7 or higher)`. It's worth turning on. In any event, even without the 
warning, `try-with-resource` is the right thing to do.


> Extend CONSTRUCT to build quads
> ---
>
> Key: JENA-491
> URL: https://issues.apache.org/jira/browse/JENA-491
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ, Fuseki
>Reporter: Andy Seaborne
>  Labels: gsoc, gsoc2015, java, linked_data, rdf, sparql
>
> This would be an extension to SPARQL.
> 1/ Add use of GRAPH inside a CONSTRUCT template see SPARQL Update.
> 2/ Add conneg for quads to Fuseki.
> 3/ New QueryExecution operations execConstructQuads() and 
> execConstructDataset()
> If asked for triples, and the CONSTRUCT generates quads, the named graph 
> items are dropped - that is, only the default graph is returned.  This is for 
> commonality with RIOT.



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

[GitHub] jena pull request: Merge confidencesun/master (Merged from JENA-49...

[ajs6f]

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

https://github.com/apache/jena/pull/89#discussion_r35870389
  
--- Diff: 
jena-arq/src-examples/arq/examples/constructquads/ExampleConstructQuads.java ---
@@ -0,0 +1,141 @@
+/*
+ * 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 arq.examples.constructquads;
+
+import java.util.Iterator;
+
+import org.apache.jena.graph.Triple;
+import org.apache.jena.query.Dataset;
+import org.apache.jena.query.DatasetFactory;
+import org.apache.jena.query.Query;
+import org.apache.jena.query.QueryExecution;
+import org.apache.jena.query.QueryExecutionFactory;
+import org.apache.jena.query.QueryFactory;
+import org.apache.jena.query.Syntax;
+import org.apache.jena.rdf.model.Model;
+import org.apache.jena.rdf.model.ModelFactory;
+import org.apache.jena.rdf.model.Property;
+import org.apache.jena.rdf.model.Resource;
+import org.apache.jena.sparql.core.Quad;
+import org.apache.jena.util.PrintUtil;
+
+public class ExampleConstructQuads {
+   public static void main(String[] args) {
+
+   // create testing data :
+   // 1) default graph data
+   Model model = ModelFactory.createDefaultModel();
+   Resource s = model.createResource("http://eg.com/s";);
+   Property p = model.createProperty("http://eg.com/p";);
+   Resource o = model.createResource("http://eg.com/o";);
+   model.add(s, p, o);
+   Dataset dataset = DatasetFactory.create(model);
+   // 2) named graph data
+   Model model1 = ModelFactory.createDefaultModel();
+   Resource s1 = model.createResource("http://eg.com/s1";);
+   Property p1 = model.createProperty("http://eg.com/p1";);
+   Resource o1 = model.createResource("http://eg.com/o1";);
+   model1.add(s1, p1, o1);
+   dataset.addNamedModel("", model1);
+
+
+   // construct named graph
+   System.out.println("construct named graph:");
+   String queryString = "CONSTRUCT { GRAPH ?g { 
 ?o} } WHERE{ GRAPH ?g {  
?o} }";
+   Query query = QueryFactory.create(queryString, 
Syntax.syntaxARQ);
+   QueryExecution qexec = QueryExecutionFactory.create(query, 
dataset);
--- End diff --

You may have them turned off. Check Preferences > Java > Compiler > 
Errors/Warnings. There is a serried host of settings there and amongst them, 
under Code Style, you will find `Resource not managed via try-with-resource 
(1.7 or higher)`. It's worth turning on. In any event, even without the 
warning, `try-with-resource` is the right thing to do.


---
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-869) Fuseki2: Can't reuse dataset name after DELETE

[Andy Seaborne (JIRA)]

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

Andy Seaborne commented on JENA-869:


Now deletes the on-disk configuration.  This should mean the error (which is 
now 409) does not occur on reading it and also the dataset will not reappear on 
server restart.

 [~kinow] if you could give it a test when you have a moment I'd be most 
grateful.

> Fuseki2: Can't reuse dataset name after DELETE
> --
>
> Key: JENA-869
> URL: https://issues.apache.org/jira/browse/JENA-869
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Fuseki 2.0.0
>Reporter: Stian Soiland-Reyes (old)
>Assignee: Andy Seaborne
> Fix For: Fuseki 2.3.0
>
> Attachments: JENA-869_20150726200200.png
>
>
> In the web interface, I create a persistent dataset "test1". I then remove 
> it. I then create a second one called "test1". Everything works fine.
> However, if I restart Fuseki, now it attemps to register test1 twice:
> {code}
> [2015-01-28 12:47:33] ServletINFO  Initializing Shiro environment
> [2015-01-28 12:47:33] Config INFO  Shiro file: file:///fuseki/shiro.ini
> [2015-01-28 12:47:33] BuilderINFO  Service: TDB test1
> [2015-01-28 12:47:34] BuilderINFO  Service: TDB test1
> [2015-01-28 12:47:34] BuilderINFO  Service: :service1
> [2015-01-28 12:47:34] BuilderINFO  Service: TDB test3
> [2015-01-28 12:47:34] Config INFO  Register: /test1
> [2015-01-28 12:47:34] Config INFO  Register: /test1
> [2015-01-28 12:47:34] Server ERROR Exception in initialization: Already 
> registered: /test1
> [2015-01-28 12:47:34] WebAppContext WARN  Failed startup of context 
> o.e.j.w.WebAppContext@d04ca48{/,file:/jena-fuseki/webapp/,STARTING}
> org.apache.jena.fuseki.FusekiException: Already registered: /test1
>   at 
> org.apache.jena.fuseki.server.DataAccessPointRegistry.register(DataAccessPointRegistry.java:28)
>   at 
> org.apache.jena.fuseki.server.FusekiServer.enable(FusekiServer.java:232)
>   at 
> org.apache.jena.fuseki.server.FusekiServer.initializeDataAccessPoints(FusekiServer.java:226)
>   at 
> org.apache.jena.fuseki.server.FusekiServerListener.init(FusekiServerListener.java:70)
>   at 
> org.apache.jena.fuseki.server.FusekiServerListener.contextInitialized(FusekiServerListener.java:45)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:799)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:446)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:791)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:296)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1347)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:743)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:492)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:117)
>   at org.eclipse.jetty.server.Server.start(Server.java:355)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:99)
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:60)
>   at org.eclipse.jetty.server.Server.doStart(Server.java:324)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
>   at org.apache.jena.fuseki.jetty.JettyFuseki.start(JettyFuseki.java:137)
>   at 
> org.apache.jena.fuseki.cmd.FusekiCmd$FusekiCmdInner.exec(FusekiCmd.java:331)
>   at arq.cmdline.CmdMain.mainMethod(CmdMain.java:102)
>   at arq.cmdline.CmdMain.mainRun(CmdMain.java:63)
>   at arq.cmdline.CmdMain.mainRun(CmdMain.java:50)
>   at 
> org.apache.jena.fuseki.cmd.FusekiCmd$FusekiCmdInner.innerMain(FusekiCmd.java:97)
>   at org.apache.jena.fuseki.cmd.FusekiCmd.main(FusekiCmd.java:60)
> {code}
> In the HTTP log from before:
> {code}
> [2015-01-28 12:47:02] Admin  INFO  [1] GET http://localhost:3031/$/server
> [2015-01-28 12:47:02] Admin  INFO  [1] 200 OK (11 ms) 
> [2015-01-28 12:47:04] Admin  INFO  [2] GET http://localhost:3031/$/server
> [2015-01-28 12:47:04] Admin  INFO  [2] 200 OK (1 ms) 
> [2015-01-28 12:47:08] Admin  INFO  [3] POST 
> http://localhost:3031/$/datasets
> [2015-01-28 12:47:08] Admin  INFO  [3] Create database : name = /test1
> [2015-01-28 12:47:08] BuilderINFO  Service: TDB test1
> [2015-01-28 12:47

[jira] [Commented] (JENA-869) Fuseki2: Can't reuse dataset name after DELETE

[ASF subversion and git services (JIRA)]

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

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

Commit eafedda9ea48efcba6eb6b7ff47996d0ac61de0a in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=eafedda ]

JENA-869 : Delete configuration file when deleting dataset service.

> Fuseki2: Can't reuse dataset name after DELETE
> --
>
> Key: JENA-869
> URL: https://issues.apache.org/jira/browse/JENA-869
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Fuseki 2.0.0
>Reporter: Stian Soiland-Reyes (old)
>Assignee: Andy Seaborne
> Fix For: Fuseki 2.3.0
>
> Attachments: JENA-869_20150726200200.png
>
>
> In the web interface, I create a persistent dataset "test1". I then remove 
> it. I then create a second one called "test1". Everything works fine.
> However, if I restart Fuseki, now it attemps to register test1 twice:
> {code}
> [2015-01-28 12:47:33] ServletINFO  Initializing Shiro environment
> [2015-01-28 12:47:33] Config INFO  Shiro file: file:///fuseki/shiro.ini
> [2015-01-28 12:47:33] BuilderINFO  Service: TDB test1
> [2015-01-28 12:47:34] BuilderINFO  Service: TDB test1
> [2015-01-28 12:47:34] BuilderINFO  Service: :service1
> [2015-01-28 12:47:34] BuilderINFO  Service: TDB test3
> [2015-01-28 12:47:34] Config INFO  Register: /test1
> [2015-01-28 12:47:34] Config INFO  Register: /test1
> [2015-01-28 12:47:34] Server ERROR Exception in initialization: Already 
> registered: /test1
> [2015-01-28 12:47:34] WebAppContext WARN  Failed startup of context 
> o.e.j.w.WebAppContext@d04ca48{/,file:/jena-fuseki/webapp/,STARTING}
> org.apache.jena.fuseki.FusekiException: Already registered: /test1
>   at 
> org.apache.jena.fuseki.server.DataAccessPointRegistry.register(DataAccessPointRegistry.java:28)
>   at 
> org.apache.jena.fuseki.server.FusekiServer.enable(FusekiServer.java:232)
>   at 
> org.apache.jena.fuseki.server.FusekiServer.initializeDataAccessPoints(FusekiServer.java:226)
>   at 
> org.apache.jena.fuseki.server.FusekiServerListener.init(FusekiServerListener.java:70)
>   at 
> org.apache.jena.fuseki.server.FusekiServerListener.contextInitialized(FusekiServerListener.java:45)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:799)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:446)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:791)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:296)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1347)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:743)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:492)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:117)
>   at org.eclipse.jetty.server.Server.start(Server.java:355)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:99)
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:60)
>   at org.eclipse.jetty.server.Server.doStart(Server.java:324)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
>   at org.apache.jena.fuseki.jetty.JettyFuseki.start(JettyFuseki.java:137)
>   at 
> org.apache.jena.fuseki.cmd.FusekiCmd$FusekiCmdInner.exec(FusekiCmd.java:331)
>   at arq.cmdline.CmdMain.mainMethod(CmdMain.java:102)
>   at arq.cmdline.CmdMain.mainRun(CmdMain.java:63)
>   at arq.cmdline.CmdMain.mainRun(CmdMain.java:50)
>   at 
> org.apache.jena.fuseki.cmd.FusekiCmd$FusekiCmdInner.innerMain(FusekiCmd.java:97)
>   at org.apache.jena.fuseki.cmd.FusekiCmd.main(FusekiCmd.java:60)
> {code}
> In the HTTP log from before:
> {code}
> [2015-01-28 12:47:02] Admin  INFO  [1] GET http://localhost:3031/$/server
> [2015-01-28 12:47:02] Admin  INFO  [1] 200 OK (11 ms) 
> [2015-01-28 12:47:04] Admin  INFO  [2] GET http://localhost:3031/$/server
> [2015-01-28 12:47:04] Admin  INFO  [2] 200 OK (1 ms) 
> [2015-01-28 12:47:08] Admin  INFO  [3] POST 
> http://localhost:3031/$/datasets
> [2015-01-28 12:47:08] Admin  INFO  [3] Create database : name = /test1
> [2015-01-28 12:47:08] BuilderINFO  Service: TDB test1
> [

[GitHub] jena pull request: Richer Javadocs for Iter and ExtendedIterator

[ajs6f]

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

https://github.com/apache/jena/pull/90#discussion_r35869523
  
--- Diff: jena-base/src/main/java/org/apache/jena/atlas/iterator/Iter.java 
---
@@ -29,6 +29,14 @@
 import org.apache.jena.atlas.lib.Closeable ;
 import org.apache.jena.atlas.lib.Sink ;
 
+/**
+ * Iter provides utilities for working with {@link Iterator}s.
+ *
+ * Iter should never be used as a return type or parameter type in the 
public contract of a class. It is only to be used
+ * inside implementation code and is instantiated only to allow 
method-chaining as part of a calculation.
--- End diff --

What I meant by "difference" was context of use. In other words, what I 
have been trying to get at with this conversation, as I have written, is the 
answer to "When should one use `Iter`, and when should one use 
`ExtendedIterator`?" I tried to use `Iter` inside an `ExtendedIterator` during 
JENA-966 and you explained that this was wrong, and I am trying to get Javadocs 
into these classes so that other people don't have the same confusion. 

I still have no idea when to use either. If the difference is purely 
historical, then there is no inherent need for both, and perhaps I should open 
a ticket for a slow, careful, un-disruptive migration towards a single type for 
these purposes?


---
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-966) LazyIterator

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-966:
-

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

https://github.com/apache/jena/pull/90#discussion_r35869523
  
--- Diff: jena-base/src/main/java/org/apache/jena/atlas/iterator/Iter.java 
---
@@ -29,6 +29,14 @@
 import org.apache.jena.atlas.lib.Closeable ;
 import org.apache.jena.atlas.lib.Sink ;
 
+/**
+ * Iter provides utilities for working with {@link Iterator}s.
+ *
+ * Iter should never be used as a return type or parameter type in the 
public contract of a class. It is only to be used
+ * inside implementation code and is instantiated only to allow 
method-chaining as part of a calculation.
--- End diff --

What I meant by "difference" was context of use. In other words, what I 
have been trying to get at with this conversation, as I have written, is the 
answer to "When should one use `Iter`, and when should one use 
`ExtendedIterator`?" I tried to use `Iter` inside an `ExtendedIterator` during 
JENA-966 and you explained that this was wrong, and I am trying to get Javadocs 
into these classes so that other people don't have the same confusion. 

I still have no idea when to use either. If the difference is purely 
historical, then there is no inherent need for both, and perhaps I should open 
a ticket for a slow, careful, un-disruptive migration towards a single type for 
these purposes?


> LazyIterator
> 
>
> Key: JENA-966
> URL: https://issues.apache.org/jira/browse/JENA-966
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Core
>Affects Versions: Jena 3.0.0
>Reporter: Claude Warren
>Assignee: Claude Warren
> Fix For: Jena 3.0.0
>
>
> LazyIterator is an abstract class.  The documentation indicates that the 
> create() method needs to be overridden to create an instance.  From this I 
> would expect that 
> now LazyIterator(){
> @Override
> public ExtendedIterator create() {
>   ...
> }};
> Would work however LazyIterator does not override:
> remoteNext(), andThen(), toList(), and toSet().
> I believe these should be implemented in the class.



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

[jira] [Commented] (JENA-869) Fuseki2: Can't reuse dataset name after DELETE

[ASF subversion and git services (JIRA)]

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

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

Commit b71df52006e5c9ff7b56a9f86652c1ce0023637a in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=b71df52 ]

JENA-869 : 409 error, not 500, when configuration file exists.

> Fuseki2: Can't reuse dataset name after DELETE
> --
>
> Key: JENA-869
> URL: https://issues.apache.org/jira/browse/JENA-869
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Fuseki 2.0.0
>Reporter: Stian Soiland-Reyes (old)
>Assignee: Andy Seaborne
> Fix For: Fuseki 2.3.0
>
> Attachments: JENA-869_20150726200200.png
>
>
> In the web interface, I create a persistent dataset "test1". I then remove 
> it. I then create a second one called "test1". Everything works fine.
> However, if I restart Fuseki, now it attemps to register test1 twice:
> {code}
> [2015-01-28 12:47:33] ServletINFO  Initializing Shiro environment
> [2015-01-28 12:47:33] Config INFO  Shiro file: file:///fuseki/shiro.ini
> [2015-01-28 12:47:33] BuilderINFO  Service: TDB test1
> [2015-01-28 12:47:34] BuilderINFO  Service: TDB test1
> [2015-01-28 12:47:34] BuilderINFO  Service: :service1
> [2015-01-28 12:47:34] BuilderINFO  Service: TDB test3
> [2015-01-28 12:47:34] Config INFO  Register: /test1
> [2015-01-28 12:47:34] Config INFO  Register: /test1
> [2015-01-28 12:47:34] Server ERROR Exception in initialization: Already 
> registered: /test1
> [2015-01-28 12:47:34] WebAppContext WARN  Failed startup of context 
> o.e.j.w.WebAppContext@d04ca48{/,file:/jena-fuseki/webapp/,STARTING}
> org.apache.jena.fuseki.FusekiException: Already registered: /test1
>   at 
> org.apache.jena.fuseki.server.DataAccessPointRegistry.register(DataAccessPointRegistry.java:28)
>   at 
> org.apache.jena.fuseki.server.FusekiServer.enable(FusekiServer.java:232)
>   at 
> org.apache.jena.fuseki.server.FusekiServer.initializeDataAccessPoints(FusekiServer.java:226)
>   at 
> org.apache.jena.fuseki.server.FusekiServerListener.init(FusekiServerListener.java:70)
>   at 
> org.apache.jena.fuseki.server.FusekiServerListener.contextInitialized(FusekiServerListener.java:45)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:799)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:446)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:791)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:296)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1347)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:743)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:492)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:117)
>   at org.eclipse.jetty.server.Server.start(Server.java:355)
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:99)
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:60)
>   at org.eclipse.jetty.server.Server.doStart(Server.java:324)
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
>   at org.apache.jena.fuseki.jetty.JettyFuseki.start(JettyFuseki.java:137)
>   at 
> org.apache.jena.fuseki.cmd.FusekiCmd$FusekiCmdInner.exec(FusekiCmd.java:331)
>   at arq.cmdline.CmdMain.mainMethod(CmdMain.java:102)
>   at arq.cmdline.CmdMain.mainRun(CmdMain.java:63)
>   at arq.cmdline.CmdMain.mainRun(CmdMain.java:50)
>   at 
> org.apache.jena.fuseki.cmd.FusekiCmd$FusekiCmdInner.innerMain(FusekiCmd.java:97)
>   at org.apache.jena.fuseki.cmd.FusekiCmd.main(FusekiCmd.java:60)
> {code}
> In the HTTP log from before:
> {code}
> [2015-01-28 12:47:02] Admin  INFO  [1] GET http://localhost:3031/$/server
> [2015-01-28 12:47:02] Admin  INFO  [1] 200 OK (11 ms) 
> [2015-01-28 12:47:04] Admin  INFO  [2] GET http://localhost:3031/$/server
> [2015-01-28 12:47:04] Admin  INFO  [2] 200 OK (1 ms) 
> [2015-01-28 12:47:08] Admin  INFO  [3] POST 
> http://localhost:3031/$/datasets
> [2015-01-28 12:47:08] Admin  INFO  [3] Create database : name = /test1
> [2015-01-28 12:47:08] BuilderINFO  Service: TDB test1
> [2015-

Re: Fwd: Final Deliveries of GSoC Project (JENA-491)

[Andy Seaborne]

Output of
* each examnple syntax file (the queries are nonsense in practcial terms!)
* running arq.qparse on the file
* notes on what seems to be going on

Andy

 File: syntax-quad-construct-01.arq
PREFIX : 

CONSTRUCT { GRAPH :g { :s :p :o } } WHERE {}
 Output of qparse --file syntax-quad-construct-01.arq
PREFIX  : 

CONSTRUCT
  { GRAPH  {:s :p :o .}
  }
WHERE
  {  }
 Issue:
Minor: formatting of  should be :g

 File: syntax-quad-construct-02.arq
PREFIX : 

CONSTRUCT { GRAPH ?g { ?s ?p ?o } } WHERE { ?s ?p ?o }
 Output of qparse --file syntax-quad-construct-02.arq
PREFIX  : 

CONSTRUCT
  { GRAPH ?g {?s ?p ?o .}
  }
WHERE
  { ?s  ?p  ?o }

OK

 File: syntax-quad-construct-03.arq
PREFIX : 

CONSTRUCT { :s :p :o } WHERE {}
 Output of qparse --file syntax-quad-construct-03.arq
PREFIX  : 

CONSTRUCT
  { GRAPH  {:s :p :o .}
  }
WHERE
  {  }
 Issue:
Major: The output is contains "GRAPH "

Note:  is for internal use only.

For syntax, that is a named graph just like 

 File: syntax-quad-construct-04.arq
PREFIX : 

CONSTRUCT {
   GRAPH ?g { :s :p :o }
   ?s ?p ?o
   }
WHERE
   { GRAPH ?g { ?s ?p ?o } }

 Output of qparse --file syntax-quad-construct-04.arq

 Check failure: reparsed query hashCode does not equal parsed input 
query

Query (hashCode: 1768688961)=
PREFIX  : 

CONSTRUCT
  { GRAPH ?g {:s :p :o .
  ?s ?p ?o .}
  }
WHERE
  { GRAPH ?g
  { ?s  ?p  ?o }
  }


Query2 (hashCode: 1896249441)=
PREFIX  : 

CONSTRUCT
  { GRAPH ?g {:s :p :o .
  ?s ?p ?o .}
  }
WHERE
  { GRAPH ?g
  { ?s  ?p  ?o }
  }

PREFIX  : 

CONSTRUCT
  { GRAPH ?g {:s :p :o .
  ?s ?p ?o .}
  }
WHERE
  { GRAPH ?g
  { ?s  ?p  ?o }
  }
 Issue:
The output puts the following triple into the GRAPH.
See also syntax-quad-construct-08.arq

 File: syntax-quad-construct-05.arq
PREFIX : 

CONSTRUCT {
   ?s ?p ?o
   GRAPH ?g { :s :p :o }
   }
WHERE
   { GRAPH ?g { ?s ?p ?o } }

 Output of qparse --file syntax-quad-construct-05.arq

 Check failure: reparsed query hashCode does not equal parsed input 
query

Query (hashCode: -262437683)=
PREFIX  : 

CONSTRUCT
  { GRAPH  {?s ?p ?o .
  :s :p :o .}
  }
WHERE
  { GRAPH ?g
  { ?s  ?p  ?o }
  }


Query2 (hashCode: -399379987)=
PREFIX  : 

CONSTRUCT
  { GRAPH  {?s ?p ?o .
  :s :p :o .}
  }
WHERE
  { GRAPH ?g
  { ?s  ?p  ?o }
  }

PREFIX  : 

CONSTRUCT
  { GRAPH  {?s ?p ?o .
  :s :p :o .}
  }
WHERE
  { GRAPH ?g
  { ?s  ?p  ?o }
  }
 Issue:
Plain ?s ?p ?o has been put into a named graph
Adjacent blocks have merged.

 File: syntax-quad-construct-06.arq
PREFIX : 

CONSTRUCT {
   GRAPH ?g { :s :p :o }
   ?s ?p ?o .
   ?s ?p ?o .
   GRAPH ?g { ?s ?p ?o }
   ?s ?p ?o .
   ?s ?p ?o
   GRAPH ?g { ?s ?p ?o }
   }
WHERE
   { GRAPH ?g { ?s ?p ?o } }

 Output of qparse --file syntax-quad-construct-06.arq

 Check failure: reparsed query hashCode does not equal parsed input 
query

Query (hashCode: -1800516808)=
PREFIX  : 

CONSTRUCT
  { GRAPH ?g {:s :p :o .
  ?s ?p ?o .
  ?s ?p ?o .
  ?s ?p ?o .
  ?s ?p ?o .
  ?s ?p ?o .
  ?s ?p ?o .}
  }
WHERE
  { GRAPH ?g
  { ?s  ?p  ?o }
  }


Query2 (hashCode: -129418312)=
PREFIX  : 

CONSTRUCT
  { GRAPH ?g {:s :p :o .
  ?s ?p ?o .
  ?s ?p ?o .
  ?s ?p ?o .
  ?s ?p ?o .
  ?s ?p ?o .
  ?s ?p ?o .}
  }
WHERE
  { GRAPH ?g
  { ?s  ?p  ?o }
  }

PREFIX  : 

CONSTRUCT
  { GRAPH ?g {:s :p :o .
  ?s ?p ?o .
  ?s ?p ?o .
  ?s ?p ?o .
  ?s ?p ?o .
  ?s ?p ?o .
  ?s ?p ?o .}
  }
WHERE
  { GRAPH ?g
  { ?s  ?p  ?o }
  }
 Issue:
Same as previous.

 File: syntax-quad-construct-07.arq
PREFIX : 

CONSTRUCT {
   GRAPH  {:s :p :o .}
   }
WHERE {}

 Output of qparse --file syntax-quad-construct-07.arq
PREFIX  : 

CONSTRUCT
  { GRAPH  {:s :p :o .}
  }
WHERE
  {  }
 Issue:
Should be different.  A named graph of GRAPH 
is not the default graph.

 File: syntax-quad-construct-08.arq
PREFIX : 

CONSTRUCT {
   GRAPH ?g { :s :p :o }
   GRAPH ?g1 { :s :p :o }
   }
WHERE
   { }

 Output of qparse --file syntax-quad-construct-08.arq

 Check failure: reparsed query hashCode does not equal parsed input 
query

Query (hashCode: 636900208)=
PREFIX  : 

CONSTRUCT
  { GRAPH ?g {:s :p :o .
  :s :p :o .}
  }
WHERE
  {  }


Query2 (hashCode: 636999583)=
PREFIX  : 

CONSTRUCT
  { GRAPH ?g {:s :p :o .
  :s :p :o .}
  }
WHERE
  {  }

PREFIX  : 

Re: Fwd: Final Deliveries of GSoC Project (JENA-491)

[Andy Seaborne]

Hi Qihong,

In my email of July 19, I wrote:


1. Code and grammar changes
2. Tests
3. Pull requests
4. Documentation


See email [1].

I don't see any tests and syntax examples I tried don't work.  Tests are 
important.


There need to be syntax tests; syntax tests go in syn-arq.sh. (your 
email [2])


To help, I have produced a number files and run them through arq.qparse. 
 I'll email you directly with a zip that has all these examples, the 
comments with each file and the script I used to run them.


In the message following this one, I include the test output with 
commentary.


Please acknowledge receipt of the zip file as soon as possible.


There will need to be execute tests in jena-arq as well. These can be 
Junit tests in java and do not need to be external script files.  This 
is separate from testing in Fuseki.


Andy

[1] 
http://mail-archives.apache.org/mod_mbox/jena-dev/201507.mbox/%3c55abd740.9010...@apache.org%3E


[2] 
http://mail-archives.apache.org/mod_mbox/jena-dev/201507.mbox/%3ccajyr9mw4jwveaxbfk--da6apfyhituntkuzkdxtmjq0zztw...@mail.gmail.com%3E


On 30/07/15 03:59, Qihong Lin wrote:

Hi,

I've fixed the bugs of  arq.aparse and "<>", with some minor
improvements for Java 7/8 you mentioned. Please check the PR 89. I
hope it can be merged into jena master ASAP, so that I can go on with
merging the code for  fuseki support.

regard,
Qihong

On Wed, Jul 29, 2015 at 11:54 AM, Ying Jiang  wrote:

Hi Qihong,

You're requried to keep us posted of your work progress regularly.
Last week, there were some comments for your code ( PR 89 ) from the
community. Have you read them and refined your code accordingly? Any
questions?

Best regards,
Ying Jiang


On Tue, Jul 21, 2015 at 4:35 PM, Andy Seaborne  wrote:

On 21/07/15 17:46, Ying Jiang wrote:


Hi Andy,

Does Qihong need to be an apache committer in order to have the commit
access? Can you grant her the access right?

Best regards,
Ying Jiang



When you press "Improve this page" it says

"please use the username anonymous and leave the password blank if prompted
for credentials"


Before documentation makes sense, there needs to code updates.
This is most important.

http://mail-archives.apache.org/mod_mbox/jena-dev/201507.mbox/%3C55ABD740.9010101%40apache.org%3E

1. Code and grammar changes
2. Tests
3. Pull requests
4. Documentation

http://mail-archives.apache.org/mod_mbox/jena-dev/201507.mbox/%3C559EF342.3010806%40apache.org%3E

 Andy




-- Forwarded message --
From: Qihong Lin 
Date: Tue, Jul 21, 2015 at 9:25 AM
Subject: Fwd: Final Deliveries of GSoC Project (JENA-491)
To: Ying Jiang 


Hi, Dr. Jiang,

How can I have the commit access to the svn server? I also tried the
"Improve this Page", which asked for user/password.

The documentation seems to be wiki style. It's better to have preview
of the doc when composing. The patch approach is not so convenient.


regards,
Qihong



-- Forwarded message --
From: Bruno P. Kinoshita 
Date: Sun, Jul 19, 2015 at 5:52 AM
Subject: Re: Final Deliveries of GSoC Project (JENA-491)
To: "dev@jena.apache.org" 



For 1), how to commit the documentation in Jena website?


If you have commit access you can either edit the pages online by
clicking on the link in the top right corner "Improve this Page", or
check out the source repository at
http://svn.apache.org/repos/asf/jena/site/trunk/ and commit your
changes.

Or you can check out the SVN repository, create a patch and attach it
to a JIRA issue.

Changes to the web site are visible initially in
http://jena.staging.apache.org/
Hope that helpsBruno


From: Qihong Lin 
   To: dev@jena.apache.org
   Sent: Sunday, July 19, 2015 6:17 AM
   Subject: Re: Final Deliveries of GSoC Project (JENA-491)

Hi,

I've been taking some course exams for the last week. The current
project status is ahead of plan. I'll continue the project next week
after the exams.

For 1), how to commit the documentation in Jena website?


regards,
Qihong



On Wed, Jul 15, 2015 at 5:43 PM, Ying Jiang  wrote:


Hi Qihong,

How is the project going?

I've reviewed the code you committed last week. The function of Fuseki
support of constructing quad is generally OK. The tests make sense to
me, although just 2 tests. However, there's more deliveries for you
final work. At least,

1) Formal documentation of the goals, approaches, results and etc.
I suggest creating a doc page in jena website [1], in the section of
"Advanced SPARQL use"

2) Pull requests from your code base into apache/jena ASAP
Please split this up so that we can check your commits one by one.
More details in the other thread advised by Andy.

3) More tests for jena-arq and jena-fuseki-core following the original
framework

Please let me know if anything forgotten.


Best regards,
Ying Jiang


[1] https://jena.apache.org/documentation/query/index.html