Alan, (01)
That is exactly the same argument used in the 1950s by programmers who
objected to FORTRAN. To satisfy them, every compiler had the option
of printing out an assembly language version of the object code. (02)
> My main point is that if there is any compilation step... then there
> is an extra step between what users assert and the final ontology,
> and that correspondingly, correcting errors may involves finding
> their origin in the source/asserted form. (03)
In fact, it was not unusual for programmers to "correct" or "improve"
or "add features" to the assembly version to create the executable code.
But they (or their managers) quickly learned that the compilers were
far more trustworthy than the programmers. (04)
> We looked at SNOMED CT, a large (>300Kclasses) medical terminology
> implemented in a subset of EL++ and now mandated for many uses in
> the US and numerous other countries. There are many occasions
> in which it is clear that editors have noted a missing subsumption
> and simply asserted or deleted it, rather than tracing down the
> cause in the original asserted form and correcting it. (05)
With today's technology, it is inexcusable for anybody to generate
a large hierarchy by humans inserting links. If anybody has such a
hierarchy, it is essential to use appropriate tools to check it for
completeness (no missing links) and consistency (no conflicting links). (06)
As an example of appropriate technology, see Formal Concept Analysis
(FCA), which routinely generates complete lattices of tens of thousands
of terms. FCA tools are also widely used to check OWL ontologies for
consistency. See the FCA home page: (07)
http://www.upriss.org.uk/fca/fca.html (08)
For the use of FCA for checking OWL ontologies, type "FCA OWL" to
Google. For examples of little sublattices derived automatically
for any term in Roget's Thesaurus or WordNet, see (09)
http://www.ketlab.org.uk/roget.html (010)
http://www.ketlab.org.uk/wordnet.html (011)
> ... any compilation step in the implementation methodology requires
> additional steps in the life cycle when modifying or "debugging" the
> ontology... (012)
That is prima facie evidence that current ontology development tools
are at the same level of sophistication as the software development
tools of the early 1960s. (013)
For an example of more modern tools, see the note about the SWESE
system by Martin Vanden Bossche. (I copied it in my note of Dec 18
-- additional copies on request.) Just one quotation: (014)
MVB
> The implementation is 100% Mercury (a concern for the customer), but
> necessitates only 45,000 LOC of which 25,000 were automatically generated. (015)
If you have decent tools, automatic generation *eliminates* steps
in the life cycle. It can improve human productivity by a factor
of 2 to 10 and make major improvements in the quality and accuracy. (016)
Even more important: Automatic compilation from notations that
the domain experts know (or can read with minimal effort) enables
the people who really know the subject to verify the ontology. (017)
Criterion for ontology evaluation: Any type hierarchy that has
*not* been automatically generated or tested for consistency
is presumed to be riddled with errors. (018)
John (019)
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2013/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2013
Community Portal: http://ontolog.cim3.net/wiki/ (020)
|