General note on error handling. The current code simply propagates most exceptions and some others it swallows completely. Ideally, the processor should tolerate errors and try to recover. For example, if a statement could no be parsed, then it might be possible to continue with the ItemDocument and just leave away this statement. We don't need to recover on the sub-statement level (if one part of a statement is left away, the meaning of the whole statement is changed, which we don't want; in contrast, leaving away one statement or one label from an EntityDocument does not change the meaning of the rest but just drops something). When implementing this type of robustness, the errors should not be hidden completely. Instead it would make sense to log them as errors. In some rare cases where you can recover, e.g., by assuming some default value for a broken entry, you could also log warnings instead. The public entry points can still throw exceptions if the EntityDocument could not be converted at all.

Related to this, you may want to distinguish JSONExceptions (the JSON object could not be read) from formatting exceptions (the JSON did not have the expected format, including cases where some string in the JSON was not what it should be). It might be worth to create a new exception class for this. Private methods can still throw their JSONExceptions. Only the methods that try to recover (or that try to report exceptions to the outside) should handle them and possibly re-throw a converted exception.