RE: SUO: Some comments about Cyc
Dear John and Robert,
I'm going to disagree with John here a little - see below.
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: John F. Sowa [mailto:sowa@bestweb.net]
> Sent: 15 September 2001 17:41
> To: Robert E. Kent
> Cc: Leo Obrst; SUO
> Subject: Re: SUO: Some comments about Cyc
>
>
>
> Robert,
>
> I am happy that you are continuing your work, but I'd like to make
> a suggestion: please separate the theoretical foundations of IFF
> from what you are proposing as a standard. The theory should go
> into a series of technical reports that can be read and understood
> on their merits, while the standard should only contain the details
> of how the theory affects the interfaces that are used to encode
> and use any ontology that has the appropriate structures.
MW: A standard is like any other technical document.
- You should identify the target audience and their assumed
knowledge level.
- You should motivate them to read the document (purpose, and
intended use).
- You should give them the information they need to fulfill
the purpose in as accessible way as possible.
MW: A standard may contain:
- Normative material, for example
- Facts
- Conventions
- Methodologies
- Conformance criteria
- Normative references (e.g. KIF)
- Informative Material, e.g.
- Notes
- Examples
- Technical Annexes
- Bibliography
MW: It is of course important to clearly separate and identify
normative and informative material. The normative material
should be able to stand on its own - rather like formal axioms
should be able to stand separate from any natural language
description.
MW: My primary concern with IFF is that its target audience
seems to be people already familiar with category theory. I
would just pont out this is a very small target, and not one
that will make a significant mark in the popularising of the
use of ontologies.
MW: This does not mean that I think that IFF should not use
category theory, but it does mean I think it needs to be
introduced properly to an unfamiliar audience in language
that will be familiar to them.
>
> Some comments:
>
> RK> The IFF is big, and version 1.0 (100+ pages) only encoded part of
> it: (1)
> > the namespace for set-theoretic classes/functions/relations
> in the IFF Core
> > (sub)Ontology, and (2) the IFF Category Theory
> (sub)Ontology, which is a
> > baseline ontology for category theory.
>
> Why is it necessary for you to specify namespaces? That should be
> the function of a formalism such as KIF and CGs that is used to
> encode the ontologies. If IFF requres features of KIF and CGs
> that are not currently being supported, then you should inform
> those groups of your needs (or you should join with those groups
> to ensure that the appropriate features are provided).
MW: I agree. However, I have asked for this more than once, and
been told to go away. So if you need namespaces you have to do
it yourself. Of course without a standard for this in the language,
there is no reason why anyone else would do it the same way ...
>
>
> > The next two versions will be further additions (not
> revisions) to the IFF.
>
> That is frightening. IFF is already too big as it is. Anything that
> is purely theoretical should go into the supporting technical reports.
MW: Not necessarily - See above. The standard(s) should have everything
an implementor needs to do his work, understand what he is doing, and
check he has got it right.
> Anything that depends on the notation should go into the KIF and CG
> standards.
MW: Yes, preferably.
>
> > I am currently working on version 2.0 (100+ pages), which
> encodes large
> > classifications and their infomorphisms, large concept
> lattices and their
> > morphisms, bonds, bonding pairs, etc. Due out next month.
> >
> > After that for version 3.0, I will continue work on a Model
> Theory Ontology
> > for Information Flow. Due out later this fall.
>
> While you're doing that, please consider how much you can remove
> from the standzrd and put into separate technical reports.
>
> > Currently, I am doing this on my own, without funding.
>
> That was my impression, but anything of this magnitude should be
> developed by more than one person (at least one principal plus
> a couple of graduate student assistants). And it should be
> funded as something more than a hobby.
>
> John
>