RE: CaveXML work plan - Objectives

New Message Reply About this list Date view Thread view Subject view Author view

From: Kouts, Devin S. (DEVIN.S.KOUTS_at_saic.com)
Date: Thu Feb 07 2002 - 20:17:44 CET


Return-Path: <owner-cavexml-outgoing_at_ethz.ch>
Delivered-To: cavexml-archive_at_cartography.ch
Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 0616B9F1B for <cavexml-outgoing_at_ethz.ch>; Thu,  7 Feb 2002 20:39:17 +0100 (CET)
Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 28) id 115959EC4; Thu,  7 Feb 2002 20:39:14 +0100 (CET)
Delivered-To: cavexml_at_cartography.ch
Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id DD1029F1B for <cavexml_at_cartography.ch>; Thu,  7 Feb 2002 20:39:12 +0100 (CET)
Received: from portal.east.saic.com (portal.east.saic.com [198.151.13.15]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with SMTP id 4D05B9EC4 for <cavexml_at_cartography.ch>; Thu,  7 Feb 2002 20:39:09 +0100 (CET)
Received: from mclmx.saic.com by portal.east.saic.com via smtpd (for karmail.ethz.ch [129.132.127.139]) with SMTP; 7 Feb 2002 19:18:02 UT
Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for cavexml_at_cartography.ch; Thu, 7 Feb 2002 14:17:46 -0500
Received: from MCL-ITS-EXIG01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.15) with SMTP id M2002020714174628494 for <cavexml_at_cartography.ch>; Thu, 07 Feb 2002 14:17:46 -0500
Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <1KD7FSSK>; Thu, 7 Feb 2002 14:18:24 -0500
Message-Id: <881CC7991757D51196CF00508BCFE591038DBF96@mcl-its-exs03.saic.com>
From: "Kouts, Devin S." <DEVIN.S.KOUTS_at_saic.com>
To: cavexml_at_cartography.ch
Subject: RE: CaveXML work plan - Objectives
Date: Thu, 7 Feb 2002 14:17:44 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-cavexml_at_karmail.ethz.ch
Precedence: bulk
Reply-To: cavexml_at_cartography.ch
X-Virus-Scanned: by AMaViS perl-11

Peter,

Excellent work. I find the revised Objectives, Scope and Approach very
acceptable.

Thanks,
DSK

Devin S. Kouts
SAIC Program Manager &
Senior Systems Engineer
703-676-6555 - office
703-966-8448 - cell
703-821-1796 - fax
devin.s.kouts_at_saic.com

-----Original Message-----
From: owner-cavexml_at_karmail.ethz.ch
[mailto:owner-cavexml_at_karmail.ethz.ch]On Behalf Of Peter MATTHEWS
Sent: Thursday, February 07, 2002 1:56 PM
To: cavexml_at_cartography.ch
Subject: Re: CaveXML work plan - Objectives

Thanks for posting initial comments on the draft work plan. In this first
response I have included only the comments related to the Objectives, Scope
and Approach (these three need to be read together). After that we can do
the Task List. Further below, after the comments, I have included the
correspondingly revised and overhauled Objectives, Scope and Approach for
your consideration. Now that an "Approach" has been introduced, some of the
original Objectives have been moved to there, which is where they more
properly belong. I'm sorry we have to spend time on this boring bit, but I
hope you will agree that it will help us in the long run if we can all be
clear about the task in hand. Hopefully the revised Objectives etc will
make things clearer.

==============================================================

At 11:45 19-01-02 -0500, Kouts, Devin S. wrote:
>The first objective is very broad in scope, and seems ultimately
>unacheivable by
>this small assemblage of know-it-alls. I.e. "produce a format ... for ...
>speleological data", the scope of such a format would be tremendous.

Devin is right of course, and indicates that we need to clarify the
Objectives. When we set up the group I indicated that we would only be
working on the format, not all the actual speleo definitions, apart from
the survey/mapping ones of course, and that the other WG (Field Definitions
WG) would be working on definitions - a long ongoing job to be carried on
by the various experts in the various speleo disciplines. Obviously our WG
would be contributing the survey & mapping fields. Unfortunately this
aspect was not clear enough in our Objectives, although the "Scope" on our
web pages, which I should also have listed, does make it clearer. So I have
reworked things a fair bit in the revised Objectives etc further below. The
relevant part of the original Scope reads:
"* Establish and recommend to the Field Definitions WG which entities and
fields are needed for cave surveying and mapping work, together with their
definitions.
* It is not required to finalize and publicise the "definitions" of any
data fields - this will be done by the Field Definitions WG."

>I would improve that paragraph by changing the following phrase "including
>data for cave surveying and mapping" to read "beginning with data for cave
>surveying and mapping".

OK.

>After that standard is established many people in this forum may likely
drop
>out and let the hydrologists, biologists, geologists, etc. carry on with
the
>inclusion of additional "speleological data".

See also above. Yes, our group is only for establishing the format of the
transfer mechanism, which should then be able to be applied to *any* speleo
fields, once they are defined. The fields themselves would be defined and
publicised by UISIC's other WG, the Field Definitions WG, which does plan
to call in the various experts via sub-WGs to establish for themselves
which fields they need and to define them. Our WG happens to be the
"experts" doing the survey & mapping fields, as well as using them to
initially establish the format. The Field Definitions WG has not been
properly activated yet, but some preliminary work can be seen via this
UISIC web page:
http://rubens.its.unimelb.edu.au/~pgm/uisic/exchange/atenlist.html
Once we agree on our survey & mapping field definitions they would be added
to these pages.

========================================================

At 22:37 19-01-02 -0800, dkouts wrote:
[snip]
>I performed requirements development interviews with many of these leading
>developers of cave surveying software in 2000. I brought their inputs
>together in a matrix analysis that was designed to illuminate the cave
>survey data elements common to each author's schema, as well as point out
>those that were unique.
>
>While it is perfectly acceptable to reinterview those developers, should
>anyone choose to do so, for the same information, it might not hurt the
>interviewer to first familiarize themself with the information already
>collected and presented on this subject at -
> http://www.psc-cavers.org/xml/Analysis.html

Yes, I expect we'll be taking advantage of this very useful list (thanks
Devin!) when we come to set out the fields.

========================================================

At 13:22 20-01-02 +1100, Michael Lake wrote:
[snip]
> Objectives (The broad targets we want to achieve)
> > =========
> > 1. Produce a data format which is hardware and software independent for
the
> > transfer and the archiving of speleological data, including data for
cave
> > surveying and mapping, and utilising existing international transfer
> > standards such as XML and related standards if possible.
>
>As XML is more than just a 'transfer' standard should we drop the word
>transfer in "existing international transfer standards"? It would then
>just read "utilising existing international standards".

OK.

[snip]
========================================================================

At 13:04 21-01-02 +0300, Alexander Nickolsky wrote:
[snip]
>The process of cave surveying has at least three stages, each of them
>having its own data model.

Yes, we need to keep this in mind.

========================================================================

Revised Objectives, Scope and Approach for comment
==================================================

Objectives (The broad targets we want to achieve)
==========

1. Produce a generalised data format which is hardware and software
independent for both the transfer and the archiving of speleological data,
utilising existing international standards where possible, and designed for
use with the speleological data field definitions published by the UISIC
Field Definitions Working Group.

2. Identify and define the entities and fields involved in cave surveying
and mapping to use as an example when producing the generalised data format.

3. Achieve international agreement for the format.

4. Promote wide knowledge of and use of the format among cavers, cave
managers and cave/karst researchers.

5. Produce explanatory and training material for use of the format.

6. List, facilitate and organize production of software to make use of the
format.

Scope (Inclusions/exclusions or limits to the Objectives)
=====

1. Basic scope: The task of this Working Group is to design, implement and
promote the format for speleological data transfer and archiving. It does
not include defining all the cave/karst data fields which can be used with
the format, except for those used in surveying and mapping, so that a
practical and complex example can be used in arriving at the format.

2. Storage type: General storage of survey data is specifically not
included because people will need to store their data for use in a variety
of ways, e.g. in text files, proprietary database software, proprietary
survey software files, etc. The Group is concerned only with transfer
between storage methods, and with long-term archiving which needs to avoid
the use of any proprietary or specific software which may in time become
unavailable or incompatible. However there is nothing to prevent data being
stored for actual use in this transfer/archiving format if that turns out
to be convenient.

3. Data sequence: The format designed should allow all the data, including
shots and their fields, to be transferred and archived independently of any
particular for-use data sequence, such as chronological, by connectivity,
by passage, etc. This is because the data sequence will be different for
different programs. The sequencing of the data for use by a particular
survey program should be performed by separate software, such as a utility
of the destination survey program, which converts the standard transfer
format into its own format. Therefore the standard format must include
sufficient fields to allow this resequencing. Note that one of the
objectives of the group is to liaise and facilitate the production of such
utilities.

4. Fields publication: It is not required to do the work of publicising the
definitions of any data fields - this will be done by the Field Definitions
WG, upon our advice.

Approach (How we want to go about the project)
========

1. Use survey and mapping fields as a practical and complex working example
while designing the standard format. These fields have been chosen because
cave surveyors have several survey programs available to work with, but
each has its own special data format, hence there has been a need for a
survey data exchange mechanism for some time.

2. Understand and document the data structures of cave surveying and
mapping. Include in the documentation as many variations of survey method
as possible.

3. Implement the standard using the XML family of international standards
(Extensible Markup Language).

4. Decide how our standard would fit into the overall scheme of survey and
mapping procedures.

5. Prepare a pilot CaveXML draft standard to completion, one which is
limited to a commonly used simple form of cave survey.

6. Expand the CaveXML standard to cover the more complex alternatives.

7. Co-operate with other groups where necessary in arriving at the format,
including advising the Field Definitions WG which entities and fields are
needed for cave surveying and mapping, together with their definitions.

8. Provide public ongoing progress information during the work of the group.

9. Provide an annual summary report to UISIC, reviewing at each whether the
work of the group has been completed, and if so, terminating the group.

                                   ******************************

Are the above revised Objectives, Scope and Approach now acceptable? Please
indicate whether you agree, and if not, advise suggested improvements.

Then when these are accepted we'll tackle the Task List.

Even when accepted, I feel we should not set the Objectives etc in stone,
but make considered updates whenever we see the need during the progress of
our work.

Regards,

Peter

At 16:52 19-01-02 +1100, Peter MATTHEWS wrote:
>Dear All,
>
>Although a lot of survey and xml issues have been raised by the group over
>the past year and a lot of excellent discussion on them has taken place,
>we haven't really established any conclusions yet. It is time we reviewed
>where we are at, and where we go from here.
>
>Now that we have a much better feel for what's involved, I would like
>first of all for us to do a quick check that we are still happy with our
>Objectives and Task List, and then, with general agreement on the separate
>tasks before us, systematically tackle them one by one.
>
>If we are to end up with general agreement on a final standard, it is
>important that everyone can follow and understand what is being done along
>the way. A systematic step-by-step approach will be needed to achieve
>this. And as software engineers know, it pays to sort out the "analysis
>and design" before beginning the fun part, the programming. This is not to
>say that some "programming" (here, XML design) should not be done early to
>check out various feasibilities etc.
>
>Below are the existing Objectives and Tasks as currently shown on our web
>page, together with a new section which I have called "Approach", which
>aims to clarify our planned general approach to the project. I have also
>numbered them for easier reference during the discussion, and indented
>three sub-tasks which I now notice should have been indented on the web
page.
>
>I think the best thing will be first to ask for general comments, and
>after that look at any individual points as seen necessary.
>
>Keep in mind that although we are concentrating on cave survey data at
>this point, our results (principles) should ultimately be applicable to
>any speleological data.
>
>If you do want to respond during this review but cannot do so just yet,
>please email me directly saying how much time you need. And if as we go
>through the review you are in agreement with a point, or do not have any
>extra comment, please indicate this also, so that we have a better idea of
>who is participating. I hope everyone can find the time to help.
>
>
>Objectives (The broad targets we want to achieve)
>=========
>
>1. Produce a data format which is hardware and software independent for
>the transfer and the archiving of speleological data, including data for
>cave surveying and mapping, and utilising existing international transfer
>standards such as XML and related standards if possible.
>
>2. Co-operate with relevant other groups where necessary in arriving at
>the format.
>
>3. Provide public ongoing progress information during the work of the
>group, including an annual report to UISIC.
>
>4. Achieve international agreement for the format.
>
>5. Promote wide knowledge of and use of the format among cavers, cave
>managers and cave/karst researchers.
>
>6. Produce explanatory and training material for use of the format.
>
>7. List, Facilitate and organize production of software to make use of the
>format.
>
>
>Approach (The overall way in which we want to tackle the project)
>========
>
>1. Understand and document the data structure of a cave survey. Include in
>the documentation as many variations of survey method as possible.
>
>2. Decide how our XML standard would fit into the overall scheme of survey
>and mapping procedures.
>
>3. Prepare a pilot CaveXML draft standard to completion, one which is
>limited to a commonly used simple form of cave survey.
>
>4. Expand the CaveXML standard to cover the more complex alternatives.
>
>
>Tasks (Individual tasks which will need to be done to achieve our
>Objectives.
>===== This is the original list, and some are already partly or
>fully done.
> [My comments shown in square brackets] )
>
>1. Draw up the Scope and Objectives for the group. [Done, now for review]
>
>2. Establish the official WG delegate for each interested country (UIS
>voting is by country). [Not started]
>
>3. Catch up with the good work which has already been done in this area:
>Each existing worker to post a "summary" of what they have done, as well
>as point us to their detail, e.g. via their web page. {Done]
>
>4. Establish website and Mailinglist as a platform for discussion and
>publishing roadmaps, working drafts and results. [Done]
>
>5. Decide on the range of fields which we need to consider in a survey
>data transfer:
>
> 5.1 Draw up a survey and mapping ERD (Entity Relationship Diagram)
> recognizing the
> difference between surveying and mapping data. [I am about ready to
> post an
> initial draft]
>
> 5.2 Fill out the fields needed in each entity of the ERD. [Many
> already discussed]
>
> 5.3 Define each of these fields.
>
>6. Define structure of the XML file: root-element, nesting, elements and
>attributes, etc.
>
>7. Produce regular working drafts for the proposed standard.
>
>8. Provide DTD and Schema.
>
>9. Provide Documentation of the field definitions and data structure.
>
>10. Publish the Working Drafts for discussion and comments.
>
>11. Make Revisions after public comment.
>
>12. Vote by WG delegates.
>
>13. Ratification by UISIC.
>
>14. Publicise the format after acceptance.
>
>15. Produce explanatory and training material.
>
>16. List software needed and organise it to get done.
>
> *************************
>
>
>So first of all, are there any *general* comments about the above
>Objectives, Approach and Tasks, ... or whatever? Please try to reply
>within a week or so, say by Mon 28 Jan, or else let me know if you need
>longer. After that, we'll look at them in more detail.
>
>Regards,
>
>Peter


New Message Reply About this list Date view Thread view Subject view Author view

This archive was generated by hypermail 2b30 : Thu Feb 28 2002 - 23:00:00 CET