- From: Phillip Lord <phillip.lord@newcastle.ac.uk>
- Date: Fri, 15 Sep 2006 13:30:04 +0100
- To: "Kashyap, Vipul" <VKASHYAP1@PARTNERS.ORG>
- Cc: "chris mungall" <cjm@fruitfly.org>, <semantic-web@w3.org>, <public-semweb-lifesci@w3.org>
>>>>> "KV" == Kashyap, Vipul <VKASHYAP1@PARTNERS.ORG> writes: KV> Obviously, if mapping into instances gives better performance KV> for a given set of inferences, that might be the basis of KV> choosing the instance-of relationship. Towards this end I have KV> the following questions for Phil: KV> 1. What are the set of Abox inferences implemented in the GO KV> example? In that example, there aren't any. At that stage, the instance store was not doing ABox reasoning at all, just TBox, made to look like ABox. The system is richer now, and you can express some relationship between individuals in the ABox (as well as any expressivity you like in the TBox). But, I don't have details, I am afraid. KV> 2. What would be the corresponding set of TBox inferences KV> implemented if the KV> design choice proposed by Chris was adopted, i.e., p53 is a KV> subclass of Gene (assuming a general "Gene" class) I am presuming by "set of inferences" you mean, what can you express? The TBox supports OWL-DL in full. Actually, as the InstanceStore punts much of the work to the reasoner, without limits this is constrainted by the reasoner not the instancestore per se. So it does what ever you reasoner does. KV> 3. What are the performance and scalability implications of (1) KV> vs (2) ABox reasoning is harder than TBox. As is the way with DL, exactly what the implications are, depends on exactly what you express and I am not really an expert. KV> 4. What are the expressiveness implications of (1) vs (2), i.e., KV> can we express KV> some statements using subclass-of based modeling which are not KV> possible using instance-of modeling; or vice versa.... KV> Look forward to a good use case illustrating the above and KV> discussing its possible consequences. The limitation is that if you're entities are in the ABox in this case, there are a very limited number of things that you can say about their relationships to other entities in the ABox, although you have the full expressivity of OWL to relate them to the TBox. Flip side, is that if you put everything into the TBox, then you get nothing from the relational backend of the instancestore. In the GO example, for instance, you could put all the associations into a reason as modelled as OWL classes, but the reasoner will probably not scale to 6 million instances. Separating entities into ABox and TBox depending on how many of them there are is, of course, unsatisfying from an ontological perspective, but as you are asking about scalability of computational reasoning I don't think you have any choice but to be pragmatic. Phil
Received on Friday, 15 September 2006 12:30:23 UTC