Re: Read-only wrapper for Jena Model

[Martynas Jusevičius]

Andy,

A follow-up question: how would you create an immutable OntModel?

OntModel ontModel = ModelFactory.createOntologyModel(ontModelSpec, modelRO);

Would the ontModel still be mutable?

On Sat, Aug 28, 2021 at 3:43 PM Andy Seaborne  wrote:
>
>
>
> On 27/08/2021 12:23, Zak Mc Kracken wrote:
> > Hi all,
> >
> > I have a little RDF file (describing a dataset metadata), which I want
> > to read in an helper class and return as a read-only view on the file.
> > The reason to return it as read-only is that I also keep a simple cache
> > of uri/Object, which is a simplified view of RDF resources in the file,
> > so a modifiable Model would make it impossible to keep the two aligned.
> >
> > That said, I wonder if there is some read-only wrapper for the Jena's
> > Model interface, something similar to Collections.unmodifiableXXX(),
> > which of course, would be based on the decorator pattern, with
> > delegation to a base Model for most of the interface methods, except
> > interceptors for addXXX(), which would throw
> > UnsupportedOperationException. Would be easy to implement it, but I
> > don't like to reinvent wheels, if something like that already exists.
>
> Apparently there isn't one. Not sure why not.
>
> There is a read-only graph (and a read-only DatasetGraph) so one way to
> create a read-only model is:
>
>  Model model = ModelFactory.createDefaultModel();
>  Graph graphRO = new GraphReadOnly(model.getGraph());
>  Model modelRO = ModelFactory.createModelForGraph(graphRO);
>
> Graph is a narrower interface do catching things here is less code.  In
> fact, GraphBase is read-only unless add/delete(Triple) are overwritten.
>
>  Andy
> >
> > Thanks,
> > Marco.
> >
> >

Re: RDF-star delete Performance

[Andy Seaborne]

On 18/12/2021 16:58, Dragan Lesic wrote:

Hello,
I'm trying to update (delete+insert) some data which has also reification
in it (order of cast members for a movie for example).
When doing delete all triples for a subject that order data seems not to be
deleted.
For example i need to change the order.
After inserting new data, when doing queries I get the new and old data
back.
Executing a delete for RDF-star data is extremely slow.


Queries:
Query data (with order):

PREFIX sub: 
PREFIX shema: 
SELECT DISTINCT ?order ?name
WHERE {
sub:SOMEID shema:cast ?o {|shema:order ?order|} .
?o shema:name ?name .
}
ORDER BY ?order

Returns:
order
name

"0"^^xsd:integer
"Sigourney Weaver"@en

"1"^^xsd:integer
"Annie Potts"@en

"1"^^xsd:integer
"Annie Potts"@en
...
This is wrong, I have the order 1 twice because of an earlier insert. I
want to delete it and insert correctly.


Then delete everything:
PREFIX sub: 
DELETE
WHERE { sub:SOMEID ?p ?o . }

Then when I insert all data again, with the correct data and no duplicates
(I've checked) and i get the duplicate reference again.

When trying to delete all references first it works but is extremely slow,
takes minutes to complete:

PREFIX sub: 
PREFIX shema: 
delete
where { << sub:SOMEID shema:cast ?o >> shema:order ?order }

Any ideas what I am doing wrong, or how to make it faster?
Thanks in advance.



Hi,

What's the storage? TDB2?
How much data?

I guess there are a lot of "shema:order" triples.

<<>> isn't indexed (there have been no changes in database layout for 
RDF-star) so it needs to do:


?X shema:order ?order
then check ?X with << sub:SOMEID shema:cast ?o >>

You could give it a starting point:


DELETE
{ << sub:SOMEID shema:cast ?o >> shema:order ?order  }
WHERE {
   sub:SOMEID shema:cast ?o {|shema:order ?order|} ;
 }

or the use case in one request:


DELETE WHERE {
   sub:SOMEID shema:cast ?o {|shema:order ?order|} .
 }
;
DELETE WHERE { sub:SOMEID ?p ?o . }


Andy

Re: Release 4.3.2 -- was:[ANN] Apache Jena 4.3.1

[Andy Seaborne]

Part 3.

https://logging.apache.org/log4j/2.x/security.html
https://nvd.nist.gov/vuln/detail/CVE-2021-45105

Fuseki does not have a pattern with with a context Lookup (for example, 
$${ctx:loginId}) or indeed any ${} lookup.


Fuseki:
  [%d{-MM-dd HH:mm:ss}] %-10c{1} %-5p %m%n

Command line tools
  %d{HH:mm:ss} %-5p %-15c{1} :: %m%n"

Andy



Don't be surprised if there are more.

When Jackson JSON data binding was found to have vulnerabilities a few 
years ago, there were a number of CVEs as it got a lot of attention.


Also expect nearby projects to get attention.  Logback has registered a 
CVE (it's a remote code JNDI attack) but not from outside text. They 
have removed the "we're not affected text" from the home page.



On 18/12/2021 00:04, Andy Seaborne wrote:

Hi Andrew,

Thank you for letting us know.

Rob spotted that the log4j project security page has been updated:

https://logging.apache.org/log4j/2.x/security.html

revising it to critical 9/10

We've already started a vote on Jena 4.3.2 with log4j 2.16.0.

   https://lists.apache.org/thread/tj0mo24g8jvfr02964nww96ckfvxnhjm

(we are not bypassing the need to have the proper votes for a release)

Very few changes in 4.3.2 but - bonus prize! - JENA-2215 (make sure 
logging is in the war file) is included.


     Andy

On 17/12/2021 21:33, Andrii Berezovskyi wrote:

Hello Andy,

I hate to be the bearer of bad news, but in a recent discussion on 
Lobsters [1] it was brought to my attention that there apparently 
exists a bypass [2] of the fix in 2.15.0 that brings back the RCE. To 
be clear, the new exploit no longer requires fiddling with the Thread 
Context Map settings. The CVE page [3] now says "This vulnerability 
has been modified since it was last analyzed by the NVD. It is 
awaiting reanalysis which may result in further changes to the 
information provided.", which means that the original score 3.7/10 no 
longer applies to the new CVE.


Harri, the WAR file of the 4.3.1 was missing log4j JARs and I had 
success simply placing 2.16.0 JARs myself. You should be able to use 
that as a temporary mitigation until the new version comes out.


/Andrew

[1]: 
https://lobste.rs/s/ccc9tu/patch_fixing_critical_log4j_0_day_has_its#c_c2syst 

[2]: 
https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/#update-the-localhost-bypass-was-discovered 


[3]: https://nvd.nist.gov/vuln/detail/CVE-2021-45046

RDF-star delete Performance

[Dragan Lesic]

Hello,
I'm trying to update (delete+insert) some data which has also reification
in it (order of cast members for a movie for example).
When doing delete all triples for a subject that order data seems not to be
deleted.
For example i need to change the order.
After inserting new data, when doing queries I get the new and old data
back.
Executing a delete for RDF-star data is extremely slow.


Queries:
Query data (with order):

PREFIX sub: 
PREFIX shema: 
SELECT DISTINCT ?order ?name
WHERE {
sub:SOMEID shema:cast ?o {|shema:order ?order|} .
?o shema:name ?name .
}
ORDER BY ?order

Returns:
order
name

"0"^^xsd:integer
"Sigourney Weaver"@en

"1"^^xsd:integer
"Annie Potts"@en

"1"^^xsd:integer
"Annie Potts"@en
...
This is wrong, I have the order 1 twice because of an earlier insert. I
want to delete it and insert correctly.


Then delete everything:
PREFIX sub: 
DELETE
WHERE { sub:SOMEID ?p ?o . }

Then when I insert all data again, with the correct data and no duplicates
(I've checked) and i get the duplicate reference again.

When trying to delete all references first it works but is extremely slow,
takes minutes to complete:

PREFIX sub: 
PREFIX shema: 
delete
where { << sub:SOMEID shema:cast ?o >> shema:order ?order }

Any ideas what I am doing wrong, or how to make it faster?
Thanks in advance.