Hi Gustavo, One major compatibility issue will be the use of "if(Literal.getLanguage() != null)" in any current code, and if a language tag exists, "Literal.getDatatype()" will now return rdf:langString so you need to make sure that you check for "getLanguage().isPresent()" before checking datatypes. You will be able to pick up most of the getLanguage() != null cases by checking compiler errors.
The other incompatibility will be that because Literal.getDatatype no longer ever returns null, you will need to work on a database migration strategy for existing Literal instances that have null, and replace them with xsd:string if the language is missing, and rdf:langString if the language exists. URI and IRI are interchangeable in terms of RDF4J. A fuller migration guide is at: http://docs.rdf4j.org/migration/ You may want to split up the migration into steps, by stepping up to Sesame-2.8 first to pick up the getDatatype() != null cases first, then go to Sesame-4 to pick up the getLanguage() != null cases, before going to RDF4J with what are virtually all package name changes. Cheers, Peter On 29 March 2017 at 12:12, Gustavo Mora <[email protected]> wrote: > Dear, > > I'm a student of Computer Science, and I'm working on my application to > GSOC 2017, but I have some questions. BTW, I also compiled the code and > started playing with it. Firstly, there's a plan to migrate because there > are some classes that have replacements; for example, IRI instead of URI, > changes in some interfaces/classes names, use of optional, etc. Also, some > tests will fail because RDF4J stores a default string as literal, for > example. If we changed that, the next release is not going to have > compatibility with the previous ones? If yes, Is it necessary to maintain > some deprecated code? What other problems can I encounter in KiWi and > platform? > > Regards, > Gustavo Mora.
