You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Andy Seaborne <an...@apache.org> on 2020/09/01 17:42:41 UTC

Re: Can RDF star support be deactivated?

Ping?

I'm not aware of any compile errors for APIs but and return signatures 
can make it complicated.

NodeVisitor doesn't include it (probably an omission - but a default 
method would solve that?

     Andy

On 28/08/2020 13:33, Andy Seaborne wrote:
> 
> 
> On 28/08/2020 02:12, cstadler@informatik.uni-leipzig.de wrote:
>>
>> +1 This is a very good point; I also have around 10 years of active 
>> code based on Jena and I was not yet able to upgrade to 3.16 because I 
>> did not find the time to resolve several compile errors which are at 
>> least partly due to changes introduced for RDF*. And even after the 
>> upgrade I would most likely run into the similar issues as Holger 
>> points out.
> 
> Hmm - where are you getting compile errors?
> 
>>
>> I have have used the following to work around legacy issues with 
>> RDF1.0/1.1:
>> JenaRuntime.isRDF11 = false;
>>
>> This might be a good place to allow for a
>> JenaRuntime.isRDFStar = false;
>>
>> Cheers,
>> Claus
>>
>> Quoting Holger Knublauch <ho...@topquadrant.com>:
>>
>>> 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 }
>>>
>>> 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*? 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.
>>>
>>> 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?
>>>
>>> Thanks
>>> Holger
>>
>>
>>

Re: Can RDF star support be deactivated?

Posted by Andy Seaborne <an...@apache.org>.
Oh - that deep inside the system :-)

Most code inherits from ElementVisitorBase which has a no-op for all 
elements.

(Ditto OpVisitor, OpVisitorBase)

     Andy

On 17/09/2020 22:55, Claus Stadler wrote:
> Hi Andy,
> 
> 
> In the meantime I have upgraded my code and it turned out that it was 
> essentially the newly introduced visitor method for ElementFind that was 
> missing in some of my transforrmers
> 
> - but that was easy to 'solve' for now by just raising an 
> UnsupportedOperationException.
> 
> 
> Cheers,
> 
> Claus
> 
> 
> On 2020/09/01 17:42:41, Andy Seaborne <a....@apache.org> wrote:
>  > Ping?>
>  >
>  > I'm not aware of any compile errors for APIs but and return signatures >
>  > can make it complicated.>
>  >
>  > NodeVisitor doesn't include it (probably an omission - but a default >
>  > method would solve that?>
>  >
>  > Andy>
>  >
>  > On 28/08/2020 13:33, Andy Seaborne wrote:>
>  > > >
>  > > >
>  > > On 28/08/2020 02:12, cstadler@informatik.uni-leipzig.de wrote:>
>  > >>>
>  > >> +1 This is a very good point; I also have around 10 years of active >
>  > >> code based on Jena and I was not yet able to upgrade to 3.16 
> because I >
>  > >> did not find the time to resolve several compile errors which are 
> at >
>  > >> least partly due to changes introduced for RDF*. And even after the >
>  > >> upgrade I would most likely run into the similar issues as Holger >
>  > >> points out.>
>  > > >
>  > > Hmm - where are you getting compile errors?>
>  > > >
>  > >>>
>  > >> I have have used the following to work around legacy issues with >
>  > >> RDF1.0/1.1:>
>  > >> JenaRuntime.isRDF11 = false;>
>  > >>>
>  > >> This might be a good place to allow for a>
>  > >> JenaRuntime.isRDFStar = false;>
>  > >>>
>  > >> Cheers,>
>  > >> Claus>
>  > >>>
>  > >> Quoting Holger Knublauch <ho...@topquadrant.com>:>
>  > >>>
>  > >>> 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 }>
>  > >>>>
>  > >>> 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*? 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.>
>  > >>>>
>  > >>> 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?>
>  > >>>>
>  > >>> Thanks>
>  > >>> Holger>
>  > >>>
>  > >>>
>  > >>>
>  >
> 

Re: Can RDF star support be deactivated?

Posted by Claus Stadler <cs...@informatik.uni-leipzig.de>.
Hi Andy,


In the meantime I have upgraded my code and it turned out that it was essentially the newly introduced visitor method for ElementFind that was missing in some of my transforrmers

- but that was easy to 'solve' for now by just raising an UnsupportedOperationException.


Cheers,

Claus


On 2020/09/01 17:42:41, Andy Seaborne <a....@apache.org> wrote:
 > Ping?>
 >
 > I'm not aware of any compile errors for APIs but and return signatures >
 > can make it complicated.>
 >
 > NodeVisitor doesn't include it (probably an omission - but a default >
 > method would solve that?>
 >
 > Andy>
 >
 > On 28/08/2020 13:33, Andy Seaborne wrote:>
 > > >
 > > >
 > > On 28/08/2020 02:12, cstadler@informatik.uni-leipzig.de wrote:>
 > >>>
 > >> +1 This is a very good point; I also have around 10 years of active >
 > >> code based on Jena and I was not yet able to upgrade to 3.16 because I >
 > >> did not find the time to resolve several compile errors which are at >
 > >> least partly due to changes introduced for RDF*. And even after the >
 > >> upgrade I would most likely run into the similar issues as Holger >
 > >> points out.>
 > > >
 > > Hmm - where are you getting compile errors?>
 > > >
 > >>>
 > >> I have have used the following to work around legacy issues with >
 > >> RDF1.0/1.1:>
 > >> JenaRuntime.isRDF11 = false;>
 > >>>
 > >> This might be a good place to allow for a>
 > >> JenaRuntime.isRDFStar = false;>
 > >>>
 > >> Cheers,>
 > >> Claus>
 > >>>
 > >> Quoting Holger Knublauch <ho...@topquadrant.com>:>
 > >>>
 > >>> 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 }>
 > >>>>
 > >>> 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*? 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.>
 > >>>>
 > >>> 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?>
 > >>>>
 > >>> Thanks>
 > >>> Holger>
 > >>>
 > >>>
 > >>>
 >

-- 
Dipl. Inf. Claus Stadler
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org/
Workpage & WebID: http://aksw.org/ClausStadler
Phone: +49 341 97-32260