Sounds like a sensible thing to do, if we're going to have breaking changes we may as well do them in bulk ;)
I think for TDB it would be simpler to move forward to the new RDF 1.1 behaviour on with no backwards compatibility since as you point out doing so would substantially impact performance. I would strongly suspect users will prefer a change in behaviour versus performance regressions Rob On 15/05/2014 13:27, "Andy Seaborne" <[email protected]> wrote: >Jena 2.12.0 will be the first release with Java7 as the base. > >At the same time, how about making the final changes for RDF 1.1? > >https://issues.apache.org/jira/browse/JENA-193 > > >This could be controlled by a flag which defaults to OFF for this release. > >At this stage, OFF seems wiser to me because the effects, while often >quite small are widespread, and visible in application code. > >** xsd:String > >http://mail-archives.apache.org/mod_mbox/jena-dev/201310.mbox/%3C525A8428. >1050207%40apache.org%3E > >1/ xsd:string and simple literals become the same. > >"ABC"^^xsd:string is the same term as "ABC" > >2/ rdf:langString > >The data type of a literal with language tag goes from null to >rdf:langString. > >If code has been checking language then datatype, typically formatting >code, no change is needed for (2). But it needs testing and bedding >down. (1) needs all output formats to be tweaked, which means two >places; RIOT and RDF/XML > > >Changes needed: >+ NodeFactory to set up things appropriately > >+ Output formatting to output as appropriate > (that is, without ^^xsd:string). > >+ (Optional) RIOT to ask the NodeFactory for correct nodes. > >and testing. > > >* What will break > >(some) Persistent data needs reloading. > >Any persistent data system that currently distinguishes between simple >literals (no datatype, no language tag) and xsd:strings will be affected. > >TDB currently keeps these are distinct. With the change, it will write >^^xsd:string in short form internally so data that just uses plain >literals (simple or with language tag), and not ""^^xsd:string will be >unaffected. > >Any data that is mixed or uses xsd:string exclusively will be affected. > >It looks like it is very expensive to put in full compatibility code in >TDB query solving - it would need pulling in the node lexical form all >the time and currently TDB goes to a lot of effort to not do that and >instead work in NodeIds (from a NodeId alone you can't tell if it's a >simple string or xsd:string). > >Unclear: external tools that rely on xsd:string (e.g. Protege maybe - it >used to, don't know the current state). > >* Good news > >ARQ optimization of equality filters can become more aggressive and >handle strings better. > >** Bnodes for graphs >https://issues.apache.org/jira/browse/JENA-608 > >This is almost all done. Missing is bnodes in SPARQL INSERT-DELETE / >GRAPH syntax and for INSERT DATA / GRAPH. > >RDF syntax parsers (NQ and Trig) are already done. > > > Andy >
