Re: topic IDs in XTM

[Jack Park <jackpark@thinkalong.com>]

Comments below...    (01)

At 02:45 PM 8/24/2001 -0700, you wrote:
>On Fri, 17 Aug 2001, Jack Park wrote:
>
> > Actually, you're not misinterpreting the spec.  Nexist does, indeed, take a
> > shortcut as it also does with class-subclass relations.  The actually cure
> > for this is to optimize the db schema in Nexist to use the <baseNameString>
> > instead of id.  That can be done at any time.  Remember, Nexist is an
> > engineering prototype, with lots of shortcuts and just plain crummy code.
>
>I'm no stranger to crummy code. :-)  This all is actually very useful;
>it's giving me a good excuse and test case to understand Topic Maps.
>
>More questions:
>
>1. You allude to Nexist taking a shortcut with class-subclass relations.
>Could you show some sample XTM that Nexist uses for an association between
>two topics?  I find the fact that XTM associations are not directional a
>little disconcerting, though obviously not impossible to deal with.    (02)

I created a couple of messageIDs just for creating tree structures using 
XTM.  The database TOPIC table contains a column called (i think) CHILDID 
which is, in fact, the TOPICID of a <topic> which happens to be a child of 
the <topic> identified by the row in the table.  I can then select for 
children of a topic, and I can select for parents of a topic.  When I 
booted Nexist just now to look at the children of the topic identified by 
the string "What are whales?", I noticed that the decompiler for 
<association> is broken (or is it "not finished yet"?).  I'll have to fix 
it and send another post to show some code.  Thanks for catching that bug, 
Eugene.    (03)

It's an interesting conundrum about how XTM associations are not 
directed.  They can take "apparent" directions when you assign <roleSpec>s 
to <member>s of <association>s.  Here, you can assign roles from any kind 
of taxonomic or other structure you wish.  In IBIS, for instance, were I 
not trying to keep the database as compact as possible, I would assign the 
role MainIssue to the original question of a new IBIS tree.  I would then 
assign other parent/child names to those tree members that follow.  But, 
for now, I view all that as implied and just ignore doing that work.  One 
of the hidden problems of XTM is that you can, if you go full monty with 
it, get awfully verbose.    (04)

>2. Playing around with Nexist, I noticed that it defines occurrences for
>every topic.  What are the URIs pointing to?  Are they entries in the
>database that contain metadata associated with an IBIS node (i.e. details,
>author, timestamp, etc.)?  And, if Nexist were to import a topic map that
>did not define occurrences for its topics, would it be unhappy?    (05)

IBIS tab is written to define every <topic> with an <occurrence> which sets 
a URI (actually, in SimpleGrove, it's just a file://... URI) for a tiny 
text file that holds the body of whatever you type in the "Details" area 
when you add a pro,con,comment,question, or idea to the tree. If you type 
nothing, there will be no file and you will see "null" in the details field 
when you browse that entry.    (06)

Nexist has author, timestamp, and the like, but, sitting down?, none of 
that is wired yet.
Nexist is ready for an overhaul of the database schema.  I'm hoping to get 
that finished before we actually take it into the classroom in a couple of 
weeks.  One changed planned is that IBIS <topic>s will have their 
<baseNameString> set to whatever your typed in response is, and Nexist will 
autoassign a TOPICID for the database, ending the tyranny of using topicID 
as a name.    (07)

If Nexist were to import an IBIS topic map, say, one exported by somebody 
else, that export would have included the occurrence 
definitions.  Otherwise, It would not be an IBIS/Nexist <topicMap> at 
all.  Nexist importXTM is agnostic on what it imports -- there's no way 
(presently) to tell it what TABNAME (e.g. IBIS) the import belongs to. If I 
recall rightly, all imports come in with an implied 'XTM' TABNAME making 
the topic map available to tabs that come in with the XTM identiry.  An XTM 
tab can see any <topicMap>, but an IBIS tab can only see <topicMaps> that 
are associated with an IBIS tab.    (08)

As you can see, the extensibility of the Nexist API derives from TABNAME 
(or TABID, I can't remember which). Oh! It's TABID.  Here's the schema for 
the <topicMap> table for HSQL:
CREATE CACHED TABLE TOPICMAP(TOPICMAPID VARCHAR PRIMARY KEY,TABID 
VARCHAR,BASE VARCHAR,AUTHOR VARCHAR,EDATE VARCHAR)
By assigning TABID to a TOPICMAPID, it becomes possible to mix topic maps 
from a variety of Nexist applications and have the right topic maps show in 
any given app.
  And, if someone wants to write a Nexist application (tab) that just 
happens to want to see all topic maps in the db, then that app should login 
as an XTM tab.  Right now, there are absolutely no security issues implemented.    (09)

In that regard, it is expected that a major fork in the Nexist tree will be 
one version configured to hand all the permissions and authentication stuff 
over to something like JBoss, UPortal, or some other J2EE front 
end.  Obviously, some approach to plugging NODAL into Nexist might bring 
these services as well.    (010)

>-Eugene
>
>--
>+=== Eugene Eric Kim ===== eekim@eekim.com ===== http://www.eekim.com/ ===+
>|       "Writer's block is a fancy term made up by whiners so they        |
>+=====  can have an excuse to drink alcohol."  --Steve Martin  ===========+    (011)