Or, likewise, what are the practical benefits of preferring a decidable
ontology or rule language over an undecidable one, in particular in the
context of Semantic Web reasoning?
Clearly, the requirement for a logic-based knowledge representation language
to be decidable
comes to a price
in form of restricted modeling and reasoning expressivity.
For example,
in OWL 2 DL it is not possible to define a comparison relationship
such as "largerThan" as both transitive and asymmetric: while both
features exist in OWL 2,
they must not be combined in order to retain decidability of OWL 2 DL.
So there should be good reasons to justify all the effort being undergone
in theoretical computer science, language design and reasoner development
to keep knowledge representation formalisms
and core ontology languages of the Semantic Web
decidable. Who knows the reasons?
At best, it helps maintain the noble but foolish illusion that one day the whole world will be axiomated and we can find its inconsistencies. At worst, it's a ploy by mathematicians and logicians to get papers published. For those who are not mathematicians or logicians and don't care about pie-in-the-sky goals, there is no benefit in choosing a decidable over an undecidable language. What matters to them is usable modelling constructs and fast reasoners.
My usual answer is that Java is also undecidable - does this make Java useless? Shall we define a subset of Java that disallows recursion only because some people may then create endless loops?
Frankly, the obsession with decidability has been one of the key mistakes in the design of the semantic web stack (together with RDF/XML serialization), and has damaged the reputation of simple yet useful technologies like RDF and SPARQL.
what are the practical benefits of preferring a decidable ontology or rule language over an undecidable one, in particular in the context of Semantic Web reasoning?
Really interesting question...
Being an engineer by trade, personally I always found the distinction between an undecidable fragment (which will sometimes not terminate) and a highly intractable fragment (which will sometimes not terminate before the heat death of the universe) as a rather curious, academic one. By definition, I don't think there can be a practical benefit to this distinction.
Of course, it is interesting to study what combinations of features cause intractability or undecidability, which might inform ontology design and reasoning techniques. Also, it's interesting to study tractable fragments (although I don't think that polynomial complexity is granular enough). But otherwise, I really don't get the practical benefits of making the language more complicated, verbose and unusable, just to shift from a theoretical notion of undecidability to a practical notion of undecidability.
For me it's almost entirely about the accessibility of the ontology that you're creating. By restricting the OWL features that you use, you make data models easier for users to understand, and easier for modelers to maintain. An overly complicated ontology can make progress to whatever end goal you're working on much, much more difficult (not counting the time it takes to create the complex model to begin with). After all, your goal isn't/shouldn't be to build an ontology, but to do as as a step towards some bigger goal.
However, the argument likely to come to the forefront here is computational cost; if you're using features that make reasoning undecidable then you can end up in an unhappy place. I'll let others expound on that one as it's less interesting to me.
This will probably indicate my lack of knowledge of OWL, but I would have thought that the biggest issue is compatability with other ontologies via imports.
The ontology is the important thing not whether it is decidable or undecidable. I want to create an ontology that relies on terms in another. If mine is decidable and theirs isn't, does that mean I can import theirs?
Also, understanding what people use reasoning for is actually more important. I think more importantly an ontology should describe itself as a 'Deduction Ontology' (one designed for deduction i.e highly expressive) or a 'Materialisation Ontology' (a vocabulary of terms with domains and ranges to help facet your data - i.e lets you create and make the most of your RDF).
EDIT - ADDENDUM
"So there should be good reasons to justify all the effort being undergone in theoretical computer science, language design and reasoner development to keep knowledge representation formalisms and core ontology languages of the Semantic Web decidable."
We should also try to think about making OWL accessible to the Web. Making OWL more clear to the layman could be argued as being more important than the above. I only mention that because some people who can contribute may be excluded due to the plethora of complexity around OWL.
Disclaimer: I don't consider myself as a decidability-integrist, and I completely agree that undecidable language can legitimately be used or standardized. However...
As I see it, a practical interest of decidable languages on the semantic web is interoperability. In some (granted, not all) situations, you may publish linked data using a given ontology, and expect the consuming agents to infer the entailed triples from the ones you published.
While some reasoners are able to deal with OWL-Full, none of them is (nor can be) complete. So different reasoners may provide different results; semi-decidability is not the answer here, as reasoner A may miss something that reasoner B finds, but the opposite can be true. As none can be complete, none can be blamed more than the other. This is not the case with OWL-DL, if two reasoners disagree, then one of them (at least) is not compliant.
Again, I'm a big fan of OWL-Full for exploratory or informative knowledge modeling. And every piece of inference you get in that context is bonus. But if you have to rely on inference, and I expect some semantic web applications will, then decidability may be required.
Something decidable is easy to test and easy to make guarantees about. You can get commercial and open source products that implement SPARQL and most OWL standards and the vendor can offer some guarantee that the product does what is documented. If the product fails to work on some particular input, I can file a bug report.
If a system is answering an undecidable question, the vendor can't guarantee that the product will work. A bug report that the system fails to perform can be hard to answer -- since no system can work correctly for every possible input, "failure to perform" might be a bug or it might just be the way it is. It could be exceptionally hard to tell the difference.