RE: SUO: RE: RE: FW: Comment #11 - 'SUO Evolution' -- Resolution
Dear Frank,
Thank you. I am very well aware of the standards alternatives and their
timescales. I have been operating within them for the last 7 years
developing industry standard data models, and trying to get them improved.
It is preceisely this expereince which is leading us in ISOTC184/SC4 away
from traditional standards towards registers.
See comments below.
Regards
Matthew
============================================
Matthew West
Asset Information Management
Shell Services International
H3229, Shell Centre, London, SE1 7NA, UK.
Tel: +44 207 934 4490 Fax: 7929
E-mail: Matthew.R.West@is.shell.com
http://www.shellservices.com/
============================================
> -----Original Message-----
> From: Frank Farance [mailto:frank@farance.com]
> Sent: 16 September 2000 18:21
> To: West, Matthew MR SSI-GREA-UK; Schoening, James R CECOM DCSC4I;
> Standard-Upper-Ontology (E-mail)
> Cc: 'Thompson, John A'
> Subject: Re: SUO: RE: RE: FW: Comment #11 - 'SUO Evolution' --
> Resolution
>
>
> At 11:55 2000-09-16 +0200, West, Matthew MR SSI-GREA-UK wrote:
> >
> > Dear Jim,
> >
> > The point is that our work does need to address how the SUO
> is updated and
> > changed, as Bill was suggesting, and so something about
> this should be in
> > the scope and purpose, because it is not sufficient just to
> leave this to
> > the existing standardisation process as you were suggesting.
>
> Matthew-
>
> The standards process should be enough to get the updates out
> in a timely basis. There are several options:
>
> - Technical Corrigenda: Effectively, these are "bug
> fixes" to the standard, they are very tiny in scope, and can
> be issued as frequent as the committee desires.
MW: I agree this is quite adequate for bug fixes, but that is not what I was
concerned with.
>
> - Amendments: These are "small changes" to the
> standard (i.e., not wholesale revision). Typically, these
> amendments also include the Technical Corridenda that has
> been approved previously. Like Technical Corregenda, they
> can be issued as frequent as the committee desires, but I
> don't see the committee issuing more than two amendments a year.
MW: But I am anticipating major extensions during each quarter over a number
of years. Say about 100 terms per quarter. More than should be acceptable
for an amendment.
Of course you can issue a series of parts, but then each part takes about 5
years.
>
> - Revisions: Signigicant changes may be incorporated
> into the review cycle.
>
> Many people misinterpret the "5-year review cycle": 5 years
> the the *maximum* time in which a standards may be revised,
> reaffirmed, or withdrawn. The committee may revise a
> standard sooner than 5 years.
MW: Yes I know this. 5 years is what I have seen in practice as the average
time to create a standard in this area from New Work Item. I know it can be
done much quicker theoretically, but that assumes you are standardising
something that is well established in the first place, or is in some sense
arbitrary. This is not the situation we have here.
>
> So assuming:
>
> - Our standard is numbered, say, IEEE 2345
> - We amend the standard three times a year
> - We revise the standard every four years
> - The first standard is issued in the year 2001
> (unrealistic, but useful for illustration purposes)
>
> our standards and ammendments would be labeled:
>
> IEEE 2345:2001 <- First Edition
> IEEE 2345A:2001
> IEEE 2345B:2001
> IEEE 2345C:2002
> IEEE 2345D:2002
> IEEE 2345E:2002
> IEEE 2345F:2003
> IEEE 2345G:2003
> IEEE 2345H:2003
> IEEE 2345J:2004
> IEEE 2345K:2004
> IEEE 2345L:2004
> IEEE 2345:2005 <- Second Edition
>
> There are some significant benefits for using this process:
>
> - Implementors of SUO-conforming products and
> services can clearly identify what they conform to, e.g.,
> "IEEE 2345F:2003" means that the implementation conforms to
> all the amendments up to "F".
> - Consumers can clearly state their needs (from a
> procurement perspective), e.g., "products shall conform to
> IEEE 2345F:2003".
> - Purchasers of the standard get all the current
> Technical Corrigenda and Amendments by simply asking for "IEEE 2345"
MW: Yes I agree with these advantages, but they are important for what is
going to be implemented as software, not what will be implemented as data. I
expect that the SUO will be a data fill for some different sorts of
applications, rather than be embedded in software.
>
> Registries can operates as the same speed as the Technical
> Corrigenda and Amendment process, but the registry has no way
> of identifying the "configuration management" (version)
> issues, such as "which set of features are included?".
MW: This is not necessarily true. It depends on the standard that governs
the the register and the way it is administered.
>
> You might not think this (the "configuration management"
> issue) matters much, but it will matter:
>
> - If you are a vendor and you lose a contract because
> your system did not conform (if you can't point to all the
> features than it's hard to know whether or not you conform to
> the standard)
MW: Again, it depends what you think people will deliver. I expect
conforming software to be delivered that utilises the SUO. It is then up to
the customer to use the latest version of the SUO (or not).
>
> - If you are a consumer and you didn't get the
> interoperability you expected (you believed you had asked for
> "standards conforming" products, but they don't interoperate
> ... it's hard to expect interoperability when you don't know
> exactly what features have been incorporated into vendors' products)
MW: This will be up to the users. Since the lates version would be available
electronically, and probably on the internet, there will not be much excuse
for using an out of date version. A registration body could even provide a
service to notify of updates.
MW: Bottom line here is that we seem to have some different ideas about what
sort of standard we are developing and how it will be used. Given that, I
think we should have some further discusion on this point so we have a
common understanding of what it is that will be standardised, and what
conformance will mean.
>
> -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 the Global Information
> Infrastructure
>