You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What steps will reproduce the problem?
1. load cecom-ddp-levels.ltm into omnigator or read via api
What is the expected output? What do you see instead?
The topic map fails to load, with:
Exception in thread "main" net.ontopia.topicmaps.core.ObjectRemovedException:
Cannot reassign object [basic.Topic, unassigned] as it has already been removed
from the topic map.
Please use labels and text to provide additional information.
Java version:
1.6.0_21
Runtime Environment:
build 1.6.0_21-b07
Ontopia:
version 5.1.0
An XTM version of the same topic map (generated via the API) is read
successfully. An LTM version of a different topic map is read successfully.
This particular topic map makes much more use of subject indicators.
Background:
I am stumbling my way through some development with Java (I am not a Java
programmer). I am currently using a pipeline approach:
1. XSLT to create LTM topic maps (from simplified RNG schemas)
2. Use ontopia api to analyze and enhance each topic map, adding relationships
3. Write each modified tm out as ltm.
4. Use the ontopia api to load the modified tm and write out an analysis as an
xml document.
As stated above, the full pipeline work(ed) for one schema's tm, but not
another. In the second case (cecom-ddp), I am attempting to use subject
identifiers to 'uniquify' the topics. These topics represent schema elements,
and I need to ensure they are not merged with the same element names in other
schema TMs.
It is entirely possible that I made some semantic errors when building the base
TM from the simplified RNG schema.
If nothing else, I am wondering whether there is any way to determine which
topic(s) in the TM is triggering the exception. The issue occurs even if I
simply read in the modified LTM and write it back out.
I am attaching the xtm that works as well as the ltm that fails, along with the
error from the api. Let me know if you need more source.
Cheers,
Eileen Kinley
Original issue reported on code.google.com by eileen.k...@gmail.com on 10 Sep 2010 at 10:18
Loading the topic map reproduced the problem. Looking at the traceback I see
that the problem is that the parser caches the reference to the display topic
(core.xtm#display), and somehow this topic gets merged away without the parser
discovering it.
Original comment by lar...@gmail.com on 13 Sep 2010 at 8:59
Fixed in revision 1366. Thank you for a very good issue report, which made it
easy for us to fix the problem. A test case for this issue has been added in
revision 1367.
Original comment by lar...@gmail.com on 13 Sep 2010 at 9:19
As a workaround you can move the four lines [id2 @"http://#display"] and the
one for #sort up to the top of the file. That will make it load without errors.
Original comment by lar...@gmail.com on 13 Sep 2010 at 10:12
Original issue reported on code.google.com by
eileen.k...@gmail.com
on 10 Sep 2010 at 10:18Attachments:
The text was updated successfully, but these errors were encountered: