Logical and ontological reasoning services?

The SubProS and ProChainS compatibility services for OWL ontologies to check for good and ‘safe’ OWL object property expression [5] may be considered ontological reasoning services by some, but according others, they are/ought to be plain logical reasoning services. I discussed this issue with Alessandro Artale back in 2007 when we came up with the RBox Compatibility service [1]—which, in the end, we called an ontological reasoning service—and it came up again during EKAW’12 and the Ontologies and Conceptual Modelling Workshop (OCM) in Pretoria in November. Moreover, in all three settings, the conversation was generalized to the following questions:

1. Is there a difference between a logical and an ontological reasoning service (be that ‘onto’-logical or ‘extra’-logical)? If so,
   1. Why, and what, then, is an ontological reasoning service?
   2. Are there any that can serve at least as prototypical example of an ontological reasoning service?

There’s still no conclusive answer on either of the questions. So, I present here some data and arguments I had and that I’ve heard so far, and I invite you to have your say on the matter. I will first introduce a few notions, terms, tools, and implicit assumptions informally, then list the three positions and their arguments I am aware of.

Some aspects about standard, non-standard, and ontological reasoning services

Let me first introduce a few ideas informally. Within Description Logics and the Semantic Web, a distinction is made between so-called ‘standard’ and ‘non-standard’ reasoning services. The standard reasoning services—which most of the DL-based reasoners support—are subsumption reasoning, satisfiability, consistency of the knowledge base, instance checking, and instance retrieval (see, e.g., [2,3] for explanations). Non-standard reasoning services include, e.g., glass-box reasoning and computing the least common subsumer, they are typically designed with the aim to facilitate ontology development, and tend to have their own plugin or extension to an existing reasoner. What these standard and non-standard reasoners have in common, is that they all focus on the (subset of first order predicate logic) logical theory only.

Take, on the other hand, OntoClean [4], which assigns meta-properties (such as rigidity and unity) to classes, and then, according to some rules involving those meta-properties, computes the class taxonomy. Those meta-properties are borrowed from Ontology in philosophy and the rules do not use the standard way of computing subsumption (where every instance of the subclass is also an instance of its super class and, thus, practically, the subclass has more or features or has the same features but with more constrained values/ranges). Moreover, OntoClean helps to distinguish between alternative logical formalisations of some piece of knowledge so as to choose the one that is better with respect to the reality we want to represent; e.g., why it is better to have the class Apple that has as quality a color green, versus the option of a class GreenObject that has shape apple-shaped. This being the case, OntoClean may be considered an ontological reasoning service. My SubProS and ProChainS [5] put constraints on OWL object property expressions so as to have safe and good hierarchies of object properties and property chains, based on the same notion of class subsumption, but then applied to role inclusion axioms: the OWL object sub-property (relationship, DL role) must be more constrained than its super-property and the two reasoning services check if that holds. But some of the flawed object property expressions do not cause a logical inconsistency (merely an undesirable deduction), so one might argue that the compatibility services are ontological.

The arguments so far

The descriptions in the previous paragraph contain implicit assumptions about the logical vs ontological reasoning, which I will spell out here. They are a synthesis from mine as well as other people’s voiced opinions about it (the other people being, among others and in alphabetical order, Alessandro Artale, Arina Britz, Giovanni Casini, Enrico Franconi, Aldo Gangemi, Chiara Ghidini, Tommie Meyer, Valentina Presutti, and Michael Uschold). It goes without saying they are my renderings of the arguments, and sometimes I state the things a little more bluntly to make the point.

1. If it is not entailed by the (standard, DL/other logic) reasoning service, then it is something ontological.

Logic is not about the study of the truth, but about the relationship of the truth of one statement and that of another. Effectively, it doesn’t matter what terms you have in the theory’s vocabulary—be this simply A, B, C, etc. or an attempt to represent Apple, Banana, Citrus, etc. conformant to what those entities are in reality—as it uses truth assignments and the usual rules of inference. If you want some reasoning that helps making a distinction between a good and a bad formalisation of what you aim to represent (where both theories are consistent), then that’s not the logician’s business but instead is relegated to the domain of whatever it is that ontologists get excited about. A counter-argument raised to that was that the early logicians were, in fact, concerned with finding a way to formalize reality in the best way; hence, not only syntax and semantics of the logic language, but also the semantics/meaning of the subject domain. A practical counter-example is that both Glimm et al [6] and Welty [7] managed to ‘hack’ OntoClean into OWL and use standard DL reasoners for it to obtain de desired inferences, so, presumably, then even OntoClean cannot be considered an ontological reasoning service after all?

2. Something ‘meta’ like OntoClean can/might be considered really ontological, but SubProS and ProChainS are ‘extra-logical’ and can be embedded like the extra-logical understanding of class subsumption, so they are logical reasoning services (for it is the analogue to class subsumption but then for role inclusion axioms).

This argument has to do with the notion of ‘standard way’ versus ‘alternative approach’ to compute something and the idea of having borrowed something from Ontology recently versus from mathematics and Aristotle somewhat longer ago. (note: the notion of subsumption in computing was still discussed in the 1980s, where the debate got settled in what is now considered the established understanding of class subsumption.) We simply can apply the underlying principles for class-subclass to one for relationships (/object properties/roles). DL/OWL reasoners and the standard view assume that the role box/object property expressions are correct and merely used to compute the class taxonomy only. But why should I assume the role box is fine, even when I know this is not always the case? And why do I have to put up with a classification of some class elsewhere in the taxonomy (or be inconsistent) when the real mistake is in the role box, not the class expression? Differently, some distinction seems to have been drawn between ‘meta’ (second order?), ‘extra’ to indicate the assumptions built into the algorithms/procedures, and ‘other, regular’ like satisfiability checking that we have for all logical theories. Another argument raised was that the ‘meta’ stuff has to do with second order logics, for which there are no good (read: sound and complete) reasoners.

3. Essentially, everything is logical, and services like OntoClean, SubProS, ProChainS can be represented formally with some clearly, precisely, formally, defined inferencing rules, so then there is no ontological reasoning, but there are only logical reasoning services.

This argument made me think of the “logic is everywhere” mug I still have (a goodie from the ICCL 2005 summer school in Dresden). More seriously, though, this argument raises some old philosophical debates whether everything can indeed be formalized, and provided any logic is fine and computation doesn’t matter. Further, it conflates the distinction, if any, between plain logical entailment, the notion of undesirable deductions (e.g., that a CarChassis is-a Perdurant [some kind of a process]), and the modeling choices and preferences (recall the apple with a colour vs. green object that has an apple-shape). But maybe that conflation is fine and there is no real distinction (if so: why?).

In my paper [5] and in the two presentations of it, I had stressed that SubProS and ProChainS were ontological reasoning services, because before that, I had tried but failed to convince logicians of the Type-I position that there’s something useful to those compatibility services and that they ought to be computed (currently, they are mostly not computed by the standard reasoners). Type-II adherents were plentiful at EKAW’12 and some at the OCM workshop. I encountered the most vocal Type-III adherent (mathematician) at the OCM workshop. Then there were the indecisive ones and people who switched and/or became indecisive. At the moment of writing this, I still lean toward Type-II, but I’m open to better arguments.

References

[1] Keet, C.M., Artale, A.: Representing and reasoning over a taxonomy of part-whole relations. Applied Ontology, 2008, 3(1-2), 91–110.

[2] F. Baader, D. Calvanese, D. L. McGuinness, D. Nardi, and P. F. Patel-Schneider (Eds). The Description Logics Handbook. Cambridge University Press, 2009.

[3] Pascal Hitzler, Markus Kroetzsch, Sebastian Rudolph. Foundations of Semantic Web Technologies. Chapman & Hall/CRC, 2009,

[4] Guarino, N. and Welty, C. An Overview of OntoClean. In S. Staab, R. Studer (eds.), Handbook on Ontologies, Springer Verlag 2009, pp. 201-220.

[5] Keet, C.M. Detecting and Revising Flaws in OWL Object Property Expressions. Proc. of EKAW’12. Springer LNAI vol 7603, pp2 52-266.

[6] Birte Glimm, Sebastian Rudolph, and Johanna Volker. Integrated metamodeling and diagnosis in OWL 2. In Peter F. Patel-Schneider, Yue Pan, Pascal Hitzler, Peter Mika, Lei Zhang, Jeff Z. Pan, Ian Horrocks, and Birte Glimm, editors, Proceedings of the 9th International Semantic Web Conference, volume 6496 of LNCS, pages 257-272. Springer, November 2010.

[7] Chris Welty. OntOWLclean: cleaning OWL ontologies with OWL. In B. Bennet and C. Fellbaum, editors, Proceedings of Formal Ontologies in Information Systems (FOIS’06), pages 347-359. IOS Press, 2006.

Moral responsibility in the Computing era (SEP entry)

The Stanford Encyclopedia of Philosophy intermittently has new entries that have to do with computing, like on the philosophy of computer science about which I blogged before, ethics of, among others, Internet research, and now Computing and Moral Responsibility by Merel Noorman [1]. The remainder of this post is about the latter entry that was added on July 18, 2012. Overall, the entry is fine, but I had expected more from it, which may well be due to that the ‘computing and moral responsibility’ topic needs some more work to mature and then maybe will give me the answers I was hoping to find already.

Computing—be this the hardware, firmware, software, or IT themes—interferes with the general notion of moral responsibility, hence, affects every ICT user at least to some extent, and the computer scientists, programmers etc who develop the artifacts may themselves be morally responsible, and perhaps even the produced artifacts, too. This area of philosophical inquiry deals with questions such as “Who is accountable when electronic records are lost or when they contain errors? To what extent and for what period of time are developers of computer technologies accountable for untoward consequences of their products? And as computer technologies become more complex and behave increasingly autonomous can or should humans still be held responsible for the behavior of these technologies?”. To this end, the entry has three main sections, covering moral responsibility, the question whether computers can be more agents, and the notion of (and the need for) rethinking the concept of moral responsibility.

First, it reiterates the general stuff about moral responsibility without the computing dimension, like that it has to do with the actions of humans and its consequences: “generally speaking, a person or group of people is morally responsible when their voluntary actions have morally significant outcomes that would make it appropriate to praise or blame them”, where the SEP entry dwells primarily on the blaming. Philosophers roughly agree that the following three conditions have to be met regarding being morally responsible (copied from the entry):

 1. There should be a causal connection between the person and the outcome of actions. A person is usually only held responsible if she had some control over the outcome of events.

2. The subject has to have knowledge of and be able to consider the possible consequences of her actions. We tend to excuse someone from blame if they could not have known that their actions would lead to a harmful event.

3. The subject has to be able to freely choose to act in certain way. That is, it does not make sense to hold someone responsible for a harmful event if her actions were completely determined by outside forces.

But how are these to be applied? Few case examples of the difficulty to apply it in praxis are given; e.g., the malfunctioning Therac-25 radiation machine (three people died caused by overdoses of radiation, primarily due to issues regarding the software), the Aegis software system that misidentified an Iranian civilian aircraft in 1988 as an attacking military aircraft and the US military decided to shoot it down (contrary to two other systems that had identified it correctly) and having killed all 209 passengers on board, the software to manage remote-controlled drones, and perhaps even the ‘filter bubble’. Who is to blame, if at all? These examples, and others I can easily think of, are vastly different scenarios, but they have not been identified, categorized, and treated as such. But if we do, then perhaps at least some general patters can emerge and even rules regarding moral responsibility in the context of computing. Here’s my initial list of different kinds of cases:

1. The hardware/software was intended for purpose X but is used for purpose Y, with X not being inherently harmful, whereas Y is; e.g., the technology of an internet filter for preventing kids to access adult-material sites is used to make a blacklist of sites that do not support government policy and subsequently the users vote for harmful policies, or, as simpler one: using mobile phones to detonate bombs.
2. The hardware/software is designed for malicious intents; ranging from so-called cyber warfare (e.g., certain computer viruses, denial-of-service attacks) to computing for physical war to developing and using shadow-accounting software for tax evasion.
3. The hardware/software has errors (‘bugs’):
   1. The specification was wrong with respect to the intentionally understated or mis-formulated intentions, and the error is simply a knock-on effect;
   2. The specification was correct, but a part of the subject domain is intentionally wrongly represented (e.g., the decision tree may be correctly implemented given the wrong representation of the subject domain);
   3. The specification was correct, the subject domain represented correctly, but there’s a conceptual error in the algorithm (e.g., the decision tree was built wrongly);
   4. The program code is scruffy and doesn’t do what the algorithm says it is supposed to do;
4. The software is correct, but has the rules implemented as alethic or hard constraints versus deontic or soft constraints (not being allowed to manually override a default rule), effectively replacing human-bureaucrats with software-bureaucrats;
5. Bad interface design to make the software difficult to use, resulting in wrong use and/or overlooking essential features;
6. No or insufficient training of the users how to use the hardware/software;
7. Insufficient maintenance of the IT system that causes the system to malfunction;
8. Overconfidence in the reliability of the hardware/software;
   1. The correctness of the software, pretending that it always gives the right answer when it may not; e.g., assuming that the pattern matching algorithm for fingerprint matching is 100% reliable when it is actually only, say, 85%;
   2. Assuming (extreme) high availability, when no extreme high availability system is in place; e.g., relying solely on electronic health records in a remote area whereas the system may be down right when it is crucial to access it in the hospital information system.
9. Overconfidence in the information provided by or through the software; this is partially alike 8-i, or the first example in item 1, and, e.g., willfully believing that everything published on the Internet is true despite the so-called ‘information warfare’ regarding the spreading of disinformation.

Where the moral responsibility lies can be vastly different depending on the case, and even within the case, it may require further analysis. For instance (and my opinions follow, not what is written in the SEP entry), regarding maintenance: a database for the electronic health records outgrows it prospective size or the new version of the RDBMS actually requires more hardware resources than the server has, with as consequence that querying the database becomes too slow in a critical case (say, to check whether patient A is allergic to medicine B that needs to be administered immediately): perhaps the system designer should have foreseen this, or perhaps management didn’t sign off on a purchase for a new server, but I think that the answer to the question of where the moral responsibility lies can be found. For mission-critical software, formal methods can be used, and if, as engineer, you didn’t and something goes wrong, then you are to blame. One cannot be held responsible for a misunderstanding, but when the domain expert says X of the subject domain and you have some political conviction that you prefer Y and build that into the software and that, then, results in something harmful, then you can be held morally responsible (item 3-ii). On human vs. software bureaucrat (item 4), the blame can be narrowed down when things go wrong: was it the engineer who didn’t bother with the possibility of exceptions, was there a/no technological solution for it at the time of development (and knowingly ignore it), or was it the client who willfully was happy avoiding such pesky individual exceptions to the rule? Or, another example, as the SEP entry questions (an example of item 1): can one hold the mobile phone companies responsible for having designed cell phones that also can be used to detonate bombs? In my opinion: no. Just in case you want to look for guidance, or even answers, in the SEP entry regarding such kind of questions and/or cases: don’t bother, there are none.

More generally, the SEP entry mentions two problems for attributing blame and responsibility: the so-called problem of ‘many hands’ and the problem with physical and temporal distance. The former concerns the issue that there are many people developing the software, training the users, etc., and it is difficult to identify the individual, or even the group of individuals, who ultimately did the thing that caused the harmful effect. It is true that this is a problem, and especially when the computing hardware or software is complex and developed by hundreds or even thousands of people. The latter concerns the problem that the distance can blur the causal connection between action and event, which “can reduce the sense of responsibility”. But, in my opinion, just because someone doesn’t reflect much on her actions and may be willfully narrow-minded to (not) accept that, yes, indeed, those people celebrating a wedding in a tent in far-away Afghanistan are (well, were) humans, too, does not absolve one from the responsibility—neither the hardware developer, nor the software developer, nor the one who pushed the button—as distance does not reduce responsibility. One could argue it is only the one who pushed the button who made the judgment error, but the drone/fighter jet/etc. computer hardware and software are made for harmful purposes in the first place. Its purpose is to do harm to other entities—be this bombing humans or, say, a water purification plant such that the residents have no clean water—and all developers involved very well know this; hence, one is morally responsible from day one that one is involved in its development and/or use.

I’ll skip the entry’s section on computers as agents (AI software, robots), and whether they can be held morally responsible, just responsible, or merely accountable, or none of them, except for the final remark of that section, credited to Bruno Latour (emphasis mine):

[Latour] suggests that in all forms of human action there are three forms of agency at work: 1) the agency of the human performing the action; 2) the agency of the designer who helped shaped the mediating role of the artifacts and 3) the artifact mediating human action. The agency of artifacts is inextricably linked to the agency of its designers and users, but it cannot be reduced to either of them. For him, then, a subject that acts or makes moral decisions is a composite of human and technological components. Moral agency is not merely located in a human being, but in a complex blend of humans and technologies.

Given the issues with assigning moral responsibility with respect to computing, some philosophers ponder about doing away with it, and replace it with a better framework. This is the topic of the third section of the SEP entry, which relies substantially on Gotterbarn’s work on it. He notes that computing is ethically not a neutral practice, and that the “design and use of technological artifacts is a moral activity” (because the choice of one design and implementation over another does have consequences). Moreover, and more interesting, is that, according to the SEP entry, he introduces the notions of negative responsibility and positive responsibility. The former “places the focus on that which exempts one from blame and liability”, whereas the latter “focuses on what ought to be done”, and entails to “strive to minimize foreseeable undesirable events”. Computing professionals, according to Gotterbarn, should adopt the notion of positive responsibility. Later on in the section, there’s a clue that there’s some way to go before achieving that. Accepting accountability is more rudimentary than taking moral responsibility, or at least a first step toward moral responsibility. Nissenbaum (paraphrased in the SEP entry) has identified four barriers to accountability in society (at least back in 1997 when she wrote it): the above-mentioned problem of many hands, the acceptance of ‘bugs’ as an inherent element of large software applications, using the computer as scapegoat, and claiming ownership without accepting liability (read any software license if you doubt the latter). Perhaps that needs to be addressed before going on to the moral responsibility, or one reinforces the other? Dijkstra vents his irritation in one of his writings about software ‘bugs’—the cute euphemism dating back to the ‘50s—and instead proposes to use one of its correct terms: they are errors. Perhaps users should not be lenient with errors, which might compel developers to deliver a better/error-free product, and/or we have to instill in the students more about the positive responsibility and reduce their tolerance for errors. And/or what about re-writing the license agreements a bit, like accepting responsibility provided it is used in one of the prescribed and tested ways? We already had that when I was working for Eurologic more than 10 years ago: the storage enclosure was supposed to work in certain ways and was tested in a variety of configurations, and that we signed off on for our customers. If it was faulty in one of the tested system configurations after all, then that was our problem, and we’d incur the associated costs to fix it. To some extent, that was also with our suppliers. Indeed, for software, that is slightly harder, but one could include in the license something along the line of ‘X works on a clean machine and when common other packages w, y, and z are installed, but we can’t guarantee it when you’ve downloaded weird stuff from the Internet’; not perfect, but it is a step in the right direction. Anyone has better ideas?

Last, the closing sentence is a useful observation, effectively stretching the standard  notion of moral responsibility thanks to computing (emphasis added): “[it] is, thus, not only about how the actions of a person or a group of people affect others in a morally significant way; it is also about how their actions are shaped by technology.”. But, as said, the details are yet to be thought through and worked out in some detail and general guidelines that can be applied.

References

[1] Merel Noorman. (forthcoming in 2012). Computing and Moral Responsibility. Stanford Encyclopedia of Philosophy (Fall 2012 Edition), Zalta, E.N. (ed.).  Stable URL: http://plato.stanford.edu/archives/fall2012/entries/computing-responsibility/.

A new version of ONSET and more technical details are now available

After the first release of the foundational ONtology Selection and Explanation Tool ONSET half a year ago, we—Zubeida Khan and I—continued its development by adding SUMO, conducting a user evaluation, and we wrote a paper about it, which was recently accepted [1] at the 18th International Conference on Knowledge Engineering and Knowledge Management (EKAW’12).

There are theoretical and practical reasons why using a foundational ontology improves the quality and interoperability of the domain ontology, be this by means of reusing DOLCE, BFO, GFO, SUMO, YAMATO, or another one, in part or in whole (see, e.g., [2,3] for some motivations). But as a domain ontology developer, and those who are potentially interested in using a foundational ontology in particular, do ask: which one of them would be best to use for the task at hand? That is not an easy question to answer, and hitherto required from a developer to pore over all the documentation, weighing the pros and cons for the scenario, make an informed decision, know exactly why, and be able to communicate that. This bottleneck has been solved with the ONSET tool. Or, at least: we claim it does, and the user evaluation supports this claim.

In short, ONSET, the foundational ONtology Selection and Explanation Tool helps the domain ontology developer in this task. Upon answering one or more questions and, optionally, adding any scaling to indicate some criteria are more important to you than others, it computes the most suitable foundational ontology for that scenario and explains why this is so, including reporting any conflicting answers (if applicable). The questions themselves are divided into five different categories—Ontology, representation language, software engineering properties, applications, and subject domain—and there are “explain” buttons to clarify terms that may not be immediately clear to the domain ontology developer. (There are a few screenshots at the end of this post.)

Behind the scenes is a detailed comparison of the features of DOLCE, BFO, GFO, and SUMO, and an efficient algorithm. The latter and the main interesting aspects of the former are included in the paper; the complete set of criteria is available in a file on the ONSET webpage. You can play with ONSET using your real or a fictitious ontology development scenario after downloading the jar file. If you don’t have a scenario and can’t come up with one: try one of the scenarios we used for the user evaluation (also online). The user evaluation consisted of 5 scenarios/problems that the 18 participants had to solve, half of them used ONSET and half of them did not. On average, the ‘accuracy’ (computed from selecting the appropriate foundatinal ontology and explaining why) was 3 times higher for those who used ONSET compared to those who did not. The ONSET users also did it slightly faster.

Thus, ONSET greatly facilitates in selecting a foundational ontology. However, I concede that from the Ontology (philosophy) viewpoint, the real research component is, perhaps, only beginning. Among others, what is the real effect of the differences between those foundational ontolgoies for ontology development, if any? Is one category of criteria, or individual criterion, always deemed more important than others? Is there one or more ‘typical’ combination of criteria, and if so, is there a single particular foundational ontology suitable, and if not, where/why are the current ones insufficient? In the case of conflicts, which criteria do they typically involve? ONSET clearly can be a useful aid investigating these questions, but answering them is left to future works. Either way, ONSET contributes to taking a scientific approach to comparing and using a foundational ontology in ontology development, and provides the hard arguments why.

We’d be happy to hear your feedback on ONSET, be this on the tool itself or when you have used it for a domain ontology development project. Also, the tool is very easy to extend thanks to the way it is programmed, so if you have your own pet foundational ontology that is not yet included in the tool, you may like to provide us with the values for the criteria so that we can include it.

Here are a few screenshots: of the start page, questions and an explanation, other questions, and the result (of a fictitious example):

Startpage of ONSET, where you select inclusion of additional questions that don’t make any difference right now, and where you can apply scaling to the five categories.

Section of the questions about ontological commitments and a pop-up screen once the related “Explain” button is clicked.

Another tab with questions. In this case, the user selected “yes” to modularity, upon which the tool expanded the question so that a way of modularisation can be selected.

Section of the results tab, after having clicked “calculate results” (in this case, of a fictitious scenario). Conflicting results, if any, will be shown here as well, and upon scrolling down, relevant literature is shown.

References

[1] Khan, Z., Keet, C.M. ONSET: Automated Foundational Ontology Selection and Explanation. 18th International Conference on Knowledge Engineering and Knowledge Management (EKAW’12). Oct 8-12, Galway, Ireland. Springer, LNAI, 15p. (accepted)

[2] Keet, C.M. The use of foundational ontologies in ontology development: an empirical assessment. 8th Extended Semantic Web Conference (ESWC’11), G. Antoniou et al (Eds.), Heraklion, Crete, Greece, 29 May-2 June, 2011. Springer, Lecture Notes in Computer Science LNCS 6643, 321-335.

[3] Borgo, S., Lesmo, L. The attractiveness of foundational ontologies in industry. In: Proc. of FOMI’08, Amsterdam, The Netherlands, IOS Press (2008), 1-9.

Identification and keys in UML Class Diagrams

ER, its extended version EER, ORM, and it extended version ORM2 have several options for identification with keys/reference schemes. UML Class Diagrams, on the other hand, have internal, system-generated, identifiers, with a little-known and underspecified option for user-defined identifiers inspired by ER’s keys, whose description is buried in the standard on pp290-293 [1]. Although UML’s ease of system-generated identifiers relieves the burden of detailed conceptual analysis by the modeller, it is exactly making implicit subject domain semantics explicit that is crucial in the analysis stage; or: less analysis during the modelling stage stores up more problems down the road in terms of software bugs and interoperability. A uniform, or at least a structured and unambiguous approach, can reduce or even avoid inconsistencies in a conceptual data model, especially concerning taxonomies, achieve interoperability through less resource-consuming information integration, and if the identification mechanisms are the same across conceptual data modeling language, then unification among them comes a step closer. The present lack of harmonisation in handling identification hampers all this.

But which identification mechanism(s) could, or should, be specified more precisely for UML, and how does it rhyme with progress about identity in Ontology? How to incorporate it in UML to foster consistent usage? For instance, should the procedure to find and represent identity, or at least good keys, be a step in the modelling methodology, also be enforced in the CASE tool, or be part of the metamodel and/or in the conceptual modelling language itself?

The distinct implicit assumptions and explicit formalisations of extant identification schemes are elucidated in [2] for ER, EER, ORM, and ORM2. As it appears, not even ER/EER and ORM/ORM2 agree fully on keys and reference schemes, neither from a formal perspective (though the difference is minimal), nor from a methodological or CASE tool perspective. Both, however, do aim at strong or weak identification of entities with so-called natural keys (/semantic identifiers) in particular.

At the other end of the spectrum, Ontology does have something on offer, but the philosophers are only interested in identity of entities. Moreover, it is not just that they don’t agree on the details, but there is a tendency to admit it is nigh on inapplicable (see [3] for a good introduction). Watered-down versions of the notion of identity in philosophy that have been proposed in AI, are to used either only the necessary or only the sufficient conditions, which are at least somewhat applicable, be it as a basis for OntoClean [4], or in Description Logic languages (including OWL 2) with their primitive and defined classes. The details of the definitions, explanations, and pros and cons are presented in a ‘digested’ format in the first part of [2].

This analysis was subsequently used to increase the ontological foundations of UML in the second part of [2] to introduce two language enhancements for UML, being formally defined simple and compound identifiers and the notion of defined class, which also have a corresponding extension of UML’s metamodel. The proposed extensions focus on practical usability in conceptual data modelling, informed by ontology, and are approximations to the qualitative, relative, and synchronic identity, and to the notion of equivalent class (defined concept) in OWL (DL).

For those of you who do not care about the ‘unnecessary philosophizing’ (as one reviewer had put it) and justifications, there is a short (4-page) version [5] with the formal definitions and the UML extensions, which has been accepted at the SAICSIT’11 conference in Cape Town, South Africa. The longer version that provides explanation as to why the proposed extensions are the way they are is available as a SoCS technical report [2].

References

[1] Object Management Group. Ontology definition metamodel v1.0. Technical Report formal/2009-05-01, Object Management Group, 2009.

[2] Keet, C.M. Enhancing identification mechanisms in UML class diagrams with meaningful keys (extended version). Technical Report SoCS11-1, School of Computer Science, University of KwaZulu-Natal, South Africa. August 8, 2011.

[3] H. Noonan. Identity. In E. N. Zalta, editor, The Stanford Encyclopedia of Philosophy. Fall 2008 edition, 2008.

[4] N. Guarino and C. Welty. Identity, unity, and individuality: towards a formal toolkit for ontological analysis. In W. Horn, editor, Proc. of ECAI’00. IOS Press, Amsterdam, 2000.

[5] Keet, C.M. Enhancing Identification Mechanisms in UML Class Diagrams with Meaningful Keys. SAICSIT Annual Research Conference 2011 (SAICSIT’11), Cape Town, October 3-5, 2011. ACM Conference Proceedings (in print).

Essay on the Nonviolent Personality

La personalità nonviolenta—the nonviolent personality—is the title of a booklet I stumbled upon in a bookshop in Trento in spring 2004 whilst being in the city for my internship at the Laboratory for Applied Ontology. The title immediately raises the question: what, then, actually does constitute a nonviolent personality? The author of the booklet, Giuliano Pontara, since recently an emeritus of Philosophy at the University of Stockholm, aims to contribute to answer this question that certainly does not have simple answer.

The booklet itself is out of print (having been published in 1996) and, moreover, written in Italian, which most people in the world cannot understand. However, in my opinion at least, Pontara’s proposed answer certainly deserves a wider audience, contemplation, and further investigation. So I set out to translate it into English and put it online for free. That took a while to accomplish, and the last year was certainly the most interesting one with multiple email exchanges with Giuliano Pontara about the finer details of the semantics of the words and sentences in both the Italian original and the English translation. Now here it is: The Nonviolent Personality [pdf, 1.7MB] (low bandwidth version [pdf, 287KB]).

So what is it about? Here is the new back flap summary of the booklet:

At the beginning of the new century, the culture of peace finds itself facing many and difficult challenges. This booklet surveys some of these challenges and the characteristics that a mature culture of peace should have in order to respond to them. Particularly, it investigates what type of person is more apt to be a carrier of such a mature culture of peace: the nonviolent personality. Finally, it addresses the question regarding the factors that in the educative process tend to impede and favour, respectively, the development of moral subjects equipped with a nonviolent personality.

The original Italian version was written by Giuliano Pontara, emeritus of Philosophy at the University of Stockholm, and published in 1996, but its message is certainly not outdated and perhaps even more important in the current climate. Why this is so, and why it is useful to have a more widely accessible version of the booklet available, is motivated in the introduction by Maria Keet, Senior Lecturer at the University of KwaZulu-Natal.

A slightly longer description

The first chapter of the book, having been written in the mid-nineties, discusses the then-current political situation in the world. Pontara describes the post-Cold War situation, touches upon separatism, nationalism, fundamentalism, exploitation and totalitarian capitalism (among other challenges). This includes the “cow-boy ethics” and the return of the Nazi mentality, the latter not being about Arian supremacy, but the glorification of force (and violence in general) and contempt for ‘the weak’, the might-is-right adagio, and that cow-boy ethics has been elevated to prime principle of conducting international politics. You can analyse and decide yourself if the shoe fits for a particular country’s culture and politics, be it then or now. After this rather gloomy first chapter, the first step toward a positive outlook is described in Chapter 2, which looks at several basic features of a mature culture of peace.

The core of the booklet is Chapter 3, which commences with listing ten characteristics of a nonviolent personality:

• Rejection of violence
• The capability to identify violence
• The capability to have empathy
• Refusal of authority
• Trust in others
• The disposition to communicate
• Mildness
• Courage
• Self-sacrifice
• Patience

These characteristics are discussed in detail in the remainder of the chapter. Read it if you want to know what is meant with these characteristics, and why.

Chapter 4 considers education at school, at home, and through other influences (such as the TV), describing both the problems in the present systems and what can to be done to change it. For example, educating students to develop a critical moral conscience, analyse, and to be able to think for oneself (as opposed to rote-learning in a degree-factory), not taking a dualistic approach but facilitating creative constructive solutions instead, and creating an atmosphere that prevents the numbing of conscience, the weakness of the senses, consumerism, and conformism of the mass-media. Also some suggestions for class activities are suggested, but note that education does not end there: it is a continuous process in life.

The English writing style may not be perfect (the spelling and grammar checkers do not complain though); either way, it tries to strike a balance between the writing style of the original and readability of the English text. And no, the translation was not done with Google translate or a similar feature, but manually and there are some notes on the translation at the end of the new booklet. Other changes or additions compared to the Italian original are the new foreword by Pontara and introduction by me, an index, bibliography in alphabetical order and several Italian translations in the original have been substituted with the original English reference, and there are biographical sketches. I did the editing and typesetting in Latex, so it looks nice and presentable.

Last, but not least:

The Nonviolent Personality by Maria Keet is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

Ontological realism, methodologies, and mud slinging: a few notes on the AO trilogy

In July at the start of the MOWS’10 course on ontology engineering I pointed to more background literature about the debate about ontology as reality representation, its principle references, the new comprehensive assessment on its problems by Gary Merrill [1], and I included the note from the Applied Ontology Journal editors that Barry Smith and Werner Ceusters were writing a comprehensive rebuttal, to which Merrill would response in turn. They’re out now [2,3], and also freely available through the dedicated AO page.

On cursory glance seeing some juicy sentences, Smith and Ceusters’ 50-page reply [2] seemed like a good pastime to read on the gray, rainy, and cold Sunday afternoon last week and to ponder if and how I would incorporate it in an updated version of the ontology engineering course. It, however, contains many harsh statements with the main message that they’re doing a great thing with their so-called “realist methodology” and that Merrill’s critique is irrelevant. Merrill’s 30-page response to that [3], which I finished reading recently, is that Smith and Ceusters’ clarification made matters worse and thereby confirming it is a misdirection.

So, what to make of all that? If I were a VIP in ontology engineering, I would ask the AO editors to write a proper reply to the Smith and Ceusters’ (BS & WC) paper. But I am not; hence, I will mention a few aspects on my blog only (which might me do more harm than good, but I hope not). I will start with a note on realism, then the usage of the term “application ontologies”, and finally claims about BS & WC’s “realist methodology” that is not a methodology.

Notes on realism

On the realism dimension of the debate, I have not much to say. I subscribe to the, what Merrill formulates as the, “Empiricist Doctrine” [1], which states that “the terms of science… are to be taken to refer to the actually existing entities in the real world”, especially when it comes to ontologies for the life sciences and (bio)medicine. If you want an ontology of deities, fairies, or other story characters, that’s fine, too—just do not put them in a bio-ontology. What I had understood from the conversations, presentations, and papers of BS & WC is that if you accept the “Empiricist Doctrine”, then so you must go along with universals (as opposed to concepts). Merrill calls the latter component the “Universalist Doctrine” where “the terms of science… are to be understood as referring directly to universals”, which is one of many metaphysical stances [1]. I do not know if I subscribe to universals and I do not care about that that much. Although I did some philosophy of science and philosophy of nature a while ago and read up on other subjects in philosophy in the past few years, I am not a philosopher by training and do not know about all intricacies of all alternatives around (but maybe I should).

Another reason for my misunderstanding—or: conflating the two doctrines—is also due to the fact that descriptions and definitions in the BS & WC papers are not consistent throughout (elaborated on by Merrill [1,3]). For instance, in [4], ontology is taken as reality representations, but in [2] it is reality representation that is described by science, i.e., as scientists understand it, or in other words: the representation of the theories. Thus, where the things in the ontology are terms that do not have a ‘direct link’ to the actual entities, but they go through the scientists’ mind with their conceptualizations of reality. This is quite a difference from [4]. Make of it what you like.

Last, the ‘funny’ thing is that when you use the Empiricists Doctrine it does not matter if you use BFO, DOLCE, GFO, or whichever foundational ontology for practical ontology development. The current formalisations of BFO, DOLCE or any of the others do not have in their formalisation that the categories [unary predicates] denote either universals or concepts. Clearly, the communication of the informal intentions would be different if the top (OWL:thing or similar) in the ontology is called Universal or Concept, but in BFO it is called Entity and in DOLCE Perdurant. Thus, de facto, neither one commits to one philosophical doctrine or another in the top-level categorization and formalisation.

What are “application ontologies”?

Smith and Ceusters in [4] make a distinction between reference ontologies and application ontologies, the former intended to represent “settled science” and latter that part of science that is in flux. This rather difficult to maintain distinction is discussed at length in [3]. What I wish to add, and which was only mentioned in passing in [3], is that the notion of ‘application ontologies’ elsewhere in the ontologies enterprise is used quite differently. It refers to OWL- or DL-formalised conceptual data models modeled in one of the common conceptual data modelling languages (UML, EER, ORM), but not real ontologies. The discussion about the difference between an ontology and a conceptual data model is beyond the current scope, but it is important to note that the same term means something different in pretty much all other literature about ontologies. Perhaps BS & WC have not read that literature, given that they happily attack computer science, knowledge engineering, and conceptual modelling (section 3.1 in [2]) with ‘justifications’ that Wüster-the-businessman over at ISO is a telling example of knowledge engineering and conceptual modelling (he is not), and that it was the training in cognitive psychology we all got as computer scientists (we did not) that makes us confused and stick to concepts instead of buying into universalist doctrine. Such statements are not helpful.

Either way, application ontology as a formal conceptual data model is definitely a more tenable definition [setting aside if one agrees with it] than application ontology for the non-settled science for the fact that there is no crisp boundary between settled and non-settled science. If the vague distinction is not enough already to complicate the debate: concepts are allowed to appear in BS & WC’s application ontologies.

About “methodologies”

Smith and Ceusters propose their “realist methodology” in section 1 of [2], but a methodology it is not—at least, not in the sense I, and (m)any other people in CS & IT, use the term. What BS & WC put forward is a set of principles. It does not say what to do, how, and when. And there is no empirical validation that the resultant ontologies are better (validation sensu a proper scientific experiment with subjects with/without using the ‘methodology’, measurable quality criteria, statistically significant, etc.).

An example of a fairly straightforward methodology for ontology development is METHONTOLOGY (among others [5]), and a more recent one for collaborative distributed ontology development: the NeON Methodology [6]. The latter has a nice fairly comprehensive overview picture of the interactions of the different steps (see Fig. 1, below) that are described further in [6] (and an aspect of this are the interactions between the different steps [7]). In my lectures, I like to be impartial and include a variety of options to sensitise  ontology developers to the plethora of options (see, e.g., Sections 3 and 4 of the MOWS’10 course, which is an updated version of SemWebTech lecture 3+4, where the what comes before the how, outlined in SemWebTech lecture 5: Methods and Methodologies), but a set of principles that is labeled “methodology” is not something that fits in a real methodology section (though they may well fit in another module).

How can BS & WC even dare to propose a methodology for ontology development when disregarding all literature on ontology development (except for the OntoClean method)? If their methodology is so superior, than give me evidence why and how it is better than all the methodologies that have been proposed over the past 15 years or so. Spoon-feed me about the shortcomings of those procedures; that is, not a lecture about the realist vs anti-realist, conceptualist and what have you, but why I should not buy into collecting non-ontological resources, looking at ontology design patterns, providing intermediate steps for the formalization, and so forth.

Whilst reading section 1 of [2], I have been trying to extract a methodology—that is, reading it with a positive attitude to try to make something of it—but could find little, and what I extracted from it, is not enough for practical ontology development and maintenance. As example, let us take the step of  “non-ontological resource reuse” for the chosen subject domain. In an ontology engineering methodology, this includes options, such as assessing chosen sources such as relevant thesauri, databases, natural language text, and methods for each option, i.e., the how-to to reuse the non-ontological resources, such as the manual database reverse engineering steps vs. semi-automated tools (in, say, VisioModeler, or the Protégé plugin Lubyte  developed [8]), data mining and clustering, the different methods to extract terms from text etc. From [2], e.g. section 1.13, I gather that the only way to execute this step of “non-ontological resource reuse” is that domain experts manually read the scientific literature and manually add the knowledge to the ontology. No help from, say, the KEGG, AGROVOC, ICD10, or ontologies that were already developed by other groups—all that should be ignored—let alone automating anything to find, say, candidate terms automatically with NLP tools. That surely must be a joke (or oversight, or sheer ignorance) and does not reflect what happens during the development of OBO ontologies. Or take, e.g., METHONTOLOGY or MoKi’s stage of intermediate representations between de domain expert’s informal representation and the formalisation of it in a suitable logic language, such as pseudo-natural language, diagrams as syntactic sugar for the underlying logic, the Protégé and OBOEdit ODEs: are they to be ignored, too? Of course not; well, I presume that that is not the intention of BS & WC’s “methodology”.

They may have enjoyed having written a trashing of 20 years of knowledge engineering and conceptual data modelling whose outputs apparently can be ignored, but there surely is room to learn a thing or two about it. After reading up on the related works on methodologies, they can make a real attempt at developing a methodology that satisfies the set of principles, be that by developing a methodology from scratch or integrating it into (or extending) existing methodologies. Until then, what is presented in section 1 of [2] will not—cannot—be added to a ‘methods and methodologies’ module in an ontology engineering course.

P.S.: Other views

A different online debate about realism in ontology engineering can be read over at Phil Lord’s blog (The Status quo farewell tour on realism, Why not?, and Why realism is wrong) and his paper together with Robert Stevens at PLoS ONE [9], versus David Sutherland’s Realism, Really? and Yes, really in favour of the realist approach for practical ontology development. Then there is the OBO-Foundry discussion list, and, e.g., a paper in FOIS’10 by Michel Dumontier and Robert Hoehndorf [10], and undoubtedly more papers about the issues raised in the AO trilogy will follow.

References

[1] Gary H. Merrill. Ontological realism: Methodology or misdirection? Applied Ontology, 5 (2010) 79–108.

[2] Barry Smith and Werner Ceusters. Ontological realism: A methodology for coordinated evolution of scientific ontologies. Applied Ontology, 5 (2010) 79–108.

[3] Gary H. Merrill. Realism and reference ontologies: Considerations, reflections and problems. Applied Ontology, 5 (2010) 79–108.

[4] Barry Smith. Beyond Concepts, or: Ontology as Reality Representation. Achille Varzi and Laure Vieu (eds.), Formal Ontology and Information Systems. Proceedings of the Third International Conference (FOIS 2004), Amsterdam: IOS Press, 2004, 73-84.

[5] Corcho, O., Fernandez-Lopez, M. and Gomez-Perez, A. (2003). Methodologies, tools and languages for building ontologies. Where is their meeting point?. Data & Knowledge Engineering 46(1): 41-64.

[6] Mari Carmen Suarez-Figueroa, Guadalupe Aguado de Cea, Carlos Buil, Klaas Dellschaft, Mariano Fernandez-Lopez, Andres Garcia, Asuncion Gomez-Perez, German Herrero, Elena Montiel-Ponsoda, Marta Sabou, Boris Villazon-Terrazas, and Zheng Yufei. NeOn Methodology for Building Contextualized Ontology Networks. NeOn Deliverable D5.4.1. 2008.

[7] Keet, C.M. Dependencies between Ontology Design Parameters. International Journal of Metadata, Semantics and Ontologies, 2010, 5(4): 265-284.

[8] Lina Lubyte. Techniques and Tools for the Design of Ontologies for Data Access. PhD Thesis, Free University of Bozen-Bolzano, KRDB Dissertation Series DS-2010-02, 2010.

[9] Lord, P. & Stevens, R. Adding a little reality to building ontologies for biology. PLoS One, 2010, 5(9), e12258. DOI: 10.1371/journal.pone.0012258.

[10] Dumontier, M. & Hoehndorf, R. Realism for scientific ontologies. In: Proceeding of the Conference on Formal Ontology in Information Systems: Proceedings of the Sixth International Conference (FOIS 2010), 387–399. Amsterdam: IOS Press.

Fig 1. Graphical depiction of different steps in ontology development, where each step has its methods and interactions with other steps (taken from 6).

A strike against the ‘realism-based approach’ to ontology development

The ontology engineering course starting this Monday at the Knowledge Representation and Reasoning group at Meraka commences with the question What is an ontology? In addition to assessing definitions, it touches upon long-standing disagreements concerning if ontologies are about representing reality, our conceptualization of entities in reality, or some conceptualization that does not necessarily ascribe to existence of reality. The “representation of reality school” is advocated in ontology engineering most prominently by Barry Smith and cs. and their foundational ontology BFO, the “conceptualization of entities in reality school” by various people and research groups, such as the LOA headed by Nicola Guarino and their DOLCE foundational ontology, whereas the “conceptualization irrespective regardless reality school” can be (but not necessarily is) encountered in organisations developing, e.g., medical ontologies that do not ascribe to evidence-based medicine to decide what goes in the ontology and how (but instead base it on, say, the outcome of power plays between big pharma and health insurance companies).

Due to the limited time and scope of this and previous courses on ontology engineering I taught, I mention[ed] only succinctly that those differences exist (e.g., pp10-11 of the UH slides), and briefly illustrate some of the aspects of the debate and their possible consequences in practical aspects of ontology engineering. This information is largely based on a few papers and extracting consequences from that, the examples they describe and that I encountered, and the discussions that took place at the various meetings, workshops, conferences, and summer schools that I participated in. But there was no nice, accessible, paper that describes de debate—or even part of it—more precisely and is readable also by ontologists who are not philosophers. Until last week, that is. The Applied Ontology journal published a paper by Gary Merrill, entitled Ontological realism: Methodology or misdirection? [1], that assess critically the ontological realism advocated by Barry Smith and his colleague Werner Ceusters. Considering its relevance in ontology engineering, the article has been made freely available, and in the announcement of the journal issue, its editors in chief (Nicola Guarino and Mark Musen) mentioned that Smith and Ceusters are busy preparing a response on Merrill’s paper, which will be published in a subsequent issue of Applied Ontology. Merrill, in turn, promised to respond to this rebuttal.

But for now, there are 30 pages of assessment on the merits of, and problems with, the philosophical underpinnings of the “realism-based approach” that is used in particular in the realm of ontology engineering within the OBO Foundry project and its large set of ontologies, BFO, and the Relation Ontology. The abstract gives an idea of the answer to the question in the paper’s title:

… The conclusion reached is that while Smith’s and Ceusters’ criticisms of prior practice in the treatment of ontologies and terminologies in medical informatics are often both perceptive and well founded, and while at least some of their own proposals demonstrate obvious merit and promise, none of this either follows from or requires the brand of realism that they propose.

The paper’s contents backs this up with analysis, arguments, examples, and bolder statements than the abstracts suggests.
For anyone involved in ontology development and interested in the debate—even if you think you’re tired of it—I recommend reading the paper, and to at least follow how the debate will unfold with responses and rebuttals.

My opinion? Well, I have one, of course, but this post is an addendum to the general course page of MOWS’10, hence I try to refrain from adding too much bias to the course material.

UPDATE (27-7-2010): On whales and apples, and on ontology and reality: you might enjoy also “Moby Dick: an exercise in ontology”, written by Lorne A. Smith.

References

[1] Gary H. Merrill. Ontological realism: Methodology or misdirection? Applied Ontology, 5 (2010) 79–108.

72010 SemWebTech lectures 3+4: Ontology Engineering Top-down and Bottom-up

Ontology languages were introduced in the previous two lectures, but one can ask oneself what then an ontology is (and if, perhaps, the two topics should have been done in reverse order). There is no unanimously agreed-upon definition what an ontology is and proposed definitions within computer science have changed over the past 20 years (see e.g., [1] and here). For better or worse, currently, the tendency is toward it being equivalent to a logical theory—even formalizing a thesaurus in OWL then ends up as a simple ‘ontology’ (e.g., the NCI thesaurus as cancer ontology) and a conceptual data model originally in EER or UML becomes an ‘application ontology’ by virtue of being formalized in OWL. Salient aspects of the merits of one definition and other will pass the revue at the beginning of the lecture on the 23^rd of November. For an initial indication of ‘things that have to do with an ontology’, I include the Ontology Summit’s “Dimension map” that is by its authors intended as a “Template for discourse” about ontologies, which has a brief and longer explanation.

The “Dimension map” of ontologies, made by the attendees of the Ontology Summit 2007 (intended as a “Template for discourse”)

The main focus of lectures 3 and 4, however, will be devoted to ontology development: having a language is one thing and in the lab of 24-11 you will practice with software-supported ontology development environments, but what to represent, and how, is quite another. Where do you start? How can you avoid reinventing the wheel? What things can guide you to make the process easier to carry out successfully? How can you make the best of ‘legacy’ material? There are two principal approaches, being the so-called top-down and bottom-up ontology development, which will be the topic of the lectures on 23 and 24 November.

Top-down ontology development

The basic starting point for top-down ontology development is to think of, and decide about, core principles. For instance, do you commit to a 3D view with objects persisting in time or a perdurantist one with space-time worms, are you concerned with (in OWL terminology) classes or individuals, is your ontology intended to be descriptive or prescriptive (see, e.g. [2,3])? Practically, the different answers to such questions end up as different foundational ontologies—even with the same answers they may be different. Foundational ontologies provide a high-level categorization about the kinds of things you will model, such as process, non-agentive-physical-object, and (what are and) how to represent ‘attributes’ (e.g., as qualities or some kind of dependent continuant or trope.).

There are several such foundational ontologies, such as DOLCE, BFO, GFO, natural language focused GUM, and SUMO. Within the Wonderweb project, the participants realized it might not be feasible to have one singe foundational ontology that pleases everybody; hence, the idea was to have a library of foundational ontologies with appropriate mappings between them so that each modeller can chose his or her pet ontology and the system will sort out the rest regarding the interoperability of ontologies that use different foundational ontologies. The basis for this has been laid with the Wonderweb deliverable D18 [3], but an implementation is yet to be done. One of the hurdles to realize this, is that people who tend to be interested in foundational ontologies start out formalizing the basic categories in a logic of their convenience (which is not OWL). For instance, DOLCE—the Descriptive Ontology for Linguistic and Cognitive Engineering—has a paper-based formalisation in a first order predicate logic, and subsequent trimming down in lite and ultralite OWL versions. BFO—the Basic Formal Ontology—too, as well as a version of it in Isabelle syntax, but this version focuses on the mereological basis only.

In the meantime, leaner OWL versions of DOLCE and BFO have been made available, which are intended to be used for development of ontologies in one’s domain of interest. These files can be found on their respective websites at the LOA and IFOMIS. To read them leisurely and make a comparison—and finding any correspondence—of the two foundational ontologies somewhat easier, I have exported the DOLCE-lite and BFO 1.1 OWL versions in a Description Logics representation and Manchester syntax rendering (generated with the Protégé ontology development tool). Whereas DOLCE-Lite is encoded in SHI, BFO is simpler (in ALC); that is, neither one uses all OWL-DL capabilities of SHOIN(D). Another difference is that BFO-in-owl is only a bare taxonomy (extensions do exist though), whereas DOLCE-Lite makes heavy use of object properties. More aspects of both foundational ontologies will be addressed in the lecture.

A different approach to the reuse of principal notions, is to use ontology design patterns (ODPs), which is inspired by the idea of software design patterns. Basically, ODPs provide mini-ontologies with formalised knowledge for how to go about modelling reusable pieces, e.g. an n­-ary relation or a relation between data type values, in an ontology (in OWL-DL), so that one can do that consistently throughout the ontology development and across ontologies. ODPs for specific subject domains are called content ODPs, such as the ‘sales and purchase order contracts’ or the ‘agent role’ to represent agents, the roles they play, and the relations between them, and even an attempt to consistently represent the classification scheme invented by Linnaeus with an ODP.

There are several different types of ODPs, which are summarized in the following figure (click to enlarge).

Taxonomy of ODPs

During the lecture, the main aspects of DOLCE, BFO, and the ODPs will be elaborated on.

Bottom-up ontology development

Bottom-up ontology development starts from the other end of the spectrum, where it may be that the process is at least informed by foundational ontologies. Principally, one can distinguish between (i) transforming information or knowledge represented in one logic into an OWL species, (ii) transforming somewhat structured information into an OWL species, (iii) starting at the base. Practically, this means starting from some ‘legacy’ (i.e., not-SemWeb) material, such as, but not limited to:

• Databases
• Conceptual models (ER, UML)
• Frame-based systems
• OBO format
• Thesauri
• Biological models
• Excel sheets
• Tagging, folksonomies
• Output of text mining, machine learning, clustering

The following figure gives an idea as to how far one has to ‘travel’ from the legacy representation to a ‘SemWeb compliant’ one (and, correspondingly, put more effort in to realize it).

Less and more structured things, with corresponding lower to higher ontological precision of the subject domain represented with the language

Given the limited time available, we shall not discuss all variants. Instead, we shall focus first on taking databases as source material. Some rather informal points about reverse engineering from databases to ontologies will be structured briefly, to subsequently take a formal turn with [5]. Imperfect transformations from other languages, such as the common OBO format [6] and a pure frames-based approach [7], are available as well, which also describe the challenges to create them. While the latter two do serve a user base, their overall impact on widespread bottom-up development is very likely to be less than the potential that might possibly be unlocked with leveraging knowledge of existing (relational) databases. One may be led to assume this holds, too, for text processing (NLP) as starting point for semi-automated ontology development, but the results have not been very encouraging yet (it will be discussed in lecture 10).

Two examples that, by basic idea at least, can have a large impact on domain ontology development will be described during the lecture: taking biological models (or any other structured graphical representation) as basis [8]—which amounts to formalizing the graphical vocabulary in textbooks and drawing tools—and the rather more cumbersome one of sorting out thesauri [9,10], which faces problems such as what to do with its basic notions (e.g., “RT: related term”) in a more expressive OWL ontology. Both examples have abundant similar instances in science, medicine, industry, and government, and, undoubtedly, some more automation to realize it would be a welcome addition to ease the efforts to realize the Semantic Web.

References

[1] Guarino, N. Formal Ontology in Information Systems. Proceedings of FOIS’98, Trento, Italy, June 6-8, 1998. IOS Press, Amsterdam, pp. 3-15.

[2] Barry Smith. Beyond Concepts, or: Ontology as Reality Representation. Achille Varzi and Laure Vieu (eds.), Formal Ontology and Information Systems. Proceedings of the Third International Conference (FOIS 2004), Amsterdam: IOS Press, 2004, 73-84.

[3] Masolo, C., Borgo, S., Gangemi, A., Guarino, N., Oltramari, A. WonderWeb Deliverable D18–Ontology library. WonderWeb. 2003.

[4] Presutti, V., Gangemi, A., David, S., de Cea, G. A., Surez-Figueroa, M. C., Montiel-Ponsoda, E., Poveda, M. A library of ontology design patterns: reusable solutions for collaborative design of networked ontologies. NeOn deliverable D2.5.1, Institute of Cognitive Sciences and Technologies (CNR). 2008.

[5] L. Lubyte, S. Tessaris. Automatic Extraction of Ontologies Wrapping Relational Data Sources. In Proc. of the 20th International Conference on Database and Expert Systems Applications (DEXA 2009). To appear.

[6] Christine Golbreich and Ian Horrocks. The OBO to OWL mapping, GO to OWL 1.1! In Proc. of the Third OWL Experiences and Directions Workshop, number 258 in CEUR (http://ceur-ws.org/), 2007. See also with wiki page on oboInOwl

[7] Zhang S, Bodenreider O, Golbreich C. Experience in reasoning with the Foundational Model of Anatomy in OWL-DL. In: Pacific Symposium on Biocomputing 2006, Altman RB, Dunker AK, Hunter L, Murray TA, Klein TE, (Eds.). World Scientific, 2006, 200-211.

[8] Keet, C.M. Factors affecting ontology development in ecology. Data Integration in the Life Sciences 2005 (DILS’05), Ludaescher, B, Raschid, L. (eds.). San Diego, USA, 20-22 July 2005. Lecture Notes in Bioinformatics LNBI 3615, Springer Verlag, 2005. pp46-62.

[9] Dagobert Soergel, Boris Lauser, Anita Liang, Frehiwot Fisseha, Johannes Keizer and Stephen Katz. Reengineering thesauri for new applications: the AGROVOC example. Journal of Digital Information 4(4) (2004)

[10] Maria Angela Biasiotti, Meritxell Fernández-Barrera. Enriching Thesauri with Ontological Information: Eurovoc Thesaurus and DALOS Domain Ontology of Consumer law. Proceedings of the Third Workshop on Legal Ontologies and Artificial Intelligence Techniques (LOAIT 2009). Barcelona, Spain, June 8, 2009.

Note: references 1, 2, 5, 8 are mandatory reading, 3 and 4 are strongly recommended to read at least in part, and 6, 7, 9, and 10 are optional.

Lecture notes: lecture 3 – Top-down and lecture 4 – Bottom-up

Course webpage

Transformations, again

A while ago I wrote about refining RO’s transformation_of relation with additional constraints to improve the representation of the intended meaning of the relation and what kind of entities the relata should be. In the meantime, a flurry of emails about the topic passed the revue on the BFO-discuss and OBO-relations lists (without a tangible concrete outcome), and this week my paper about it was accepted for oral presentation at the AI*IA’09 conference in December and will be published in an LNAI volume. Weehee.

By ‘completing’ one piece of work, one always finds more open issues to tackle, which holds also for this topic regarding about, and beyond, the transformation_of (or similar) relation. More on both the ontology and logic is, and soon will be, in the pipeline.

Computing and the philosophy of technology

Recently I wrote about the philosophy of computer science (PCS), where some people, online and offline, commented that one cannot have computer science but have the science of computing instead and that it must have as part experimental validation of the theory. Regarding the latter, related and often-raised remarks are that it is computer engineering instead, which, in turn, it closely tied to information technology. In addition, many a BSc programme trains students so as to equip them with the skills to obtain a job in IT. Coincidentally, there is a new entry in the Stanford Encyclopedia of Philosophy on the Philosophy of Technology (PT) [1], which, going by the title, may well be more encompassing than just PCS and perhaps just as applicable. In my opinion, not quite. There as several relevant aspects of the PT for computing, but if one takes the strand of engineering and IT of computing, then there are some gaps in the overview presented by Franssen, Lokhorst and Van de Poel. The the main gap I will address is that it misses the centrality of ‘problem’ in engineering and that it conflates it with notions such as requirements and design.

But to comment on it, let me first start with mentioning few salient points of their sections “historical developments” and “analytic philosophy of technology” to illustrate notions of technology and which strand of PT the SEP entry is about (I will leave the third part, “ethical and social aspects of technology”, for another time).

A few notes on its historical developments
Plato put forward the thesis that “technology learns from or imitates nature”, whereas Aristotle went a step further: “generally, art in some cases completes what nature cannot bring to a finish, and in others imitates nature”. A different theme concerning technology is that “there is a fundamental ontological distinction between natural things and artifacts” (not everybody agrees with that thesis), and if so, what, then, those distinctions are. Aristotle, again, also has a doctrine of the four causes with respect to technology: material, formal, efficient, and final.
As is well-know, there was a lull in the intellectual and technological progress in Europe during the Dark Ages, but the Renaissance and the industrial revolution made thinking about technology all the more interesting again, with notable contributions by Francis Bacon, Karl Marx, and Samuel Butler, among others. Curiously, “During the last quarter of the nineteenth century and most of the twentieth century a critical attitude [toward technology] predominated in philosophy. The representatives were, overwhelmingly, schooled in the humanities or the social sciences and had virtually no first-hand knowledge of engineering practice” (emphasis added). This type of PT is referred to as humanities PT, which looks into socio-politico-cultural aspects of technology. Not everyone was, or is, happy with that approach. Since the 1960s, an alternative approach has been gestating and is becoming more important, which can be dubbed the analytic PT that is concerned with technology itself, where technology is considered the practice of engineering. The SEP entry about PT is about this type of PT.

Main topics in Analytic PT
The topics that the authors of the PT overview deem the main ones have to do with the discussion on the relation between science and technology (and thus also on the relation of philosophy of science and of technology), the importance of design for technology, design as decision-making, and the status and characteristics of artifacts. Noteworthy is that their section 2.6 on other topics mentions that “there is at least one additional technology-related topic that ought to be mentioned… namely, Artificial Intelligence and related areas” (emphasis added) and the reader is referred to several other SEP entries. Notwithstanding the latter, I will comment on the content from a CS perspective anyway.

Sections 2.1 and 2.2 contain a useful discourse on the differences between science and engineering and on their respective philosophy-of. It was Ellul in 1964 who observed in technology “the emergent single dominant way of answering all questions concerning human action, comparable to science as the single dominant way of answering all questions concerning human knowledge” (emphasis added). Skolimowski phrased it as “science concerns itself with what is, whereas technology with what is to be.” Simon used the verb tenses are and ought to be, respectively. To hit the message home, they also say that science aims to understand the world but that technology aims to change the world, and is seen as a service to the public. (I leave it to the reader to assess what, then, the great service to the public is of artifacts such as the nuclear bomb, flight simulator games for kids, CCTV, and the likes.) In contrast, while Bunge did acknowledge technology was about action, he stressed that it is one heavily underpinned by theory, thereby distinguishing it from the arts and crafts. Practically regarding software engineering, then to say that development of ontologies or the conceptual modelling during the conceptual analysis stage of software development are, largely or wholly, an art, is to say that there is no underlying theoretical foundation for those activities. This is not true. Indeed, there are people who, without being aware of its theoretical foundations, go off and develop an ontology or ontology-like artifact nevertheless and call that activity an art, but that does not make the activity an art per sé.
Closing the brief summary of the first part of the PT entry, Bunge mentioned also that theories in technology come into two types: substantive (on knowledge about the objects of action) and operative (on the action itself). A further distinction has been put forward by Jarvie, which concerns the difference between knowing that and knowing how, the latter which Polanyi made a central aspect of technology.

Designs, requirements, and the lack of problems
The principal points of criticism I have are on the content of sections 2.3 and 2.4, which revolve around the messiness in the descriptions of design, goals, requirements. Franssen et al first state that “technology is a practice focused on the creation of artifacts and, of increasing importance, artifact-based services. The design process, the structured process leading toward that goal, forms the core of the practice of technology” and that the first step in that process is to translate the needs or wishes of the customer into a list of functional requirements. But ought the first step not to be the identification of the problem? For if we then ultimately solve the problem (giong through writing down the requirements, design the artifact, and build and tests it), it is a ‘service to the public’. Moreover, if we have identified the problem, formulated it in a problem description, written a specification of the goal to achieve, only then we can write down the list of requirements that are relevant to achieving the goal and that solves the problem, which will not only avoid a ‘solution’ exhibiting the same problem but also meet the goal and be this service to the public. But problem identification and problem solving is not a central issue to technology, according to the PT entry; just designing artifacts based on functional requirements.
Looking back at the science and engineering studies I enjoyed, the former had put an emphasis on formulating and testing the hypotheses—no thesis could do without that—whereas the latter focusses on which problem(s) your research tackles and solves, where theses and research papers have to have a (list of) problem(s) to solve. If a CS paper does not have a description of the problem, one might want to look again what they are really doing, if anything; if it is a mere ‘we did develop a cute software tool’, it is straightforward to criticise and easily can be rejected because it is insufficient regarding the problem specification and the system requirements (the reader may not share the unwritten background setting with the authors, hence think of other problems and requirements that he would expect the tool to solve), and the ‘solution’ to that (the tool) is then no contribution to science/engineering, at least not in the way it is presented. Not even mentioning the problem-identification-and-solving and its distinction with science in the approach of doing research is quite a shortcoming of the PT entry.

In addition, the authors confuse such different topics even more clearly by stating that “The functional requirements that define most design problems” (emphasis added). Design problems? So there are different types of problem, and if so, which? How can requirements define a problem? They don’t. The requirements entail what the artifact is supposed to do and what constraints it has to meet. However, if it defines the problem instead, as the authors say, then they are not parameters for the solution to that problem, even though the to-be-designed artifact that meets the requirements is supposed to solve a (perceived) problem. Further, they say that engineers claim that their designs are optimal solutions, but can one really say that a design is the solution, rather than the outcome of the design, i.e., the realisation of the working artifact?

If it is the case, as the authors summarise, that technology aims to change the world, then one needs to know what one is changing, why one is changing that, and how. If something is already ‘perfect’, then there is no need to change it. So, provided it is not ‘perfect’ according to at least one person, then there is something to change to make it (closer to) ‘perfect’; hence, there is a problem with that thing (regardless if this thing is an existing artifact or annoying practice that perhaps could be solved by using technology). Thus, one—well, at least, I—would have expected that ‘problem’ would be a point of inquiry, e.g.: what is it, what does it depend upon, if there is a difference between problem and nuisance, how it relates to requirements and design and human action, the processes of problem identification and problem specification, the drive for problem-solving in engineering and the brownie points one scores with it upon having a solution, and even the not unheard of, but lamentable, practice of ‘reverse engineering the problem’ (i.e.: the ‘we have a new tool, now we think of what it [may/can/does] solve and that can be written in such a way as if it [is/sounds like] a real problem’).

In closing, the original PT entry was published in February this year, and quickly has undergone “substantive revision” meriting a revised release on 22 June ’09, so maybe the area is active and in flux so that a next version could include some considerations about problems.

References
[1] Franssen, Maarten, Lokhorst, Gert-Jan, van de Poel, Ibo, “Philosophy of Technology”, The Stanford Encyclopedia of Philosophy  (Fall 2009 Edition), Edward N. Zalta (ed.), forthcoming URL =http://plato.stanford.edu/archives/fall2009/entries/technology/