ontology-summit
[Top] [All Lists]

Re: [ontology-summit] Reasoners and the life cycle

To: Ontology Summit 2013 discussion <ontology-summit@xxxxxxxxxxxxxxxx>
From: Alan Rector <rector@xxxxxxxxxxxx>
Date: Fri, 21 Dec 2012 16:28:37 +0000
Message-id: <5879D9BA-FFB2-468C-8965-ACA49B3A4546@xxxxxxxxxxxx>
John    (01)

On 19 Dec 2012, at 15:27, John F Sowa wrote:    (02)

> 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.    (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)

I could not agree more.  Indeed, I use the analogy with patching object code 
from a compiler regularly in talks - see presentations on my web site.  
(Unfortunately, I am enough older than most of the audience that few of them 
have actually tried to maintain a piece of code containing an object-code 
patch, or even been in a group where it happened, or even imagined it possible 
- so the analogy isn't always as effective as I would hope.)    (05)

More seriously, much of the work on SNOMED, which is increasingly mandated by 
law for various functions in the US and elsewhere in the world, has operated 
without adequately dealing with errors at their source ("stated form") when 
they were found in the inferred hierarchies.  This was certainly true 
historically and, I suspect, still is true to some degree, although I have no 
direct access to the process.  Hence the errors found in the papers cited in my 
last email and on my web site (and those were only a few of the more egregious 
issues, ones that were unarguable and easily turned into "paper fodder".)     (06)

We have also found that some people trying to learn to use OWL don't realise 
that they have to trace errors to their source rather than just kluging in an 
extra subclass axiom ( if they are using our tools they can't delete an 
inferred axiom, but not all tools enforce this - and there is nothing so 
foolproof that some one ingenious can't find away around it.)   That errors 
have to fixed at source may be obvious to programmers, but most of the people 
we train are domain experts with little IT background.    (07)

Hence my concern that, if we are discussing the "ontology life cycle", the 
issues of dealing with any transformation, compilation, or inference step be 
included, whether the step uses DL reasoners or something else.  This is 
particularly true because there may be cases where the domain experts do not 
have the technical expertise to trace faults to their source, and so may 
require special software or human assistance.    (08)

Regards    (09)

Alan    (010)


> 
>> 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.
> 
> 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.
> 
>> 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.
> 
> 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).
> 
> 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:
> 
>    http://www.upriss.org.uk/fca/fca.html
> 
> 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
> 
>    http://www.ketlab.org.uk/roget.html
> 
>    http://www.ketlab.org.uk/wordnet.html
> 
>> ... any compilation step in the implementation methodology requires
>> additional steps in the life cycle when modifying or "debugging" the
>> ontology...
> 
> 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.
> 
> 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:
> 
> MVB
>> The implementation is 100% Mercury (a concern for the customer), but
>> necessitates only 45,000 LOC of which 25,000 were automatically generated.
> 
> 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.
> 
> 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.
> 
> Criterion for ontology evaluation:  Any type hierarchy that has
> *not* been automatically generated or tested for consistency
> is presumed to be riddled with errors.
> 
> John
> 
> _________________________________________________________________
> 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/     (011)

-----------------------
Alan Rector
Professor of Medical Informatics
School of Computer Science
University of Manchester
Manchester M13 9PL, UK
TEL +44 (0) 161 275 6149/6188
FAX +44 (0) 161 275 6204
www.cs.man.ac.uk/~rector
www.co-ode.org
http://clahrc-gm.nihr.ac.uk/    (012)






_________________________________________________________________
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/     (013)
<Prev in Thread] Current Thread [Next in Thread>