Currently the LTM-Parser of TM4J (v 0.8.3) generates a generic ID for every Topic it creates. The ids defined in the LTM-file are used as the fragment-identifier of the resourceLocator, but they are not used as the internal tm4j-id. This is contrary to how the XTM-Builder behaves, who tries to preserve the ids assigned in the xtm-source as the internal tm4j-id.

This means firstly, that a topic which origins from a LTM-source is not identifiable byID.

An secondly, a tolog query that uses the default form of topic reference uses the ids of the TopicMapObjects, queries that rely on objects that originated from ltm-sources, will always fail.

If you don't need to identify objects byTolog, you can safely merge from ltm-files and identify the objects byResourceLocator.

If you must use tolog, then you must either merge from an XTM file or express your query using the subject indicators of topics in the LTM file (these are expressed using the "http://my.subject.indicator" tolog construct).

In order to provide custom classes to a harvesting process, you have three options: