Re: Issue with Turtle serialization

[Martynas Jusevičius]

I think the output is equivalent to the input - two different ways to
encode the same string.

On Sat, 31 Aug 2024 at 09.20, Chavdar Ivanov  wrote:

> Hello all,
>
> I noticed something around the support for multiline literals
>
> It seems it is possible to have this for RDFXML writers, but for the
> Turtle I am getting single line
>
> I looked in the spec RDF 1.1 Turtle (w3.org)
> under 2.5.1 we have this example
>
>
> show:218 show:blurb '''This is a multi-line#
> literal with embedded new lines and quotes
> literal with many quotes (")
> and up to two sequential apostrophes ('').''' .
>
> I did a test
>
> Input
> l3igm:test
> a   sh:PropertyGroup ;
> rdfs:label  "test" ;
> sh:order0 ;
> l3igm:blurb '''This is a multi-line
> literal with many quotes (")
> and up to two sequential apostrophes ('').''' .
>
>
> When this is read and then serialized back to ttl I get this
>
> l3igm:test  rdf:type  sh:PropertyGroup;
> rdfs:label   "test";
> sh:order 0;
> l3igm:blurb  "This is a multi-line
>  \r\nliteral with many quotes (\"\"\"\"\")\r\nand up to two sequential
> apostrophes ('')." .
>
>
> I am using this way of writer
>
>
> RDFWriter.create()
> .base("https://test.eu/test";)
> .set(RIOT.symTurtleOmitBase, false)
> .set(RIOT.symTurtleIndentStyle, "wide")
> .set(RIOT.symTurtleDirectiveStyle, "rdf10")
> .lang(Lang.TURTLE)
> .source(model)
> .output(out);
>
> Is there something I am doing wrong or this is a bug to be fixed? If a
> bug, where the fix should be?
>
> Best regards
> Chavdar
>
>

Re: Updates for sparql.org

[Martynas Jusevičius]

Maybe http://sparql.org should redirect to https://sparql.org?

On Thu, Mar 30, 2023 at 3:03 PM Andy Seaborne  wrote:
>
> Claude,
>
> Thank you for doing this. https works now as well which is great.
>
> One question: the ASF Infra email mentioned
>
> On 29/03/2023 12:43, Claude Warren wrote:
> > Greetings,
> >
> > After several attempts the sparql.org site is automated.  There was a
> > recent announcement from infrastructure indicating that they would be
> > automating reboots to handle system updates.  The changes listed below were
> > undertaken to ensure that the sparql.org site would restart properly.
> >
> > I modified
> > https://github.com/apache/infrastructure-p6/blob/production/data/nodes/jena-vm.apache.org.yaml
> > to add the uu_asf entry to send reboot notifications to dev@jena.a.o and
> > added proxy pass info to the sparql-ssl section.
>
> If the reboots become too frequent (I hope not) emal can be redirected
> but i think for now, dev@ is fine.
>
> FYI all: the server runs Ubuntu 20.04.6 LTS
>
> > On the jena-vm.apache.org server (where sparql.org is alised) I created an
> > /etc/jena directory and
> > copied files from /home/andy/sparqler to /etc/jena/sparqler.
> >
> > Updates for sparqler should now be performed in the /etc/jena/sparqler
> > directory.
>
> And I've moved the old stuff into a dumping area to make sure I see that
> the upgrade should be done elsewhere.
>
> >
> > I created sparqler.service starts after apache2.service and uses
> > "ExecStart=/etc/jena/sparqler/run-sparqler" and "ExecStop=/usr/bin/pkill -f
> > fuseki" to start and stop the Fuseki engine after setting
> > "Environment=BACKGROUND=0" to force operation in the foreground.
> >
> > I created a symbolic link from  /lib/systemd/system/sparqler.service to
> > /etc/jena/sparqler.service and executed `systemctl enable sparqler.service`
> > to ensure the system starts and stops as required during rebooting.
> >
> > We might want to consider adding sparqler.service as a fuseki.service into
> > one of the subprojects as an example of how to start/stop using systemd.
>
> Yes - where do you suggest?
>
> Either jena-fuseki2/examples or jena-fuseki2/jena-fuseki-main/sparqler
> (and the latter could usefully be moved out .. but separate matter).
>
> > This should resolve any issues with rebooting the sparql.org system.
> >
> > Claude
> >
>
> Works great!
>
>  Andy

Re: Towards Jena 4.7.0

[Martynas Jusevičius]

Updated based on Andy's comments + support for Writer registries as well.
https://github.com/apache/jena/pull/1682

On Fri, Dec 16, 2022 at 11:04 AM rve...@dotnetrdf.org
 wrote:
>
> Looks nice and straightforward, have approved and merged
>
> Thanks,
>
> Rob
>
> From: Martynas Jusevičius 
> Date: Thursday, 15 December 2022 at 21:49
> To: dev@jena.apache.org 
> Subject: Re: Towards Jena 4.7.0
> I'd like to add https://github.com/apache/jena/pull/1677 if it's not
> too late. I think it's pretty low risk.
>
> On Thu, Dec 15, 2022 at 10:12 PM Andy Seaborne  wrote:
> >
> >
> >
> > On 01/12/2022 18:12, Andy Seaborne wrote:
> > > This is progressing - hopefully sometime between mid December and
> > > Christmas.
> > >
> > > There have been a lot of changes, and there are some nearly but not
> > > quite there yet PRs.
> > >
> > > It is in a sufficiently completed state now that the development
> > > codebase  can be tested as widely as possible.
> > >
> > > I like to have a period of stability. This reduces the risk of
> > > unexpected changes in the 4.7.0 release.
> >
> > Hopefully final PRs have gone in.
> >
> > There is a sort ordering issue outstanding. I have a branch which needs
> > cleaning but does address the issue. For something like this, I think
> > its too late to put into the release, there being a chance of unexpected
> > corner cases.
> >
> >  Andy

Re: Towards Jena 4.7.0

[Martynas Jusevičius]

I'd like to add https://github.com/apache/jena/pull/1677 if it's not
too late. I think it's pretty low risk.

On Thu, Dec 15, 2022 at 10:12 PM Andy Seaborne  wrote:
>
>
>
> On 01/12/2022 18:12, Andy Seaborne wrote:
> > This is progressing - hopefully sometime between mid December and
> > Christmas.
> >
> > There have been a lot of changes, and there are some nearly but not
> > quite there yet PRs.
> >
> > It is in a sufficiently completed state now that the development
> > codebase  can be tested as widely as possible.
> >
> > I like to have a period of stability. This reduces the risk of
> > unexpected changes in the 4.7.0 release.
>
> Hopefully final PRs have gone in.
>
> There is a sort ordering issue outstanding. I have a branch which needs
> cleaning but does address the issue. For something like this, I think
> its too late to put into the release, there being a chance of unexpected
> corner cases.
>
>  Andy

Re: About JENA-2339 - security related

[Martynas Jusevičius]

On Mon, 8 Aug 2022 at 18.06, Vilnis Termanis
 wrote:

> On Mon, 1 Aug 2022 at 12:29, Andy Seaborne  wrote:
> >
> >
> >
> > On 28/07/2022 20:50, Vilnis Termanis wrote:
> > > Hi Andy & Jena development community,
> > >
> > > (Answers inline - apologies if I repeat myself)
> > >
> > > FYI - Our aim is to enable end-users to make SPARQL queries whilst
> > > respecting visibility restrictions.
> > > I.e. users (indirectly) add sets of related triples to a dataset and
> > > they can choose who has visibility (beyond themselves) over these,
> > > either: Nobody, Everyone or a chosen set (which can be updated). Note
> > > that this restriction is not by a specific subject or predicate.
> > > (Although the sets of triples do have relationships - not all of them
> > > are known in advance.)
> >
> > Let's clarify terminology here.
> >
> > A "Jena user" is a person or organisation that is downloading Jena,
> > either as the formal release (source code) or convenience binaries (e.g.
> > jars from Maven Central). The "convenience binaries" is the more usual
> case.
> >
> > Not Iotics users. Systems built with Jena have their own users.
> > (The Apache License applies - including clause 7.)
> >
> > The responsibility is between the downstream system builder and their
> > users of product or service being "fit for purpose".
>
> Sorry about that - I should have been clearer with the terms.
>
> In the submission - there is only one entity - the "Fuseki user" (e.g.
> via BasicAuth) to which the dynamic mode applies. However, since this
> is intended to be used a part of an integration (by Jena users - to
> gate access to their own domain-specific end-users), the
> authentication bit I think is irrelevant. (E.g. a separate service
> endpoint could have the proposed functionality enabled and this is
> what the integration calls.)
>
> >
> > > using a "SELECT {} 1" query, and
> > > adding a certain set of graphs makes the queries on my laptop take:
> > > ~600 graphs ~115ms
> > > ~1500 graphs ~162ms
> > > ~3k graphs ~240ms
> > > ~6k graphs ~400ms
> >
> > That's an illustration of the current system but we don't know what is
> > the cause of the cost.
> >
> > What piece of the code is taking the time?
> > Maybe the right thing to do is make it faster.
>
> I haven't looked into this in great detail, but from my understanding
> the time taken is a combination of a) parsing the input of allowed
> graphs and b) generating a new SecurityContext (holding a hashmap of
> said graphs). If providing a set of allowed graphs in the proposed way
> is not a no-go, I'm happy to dig into where the cost is exactly.
>
> >
> > And in the general area - what are you using for authentication?
> >
>
> For us right now, we're only using fuseki:auth "basic" for the
> purposes of differentiating different access levels against Fuseki
> Data Access Control configuration (by mapping those to Fuseki users),
> e.g.:
> Fuseki user1 => allowed to see graphs A & B
> Fuseki user2 => allowed to see graphs B & C
> Fuseki user3 => has the proposed feature dynamic-access feature
> enabled (i.e. no access unless the pragma preamble exists in query
> with 1+ graphs defined)
>
> Said Fuseki users (=roles) are then chosen based on what the system
> needs to do (domain-specific).
>
> > There is some bearer auth support in the next release ... it does not
> > provide complete bearer auth because it can't cover all cases (e.g. JWT
> > validation). It is more of a framework template with which to build a
> > local solution.
>
> I'm showing my lack of JWT/Bearer auth knowledge - but is this
> building block for what Martynas suggested, namely the token implies
> the user to which dynamic ACL applies and then access can be
> restricted e.g. via WACL/Solid? (Correct me if I'm wrong but is  this
> still not a solution that involves ACL rules being stored in Jena or
> at least be accessible via SPARQL for a SERVICE call?)
>

LinkedDataHub identifies agents with URIs, which can be called WebIDs [1].
Currently it supports WebID-TLS and OIDC with JWT tokens as authentication
protocols. Authorization is checked using WAC as mentioned earlier.

We use 2 Fuseki endpoints for each webapp instance: “end-user” and “admin”.
The auth queries federate between them using SERVICE. Sandboxing them might
be a little tricky, but in general it has worked well and did not require
any new security features in Fuseki.

[1] https://www.w3.org/2005/Incubator/webid/spec/
[2] https://github.com/AtomGraph/LinkedDataHub/issues/107


> >
> > 
> >
> > "FMod_ABAC" is not related to jena-permissions.
> >
> > "FMod_" means Fuseki Module.
> > https://jena.apache.org/documentation/fuseki2/fuseki-modules
> > No forks.
> > ABAC = Attribute Based Access Control.
> >
> > Using attributes separates ACLs from direct naming users for access to
> > things. FMod_ABAC things are triples. Triples have "labels". Labels are
> > attribute expressions, including AND and OR operators.
> >
> >  "employee | contractor"

Re: About JENA-2339 - security related

[Martynas Jusevičius]

On Mon, 8 Aug 2022 at 17.21, Vilnis Termanis
 wrote:

> On Sat, 30 Jul 2022 at 21:14, Martynas Jusevičius
>  wrote:
> >
> > On Fri, Jul 29, 2022 at 7:27 PM Vilnis Termanis
> >  wrote:
> > >
> > > (inline)
> > >
> > > On Fri, 29 Jul 2022 at 07:56, Martynas Jusevičius
> > >  wrote:
> > > >
> > > > “Sets of triples” — aren’t these datasets?
> > > >
> > > > Couldn’t this use case be addressed by maintaining per-user
> datasets? Not
> > > > sure if Fuseki can create datasets on the fly, but this seems like a
> much
> > > > simpler feature to implement compared to a whole new ACL mechanism.
> > >
> > > The idea is, that if you had these "sets of triples" A-Z, one user
> > > might be allowed to see A-M and another C-Q. With per-user datasets
> > > you'd have to duplicate data to achieve that. And, when the ACL
> > > changes, you'd have to copy/move triples from one dataset to another.
> > > (Or am I missing a nuance to your proposal? Do you mean dynamically
> > > creating a new dataset which references graphs from another dataset?)
> >
> > No, not missing :)
> >
> > I mean it sounds like a useful feature, and we could probably find use
> > for it ourselves.
> >
> > But if the ACL is graph-scoped, can't it employ an existing ontology
> > such as WAC? [1]
> > It would be eating your own dogfood, and of course it being RDF you
> > could query and update your ACL using SPARQL.That would probably
> > require a meta-dataset containing ACL data for each secured dataset.
>
> It definitely could (and in fact, we are doing pretty much what you
> describe right now).
> However, thinking in general terms - aren't there two levels to such
> an ACL solution:
>
> 1) ACL is treated as completely external to Jena/Fuseki: Something
> else is responsible for providing the "allow list" of graphs. (And:
> Ideally there is no hard requirement to require a Java integration to
> use the feature.)


This option has the advantage of not being specific to Fuseki, meaning thay
it can work with any triplestore. The access check is encapsulated as a
SPARQL query and can be easily reused accross frameworks.


> 2) ACL is enabled by storing rules in a specific graph in a Jena
> dataset (and there I agree WAC seems very sensible - as you've
> linked).
>
> I'm querying about (1) where Jena/Fuseki is not necessarily the centre
> of the picture, but part of multiple components.
>
> >
> > As it happens we have an authorization request filter for Jersey that
> > checks WAC access using SPARQL:
> >
> https://github.com/AtomGraph/LinkedDataHub/blob/master/src/main/java/com/atomgraph/linkeddatahub/server/filter/request/AuthorizationFilter.java
> > The SPARQL query:
> >
> https://github.com/AtomGraph/LinkedDataHub/blob/master/src/main/webapp/WEB-INF/web.xml#L25
> >
> > [1] https://www.w3.org/wiki/WebAccessControl
> >
> > >
> > > >
> > > > On Thu, 28 Jul 2022 at 22.51, Vilnis Termanis
> > > >  wrote:
> > > >
> > > > > Hi Andy & Jena development community,
> > > > >
> > > > > (Answers inline - apologies if I repeat myself)
> > > > >
> > > > > FYI - Our aim is to enable end-users to make SPARQL queries whilst
> > > > > respecting visibility restrictions.
> > > > > I.e. users (indirectly) add sets of related triples to a dataset
> and
> > > > > they can choose who has visibility (beyond themselves) over these,
> > > > > either: Nobody, Everyone or a chosen set (which can be updated).
> Note
> > > > > that this restriction is not by a specific subject or predicate.
> > > > > (Although the sets of triples do have relationships - not all of
> them
> > > > > are known in advance.)
> > > > >
> > > > > On Thu, 28 Jul 2022 at 10:43, Andy Seaborne 
> wrote:
> > > > > >
> > > > > > JENA-2339
> > > > > > PR#1441
> > > > > >
> > > > >
> https://github.com/vtermanis/jena/blob/dynamic-graph-restriction-extension/MOVE_ME_DynamicACL_notes.md
> > > > > >
> > > > > > tl;dr:
> > > > > >
> > > > > > It is a different role for Fuseki.
> > > > > >
> > > > > > Fuseki execute the security but the setup and control is from a
> trusted
> > > > > > external serv

Re: About JENA-2339 - security related

[Martynas Jusevičius]

On Fri, Jul 29, 2022 at 7:27 PM Vilnis Termanis
 wrote:
>
> (inline)
>
> On Fri, 29 Jul 2022 at 07:56, Martynas Jusevičius
>  wrote:
> >
> > “Sets of triples” — aren’t these datasets?
> >
> > Couldn’t this use case be addressed by maintaining per-user datasets? Not
> > sure if Fuseki can create datasets on the fly, but this seems like a much
> > simpler feature to implement compared to a whole new ACL mechanism.
>
> The idea is, that if you had these "sets of triples" A-Z, one user
> might be allowed to see A-M and another C-Q. With per-user datasets
> you'd have to duplicate data to achieve that. And, when the ACL
> changes, you'd have to copy/move triples from one dataset to another.
> (Or am I missing a nuance to your proposal? Do you mean dynamically
> creating a new dataset which references graphs from another dataset?)

No, not missing :)

I mean it sounds like a useful feature, and we could probably find use
for it ourselves.

But if the ACL is graph-scoped, can't it employ an existing ontology
such as WAC? [1]
It would be eating your own dogfood, and of course it being RDF you
could query and update your ACL using SPARQL.That would probably
require a meta-dataset containing ACL data for each secured dataset.

As it happens we have an authorization request filter for Jersey that
checks WAC access using SPARQL:
https://github.com/AtomGraph/LinkedDataHub/blob/master/src/main/java/com/atomgraph/linkeddatahub/server/filter/request/AuthorizationFilter.java
The SPARQL query:
https://github.com/AtomGraph/LinkedDataHub/blob/master/src/main/webapp/WEB-INF/web.xml#L25

[1] https://www.w3.org/wiki/WebAccessControl

>
> >
> > On Thu, 28 Jul 2022 at 22.51, Vilnis Termanis
> >  wrote:
> >
> > > Hi Andy & Jena development community,
> > >
> > > (Answers inline - apologies if I repeat myself)
> > >
> > > FYI - Our aim is to enable end-users to make SPARQL queries whilst
> > > respecting visibility restrictions.
> > > I.e. users (indirectly) add sets of related triples to a dataset and
> > > they can choose who has visibility (beyond themselves) over these,
> > > either: Nobody, Everyone or a chosen set (which can be updated). Note
> > > that this restriction is not by a specific subject or predicate.
> > > (Although the sets of triples do have relationships - not all of them
> > > are known in advance.)
> > >
> > > On Thu, 28 Jul 2022 at 10:43, Andy Seaborne  wrote:
> > > >
> > > > JENA-2339
> > > > PR#1441
> > > >
> > > https://github.com/vtermanis/jena/blob/dynamic-graph-restriction-extension/MOVE_ME_DynamicACL_notes.md
> > > >
> > > > tl;dr:
> > > >
> > > > It is a different role for Fuseki.
> > > >
> > > > Fuseki execute the security but the setup and control is from a trusted
> > > > external server on the request execution path.
> > > >
> > > > It assumes certain deployment environments to be safe.
> > >
> > > FYI - In our case this means that we have a "make SPARQL query" API
> > > call. When received, the applicable user (our domain) is known and, in
> > > the proposed PR, we can prepend the set of allowed graphs to the query
> > > (which have been looked up prior to query execution, externally). The
> > > end user has NO direct access to Fuseki itself.
> > >
> > > >
> > > > My feeling is that we should make Fuseki configurable enough so that a
> > > > downstream 3rd party can add their security solution that is suitable
> > > > for their environment. But we should not incorporate a particular
> > > > security solution that relies on the deployment environment.
> > > >
> > > > 
> > > >
> > > > I've asked for more information about the claim on a performance
> > > > motivator and some other background information.
> > > >
> > > > The usage patterns are not yet clear. The data is described as "a one
> > > > graph per handful of subjects and their properties" and "100s of
> > > > graphs". What the queries are is unstated.
> > >
> > > Right now, each graph has in the range of 300-500 triples (though the
> > > amount depends on how much additional/domain-specific metadata
> > > end-users choose to add) and the scale of deployed Fuseki datasets
> > > range from having a few to ~6k graphs.
> > > Since we'd like to allow end-users to run **any** queries they wish
>

Re: About JENA-2339 - security related

[Martynas Jusevičius]

“Sets of triples” — aren’t these datasets?

Couldn’t this use case be addressed by maintaining per-user datasets? Not
sure if Fuseki can create datasets on the fly, but this seems like a much
simpler feature to implement compared to a whole new ACL mechanism.

On Thu, 28 Jul 2022 at 22.51, Vilnis Termanis
 wrote:

> Hi Andy & Jena development community,
>
> (Answers inline - apologies if I repeat myself)
>
> FYI - Our aim is to enable end-users to make SPARQL queries whilst
> respecting visibility restrictions.
> I.e. users (indirectly) add sets of related triples to a dataset and
> they can choose who has visibility (beyond themselves) over these,
> either: Nobody, Everyone or a chosen set (which can be updated). Note
> that this restriction is not by a specific subject or predicate.
> (Although the sets of triples do have relationships - not all of them
> are known in advance.)
>
> On Thu, 28 Jul 2022 at 10:43, Andy Seaborne  wrote:
> >
> > JENA-2339
> > PR#1441
> >
> https://github.com/vtermanis/jena/blob/dynamic-graph-restriction-extension/MOVE_ME_DynamicACL_notes.md
> >
> > tl;dr:
> >
> > It is a different role for Fuseki.
> >
> > Fuseki execute the security but the setup and control is from a trusted
> > external server on the request execution path.
> >
> > It assumes certain deployment environments to be safe.
>
> FYI - In our case this means that we have a "make SPARQL query" API
> call. When received, the applicable user (our domain) is known and, in
> the proposed PR, we can prepend the set of allowed graphs to the query
> (which have been looked up prior to query execution, externally). The
> end user has NO direct access to Fuseki itself.
>
> >
> > My feeling is that we should make Fuseki configurable enough so that a
> > downstream 3rd party can add their security solution that is suitable
> > for their environment. But we should not incorporate a particular
> > security solution that relies on the deployment environment.
> >
> > 
> >
> > I've asked for more information about the claim on a performance
> > motivator and some other background information.
> >
> > The usage patterns are not yet clear. The data is described as "a one
> > graph per handful of subjects and their properties" and "100s of
> > graphs". What the queries are is unstated.
>
> Right now, each graph has in the range of 300-500 triples (though the
> amount depends on how much additional/domain-specific metadata
> end-users choose to add) and the scale of deployed Fuseki datasets
> range from having a few to ~6k graphs.
> Since we'd like to allow end-users to run **any** queries they wish
> (we enforce query timeouts), it's difficult to give concrete examples.
> I can however say that TDB unionDefaultGraph mode is enabled (i.e.
> most end-users won't choose to explicitly target a specific graph) and
> that one of our representative "search" queries (which combines
> GeoSPARQL + multiple explicit property matching across multiple
> different subjects in a UNION + subsequent collection of mandatory &
> optional fields) is between 20-40% faster than the current custom
> solution.
> (Note that we have also tried query re-writing to insert FROM/FROM
> NAMED clauses - and that is very slow in comparison, presumably to the
> higher level filtering involved, unlike the quad filter herein.)
>
> >
> > There is no characterisation of the queries being made. If we are
> > talking about overheads, the cases of a few big queries and many small
> > queries are different.
>
> (pasted from JENA-2339 ticket) - using a "SELECT {} 1" query, and
> adding a certain set of graphs makes the queries on my laptop take:
> ~600 graphs ~115ms
> ~1500 graphs ~162ms
> ~3k graphs ~240ms
> ~6k graphs ~400ms
>
> >
> > The scale looks small (less than a million triples of triples -
> > approximating as 100 graphs * 1000 triples). That makes the point about
> > access to TDB hooks a bit redundant.
>
> The dataset I've tested this with has ~1.8M triples. That's not to say
> this is the scale we're hoping to satisfy - that's the just what I
> tested with first. By redundant, do you mean an alternative approach
> should be used for this scale?
>
> >
> >
> > There is are distinguished users. A request from one of these users
> > causes the set of visible graphs to be read from a comment at the start
> > of the query text in the request.
> >
> > The use of large numbers of small named graphs to manage security
> > settings looks to me like triple-level security.  I have already
> > mentioned work "FMod_ABAC": (£job related) awhile back (2/Jan/2022). It
> > is triple level attribute-based security.
>
> It could well be that I'm seeing the wrong solution for the feature
> we're trying to support (that's the other reason for reaching out to
> the community. The reason (rightly or wrongly) to model this as a set
> of graphs is: Each set of triples to be restricted are related, but
> span multiple subjects and could also relate to other subjects in
> other sets (as

Re: UI jar

[Martynas Jusevičius]

Not a multi-module build, but this is how we publish WAR + JAR:
https://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#attachClasses


org.apache.maven.plugins
maven-war-plugin
3.2.3

ROOT
target/ROOT
true
true



The dependency then looks like this (using "classes" which is the
default  classifier):


${project.groupId}
client
3.1.8-SNAPSHOT
classes


${project.groupId}
client
3.1.8-SNAPSHOT
war


On Sat, Jan 29, 2022 at 12:01 PM Andy Seaborne  wrote:
>
>
>
> On 28/01/2022 23:43, Bruno Kinoshita wrote:
> > Build passed from tag, with:
> >
> >
> > Apache Maven 3.8.2 (ea98e05a04480131370aa0c110b8c54cf726c06f)
> > Maven home: /opt/apache-maven-3.8.2
> > Java version: 11.0.13, vendor: Ubuntu, runtime:
> > /usr/lib/jvm/java-11-openjdk-amd64
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "linux", version: "5.4.0-96-generic", arch: "amd64", family: "unix"
> >
> >
> > Looked inside .jar and .tar.gz files in the dist area (binaries and
> > sources), and everything looks good (checked the new -ui module, didn't
> > find node_modules or any other unnecessary files). The jena-fuseki-ui
> > module creates a jar that only contains metadata. Maybe we could skip
> > releasing it in the future? I think as it is, it should be available in the
> > Maven repository as a jar dependency for users, even though it's not usable
> > in any way in Java I think.
>
> We can make it a POM artifact then no jar generated.
>
> Or.
>
> Use the jar to deliver the UI files.
>
> They can be served from the jar.  No files on disk. No copying from
> ../jena-fuseki-ui/target/dist/ during jena-fuseki-webapp.
>
> The Jetty content-serving servlet takes URL string - and a jar is
> accessed with URL .
>
> The path can be determined automatically by looking up the path-in-jar
> as the server starts. The files are places under "src/main/resources/"
>
> I have, experimentally, done a Fuseki module for the UI. This is a
> drop-in to FusekiMain (ditto the admin functions as a drop-in).
>
> These will convert the standalone Fuseki server to being a Fuseki/Main +
> Mod_UI + Mod_Admin, not a webapp+Jetty to run it.
>
> Good for docker.
>
> What I haven't looked at is how to get the WAR file setup with this
> change of build. A war file unpacks its contents to disk and has jars in
> WEB-INF/lib which is the webapps classpath. "Should" work if start-up
> can set the location of static content.
> An alternative is have a prepare step in the build to unpack the jar.
>
> Anyone got experience of delivering JS into a WAR file in a multi-module
> build?
>
>  Andy

Re: Fuseki Evolution

[Martynas Jusevičius]

Hi,

>From our side, the only distribution of Fuseki we are using is the
Docker image (plain server without UI).

On Sun, Jan 2, 2022 at 5:23 PM Andy Seaborne  wrote:
>
> A collection of thoughts and discussion points about Fuseki.
>
> == Jena 4.4.0
>
> There is a vue-based rewrite of the UI thanks to Bruno (yea!). The new
> UI is in the codebase and the LICENSE and NOTICE files updated. There
> are no blockers for releasing this in 4.4.0 release. Prior to the
> kerfuffle over security, the hope was an earlier-then-usual 4.4.0
> because the UI only just missed 4.3.x.
>
> == javax-jakarta transition
>
> jakarta is JavaEE at the Eclipse Foundation).
>
> At some time, there will need to be transition from javax.* to jakarta.*
> for the package imports of javax.* that relate to Java EE.
>
> For Fuseki that is mainly for javax.servlet but also an implication for
> the WAR file.
>
> For the Fuseki code itself, there isn't much impact, just a rename.
> Partially this is because Fuseki does not use JavaEE features. For
> example, request dispatch is not done with web.xml (Fuseki dispatch is
> dynamic, not a static setup). FusekiMain does not use web.xml at all.
>
> Jetty version 11 is the same as Jetty version 10 except that "javax" ->
> "jakarta" renaming. A big bang switch over but it should be mechanical
> translation.
>
> There are two dependencies that use javax.servlet -- commons-fileupload
> and shiro.
>
> commons-fileupload code does not update very often (last version was
> 2018). It is small and Fuseki only uses a small part of it so we could
> adopt the code we need for file upload from HTML pages.
>
> shiro is an unknown.
>
> The WAR file is more of a problem - we have already had someone try to
> run Fuseki in Tomcat 10 and it fails. All Tomcat 9 webapps fail in
> Tomcat 10.
>
> Tomcat10 is based on jakarta while Tomcat9 is javax.
>
> Tomcat has a migration tool: tomcat-jakartaee-migration but otherwise
> it's a incompatible change. (I haven't tried the tool).
>
> I haven't come across the reverse conversion. Maybe maven-shade-plugin
> will do it.
>
> == Distributing the WAR file.
>
> The apache-jena-fuseki zip/tar.gz download is getting quite big. It has
> both the war file and the standalong Fuseki server (jena-fuseki-fulljar).
>
> One option is to change to providing the WAR file by a link on the
> project download page, and note in the apache-jena-fuseki README.
>
> The link could be in /binaries or to maven central.
>
> What is hard to determine is how important the war file version actually
> is nowadays.  Should we focus on a runnable server Fuseki or are
> multi-webapp hosting containers still common for semantic web data?
>
> Or change the WAR file to be less webapp internally? Have a simple "all
> URLs" grabber in web.xml and feed it into a wrapped FusekiMain?
>
> == Standalone server - switch to Fuseki Main+UI
>
> Ideally, long term, the standalone server would switch to being
> Fuseli/Main + UI + Admin module. At the moment it is Jetty+and the same
> code as the war file version.
>
> More on Fuseki modules below.
>
> Fuseki/main and Fuseki/webapp differ in how they startup and whether the
> additional servlets like admin are routed by web.xml or configured by
> the HTTP server builder in java code setup directly into Jetty.
>
> == Modules
>
> A Fuseki Module is loadable code that gets called in the server
> lifecycle, principally getting called during server build with direct
> access into the Fuseki server datastructures. A module can add new
> features, modify the Fuseki server as it is being built or simply
> monitor operations.
>
> It only works with FusekiMain - FusekiMain has a clearly defined
> lifecycle. The webapp is a "build-once" but also tied to the fixed
> web.xml routing.
>
> https://github.com/apache/jena/blob/main/jena-fuseki2/jena-fuseki-main/src/main/java/org/apache/jena/fuseki/main/sys/FusekiModule.java
>
> This has been "experimental" in 4.3.x. I have (not-production-ready)
> modules:
>
> FMod_UI: jar file serving the static content of the UI JS/CSS/HTML
> directly from the jar file. No fixed disk area for static content.
>
> FMod_Admin: makes the admin code work as a Fuseki module.
> This would also be a chance to simplify the design.
> Thius experimental module is compatible with the on-disk layout of
> FusekiWebapp admin.
>
> FMod_Shiro (sktech): looks possible. A Fuseki module can add servlet
> filters to the servlet dispatch chain.
>
> FMod_FusekiKafka: Adds Kafka topics as an data input channel to Fuseki.
> It can transport data, patches or SPARQL Update requests and routes them
> to a dataset. (£job related.)
>
> FMod_ProvidePATCH: Add handling of HTTP verb PATCH.
> This is in "ExFusekiMain_3_FusekiModule.java"
>
> FMod_GraphAccessCtl: Configure the graph level security
> (jena-fuseki-access).
>
> FMod_ABAC: (£job related). Triple level attribute-based security.
>
> And recently mentioned: FMod_GeoSPARQL as a way of delivering
> jena-fuseki-geosparql capability i

Re: Wikidata evolution

[Martynas Jusevičius]

I have followed this for a bit but hadn’t suggested Jena for the reasons
you mentioned.

AFAIK they are looking for a triplestore that is
- open-source
- actively maintained
- scales to their data volume

To my knowledge, there isn’t any that satisfies all 3 requirements :/

On Sat, 20 Nov 2021 at 15.21, Andy Seaborne  wrote:

> Wikidata are looking for a replace for BlazeGraph
>
> About WDQS, current scale and current challenges
>https://youtu.be/wn2BrQomvFU?t=9148
>
> And in the process of appointing a graph consultant: (5 month contract):
> https://boards.greenhouse.io/wikimedia/jobs/3546920
>
> and Apache Jena came up:
> https://phabricator.wikimedia.org/T206560#7517212
>
> Realistically?
>
> Full wikidata is 16B triples. Very hard to load - xloader may help
> though the goal for that was to make loading the truthy subset (5B)
> easier. 5B -> 16B is not a trivial step.
>
> Even if wikidata loads, it would be impractically slow as TDB is today.
> (yes, that's fixable; not practical in their timescales.)
>
> The current discussions feel more like they are looking for a "product"
> - a triplestore that they are use - rather than a collaboration.
>
>  Andy
>

Re: Towards Jena 4.3.0

[Martynas Jusevičius]

Oh OK, I see it now under resolved tickets.

On Thu, 18 Nov 2021 at 13.09, Martynas Jusevičius 
wrote:

> Hi,
>
> What about
> https://issues.apache.org/jira/browse/JENA-2184? Is it not included or
> just not mentioned?
>
>
> Martynas
>
> On Wed, 17 Nov 2021 at 11.09, Andy Seaborne  wrote:
>
>> We're a little way from the clock tick - 3 months would be 16/Dec.
>>
>>  From my point of view, it would be nice to release early to mid
>> December rather than the run up to Christmas.
>>
>> Does that fit with PMC members?
>>
>>  Andy
>>
>> Resolved tickets for 4.3.0:
>> https://s.apache.org/jena-4.3.0-jira
>>
>> Jenkins:
>> https://ci-builds.apache.org/job/Jena/
>>
>> and the additional CI builds on Windows and MacOS pass.
>> https://github.com/apache/jena/actions
>>
>> Contributions:
>>
>> Jan Martin Keil
>> JENA-2169: Blank node graph names in Dataset interface
>>
>> Erich Bremer
>> Update EnhGraph.java
>>
>> Stefan Obermeier
>> JENA-2195: Include jena-examples in build
>>
>> jena-site:
>>Michael Wechner
>>@den1s0v
>>Robin Vobruba
>>
>> Main Items:
>>
>>  java.net.http
>>
>> HTTP usage provided by the JDK java.net.http package, with
>> challenge-based authentication provided on top by Jena.
>>
>> Rework SPARQL client APIs using HTTP code (query, update GSP).
>>
>>  SPARQL APIs
>>
>> * Execution objects (QueryExecution, UpdateExecution, RDFConnection)
>> have a companion builders for detailed configuration. Previous factory
>> classes remain but builders are preferred.
>>
>> This is especially important for HTTP as there many configuration
>> options that may be needed (including template queries).
>>
>> https://jena.apache.org/documentation/sparql-apis/#changes
>>
>> Epic: JENA-2125
>>
>> Internal reorg:
>>
>> https://lists.apache.org/thread.html/r02f8938a5fea60f6dd1781dabcb81862abebd19052b076fad57340db%40%3Cusers.jena.apache.org%3E
>>
>> If apps use methods that have Apache HttpClient arguments (HttpClient,
>> HttpContext), they will be affected.
>>
>>  xloader
>>
>> TDB1 and TDB2 loader for billion+ triples on a modest machine.
>>
>> JENA-2175
>> xloader
>>tdbloader2 renamed. tdb1.xloader
>>tdb2.xloader
>>
>>  Retire OSGi artifacts
>> JENA-2165
>>
>>  jena-examples
>> Consolidate ARQ/TDB/ShEx/SHACL and RDFConnection examples
>>
>

Re: Towards Jena 4.3.0

[Martynas Jusevičius]

Hi,

What about
https://issues.apache.org/jira/browse/JENA-2184? Is it not included or just
not mentioned?


Martynas

On Wed, 17 Nov 2021 at 11.09, Andy Seaborne  wrote:

> We're a little way from the clock tick - 3 months would be 16/Dec.
>
>  From my point of view, it would be nice to release early to mid
> December rather than the run up to Christmas.
>
> Does that fit with PMC members?
>
>  Andy
>
> Resolved tickets for 4.3.0:
> https://s.apache.org/jena-4.3.0-jira
>
> Jenkins:
> https://ci-builds.apache.org/job/Jena/
>
> and the additional CI builds on Windows and MacOS pass.
> https://github.com/apache/jena/actions
>
> Contributions:
>
> Jan Martin Keil
> JENA-2169: Blank node graph names in Dataset interface
>
> Erich Bremer
> Update EnhGraph.java
>
> Stefan Obermeier
> JENA-2195: Include jena-examples in build
>
> jena-site:
>Michael Wechner
>@den1s0v
>Robin Vobruba
>
> Main Items:
>
>  java.net.http
>
> HTTP usage provided by the JDK java.net.http package, with
> challenge-based authentication provided on top by Jena.
>
> Rework SPARQL client APIs using HTTP code (query, update GSP).
>
>  SPARQL APIs
>
> * Execution objects (QueryExecution, UpdateExecution, RDFConnection)
> have a companion builders for detailed configuration. Previous factory
> classes remain but builders are preferred.
>
> This is especially important for HTTP as there many configuration
> options that may be needed (including template queries).
>
> https://jena.apache.org/documentation/sparql-apis/#changes
>
> Epic: JENA-2125
>
> Internal reorg:
>
> https://lists.apache.org/thread.html/r02f8938a5fea60f6dd1781dabcb81862abebd19052b076fad57340db%40%3Cusers.jena.apache.org%3E
>
> If apps use methods that have Apache HttpClient arguments (HttpClient,
> HttpContext), they will be affected.
>
>  xloader
>
> TDB1 and TDB2 loader for billion+ triples on a modest machine.
>
> JENA-2175
> xloader
>tdbloader2 renamed. tdb1.xloader
>tdb2.xloader
>
>  Retire OSGi artifacts
> JENA-2165
>
>  jena-examples
> Consolidate ARQ/TDB/ShEx/SHACL and RDFConnection examples
>

Re: Retrieve all sub resources from one resource in one model

[Martynas Jusevičius]

https://jena.apache.org/documentation/javadoc/jena/org/apache/jena/util/ResourceUtils.html#reachableClosure(org.apache.jena.rdf.model.Resource)

On Mon, Jul 19, 2021 at 1:39 PM Roland Bailly
 wrote:
>
> Thank you for your swift answer.
>
> Yes exactly. The idea is to get the sub graph from a given a node.
>
>
> -Original Message-
> From: LB 
> Sent: lundi 19 juillet 2021 13:27
> To: dev@jena.apache.org
> Subject: Re: Retrieve all sub resources from one resource in one model
>
> --- This is an incoming mail from an EXTERNAL DOMAIN. Please verify sender 
> before you open attachments or access links. ---
>
>
> what is a "sub-resource" in RDF? Are you talking about CBDs? Like what SPARQL 
> DESCRIBE returns (to some extend)?
>
> On 19.07.21 13:18, Roland Bailly wrote:
> > Hello,
> >
> > Currently I am working with a huge RDF file.
> > I would like to retrieve all sub resources from one resource and put 
> > everything in one model.
> >
> > The idea with that is to convert the model to JSON LD FRAMING to create a 
> > java object.
> > I don't want to convert my huge RDF file in JSON LD, but only the part I 
> > need.
> > With Jena I can already retrieve my root object with 
> > model.getResource("id") but it doesn't contain the sub resources.
> >
> > Please, do you know how to retrieve the subresources ?
> >
> > Roland Bailly
> > Analyst - Programmer
> >
> > Email:
> >
> >   roland.bai...@arhs-dev-be.com
> >
> > Mobil:
> >
> > 04 97 28 38 16
> >
> > Fax:
> >
> > +32 2 774 88 31
> >
> >
> > [http://www.arhs-group.com/wp-content/uploads/2017/03/arhs-dev-be.png]
> >
> >
> > Woluwedal 30
> > B-1932 Zaventem
> > www.arhs-dev-be.com
> >
> >
> >
> >
>
>

Re: SPARQL question

[Martynas Jusevičius]

I guess the first one was meant to be

CONSTRUCT
  {
?s ?p ?o .
  }
WHERE
  { { { ?s  ?p  ?o } }
?s2  ?p2  ?o2
  }

On Thu, Apr 15, 2021 at 11:31 AM Rob Vesse  wrote:
>
> Well the first is invalid syntax...?
>
> Rob
>
> On 15/04/2021, 10:26, "Claude Warren"  wrote:
>
> Is there a difference between
>
> CONSTRUCT
>   {
> ?s ?p ?o .
>   }
> WHERE
>   { { WHERE
> { ?s  ?p  ?o}
> }
> ?s2  ?p2  ?o2
>   }
>
> and
> CONSTRUCT
>   {
> ?s ?p ?o .
>   }
> WHERE
>   { { SELECT  *
>   WHERE
> { ?s  ?p  ?o}
> }
> ?s2  ?p2  ?o2
>   }
>
> --
> I like: Like Like - The likeliest place on the web
> 
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
>
>
>

Re: ApacheCon 2021

[Martynas Jusevičius]

We might be interested :) When is it and what does it take?

On Thu, Feb 18, 2021 at 7:52 PM Claude Warren  wrote:
>
> arrrgg.  What was I thinking??  I don't know either.  I meant to ping this
> topic to see if there was any interest before dropping it.  So if you are
> interested in a Jena topic at ApacheCon this year let me know and I will
> propose it and drive it forward as best I can.
>
> Claude
>
> On Thu, Feb 18, 2021 at 6:50 PM Claude Warren  wrote:
>
> > not hearing any suggestions on this topic. I will drop it.
> >
> > Thx
> >
> > On Wed, Feb 17, 2021 at 5:41 PM Marco Neumann 
> > wrote:
> >
> >> I am in touch with the Apache spatial group about the 2021 slots, and it
> >> looks like I will dedicate a strand to linked data and geosparql with jena
> >> here in spatial track.
> >>
> >> Marco
> >>
> >>
> >>
> >> On Wed, Feb 17, 2021 at 11:43 AM Claude Warren  wrote:
> >>
> >> > There is a call for tracks for ApacheCon 2021.  Do we want to propose a
> >> > track again this year?  Perhaps we could get some presentations from
> >> users.
> >> >
> >> > FYI:  I gave an impromptu talk about Jena at the Apache "table" during
> >> > FOSDEM at the beginning of this month.
> >> >
> >> > Claude
> >> >
> >> > --
> >> > 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
> >
>
>
> --
> I like: Like Like - The likeliest place on the web
> 
> LinkedIn: http://www.linkedin.com/in/claudewarren

Re: Fuseki lock-up - any ideas?

[Martynas Jusevičius]

Not Fuseki-related per se, but I've experienced something similar when
the HTTP client is running out of connections.

On Tue, Feb 16, 2021 at 11:50 AM Dave Reynolds
 wrote:
>
> We have a mysterious problem with fuseki in production that we've not
> seen before.  Posting in case anyone has seen something similar and has
> any advice but I realise there's not really much here to go on.
>
> Environment:
> Fuseki 3.17 (was 3.16, tried upgrade just in case) using TDB1
> OpenJDK java 8
> Docker container (running in k8s pod)
> ABW EBS file system
> O(2k) small updates per day (uses RDFConnection to send update)
> Variable read request rate but issue hits at low request levels
>
> Symptoms are that fuseki receives an update request but never completes it:
>
>  INFO  550175  POST http://localhost:3030/ds
>  INFO  550175  Update
>  INFO  550175  204 No Content (20 ms)
>  INFO  550176  POST http://localhost:3030/ds
>  INFO  550176  Update
> -->
>  INFO  550178  Query = ASK { ?s ?p ?o }
>  INFO  550178  GET
> http://localhost:3030/ds?query=ASK+%7B+%3Fs+%3Fp+%3Fo+%7D
>  INFO  550179  GET
> http://localhost:3030/ds?query=ASK+%7B+%3Fs+%3Fp+%3Fo+%7D
>  INFO  550179  Query = ASK { ?s ?p ?o }
>
> So no 204 return from request 550176.
>
>  From that point on fuseki continues to log incoming read queries but
> does not answer any of them and the update request never terminates.
> Acts as if there's some form of deadlock.
>
> Update requests are serialised, there's never more than one in flight at
> a time.
>
> It's not the update itself that's the issue. It's small and if the
> container is restarted with the same data and the same update sequence
> is reapplied it all works fine.
>
> The jvm stats all look completely fine in the prometheus records.
>
> The various parts of this set up have been in various production
> settings without problems in the past. In particular, we've run the
> exact same pattern of mixed updates and queries in fuseki in a k8s
> environment for two years without ever having a lockup. But on a new
> deployment it's happening every few days.
>
> There are differences between the new and old deployments but the ones
> we've identified seem very unlikely to be the cause. We've not used
> RDFConnection in the client before but can't see how that could affect
> this. We don't often run with TDB on EBS but we do have a dozen
> instances of that around which haven't had problems. We have generally
> shifted to AWS Corretto as the jvm but we have plenty of OpenJDK
> instances around without problems. The docker image is slightly unusual
> in using the s6 overlay init system rather than running fuseki as the
> root process but again can't see how this might cause these symptoms and
> other uses of that, with fuseki, have been fine.
>
> We'll find a workaround eventually, possibly involving shifting to TDB2,
> but posting in case anyone has had an experience similar enough to this
> to give us some hints.
>
> Dave
>

Re: Java 8 or 11?

[Martynas Jusevičius]

Suggestion: migrate builds to GitHub actions. I just did that for our
test suites.
https://www.jeffgeerling.com/blog/2020/travis-cis-new-pricing-plan-threw-wrench-my-open-source-works

On Fri, Jan 8, 2021 at 6:38 PM Andy Seaborne  wrote:
>
> Status: JENA-2022
>
> One slight problem - on travis-ci.org, the Java11 system is 11.0.2 which
> hits a javadoc problem
>
>https://bugs.openjdk.java.net/browse/JDK-8212233
>
> (it says Java12 but it applies to 11.0.1, and 11.0.2, not 11.0.0, the GA
> release, or 11.0.3 or later, then 12.0.0, 12.0.1)
>
> I think this is triggered by cross links in Java source code from one
> module to another when the modules have Automatic-Module-Name. The fixes
> mentioned don't work for Jena.
>
> See also https://issues.apache.org/jira/browse/MJAVADOC-555
>
> There are no problems building with the default Java11 on my machine
> (11.0.9)
>
> For now I have switched off javadoc production in the .travis.yml file.
>
> It should be OK on ASF Jenkins because there, we control the JDK (and
> only 11.0.9 in various forms is available anyway).
>
> What the travis file does for us is that PRs automatically get a check
> applied of running the build with the PR at travis (it can take a while
> to get scheduled and run). We didn't ask INFRA for this - recent
> infrastructure changes mean it just happens.
>
>  Andy
>
> On 01/01/2021 12:13, Andy Seaborne wrote:
> > Should we switch to Java11?
> >
> > There are the usually issues of moving to a newer Java. There seems
> > likely to be an emerging bimodal distribution of systems remaining with
> > Java8 and systems moving to Java11 and Java 17 (likely an LTS -
> > September 2021).
> >
> > The question is how many systems would upgrade their Jena version and
> > are restricted to Java8 (and why!).
> >
> > Java is evolving to better fit in the new tech landscape (e.g. better
> > container usage), more compact strings (significant for Jena), and
> > JDK-provided HTTP/2.
> >
> > Some dependences or potential dependencies are Java11:
> >
> > Titanium - for JSON-LD 1.1 (JENA-1948 - titanium-json-ld )
> >
> > Eclipse Jetty 10 and 11 now depend on Java11.
> >
> > (the difference between Jetty 10 and Jetty 11 is that Jetty 10 uses the
> > package root name "javax..." whereas Jetty11 uses package route
> > "jakarta...")
> >
> > Proposal:
> >
> > 1/ Ask on users@ -- what we need is "new information" such as "I am
> > blocked from updating Java because ...", not "I haven't got round to it".
> >
> > 2/ Switch to Java11 for the next release but not make so many changes
> > that we can't easily go back to Java8.
> >
> >  Andy

Re: Java 8 or 11?

[Martynas Jusevičius]

I recently upgraded AtomGraph components to Java 11 and took advantage
of the -XX:MaxRAMPercentage JVM setting in a Docker setup:
https://www.eclipse.org/openj9/docs/xxinitialrampercentage/

On Fri, Jan 1, 2021 at 1:13 PM Andy Seaborne  wrote:
>
> Should we switch to Java11?
>
> There are the usually issues of moving to a newer Java. There seems
> likely to be an emerging bimodal distribution of systems remaining with
> Java8 and systems moving to Java11 and Java 17 (likely an LTS -
> September 2021).
>
> The question is how many systems would upgrade their Jena version and
> are restricted to Java8 (and why!).
>
> Java is evolving to better fit in the new tech landscape (e.g. better
> container usage), more compact strings (significant for Jena), and
> JDK-provided HTTP/2.
>
> Some dependences or potential dependencies are Java11:
>
> Titanium - for JSON-LD 1.1 (JENA-1948 - titanium-json-ld )
>
> Eclipse Jetty 10 and 11 now depend on Java11.
>
> (the difference between Jetty 10 and Jetty 11 is that Jetty 10 uses the
> package root name "javax..." whereas Jetty11 uses package route
> "jakarta...")
>
> Proposal:
>
> 1/ Ask on users@ -- what we need is "new information" such as "I am
> blocked from updating Java because ...", not "I haven't got round to it".
>
> 2/ Switch to Java11 for the next release but not make so many changes
> that we can't easily go back to Java8.
>
>  Andy

Re: Towards 3.17.0

[Martynas Jusevičius]

How about https://issues.apache.org/jira/projects/JENA/issues/JENA-1983?

If not for 3.17.0, then for 3.18.0.

On Wed, Nov 11, 2020 at 4:09 PM Andy Seaborne  wrote:
>
>
>
> On 11/11/2020 14:35, Aaron Coburn wrote:
> > This looks excellent. Should we also update the version of
> > o.a.httpcomponents:httpclient? 4.5.10 => 4.5.13
>
> Yes - I don't know if the dependabot has finished but so far we have one
> for httpcore-osgi but not httpcore nor httpclient.
>
> Others?
>
> (There is a ElasticSearch one but it is a major version change so
> probably better to ignore that.)
>
>  Andy
>
>
> >
> > Aaron
> >
> > On Tue, 10 Nov 2020 at 15:21, Bruno P. Kinoshita  wrote:
> >
> >>   Looks good to me. I thought there would be 5-10 issues, was surprised to
> >> see 38! Great work, +1
> >> Bruno
> >>
> >>  On Wednesday, 11 November 2020, 6:30:55 am NZDT, Andy Seaborne <
> >> a...@apache.org> wrote:
> >>
> >>   Jena 3.16.0 was 2020-07-09
> >> so the tick for 3.17.0 is here.
> >>
> >> There's a list of notable items below - is anything missing?
> >>
> >> Tickets this release:
> >> https://s.apache.org/jena-3.17.0-jira
> >>
> >> Also of of note:
> >> ## Proposal:
> >>Didac: Titanium proposal for JSON-LD 1.1
> >>  No changes in this version.
> >>  Discuss!
> >>
> >>
> >>  Andy
> >>
> >>
> >> ## Work-in-progress:
> >>
> >> JENA-1911: Updating Fuseki UI
> >> JENA-1894: Order preserving datasets
> >> JENA-1987: Add Fuseki /$/compact/* endpoint
> >> JENA-1992: Fix for logging running in Tomcat.
> >>
> >> ## Updates:
> >> JENA-1959, JENA-1967
> >>JSON-LD 0.12.5 -> 0.13.2 (umbreak)
> >> JENA-1972: Jetty 9.4.26 -> 9.4.31
> >> JENA-1973: Micrometer: 1.2.1 -> 1.5.5
> >> JENA-1992: Update Log4j2 to 2.14.0
> >> JENA-1993: Update Eclipse Jetty to 9.4.34
> >>
> >> ## 
> >> ## Features:
> >>
> >> JENA-1982. SPARQL \U escapes in String and IRIs.
> >> This is a change to ARQ extended SPARQL syntax.
> >>
> >> Pavel Mikhailovskii
> >>
> >> JENA-1950: Use GraalVM for javascript if available.
> >> This also opens up the possibility of other languages for scripting
> >> SPARQL extension functions. (JENA-1951)
> >>
> >> The license means we do not ship GraalVM itself (and it is quite big).
> >>
> >> JENA-1968
> >> Support Turtle output with relative URIs but no BASE declaration.
> >>
> >> JENA-1974: G library
> >> A library for working with Graphs
> >> More :
> >>
> >> https://lists.apache.org/thread.html/r973fd076583327b75e15bda798dce66d47f4f7cd8dbaa14c280f1fe3%40%3Cdev.jena.apache.org%3E
> >>
> >> JENA-1937: SHACL Compact Syntax writer
> >>
> >>
> >> Fuseki:
> >>
> >> JENA-1929: Fuseki: Detect TDB1/TDB2 database types.
> >>
> >> JENA-1949: Dockerfile
> >> and build instructions
> >> https://jena.apache.org/documentation/fuseki2/fuseki-docker.html
> >>
> >> This is a build system published as a zip file and it can be used to
> >> build a docker container (about 100M) for any recent version of
> >> Fuseki/Main.
> >>
> >> JENA-1976
> >> Make CORS support in Fuseki main default to on.
> >>
> >> JENA-1961
> >> Support /$/metrics in Fuseki Main
> >>
> >> JENA-1989
> >> Logging in Fuseki/webapp
> >>
> >>
> >

Re: Towards 3.16.0

[Martynas Jusevičius]

Any chance to squeeze JENA-1936 in? :)

On Thu, 9 Jul 2020 at 17.55, Andy Seaborne  wrote:

> First attempt failed - ran into the issue that source-release skips
> files with the string "target" anywhere in the file name.
>
> SHACL has "targets" so data in test files has the string in it and there
> are new test files for the SHACLC reader.
>
> Oops.
>
> The temporary fix is to move the under src/test/resources but stil read
> them as files (because URI resolution comes into play, I don't want to
> classpath load the files).
>
> Trying again.
>
>  Andy
>
> On 08/07/2020 20:32, Andy Seaborne wrote:
> > I've started on producing the release.
> >
> > On 30/06/2020 17:16, Andy Seaborne wrote:
> >> 3.15.0 has some problems for users - the fulljar Fuseki does not start
> >> without modification, and the commands print error/warning message to
> >> stdout. The logging issue is especially a nuisance for new people and
> >> it has come up a few times on stackoverflow.
> >>
> >> RDF* for TDB1 and TDB2 are now working.
> >> There is a SHACL Compact Syntax reader.
> >>
> >> https://s.apache.org/jena-3.16.0-jira
> >>
> >> If that's OK with everyone, let's do 3.16.0 to have the latest version
> >> being tidier.
> >>
> >> PR #770 (a jena-text-es fix) should go in. - anything else outstanding?
> >>
> >>  Andy
> >>
> >>
> >>
> >> -- Upgrades
> >>
> >> JENA-1896 : Google Guava to 24.1-jre to 29-jre
> >>
> >>
> >> 
> >> Contrib:
> >>
> >>
> >> JENA-1901
> >> Provide default implementations for some of SecurityEvaluator's methods
> >> Unassigned Pavel Mikhailovskii
> >>
> >> JENA-1904 : QueryExecution.sparqlService fix.
> >> Daniel Arturo Casals Amat
> >>
> >> 
> >>
> >> Features:
> >> JENA-1921 : SHACLC reader
> >> JENA-1899 : RDF* for TDB1, TDB2
> >>
> >> Also:
> >>
> >> JENA-1924 : Invalid IRIs
> >> JENA-1918 : Performance improvements for paths
> >> JENA-1913 : Fuseki: Support multiple "--file" arguments to load all
> >> the files into one database.
> >>
> >>
>

Jersey Client for HTTP I/O

[Martynas Jusevičius]

Hey all,

I refactored HTTP I/O code which previously combined Jena's
DataManager, DatasetGraphAccessorHTTP, and QueryEngineHTTP using
Jersey Client 1.x API.

I think the code became much more higher-level, flexible and
consistent. ClientResponse provides a rich interface with full
metadata about the response. The serialization logic is orthogonal to
HTTP and is separated nicely into JAX-RS MessageBodyReaders/Writers.
JAX-RS 2.x provides even more features.

I'd like to suggest that Jena 3 evaluates both JAX-RS and Client API
as dependencies instead of Apache HTTPClient.

Refactored DataManager.loadModel():
https://github.com/Graphity/graphity-core/blob/de8d9c201ea95ec5f8978052697a515c747137b1/src/main/java/org/graphity/core/util/jena/DataManager.java#L130

SPARQL and GSP clients:
https://github.com/Graphity/graphity-core/blob/de8d9c201ea95ec5f8978052697a515c747137b1/src/main/java/org/graphity/core/client/SPARQLClient.java
https://github.com/Graphity/graphity-core/blob/de8d9c201ea95ec5f8978052697a515c747137b1/src/main/java/org/graphity/core/client/GraphStoreClient.java

Model provider:
https://github.com/Graphity/graphity-core/blob/de8d9c201ea95ec5f8978052697a515c747137b1/src/main/java/org/graphity/core/provider/ModelProvider.java


Martynas
graphityhq.com