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

[Patrick Durusau <pdurusau@emory.edu>]

	My Groups | xtm-wg Main Page | Start a new group!

Greetings,

(See comments on September 3, 2000 deliverable after the moment of clarification.)

Just a moment to clarify the work of the Use Case Subgroup of the XTM-WG:

The minutes of the meeting in Montreal reflect that by September 3, 2000, the UCS is to deliver:

> 1.An outline of the nature of their expected deliverables, and 
> 2.Anticipated implications for the work of the other groups.

The UCS is supposed to deliver its work by the mid-October meeting:

> An intermediate meeting should be held in mid October, at which the Subgroups will deliver their work, and then be dissolved. Version 1.0 of the XTM Specification
> should be completed between mid October and early December.

One assumes this is to allow the other groups to actually comment on and use the work of the UCS (and members of the UCS the work of other groups) prior to the release of the XTM Specification in December 2000.

The mission of the UCS was defined as:

> It is the mission of the Use Cases Subgroup to:
>
>      Identify representative use cases of XTM, 
>      Derive requirements of XTM from the use cases 
>      Evaluate XTM against requirements

However interesting it would be to explore the intellectual landscape beyond the confines of the mandate established in Montreal, such activities fall outside the work (and deliverables) of the UCS. Not to mention that even the "pedestrian" issues facing the various subgroups are more than enough grist to grind between now and the interim meeting dates as well as the final deliverable date. (Please do not be offended by my use of the word "pedestrian." The issues facing the working groups are extremely complex and important and will require all the talent the various groups can muster. I say the issues are "pedestrian" only to distinguish them from the type of discussion that occurs in Ogden and Richards "The Meaning of Meaning." A very worthwhile book but it is not relevant to the tasks that will result in a XTM Specification by December 2000.)

The mission of the XTM and its subgroups with deadlines were set at the Montreal meeting. I intend to discuss (in this forum) only matters that fall within the mission as so defined.

September 3, 2000 deliverable:

I will be submitting a response to the UCS survey later today (blush, bad when you expect other to answer absent your own) dealing with academic use of XTM.

In terms of our deliverable for September 3, 2000, would the following be a fair statement of what we want to deliver by mid-October?

1. A list of use cases sorted by a typology created by the UCS
2. A representative sample of the use cases explored in greater detail
3. A list of capabilities for XTM derived from the use cases
4. As an appendix to the deliverable, a sorted list of "raw" responses in XML

Comments, suggestions on the proposed outline of our deliverable? Note that this is simply our report of what we expect to deliver by mid-October.

Question: If we intend to explore beyond the confines of xtm-wg for use cases, should we establish a cut-off date of say September 30, 2000, for responses to survey? Something in very bold, clear type. It will take some time to digest the material and I am hopeful that the big rush of submissions will come earlier rather than later in the cycle.

Question: If there is no serious objection, can we agree to use the XML fragment I proposed as part of the annoucement. I can collate the responses (depending upon ultimate volume) but only if I can simply cut-n-paste into my XML master for sorting and processing by XSLT. (Peter, were you suggesting that your solution would be for an online form to store the responses in a database? That would allow us to gather both email responses as well as people who wanted to use your online form. If you will create a query to export to the XML fragment, we can then combine and collate the responses with a minimum of hand processing. Or I can export to a delimited file for import into your database but either way I would assume we are going to use XML as the format for transformation into HTML.)

Many thanks!

Patrick

--
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu
 
 

Andrius Kulikauskas wrote:

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

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

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