Re: [ontology-summit] Clarification re Big Data Challenges Synthesis

[Amanda Vizedom <amanda.vizedom@xxxxxxxxx>]

On Tue, Apr 3, 2012 at 11:02, Obrst, Leo J. <lobrst@xxxxxxxxx> wrote:

In addition, the expressiveness of the language that the ontology is modeled (represented) in is important (my (1)), and it is driven by the ontology requirements. If you need FOL or HOL expressiveness because of your domain requirements, and then you model in a less expressive language, you are corrupting your requirements.

+1, especially for the *driven by requirements* part. 

A further point: some folks (AFAICT, people who have done little work with FOL or HOL based systems) will argue, or simply assert, that more expressive languages make the representation work harder (because they are so complex or have harder to understand elements, like quantifiers).

This involves a confusion between *language* simplicity and *representation* simplicity. 

If you have to model complex things, you have to model complex things. Making the *language* simpler doesn't change that. It must makes it harder to represent complex things.

To wit:  

- I've worked with many newbie ontologists and domain expert non-ontologists trying to get their heads around different modeling constructs in various different languages. Yes, quantified rules are hard, and not everyone really gets them.  Restriction Classes in OWL are also hard, and (generally) even those who get them generally continue to find them counter-intuitive. Neither are going to be good interfaces for the non-ontologist; at least quantified rules are (generally) intuitive to ontologists. So if your modeling requirements include complex things that can be expressed in quantified rules or restriction classes, you don't make your task simpler by choosing a less expressive language.

- Many of the most specialized ways of thinking needed to do the simplest ontology are difficult for the unfamiliar in any language. This includes fundamental semantic/ontological principles such as the distinction between subClass-superClass, part-whole, and subtopic-supertopic relationships. IME, these fundamental distinctions are much easier to teach and learn if you have the logical entailments of close at hand, for inspection and reminder, as declarative rules that are part of the representation of the concepts, BTW. That is, they are easier to get across, and easier for the newbie to find and remember, when teaching someone to use CycL than when teaching someone to use OWL. So, a less expressive language doesn't necessarily make the hard parts easier; it may actually make them harder by rendering them more opaque.

- Finally, an argument by analogy.  Some folks say that you should use simpler, less-expressive languages iff your requirements don't include anything that can't, in principle, be expressed in those languages. In some cases, they are confusing language simplicity and representation simplicity. In other cases, they are just not taking into account the *cost* of language simplicity in terms of representation simplicity. A simpler language often makes representation more complex. If this does not seem obvious, remember your basic propositional calculus: we don't really need all those operators. Every statement expressible in prop logic using the classical set {&, V, ~, ->, <->} can be expressed with just {&, ~} or {v,~}. So the rest is just syntactic sugar, right? OK, now think: If you, a human, have to represent a whole lot of statements in propositional calculus, and many of those statements are expressed using "if-then"s and "and"s in their intuitive and/or given state, is it *easier* or *harder* to get the task done if you just have {v,~}?  As you might remember if you ever took an Intro to Formal Logic class, and I can report from teaching it about a dozen times, the answer is *harder*.  It's not even a close call. So: If you have to represent complex things, choosing a less-expressive representation language does not make those things less complex. It just makes them harder to represent. And that, most certainly, has a cost. 

Amanda

 

_________________________________________________________________
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/OntologySummit2012/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2012  
Community Portal: http://ontolog.cim3.net/wiki/     (01)