Re: Jena next

[Marco Neumann]

thank you for the link Claude, looks indeed like a very useful addition to
a standard implementation. In particular when combined with an enhanced
admin UI I would think.

Marco

On Fri, Nov 15, 2019 at 1:33 PM Claude Warren  wrote:

> Marco,
>
> The permissions layer [1] is a separate module that wraps graph and model
> implementations with permissions checking.  It can use Shiro (or whatever
> Fuseki uses).
>
> Basically, it uses the dynamic proxy mechanism to intercept "interesting"
> calls to graph and model to filter out triples that should not be seen by
> the user.  It operates at 2 distinct levels:  You can limit user access to
> an entire graph/module or you can limit access to specific triples within
> the graph/module.
>
> I was recently wondering if anybody actually, (outside of the project I
> worked on, used it in production.  I got an answer when I got a query about
> how to do some specific task from a company that was utilizing it for a
> number of implementations.
>
> Claude
>
> [1] https://jena.apache.org/documentation/permissions/index.html
>
> On Fri, Nov 15, 2019 at 11:24 AM Marco Neumann 
> wrote:
>
> > when you say as an afterthought you refer to shiro? to define permissions
> > functionality in a TTL configuration for high granularity would indeed be
> > nice. why not do it somewhat similar to how it's done in mainstream RDBMS
> > with SQL system tables?
> >
> >
> > On Fri, Nov 15, 2019 at 11:07 AM Claude Warren  wrote:
> >
> > > I would like to see the permissions functionality baked into the
> standard
> > > implementations rather than wrapped around as an afterthought.
> However,
> > if
> > > that can't be done or is just more overhead than we want when
> permissions
> > > are not in use then I would hope that we will continue to use
> interfaces
> > to
> > > define the objects in the API.
> > >
> > > I think we should also look at Rya (https://rya.apache.org) and
> Commons
> > > RDF
> > > (https://commons.apache.org/proper/commons-rdf/index.html) to see if
> > there
> > > is anything we can learn from them.
> > >
> > > On Thu, Nov 14, 2019 at 8:09 PM Aaron Coburn 
> wrote:
> > >
> > > > I would be very interested in discussing the high level Java API and
> > how
> > > it
> > > > could be simplified.
> > > > It might also be worthwhile to look into the overall package/jar
> > > structure.
> > > > This will help for both OSGi and JPMS support.
> > > >
> > > > Regarding the Java14/JPMS target, I assume this means that the Jena
> > code
> > > > can be compiled and run on a Java14 environment and/or used on the
> > module
> > > > path in a JPMS-enabled application (and *not* that all downstream
> > > > applications must use one of the newer Java runtimes). That is, would
> > the
> > > > compiler target and source still be Java8?
> > > >
> > > > Cheers,
> > > > Aaron
> > > >
> > > > On Wed, 13 Nov 2019 at 14:18, Andy Seaborne  wrote:
> > > >
> > > > > I'd like to start a discussion on where the project might go longer
> > > term.
> > > > >
> > > > > This can be specific areas, overall design, about project
> processes,
> > > > > anything.
> > > > >
> > > > > If we are going to do a major change, Jena4, what preparation for
> > that
> > > > > can be done? (e.g. deprecation and signalling in Jena3, before the
> > > > > change happens).
> > > > >
> > > > > Realistically, Jena4 means having Jena3 and Jena4 in parallel.
> Jena4
> > > > > need not be that big - we can have Jena5 etc.
> > > > >
> > > > > I'll put some technical points in a separate email.
> > > > >
> > > > > I would put on the list:
> > > > >
> > > > > * How has the world changed? What should the project produce?
> > > > > * Target audience: for developers of Jena, while Jena3 is for
> users.
> > > > > * Target: Java14, JPMS.
> > > > > * Clear-up not easily done with perfect compatibility.
> > > > > * Simpler. There are APIs and packages entangled due to history.
> > > > >
> > > > > To the lurkers :-)
> > > > >
> > > > > Feedback and specific feature requests are welcome. But before you
> > "go
> > > > > shopping", you may wish to factor in that every feature needs
> effort
> > to
> > > > > do it. The better place to be is that an application can get what
> it
> > > > > needs to do, not whether the Jena system has every feature
> built-in.
> > > > >
> > > > >  Andy
> > > > >
> > > >
> > >
> > >
> > > --
> > > I like: Like Like - The likeliest place on the web
> > > 
> > > LinkedIn: http://www.linkedin.com/in/claudewarren
> > >
> >
> >
> > --
> >
> >
> > ---
> > Marco Neumann
> > KONA
> >
>
>
> --
> I like: Like Like - The likeliest place on the web
> 
> LinkedIn: http://www.linkedin.com/in/claudewarren
>


-- 


---
Marco Neumann
KONA

Re: Jena next

[Claude Warren]

Marco,

The permissions layer [1] is a separate module that wraps graph and model
implementations with permissions checking.  It can use Shiro (or whatever
Fuseki uses).

Basically, it uses the dynamic proxy mechanism to intercept "interesting"
calls to graph and model to filter out triples that should not be seen by
the user.  It operates at 2 distinct levels:  You can limit user access to
an entire graph/module or you can limit access to specific triples within
the graph/module.

I was recently wondering if anybody actually, (outside of the project I
worked on, used it in production.  I got an answer when I got a query about
how to do some specific task from a company that was utilizing it for a
number of implementations.

Claude

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

On Fri, Nov 15, 2019 at 11:24 AM Marco Neumann 
wrote:

> when you say as an afterthought you refer to shiro? to define permissions
> functionality in a TTL configuration for high granularity would indeed be
> nice. why not do it somewhat similar to how it's done in mainstream RDBMS
> with SQL system tables?
>
>
> On Fri, Nov 15, 2019 at 11:07 AM Claude Warren  wrote:
>
> > I would like to see the permissions functionality baked into the standard
> > implementations rather than wrapped around as an afterthought.  However,
> if
> > that can't be done or is just more overhead than we want when permissions
> > are not in use then I would hope that we will continue to use interfaces
> to
> > define the objects in the API.
> >
> > I think we should also look at Rya (https://rya.apache.org) and Commons
> > RDF
> > (https://commons.apache.org/proper/commons-rdf/index.html) to see if
> there
> > is anything we can learn from them.
> >
> > On Thu, Nov 14, 2019 at 8:09 PM Aaron Coburn  wrote:
> >
> > > I would be very interested in discussing the high level Java API and
> how
> > it
> > > could be simplified.
> > > It might also be worthwhile to look into the overall package/jar
> > structure.
> > > This will help for both OSGi and JPMS support.
> > >
> > > Regarding the Java14/JPMS target, I assume this means that the Jena
> code
> > > can be compiled and run on a Java14 environment and/or used on the
> module
> > > path in a JPMS-enabled application (and *not* that all downstream
> > > applications must use one of the newer Java runtimes). That is, would
> the
> > > compiler target and source still be Java8?
> > >
> > > Cheers,
> > > Aaron
> > >
> > > On Wed, 13 Nov 2019 at 14:18, Andy Seaborne  wrote:
> > >
> > > > I'd like to start a discussion on where the project might go longer
> > term.
> > > >
> > > > This can be specific areas, overall design, about project processes,
> > > > anything.
> > > >
> > > > If we are going to do a major change, Jena4, what preparation for
> that
> > > > can be done? (e.g. deprecation and signalling in Jena3, before the
> > > > change happens).
> > > >
> > > > Realistically, Jena4 means having Jena3 and Jena4 in parallel. Jena4
> > > > need not be that big - we can have Jena5 etc.
> > > >
> > > > I'll put some technical points in a separate email.
> > > >
> > > > I would put on the list:
> > > >
> > > > * How has the world changed? What should the project produce?
> > > > * Target audience: for developers of Jena, while Jena3 is for users.
> > > > * Target: Java14, JPMS.
> > > > * Clear-up not easily done with perfect compatibility.
> > > > * Simpler. There are APIs and packages entangled due to history.
> > > >
> > > > To the lurkers :-)
> > > >
> > > > Feedback and specific feature requests are welcome. But before you
> "go
> > > > shopping", you may wish to factor in that every feature needs effort
> to
> > > > do it. The better place to be is that an application can get what it
> > > > needs to do, not whether the Jena system has every feature built-in.
> > > >
> > > >  Andy
> > > >
> > >
> >
> >
> > --
> > I like: Like Like - The likeliest place on the web
> > 
> > LinkedIn: http://www.linkedin.com/in/claudewarren
> >
>
>
> --
>
>
> ---
> Marco Neumann
> KONA
>


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

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

[jira] [Resolved] (JENA-1778) COUNT(DISTINCT *) can generate incorrect results.

[Andy Seaborne (Jira)]

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

Andy Seaborne resolved JENA-1778.
-
Fix Version/s: Jena 3.14.0
   Resolution: Fixed

> COUNT(DISTINCT *) can generate incorrect results.
> -
>
> Key: JENA-1778
> URL: https://issues.apache.org/jira/browse/JENA-1778
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.13.1
>Reporter: Simon Fell
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.14.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Using COUNT(DISTINCT *) appears to generate the wrong result, in that it 
> appears to include system generated bindings as part of the solution when 
> DISTINCTing them. (I think similar to the issue in JENA-211).
> For example, I'd expect these 2 queries to return the same results, as ?lbl 
> should be the only variable considered part of the solutions.
> {code:java}
> SELECT (COUNT(DISTINCT *) as ?c)
> WHERE {  +/ ?lbl }
> {code}
> {code:java}
> SELECT (COUNT(DISTINCT ?lbl) as ?c)
> WHERE  {  +/ ?lbl }
> {code}
>  
> However these return different results. A full simple repro case is available 
> at https://github.com/superfell/jena-count-distinct-star
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (JENA-1776) RDFConnection with user/password fails intermittently on the second call.

[Andy Seaborne (Jira)]

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

Andy Seaborne resolved JENA-1776.
-
Fix Version/s: Jena 3.14.0
   Resolution: Fixed

> RDFConnection with user/password fails intermittently on the second call.
> -
>
> Key: JENA-1776
> URL: https://issues.apache.org/jira/browse/JENA-1776
> Project: Apache Jena
>  Issue Type: Improvement
>Affects Versions: Jena 3.13.1
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.14.0
>
> Attachments: Connect.java
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Report on [users@ 
> 2019-10-31|https://lists.apache.org/thread.html/2a12bd894a583f9f6c6651047f674c3a56231db78ce00ae72c9ffdb5@%3Cusers.jena.apache.org%3E].
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (JENA-1776) RDFConnection with user/password fails intermittently on the second call.

[Andy Seaborne (Jira)]

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

Andy Seaborne reassigned JENA-1776:
---

Assignee: Andy Seaborne

> RDFConnection with user/password fails intermittently on the second call.
> -
>
> Key: JENA-1776
> URL: https://issues.apache.org/jira/browse/JENA-1776
> Project: Apache Jena
>  Issue Type: Improvement
>Affects Versions: Jena 3.13.1
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Attachments: Connect.java
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Report on [users@ 
> 2019-10-31|https://lists.apache.org/thread.html/2a12bd894a583f9f6c6651047f674c3a56231db78ce00ae72c9ffdb5@%3Cusers.jena.apache.org%3E].
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JENA-1778) COUNT(DISTINCT *) can generate incorrect results.

[ASF subversion and git services (Jira)]

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

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

Commit 945143d75b0f71e0121b9428b429e32318028a13 in jena's branch 
refs/heads/master from Andy Seaborne
[ https://gitbox.apache.org/repos/asf?p=jena.git;h=945143d ]

JENA-1778: Hide system vars in COUNT(DISTINCT *)


> COUNT(DISTINCT *) can generate incorrect results.
> -
>
> Key: JENA-1778
> URL: https://issues.apache.org/jira/browse/JENA-1778
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.13.1
>Reporter: Simon Fell
>Assignee: Andy Seaborne
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Using COUNT(DISTINCT *) appears to generate the wrong result, in that it 
> appears to include system generated bindings as part of the solution when 
> DISTINCTing them. (I think similar to the issue in JENA-211).
> For example, I'd expect these 2 queries to return the same results, as ?lbl 
> should be the only variable considered part of the solutions.
> {code:java}
> SELECT (COUNT(DISTINCT *) as ?c)
> WHERE {  +/ ?lbl }
> {code}
> {code:java}
> SELECT (COUNT(DISTINCT ?lbl) as ?c)
> WHERE  {  +/ ?lbl }
> {code}
>  
> However these return different results. A full simple repro case is available 
> at https://github.com/superfell/jena-count-distinct-star
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JENA-1778) COUNT(DISTINCT *) can generate incorrect results.

[ASF subversion and git services (Jira)]

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

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

Commit bed564bf777b74d272424bcd6595a504d830db37 in jena's branch 
refs/heads/master from Andy Seaborne
[ https://gitbox.apache.org/repos/asf?p=jena.git;h=bed564b ]

Merge pull request #630 from afs/jena1778-distinct

JENA-1778: Hide system vars in COUNT(DISTINCT *)

> COUNT(DISTINCT *) can generate incorrect results.
> -
>
> Key: JENA-1778
> URL: https://issues.apache.org/jira/browse/JENA-1778
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.13.1
>Reporter: Simon Fell
>Assignee: Andy Seaborne
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Using COUNT(DISTINCT *) appears to generate the wrong result, in that it 
> appears to include system generated bindings as part of the solution when 
> DISTINCTing them. (I think similar to the issue in JENA-211).
> For example, I'd expect these 2 queries to return the same results, as ?lbl 
> should be the only variable considered part of the solutions.
> {code:java}
> SELECT (COUNT(DISTINCT *) as ?c)
> WHERE {  +/ ?lbl }
> {code}
> {code:java}
> SELECT (COUNT(DISTINCT ?lbl) as ?c)
> WHERE  {  +/ ?lbl }
> {code}
>  
> However these return different results. A full simple repro case is available 
> at https://github.com/superfell/jena-count-distinct-star
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JENA-1776) RDFConnection with user/password fails intermittently on the second call.

[ASF subversion and git services (Jira)]

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

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

Commit 2d5b86d5e91116ea3ba40d20e42295703c0c6d3e in jena's branch 
refs/heads/master from Andy Seaborne
[ https://gitbox.apache.org/repos/asf?p=jena.git;h=2d5b86d ]

JENA-1776: Set Content-Length when sending a graph or dataset


> RDFConnection with user/password fails intermittently on the second call.
> -
>
> Key: JENA-1776
> URL: https://issues.apache.org/jira/browse/JENA-1776
> Project: Apache Jena
>  Issue Type: Improvement
>Affects Versions: Jena 3.13.1
>Reporter: Andy Seaborne
>Priority: Major
> Attachments: Connect.java
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Report on [users@ 
> 2019-10-31|https://lists.apache.org/thread.html/2a12bd894a583f9f6c6651047f674c3a56231db78ce00ae72c9ffdb5@%3Cusers.jena.apache.org%3E].
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [jena] afs merged pull request #630: JENA-1778: Hide system vars in COUNT(DISTINCT *)

[GitBox]

afs merged pull request #630: JENA-1778: Hide system vars in COUNT(DISTINCT *)
URL: https://github.com/apache/jena/pull/630
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [jena] afs merged pull request #628: JENA-1776: Set Content-Length when sending a graph or dataset

[GitBox]

afs merged pull request #628: JENA-1776: Set Content-Length when sending a 
graph or dataset
URL: https://github.com/apache/jena/pull/628
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: Jena next

[Marco Neumann]

when you say as an afterthought you refer to shiro? to define permissions
functionality in a TTL configuration for high granularity would indeed be
nice. why not do it somewhat similar to how it's done in mainstream RDBMS
with SQL system tables?


On Fri, Nov 15, 2019 at 11:07 AM Claude Warren  wrote:

> I would like to see the permissions functionality baked into the standard
> implementations rather than wrapped around as an afterthought.  However, if
> that can't be done or is just more overhead than we want when permissions
> are not in use then I would hope that we will continue to use interfaces to
> define the objects in the API.
>
> I think we should also look at Rya (https://rya.apache.org) and Commons
> RDF
> (https://commons.apache.org/proper/commons-rdf/index.html) to see if there
> is anything we can learn from them.
>
> On Thu, Nov 14, 2019 at 8:09 PM Aaron Coburn  wrote:
>
> > I would be very interested in discussing the high level Java API and how
> it
> > could be simplified.
> > It might also be worthwhile to look into the overall package/jar
> structure.
> > This will help for both OSGi and JPMS support.
> >
> > Regarding the Java14/JPMS target, I assume this means that the Jena code
> > can be compiled and run on a Java14 environment and/or used on the module
> > path in a JPMS-enabled application (and *not* that all downstream
> > applications must use one of the newer Java runtimes). That is, would the
> > compiler target and source still be Java8?
> >
> > Cheers,
> > Aaron
> >
> > On Wed, 13 Nov 2019 at 14:18, Andy Seaborne  wrote:
> >
> > > I'd like to start a discussion on where the project might go longer
> term.
> > >
> > > This can be specific areas, overall design, about project processes,
> > > anything.
> > >
> > > If we are going to do a major change, Jena4, what preparation for that
> > > can be done? (e.g. deprecation and signalling in Jena3, before the
> > > change happens).
> > >
> > > Realistically, Jena4 means having Jena3 and Jena4 in parallel. Jena4
> > > need not be that big - we can have Jena5 etc.
> > >
> > > I'll put some technical points in a separate email.
> > >
> > > I would put on the list:
> > >
> > > * How has the world changed? What should the project produce?
> > > * Target audience: for developers of Jena, while Jena3 is for users.
> > > * Target: Java14, JPMS.
> > > * Clear-up not easily done with perfect compatibility.
> > > * Simpler. There are APIs and packages entangled due to history.
> > >
> > > To the lurkers :-)
> > >
> > > Feedback and specific feature requests are welcome. But before you "go
> > > shopping", you may wish to factor in that every feature needs effort to
> > > do it. The better place to be is that an application can get what it
> > > needs to do, not whether the Jena system has every feature built-in.
> > >
> > >  Andy
> > >
> >
>
>
> --
> I like: Like Like - The likeliest place on the web
> 
> LinkedIn: http://www.linkedin.com/in/claudewarren
>


-- 


---
Marco Neumann
KONA

Re: Jena next

[Claude Warren]

I would like to see the permissions functionality baked into the standard
implementations rather than wrapped around as an afterthought.  However, if
that can't be done or is just more overhead than we want when permissions
are not in use then I would hope that we will continue to use interfaces to
define the objects in the API.

I think we should also look at Rya (https://rya.apache.org) and Commons RDF
(https://commons.apache.org/proper/commons-rdf/index.html) to see if there
is anything we can learn from them.

On Thu, Nov 14, 2019 at 8:09 PM Aaron Coburn  wrote:

> I would be very interested in discussing the high level Java API and how it
> could be simplified.
> It might also be worthwhile to look into the overall package/jar structure.
> This will help for both OSGi and JPMS support.
>
> Regarding the Java14/JPMS target, I assume this means that the Jena code
> can be compiled and run on a Java14 environment and/or used on the module
> path in a JPMS-enabled application (and *not* that all downstream
> applications must use one of the newer Java runtimes). That is, would the
> compiler target and source still be Java8?
>
> Cheers,
> Aaron
>
> On Wed, 13 Nov 2019 at 14:18, Andy Seaborne  wrote:
>
> > I'd like to start a discussion on where the project might go longer term.
> >
> > This can be specific areas, overall design, about project processes,
> > anything.
> >
> > If we are going to do a major change, Jena4, what preparation for that
> > can be done? (e.g. deprecation and signalling in Jena3, before the
> > change happens).
> >
> > Realistically, Jena4 means having Jena3 and Jena4 in parallel. Jena4
> > need not be that big - we can have Jena5 etc.
> >
> > I'll put some technical points in a separate email.
> >
> > I would put on the list:
> >
> > * How has the world changed? What should the project produce?
> > * Target audience: for developers of Jena, while Jena3 is for users.
> > * Target: Java14, JPMS.
> > * Clear-up not easily done with perfect compatibility.
> > * Simpler. There are APIs and packages entangled due to history.
> >
> > To the lurkers :-)
> >
> > Feedback and specific feature requests are welcome. But before you "go
> > shopping", you may wish to factor in that every feature needs effort to
> > do it. The better place to be is that an application can get what it
> > needs to do, not whether the Jena system has every feature built-in.
> >
> >  Andy
> >
>


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

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

Re: Jena next

[Marco Neumann]

first of all Andy thank you for your leadership as PMC chair of the Apache
Jena project, the PMCs and the Jena community. I do believe Jena as a
technical project is in a good place to be considered as the development
choice for any possible RDF related effort at this point.

Over the last 20 years the semantic web community (yes 20 and the Jena
project will indeed turn 20 in 2020) has seen a number of transformations
that have also, in one way or another, found their technical expression in
form of new modules and / or capabilities in the Jena project.

I believe future versions of Jena need to be a bit bolder, this while
maintaining basic API features and design choices for compatibility in a
maintenance release. Jena 4 might be a good candidate for such a LTS
maintenance release while Jena 5 should take a more ambitious approach and
innovate where it hasn't made inroads in the technical community yet.
(SPARQL 1.2, RDF 2, parallelization/concurrency, improved scripting
support, web focus, UI, integration with other projects etc). I believe
last time we have seen such transformative change to Jena was for releases
2.7+ and the migration of the project to the Apache software foundation
almost 10 years ago.

And IMO an area that needs closer attention as well is documentation,
education and outreach. I am not sure where we currently stand in
regards to developer adoption, downloads and deployments etc but it would
be useful to gauge this type of information more systematically and more
regularly for project reviews.

Marco





On Wed, Nov 13, 2019 at 7:18 PM Andy Seaborne  wrote:

> I'd like to start a discussion on where the project might go longer term.
>
> This can be specific areas, overall design, about project processes,
> anything.
>
> If we are going to do a major change, Jena4, what preparation for that
> can be done? (e.g. deprecation and signalling in Jena3, before the
> change happens).
>
> Realistically, Jena4 means having Jena3 and Jena4 in parallel. Jena4
> need not be that big - we can have Jena5 etc.
>
> I'll put some technical points in a separate email.
>
> I would put on the list:
>
> * How has the world changed? What should the project produce?
> * Target audience: for developers of Jena, while Jena3 is for users.
> * Target: Java14, JPMS.
> * Clear-up not easily done with perfect compatibility.
> * Simpler. There are APIs and packages entangled due to history.
>
> To the lurkers :-)
>
> Feedback and specific feature requests are welcome. But before you "go
> shopping", you may wish to factor in that every feature needs effort to
> do it. The better place to be is that an application can get what it
> needs to do, not whether the Jena system has every feature built-in.
>
>  Andy
>


-- 


---
Marco Neumann
KONA