On 19 Oct 2011, at 17:07, Ali SH wrote:
[AH] Allow me to attempt re-phrasing what's been said. In contrast to a paradigm for ontologies like Cyc, whereby one tries to model the domain as faithfully and completely in one formalism and then delegates reasoning tasks based on the analysis of this expressive representation;
[BP] Is that how Cyc works? That's not my understanding, but whatever :)
I over simplified and in fact cringed after reading the sent email. What I meant to contrast is that in many ways Cyc is an example of a paradigm which represents the domain in an expressive language and then finds the appropriate subsets that match decidable logics for reasoning. At least, that's my understanding. It uses a variety of reasoners.
Sure. Approximation is a reasonable approach.
[BP] The problem with super expressive logics such as Common Logic is, roughly, the tool support sucks and probably sucks for the forseeable future.
I would hope that with the current work under way by the Bremen group (HeTS) and the Toronto group (COLORE), a CL ontology could be factored into more tractable fragments.
If so, then it probably doesn't need the extra expressivity. In expressive logics, size is less important than complexity. Euclid's Theorems don't make for a *large* KB, but good luck writing a reasoner that can return the rest of the Elements :)
Of course, not to mention a number of CL reasoners currently under development
Such as? First order theorem proving is pretty hard and existing ones are pretty good. None that I know of are targeting CL per se or ontologies, really.
and the environment being developed by CameronRoss. Needless to say, I'm more optimistic about utilizing more expressive languages.
As I work on adding expressivity to OWL, I am too. I'm much less sanguine on having a FOL reasoner that is robust to wide rangingly complex input. Show me something that can handle an appreciable fraction of Ernie Davis' Commonsense Reasoning textbook and I'll be impressed.
If you are "using" FOL but really using a hugely restricted subset + a radically incomplete reasoner, then, well, I'd argue you shouldn't be too excited about the fact that you're "using" FOL.
On Wed, Oct 19, 2011 at 11:42 AM, Bijan Parsia <bparsia@xxxxxxxxxxxx>
In the end, it shouldn't really affect what you're trying to do. If you need to represent something, you need to represent it. If you put it in your "ontology" rather than in your "rule base", but the answers are the same, does it *really* matter?
Admittedly, the surface language might end up not mattering much,
Surface or deep, the terms "rule" and "ontology" are almost certainly analytically null from every perspective.
but I certainly was confused as to what people meant by Rule, and clarifications such as this thread can help avoid pointless future confusion when talking to different groups of people :D. Further, in the context of the OOR and using the OMV to tag various registered ontologies and create web-services and workflows around what is in the OOR, these distinctions could come to bear.
I'd be surprised. But I don't know what OOR and OMV are.
Presumably, we're going to see more OWL+SWRL or RIF ontologies being deployed and registered in the repository. How will the SWRL or RIF modules be stored
If that's an issue I'd respectively suggests that your repository has fundamental problems of a non-deep nature.
and what is the nature of their relationship (using OMV or an extension) to the OWL ontologies? What is the nature of a subset of some CL ontology that maps to some OWL+SWRL combo?
I don't really understand the question(s). Presumably the nature will be, oh, equivalence? What "nature"? Different equivalent formulations can have distinct computational issues, of course, but..."nature"?
And so on.
Well, since I can't follow the first terms of the series I don't know how it goes on. I'm sorry that I'm not up to speed on the distinctive challenges which are being debated here, but for me, the challenges of e.g., ontology integration is where the domains (and perhaps knowledge) are the same but the representations (say, in a single formalism) diverse or when the domains are distinct and their formalisms diverse as well. So, in the first case, ontology alignment; in the second, combining formalisms. I'd be surprised if there was a huge call for the first case across significantly different base formalisms.
To what extent can these mappings be automated and tools / services orchestrated to solve ontology related problems for reseachers / professionals?
It'd be nice to know what problems, with what degree of occurrence are trying to be met.
This seems to be precisely the sort of low level implementation detail being wrongly elevated into a high level strategic or architectural decision that should be strenuously avoided. (I stress the "seems"; I wasn't there.)
The sense I got was that not everyone involved in the discussion was clear about the distinction between rules / axioms, so it seems rather relevant.
No, it's really totally and utterly irrelevant, afaict. It's easily subsumed by how do you cope with different formalisms (which is at a level above the level of dealing with different concrete notations) and different (equivalent or otherwise related) formulations.
The simple (and right) thing to do is just to develop requirements for formalisms (and formalism handlers) to be targeted, and leave the rest to implementors.
Bijan "It's important to know when not to care" Parsia.