[Inquiry] Re: Arisbe -> Inquiry

[Jack Park]

At 01:30 PM 3/10/2003, elijah wright wrote:

><snippage/>
> > i hope to hear more pretty soon.  incidentally, this whole business of
> > maintaining a complex linkage system in portable form is one of those
> > things that i began addressing in my theme-one program way.bak when.
>
>how do XML fragments and schemas take a stab at this ("maintaining a
>complex linkage system in portable form")?  one would think that they
>would be quite useful...  'specially if you can write transforms from one
>flavor of data into another one.

There are many ways to deal with maintenance of complex links. My approach 
has been to follow lessons learned from both topic maps and frame-based AI 
systems thinking. I maintain a series of "associations" which, in my 
implementation (speaking of NexistWiki here), permit a form of hypergraph, 
in which one association may have many links radiating from it, and one 
link leading into it. Each completed link
(origin->destination) becomes the equivalent of a labeled arc, taking the 
name of the association itself.

I write import routines to map different XML source documents into the 
internal structure of a relational database, and I write export routines to 
write XML files from the database.  Others might perform mappings between 
XML dialects using XSLT, but I haven't needed to do that. (Truth be told, 
I'm not sure I know how to do that ;o)

On rereading this before shipping, I'm inclined to visit "portable form" a 
bit more. It's just not clear what "portable form" might mean. I can see at 
least two views, both related to the serialization scheme chosen; there 
seem to be two camps, ergo, two candidate views. RDF comes to mind and is 
being extremely popular these days.  RDF always appealed to me; as a 
frame-based AI jockey in a former life, RDF makes plenty of sense, and, 
when combined with RDFS, gets quite powerful.  XML dialects for graphs also 
come to mind, and XTM is the dialect with which I am most familiar.

My take on the two views is this: it really doesn't matter which route you 
take, but, to me, the underlying topic maps application model ought to be 
considered, no matter which direction is taken. the SAM, as it is called, 
is a really powerful approach to processing the graph. Topic maps are being 
built with three different approaches, XTM if you prefer XML, HyTM, if you 
prefer SGML, and with RDF.  All three are, imho, portable, perhaps with the 
XML and RDF versions being the two most popular at the implementation 
level, and, with TM4J, XTM in Java is becoming rather easy.

> > i called it "content addressable relative memory access" (carma), or
> > "graphically abstract structure" (gas), and this came up again
>
>funny :)
>
> > when jack started to talk about building desktop modules that you would
> > then have to keep coordinated with each other and with the master/mirror
> > copies.
>
>synchronization without intervention is Really Hard, if you don't have a
>common ground from which to evaluate two things... that common ground can
>be as simple as "which one changed last", but that still can't cover all
>possible cases where changes in a system happen...
>
>i dont think i'm making sense ;)

Sure you are. Topic maps were invented with merging in mind, so, it seems 
reasonable to syndicate content as topic maps, then simply subscribe to 
those syndications and build ever-larger topic maps.  What, then, is the 
common ground? If I am following this thread with the right set of 
interpretive lenses, then I would suggest that published subject indicators 
make merging topics much easier.


> > it's really just virtual copies, or even more archtypical, the theory of
> > manifolds all over again. we are yet to finish that conversation/story.
>
>hehehe

I think that Jon was responding to a query I made for ways in which 
databases could be merged without regard to the *id* attributes, since, at 
least, speaking in terms of my implementation strategy, the id attribute is 
a locally generated value and, thus, simple database joins would suffer 
identity collisions.  My more recent thinking has been to move, instead, to 
the notion of syndication in XTM (XML topic maps notation) and pay 
attention to topic types.

> > > a couple of my fellow students here (chris dent and kathryn labarre)
> > > were working on integrating 'purple numbers' into mailing list archives
> >
> > yes, i remember their names.  i gather that jack's notion of
> > "addressable information resource" (air) is in that ballpark.
>
>i think so.
>
> > that's dormitive right now --- http://www.nexist.org/wiki/ yup, it's
> > still sleeping ... but he says any day now ...
> >

"he says any day now..."" <hehehe> Yup. I meant that. Any day is much, much 
closer. I finally got my associations and the IBIS discussion space 
working, and later this week, the most recent version (1.8) of NexistWiki 
will be online, an instance of which will be found at 
http://www.nexist.org/jt/ , which is a site being built for Joy Tang who 
intends to collect stories from hundreds of kids in orphanages in Africa.

Hope that explanation helps.

>elijah

Cheers
Jack


---------------------------------------------------------------------------
XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor

Build smarter kids globally to reduce the need for smarter bombs.