The principle is "existing data, existing code" is unaffected.
On 28/08/2020 01:52, Holger Knublauch wrote:
It's good to see the recently introduced RDF* features in Jena. But as
someone with a lot of existing Jena code, this low-level change poses a
number of challenges. For example we have many of places with variations of
if(rdfNode.isResource()) { if(rdfNode.isURIResource()) { } else { //
Here we now assume it's a blank node, yet this is no longer true // and
they node may also be a triple node } } else { // Must be a literal -
this hasn't changed }
Well, you're lucky that Node_Triple isn't a literal! It behaves like
one. It is because the Model API is typed, that is manifests as a
resource, the only way to get into the subject position.
If the data does not contain <<>> (and your code does not create the new
node type) then the new cases won't arise.
Otherwise the situation is one of "new data, old code", which is always
tricky.
You can detect new data with an StreamRDF on parsing external input.
In fact, for TopQuadrant, you may wish to translate <<>> into your
internal form for RDF* triple term. An StreamRDF can do that.
which now need to be changed to handle rdfNode.isStmtResource() too. And
it should of course do so in a meaningful way.
I guess properly adjusting our code base will take many months, and it
will require a lot of testing and iterating.
In the meantime, is there a flag that we can set to deactivate RDF*
support in the parsers and SPARQL*?
Not currently - "existing data, existing code" is unaffected.
Particular to SPARQL* -- no need to turn it off, it simply won't match.
The page
https://jena.apache.org/documentation/rdfstar/ only states "it is active
by default in Fuseki" but doesn't show an API to do the same
programmatically.
It's active in the code.
Could you also give some background on the implications on TDB? I guess
if such new nodes end up in a database, then this database can no longer
work with older Jena versions?
Correct.
But it's a big IF "if such new nodes end up in a database". The question
is how did it happen?
Andy
PS The SHACL impact is quite natural but there is a new case for
constants sh:BlankNodeOrLiteral etc etc.
Thanks
Holger
