You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2015/12/08 12:56:25 UTC
[VOTE] Release Jena 3.0.1 and Fuseki 2.3.1
Hi,
Here is a vote on a release of Jena 3.0.1 with Fuseki 2.3.1 and Fuseki
1.3.1.
This is the first proposed candidate for this release.
It includes:
* In-memory txn dataset RC (Adam Soroka)
http://jena.staging.apache.org/documentation/rdf/datasets.html
* Quads (Qihong Lin)
http://jena.staging.apache.org/documentation/query/construct-quad.html
* configurable lucene analyzers (Osma Suominen)
http://jena.staging.apache.org/documentation/query/text-query.html#configuring-an-analyzer
* Improved start-up and configuration to wire the jars together
and other code can join in.
* general maintenance: about 74 JIRA.
Dependency changes:
Added:
com.github.andrewoma.dexx::dexx-collections:0.2
(for testing)
com.jayway.awaitility:awaitility:1.6.4
Updates:
jsonld-java : 0.5.1 -> 0.7.0
httpcore 4.2.5 -> 4.2.6
Everyone, not just committers, is invited to test and vote.
Staging repository:
https://repository.apache.org/content/repositories/orgapachejena-1010/
Proposed dist/ area:
https://dist.apache.org/repos/dist/dev/jena/
Keys:
https://svn.apache.org/repos/asf/jena/dist/KEYS
Git commit (browser URL):
http://git-wip-us.apache.org/repos/asf/jena/commit/499317ad
Git Commit Hash:
499317adff7902195ae4fa87254d6c176b6fb1d6
Git Commit Tag:
jena-3.0.1-rc1
Please vote to approve this release:
[ ] +1 Approve the release
[ ] 0 Don't care
[ ] -1 Don't release, because ...
This vote will be open to at least the end of
Friday, 11th December 2015, 23:59 UTC
(72 hours from the same hour tonight UTC).
If you expect to check the release but the 72 hour limit does not work
for you, please email within the schedule above with an expected time
and we can extend the vote period.
Thanks,
Andy
Checking needed:
+ does everything work on Linux?
+ does everything work on MS Windows?
+ does everything work on OS X?
+ are the GPG signatures fine?
+ are the checksums correct?
+ is there a source archive?
+ can the source archive really be built?
+ is there a correct LICENSE and NOTICE file in each artifact
(both source and binary artifacts)?
+ does the NOTICE file contain all necessary attributions?
+ have any licenses of dependencies changed due to upgrades?
if so have LICENSE and NOTICE been upgraded appropriately?
+ does the tag/commit in the SCM contain reproducible sources?
[RESULT] [VOTE] Release Jena 3.0.1 and Fuseki 2.3.1
Posted by Andy Seaborne <an...@apache.org>.
The vote passes with 3 +1 and not other votes
+1:
Bruno
Osma
Andy
I'll push the bits out, let the mirrors sync, then announce on users@.
Andy
On 08/12/15 11: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.
>
> This is the first proposed candidate for this release.
>
> It includes:
>
> * In-memory txn dataset RC (Adam Soroka)
>
> http://jena.staging.apache.org/documentation/rdf/datasets.html
>
> * Quads (Qihong Lin)
>
> http://jena.staging.apache.org/documentation/query/construct-quad.html
>
> * configurable lucene analyzers (Osma Suominen)
>
> http://jena.staging.apache.org/documentation/query/text-query.html#configuring-an-analyzer
>
>
> * Improved start-up and configuration to wire the jars together
> and other code can join in.
>
> * general maintenance: about 74 JIRA.
>
> Dependency changes:
>
> Added:
> com.github.andrewoma.dexx::dexx-collections:0.2
>
> (for testing)
> com.jayway.awaitility:awaitility:1.6.4
>
> Updates:
> jsonld-java : 0.5.1 -> 0.7.0
> httpcore 4.2.5 -> 4.2.6
>
>
>
>
> Everyone, not just committers, is invited to test and vote.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachejena-1010/
>
> Proposed dist/ area:
> https://dist.apache.org/repos/dist/dev/jena/
>
> Keys:
> https://svn.apache.org/repos/asf/jena/dist/KEYS
>
> Git commit (browser URL):
> http://git-wip-us.apache.org/repos/asf/jena/commit/499317ad
>
> Git Commit Hash:
> 499317adff7902195ae4fa87254d6c176b6fb1d6
>
> Git Commit Tag:
> jena-3.0.1-rc1
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] 0 Don't care
> [ ] -1 Don't release, because ...
>
> This vote will be open to at least the end of
>
> Friday, 11th December 2015, 23:59 UTC
>
> (72 hours from the same hour tonight UTC).
>
> If you expect to check the release but the 72 hour limit does not work
> for you, please email within the schedule above with an expected time
> and we can extend the vote period.
>
> Thanks,
>
> Andy
>
> Checking needed:
>
> + does everything work on Linux?
> + does everything work on MS Windows?
> + does everything work on OS X?
> + are the GPG signatures fine?
> + are the checksums correct?
> + is there a source archive?
> + can the source archive really be built?
> + is there a correct LICENSE and NOTICE file in each artifact
> (both source and binary artifacts)?
> + does the NOTICE file contain all necessary attributions?
> + have any licenses of dependencies changed due to upgrades?
> if so have LICENSE and NOTICE been upgraded appropriately?
> + does the tag/commit in the SCM contain reproducible sources?
Re: [VOTE] Release Jena 3.0.1 and Fuseki 2.3.1
Posted by "Bruno P. Kinoshita" <ki...@apache.org>.
+1 binding
Build successful with
Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06; 2015-04-22T23:57:37+12:00)Maven home: /opt/apache-maven-3.3.3Java version: 1.8.0_66, vendor: Oracle CorporationJava home: /usr/lib/jvm/java-8-oracle/jreDefault locale: en_NZ, platform encoding: UTF-8OS name: "linux", version: "3.16.0-50-generic", arch: "amd64", family: "unix"
and
Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06; 2015-04-22T23:57:37+12:00)Maven home: /usr/local/Cellar/maven/3.3.3/libexecJava version: 1.8.0_60, vendor: Oracle CorporationJava home: /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jreDefault locale: en_US, platform encoding: UTF-8OS name: "mac os x", version: "10.10.5", arch: "x86_64", family: "mac"
and
Apache Maven 3.0.5Maven home: /usr/share/mavenJava version: 1.8.0_66, vendor: Oracle CorporationJava home: /usr/lib/jvm/java-8-oracle/jreDefault locale: en_NZ, platform encoding: UTF-8OS name: "linux", version: "3.19.0-39-generic", arch: "amd64", family: "unix"
Grabbed fuseki war from the last environment build, and deployed to an Apache Tomcat 9.0.0.M1 (also in Ubuntu 14.04.3 LTS server, with Java 8) and it worked fine. Tried connecting SKOSMOS, but had some problems related to SKOSMOS and my Ubuntu + PHP 5.5.
Everything seems to be working correctly. Executed some code that was doing some basic RDF in Java, and everything is looking good. Also tried created an in-memory dataset and it also worked with no problems.
Thanks a lot for the hard work, and sorry for not being of much help in the last months :o) Will play more with the new version once it is released, and will review the documentation, in special Jena Text, Jena Permissions and Jena Elephas, as I think I will use these modules in a POC in the next weeks.
CheersBruno
From: Andy Seaborne <an...@apache.org>
To: dev@jena.apache.org
Sent: Wednesday, 9 December 2015 12:56 AM
Subject: [VOTE] Release Jena 3.0.1 and Fuseki 2.3.1
Hi,
Here is a vote on a release of Jena 3.0.1 with Fuseki 2.3.1 and Fuseki
1.3.1.
This is the first proposed candidate for this release.
It includes:
* In-memory txn dataset RC (Adam Soroka)
http://jena.staging.apache.org/documentation/rdf/datasets.html
* Quads (Qihong Lin)
http://jena.staging.apache.org/documentation/query/construct-quad.html
* configurable lucene analyzers (Osma Suominen)
http://jena.staging.apache.org/documentation/query/text-query.html#configuring-an-analyzer
* Improved start-up and configuration to wire the jars together
and other code can join in.
* general maintenance: about 74 JIRA.
Dependency changes:
Added:
com.github.andrewoma.dexx::dexx-collections:0.2
(for testing)
com.jayway.awaitility:awaitility:1.6.4
Updates:
jsonld-java : 0.5.1 -> 0.7.0
httpcore 4.2.5 -> 4.2.6
Everyone, not just committers, is invited to test and vote.
Staging repository:
https://repository.apache.org/content/repositories/orgapachejena-1010/
Proposed dist/ area:
https://dist.apache.org/repos/dist/dev/jena/
Keys:
https://svn.apache.org/repos/asf/jena/dist/KEYS
Git commit (browser URL):
http://git-wip-us.apache.org/repos/asf/jena/commit/499317ad
Git Commit Hash:
499317adff7902195ae4fa87254d6c176b6fb1d6
Git Commit Tag:
jena-3.0.1-rc1
Please vote to approve this release:
[ ] +1 Approve the release
[ ] 0 Don't care
[ ] -1 Don't release, because ...
This vote will be open to at least the end of
Friday, 11th December 2015, 23:59 UTC
(72 hours from the same hour tonight UTC).
If you expect to check the release but the 72 hour limit does not work
for you, please email within the schedule above with an expected time
and we can extend the vote period.
Thanks,
Andy
Checking needed:
+ does everything work on Linux?
+ does everything work on MS Windows?
+ does everything work on OS X?
+ are the GPG signatures fine?
+ are the checksums correct?
+ is there a source archive?
+ can the source archive really be built?
+ is there a correct LICENSE and NOTICE file in each artifact
(both source and binary artifacts)?
+ does the NOTICE file contain all necessary attributions?
+ have any licenses of dependencies changed due to upgrades?
if so have LICENSE and NOTICE been upgraded appropriately?
+ does the tag/commit in the SCM contain reproducible sources?
Re: [VOTE] Release Jena 3.0.1 and Fuseki 2.3.1
Posted by Andy Seaborne <an...@apache.org>.
+1
To build, it is necessary to "mvn install" because of the
shaded Guava -- simply "mvn test" would work from the compiled class
files of other modules which is not how shading works.
Andy
> Dependency changes:
>
> Added:
> com.github.andrewoma.dexx::dexx-collections:0.2
>
> (for testing)
> com.jayway.awaitility:awaitility:1.6.4
>
> Updates:
> jsonld-java : 0.5.1 -> 0.7.0
> httpcore 4.2.5 -> 4.2.6
>
>
>
>
> Everyone, not just committers, is invited to test and vote.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachejena-1010/
>
> Proposed dist/ area:
> https://dist.apache.org/repos/dist/dev/jena/
>
> Keys:
> https://svn.apache.org/repos/asf/jena/dist/KEYS
>
> Git commit (browser URL):
> http://git-wip-us.apache.org/repos/asf/jena/commit/499317ad
>
> Git Commit Hash:
> 499317adff7902195ae4fa87254d6c176b6fb1d6
>
> Git Commit Tag:
> jena-3.0.1-rc1
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] 0 Don't care
> [ ] -1 Don't release, because ...
>
> This vote will be open to at least the end of
>
> Friday, 11th December 2015, 23:59 UTC
Re: text:query fails with GRAPH and VALUES Re: [] Release Jena 3.0.1
and Fuseki 2.3.1
Posted by Osma Suominen <os...@helsinki.fi>.
Oh yes, stacktrace. Here:
21:56:15 WARN [4] RC = 500 : Attempt to reassign '?graph' from
'<http://www.yso.fi/onto/yso/>' to '<http://www.yso.fi/onto/yso/>'
org.apache.jena.sparql.ARQInternalErrorException: Attempt to reassign
'?graph' from '<http://www.yso.fi/onto/yso/>' to
'<http://www.yso.fi/onto/yso/>'
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:240)
at
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
at
org.eclipse.jetty.server.nio.BlockingChannelConnector$BlockingChannelEndPoint.run(BlockingChannelConnector.java:298)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:745)
21:56:15 INFO [4] 500 Attempt to reassign '?graph' from
'<http://www.yso.fi/onto/yso/>' to '<http://www.yso.fi/onto/yso/>' (27 ms)
-Osma
10.12.2015, 18:51, Andy Seaborne kirjoitti:
> 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: <http://www.w3.org/2004/02/skos/core#>
>> PREFIX text: <http://jena.apache.org/text#>
>>
>> SELECT *
>> WHERE {
>> GRAPH ?graph {
>> ?s text:query 'musiikkikasv*' .
>> }
>> }
>> VALUES ?graph { <http://www.yso.fi/onto/yso/> }
>>
>> when there are any potential results, produces this error:
>>
>> Error 500: Attempt to reassign '?graph' from
>> '<http://www.yso.fi/onto/yso/>' to '<http://www.yso.fi/onto/yso/>'
>>
>>
>> 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+0000)
>>
>
> Stacktrace?
>
> Andy
>
>
--
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.suominen@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
Posted by Andy Seaborne <an...@apache.org>.
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: <http://www.w3.org/2004/02/skos/core#>
> PREFIX text: <http://jena.apache.org/text#>
>
> SELECT *
> WHERE {
> GRAPH ?graph {
> ?s text:query 'musiikkikasv*' .
> }
> }
> VALUES ?graph { <http://www.yso.fi/onto/yso/> }
>
> when there are any potential results, produces this error:
>
> Error 500: Attempt to reassign '?graph' from
> '<http://www.yso.fi/onto/yso/>' to '<http://www.yso.fi/onto/yso/>'
>
>
> 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+0000)
>
Stacktrace?
Andy
text:query fails with GRAPH and VALUES Re: [] Release Jena 3.0.1 and
Fuseki 2.3.1
Posted by Osma Suominen <os...@helsinki.fi>.
Hi,
While trying to find a query that works and performs well enough I
noticed that this query:
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX text: <http://jena.apache.org/text#>
SELECT *
WHERE {
GRAPH ?graph {
?s text:query 'musiikkikasv*' .
}
}
VALUES ?graph { <http://www.yso.fi/onto/yso/> }
when there are any potential results, produces this error:
Error 500: Attempt to reassign '?graph' from
'<http://www.yso.fi/onto/yso/>' to '<http://www.yso.fi/onto/yso/>'
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+0000)
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 : <http://example/>
>> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
>>
>> 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+0000 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: <http://www.w3.org/2002/07/owl#>
>>> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
>>> PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
>>> PREFIX isothes: <http://purl.org/iso25964/skos-thes#>
>>> PREFIX text: <http://jena.apache.org/text#>
>>> PREFIX cn: <http://urn.fi/URN:NBN:fi:au:cn:>
>>> PREFIX lapponica: <http://urn.fi/URN:NBN:fi:au: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*' 100000) }
>>> GRAPH ?graph {
>>> { ?s rdf:type <http://www.w3.org/2004/02/skos/core#Concept> } 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) { (<http://www.yso.fi/onto/afo/>)
>>> (<http://www.yso.fi/onto/allars/>)
>>> (<http://avoindata.fi/onto/contentType/>)
>>> (<http://avoindata.fi/onto/topic/>) (<http://urn.fi/URN:NBN:fi:au:cn:>)
>>> (<http://iconclass.org/>) (<http://cv.iptc.org/newscodes/scene/>)
>>> (<http://cv.iptc.org/newscodes/subjectcode/>)
>>> (<http://www.yso.fi/onto/juho/>) (<http://www.yso.fi/onto/jupo/>)
>>> (<http://www.yso.fi/onto/kassu/>) (<http://www.yso.fi/onto/kauno/>)
>>> (<http://www.yso.fi/onto/kito/>) (<http://www.yso.fi/onto/koko/>)
>>> (<http://www.yso.fi/onto/kto/>) (<http://www.yso.fi/onto/kulo/>)
>>> (<http://urn.fi/URN:NBN:fi:au:lapponica:>)
>>> (<http://www.yso.fi/onto/liito/>) (<http://lexvo.org/id/iso639-3/>)
>>> (<http://www.yso.fi/onto/tao/>) (<http://www.yso.fi/onto/mero/>)
>>> (<http://www.yso.fi/onto/mesh/>) (<http://metatietosanasto.fi/>)
>>> (<http://www.yso.fi/onto/musa/>) (<http://www.yso.fi/onto/muso/>)
>>> (<http://www.yso.fi/onto/okm-tieteenala/>)
>>> (<http://www.yso.fi/onto/paikat/>)
>>> (<http://www.yso.fi/onto/ponduskategorier/>)
>>> (<http://www.yso.fi/onto/pto/>) (<http://www.yso.fi/onto/puho/>)
>>> (<http://www.yso.fi/onto/sapo/>) (<http://www.yso.fi/onto/tero/>)
>>> (<http://www.yso.fi/onto/tsr/>) (<http://www.yso.fi/onto/valo/>)
>>> (<http://www.yso.fi/onto/ysa/>) (<http://www.yso.fi/onto/yso/>)
>>> (<http://aims.fao.org/aos/agrovoc/>) (<http://skos.um.es/unescothes/>) }
>>>
>>>
>>>
>>>
>>>
>>
>
>
--
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.suominen@helsinki.fi
http://www.nationallibrary.fi
Re: [] Release Jena 3.0.1 and Fuseki 2.3.1
Posted by Andy Seaborne <an...@apache.org>.
On 11/12/15 12:07, Osma Suominen wrote:
> Hi Andy!
>
> On 11/12/15 13:54, Andy Seaborne wrote:
>> On 10/12/15 20:18, Osma Suominen wrote:
>>> PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
>>> PREFIX text: <http://jena.apache.org/text#>
>>>
>>> SELECT *
>>> WHERE {
>>> GRAPH <http://www.yso.fi/onto/yso/> {
>>> GRAPH <urn:x-arq:UnionGraph> {
>>> (?s ?score ?literal) text:query 'musiikkikasv*' .
>>> }
>>> ?s skos:prefLabel ?label .
>>> FILTER (LANG(?label)=LANG(?literal))
>>> }
>>> }
>>
>> You are running with union default graph? In which case that's good.
>
> Yes, I'm using unionDefaultGraph=true.
>
>> Else use <urn:x-arq:DefaultGraph>
>
> Right.
>
>> One of my regrets in SPARQL is that you can't get back to the default
>> graph inside a GRAPH block.
>
> Exactly. That's the problem here, and the workaround requires using
> these magic ARQ graph names. Or...
>
>> The key to your query is the back that the FILTER covers the inner GRAPH.
>>
>> This should work:
>>
>> WHERE {
>> (?s ?score ?literal) text:query 'musiikkikasv*' .
>> GRAPH <http://www.yso.fi/onto/yso/> { ?s skos:prefLabel ?label . }
>> FILTER (LANG(?label)=LANG(?literal))
>> }
>>
>> and it gets optimized into a
>
> ...something missing from your sentence?
gets optimized into a stream execution.
>
> Indeed, this works. It's also faster than I expected (20ms). It appears
> that when the expression within the GRAPH block gets executed, ?s is
> already bound to a single resource (as returned by text:query).
> Otherwise the { ?s skos:prefLabel ?label } pattern would have to iterate
> over many potential solutions, which would have taken more time.
which is why it hits the GRAPH with ?s bound.
What the optimizer has done is notice that the bottom up execution (the
correct form) has the same output as streaming. That FILTER inside the
GRAPH would block that because streaming changes variable scope - the
?literal in this case.
In the algebra from qoarse look for "sequence" (joins does index join,
global scope variables) and "conditional" (same, expect leftjoins).
>
>> You had an OPTIONAL in the original:
>>
>> WHERE {
>> (?s ?score ?literal) text:query 'musiikkikasv*' .
>> OPTIONAL {
>> GRAPH <http://www.yso.fi/onto/yso/>
>> { ?s skos:prefLabel ?label . }
>> }
>> FILTER (!BOUND(?label) || LANG(?label)=LANG(?literal))
>> }
>>
>> or
>>
>> WHERE {
>> (?s ?score ?literal) text:query 'musiikkikasv*' .
>> OPTIONAL {
>> GRAPH <http://www.yso.fi/onto/yso/>
>> { ?s skos:prefLabel ?label . }
>> FILTER (LANG(?label)=LANG(?literal))
>> }
>> }
>>
>> In this one it is very important the FILTER is at the top level of the
>> OPTIONAL{} block. It puts ?literal in-scope because the FILTER is part
>> of the LeftJoin condition.
>
> I see - moving the FILTER is indeed the key. I don't quite understand
> all the magic that's happening here, but I think I can use this to get a
> working solution.
>
> Thanks a lot for all the explanations and help!
Glad to help,
We still have that weird "graph" getting redefined which is most odd.
Back to the release ...
You retracted your -1 ... if you have time (and we're all short of
that!), could say what your vote is now with a [VOTE] message.
Andy
>
> -Osma
>
>
Re: [] Release Jena 3.0.1 and Fuseki 2.3.1
Posted by Osma Suominen <os...@helsinki.fi>.
Hi Andy!
On 11/12/15 13:54, Andy Seaborne wrote:
> On 10/12/15 20:18, Osma Suominen wrote:
>> PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
>> PREFIX text: <http://jena.apache.org/text#>
>>
>> SELECT *
>> WHERE {
>> GRAPH <http://www.yso.fi/onto/yso/> {
>> GRAPH <urn:x-arq:UnionGraph> {
>> (?s ?score ?literal) text:query 'musiikkikasv*' .
>> }
>> ?s skos:prefLabel ?label .
>> FILTER (LANG(?label)=LANG(?literal))
>> }
>> }
>
> You are running with union default graph? In which case that's good.
Yes, I'm using unionDefaultGraph=true.
> Else use <urn:x-arq:DefaultGraph>
Right.
> One of my regrets in SPARQL is that you can't get back to the default
> graph inside a GRAPH block.
Exactly. That's the problem here, and the workaround requires using
these magic ARQ graph names. Or...
> The key to your query is the back that the FILTER covers the inner GRAPH.
>
> This should work:
>
> WHERE {
> (?s ?score ?literal) text:query 'musiikkikasv*' .
> GRAPH <http://www.yso.fi/onto/yso/> { ?s skos:prefLabel ?label . }
> FILTER (LANG(?label)=LANG(?literal))
> }
>
> and it gets optimized into a
...something missing from your sentence?
Indeed, this works. It's also faster than I expected (20ms). It appears
that when the expression within the GRAPH block gets executed, ?s is
already bound to a single resource (as returned by text:query).
Otherwise the { ?s skos:prefLabel ?label } pattern would have to iterate
over many potential solutions, which would have taken more time.
> You had an OPTIONAL in the original:
>
> WHERE {
> (?s ?score ?literal) text:query 'musiikkikasv*' .
> OPTIONAL {
> GRAPH <http://www.yso.fi/onto/yso/>
> { ?s skos:prefLabel ?label . }
> }
> FILTER (!BOUND(?label) || LANG(?label)=LANG(?literal))
> }
>
> or
>
> WHERE {
> (?s ?score ?literal) text:query 'musiikkikasv*' .
> OPTIONAL {
> GRAPH <http://www.yso.fi/onto/yso/>
> { ?s skos:prefLabel ?label . }
> FILTER (LANG(?label)=LANG(?literal))
> }
> }
>
> In this one it is very important the FILTER is at the top level of the
> OPTIONAL{} block. It puts ?literal in-scope because the FILTER is part
> of the LeftJoin condition.
I see - moving the FILTER is indeed the key. I don't quite understand
all the magic that's happening here, but I think I can use this to get a
working solution.
Thanks a lot for all the explanations and help!
-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.suominen@helsinki.fi
http://www.nationallibrary.fi
Re: [] Release Jena 3.0.1 and Fuseki 2.3.1
Posted by Andy Seaborne <an...@apache.org>.
On 10/12/15 20:18, Osma Suominen wrote:
> PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
> PREFIX text: <http://jena.apache.org/text#>
>
> SELECT *
> WHERE {
> GRAPH <http://www.yso.fi/onto/yso/> {
> GRAPH <urn:x-arq:UnionGraph> {
> (?s ?score ?literal) text:query 'musiikkikasv*' .
> }
> ?s skos:prefLabel ?label .
> FILTER (LANG(?label)=LANG(?literal))
> }
> }
You are running with union default graph? In which case that's good.
Else use <urn:x-arq:DefaultGraph>
One of my regrets in SPARQL is that you can't get back to the default
graph inside a GRAPH block.
The key to your query is the back that the FILTER covers the inner GRAPH.
This should work:
WHERE {
(?s ?score ?literal) text:query 'musiikkikasv*' .
GRAPH <http://www.yso.fi/onto/yso/> { ?s skos:prefLabel ?label . }
FILTER (LANG(?label)=LANG(?literal))
}
and it gets optimized into a
You had an OPTIONAL in the original:
WHERE {
(?s ?score ?literal) text:query 'musiikkikasv*' .
OPTIONAL {
GRAPH <http://www.yso.fi/onto/yso/>
{ ?s skos:prefLabel ?label . }
}
FILTER (!BOUND(?label) || LANG(?label)=LANG(?literal))
}
or
WHERE {
(?s ?score ?literal) text:query 'musiikkikasv*' .
OPTIONAL {
GRAPH <http://www.yso.fi/onto/yso/>
{ ?s skos:prefLabel ?label . }
FILTER (LANG(?label)=LANG(?literal))
}
}
In this one it is very important the FILTER is at the top level of the
OPTIONAL{} block. It puts ?literal in-scope because the FILTER is part
of the LeftJoin condition.
Andy
Re: [] Release Jena 3.0.1 and Fuseki 2.3.1
Posted by Osma Suominen <os...@helsinki.fi>.
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: <http://www.w3.org/2004/02/skos/core#>
PREFIX text: <http://jena.apache.org/text#>
SELECT *
WHERE {
GRAPH <http://www.yso.fi/onto/yso/> {
GRAPH <urn:x-arq:UnionGraph> {
(?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.suominen@helsinki.fi
http://www.nationallibrary.fi
Re: [] Release Jena 3.0.1 and Fuseki 2.3.1
Posted by Andy Seaborne <an...@apache.org>.
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 : <http://example/>
>> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
>>
>> 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+0000 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: <http://www.w3.org/2002/07/owl#>
>>> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
>>> PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
>>> PREFIX isothes: <http://purl.org/iso25964/skos-thes#>
>>> PREFIX text: <http://jena.apache.org/text#>
>>> PREFIX cn: <http://urn.fi/URN:NBN:fi:au:cn:>
>>> PREFIX lapponica: <http://urn.fi/URN:NBN:fi:au: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*' 100000) }
>>> GRAPH ?graph {
>>> { ?s rdf:type <http://www.w3.org/2004/02/skos/core#Concept> } 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) { (<http://www.yso.fi/onto/afo/>)
>>> (<http://www.yso.fi/onto/allars/>)
>>> (<http://avoindata.fi/onto/contentType/>)
>>> (<http://avoindata.fi/onto/topic/>) (<http://urn.fi/URN:NBN:fi:au:cn:>)
>>> (<http://iconclass.org/>) (<http://cv.iptc.org/newscodes/scene/>)
>>> (<http://cv.iptc.org/newscodes/subjectcode/>)
>>> (<http://www.yso.fi/onto/juho/>) (<http://www.yso.fi/onto/jupo/>)
>>> (<http://www.yso.fi/onto/kassu/>) (<http://www.yso.fi/onto/kauno/>)
>>> (<http://www.yso.fi/onto/kito/>) (<http://www.yso.fi/onto/koko/>)
>>> (<http://www.yso.fi/onto/kto/>) (<http://www.yso.fi/onto/kulo/>)
>>> (<http://urn.fi/URN:NBN:fi:au:lapponica:>)
>>> (<http://www.yso.fi/onto/liito/>) (<http://lexvo.org/id/iso639-3/>)
>>> (<http://www.yso.fi/onto/tao/>) (<http://www.yso.fi/onto/mero/>)
>>> (<http://www.yso.fi/onto/mesh/>) (<http://metatietosanasto.fi/>)
>>> (<http://www.yso.fi/onto/musa/>) (<http://www.yso.fi/onto/muso/>)
>>> (<http://www.yso.fi/onto/okm-tieteenala/>)
>>> (<http://www.yso.fi/onto/paikat/>)
>>> (<http://www.yso.fi/onto/ponduskategorier/>)
>>> (<http://www.yso.fi/onto/pto/>) (<http://www.yso.fi/onto/puho/>)
>>> (<http://www.yso.fi/onto/sapo/>) (<http://www.yso.fi/onto/tero/>)
>>> (<http://www.yso.fi/onto/tsr/>) (<http://www.yso.fi/onto/valo/>)
>>> (<http://www.yso.fi/onto/ysa/>) (<http://www.yso.fi/onto/yso/>)
>>> (<http://aims.fao.org/aos/agrovoc/>) (<http://skos.um.es/unescothes/>) }
>>>
>>>
>>>
>>>
>>>
>>
>
>
Re: [] Release Jena 3.0.1 and Fuseki 2.3.1
Posted by Osma Suominen <os...@helsinki.fi>.
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 : <http://example/>
> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
>
> 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+0000 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: <http://www.w3.org/2002/07/owl#>
>> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
>> PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
>> PREFIX isothes: <http://purl.org/iso25964/skos-thes#>
>> PREFIX text: <http://jena.apache.org/text#>
>> PREFIX cn: <http://urn.fi/URN:NBN:fi:au:cn:>
>> PREFIX lapponica: <http://urn.fi/URN:NBN:fi:au: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*' 100000) }
>> GRAPH ?graph {
>> { ?s rdf:type <http://www.w3.org/2004/02/skos/core#Concept> } 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) { (<http://www.yso.fi/onto/afo/>)
>> (<http://www.yso.fi/onto/allars/>)
>> (<http://avoindata.fi/onto/contentType/>)
>> (<http://avoindata.fi/onto/topic/>) (<http://urn.fi/URN:NBN:fi:au:cn:>)
>> (<http://iconclass.org/>) (<http://cv.iptc.org/newscodes/scene/>)
>> (<http://cv.iptc.org/newscodes/subjectcode/>)
>> (<http://www.yso.fi/onto/juho/>) (<http://www.yso.fi/onto/jupo/>)
>> (<http://www.yso.fi/onto/kassu/>) (<http://www.yso.fi/onto/kauno/>)
>> (<http://www.yso.fi/onto/kito/>) (<http://www.yso.fi/onto/koko/>)
>> (<http://www.yso.fi/onto/kto/>) (<http://www.yso.fi/onto/kulo/>)
>> (<http://urn.fi/URN:NBN:fi:au:lapponica:>)
>> (<http://www.yso.fi/onto/liito/>) (<http://lexvo.org/id/iso639-3/>)
>> (<http://www.yso.fi/onto/tao/>) (<http://www.yso.fi/onto/mero/>)
>> (<http://www.yso.fi/onto/mesh/>) (<http://metatietosanasto.fi/>)
>> (<http://www.yso.fi/onto/musa/>) (<http://www.yso.fi/onto/muso/>)
>> (<http://www.yso.fi/onto/okm-tieteenala/>)
>> (<http://www.yso.fi/onto/paikat/>)
>> (<http://www.yso.fi/onto/ponduskategorier/>)
>> (<http://www.yso.fi/onto/pto/>) (<http://www.yso.fi/onto/puho/>)
>> (<http://www.yso.fi/onto/sapo/>) (<http://www.yso.fi/onto/tero/>)
>> (<http://www.yso.fi/onto/tsr/>) (<http://www.yso.fi/onto/valo/>)
>> (<http://www.yso.fi/onto/ysa/>) (<http://www.yso.fi/onto/yso/>)
>> (<http://aims.fao.org/aos/agrovoc/>) (<http://skos.um.es/unescothes/>) }
>>
>>
>>
>>
>>
>
--
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.suominen@helsinki.fi
http://www.nationallibrary.fi
Re: [] Release Jena 3.0.1 and Fuseki 2.3.1
Posted by Andy Seaborne <an...@apache.org>.
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+0000 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: <http://www.w3.org/2002/07/owl#>
> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
> PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
> PREFIX isothes: <http://purl.org/iso25964/skos-thes#>
> PREFIX text: <http://jena.apache.org/text#>
> PREFIX cn: <http://urn.fi/URN:NBN:fi:au:cn:>
> PREFIX lapponica: <http://urn.fi/URN:NBN:fi:au: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*' 100000) }
> GRAPH ?graph {
> { ?s rdf:type <http://www.w3.org/2004/02/skos/core#Concept> } 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) { (<http://www.yso.fi/onto/afo/>)
> (<http://www.yso.fi/onto/allars/>)
> (<http://avoindata.fi/onto/contentType/>)
> (<http://avoindata.fi/onto/topic/>) (<http://urn.fi/URN:NBN:fi:au:cn:>)
> (<http://iconclass.org/>) (<http://cv.iptc.org/newscodes/scene/>)
> (<http://cv.iptc.org/newscodes/subjectcode/>)
> (<http://www.yso.fi/onto/juho/>) (<http://www.yso.fi/onto/jupo/>)
> (<http://www.yso.fi/onto/kassu/>) (<http://www.yso.fi/onto/kauno/>)
> (<http://www.yso.fi/onto/kito/>) (<http://www.yso.fi/onto/koko/>)
> (<http://www.yso.fi/onto/kto/>) (<http://www.yso.fi/onto/kulo/>)
> (<http://urn.fi/URN:NBN:fi:au:lapponica:>)
> (<http://www.yso.fi/onto/liito/>) (<http://lexvo.org/id/iso639-3/>)
> (<http://www.yso.fi/onto/tao/>) (<http://www.yso.fi/onto/mero/>)
> (<http://www.yso.fi/onto/mesh/>) (<http://metatietosanasto.fi/>)
> (<http://www.yso.fi/onto/musa/>) (<http://www.yso.fi/onto/muso/>)
> (<http://www.yso.fi/onto/okm-tieteenala/>)
> (<http://www.yso.fi/onto/paikat/>)
> (<http://www.yso.fi/onto/ponduskategorier/>)
> (<http://www.yso.fi/onto/pto/>) (<http://www.yso.fi/onto/puho/>)
> (<http://www.yso.fi/onto/sapo/>) (<http://www.yso.fi/onto/tero/>)
> (<http://www.yso.fi/onto/tsr/>) (<http://www.yso.fi/onto/valo/>)
> (<http://www.yso.fi/onto/ysa/>) (<http://www.yso.fi/onto/yso/>)
> (<http://aims.fao.org/aos/agrovoc/>) (<http://skos.um.es/unescothes/>) }
>
>
>
>
>
Re: [] Release Jena 3.0.1 and Fuseki 2.3.1
Posted by Andy Seaborne <an...@apache.org>.
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: <http://www.w3.org/2004/02/skos/core#>
>> PREFIX text: <http://jena.apache.org/text#>
>>
>> SELECT *
>> WHERE {
>> (?s ?score ?literal) text:query 'musiikkikasv*' .
>> GRAPH <http://www.yso.fi/onto/yso/> {
>> 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
Posted by Andy Seaborne <an...@apache.org>.
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 : <http://example/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
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 ((: <http://example/>)
(rdfs: <http://www.w3.org/2000/01/rdf-schema#>))
(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 ((: <http://example/>)
(rdfs: <http://www.w3.org/2000/01/rdf-schema#>))
(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
Posted by Osma Suominen <os...@helsinki.fi>.
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.suominen@helsinki.fi
http://www.nationallibrary.fi
Re: [] Release Jena 3.0.1 and Fuseki 2.3.1
Posted by Andy Seaborne <an...@apache.org>.
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: <http://www.w3.org/2004/02/skos/core#>
> PREFIX text: <http://jena.apache.org/text#>
>
> SELECT *
> WHERE {
> (?s ?score ?literal) text:query 'musiikkikasv*' .
> GRAPH <http://www.yso.fi/onto/yso/> {
> 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
Posted by Osma Suominen <os...@helsinki.fi>.
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: <http://www.w3.org/2004/02/skos/core#>
PREFIX text: <http://jena.apache.org/text#>
SELECT *
WHERE {
(?s ?score ?literal) text:query 'musiikkikasv*' .
GRAPH <http://www.yso.fi/onto/yso/> {
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.suominen@helsinki.fi
http://www.nationallibrary.fi
Re: [VOTE] Release Jena 3.0.1 and Fuseki 2.3.1
Posted by Osma Suominen <os...@helsinki.fi>.
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+0000 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: <http://www.w3.org/2002/07/owl#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX isothes: <http://purl.org/iso25964/skos-thes#>
PREFIX text: <http://jena.apache.org/text#>
PREFIX cn: <http://urn.fi/URN:NBN:fi:au:cn:>
PREFIX lapponica: <http://urn.fi/URN:NBN:fi:au: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*' 100000) }
GRAPH ?graph {
{ ?s rdf:type <http://www.w3.org/2004/02/skos/core#Concept> } 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) { (<http://www.yso.fi/onto/afo/>)
(<http://www.yso.fi/onto/allars/>)
(<http://avoindata.fi/onto/contentType/>)
(<http://avoindata.fi/onto/topic/>) (<http://urn.fi/URN:NBN:fi:au:cn:>)
(<http://iconclass.org/>) (<http://cv.iptc.org/newscodes/scene/>)
(<http://cv.iptc.org/newscodes/subjectcode/>)
(<http://www.yso.fi/onto/juho/>) (<http://www.yso.fi/onto/jupo/>)
(<http://www.yso.fi/onto/kassu/>) (<http://www.yso.fi/onto/kauno/>)
(<http://www.yso.fi/onto/kito/>) (<http://www.yso.fi/onto/koko/>)
(<http://www.yso.fi/onto/kto/>) (<http://www.yso.fi/onto/kulo/>)
(<http://urn.fi/URN:NBN:fi:au:lapponica:>)
(<http://www.yso.fi/onto/liito/>) (<http://lexvo.org/id/iso639-3/>)
(<http://www.yso.fi/onto/tao/>) (<http://www.yso.fi/onto/mero/>)
(<http://www.yso.fi/onto/mesh/>) (<http://metatietosanasto.fi/>)
(<http://www.yso.fi/onto/musa/>) (<http://www.yso.fi/onto/muso/>)
(<http://www.yso.fi/onto/okm-tieteenala/>)
(<http://www.yso.fi/onto/paikat/>)
(<http://www.yso.fi/onto/ponduskategorier/>)
(<http://www.yso.fi/onto/pto/>) (<http://www.yso.fi/onto/puho/>)
(<http://www.yso.fi/onto/sapo/>) (<http://www.yso.fi/onto/tero/>)
(<http://www.yso.fi/onto/tsr/>) (<http://www.yso.fi/onto/valo/>)
(<http://www.yso.fi/onto/ysa/>) (<http://www.yso.fi/onto/yso/>)
(<http://aims.fao.org/aos/agrovoc/>) (<http://skos.um.es/unescothes/>) }
--
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.suominen@helsinki.fi
http://www.nationallibrary.fi
Re: [VOTE] Release Jena 3.0.1 and Fuseki 2.3.1
Posted by Osma Suominen <os...@helsinki.fi>.
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.
I'm still a bit worried about the weird GRAPH with VALUES error that I
stumbled on yesterday, but it doesn't seem to affect my actual queries
(which also combine GRAPH with text:query and VALUES but in more complex
ways), and it's apparently not a regression from 1.3.0, so it can be
left for later.
-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.suominen@helsinki.fi
http://www.nationallibrary.fi