[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: P&P: RE: Fw: SUO: Motion to Adopt Standard Upper Ontology Working Group Development Guidelines, Version 1.0 D5
- To: "Frank Farance" <frank@farance.com>, <suo-policies@ieee.org>
- Subject: RE: P&P: RE: Fw: SUO: Motion to Adopt Standard Upper Ontology Working Group Development Guidelines, Version 1.0 D5
- From: "West, Matthew R SITI-ITPSIE" <matthew.west@shell.com>
- Date: Sun, 21 Dec 2003 17:45:40 -0000
- Sender: owner-suo-policies@majordomo.ieee.org
- Thread-Index: AcPHPZjcpnDprqJ+Sh+L8fDkPln9XgAdtuQg
- Thread-Topic: P&P: RE: Fw: SUO: Motion to Adopt Standard Upper Ontology Working Group Development Guidelines, Version 1.0 D5
Dear Frank,
See responses below.
Matthew West
Principal Consultant
Shell Information Technology International Limited
Shell Centre, London SE1 7NA, United Kingdom
Tel: +44 20 7934 4490 Mobile: +44 7796 336538
Email: matthew.west@shell.com
Internet: http://www.shell.com
http://www.matthew-west.org.uk
> -----Original Message-----
> From: Frank Farance [mailto:frank@farance.com]
> Sent: 20 December 2003 21:12
> To: West, Matthew R SITI-ITPSIE; suo-policies@ieee.org
> Subject: Re: P&P: RE: Fw: SUO: Motion to Adopt Standard Upper Ontology
> Working Group Development Guidelines, Version 1.0 D5
>
>
> Matthew-
>
> I am strongly opposed to your procedures document because it
> re-invents terminology and parts of the standards process
MW: This is a misinterpretation of what I am trying to do. What
I am doing is extending the standards development process in a
way that adds some features that are important when developing
ontologies - a quality management approach - and placing it
within the context of the existing standards development process
(which is really no more than RRO plus a style guide plus a
requirement to submit a draft to the IEEE SA).
> --
> and it re-invents them imprecisely, which is of little good
> to us.
MW: If you wish to help with the precision on specific points
with specific corrections I would be happy to make improvements.
However, I am happy to move forward with something that is able
to be useful even if it is capable of improvement.
> I believe you are a participant of ISO TC184, yet I
> would have expected that your documents regarding the
> standards process would have used ISO "standards terminology"
> (e.g., ISO/IEC Directives, ISO/IEC Guide 2, etc.) rather than
> using the Oxford English Dictionary (<-- good for lay people,
> poor for technical definitions).
MW: If I were in ISO I would, but we aren't. I might add that
in SC4 we have a wide range of procedures documents that add
to the provisions made by ISO to support the specialised kind of
work they do (rather similar to what is done here).
> For example, the terms
> "conformance", "defect", "definition", "example", "formal
> issue", "informative", "normative", "principle", and "term"
> are all defined in ISO sources or have their ISO equivalents
> (e.g., "formal issue" would be a line-item on the ISO comment
> form, which is part of comment resolution, which may be part
> of ballot resolution).
MW: We are not part of ISO, and ISO develop their documents
specfically for developing ISO (and in some cases IEC)
standards. So for example the ISO/IEC Directives are made
publicly available, but for that purpose. I notice that
the ISO/IEC Guide 2 is available for sale, so presumably we
would be safe using those. However, I don't have a copy.
I presume you do, so if you would care to contribute by
making available the appropriate definitions and references
I will happily include them in preference to the ones I have.
>
> Regarding the notion of "principles", standards have a notion
> of "provisions" (requirement, recommendation, statement,
> instruction). We should simply use what already exists. The
> wording in Clause 4 appears to be either recommendations or
> statments -- my guess is that you intend for
> "recommendations" since there are no "requirements" in Clause 4.
MW: The provisions of Clause 4 are statements.
>
> Regarding Clause 5, the work programme for this working group
> is clearly defined: currently, we have 1 PAR (project)
> outstanding <-- that is our work programme. If we want more
> projects, we need to request them (I haven't seen any
> requests for additional projects).
MW: We have one project, we have a number of work programmes that
are contributing elements towards that project. I expect we will
have a number more before we are finished. Whilst I would agree
that we would need a new PAR for something distinctly different,
I don't think we yet see ourselves developing a number of
standards.
MW: On the other hand, it is clear that the PAR does not reflect
the current direction of the standards we are developed, and I
would recommend that we revise the PAR to better reflect our
collective intent.
>
> Regarding subclause 5.2 and 5.3, the so-called "deliverable"
> is what IEEE calls a "standard", "recommendation", or
> "guideline" <-- a formal result of a unit of the work
> programme (project == unit of work programme).
MW: But internal procedures documents and other material that
was not intended to be an external standard is also included.
Your items are included within that, as the definition intend
to make clear.
>
> So I suggest we postpone discussion of your procedures
> document until you can tell us how we make progress on the
> work we a required to do.
MW: The document is precisely what we need to make progress on
the work we are required to do. The only time I have ever seen
progress in work of this nature is when an active issues log
has been maintained.
>
> Regarding Clause 6, for international and national standards,
> your concerns about "an untrue statement, an unclear,
> ambiguous or misleading statement, something missing that is
> necessary" aren't the proper criteria for issues. The
> criteria for issues is: text that causes the lack of
> consensus (regardless of reason).
MW: That may be the general case, but when you are developing
ontologies or data models the reasons above are the ones that
are important.
> As an example, certain
> standards wording is purposely ambiguous (e.g., it permits a
> range of implementations) and other kinds of standards
> wording purposely have features where "something missing that
> is necessary" (<- this is known as "implementation-defined").
> So I believe this criteria is incorrect.
MW: I think you will find few here who would agree that when
defining a concept in an ontology that it is a good idea for
the definition to be ambiguous. That is what we are defining
here, and so we need to refine the more general standardisation
provisions so that they are effective for the work we have to do.
>
> Regarding Annex 3, the split between "normative" and
> "informative" is inaccurate -- whole clauses and subclauses
> can be informative.
MW: That is easily fixed. (done)
>
> If your notion of "deliverable" means "project" in the IEEE
> sense, then your process has re-invented the IEEE process.
MW: It includes but is not limited to "project" and it does not
re-invent the IEEE process, because there hardly is one that I
can detect for actually developing draft standards etc except
the use of meetings under RRO. That is probably sufficient for
many purposes, but not here. We are doing quite specialised
work that needs specialised procedures.
> If your notion of "deliverable" does not mean "project" in
> the IEEE sense, then it is unclear how you "devlierable"
> actually relates to the P1600.01 project this is established
> -- i.e., this is all nice discussion, but the purpose of IEEE
> Working Groups is to produce standards, not just facilatate
> discussion.
MW: Quite. Getting out of that mode is just what these
procedures are intended to achieve. If we can start identifying
and resolving issues, we might just get somewhere.
MW: Equally, I believe that we will need to develop a number of
intermediate deliverables that will contribute to some final
standards document(s). You can see evidence of these today in
the IFF work, and the other starter documents.
>
> As you can see, I believe there are major problems with your
> document
MW: Well there may be a few rough edges still - but that can
be fixed easily enough, and I believe it is usable as it is.
For the rest, I believe you misunderstand what the document
is about.
> -- and I find the document unnecessary because we
> already have a document for the IEEE standards development process.
MW: The existence of an IEEE standards development process has no
bearing on whether or not we need to agree some additional provisions
for how we undertake our work.
>
> -FF
>
> ______________________________________________________________________
> Frank Farance, Farance Inc. T: +1 212 486 4700 F: +1 212 759 1605
> mailto:frank@farance.com http://farance.com
> Standards/Products/Services for Information/Communication Technologies
>
>