date:20151210

Fwd: [jira] [Created] (JENA-1084) Compare nontransactional DatasetGraphInMemory and DatasetGraphFactory::create

2015-12-10 Thread A. Soroka

Andy, if the ticket below captures what you would like done, please assign it 
to me.

---
A. Soroka
The University of Virginia Library

> Begin forwarded message:
> 
> From: "A. Soroka (JIRA)" 
> Subject: [jira] [Created] (JENA-1084) Compare nontransactional 
> DatasetGraphInMemory and DatasetGraphFactory::create
> Date: December 10, 2015 at 3:57:11 PM EST
> To: dev@jena.apache.org
> Reply-To: dev@jena.apache.org
> 
> A. Soroka created JENA-1084:
> ---
> 
> Summary: Compare nontransactional DatasetGraphInMemory and 
> DatasetGraphFactory::create
> Key: JENA-1084
> URL: https://issues.apache.org/jira/browse/JENA-1084
> Project: Apache Jena
>  Issue Type: Test
>  Components: ARQ
>Reporter: A. Soroka
>Priority: Minor
> 
> 
> This task is to determine whether a nontransactional construction of 
> DatasetGraphInMemory is performant compared with the current implementation 
> behind {{DatasetGraphFactory::create}}, with an eye towards possible 
> replacement.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)

[jira] [Created] (JENA-1084) Compare nontransactional DatasetGraphInMemory and DatasetGraphFactory::create

2015-12-10 Thread A. Soroka (JIRA)

A. Soroka created JENA-1084:
---

 Summary: Compare nontransactional DatasetGraphInMemory and 
DatasetGraphFactory::create
 Key: JENA-1084
 URL: https://issues.apache.org/jira/browse/JENA-1084
 Project: Apache Jena
  Issue Type: Test
  Components: ARQ
Reporter: A. Soroka
Priority: Minor


This task is to determine whether a nontransactional construction of 
DatasetGraphInMemory is performant compared with the current implementation 
behind {{DatasetGraphFactory::create}}, with an eye towards possible 
replacement.



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

[jira] [Commented] (JENA-1083) MInor refactoring in TupleTables

2015-12-10 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on JENA-1083:
--

Github user ajs6f commented on the pull request:

https://github.com/apache/jena/pull/106#issuecomment-163739254
  
There are a lot of whitespace changes in this PR, for which I apologize. 
They are present because I have switched my IDE to 4-space indents to match the 
more commons usage in the Jena codebase. If this is too confusing and it would 
be preferably to go back to the form that I had been using, please say so and I 
will be happy to so do.


> MInor refactoring in TupleTables
> 
>
> Key: JENA-1083
> URL: https://issues.apache.org/jira/browse/JENA-1083
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Reporter: A. Soroka
>Priority: Minor
>
> There are some minor refactorings available for TupleTable and its subtypes, 
> particularly PMapTripleTable and PMapQuadTable that will clarify their use. 
> Specifically, current impls of those abstract types have to override several 
> methods for adding, removing, and finding tuples. In fact, the only 
> information being added when those methods are overridden is conversion 
> between canonical and internal tuple ordering. This refactoring is to provide 
> methods that do that conversion and nothing else, which will make two methods 
> the most that any implementation of those abstract classes will have to 
> provide.



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

[jira] [Commented] (JENA-1083) MInor refactoring in TupleTables

2015-12-10 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on JENA-1083:
--

GitHub user ajs6f opened a pull request:

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

JENA-1083: Refactoring in TupleTable and subtypes for clarity and concision



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

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

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

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


commit 7769970b0124b3a054a20d315e44dce77c33e030
Author: ajs6f 
Date:   2015-12-10T20:07:18Z

Refactoring in TupleTable and subtypes for clarity and concision




> MInor refactoring in TupleTables
> 
>
> Key: JENA-1083
> URL: https://issues.apache.org/jira/browse/JENA-1083
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Reporter: A. Soroka
>Priority: Minor
>
> There are some minor refactorings available for TupleTable and its subtypes, 
> particularly PMapTripleTable and PMapQuadTable that will clarify their use. 
> Specifically, current impls of those abstract types have to override several 
> methods for adding, removing, and finding tuples. In fact, the only 
> information being added when those methods are overridden is conversion 
> between canonical and internal tuple ordering. This refactoring is to provide 
> methods that do that conversion and nothing else, which will make two methods 
> the most that any implementation of those abstract classes will have to 
> provide.



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

[GitHub] jena pull request: JENA-1083: Refactoring in TupleTable and subtyp...

2015-12-10 Thread ajs6f

GitHub user ajs6f opened a pull request:

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

JENA-1083: Refactoring in TupleTable and subtypes for clarity and concision



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

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

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

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


commit 7769970b0124b3a054a20d315e44dce77c33e030
Author: ajs6f 
Date:   2015-12-10T20:07:18Z

Refactoring in TupleTable and subtypes for clarity and concision




---
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: JENA-1083: Refactoring in TupleTable and subtyp...

2015-12-10 Thread ajs6f

Github user ajs6f commented on the pull request:

https://github.com/apache/jena/pull/106#issuecomment-163739254
  
There are a lot of whitespace changes in this PR, for which I apologize. 
They are present because I have switched my IDE to 4-space indents to match the 
more commons usage in the Jena codebase. If this is too confusing and it would 
be preferably to go back to the form that I had been using, please say so and I 
will be happy to so 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] [Created] (JENA-1083) MInor refactoring in TupleTables

2015-12-10 Thread A. Soroka (JIRA)

A. Soroka created JENA-1083:
---

 Summary: MInor refactoring in TupleTables
 Key: JENA-1083
 URL: https://issues.apache.org/jira/browse/JENA-1083
 Project: Apache Jena
  Issue Type: Improvement
  Components: ARQ
Reporter: A. Soroka
Priority: Minor


There are some minor refactorings available for TupleTable and its subtypes, 
particularly PMapTripleTable and PMapQuadTable that will clarify their use. 
Specifically, current impls of those abstract types have to override several 
methods for adding, removing, and finding tuples. In fact, the only information 
being added when those methods are overridden is conversion between canonical 
and internal tuple ordering. This refactoring provide methods that do that 
conversion and nothing else, which makes two methods the most that any 
implementation of those abstract classes will have to provide.



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

[jira] [Updated] (JENA-1083) MInor refactoring in TupleTables

2015-12-10 Thread A. Soroka (JIRA)


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

A. Soroka updated JENA-1083:

Description: There are some minor refactorings available for TupleTable and 
its subtypes, particularly PMapTripleTable and PMapQuadTable that will clarify 
their use. Specifically, current impls of those abstract types have to override 
several methods for adding, removing, and finding tuples. In fact, the only 
information being added when those methods are overridden is conversion between 
canonical and internal tuple ordering. This refactoring is to provide methods 
that do that conversion and nothing else, which will make two methods the most 
that any implementation of those abstract classes will have to provide.  (was: 
There are some minor refactorings available for TupleTable and its subtypes, 
particularly PMapTripleTable and PMapQuadTable that will clarify their use. 
Specifically, current impls of those abstract types have to override several 
methods for adding, removing, and finding tuples. In fact, the only information 
being added when those methods are overridden is conversion between canonical 
and internal tuple ordering. This refactoring provide methods that do that 
conversion and nothing else, which makes two methods the most that any 
implementation of those abstract classes will have to provide.)

> MInor refactoring in TupleTables
> 
>
> Key: JENA-1083
> URL: https://issues.apache.org/jira/browse/JENA-1083
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Reporter: A. Soroka
>Priority: Minor
>
> There are some minor refactorings available for TupleTable and its subtypes, 
> particularly PMapTripleTable and PMapQuadTable that will clarify their use. 
> Specifically, current impls of those abstract types have to override several 
> methods for adding, removing, and finding tuples. In fact, the only 
> information being added when those methods are overridden is conversion 
> between canonical and internal tuple ordering. This refactoring is to provide 
> methods that do that conversion and nothing else, which will make two methods 
> the most that any implementation of those abstract classes will have to 
> provide.



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

Re: [] Release Jena 3.0.1 and Fuseki 2.3.1

2015-12-10 Thread Osma Suominen


10.12.2015, 18:52, Andy Seaborne kirjoitti:

JENA-1018 looks like the relevant change.

In the commit for that, processing all Op was added to VarFinder
including property functions.  Previous they didn't contribute and
that's a bug.  So this looks like the unknown bug getting fixed.


Thanks Andy. That seems to be exactly the issue. My query relied on the 
old behaviour where variables were expected to be visible when they 
shouldn't be. The problem is not with Jena but with my query.


Now I just need a solution for this problem:

1. make a jena-text query *without any graph*
2. using bindings from the results of that query, match additional patterns 
from specific graphs


I think I found one way to do this, but it's not pretty and it relies on 
knowledge of ARQ and jena-text internals. But since the jena-text lookup 
is Jena-specific anyway, maybe this will do:


PREFIX skos: 
PREFIX text: 

SELECT *
WHERE {
  GRAPH  {
GRAPH   {
  (?s ?score ?literal) text:query 'musiikkikasv*' .
}
?s skos:prefLabel ?label .
FILTER (LANG(?label)=LANG(?literal))
  }
}

This is fast (~30ms) and it returns a solution where ?label is bound to 
"musiikkikasvatus"@fi, as I wanted it to be.


Here the inner GRAPH is executed on the special union graph URI, which 
is recognized by jena-text and therefore the Lucene lookup is performed 
on all graphs (i.e. no graph restriction set).


As I see it, the problem is that in SPARQL, if you don't have a GRAPH 
clause, you are addressing the default graph, but once you go inside 
one, there is no way back; you can switch to another named graph using 
another GRAPH clause, but not back to the default graph, because it has 
no name. Unless I've missed something.


-Osma

PS. You asked about Fuseki2 in an earlier message and I forgot to reply. 
I've been lazy about switching since I don't use the UI much anyway, 
just the APIs and occasionally http://yasgui.org for SPARQL queries. I 
have a custom Jetty configuration [1] and some other server 
configuration (startup scripts and symlinks) that maybe needs some 
migration to be able to switch to Fuseki2.


[1] https://github.com/NatLibFi/Skosmos/wiki/FusekiTuning#tuning-jetty

--
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Kaikukatu 4)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
osma.suomi...@helsinki.fi
http://www.nationallibrary.fi

Re: text:query fails with GRAPH and VALUES Re: [] Release Jena 3.0.1 and Fuseki 2.3.1

2015-12-10 Thread Osma Suominen


Oh yes, stacktrace. Here:

21:56:15 WARN  [4] RC = 500 : Attempt to reassign '?graph' from 
'' to ''
org.apache.jena.sparql.ARQInternalErrorException: Attempt to reassign 
'?graph' from '' to 
''
	at 
org.apache.jena.sparql.engine.binding.BindingHashMap.checkAdd(BindingHashMap.java:112)
	at 
org.apache.jena.sparql.engine.binding.BindingHashMap.add(BindingHashMap.java:91)
	at 
org.apache.jena.sparql.engine.binding.BindingFactory.materialize(BindingFactory.java:60)
	at 
org.apache.jena.tdb.solver.QueryEngineTDB$QueryIteratorMaterializeBinding.moveToNextBinding(QueryEngineTDB.java:131)
	at 
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.nextBinding(QueryIteratorBase.java:153)
	at 
org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.moveToNextBinding(QueryIteratorWrapper.java:42)
	at 
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.nextBinding(QueryIteratorBase.java:153)
	at 
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.next(QueryIteratorBase.java:128)
	at 
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.next(QueryIteratorBase.java:40)
	at 
org.apache.jena.sparql.engine.ResultSetStream.nextBinding(ResultSetStream.java:86)
	at 
org.apache.jena.sparql.engine.ResultSetStream.nextSolution(ResultSetStream.java:114)
	at 
org.apache.jena.sparql.engine.ResultSetStream.next(ResultSetStream.java:123)
	at 
org.apache.jena.sparql.engine.ResultSetCheckCondition.next(ResultSetCheckCondition.java:65)
	at 
org.apache.jena.sparql.resultset.ResultSetApply.apply(ResultSetApply.java:39)

at 
org.apache.jena.sparql.resultset.JSONOutput.format(JSONOutput.java:34)
	at 
org.apache.jena.query.ResultSetFormatter.outputAsJSON(ResultSetFormatter.java:500)
	at 
org.apache.jena.fuseki.servlets.ResponseResultSet$2.output(ResponseResultSet.java:209)
	at 
org.apache.jena.fuseki.servlets.ResponseResultSet.output(ResponseResultSet.java:301)
	at 
org.apache.jena.fuseki.servlets.ResponseResultSet.jsonOutput(ResponseResultSet.java:227)
	at 
org.apache.jena.fuseki.servlets.ResponseResultSet.doResponseResultSet$(ResponseResultSet.java:145)
	at 
org.apache.jena.fuseki.servlets.ResponseResultSet.doResponseResultSet(ResponseResultSet.java:88)
	at 
org.apache.jena.fuseki.servlets.SPARQL_Query.sendResults(SPARQL_Query.java:364)
	at 
org.apache.jena.fuseki.servlets.SPARQL_Query.execute(SPARQL_Query.java:254)
	at 
org.apache.jena.fuseki.servlets.SPARQL_Query.executeWithParameter(SPARQL_Query.java:205)
	at 
org.apache.jena.fuseki.servlets.SPARQL_Query.perform(SPARQL_Query.java:100)
	at 
org.apache.jena.fuseki.servlets.SPARQL_ServletBase.executeLifecycle(SPARQL_ServletBase.java:227)
	at 
org.apache.jena.fuseki.servlets.SPARQL_ServletBase.executeAction(SPARQL_ServletBase.java:204)
	at 
org.apache.jena.fuseki.servlets.SPARQL_ServletBase.execCommonWorker(SPARQL_ServletBase.java:186)
	at 
org.apache.jena.fuseki.servlets.SPARQL_ServletBase.doCommon(SPARQL_ServletBase.java:79)
	at 
org.apache.jena.fuseki.servlets.SPARQL_Query.doPost(SPARQL_Query.java:60)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:755)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
	at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1496)
	at 
org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)

at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:256)
	at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
	at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
	at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:229)
	at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
	at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)
	at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
	at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
	at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
	at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)

at org.eclipse.jetty.server.Server.handle(Server.java:370)
	at 
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
	at 
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
	at 
org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)
	at 
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)

at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:2

Re: A release?

2015-12-10 Thread A. Soroka

“We” are the people having this conversation. It’s often very hard for me to 
understand what you are saying (e.g. “If it makes a difference, it can the 
implementation for Dataset(Graph)Factory.create()…", so I need to confirm 
carefully what we are talking about.

If I understand it so far, you want me to execute some TupleTable 
implementations that use simple datastructures that would not support 
transactionality but would operate with low overhead so that we can check the 
performance of a DatasetGraphInMemory using them?

---
A. Soroka
The University of Virginia Library

> On Dec 10, 2015, at 1:07 PM, Andy Seaborne  wrote:
> 
> On 10/12/15 17:41, A. Soroka wrote:
>> Ah, okay, cool. But was my other interpretation correct? A 
>> DatasetGraphInMemory using simple (non-transaction-supporting) TupleTables 
>> would be good for DatasetGraphFactory::create?
>> 
> 
> "so we are saying" - who is "we?!
> 
> maybe - if it's appreciably faster, yes; if it's not less point and it adds 
> to maintenance.
> 
> That's why I was interested in a performance comparison.
> 
>> ---
>> A. Soroka
>> The University of Virginia Library
>> 
>>> On Dec 10, 2015, at 12:38 PM, Andy Seaborne  wrote:
>>> 
>>> On 10/12/15 17:18, A. Soroka wrote:
 Okay, so we are saying that a Dataset around a DatasetGraphInMemory using 
 simple (non-transaction-supporting) TupleTables would be good for 
 DatasetFactory::create or ::createGeneral? (Or both— I’m not totally clear 
 about the difference between them.)
>>> 
>>> General holds graphs from other storages as a ptr to that graph.  It is a 
>>> collection of graphs, no quads.  "GRAPH ?g" is a loop.
>>> 
>>> Andy
>>> 
 
 ---
 A. Soroka
 The University of Virginia Library
 
> On Dec 10, 2015, at 10:25 AM, Andy Seaborne  wrote:
> 
> On 10/12/15 13:31, A. Soroka wrote:
>> To the first question, I think the answer is yes. It was very much my 
>> intention that TupleTable and its subtypes would provide opportunity to 
>> explore different useful structures (e.g. Claude Warren’s ideas about 
>> Bloom filters). A [Triple|Quad]Table that uses ordinary maps/structures 
>> in the same way as the current impl uses persistent structures should be 
>> very easy. Would you like me to cut such classes to have them available 
>> for non-transactional cases?
>> 
>> I’m not quite sure what your last sentence means; is it about the 
>> semantics of the factory methods?
> 
> There are 4 factory methods in each factory
> 
> * DatasetFactory.create()
> The new place for in-memory, non-transactional dataset with graph-copy 
> semantics.  Currently, it is a general dataset with "add graph" 
> overridden to do a copy-in.
> 
> * DatasetFactory.createTxnMem()
> The new place for in-memory, transactional dataset (with graph-copy 
> semantics).
> 
> * DatasetFactory.createMem()
> The old place for in-memory datasets - goes to createGeneral()
> Deprecated because if replaced by create() then details have changed.
> 
> * DatasetFactory.createGeneral()
> The new place for general datasets.
> 
>   Andy
> 
>> 
>> ---
>> A. Soroka
>> The University of Virginia Library
>> 
>>> On Dec 10, 2015, at 8:15 AM, Andy Seaborne  wrote:
>>> 
>>> On 09/12/15 21:00, A. Soroka wrote:
 Cool. The extension points are basically TripleTable and QuadTable, 
 because of the constructor DatasetGraphInMemory(QuadTable, 
 TripleTable). Someone could offer their own impls and use that 
 (public) constructor.
>>> 
>>> Does that mean it would be easy to do a non-transactional version, that 
>>> used hash maps (or used hash maps at the top level at least)?
>>> 
>>> That would make an excellent performance comparison.
>>> 
>>> If it makes a difference, it can the implementation for 
>>> Dataset(Graph)Factory.create() and have the copy-in semantics for "add 
>>> graph".
>>> 
>>> Andy
>> 
> 
 
>>> 
>> 
>

Re: A release?

2015-12-10 Thread Andy Seaborne


On 10/12/15 17:41, A. Soroka wrote:

Ah, okay, cool. But was my other interpretation correct? A DatasetGraphInMemory 
using simple (non-transaction-supporting) TupleTables would be good for 
DatasetGraphFactory::create?



"so we are saying" - who is "we?!

maybe - if it's appreciably faster, yes; if it's not less point and it 
adds to maintenance.


That's why I was interested in a performance comparison.


---
A. Soroka
The University of Virginia Library


On Dec 10, 2015, at 12:38 PM, Andy Seaborne  wrote:

On 10/12/15 17:18, A. Soroka wrote:

Okay, so we are saying that a Dataset around a DatasetGraphInMemory using 
simple (non-transaction-supporting) TupleTables would be good for 
DatasetFactory::create or ::createGeneral? (Or both— I’m not totally clear 
about the difference between them.)


General holds graphs from other storages as a ptr to that graph.  It is a collection of 
graphs, no quads.  "GRAPH ?g" is a loop.

Andy



---
A. Soroka
The University of Virginia Library


On Dec 10, 2015, at 10:25 AM, Andy Seaborne  wrote:

On 10/12/15 13:31, A. Soroka wrote:

To the first question, I think the answer is yes. It was very much my intention 
that TupleTable and its subtypes would provide opportunity to explore different 
useful structures (e.g. Claude Warren’s ideas about Bloom filters). A 
[Triple|Quad]Table that uses ordinary maps/structures in the same way as the 
current impl uses persistent structures should be very easy. Would you like me 
to cut such classes to have them available for non-transactional cases?

I’m not quite sure what your last sentence means; is it about the semantics of 
the factory methods?


There are 4 factory methods in each factory

* DatasetFactory.create()
The new place for in-memory, non-transactional dataset with graph-copy semantics.  
Currently, it is a general dataset with "add graph" overridden to do a copy-in.

* DatasetFactory.createTxnMem()
The new place for in-memory, transactional dataset (with graph-copy semantics).

* DatasetFactory.createMem()
The old place for in-memory datasets - goes to createGeneral()
Deprecated because if replaced by create() then details have changed.

* DatasetFactory.createGeneral()
The new place for general datasets.

   Andy



---
A. Soroka
The University of Virginia Library


On Dec 10, 2015, at 8:15 AM, Andy Seaborne  wrote:

On 09/12/15 21:00, A. Soroka wrote:

Cool. The extension points are basically TripleTable and QuadTable, because of 
the constructor DatasetGraphInMemory(QuadTable, TripleTable). Someone could 
offer their own impls and use that (public) constructor.


Does that mean it would be easy to do a non-transactional version, that used 
hash maps (or used hash maps at the top level at least)?

That would make an excellent performance comparison.

If it makes a difference, it can the implementation for Dataset(Graph)Factory.create() 
and have the copy-in semantics for "add graph".

Andy

[jira] [Updated] (JENA-1082) Add to org.apache.jena.rdf.model.ModelCon interface a listLiteralStatements method that accepts ints.

2015-12-10 Thread Andy Seaborne (JIRA)


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

Andy Seaborne updated JENA-1082:

Issue Type: Improvement  (was: Bug)

> Add to org.apache.jena.rdf.model.ModelCon interface a listLiteralStatements 
> method that accepts ints.
> -
>
> Key: JENA-1082
> URL: https://issues.apache.org/jira/browse/JENA-1082
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.0.0
>Reporter: Ramiro Pereira de Magalhães
>
> Add to org.apache.jena.rdf.model.ModelCon interface a {{StmtIterator 
> listLiteralStatements(Resource subject, Property predicate, int object );}} 
> method.
> Implement such method in classes that implement such interface. This method 
> should be able to list literal integer statements, like the other 
> listLiteralStatement methods do to other types.



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

[jira] [Updated] (JENA-1082) Add to org.apache.jena.rdf.model.ModelCon interface a listLiteralStatements method that accepts ints.

2015-12-10 Thread Andy Seaborne (JIRA)


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

Andy Seaborne updated JENA-1082:

Component/s: (was: Base)
 Core

> Add to org.apache.jena.rdf.model.ModelCon interface a listLiteralStatements 
> method that accepts ints.
> -
>
> Key: JENA-1082
> URL: https://issues.apache.org/jira/browse/JENA-1082
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.0.0
>Reporter: Ramiro Pereira de Magalhães
>Priority: Minor
>
> Add to org.apache.jena.rdf.model.ModelCon interface a {{StmtIterator 
> listLiteralStatements(Resource subject, Property predicate, int object );}} 
> method.
> Implement such method in classes that implement such interface. This method 
> should be able to list literal integer statements, like the other 
> listLiteralStatement methods do to other types.



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

[jira] [Updated] (JENA-1082) Add to org.apache.jena.rdf.model.ModelCon interface a listLiteralStatements method that accepts ints.

2015-12-10 Thread Andy Seaborne (JIRA)


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

Andy Seaborne updated JENA-1082:

Priority: Minor  (was: Major)

> Add to org.apache.jena.rdf.model.ModelCon interface a listLiteralStatements 
> method that accepts ints.
> -
>
> Key: JENA-1082
> URL: https://issues.apache.org/jira/browse/JENA-1082
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.0.0
>Reporter: Ramiro Pereira de Magalhães
>Priority: Minor
>
> Add to org.apache.jena.rdf.model.ModelCon interface a {{StmtIterator 
> listLiteralStatements(Resource subject, Property predicate, int object );}} 
> method.
> Implement such method in classes that implement such interface. This method 
> should be able to list literal integer statements, like the other 
> listLiteralStatement methods do to other types.



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

[jira] [Commented] (JENA-1082) Add to org.apache.jena.rdf.model.ModelCon interface a listLiteralStatements method that accepts ints.

2015-12-10 Thread Andy Seaborne (JIRA)


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

Andy Seaborne commented on JENA-1082:
-

There is already {{listLiteralStatements(Resource subject, Property predicate, 
long object)}}.  Does that work for your use case?

> Add to org.apache.jena.rdf.model.ModelCon interface a listLiteralStatements 
> method that accepts ints.
> -
>
> Key: JENA-1082
> URL: https://issues.apache.org/jira/browse/JENA-1082
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Base
>Affects Versions: Jena 3.0.0
>Reporter: Ramiro Pereira de Magalhães
>
> Add to org.apache.jena.rdf.model.ModelCon interface a {{StmtIterator 
> listLiteralStatements(Resource subject, Property predicate, int object );}} 
> method.
> Implement such method in classes that implement such interface. This method 
> should be able to list literal integer statements, like the other 
> listLiteralStatement methods do to other types.



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

Re: per-graph locking for dataset?

2015-12-10 Thread A. Soroka

On Dec 10, 2015, at 8:29 AM, Andy Seaborne  wrote:
> On 09/12/15 13:22, A. Soroka wrote:
>> So I’ve been casting about for some simple ways to deliver cheap and very 
>> limited forms of MRMW that might provide some “bang for the buck” for Jena 
>> users. One to which I keep coming back is the idea of a dataset with 
>> per-graph transaction locking.
> 
> That might combine well with using the Graph Store Protocol for graph 
> management where default union graph is common.
> Another locking strategy is "graph node" i.e. a subject-in-a-graph and all 
> its in and out links.  Then it's MW when working on different parts of a 
> graph.  Different characteristics.

I’ve thought about this and variations on it, and read some papers by people 
who have developed other kinds of triplestore locking schemes. For simplicity 
I’m trying to understand the per-named-graph approach in the lattice of 
partitions of the dataset, if we think about the blocks of a partition as each 
taking an MR+SW lock. The trivial/greatest partition is the MR+SW dataset we 
are now introducing in 3.0.1. The finest/least partition is locking per-triple. 
I’m trying to find a scheme in the middle that is a reasonable “iteration 
forward” from what’s been done for 624 so far, reasonably performant, 
reasonably useful, etc.

The “graph node” approach doesn’t partition the dataset, but it is obviously of 
a finer/more sophisticated granularity than the per-named-graph approach, so 
could be superior in at least that way for at least some cases. But an approach 
that partitions the dataset is attractive to me because it can lend a natural 
form to the implementation (depending on how the partition is chosen) and is 
easy to reason about for application developers.

>> In other words, a dataset wherein each named graph has a SW lock and the 
>> dataset as a whole can support MRMW, as long as every writer is working in a 
>> different graph.
> What isolation levels do you want to support?  With MW, this now matters.

I think we might have to go for snapshot isolation again for some of the 
reasons you gave, but I’m still trying to reason about this and also sniff out 
other issues. For example, I don’t understand lock interaction very well yet. 
Suppose Transaction1 acquires a W lock on Graph1 and a R lock on Graph2. Then 
Transaction2 commits a W to Graph2. I suppose Transaction1 should now fail? The 
fact that it held the two locks together implies that the mutations to Graph1 
could have had some dependency on triples in Graph2 which have changed.

> That's not to say it's a bad idea - but that what "it" is matters.

Yes, the first email was just to start a conversation about whether this level 
of granularity meets the tests of “reasonableness”. The devil is in the 
details, but it is starting to sound to me like it might be worth nailing down 
some of those details.

>> Some examples of where this could be helpful:
>> 
>> * Linked Data persistence backends in which the graph about each
>> HTTP-accessible resource is stored in a separate named graph.
> 
> SPARQL graph Store Protocol.

Meaning that GSP is a good use case?

>> * Fast loading of quads from a sorted file (using multiple cursors).
> 
> Different problem?  That's threading inside a single SW?

Yes, perhaps it is. I was just “brainstorming”. I think there are other cases, 
though. Multi-tenancy comes to mind.

---
A. Soroka
The University of Virginia Library

Re: A release?

2015-12-10 Thread A. Soroka

Ah, okay, cool. But was my other interpretation correct? A DatasetGraphInMemory 
using simple (non-transaction-supporting) TupleTables would be good for 
DatasetGraphFactory::create?

---
A. Soroka
The University of Virginia Library

> On Dec 10, 2015, at 12:38 PM, Andy Seaborne  wrote:
> 
> On 10/12/15 17:18, A. Soroka wrote:
>> Okay, so we are saying that a Dataset around a DatasetGraphInMemory using 
>> simple (non-transaction-supporting) TupleTables would be good for 
>> DatasetFactory::create or ::createGeneral? (Or both— I’m not totally clear 
>> about the difference between them.)
> 
> General holds graphs from other storages as a ptr to that graph.  It is a 
> collection of graphs, no quads.  "GRAPH ?g" is a loop.
> 
>   Andy
> 
>> 
>> ---
>> A. Soroka
>> The University of Virginia Library
>> 
>>> On Dec 10, 2015, at 10:25 AM, Andy Seaborne  wrote:
>>> 
>>> On 10/12/15 13:31, A. Soroka wrote:
 To the first question, I think the answer is yes. It was very much my 
 intention that TupleTable and its subtypes would provide opportunity to 
 explore different useful structures (e.g. Claude Warren’s ideas about 
 Bloom filters). A [Triple|Quad]Table that uses ordinary maps/structures in 
 the same way as the current impl uses persistent structures should be very 
 easy. Would you like me to cut such classes to have them available for 
 non-transactional cases?
 
 I’m not quite sure what your last sentence means; is it about the 
 semantics of the factory methods?
>>> 
>>> There are 4 factory methods in each factory
>>> 
>>> * DatasetFactory.create()
>>> The new place for in-memory, non-transactional dataset with graph-copy 
>>> semantics.  Currently, it is a general dataset with "add graph" overridden 
>>> to do a copy-in.
>>> 
>>> * DatasetFactory.createTxnMem()
>>> The new place for in-memory, transactional dataset (with graph-copy 
>>> semantics).
>>> 
>>> * DatasetFactory.createMem()
>>> The old place for in-memory datasets - goes to createGeneral()
>>> Deprecated because if replaced by create() then details have changed.
>>> 
>>> * DatasetFactory.createGeneral()
>>> The new place for general datasets.
>>> 
>>>   Andy
>>> 
 
 ---
 A. Soroka
 The University of Virginia Library
 
> On Dec 10, 2015, at 8:15 AM, Andy Seaborne  wrote:
> 
> On 09/12/15 21:00, A. Soroka wrote:
>> Cool. The extension points are basically TripleTable and QuadTable, 
>> because of the constructor DatasetGraphInMemory(QuadTable, TripleTable). 
>> Someone could offer their own impls and use that (public) constructor.
> 
> Does that mean it would be easy to do a non-transactional version, that 
> used hash maps (or used hash maps at the top level at least)?
> 
> That would make an excellent performance comparison.
> 
> If it makes a difference, it can the implementation for 
> Dataset(Graph)Factory.create() and have the copy-in semantics for "add 
> graph".
> 
>   Andy
 
>>> 
>> 
>

Re: A release?

2015-12-10 Thread Andy Seaborne


On 10/12/15 17:18, A. Soroka wrote:

Okay, so we are saying that a Dataset around a DatasetGraphInMemory using 
simple (non-transaction-supporting) TupleTables would be good for 
DatasetFactory::create or ::createGeneral? (Or both— I’m not totally clear 
about the difference between them.)


General holds graphs from other storages as a ptr to that graph.  It is 
a collection of graphs, no quads.  "GRAPH ?g" is a loop.


Andy



---
A. Soroka
The University of Virginia Library


On Dec 10, 2015, at 10:25 AM, Andy Seaborne  wrote:

On 10/12/15 13:31, A. Soroka wrote:

To the first question, I think the answer is yes. It was very much my intention 
that TupleTable and its subtypes would provide opportunity to explore different 
useful structures (e.g. Claude Warren’s ideas about Bloom filters). A 
[Triple|Quad]Table that uses ordinary maps/structures in the same way as the 
current impl uses persistent structures should be very easy. Would you like me 
to cut such classes to have them available for non-transactional cases?

I’m not quite sure what your last sentence means; is it about the semantics of 
the factory methods?


There are 4 factory methods in each factory

* DatasetFactory.create()
The new place for in-memory, non-transactional dataset with graph-copy semantics.  
Currently, it is a general dataset with "add graph" overridden to do a copy-in.

* DatasetFactory.createTxnMem()
The new place for in-memory, transactional dataset (with graph-copy semantics).

* DatasetFactory.createMem()
The old place for in-memory datasets - goes to createGeneral()
Deprecated because if replaced by create() then details have changed.

* DatasetFactory.createGeneral()
The new place for general datasets.

   Andy



---
A. Soroka
The University of Virginia Library


On Dec 10, 2015, at 8:15 AM, Andy Seaborne  wrote:

On 09/12/15 21:00, A. Soroka wrote:

Cool. The extension points are basically TripleTable and QuadTable, because of 
the constructor DatasetGraphInMemory(QuadTable, TripleTable). Someone could 
offer their own impls and use that (public) constructor.


Does that mean it would be easy to do a non-transactional version, that used 
hash maps (or used hash maps at the top level at least)?

That would make an excellent performance comparison.

If it makes a difference, it can the implementation for Dataset(Graph)Factory.create() 
and have the copy-in semantics for "add graph".

Andy

Re: A release?

2015-12-10 Thread A. Soroka

Okay, so we are saying that a Dataset around a DatasetGraphInMemory using 
simple (non-transaction-supporting) TupleTables would be good for 
DatasetFactory::create or ::createGeneral? (Or both— I’m not totally clear 
about the difference between them.)

---
A. Soroka
The University of Virginia Library

> On Dec 10, 2015, at 10:25 AM, Andy Seaborne  wrote:
> 
> On 10/12/15 13:31, A. Soroka wrote:
>> To the first question, I think the answer is yes. It was very much my 
>> intention that TupleTable and its subtypes would provide opportunity to 
>> explore different useful structures (e.g. Claude Warren’s ideas about Bloom 
>> filters). A [Triple|Quad]Table that uses ordinary maps/structures in the 
>> same way as the current impl uses persistent structures should be very easy. 
>> Would you like me to cut such classes to have them available for 
>> non-transactional cases?
>> 
>> I’m not quite sure what your last sentence means; is it about the semantics 
>> of the factory methods?
> 
> There are 4 factory methods in each factory
> 
> * DatasetFactory.create()
> The new place for in-memory, non-transactional dataset with graph-copy 
> semantics.  Currently, it is a general dataset with "add graph" overridden to 
> do a copy-in.
> 
> * DatasetFactory.createTxnMem()
> The new place for in-memory, transactional dataset (with graph-copy 
> semantics).
> 
> * DatasetFactory.createMem()
> The old place for in-memory datasets - goes to createGeneral()
> Deprecated because if replaced by create() then details have changed.
> 
> * DatasetFactory.createGeneral()
> The new place for general datasets.
> 
>   Andy
> 
>> 
>> ---
>> A. Soroka
>> The University of Virginia Library
>> 
>>> On Dec 10, 2015, at 8:15 AM, Andy Seaborne  wrote:
>>> 
>>> On 09/12/15 21:00, A. Soroka wrote:
 Cool. The extension points are basically TripleTable and QuadTable, 
 because of the constructor DatasetGraphInMemory(QuadTable, TripleTable). 
 Someone could offer their own impls and use that (public) constructor.
>>> 
>>> Does that mean it would be easy to do a non-transactional version, that 
>>> used hash maps (or used hash maps at the top level at least)?
>>> 
>>> That would make an excellent performance comparison.
>>> 
>>> If it makes a difference, it can the implementation for 
>>> Dataset(Graph)Factory.create() and have the copy-in semantics for "add 
>>> graph".
>>> 
>>> Andy
>> 
>

Re: [] Release Jena 3.0.1 and Fuseki 2.3.1

2015-12-10 Thread Andy Seaborne


JENA-1018 looks like the relevant change.

In the commit for that, processing all Op was added to VarFinder 
including property functions.  Previous they didn't contribute and 
that's a bug.  So this looks like the unknown bug getting fixed.


Andy

On 10/12/15 13:14, Osma Suominen wrote:

Hi Andy!

I'm very sorry, I've done some testing on intermediate versions
(particularly as I was developing the customizable jena-text analyzer)
but apparently I hadn't tried this particular type of query where the
text condition is outside the GRAPH block. We use them in only in a
special case situation (global search across many SKOS vocabularies) in
the Skosmos application.

I retract my -1 vote. As you say, the vote should be about doing the
release process properly, not the technical side.

I'm still trying to understand the problem. I've tested the Join flags
but I haven't been able to produce any difference. I set both flags to
true but the results were the same as before. For the shorter query,
?label remains unbound and the query takes 400-600 ms.

 From your newer message:

Simpler query:

PREFIX  : 
PREFIX  rdfs: 

SELECT  *
WHERE
  { ?s  :p  ?literal
GRAPH :g
  { ?s  rdfs:label  ?label
FILTER ( ?label = ?literal )
  }
  }

Note also putting the text:query inside {} makes things worse.  It
isolates that part

In this case the ?literal in the FILTER is out of scope of the basic
graph pattern it is defined in.


Right, thanks, I think I now understand what is happening.

Is there a way to rewrite that query so that ?literal would be in scope
for the FILTER, while still keeping the first pattern (?s :p ?literal)
outside the GRAPH block, i.e. targeting the default graph?

I'm willing to rewrite the queries in my application so that they work
with the current ARQ. So far I just haven't found a way to do this:

1. make a jena-text query *without any graph*
2. using bindings from the results of that query, match additional
patterns from specific graphs

-Osma




10.12.2015, 13:26, Andy Seaborne kirjoitti:

Hi Osma,

The primary purpose of the vote is to verify that the release process
has been executed correctly.  A majority and 3 of PMC votes are needed
to show that the release meets the requirements for a release.

I signalled a possible release last month and got a positive response
from you about proceeding.  There are several new features in this
release and it would be good to get those out to people.

Whether a release meets technical goals is a separate matter.

If this is a simple fix, then I'm willing to redo the release but to
quite clear that is not because it fails the release criteria but
because I, not as an release manager, want to get useful code to the
public.

I think if we make the vote the start of checking months of changes,
then we'd never release anything.  There have been builds for some time.

A possible change was JENA-1023 and that was in September.  There is a
flag in class "Join" to control the join strategy.  Please try that (it
needs a rebuild as it's a private static final).

 Andy

http://www.apache.org/dev/release.html#approving-a-release

PS can you use Fuseki 2? (it will not make a performance difference, it
is better code)

On 10/12/15 09:57, Osma Suominen wrote:

On 08/12/15 13:56, Andy Seaborne wrote:

Hi,

Here is a vote on a release of Jena 3.0.1 with Fuseki 2.3.1 and Fuseki
1.3.1.


-1.

We installed Fuseki 1.3.1-SNAPSHOT 2015-12-07T14:05:00+ on our dev
server today. The query below now takes more than 100 seconds. With
1.3.0 it takes about 2.5 seconds. The configuration and databases are
the same.

I'll try to investigate further and isolate a more minimal example. I
just wanted to raise this ASAP.

-Osma


PREFIX owl: 
PREFIX rdf: 
PREFIX skos: 
PREFIX isothes: 
PREFIX text: 
PREFIX cn: 
PREFIX lapponica: 

SELECT DISTINCT ?s ?label ?plabel ?alabel ?hlabel ?graph
(GROUP_CONCAT(DISTINCT ?type) as ?types)

WHERE {
  VALUES (?prop) { (skos:prefLabel) (skos:altLabel) (skos:hiddenLabel) }
  { (?s ?score ?literal) text:query (?prop 'musiikki*'  10) }
  GRAPH ?graph {
   { ?s rdf:type  } UNION {
?s a isothes:ConceptGroup }
   {
?s rdf:type ?type .
OPTIONAL {
 ?s skos:prefLabel ?label .
 FILTER (langMatches(lang(?label), lang(?literal)))
}
   }
   FILTER NOT EXISTS { ?s owl:deprecated true }
  }
  BIND(IF(?prop = skos:prefLabel && ?literal != ?label, ?literal,
?unbound) as ?plabel)
  BIND(IF(?prop = skos:altLabel, ?literal, ?unbound) as ?alabel)
  BIND(IF(?prop = skos:hiddenLabel, ?literal, ?unbound) as ?hlabel)
}
GROUP BY ?literal ?s ?label ?plabel ?alabel ?hlabel ?

Re: text:query fails with GRAPH and VALUES Re: [] Release Jena 3.0.1 and Fuseki 2.3.1

2015-12-10 Thread Andy Seaborne


On 10/12/15 15:53, Osma Suominen wrote:

Hi,

While trying to find a query that works and performs well enough I
noticed that this query:

PREFIX skos: 
PREFIX text: 

SELECT *
WHERE {
   GRAPH ?graph {
 ?s text:query 'musiikkikasv*' .
   }
}
VALUES ?graph {  }

when there are any potential results, produces this error:

Error 500: Attempt to reassign '?graph' from
'' to ''


I guess this is a bug related to jena-text, since a basic graph pattern
instead of the text:query pattern works.

If I change ?graph to the actual URI and remove the VALUES clause, then
there is no error.

This also happens with 1.3.0 so this is not a new bug.

-Osma



Fuseki - version 1.3.1-SNAPSHOT (Build date: 2015-12-06T09:53:42+)



Stacktrace?

Andy

text:query fails with GRAPH and VALUES Re: [] Release Jena 3.0.1 and Fuseki 2.3.1

2015-12-10 Thread Osma Suominen


Hi,

While trying to find a query that works and performs well enough I 
noticed that this query:


PREFIX skos: 
PREFIX text: 

SELECT *
WHERE {
  GRAPH ?graph {
?s text:query 'musiikkikasv*' .
  }
}
VALUES ?graph {  }

when there are any potential results, produces this error:

Error 500: Attempt to reassign '?graph' from 
'' to ''



I guess this is a bug related to jena-text, since a basic graph pattern 
instead of the text:query pattern works.


If I change ?graph to the actual URI and remove the VALUES clause, then 
there is no error.


This also happens with 1.3.0 so this is not a new bug.

-Osma



Fuseki - version 1.3.1-SNAPSHOT (Build date: 2015-12-06T09:53:42+)

10.12.2015, 15:14, Osma Suominen kirjoitti:

Hi Andy!

I'm very sorry, I've done some testing on intermediate versions
(particularly as I was developing the customizable jena-text analyzer)
but apparently I hadn't tried this particular type of query where the
text condition is outside the GRAPH block. We use them in only in a
special case situation (global search across many SKOS vocabularies) in
the Skosmos application.

I retract my -1 vote. As you say, the vote should be about doing the
release process properly, not the technical side.

I'm still trying to understand the problem. I've tested the Join flags
but I haven't been able to produce any difference. I set both flags to
true but the results were the same as before. For the shorter query,
?label remains unbound and the query takes 400-600 ms.

 From your newer message:

Simpler query:

PREFIX  : 
PREFIX  rdfs: 

SELECT  *
WHERE
  { ?s  :p  ?literal
GRAPH :g
  { ?s  rdfs:label  ?label
FILTER ( ?label = ?literal )
  }
  }

Note also putting the text:query inside {} makes things worse.  It
isolates that part

In this case the ?literal in the FILTER is out of scope of the basic
graph pattern it is defined in.


Right, thanks, I think I now understand what is happening.

Is there a way to rewrite that query so that ?literal would be in scope
for the FILTER, while still keeping the first pattern (?s :p ?literal)
outside the GRAPH block, i.e. targeting the default graph?

I'm willing to rewrite the queries in my application so that they work
with the current ARQ. So far I just haven't found a way to do this:

1. make a jena-text query *without any graph*
2. using bindings from the results of that query, match additional
patterns from specific graphs

-Osma




10.12.2015, 13:26, Andy Seaborne kirjoitti:

Hi Osma,

The primary purpose of the vote is to verify that the release process
has been executed correctly.  A majority and 3 of PMC votes are needed
to show that the release meets the requirements for a release.

I signalled a possible release last month and got a positive response
from you about proceeding.  There are several new features in this
release and it would be good to get those out to people.

Whether a release meets technical goals is a separate matter.

If this is a simple fix, then I'm willing to redo the release but to
quite clear that is not because it fails the release criteria but
because I, not as an release manager, want to get useful code to the
public.

I think if we make the vote the start of checking months of changes,
then we'd never release anything.  There have been builds for some time.

A possible change was JENA-1023 and that was in September.  There is a
flag in class "Join" to control the join strategy.  Please try that (it
needs a rebuild as it's a private static final).

 Andy

http://www.apache.org/dev/release.html#approving-a-release

PS can you use Fuseki 2? (it will not make a performance difference, it
is better code)

On 10/12/15 09:57, Osma Suominen wrote:

On 08/12/15 13:56, Andy Seaborne wrote:

Hi,

Here is a vote on a release of Jena 3.0.1 with Fuseki 2.3.1 and Fuseki
1.3.1.


-1.

We installed Fuseki 1.3.1-SNAPSHOT 2015-12-07T14:05:00+ on our dev
server today. The query below now takes more than 100 seconds. With
1.3.0 it takes about 2.5 seconds. The configuration and databases are
the same.

I'll try to investigate further and isolate a more minimal example. I
just wanted to raise this ASAP.

-Osma


PREFIX owl: 
PREFIX rdf: 
PREFIX skos: 
PREFIX isothes: 
PREFIX text: 
PREFIX cn: 
PREFIX lapponica: 

SELECT DISTINCT ?s ?label ?plabel ?alabel ?hlabel ?graph
(GROUP_CONCAT(DISTINCT ?type) as ?types)

WHERE {
  VALUES (?prop) { (skos:prefLabel) (skos:altLabel) (skos:hiddenLabel) }
  { (?s ?score ?literal) text:query (?prop 'musiikki*'  10)

Re: A release?

2015-12-10 Thread Andy Seaborne


On 10/12/15 13:31, A. Soroka wrote:

To the first question, I think the answer is yes. It was very much my intention 
that TupleTable and its subtypes would provide opportunity to explore different 
useful structures (e.g. Claude Warren’s ideas about Bloom filters). A 
[Triple|Quad]Table that uses ordinary maps/structures in the same way as the 
current impl uses persistent structures should be very easy. Would you like me 
to cut such classes to have them available for non-transactional cases?

I’m not quite sure what your last sentence means; is it about the semantics of 
the factory methods?


There are 4 factory methods in each factory

* DatasetFactory.create()
The new place for in-memory, non-transactional dataset with graph-copy 
semantics.  Currently, it is a general dataset with "add graph" 
overridden to do a copy-in.


* DatasetFactory.createTxnMem()
The new place for in-memory, transactional dataset (with graph-copy 
semantics).


* DatasetFactory.createMem()
The old place for in-memory datasets - goes to createGeneral()
Deprecated because if replaced by create() then details have changed.

* DatasetFactory.createGeneral()
The new place for general datasets.

   Andy



---
A. Soroka
The University of Virginia Library


On Dec 10, 2015, at 8:15 AM, Andy Seaborne  wrote:

On 09/12/15 21:00, A. Soroka wrote:

Cool. The extension points are basically TripleTable and QuadTable, because of 
the constructor DatasetGraphInMemory(QuadTable, TripleTable). Someone could 
offer their own impls and use that (public) constructor.


Does that mean it would be easy to do a non-transactional version, that used 
hash maps (or used hash maps at the top level at least)?

That would make an excellent performance comparison.

If it makes a difference, it can the implementation for Dataset(Graph)Factory.create() 
and have the copy-in semantics for "add graph".

Andy

Re: A release?

2015-12-10 Thread A. Soroka

To the first question, I think the answer is yes. It was very much my intention 
that TupleTable and its subtypes would provide opportunity to explore different 
useful structures (e.g. Claude Warren’s ideas about Bloom filters). A 
[Triple|Quad]Table that uses ordinary maps/structures in the same way as the 
current impl uses persistent structures should be very easy. Would you like me 
to cut such classes to have them available for non-transactional cases?

I’m not quite sure what your last sentence means; is it about the semantics of 
the factory methods?

---
A. Soroka
The University of Virginia Library

> On Dec 10, 2015, at 8:15 AM, Andy Seaborne  wrote:
> 
> On 09/12/15 21:00, A. Soroka wrote:
>> Cool. The extension points are basically TripleTable and QuadTable, because 
>> of the constructor DatasetGraphInMemory(QuadTable, TripleTable). Someone 
>> could offer their own impls and use that (public) constructor.
> 
> Does that mean it would be easy to do a non-transactional version, that used 
> hash maps (or used hash maps at the top level at least)?
> 
> That would make an excellent performance comparison.
> 
> If it makes a difference, it can the implementation for 
> Dataset(Graph)Factory.create() and have the copy-in semantics for "add graph".
> 
>   Andy

Re: per-graph locking for dataset?

2015-12-10 Thread Andy Seaborne


On 09/12/15 13:22, A. Soroka wrote:

I now understand a little what I did not understand at all a few
months ago: how very hard the MRMW problem for RDF datasets is.


:-)


So
I’ve been casting about for some simple ways to deliver cheap and
very limited forms of MRMW that might provide some “bang for the
buck” for Jena users. One to which I keep coming back is the idea of
a dataset with per-graph transaction locking.


That might combine well with using the Graph Store Protocol for graph 
management where default union graph is common.


Another locking strategy is "graph node" i.e. a subject-in-a-graph and 
all its in and out links.  Then it's MW when working on different parts 
of a graph.  Different characteristics.



In other words, a
dataset wherein each named graph has a SW lock and the dataset as a
whole can support MRMW, as long as every writer is working in a
different graph.


What isolation levels do you want to support?  With MW, this now matters.

If it is "read committed" even BGPs are unstable, not if it's SW per 
graph though a variation that is unstable is:


SELECT * {
GRAPH  { ... }
GRAPH  { ... }
}

and also default union graph.

Counting and aggregates generally, can yield answers that never exist in 
any snapshot of the whole database.


That's not to say it's a bad idea - but that what "it" is matters.


Some examples of where this could be helpful:

* Linked Data persistence backends in which the graph about each
HTTP-accessible resource is stored in a separate named graph.


SPARQL graph Store Protocol.


* Fast loading of quads from a sorted file (using multiple cursors).


Different problem?  That's threading inside a single SW?


* Persistence backends that use RDF (like the one that Claude
recently mentioned on users@) if they can be configured to take
advantage of named graphs.

Does this sound like it would be useful enough for me to spend some
time working out a design (after finishing what’s needed to
RC-release the MR+SW in-memory dataset)? I know we can never be sure
about what users will find handy until they start relying on it and
praise it and complain about it… {grin}

--- A. Soroka The University of Virginia Library



Andy

Re: A release?

2015-12-10 Thread Andy Seaborne


On 09/12/15 21:00, A. Soroka wrote:

Cool. The extension points are basically TripleTable and QuadTable, because of 
the constructor DatasetGraphInMemory(QuadTable, TripleTable). Someone could 
offer their own impls and use that (public) constructor.


Does that mean it would be easy to do a non-transactional version, that 
used hash maps (or used hash maps at the top level at least)?


That would make an excellent performance comparison.

If it makes a difference, it can the implementation for 
Dataset(Graph)Factory.create() and have the copy-in semantics for "add 
graph".


Andy

Re: [] Release Jena 3.0.1 and Fuseki 2.3.1

2015-12-10 Thread Osma Suominen


Hi Andy!

I'm very sorry, I've done some testing on intermediate versions 
(particularly as I was developing the customizable jena-text analyzer) 
but apparently I hadn't tried this particular type of query where the 
text condition is outside the GRAPH block. We use them in only in a 
special case situation (global search across many SKOS vocabularies) in 
the Skosmos application.


I retract my -1 vote. As you say, the vote should be about doing the 
release process properly, not the technical side.


I'm still trying to understand the problem. I've tested the Join flags 
but I haven't been able to produce any difference. I set both flags to 
true but the results were the same as before. For the shorter query, 
?label remains unbound and the query takes 400-600 ms.


From your newer message:

Simpler query:

PREFIX  : 
PREFIX  rdfs: 

SELECT  *
WHERE
  { ?s  :p  ?literal
GRAPH :g
  { ?s  rdfs:label  ?label
FILTER ( ?label = ?literal )
  }
  }

Note also putting the text:query inside {} makes things worse.  It isolates 
that part

In this case the ?literal in the FILTER is out of scope of the basic graph 
pattern it is defined in.


Right, thanks, I think I now understand what is happening.

Is there a way to rewrite that query so that ?literal would be in scope 
for the FILTER, while still keeping the first pattern (?s :p ?literal) 
outside the GRAPH block, i.e. targeting the default graph?


I'm willing to rewrite the queries in my application so that they work 
with the current ARQ. So far I just haven't found a way to do this:


1. make a jena-text query *without any graph*
2. using bindings from the results of that query, match additional 
patterns from specific graphs


-Osma




10.12.2015, 13:26, Andy Seaborne kirjoitti:

Hi Osma,

The primary purpose of the vote is to verify that the release process
has been executed correctly.  A majority and 3 of PMC votes are needed
to show that the release meets the requirements for a release.

I signalled a possible release last month and got a positive response
from you about proceeding.  There are several new features in this
release and it would be good to get those out to people.

Whether a release meets technical goals is a separate matter.

If this is a simple fix, then I'm willing to redo the release but to
quite clear that is not because it fails the release criteria but
because I, not as an release manager, want to get useful code to the
public.

I think if we make the vote the start of checking months of changes,
then we'd never release anything.  There have been builds for some time.

A possible change was JENA-1023 and that was in September.  There is a
flag in class "Join" to control the join strategy.  Please try that (it
needs a rebuild as it's a private static final).

 Andy

http://www.apache.org/dev/release.html#approving-a-release

PS can you use Fuseki 2? (it will not make a performance difference, it
is better code)

On 10/12/15 09:57, Osma Suominen wrote:

On 08/12/15 13:56, Andy Seaborne wrote:

Hi,

Here is a vote on a release of Jena 3.0.1 with Fuseki 2.3.1 and Fuseki
1.3.1.


-1.

We installed Fuseki 1.3.1-SNAPSHOT 2015-12-07T14:05:00+ on our dev
server today. The query below now takes more than 100 seconds. With
1.3.0 it takes about 2.5 seconds. The configuration and databases are
the same.

I'll try to investigate further and isolate a more minimal example. I
just wanted to raise this ASAP.

-Osma


PREFIX owl: 
PREFIX rdf: 
PREFIX skos: 
PREFIX isothes: 
PREFIX text: 
PREFIX cn: 
PREFIX lapponica: 

SELECT DISTINCT ?s ?label ?plabel ?alabel ?hlabel ?graph
(GROUP_CONCAT(DISTINCT ?type) as ?types)

WHERE {
  VALUES (?prop) { (skos:prefLabel) (skos:altLabel) (skos:hiddenLabel) }
  { (?s ?score ?literal) text:query (?prop 'musiikki*'  10) }
  GRAPH ?graph {
   { ?s rdf:type  } UNION {
?s a isothes:ConceptGroup }
   {
?s rdf:type ?type .
OPTIONAL {
 ?s skos:prefLabel ?label .
 FILTER (langMatches(lang(?label), lang(?literal)))
}
   }
   FILTER NOT EXISTS { ?s owl:deprecated true }
  }
  BIND(IF(?prop = skos:prefLabel && ?literal != ?label, ?literal,
?unbound) as ?plabel)
  BIND(IF(?prop = skos:altLabel, ?literal, ?unbound) as ?alabel)
  BIND(IF(?prop = skos:hiddenLabel, ?literal, ?unbound) as ?hlabel)
}
GROUP BY ?literal ?s ?label ?plabel ?alabel ?hlabel ?graph ?prop
ORDER BY lcase(str(?literal)) lang(?literal) ?graph
VALUES (?graph) { ()
()
()
() ()
(

[jira] [Created] (JENA-1082) Add to org.apache.jena.rdf.model.ModelCon interface a listLiteralStatements method that accepts ints.

2015-12-10 Thread JIRA

Ramiro Pereira de Magalhães created JENA-1082:
-

 Summary: Add to org.apache.jena.rdf.model.ModelCon interface a 
listLiteralStatements method that accepts ints.
 Key: JENA-1082
 URL: https://issues.apache.org/jira/browse/JENA-1082
 Project: Apache Jena
  Issue Type: Bug
  Components: Base
Affects Versions: Jena 3.0.0
Reporter: Ramiro Pereira de Magalhães


Add to org.apache.jena.rdf.model.ModelCon interface a {{StmtIterator 
listLiteralStatements(Resource subject, Property predicate, int object );}} 
method.

Implement such method in classes that implement such interface. This method 
should be able to list literal integer statements, like the other 
listLiteralStatement methods do to other types.



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

Re: [] Release Jena 3.0.1 and Fuseki 2.3.1

2015-12-10 Thread Andy Seaborne


On 10/12/15 11:25, Osma Suominen wrote:

On 10/12/15 13:21, Andy Seaborne wrote:

What happens if you put the text:query should be inside the GRAPH?


That sort of works for this case, i.e. the query becomes fast (~20ms)
and I get a result with ?label bound, as with Fuseki 1.3.0.

But in the original query I'm deliberately placing the text:query
outside the GRAPH because I want to target all graphs, not just a
specific one. (the jena-text index is graph-aware)

-Osma



This is not related to the performance issue although work in that area 
seems to have fixed an unknown old bug.


Simpler query:

PREFIX  : 
PREFIX  rdfs: 

SELECT  *
WHERE
  { ?s  :p  ?literal
GRAPH :g
  { ?s  rdfs:label  ?label
FILTER ( ?label = ?literal )
  }
  }

Note also putting the text:query inside {} makes things worse.  It 
isolates that part


In this case the ?literal in the FILTER is out of scope of the basic 
graph pattern it is defined in.


Algebra:

(prefix ((: )
 (rdfs: ))
  (join
(bgp (triple ?s :p ?literal))
(graph :g
  (filter (= ?label ?literal)
(bgp (triple ?s rdfs:label ?label))

In this simpler case there is even an optimizer step that spots that and 
replaces the inner {} by the empty table because the inner {} block 
always evaluates to empty.


(prefix ((: )
 (rdfs: ))
  (sequence
(bgp (triple ?s :p ?literal))
(table empty)))

It is the same effect as FILTER inside {}

SELECT  *
WHERE
  { ?s  :p  ?literal
{ FILTER ( ?literal = "WORD" ) }
  }
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  (join
(bgp (triple ?s :p ?literal))
(filter (= ?literal "WORD")
  (table unit)))

Andy

Re: [] Release Jena 3.0.1 and Fuseki 2.3.1

2015-12-10 Thread Andy Seaborne


Hi Osma,

The primary purpose of the vote is to verify that the release process 
has been executed correctly.  A majority and 3 of PMC votes are needed 
to show that the release meets the requirements for a release.


I signalled a possible release last month and got a positive response 
from you about proceeding.  There are several new features in this 
release and it would be good to get those out to people.


Whether a release meets technical goals is a separate matter.

If this is a simple fix, then I'm willing to redo the release but to 
quite clear that is not because it fails the release criteria but 
because I, not as an release manager, want to get useful code to the public.


I think if we make the vote the start of checking months of changes, 
then we'd never release anything.  There have been builds for some time.


A possible change was JENA-1023 and that was in September.  There is a 
flag in class "Join" to control the join strategy.  Please try that (it 
needs a rebuild as it's a private static final).


Andy

http://www.apache.org/dev/release.html#approving-a-release

PS can you use Fuseki 2? (it will not make a performance difference, it 
is better code)


On 10/12/15 09:57, Osma Suominen wrote:

On 08/12/15 13:56, Andy Seaborne wrote:

Hi,

Here is a vote on a release of Jena 3.0.1 with Fuseki 2.3.1 and Fuseki
1.3.1.


-1.

We installed Fuseki 1.3.1-SNAPSHOT 2015-12-07T14:05:00+ on our dev
server today. The query below now takes more than 100 seconds. With
1.3.0 it takes about 2.5 seconds. The configuration and databases are
the same.

I'll try to investigate further and isolate a more minimal example. I
just wanted to raise this ASAP.

-Osma


PREFIX owl: 
PREFIX rdf: 
PREFIX skos: 
PREFIX isothes: 
PREFIX text: 
PREFIX cn: 
PREFIX lapponica: 

SELECT DISTINCT ?s ?label ?plabel ?alabel ?hlabel ?graph
(GROUP_CONCAT(DISTINCT ?type) as ?types)

WHERE {
  VALUES (?prop) { (skos:prefLabel) (skos:altLabel) (skos:hiddenLabel) }
  { (?s ?score ?literal) text:query (?prop 'musiikki*'  10) }
  GRAPH ?graph {
   { ?s rdf:type  } UNION {
?s a isothes:ConceptGroup }
   {
?s rdf:type ?type .
OPTIONAL {
 ?s skos:prefLabel ?label .
 FILTER (langMatches(lang(?label), lang(?literal)))
}
   }
   FILTER NOT EXISTS { ?s owl:deprecated true }
  }
  BIND(IF(?prop = skos:prefLabel && ?literal != ?label, ?literal,
?unbound) as ?plabel)
  BIND(IF(?prop = skos:altLabel, ?literal, ?unbound) as ?alabel)
  BIND(IF(?prop = skos:hiddenLabel, ?literal, ?unbound) as ?hlabel)
}
GROUP BY ?literal ?s ?label ?plabel ?alabel ?hlabel ?graph ?prop
ORDER BY lcase(str(?literal)) lang(?literal) ?graph
VALUES (?graph) { ()
()
()
() ()
() ()
()
() ()
() ()
() ()
() ()
()
() ()
() ()
() ()
() ()
()
()
()
() ()
() ()
() ()
() ()
() () }

Re: [] Release Jena 3.0.1 and Fuseki 2.3.1

2015-12-10 Thread Osma Suominen


On 10/12/15 13:21, Andy Seaborne wrote:

What happens if you put the text:query should be inside the GRAPH?


That sort of works for this case, i.e. the query becomes fast (~20ms) 
and I get a result with ?label bound, as with Fuseki 1.3.0.


But in the original query I'm deliberately placing the text:query 
outside the GRAPH because I want to target all graphs, not just a 
specific one. (the jena-text index is graph-aware)


-Osma

--
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Kaikukatu 4)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
osma.suomi...@helsinki.fi
http://www.nationallibrary.fi

Re: [] Release Jena 3.0.1 and Fuseki 2.3.1

2015-12-10 Thread Andy Seaborne


On 10/12/15 11:21, Andy Seaborne wrote:

What happens if you put the text:query should be inside the GRAPH?


s/should be //





 Andy

On 10/12/15 10:57, Osma Suominen wrote:

On 10/12/15 11:57, Osma Suominen wrote:


I'll try to investigate further and isolate a more minimal example. I
just wanted to raise this ASAP.


The query execution order seems to have changed for this kind of query:

PREFIX skos: 
PREFIX text: 

SELECT *
WHERE {
   (?s ?score ?literal) text:query 'musiikkikasv*' .
   GRAPH  {
 OPTIONAL {
   ?s skos:prefLabel ?label .
   FILTER (lang(?label) = lang(?literal))
 }
   }
}


(The YSO data that I have in the named graph is available at
http://finto.fi/rest/v1/yso/data if you need it)

With Fuseki 1.3.0, I get a single result row with ?label bound to
"musiikkikasvatus"@fi and it takes about 40 ms.

With Fuseki 1.3.1-SNAPSHOT I get a result with ?label unbound and it
takes about 600 ms.

My guess is that the new version is evaluating the GRAPH block first,
when ?literal is still unbound. The old version performed the text:query
part first, which is what I'd expect.

-Osma

Re: [] Release Jena 3.0.1 and Fuseki 2.3.1

2015-12-10 Thread Andy Seaborne


What happens if you put the text:query should be inside the GRAPH?

Andy

On 10/12/15 10:57, Osma Suominen wrote:

On 10/12/15 11:57, Osma Suominen wrote:


I'll try to investigate further and isolate a more minimal example. I
just wanted to raise this ASAP.


The query execution order seems to have changed for this kind of query:

PREFIX skos: 
PREFIX text: 

SELECT *
WHERE {
   (?s ?score ?literal) text:query 'musiikkikasv*' .
   GRAPH  {
 OPTIONAL {
   ?s skos:prefLabel ?label .
   FILTER (lang(?label) = lang(?literal))
 }
   }
}


(The YSO data that I have in the named graph is available at
http://finto.fi/rest/v1/yso/data if you need it)

With Fuseki 1.3.0, I get a single result row with ?label bound to
"musiikkikasvatus"@fi and it takes about 40 ms.

With Fuseki 1.3.1-SNAPSHOT I get a result with ?label unbound and it
takes about 600 ms.

My guess is that the new version is evaluating the GRAPH block first,
when ?literal is still unbound. The old version performed the text:query
part first, which is what I'd expect.

-Osma

Re: [VOTE] Release Jena 3.0.1 and Fuseki 2.3.1

2015-12-10 Thread Osma Suominen


On 10/12/15 11:57, Osma Suominen wrote:


I'll try to investigate further and isolate a more minimal example. I
just wanted to raise this ASAP.


The query execution order seems to have changed for this kind of query:

PREFIX skos: 
PREFIX text: 

SELECT *
WHERE {
  (?s ?score ?literal) text:query 'musiikkikasv*' .
  GRAPH  {
OPTIONAL {
  ?s skos:prefLabel ?label .
  FILTER (lang(?label) = lang(?literal))
}
  }
}


(The YSO data that I have in the named graph is available at 
http://finto.fi/rest/v1/yso/data if you need it)


With Fuseki 1.3.0, I get a single result row with ?label bound to 
"musiikkikasvatus"@fi and it takes about 40 ms.


With Fuseki 1.3.1-SNAPSHOT I get a result with ?label unbound and it 
takes about 600 ms.


My guess is that the new version is evaluating the GRAPH block first, 
when ?literal is still unbound. The old version performed the text:query 
part first, which is what I'd expect.


-Osma


--
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Kaikukatu 4)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
osma.suomi...@helsinki.fi
http://www.nationallibrary.fi

Re: [jira] [Commented] (JENA-955) Review security documentation

2015-12-10 Thread Bruno P. Kinoshita

Thanks Claude, I tried using Jena Permissions for the permissions system, and 
jena-permissions for the maven artifact or jar. Also found two trivial typos 
while reading the docs, one package that I believe could be fixed in the 
migration guide, and learned a lot reviewing it :o)
Tomorrow will build Jena latest from work to test it on a Mac OS and on an 
Ubuntu. Will try to play with the permissions system, and also cast my vote on 
the new release.
See commit here https://svn.apache.org/r1719046, feel free to amend any 
inconsistencies.
CheersBruno

  From: Claude Warren 
 To: dev@jena.apache.org 
 Sent: Wednesday, 9 December 2015 8:29 PM
 Subject: Re: [jira] [Commented] (JENA-955) Review security documentation

I hadn't checked but I was thinking that Jena Permissions is the name of
the package while jena-permissions is the Maven artifact ID.  I tend to use
them interchangeably but perhaps the documentation should use the name
except where referencing the maven artifact id or the jar.  Feel free to
make the changes.

On Wed, Dec 9, 2015 at 12:37 AM, Bruno P. Kinoshita (JIRA) 
wrote:

>
>    [
> https://issues.apache.org/jira/browse/JENA-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15047783#comment-15047783
> ]
>
> Bruno P. Kinoshita commented on JENA-955:
> -
>
> Hi Claude!
>
> Looking great, thanks!
>
> The only minor issue I noted is that the title uses "Jena Permissions",
> then in the first paragraph it says "Jena-permissions", but in other pages
> (eg Assembler) it says "Jena Permissions in the first paragraph.
>
> Should we refer to the module as Jena Permissions, Jena-permissions or
> both interchangeably?
>
> > Review security documentation
> > -
> >
> >                Key: JENA-955
> >                URL: https://issues.apache.org/jira/browse/JENA-955
> >            Project: Apache Jena
> >          Issue Type: Documentation
> >          Components: Security
> >            Reporter: Bruno P. Kinoshita
> >            Assignee: Claude Warren
> >            Priority: Trivial
> >              Labels: documentation
> >            Fix For: Jena 3.0.0
> >
> >
> > Review the current documentation for the security module, and check if
> there's any enhancements, or if anything changed after the Jena3 branch.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>

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

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

Re: [VOTE] Release Jena 3.0.1 and Fuseki 2.3.1

2015-12-10 Thread Osma Suominen


On 08/12/15 13:56, Andy Seaborne wrote:

Hi,

Here is a vote on a release of Jena 3.0.1 with Fuseki 2.3.1 and Fuseki
1.3.1.


-1.

We installed Fuseki 1.3.1-SNAPSHOT 2015-12-07T14:05:00+ on our dev 
server today. The query below now takes more than 100 seconds. With 
1.3.0 it takes about 2.5 seconds. The configuration and databases are 
the same.


I'll try to investigate further and isolate a more minimal example. I 
just wanted to raise this ASAP.


-Osma


PREFIX owl: 
PREFIX rdf: 
PREFIX skos: 
PREFIX isothes: 
PREFIX text: 
PREFIX cn: 
PREFIX lapponica: 

SELECT DISTINCT ?s ?label ?plabel ?alabel ?hlabel ?graph 
(GROUP_CONCAT(DISTINCT ?type) as ?types)


WHERE {
 VALUES (?prop) { (skos:prefLabel) (skos:altLabel) (skos:hiddenLabel) }
 { (?s ?score ?literal) text:query (?prop 'musiikki*'  10) }
 GRAPH ?graph {
  { ?s rdf:type  } UNION { 
?s a isothes:ConceptGroup }

  {
   ?s rdf:type ?type .
   OPTIONAL {
?s skos:prefLabel ?label .
FILTER (langMatches(lang(?label), lang(?literal)))
   }
  }
  FILTER NOT EXISTS { ?s owl:deprecated true }
 }
 BIND(IF(?prop = skos:prefLabel && ?literal != ?label, ?literal, 
?unbound) as ?plabel)

 BIND(IF(?prop = skos:altLabel, ?literal, ?unbound) as ?alabel)
 BIND(IF(?prop = skos:hiddenLabel, ?literal, ?unbound) as ?hlabel)
}
GROUP BY ?literal ?s ?label ?plabel ?alabel ?hlabel ?graph ?prop
ORDER BY lcase(str(?literal)) lang(?literal) ?graph
VALUES (?graph) { () 
() 
() 
() () 
() () 
() 
() () 
() () 
() () 
() () 
() 
() () 
() () 
() () 
() () 
() 
() 
() 
() () 
() () 
() () 
() () 
() () }






--
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Kaikukatu 4)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
osma.suomi...@helsinki.fi
http://www.nationallibrary.fi

[jira] [Commented] (JENA-955) Review security documentation

2015-12-10 Thread ASF subversion and git services (JIRA)


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

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

Commit 1719046 from [~kinow] in branch 'site/trunk'
[ https://svn.apache.org/r1719046 ]

Reviewing permissions changes as per JENA-955. Minor typos, removed duplicate 
spaces, fixed one package name, and used Jena Permissions for the permissions 
system, and jena-permissions for the artifact

> Review security documentation
> -
>
> Key: JENA-955
> URL: https://issues.apache.org/jira/browse/JENA-955
> Project: Apache Jena
>  Issue Type: Documentation
>  Components: Security
>Reporter: Bruno P. Kinoshita
>Assignee: Claude Warren
>Priority: Trivial
>  Labels: documentation
> Fix For: Jena 3.0.0
>
>
> Review the current documentation for the security module, and check if 
> there's any enhancements, or if anything changed after the Jena3 branch.



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

38 matches

Mail list logo