[Inquiry] Re: Arisbe -> Inquiry

[elijah wright]

> >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.

*nod*

> 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)

i suspect that its a freaky thing to want to do.  (i don't know how
either, though i'm told that's one of the applications of the tools ;) )


> 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.

say more here?  i'm interested.  what are the two candidate views?


> 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.

topic maps seem extraordinarily cool.

> > > 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.

ok.

i think i agree - w/ a published subject indicator / 'map' (sorry for the
bad pun), you have some solid ground to push against.


> > > 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.

....

> > > 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.

hoping to see more activity in this neighborhood soonish ;)


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

haven't read this, but think that i probably should....

elijah