Re: [xtm-wg] XTM Requirements (Was RE: Is this valid per HyTime? - topicmapmai l thread)

["Jack Park" <jackpark@verticalnet.com>]

With regards to Daniel's comments below, I have begun to envision a scenario
in which XTM is built to do precisely what the ISO standard already does,
and just a little bit more.  My opinion is that topic maps, as they were
originally conceived, are more than powerful enough to suit the needs of a
lot of users.

But, judging from the many papers at Paris, there is still this thrust to
achieve the ability to represent knowledge vastly richer than XTM would be
capable of at this time.  There were papers on RDF vs XTM, and on combining
RDF or other semantic network implementations directly with XTM.  After
studying the issue in my own way, I conclude that XTM is just simple enough
that many will use it as is.  But then, the pressure to enhance it.  My
thinking suggests a simple enhancement to XTM to allow it to have pointers
other than occurences; pointers into a richer network.  This then builds a
kind of 3 layer architecture, one in which the raw material resides, say, at
the bottom. A very rich semantic middle layer resides just below the XTM
layer which, itself represents the user's view into either the rich middle
layer, or the raw material (as presently expressed in occurences).  My
hipshot at this just asks for one additional kind of link in the XTM dtd.
The precise nature of the new middle layer need not necessarily be a part of
even an extension to XTM. Just leave the anchors so we can use it when it
happens. Daniel has a point when he says such a goal is unachievable, to
which I add: at this time.

But then, get this: I am building a java-based open source XTM editor. It is
made from the program Jext (found on SourceForge), and another program
called GraphMaker.  GraphMaker allows me to draw topic maps as ovals and
arcs.  But it goes one tiny step further: it records the x,y,z location (z
for future 3d expansion) of the node, such that it remembers where the nodes
are placed in a picture.  I would respectfully submit a request for one
teensy addition to XTM: something like additional attributes on <topic>
(x=,y=z=) so that my system will work easily.  GraphMaker originally exports
lists of nodes and arcs. I am modifying it to label those according to XTM.
One then copies and pastes from GraphMaker to Jext and Presto!, you've got a
topic map.

In summary, I am asking for two tiny additions to XTM, and suggesting that
XTM remain purely a topic map system.

Jack

From: Daniel Rivers-Moore <daniel.rivers-moore@rivcom.com>

> This very interesting discussion that is going on in
> topicmapmail@infoloom.com emphasises the need to develop the Requirements
> document for XTM. I agree that this can be done in parallel with the work
of
> the Modeling Group, if that is deemed appropriate.
>
> Eliot has said of HyTime that it was "not intended to be complete with
> respect to knowledge
> representation". Is XTM intended to be complete with respect to knowledge
> representation? What do we mean by that? These are requirements-definition
> issues.
>
> My personal position is that "complete with respect to knowledge
> representation" is an unachievable goal, since humans have not yet managed
> to understand what knowledge is sufficiently clearly to know what it would
> mean. However, the ability to express some of the semantics that are under
> discussion in this and other recent threads, to do with classification,
> subtyping, class-instance relationships, transitivity and symmetry of
> relationships, etc, is important enough in my view to provide a useful set
> of candidate requirements. We'd need to decide which of these candidate
> requirements we include in the formal requirements for XTM. Then we'd need
> to decide how they are met, and this could include meeting some in the
> formal core model and others in public subjects.
>
> Eric asks "Do public subjects have the same degree of enforceability as
> something stated in the standard?" The answer is "Yes if they are stated
in
> the standard".
>
> This rhetorical answer is not a joke. I suggested in the modeling group
that
> we could have a formal "core" model AND a set of public subjects in the
> standard. I believe this is what the ISO WG is coming round to also. We
> could also have a base syntax (which is a syntactic representation just of
> the core model, so that users of the public subjects would make them
> explicit using the core syntax) AND a fuller syntax in which the public
> subjects get enshrined in special element types or attribute names. This
is
> already done in the ISO standard, where alternative syntaxes are provided
> for certain constructs, with the express statement that they are
> semantically equivalent. My suggestion would be that the base syntax
provide
> only one syntactic representation for each construct in the core model,
but
> that the  alternative syntax might provide more than one, with clear
> mappings back to the core model plus public subjects.
>
> Daniel



------------------------------------------------------------------------
Create professional forms and interactive web pages in less time 
with Mozquito(tm) technology.
Form the Web today - visit:
http://click.egroups.com/1/5770/4/_/337252/_/962045146/
------------------------------------------------------------------------

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com