Re: Spatial Indexing library for GeoSPARQL

[Marco Neumann]

I would say yes the interesting bits are done by JTS. we used another LGPL
index for geosparql.org.

I think Jena deserves a dedicated file based indexer to support the full
OGC geosparql standard but that said the task should not be underestimated.





On Wed, Sep 12, 2012 at 5:59 PM, Rob Vesse  wrote:

> If I read the documentation correctly it can optionally use the JTS
> library (which yes is LGPL and so no go for Apache projects) if that
> library is needed, it can be used without.
>
> I'm not sure if the extra features that JTS provides are necessary for a
> GeoSPARQL implementation because I'm not up to speed on exactly what
> GeoSPARQL requires
>
> Rob
>
>
> On 9/12/12 2:51 PM, "Marco Neumann"  wrote:
>
> >it uses the JTS Topology Suite indexer which hasn't been updated for a
> >while but is open source under the LGPL license.
> >
> >
> >
> >On Wed, Sep 12, 2012 at 5:42 PM, Rob Vesse  wrote:
> >
> >> I remember some discussions a while back about one of the barriers to
> >> implementing GeoSPARQL in Jena being the lack of a good indexing
> >>library to
> >> use
> >>
> >> I notice that Lucene 4.0 has a new Spatial module -
> >> http://lucene.apache.org/core/4_0_0-BETA/spatial/index.html ­ which is
> >> itself built on another library Spatial4j which is ASL licensed
> >>
> >> Would these be sufficient pieces to get us started?  I haven't looked in
> >> detail as to whether these libraries provide the specific geospatial
> >> primitives and functions we'd need to implement GeoSPARQL
> >>
> >> Rob
> >>
> >
> >
> >
> >--
> >
> >
> >---
> >Marco Neumann
> >KONA
> >
> >Join us at SemTech Biz in New York City October 15-17, 2012 and save 15%
> >with code STMN
> >http://www.lotico.com/evt/SemTechBizNYC2012
>
>


-- 


---
Marco Neumann
KONA

Join us at SemTech Biz in New York City October 15-17, 2012 and save 15%
with code STMN
http://www.lotico.com/evt/SemTechBizNYC2012

Re: Spatial Indexing library for GeoSPARQL

[Rob Vesse]

If I read the documentation correctly it can optionally use the JTS
library (which yes is LGPL and so no go for Apache projects) if that
library is needed, it can be used without.

I'm not sure if the extra features that JTS provides are necessary for a
GeoSPARQL implementation because I'm not up to speed on exactly what
GeoSPARQL requires

Rob


On 9/12/12 2:51 PM, "Marco Neumann"  wrote:

>it uses the JTS Topology Suite indexer which hasn't been updated for a
>while but is open source under the LGPL license.
>
>
>
>On Wed, Sep 12, 2012 at 5:42 PM, Rob Vesse  wrote:
>
>> I remember some discussions a while back about one of the barriers to
>> implementing GeoSPARQL in Jena being the lack of a good indexing
>>library to
>> use
>>
>> I notice that Lucene 4.0 has a new Spatial module -
>> http://lucene.apache.org/core/4_0_0-BETA/spatial/index.html ­ which is
>> itself built on another library Spatial4j which is ASL licensed
>>
>> Would these be sufficient pieces to get us started?  I haven't looked in
>> detail as to whether these libraries provide the specific geospatial
>> primitives and functions we'd need to implement GeoSPARQL
>>
>> Rob
>>
>
>
>
>-- 
>
>
>---
>Marco Neumann
>KONA
>
>Join us at SemTech Biz in New York City October 15-17, 2012 and save 15%
>with code STMN
>http://www.lotico.com/evt/SemTechBizNYC2012

Re: Spatial Indexing library for GeoSPARQL

[Marco Neumann]

it uses the JTS Topology Suite indexer which hasn't been updated for a
while but is open source under the LGPL license.



On Wed, Sep 12, 2012 at 5:42 PM, Rob Vesse  wrote:

> I remember some discussions a while back about one of the barriers to
> implementing GeoSPARQL in Jena being the lack of a good indexing library to
> use
>
> I notice that Lucene 4.0 has a new Spatial module -
> http://lucene.apache.org/core/4_0_0-BETA/spatial/index.html – which is
> itself built on another library Spatial4j which is ASL licensed
>
> Would these be sufficient pieces to get us started?  I haven't looked in
> detail as to whether these libraries provide the specific geospatial
> primitives and functions we'd need to implement GeoSPARQL
>
> Rob
>



-- 


---
Marco Neumann
KONA

Join us at SemTech Biz in New York City October 15-17, 2012 and save 15%
with code STMN
http://www.lotico.com/evt/SemTechBizNYC2012

Spatial Indexing library for GeoSPARQL

[Rob Vesse]

I remember some discussions a while back about one of the barriers to 
implementing GeoSPARQL in Jena being the lack of a good indexing library to use

I notice that Lucene 4.0 has a new Spatial module - 
http://lucene.apache.org/core/4_0_0-BETA/spatial/index.html – which is itself 
built on another library Spatial4j which is ASL licensed

Would these be sufficient pieces to get us started?  I haven't looked in detail 
as to whether these libraries provide the specific geospatial primitives and 
functions we'd need to implement GeoSPARQL

Rob

Re: 2.7.4 release?

[Simon Helsen]

Thanks for the update Rob. Yes, I understand it is mostly a question for 
one of the committers to have time to put it all together, assuming 
nothing goes wrong and people agree that a service increment is a good 
idea. There are a significant number of fixes in the transactional code as 
Andy points out and we feel more comfortable with that than what we have 
in 2.7.1 although they mostly affect TDB's ability to recover during a 
crash. On the testing front, we just got one of our clients to run a 
scalability test (meaning they run with a large starting repository and 
fire up multiple users to perform read/write activities) and they have not 
observed any regressions compared to 2.7.1 and a slight overall speed 
improvement (something like 6%, not stellar, but most importantly not 
slower)

Simon




From:
Rob Vesse 
To:
"dev@jena.apache.org" 
Date:
09/12/2012 02:19 PM
Subject:
Re: 2.7.4 release?



Any release should take in the region of a week assuming everyone is happy
with the state of the code and people have been testing continuously.
There's no reason a release should take much longer than that unless any
serious issues crop up during the process


It's mainly a question of someone having the free time to shepherd the
process through because it is somewhat time consuming in parts

Rob

On 9/12/12 11:04 AM, "Simon Helsen"  wrote:

>Well, we had two timescales in mind:
>
>Either very quick, i.e. sometime next week :-) That would give our
>verification testers enough time to get decent coverage before release
>and 
>would just be sufficient to get legal aspects out of the way. I realize
>that would have been ambitious either way, but in the past, I have
>observed with Jena 2.7.2 and Jena 2.7.3, it took you guys no more than a
>week from the intend of releasing to getting it cleared and voted on.
>Anyhow, I was kind of assuming that wouldn't be possible anymore, so the
>next window of opportunity for us would be December at which point our
>integration testers would probably be in a position to hammer the thing
>and there would be plenty of room for legal.
>
>I realize this is volunteer effort, so we are not demanding anything of
>course, but 2.7.3 was not good enough for us in terms of stability and
>2.7.1, well, we can live with it, but it is not as robust under crashes
>as 
>2.7.4. Also, it seems slightly faster
>
>
>
>
>From:
>Andy Seaborne 
>To:
>Simon Helsen/Toronto/IBM@IBMCA
>Cc:
>dev@jena.apache.org, Philippe P Mulet 
>Date:
>09/12/2012 01:41 PM
>Subject:
>Re: 2.7.4 release?
>
>
>
>Simon,
>
>What timescale are you working to?
>
> Andy
>
>On 12/09/12 15:26, Simon Helsen wrote:
>> Thanks Andy
>>
>> "The changes (post TDB 0.9.3) for optimized and correct transactions 
are
>> new and really could do with bedding down.  If you could go beyond 
basic
>> testing that would be helpful so things get raised before a .4 
release."
>>
>> we are in the process of getting more comprehensive tests done,but that
>> process is quite resource intensive as you can imagine. If there is no
>> prospect of having a .4 release on time, it is also more difficult to
>> justify. You have to see it this way: we can easily test snapshots
>> (pre-releases) with our own development automated tests and some 
limited
>> scalability tests of some of our clients. Beyond that, it becomes
>> cumbersome to test snapshots because we can never get legal approval 
for
>> these, meaning we can't bring the changes into our main development
>> stream etc. We are then forced to produce custom builds and equip our
>> testers with these. Nothing is impossible, but some things are more
>> difficult and more importantly, take more time.
>>
>> "The deprecations in jena-core could do with some inspection before a
>> release because the point of deprecating them is that they can then get
>> removed."
>>
>> Right, however, I assume that for a .4, these APIs would just be
>> deprecated and not removed, right?
>>
>> "The SDB release cycle is going quite well - and doing a lightweight
>> community "Release Candidate" seems to have been a success.  We have
>> reports, and something has been reported that could do with
>investigation."
>>
>> Right, I understand that, although I am not sure if an SDB release has
>> to be a prereq for a .4 service release
>>
>> "It would be nice to release LARQ as a post-incubator."
>>
>> I agree, but here as well, is that really a prereq for a service
>release?
>>
>> "Things are busy."
>>
>> no doubt
>>
>>
>> From:  Andy Seaborne 
>> To:dev@jena.apache.org, Philippe P Mulet
>
>> Date:  09/12/2012 05:06 AM
>> Subject:   Re: 2.7.4 release?
>>
>>
>> 

>>
>>
>>
>> On 06/09/12 21:28, Simon Helsen wrote:
>>  > hi everyone,
>>  >
>>  > I was wondering if there is a chance to get a 2.7.4 release soon.
>There
>>  > have been numerous fixes since 2.7.3 and unfortunately, we are not

Re: 2.7.4 release?

[Rob Vesse]

Any release should take in the region of a week assuming everyone is happy
with the state of the code and people have been testing continuously.
There's no reason a release should take much longer than that unless any
serious issues crop up during the process


It's mainly a question of someone having the free time to shepherd the
process through because it is somewhat time consuming in parts

Rob

On 9/12/12 11:04 AM, "Simon Helsen"  wrote:

>Well, we had two timescales in mind:
>
>Either very quick, i.e. sometime next week :-) That would give our
>verification testers enough time to get decent coverage before release
>and 
>would just be sufficient to get legal aspects out of the way. I realize
>that would have been ambitious either way, but in the past, I have
>observed with Jena 2.7.2 and Jena 2.7.3, it took you guys no more than a
>week from the intend of releasing to getting it cleared and voted on.
>Anyhow, I was kind of assuming that wouldn't be possible anymore, so the
>next window of opportunity for us would be December at which point our
>integration testers would probably be in a position to hammer the thing
>and there would be plenty of room for legal.
>
>I realize this is volunteer effort, so we are not demanding anything of
>course, but 2.7.3 was not good enough for us in terms of stability and
>2.7.1, well, we can live with it, but it is not as robust under crashes
>as 
>2.7.4. Also, it seems slightly faster
>
>
>
>
>From:
>Andy Seaborne 
>To:
>Simon Helsen/Toronto/IBM@IBMCA
>Cc:
>dev@jena.apache.org, Philippe P Mulet 
>Date:
>09/12/2012 01:41 PM
>Subject:
>Re: 2.7.4 release?
>
>
>
>Simon,
>
>What timescale are you working to?
>
> Andy
>
>On 12/09/12 15:26, Simon Helsen wrote:
>> Thanks Andy
>>
>> "The changes (post TDB 0.9.3) for optimized and correct transactions are
>> new and really could do with bedding down.  If you could go beyond basic
>> testing that would be helpful so things get raised before a .4 release."
>>
>> we are in the process of getting more comprehensive tests done,but that
>> process is quite resource intensive as you can imagine. If there is no
>> prospect of having a .4 release on time, it is also more difficult to
>> justify. You have to see it this way: we can easily test snapshots
>> (pre-releases) with our own development automated tests and some limited
>> scalability tests of some of our clients. Beyond that, it becomes
>> cumbersome to test snapshots because we can never get legal approval for
>> these, meaning we can't bring the changes into our main development
>> stream etc. We are then forced to produce custom builds and equip our
>> testers with these. Nothing is impossible, but some things are more
>> difficult and more importantly, take more time.
>>
>> "The deprecations in jena-core could do with some inspection before a
>> release because the point of deprecating them is that they can then get
>> removed."
>>
>> Right, however, I assume that for a .4, these APIs would just be
>> deprecated and not removed, right?
>>
>> "The SDB release cycle is going quite well - and doing a lightweight
>> community "Release Candidate" seems to have been a success.  We have
>> reports, and something has been reported that could do with
>investigation."
>>
>> Right, I understand that, although I am not sure if an SDB release has
>> to be a prereq for a .4 service release
>>
>> "It would be nice to release LARQ as a post-incubator."
>>
>> I agree, but here as well, is that really a prereq for a service
>release?
>>
>> "Things are busy."
>>
>> no doubt
>>
>>
>> From:  Andy Seaborne 
>> To:dev@jena.apache.org, Philippe P Mulet
>
>> Date:  09/12/2012 05:06 AM
>> Subject:   Re: 2.7.4 release?
>>
>>
>> 
>>
>>
>>
>> On 06/09/12 21:28, Simon Helsen wrote:
>>  > hi everyone,
>>  >
>>  > I was wondering if there is a chance to get a 2.7.4 release soon.
>There
>>  > have been numerous fixes since 2.7.3 and unfortunately, we are not
>> allowed
>>  > to adopt a non-released snapshot. Basic internal testing seems to
>suggest
>>  > 2.7.4 is pretty stable. Does not mean we would not find more bugs,
>but it
>>  > would fit the frequent small service releases. As a non-committer, I
>> don't
>>  > think I can help the process (other than testing)
>>  >
>>  > thanks
>>  >
>>  > Simon
>>  >
>>
>> The changes (post TDB 0.9.3) for optimized and correct transactions are
>> new and really could do with bedding down.  If you could go beyond basic
>> testing that would be helpful so things get raised before a .4 release.
>>
>> Quite a few JIRA have had input in the last week or so and I haven't
>> managed to get a picture of where we are.  The Fuseki as a WAR file
>> (JENA-201) has lots of votes.
>>
>> The deprecations in jena-core could do with some inspection before a
>> release because the point of deprecating them is that they can then get
>> removed

Re: 2.7.4 release?

[Simon Helsen]

Well, we had two timescales in mind:

Either very quick, i.e. sometime next week :-) That would give our 
verification testers enough time to get decent coverage before release and 
would just be sufficient to get legal aspects out of the way. I realize 
that would have been ambitious either way, but in the past, I have 
observed with Jena 2.7.2 and Jena 2.7.3, it took you guys no more than a 
week from the intend of releasing to getting it cleared and voted on. 
Anyhow, I was kind of assuming that wouldn't be possible anymore, so the 
next window of opportunity for us would be December at which point our 
integration testers would probably be in a position to hammer the thing 
and there would be plenty of room for legal. 

I realize this is volunteer effort, so we are not demanding anything of 
course, but 2.7.3 was not good enough for us in terms of stability and 
2.7.1, well, we can live with it, but it is not as robust under crashes as 
2.7.4. Also, it seems slightly faster




From:
Andy Seaborne 
To:
Simon Helsen/Toronto/IBM@IBMCA
Cc:
dev@jena.apache.org, Philippe P Mulet 
Date:
09/12/2012 01:41 PM
Subject:
Re: 2.7.4 release?



Simon,

What timescale are you working to?

 Andy

On 12/09/12 15:26, Simon Helsen wrote:
> Thanks Andy
>
> "The changes (post TDB 0.9.3) for optimized and correct transactions are
> new and really could do with bedding down.  If you could go beyond basic
> testing that would be helpful so things get raised before a .4 release."
>
> we are in the process of getting more comprehensive tests done,but that
> process is quite resource intensive as you can imagine. If there is no
> prospect of having a .4 release on time, it is also more difficult to
> justify. You have to see it this way: we can easily test snapshots
> (pre-releases) with our own development automated tests and some limited
> scalability tests of some of our clients. Beyond that, it becomes
> cumbersome to test snapshots because we can never get legal approval for
> these, meaning we can't bring the changes into our main development
> stream etc. We are then forced to produce custom builds and equip our
> testers with these. Nothing is impossible, but some things are more
> difficult and more importantly, take more time.
>
> "The deprecations in jena-core could do with some inspection before a
> release because the point of deprecating them is that they can then get
> removed."
>
> Right, however, I assume that for a .4, these APIs would just be
> deprecated and not removed, right?
>
> "The SDB release cycle is going quite well - and doing a lightweight
> community "Release Candidate" seems to have been a success.  We have
> reports, and something has been reported that could do with 
investigation."
>
> Right, I understand that, although I am not sure if an SDB release has
> to be a prereq for a .4 service release
>
> "It would be nice to release LARQ as a post-incubator."
>
> I agree, but here as well, is that really a prereq for a service 
release?
>
> "Things are busy."
>
> no doubt
>
>
> From:  Andy Seaborne 
> To:dev@jena.apache.org, Philippe P Mulet 

> Date:  09/12/2012 05:06 AM
> Subject:   Re: 2.7.4 release?
>
>
> 
>
>
>
> On 06/09/12 21:28, Simon Helsen wrote:
>  > hi everyone,
>  >
>  > I was wondering if there is a chance to get a 2.7.4 release soon. 
There
>  > have been numerous fixes since 2.7.3 and unfortunately, we are not
> allowed
>  > to adopt a non-released snapshot. Basic internal testing seems to 
suggest
>  > 2.7.4 is pretty stable. Does not mean we would not find more bugs, 
but it
>  > would fit the frequent small service releases. As a non-committer, I
> don't
>  > think I can help the process (other than testing)
>  >
>  > thanks
>  >
>  > Simon
>  >
>
> The changes (post TDB 0.9.3) for optimized and correct transactions are
> new and really could do with bedding down.  If you could go beyond basic
> testing that would be helpful so things get raised before a .4 release.
>
> Quite a few JIRA have had input in the last week or so and I haven't
> managed to get a picture of where we are.  The Fuseki as a WAR file
> (JENA-201) has lots of votes.
>
> The deprecations in jena-core could do with some inspection before a
> release because the point of deprecating them is that they can then get
> removed.
>
> The SDB release cycle is going quite well - and doing a lightweight
> community "Release Candidate" seems to have been a success.  We have
> reports, and something has been reported that could do with 
investigation.
>
> It would be nice to release LARQ as a post-incubator.
>
> Things are busy.
>
> I wonder if an RC phase is the best way forward.
>
> (all) What things would ideally be done before a RC phase can start?
>
> Andy
>
>
>

Re: 2.7.4 release?

[Andy Seaborne]

Simon,

What timescale are you working to?

Andy

On 12/09/12 15:26, Simon Helsen wrote:

Thanks Andy

"The changes (post TDB 0.9.3) for optimized and correct transactions are
new and really could do with bedding down.  If you could go beyond basic
testing that would be helpful so things get raised before a .4 release."

we are in the process of getting more comprehensive tests done,but that
process is quite resource intensive as you can imagine. If there is no
prospect of having a .4 release on time, it is also more difficult to
justify. You have to see it this way: we can easily test snapshots
(pre-releases) with our own development automated tests and some limited
scalability tests of some of our clients. Beyond that, it becomes
cumbersome to test snapshots because we can never get legal approval for
these, meaning we can't bring the changes into our main development
stream etc. We are then forced to produce custom builds and equip our
testers with these. Nothing is impossible, but some things are more
difficult and more importantly, take more time.

"The deprecations in jena-core could do with some inspection before a
release because the point of deprecating them is that they can then get
removed."

Right, however, I assume that for a .4, these APIs would just be
deprecated and not removed, right?

"The SDB release cycle is going quite well - and doing a lightweight
community "Release Candidate" seems to have been a success.  We have
reports, and something has been reported that could do with investigation."

Right, I understand that, although I am not sure if an SDB release has
to be a prereq for a .4 service release

"It would be nice to release LARQ as a post-incubator."

I agree, but here as well, is that really a prereq for a service release?

"Things are busy."

no doubt


From:   Andy Seaborne 
To: dev@jena.apache.org, Philippe P Mulet 
Date:   09/12/2012 05:06 AM
Subject:Re: 2.7.4 release?






On 06/09/12 21:28, Simon Helsen wrote:
 > hi everyone,
 >
 > I was wondering if there is a chance to get a 2.7.4 release soon. There
 > have been numerous fixes since 2.7.3 and unfortunately, we are not
allowed
 > to adopt a non-released snapshot. Basic internal testing seems to suggest
 > 2.7.4 is pretty stable. Does not mean we would not find more bugs, but it
 > would fit the frequent small service releases. As a non-committer, I
don't
 > think I can help the process (other than testing)
 >
 > thanks
 >
 > Simon
 >

The changes (post TDB 0.9.3) for optimized and correct transactions are
new and really could do with bedding down.  If you could go beyond basic
testing that would be helpful so things get raised before a .4 release.

Quite a few JIRA have had input in the last week or so and I haven't
managed to get a picture of where we are.  The Fuseki as a WAR file
(JENA-201) has lots of votes.

The deprecations in jena-core could do with some inspection before a
release because the point of deprecating them is that they can then get
removed.

The SDB release cycle is going quite well - and doing a lightweight
community "Release Candidate" seems to have been a success.  We have
reports, and something has been reported that could do with investigation.

It would be nice to release LARQ as a post-incubator.

Things are busy.

I wonder if an RC phase is the best way forward.

(all) What things would ideally be done before a RC phase can start?

Andy

Re: 2.7.4 release?

[Rob Vesse]

I plan to take a look at the Fuseki as a WAR again at some point but am
fairly snowed under at the moment

Also it's a non-trivial change which may also require some maven and svn
shenanigans if we want to generate both a WAR and the existing runnable
JAR packaging (possibly splitting the fuseki module into a fuseki-core and
fuseki-war).  Plus I have no idea if the provided patch is all that is
needed or not.


I would rather not do this in a rush or for a point release, this should
be at least a minor if not major release for Fuseki when we make that
change.

Just because something has lots of votes and is a good idea doesn't mean
we should rush it!

Rob

On 9/12/12 2:05 AM, "Andy Seaborne"  wrote:

>On 06/09/12 21:28, Simon Helsen wrote:
>> hi everyone,
>>
>> I was wondering if there is a chance to get a 2.7.4 release soon. There
>> have been numerous fixes since 2.7.3 and unfortunately, we are not
>>allowed
>> to adopt a non-released snapshot. Basic internal testing seems to
>>suggest
>> 2.7.4 is pretty stable. Does not mean we would not find more bugs, but
>>it
>> would fit the frequent small service releases. As a non-committer, I
>>don't
>> think I can help the process (other than testing)
>>
>> thanks
>>
>> Simon
>>
>
>The changes (post TDB 0.9.3) for optimized and correct transactions are
>new and really could do with bedding down.  If you could go beyond basic
>testing that would be helpful so things get raised before a .4 release.
>
>Quite a few JIRA have had input in the last week or so and I haven't
>managed to get a picture of where we are.  The Fuseki as a WAR file
>(JENA-201) has lots of votes.
>
>The deprecations in jena-core could do with some inspection before a
>release because the point of deprecating them is that they can then get
>removed.
>
>The SDB release cycle is going quite well - and doing a lightweight
>community "Release Candidate" seems to have been a success.  We have
>reports, and something has been reported that could do with investigation.
>
>It would be nice to release LARQ as a post-incubator.
>
>Things are busy.
>
>I wonder if an RC phase is the best way forward.
>
>(all) What things would ideally be done before a RC phase can start?
>
>   Andy
>

[jira] [Commented] (JENA-320) Unexpected result from SPARQL Tutorial - Filters

[Don Pellegrino (JIRA)]

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

Don Pellegrino commented on JENA-320:
-

Thanks, it is now working as expected.

> Unexpected result from SPARQL Tutorial - Filters
> 
>
> Key: JENA-320
> URL: https://issues.apache.org/jira/browse/JENA-320
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB, Web site
>Affects Versions: ARQ 2.9.3, TDB 0.9.3, Jena 2.7.3
> Environment: $ java -version
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> $ lsb_release -a
> LSB Version:
> :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch
> Distributor ID: CentOS
> Description:CentOS release 5.5 (Final)
> Release:5.5
> Codename:   Final
>Reporter: Don Pellegrino
>Assignee: Andy Seaborne
> Fix For: Jena 2.7.4
>
>
> The "Testing Values" section of the Apache Jena "SPARQL Tutorial - Filters" 
> page(http://jena.apache.org/tutorials/sparql_filters.html) does not produce 
> the expected results. I made sure to pull the example files from the site to 
> ensure the issue was not due to typos in transcription:
> $ wget "http://jena.apache.org/tutorials/sparql_data/vc-db-2.rdf";
> --2012-09-04 10:47:20-- 
> http://jena.apache.org/tutorials/sparql_data/vc-db-2.rdf
> Resolving jena.apache.org... 140.211.11.131, 
> 192.87.106.229,2001:610:1:80bc:192:87:106:229
> Connecting to jena.apache.org|140.211.11.131|:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 1149 (1.1K) [application/rdf+xml]
> Saving to: `vc-db-2.rdf'
> 100%[=>] 
> 1,149--.-K/s in 0s
> 2012-09-04 10:47:20 (99.6 MB/s) - `vc-db-2.rdf' saved [1149/1149]
> $ wget "http://jena.apache.org/tutorials/sparql_data/q-f2.rq";
> --2012-09-04 10:48:03-- http://jena.apache.org/tutorials/sparql_data/q-f2.rq
> Resolving jena.apache.org... 140.211.11.131, 
> 192.87.106.229,2001:610:1:80bc:192:87:106:229
> Connecting to jena.apache.org|140.211.11.131|:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 148 [application/sparql-query]
> Saving to: `q-f2.rq'
> 100%[=>] 
> 148--.-K/s in 0s
> 2012-09-04 10:48:03 (990 KB/s) - `q-f2.rq' saved [148/148]
> I then used the following query command:
> $ sparql --data=vc-db-2.rdf --query=q-f2.rq
> 
> | resource |
> 
> 
> The Tutorial page indicates that the result should have been:
> -
> | resource |
> =
> |  |
> -

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: 2.7.4 release?

[Simon Helsen]

Thanks Andy

"The changes (post TDB 0.9.3) for optimized and correct transactions are 
new and really could do with bedding down.  If you could go beyond basic 
testing that would be helpful so things get raised before a .4 release."

we are in the process of getting more comprehensive tests done, but that 
process is quite resource intensive as you can imagine. If there is no 
prospect of having a .4 release on time, it is also more difficult to 
justify. You have to see it this way: we can easily test snapshots 
(pre-releases) with our own development automated tests and some limited 
scalability tests of some of our clients. Beyond that, it becomes 
cumbersome to test snapshots because we can never get legal approval for 
these, meaning we can't bring the changes into our main development stream 
etc. We are then forced to produce custom builds and equip our testers 
with these. Nothing is impossible, but some things are more difficult and 
more importantly, take more time.

"The deprecations in jena-core could do with some inspection before a 
release because the point of deprecating them is that they can then get 
removed."

Right, however, I assume that for a .4, these APIs would just be 
deprecated and not removed, right?

"The SDB release cycle is going quite well - and doing a lightweight 
community "Release Candidate" seems to have been a success.  We have 
reports, and something has been reported that could do with investigation.
"

Right, I understand that, although I am not sure if an SDB release has to 
be a prereq for a .4 service release

"It would be nice to release LARQ as a post-incubator."

I agree, but here as well, is that really a prereq for a service release?

"Things are busy."

no doubt



From:
Andy Seaborne 
To:
dev@jena.apache.org, Philippe P Mulet 
Date:
09/12/2012 05:06 AM
Subject:
Re: 2.7.4 release?



On 06/09/12 21:28, Simon Helsen wrote:
> hi everyone,
>
> I was wondering if there is a chance to get a 2.7.4 release soon. There
> have been numerous fixes since 2.7.3 and unfortunately, we are not 
allowed
> to adopt a non-released snapshot. Basic internal testing seems to 
suggest
> 2.7.4 is pretty stable. Does not mean we would not find more bugs, but 
it
> would fit the frequent small service releases. As a non-committer, I 
don't
> think I can help the process (other than testing)
>
> thanks
>
> Simon
>

The changes (post TDB 0.9.3) for optimized and correct transactions are 
new and really could do with bedding down.  If you could go beyond basic 
testing that would be helpful so things get raised before a .4 release.

Quite a few JIRA have had input in the last week or so and I haven't 
managed to get a picture of where we are.  The Fuseki as a WAR file 
(JENA-201) has lots of votes.

The deprecations in jena-core could do with some inspection before a 
release because the point of deprecating them is that they can then get 
removed.

The SDB release cycle is going quite well - and doing a lightweight 
community "Release Candidate" seems to have been a success.  We have 
reports, and something has been reported that could do with investigation.

It would be nice to release LARQ as a post-incubator.

Things are busy.

I wonder if an RC phase is the best way forward.

(all) What things would ideally be done before a RC phase can start?

 Andy

[jira] [Commented] (JENA-244) Deadlock during SPARQL execution on an inference model

[Dave Reynolds (JIRA)]

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

Dave Reynolds commented on JENA-244:


Stephen - yes, no work has been done on this bug. Too much "day job" in the way.

> Deadlock during SPARQL execution on an inference model
> --
>
> Key: JENA-244
> URL: https://issues.apache.org/jira/browse/JENA-244
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Jena
>Reporter: Stephen Owens
> Attachments: JenaDeadLockTest.java, JenaDeadLockTest.java
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (JENA-244) Deadlock during SPARQL execution on an inference model

[Simon Helsen (JIRA)]

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

Simon Helsen commented on JENA-244:
---

Have you tested this with a snapshot 2.7.4 build?

> Deadlock during SPARQL execution on an inference model
> --
>
> Key: JENA-244
> URL: https://issues.apache.org/jira/browse/JENA-244
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Jena
>Reporter: Stephen Owens
> Attachments: JenaDeadLockTest.java, JenaDeadLockTest.java
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (JENA-189) Jena 3 / technical

[Rajeev B (JIRA)]

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

Rajeev B commented on JENA-189:
---

I'll read through and try to proceed in the direction of an "Ouplementation", 
this should bring any Store supporting Blueprints, into the gamut of Jena 
(without implementing anything on the Store side). 

So I'll start looking at the Sail Ouplementation and StageGenerator that you 
mentioned.

> Jena 3 / technical
> --
>
> Key: JENA-189
> URL: https://issues.apache.org/jira/browse/JENA-189
> Project: Apache Jena
>  Issue Type: Brainstorming
>Reporter: Andy Seaborne
>
> This is a JIRA to discuss and collect technical changes to Jena that would 
> warrant a "Jena3" whether an incompatible change or just sufficient changes 
> to mean bumping the major version number is best.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: 2.7.4 release?

[Andy Seaborne]

On 06/09/12 21:28, Simon Helsen wrote:

hi everyone,

I was wondering if there is a chance to get a 2.7.4 release soon. There
have been numerous fixes since 2.7.3 and unfortunately, we are not allowed
to adopt a non-released snapshot. Basic internal testing seems to suggest
2.7.4 is pretty stable. Does not mean we would not find more bugs, but it
would fit the frequent small service releases. As a non-committer, I don't
think I can help the process (other than testing)

thanks

Simon



The changes (post TDB 0.9.3) for optimized and correct transactions are 
new and really could do with bedding down.  If you could go beyond basic 
testing that would be helpful so things get raised before a .4 release.


Quite a few JIRA have had input in the last week or so and I haven't 
managed to get a picture of where we are.  The Fuseki as a WAR file 
(JENA-201) has lots of votes.


The deprecations in jena-core could do with some inspection before a 
release because the point of deprecating them is that they can then get 
removed.


The SDB release cycle is going quite well - and doing a lightweight 
community "Release Candidate" seems to have been a success.  We have 
reports, and something has been reported that could do with investigation.


It would be nice to release LARQ as a post-incubator.

Things are busy.

I wonder if an RC phase is the best way forward.

(all) What things would ideally be done before a RC phase can start?

Andy