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 2019/11/13 19:19:04 UTC
Jena next
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
Re: [java runtime] Re: Jena next
Posted by aj...@apache.org.
I'm not sure how unusually slow Bruno's $work is. It's the same where I am
and I know of plenty of other places in academia or government that look
similar schedule-wise.
To be clear, I am not arguing for Java 8 beyond Jena 3-- instead (I think)
I'm agreeing with Bruno that we might want to think about 11 as a good
compromise between all the good new language features becoming available
and getting solid uptake.
That having been said, we're at the beginning of a long journey and things
may well look different by the time we've actually scoped 4.
ajs6f
On Tue, Nov 19, 2019, 8:38 AM Andy Seaborne <an...@apache.org> wrote:
>
>
> On 16/11/2019 23:55, Bruno P. Kinoshita wrote:
> >> What perspectives do other people have on the landscape?
> > My company is pretty slow in updating its stack. They have Java8 only
> now (and an isolated pod with java 5 or 6 for a legacy app I think). Not
> aware of any java9+ yet.
> > I think for Jena 4 we could go with Java LTS os LTS-next (assuming Jena4
> may take a while to be ready)?
> > Bruno
>
> So the real question is whether they would use a Java11 runtime - and
> for security reasons updating the JVM is a good idea (tm) - even if its
> running older code.
>
> That's what I am seeing - Java11 JVM for Java8 apps especially when
> deploying a new installation. The standard IT dept recipe is for Java11
> so it just happens that way.
>
> Andy
>
> >
> > Sent from Yahoo Mail on Android
> >
> > On Sun, 17 Nov 2019 at 10:41, Andy Seaborne<an...@apache.org> wrote:
> >
> > On 14/11/2019 20:08, Aaron Coburn wrote:
> >> I would be very interested in discussing the high level Java API and
> how it
> >> could be simplified.
> >
> > Let's take API discussion to [API] and not loose the other points.
> >
> >> It might also be worthwhile to look into the overall package/jar
> structure.
> >> This will help for both OSGi and JPMS support.
> >
> > Yes. The package structure is a current impedance.
> >
> >> 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?
> >
> > Actually, I was thinking Java14 APIs (var type inference improvements;
> > Java9 has Http/2; Java12,13 Switch Expressions; java14 NVM
> > MappedByteBuffer improvemnts) and language changes - so a Java14 runtime
> > is required.
> >
> > Modules would not be required of applications, and mixed JavaOld/Java14
> > code can be run on a Java14 JVM.
> >
> > This is something we need to agree on first.
> >
> > If we going to move from Java8, we might as well jump to Java14.
> >
> > Jena3 remains for some overlap period.
> >
> > I think the Java version factor is changed by the slow demise of
> > multi-application platforms (e.g. Tomcat + multiple WAR files).
> > Container and microservices isolate the Java choice.
> >
> > Java8 EOL is September 2023 (End of free public updates by AdoptOpenJDK)
> > which is the same as Java11.
> >
> > What perspectives do other people have on the landscape?
> >
> > Andy
> >
> >>
> >> Cheers,
> >> Aaron
> >>
> >> On Wed, 13 Nov 2019 at 14:18, Andy Seaborne <an...@apache.org> 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
> >>>
> >>
> >
> >
>
Re: [java runtime] Re: Jena next
Posted by Andy Seaborne <an...@apache.org>.
On 16/11/2019 23:55, Bruno P. Kinoshita wrote:
>> What perspectives do other people have on the landscape?
> My company is pretty slow in updating its stack. They have Java8 only now (and an isolated pod with java 5 or 6 for a legacy app I think). Not aware of any java9+ yet.
> I think for Jena 4 we could go with Java LTS os LTS-next (assuming Jena4 may take a while to be ready)?
> Bruno
So the real question is whether they would use a Java11 runtime - and
for security reasons updating the JVM is a good idea (tm) - even if its
running older code.
That's what I am seeing - Java11 JVM for Java8 apps especially when
deploying a new installation. The standard IT dept recipe is for Java11
so it just happens that way.
Andy
>
> Sent from Yahoo Mail on Android
>
> On Sun, 17 Nov 2019 at 10:41, Andy Seaborne<an...@apache.org> wrote:
>
> On 14/11/2019 20:08, Aaron Coburn wrote:
>> I would be very interested in discussing the high level Java API and how it
>> could be simplified.
>
> Let's take API discussion to [API] and not loose the other points.
>
>> It might also be worthwhile to look into the overall package/jar structure.
>> This will help for both OSGi and JPMS support.
>
> Yes. The package structure is a current impedance.
>
>> 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?
>
> Actually, I was thinking Java14 APIs (var type inference improvements;
> Java9 has Http/2; Java12,13 Switch Expressions; java14 NVM
> MappedByteBuffer improvemnts) and language changes - so a Java14 runtime
> is required.
>
> Modules would not be required of applications, and mixed JavaOld/Java14
> code can be run on a Java14 JVM.
>
> This is something we need to agree on first.
>
> If we going to move from Java8, we might as well jump to Java14.
>
> Jena3 remains for some overlap period.
>
> I think the Java version factor is changed by the slow demise of
> multi-application platforms (e.g. Tomcat + multiple WAR files).
> Container and microservices isolate the Java choice.
>
> Java8 EOL is September 2023 (End of free public updates by AdoptOpenJDK)
> which is the same as Java11.
>
> What perspectives do other people have on the landscape?
>
> Andy
>
>>
>> Cheers,
>> Aaron
>>
>> On Wed, 13 Nov 2019 at 14:18, Andy Seaborne <an...@apache.org> 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
>>>
>>
>
>
Re: [java runtime] Re: Jena next
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>.
>What perspectives do other people have on the landscape?
My company is pretty slow in updating its stack. They have Java8 only now (and an isolated pod with java 5 or 6 for a legacy app I think). Not aware of any java9+ yet.
I think for Jena 4 we could go with Java LTS os LTS-next (assuming Jena4 may take a while to be ready)?
Bruno
Sent from Yahoo Mail on Android
On Sun, 17 Nov 2019 at 10:41, Andy Seaborne<an...@apache.org> wrote:
On 14/11/2019 20:08, Aaron Coburn wrote:
> I would be very interested in discussing the high level Java API and how it
> could be simplified.
Let's take API discussion to [API] and not loose the other points.
> It might also be worthwhile to look into the overall package/jar structure.
> This will help for both OSGi and JPMS support.
Yes. The package structure is a current impedance.
> 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?
Actually, I was thinking Java14 APIs (var type inference improvements;
Java9 has Http/2; Java12,13 Switch Expressions; java14 NVM
MappedByteBuffer improvemnts) and language changes - so a Java14 runtime
is required.
Modules would not be required of applications, and mixed JavaOld/Java14
code can be run on a Java14 JVM.
This is something we need to agree on first.
If we going to move from Java8, we might as well jump to Java14.
Jena3 remains for some overlap period.
I think the Java version factor is changed by the slow demise of
multi-application platforms (e.g. Tomcat + multiple WAR files).
Container and microservices isolate the Java choice.
Java8 EOL is September 2023 (End of free public updates by AdoptOpenJDK)
which is the same as Java11.
What perspectives do other people have on the landscape?
Andy
>
> Cheers,
> Aaron
>
> On Wed, 13 Nov 2019 at 14:18, Andy Seaborne <an...@apache.org> 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
>>
>
[java runtime] Re: Jena next
Posted by Andy Seaborne <an...@apache.org>.
On 14/11/2019 20:08, Aaron Coburn wrote:
> I would be very interested in discussing the high level Java API and how it
> could be simplified.
Let's take API discussion to [API] and not loose the other points.
> It might also be worthwhile to look into the overall package/jar structure.
> This will help for both OSGi and JPMS support.
Yes. The package structure is a current impedance.
> 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?
Actually, I was thinking Java14 APIs (var type inference improvements;
Java9 has Http/2; Java12,13 Switch Expressions; java14 NVM
MappedByteBuffer improvemnts) and language changes - so a Java14 runtime
is required.
Modules would not be required of applications, and mixed JavaOld/Java14
code can be run on a Java14 JVM.
This is something we need to agree on first.
If we going to move from Java8, we might as well jump to Java14.
Jena3 remains for some overlap period.
I think the Java version factor is changed by the slow demise of
multi-application platforms (e.g. Tomcat + multiple WAR files).
Container and microservices isolate the Java choice.
Java8 EOL is September 2023 (End of free public updates by AdoptOpenJDK)
which is the same as Java11.
What perspectives do other people have on the landscape?
Andy
>
> Cheers,
> Aaron
>
> On Wed, 13 Nov 2019 at 14:18, Andy Seaborne <an...@apache.org> 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
>>
>
Re: Jena next
Posted by Marco Neumann <ma...@gmail.com>.
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 <cl...@xenei.com> 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 <ma...@gmail.com>
> 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 <cl...@xenei.com> 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 <ac...@apache.org>
> 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 <an...@apache.org> 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
> > > <http://like-like.xenei.com>
> > > LinkedIn: http://www.linkedin.com/in/claudewarren
> > >
> >
> >
> > --
> >
> >
> > ---
> > Marco Neumann
> > KONA
> >
>
>
> --
> I like: Like Like - The likeliest place on the web
> <http://like-like.xenei.com>
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
--
---
Marco Neumann
KONA
Re: Jena next
Posted by Claude Warren <cl...@xenei.com>.
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 <ma...@gmail.com>
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 <cl...@xenei.com> 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 <ac...@apache.org> 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 <an...@apache.org> 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
> > <http://like-like.xenei.com>
> > LinkedIn: http://www.linkedin.com/in/claudewarren
> >
>
>
> --
>
>
> ---
> Marco Neumann
> KONA
>
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: Jena next
Posted by Marco Neumann <ma...@gmail.com>.
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 <cl...@xenei.com> 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 <ac...@apache.org> 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 <an...@apache.org> 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
> <http://like-like.xenei.com>
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
--
---
Marco Neumann
KONA
Re: Jena next
Posted by Andy Seaborne <an...@apache.org>.
On 15/11/2019 11:07, 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.
Certainly interfaces.
If the new API is not additions/modifications of the existing one, I
think we should have the current one and introduce a new API.
What would be the requirements for permissions-extensions? If not in
use, I'd like it to be invisible - security can also be in application
via request processing (the usual ACL stuff).
Clause also wrote:
> 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 am curious as to whether the permissions capabilities could be
provided at the Graph level on find/add/delete.
> 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.
Yes - are there specific aspects you have in mind?
We can not adopt CommonsRDF raw - the idea of just adding the interfaces
to existing Graph or Model unfortunately is messy with different methods
to do the same thing - an autocomplete nightmare.
We can provide an API module that is CommonsRDF over Graph.
Is there much code nowadays that uses CommonsRDF as its target? I have
always hoped we see the emergence of projects with algorithms that
target CommonsRDF for portability.
Andy
>
> On Thu, Nov 14, 2019 at 8:09 PM Aaron Coburn <ac...@apache.org> 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 <an...@apache.org> 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
>>>
>>
>
>
Re: Jena next
Posted by Claude Warren <cl...@xenei.com>.
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 <ac...@apache.org> 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 <an...@apache.org> 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
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: Jena next
Posted by Aaron Coburn <ac...@apache.org>.
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 <an...@apache.org> 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
>
Re: Jena next
Posted by Andy Seaborne <an...@apache.org>.
On 15/11/2019 09:49, Marco Neumann wrote:
> 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.
Agreed - there should be a system which is production-stable, certainly
covering up to Fuseki+text with extension points.
Then there are evolving modules.
For example, SPARQL 1.2 does not destabilize SPARQL 1.1 - that may mean
1.2 is separate and optionally replaces 1.1. When some 1.2 features are
considered stable, they move to core-ARQ.
And some things like first steps in concurrency for ARQ don't need to be
in 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.
Jena3 is LTS in practice.
Given we have non-dedicated resources, I don't think it is helpful to
ourselves to set up some grand long term roadmap that we can't
realistically achieve. What will happen is that progress will be
demotivating slow when measured against the ultimate goals.
If more people become active contributors or some of us can get
resourcing, then that can change.
Andy
> (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 <an...@apache.org> 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
>>
>
>
Re: Jena next
Posted by Marco Neumann <ma...@gmail.com>.
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 <an...@apache.org> 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
Re: Jena next
Posted by Andy Seaborne <an...@apache.org>.
On 14/11/2019 22:39, Bruno P. Kinoshita wrote:
> Maybe an upgrade on Fuseki UI? Last I checked it was using Backbone JS, with dependencies bundled in the code. Even though the NPM/JS ecosystem is a bit more complex, we could probably upgrade it to
Maybe worth starting as a new UI, write the requirements and definition,
which may be less or different to the current one, and see whether
change or write fresh is better. If we make it a React webapp (or other
similar), then more likely "fresh" and copy what we can.
Oh - and it greatly simplify the licensing if we didn't have to
incorporate JS into the code base.
> - use a framework- specify dependencies in package.json (good to monitor for security issues)
> - use sass/scss for styling- have a few tests in the JS project too- allow for user extensions (i.e. changing how it looks, i18n, rtl-ltr, either provide a way for users to customize it or just document where they could get started, etc)
> At the moment I am 30% doing Python, and 70% JS at $work (plus a bunch of spare time to get up to speed with the JS world). That will continue until Oct/2020 or later if the project confirms more funding/grants/etc. So that's something I could help with during next year.
> The other thing I think is already planned, but removing deprecated or unused stuff is always helpful.
Smaller is better!
>
> CheersBruno
>
>
> On Thursday, 14 November 2019, 8:18:31 am NZDT, Andy Seaborne <an...@apache.org> 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
>
>
Re: Jena next
Posted by "Bruno P. Kinoshita" <ki...@apache.org>.
Maybe an upgrade on Fuseki UI? Last I checked it was using Backbone JS, with dependencies bundled in the code. Even though the NPM/JS ecosystem is a bit more complex, we could probably upgrade it to
- use a framework- specify dependencies in package.json (good to monitor for security issues)
- use sass/scss for styling- have a few tests in the JS project too- allow for user extensions (i.e. changing how it looks, i18n, rtl-ltr, either provide a way for users to customize it or just document where they could get started, etc)
At the moment I am 30% doing Python, and 70% JS at $work (plus a bunch of spare time to get up to speed with the JS world). That will continue until Oct/2020 or later if the project confirms more funding/grants/etc. So that's something I could help with during next year.
The other thing I think is already planned, but removing deprecated or unused stuff is always helpful.
CheersBruno
On Thursday, 14 November 2019, 8:18:31 am NZDT, Andy Seaborne <an...@apache.org> 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