SUO: RE: Modularity (and conformance)
Dear Frank,
Some more conformance issues from below.
> I'm glad that we can all agree that "conformance" is
> something to worry about.
>
> Your questions above are all good ones. Since "conformance"
> concerns the an implementation's satisfaction of the
> requirements of a standard, then a good question to ask is:
> what is the implementation? In my prior E-mail on
> conformance, I said there many "conformance paradigms" might
> be possible, so the nature of "implementation" might actually
> involve several "roles" (e.g., power source and electrical appliance).
>
> Regarding a couple of your questions:
>
> - Could an API fail to conform to an ontology
> standard, for example?
>
> I might have some ideas on APIs, but they don't yet make
> sense in any of the ways we have been talking about SUO, so I
> don't have an answer to your question. Maybe it is a
> question that is unanswerable.
MW: An API fails to conform when it is unable to support an ontology.
However, an API is usually defined relative to a language, so in this
case KIF. A conformant API should be able to support any legal KIF
"statement". So if your ontology was legal KIF then it should be
supported by any KIF API. On the other hand if your ontology was not
legal KIF then your ontology was not conformant to the KIF standard.
>
> - Could a web-based ontology engine be said to
> conform or not to the SUO?
MW: It depends what an ontology engine is and does. Generally I would
expect this to be a language related issue rather than an ontology
issue.
>
> I think is a very good question. We should explore this
> question ... it might help us understand conformance.
>
> - How would one make the determination that it did or did not?
>
> This is also a very good question. If the determination
> (also known as "conformity assessment") can be made quickly
> and (hopefully, mostly) automatically, then conformance to
> SUO will be useful. If it can't be determined quickly, or it
> requires years of manual verification, then conformance to
> SUO may be less useful because everyone will be able to claim
> "SUO conformance" yet these conformance claims
> (Implementation Conformance Statements) will be difficult to
> verify (conformity assessment).
>
> We should explore your last two questions ... the discussion
> is likely to be fruitful.
MW: Well my main conclusion is that conformance to KIF is the
critical issue for these questions - not the SUO. I stated in
another e-mail that the main way in which conformance to SUO is
considered is in use of the SUO identifiers for the concepts
they represent, and not for some other concept. I still think
this is the main thing for the SUO itself.
Matthew West
Principal Consultant
Shell Information Technology International Limited
Shell Centre, London SE1 7NA, United Kingdom
Tel: +44 20 7934 4490 Other Tel: +44 7796 336538
Email: matthew.r.west@is.shell.com
Internet: http://www.shell.com
> -----Original Message-----
> From: Frank Farance [mailto:frank@farance.com]
> Sent: 08 October 2001 21:23
> To: standard-upper-ontology@ieee.org
> Subject: SUO: Modularity (and conformance)
>
>
>
> At 14:33 2001-10-08 -0500, Pat Hayes wrote:
> > ...
> > In any reasonable sense, one can probably date the introduction of
> > modularity in the modern sense to the mid-19th century when the
> > advent of reasonably precise machine tools made it possible to
> > manufacture complex machinery with interchangeable parts (marine
> > tackle - Brunel; guns - Colt; clocks - Jerome).
>
> Pat-
>
> I think you missed my main point: John's claim that modules
> be divided along the lines of the major decisions <-- I
> believe this is false.
>
> > >.....
> > > >[FF] The main reason not to "go modular" is coherency
> and consistency,
> >
> > On the face of it, that seems an incredibly silly remark. On those
> > grounds, all APIs should be scrapped, and all process
> communications
> > should be re-negotiated on an ad-hoc basis, in the interest of
> > coherency and consistency.
>
> You keep taking my remarks out of context. Each time, I've
> said modularity is a methodology, and it doesn't always work
> at the high levels of design.
>
> Regarding API design, I can't see how your conclusions, e.g.,
> all APIs should be scrapped, come from my remarks. In many
> software design, you don't do a bottom-up design. For
> example, you don't start off with "get value" and "put value"
> APIs/methods ... you start off with addressing the high level
> needs of the system. For example, in one design, it might be
> appropriate to add the security parameters to each "get
> value" call, while in another design it might be appropriate
> to have a separate "security params" API/method. Regardless
> of which design you choose, you'll have API/methods in the end.
>
> However, the evidence of components (e.g., APIs/methods) does
> not imply that the *high-level* design was modular. You
> might call these components "modules", but the primary design
> concerns might have been coherency and consistency, e.g., a
> consistent way of "getting values" (regardless of datatype or
> security features). In other words, just because "modules"
> (components) exist does not imply that "modularity" was a
> significant methodology is the design of a system.
>
> Certainly, I don't oppose the use of APIs and good design.
> I'm just pointing out (again) that "modularity" is just one
> methodology in the tool box. Sometimes, one methodology is
> preferable or more useful than another; sometimes, there are
> guidelines that help one choose methodologies.
>
> > ...
> > > >[FF] - We should work on the "conformance clause",
> i.e., how do we
> > >know if an "implementation" (e.g., a system) conforms to SUO? (<--
> > >again, a ballot comment on both SUMO and IFF)
> > >
> > >I agree. And the clear distinction between the framework and the
> > >collection of certified modules would make it easier to state and
> > >test conformance.
> >
> > I also agree. There seems to ba a major disconnect here in
> the entire
> > SUO activity. I have no clear idea what kind of software
> conformance
> > is envisioned. Just focus on the concept classification heirarchy,
> > for example, and leave the axioms out of the picture; what kind of
> > conformance would be expected? That any reasoner use this as its
> > classification heirarchy? Of part of its heirarchy? That it be
> > consistent with the program's heirarchy?(Relative to the
> semantics of
> > what formalism?) What about other kinds of software? Could an API
> > fail to conform to an ontology standard, for example?
> (How?) Could a
> > web-based ontology engine be said to conform or not to the SUO? How
> > would one make the determination that it did or did not?
>
> I'm glad that we can all agree that "conformance" is
> something to worry about.
>
> Your questions above are all good ones. Since "conformance"
> concerns the an implementation's satisfaction of the
> requirements of a standard, then a good question to ask is:
> what is the implementation? In my prior E-mail on
> conformance, I said there many "conformance paradigms" might
> be possible, so the nature of "implementation" might actually
> involve several "roles" (e.g., power source and electrical appliance).
>
> Regarding a couple of your questions:
>
> - Could an API fail to conform to an ontology
> standard, for example?
>
> I might have some ideas on APIs, but they don't yet make
> sense in any of the ways we have been talking about SUO, so I
> don't have an answer to your question. Maybe it is a
> question that is unanswerable.
>
> - Could a web-based ontology engine be said to
> conform or not to the SUO?
>
> I think is a very good question. We should explore this
> question ... it might help us understand conformance.
>
> - How would one make the determination that it did or did not?
>
> This is also a very good question. If the determination
> (also known as "conformity assessment") can be made quickly
> and (hopefully, mostly) automatically, then conformance to
> SUO will be useful. If it can't be determined quickly, or it
> requires years of manual verification, then conformance to
> SUO may be less useful because everyone will be able to claim
> "SUO conformance" yet these conformance claims
> (Implementation Conformance Statements) will be difficult to
> verify (conformity assessment).
>
> We should explore your last two questions ... the discussion
> is likely to be fruitful.
>
> -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
>