[lego] occurs_in inferences

From cmung...@gmail.com on July 24, 2013 15:34:15

If a reaction instance R is part of a process instance P, and that process
instance occurs P in some C, then the yellow box should should show C
for the reaction R too (unless a more specific one is specified).

The challenge here is inferring superclass expressions (e.g. "occurs in
some P"). Options:

1. Name potential class expressions
2. Use graphwalker code. Either OWLTools or LEGO native code
3. Name individuals

I think 3 may be most promising for LEGO in general. The basic idea is
that if you know that P Type: occurs_in some cytosol, then you can
name the specific cytosol instance (e.g. a UUID or a skolemized name
like P-location-in-cytosol).

So given

• R part_of P
• P occurs_in L
• L rdf:type C

(where L is the new named individual)

We can infer

• R occurs_in L

Given the relevant property chain (check: OPEs in Elk 0.4).

Now this may require a change to the algorith for finding what goes in
the yellow box. Previously there was some kind of graph walking(?)

The modified algorithm would simply be to query for all OPEs for an
individual for the occurs_in property. Use the asserted Type for the
targets of all these OPEs. If you end up with >1 Type, do the usual
(take the most specific, or make an intersection of the most
specific).

This style of instance-based reasoning may be the way we want to go
for LEGO in future.

Original issue: http://code.google.com/p/owltools/issues/detail?id=74

Start by tracing the algorithm that determines what appears in the yellow box, then inspect the relevant property-chain support in OWLTools or LEGO native code, including the Elk 0.4 OPE behavior mentioned. The work is done when an R part_of P and P occurs_in L relationship causes R to show L's asserted type, using the specified most-specific or intersection handling.