OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [xtm-wg] The XTM data model: the wheel has already been invented



Hi all!

I've been following the data/processing model discussions lately. It's
rather interesting to see the directions in which it has moved. The
target is certainly narrowing, but we're IMHO spending too much time
[and bandwidth] on the formalism in which it is to be represented.

Therefore I'd like to propose another alternative. :)

- - -

But first my view on things:

What _I_ would most like to have is a data model that describes the
types of things that exists in a topic map and the valid relationships
between them, including constraints on those relationships. 

I would also like to have a standardized API, but that'd have to wait
until after the data model has been created.

The most important thing being a rich as possible ontology for
describing the model; the more types of things the better. This makes
distinctions easier to recognize for readers of the model. 

T-nodes, A-nodes and S-nodes makes it hard to really understand the real
life implications of representing topic maps in computers. The model is
IMO too flat - too blurred - a bit too abstract/conceptual - the really
fine details are missing. It's a really nice document - I like it, but
it doesn't tell me the important things if I were to implement a topic
map system.

The formalism in which the data model is represented isn't all that
important. What's important is what goes into that model. So far we
haven't discussed that at all - except for the proposals that has been
put forward. Even the proposals haven't been discussed in any detail.

It surprises me that nobody has mentioned the specification that we've
ourselves been developing in this discussion -- XTM. Topic maps are
there to describe knowledge, so why not describe XTM's data model using
itself?

Some advantages:

  - Readers don't have to learn a new formalism.

  - The navigation tools available for navigating the model are
  exceptional - and they're really great learning tools.

  - The objects in the data model are addressable. If the data model
  topic map is given a fixed location on the topicmaps.org web server,
  or topics given PSIs, it would allow others to refer to it or
  retrieve its contents.

  Addressability allows us to further extend the knowledge stored in
  the model, by refering to the model topics from other topic maps.

  - Topic maps have a self-documenting feature!

  - Information resources [occurrences] of any notation can be
  attached to the objects in the model. This would allow UML diagrams
  and OCL constraints to be easily integrated. In fact nothing is
  preventing nobody to do whatever they'd like.

I'll post a sample XTM data model topic map document really soon.

All the best,
Geir O.

------------------------ Yahoo! Groups Sponsor ---------------------~-~>
Do you have 128-bit SSL encryption server security?
Get VeriSign's FREE Guide, "Securing Your
Web Site for Business." Get it now!
http://us.click.yahoo.com/EVNB7A/c.WCAA/bT0EAA/2n6YlB/TM
---------------------------------------------------------------------_->

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

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

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC