[xtm-wg] [XTM_UCS] What will be our deliverables?

[Andrius Kulikauskas <ms@ms.lt>]

-------------------------- eGroups Sponsor -------------------------~-~>
GET A NEXTCARD VISA, in 30 seconds!  Get rates
of 2.9% Intro or 9.9% Ongoing APR* and no annual fee!
Apply NOW!
http://click.egroups.com/1/7872/4/_/337252/_/967609484/
---------------------------------------------------------------------_->

Hi Bryan and everybody, especially of XTM_ISS and XTM_CMS,
     Although we don't have a lot of use cases yet, I think there is
definitely a lot of important contribution that we will be making.  I
think we've hit a nerve, but everything is new, so it's hard to imagine
the scope of what we can accomplish.
     What will be our deliverables?  I think this means, what do we
intend to do over the next four months?  Especially, what can the other
subgroups look to us for?
     One important thing to note is that use cases can serve a wide
variety of purposes.  They can:
     OURSELVES) Help us figure out what "topic maps" means to us, the
active members of TopicMaps.Org, not just what is written in the ISO
standard.
     DIMENSIONS) Help us understand what are the underlying dimensions
(for example, from automated to manual, from structural to semantic,
from ... to ...) that "topic maps" can deal with in a sophisticated
manner.
     SPIRIT) Help us become aware of other projects that share the
spirit of topic maps, in that they involve the same underlying
dimensions, but are perhaps less sophisticated, or more sophisiticated. 
In other words, think of topic maps as a way of thinking, broader than
just a particular standard.
     ILLUSTRATION) Give us at least one clearly understandable example,
that is not contrived, but shows the real issues that the full blown
topic maps address.  Such examples help illustrate the standard for the
implementors.
     PROMOTION) Give us a whole quiver full of examples attractive to
different audiences that can help Cupid promote topic maps.
     CORE) Give us a spectrum of sophistication, along the various
underlying dimensions, so that we can argue which concepts are central,
and which are peripheral to topic maps.  We can present this spectrum to
our fellow subgroups should they need to decide whether a particular
concept should be made more pronounced, less pronounced, more explicit,
less explicit, removed or added to the XTM, which may not necessarily
match the ISO standard, but should match what TopicMaps.Org members
think of as a "topic map".
     COMPARISON) Use that spectrum to show how topic maps compares with
other solutions, such as RDF, along the same dimensions, and have the
use cases be the basis for any harmonization.  I doubt that anybody else
will have such a cool set of use cases, and that will be a tremendous
asset for topic maps, especially because they will show how great topic
maps are.
     EXPECTATION) Make such a spectrum of use cases available to the
public, so people can make sound decisions whether topic maps are the
right solution for them.  In many cases the answer may be, you don't
really need the power of topic maps now, but you are definitely headed
in that direction.  The use case spectrum shows the directions people
naturally head in.
     EXPLANATION) On the basis of such a spectrum, have a simple
modeling language that explains how structures like topic maps come to
be, why somebody would want to do something that sophisticated.  This is
a major goal of the Minciu Sodas laboratory, the reason why I am
participating, that we can conceptually show a progression of
sophistication between a very simple standard for tools for organizing
thoughts, for individuals working with www.thebrain.com or
http://thoughtstream.org or etc. and something as rich as topic maps. 
Topic maps, like it or not, are a modeling language.  Certainly the
implementor, and a reflective user, needs to think in terms of the topic
maps way of thinking.  The value of such a spectrum is great for tool
makers like TheBrain who have a technology that can work great with
topic maps, but really is a front end to a wide range of solutions of
varying degrees of sophistication.

     That's a long list, and maybe you can add.  I think an important
question now, one that we should ask our fellow subgroups, is which of
these are relevant for their work during the next three months.  Our
deliverables should be the minimum of what they need, and then
everything else we can pursue according to our resources.

     There are a lot of exciting benefits that can come about.  We're
just making them explicit, they've been in the past, and will be in the
future.  Steven Newcomb wrote on August 27:

>>>>The syntax was developed mainly by Michel Biezunski
during his lonely and heroic years of presenting the idea of
topic maps to potential users and listening carefully to
their feedback -- feedback that was often extremely
difficult to decipher, and that required him to develop a
deep understanding of the mindsets and world views of the
potential users of topic maps.  As a result, the interchange
syntax of topic maps is attractive to an extraordinarily
wide variety of users and potential users.  That
attractiveness is really what has made the topic maps
paradigm such an economically interesting phenomenon, and
it's the real reason for the existence of the XTM
Specification Authoring Group (AG).  

>>>>think of the development of the syntax as
being very like the development of a user interface, as if
users were actually going to type in their topic map
documents by hand (which they're not going to do, I know,
but many creators of topic maps will have a need to
understand and be intimate with the nuts and bolts of the
topic map resources that they're creating).  A user
interface must be intuitive -- it must teach users about
itself and about the functionality to which it provides
access.  During the development of a user interface, it is
almost inevitable that many user requirements will be newly
discovered.  Should we regard these requirements as *a
priori* less important than the already-known requirements
that will drive the process of developing a conceptual
model?  I think not!

A little out of context, but I take it as evidence that there really is
a need for all three subgroups.

Steven Newcomb also wrote on August 28th:

>>>>>I personally believe that dialogue between the modeling group and the
syntax group will bring a greater understanding of the basic ideas
here.  I do not believe that either group's models will be the truth,
or even that the combination of all models will be the truth.  The
truth is much more elusive and intangible than that.  But the truth
*does* exist, it *does* await further unfolding, our apprehension of
it *will* improve.  That improvement will be greater and sooner by the
use of reasonable and reasonably diverse approaches to expressing it,
especially in cases where multiple diverse expressions are *required*.

I think this is also true of the use case group. I think we pursue truth
by asking three questions:

Modeling group:  We reflect a lot, but do we take a stand?
Syntax group:  We take a stand, but are we implementing it?
Use case group:  We implement, but do we reflect on that?

So all three need to be in parallel, and to learn together.  It is great
that we have subgroups explicitly advocating for all three questions. 
Having these three groups will make a difference as to the success of
topic maps.  The use case group is new, so it would be great if we knew
the minimum of what we should achieve.  Then we can do a lot extra, as
we learn what is most useful for us to do.

So what should are deliverables be, what would be most helpful?

Andrius Kulikauskas
Minciu Sodas
http://www.ms.lt/importexport.html
ms@ms.lt

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

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