Version 4 (modified by detwiler, 8 years ago) (diff)


For this view we wanted to first identify everything in the FMA that is part of (transitively) the musculoskeletal system. For each such entity, we want all of its superclasses and metaclasses. For all classes so far we want all properties (and property instances) whose instances either connect two of our classes of interest, connect a class of interest to a literal value, or connect a class of interest to an instance of a reified relationship class. For each such property we want its super properties. For each class of reified relationship encountered, we want its superclasses. For each of these new resources we want their properties, according to the same criteria just described.

On the surface this sounds a lot like the NeuroFMA query, and it is. So I started with the NeuroFMA query and attempted to alter it to fit the musculoskeletal system. Actually, I first tried to alter it to produce a simpler view for just the skeletal system. I needed to first determine whether to start from "Skeletal_system" or "Skeleton" and traverse parts. In the FMA, the former contains the joints, while the latter is strictly bones. So I decided to start from the Skeletal_system. However, it was not connected to everything that one would expect simply by following the alternation of regional_part and constitutional_part (as was used in the NeuroFMA query). I initially tried adding Systemic_part to the list of properties to traverse, but this property is old and nearly obsolete and introduced more errors than expected. After conferring with the FMA's main author, I changed Systemic_part to Member. This enabled the query to reach a lot more musculoskeletal entities.

After the above change, I noticed that the above query was including the Eyeball in its results, clearly not a part of the Skeletal system. After consulting with the FMA's author, it was discovered that this was related to a change in the meaning of "Orbit" in the FMA. Initially the Orbit meant only the bone surrounding the compartment containing the eye. Later it was amended to mean the surrounding bone and the compartment itself. When this change was made, not all of the appropriate properties were updated. Still included was Skull regional_part Orbit, which was no longer correct. I removed this fact from the knowledge base and re-ran the query. At the same time I modified the root to be the musculoskeletal system instead of just the skeletal system. I still found right and left eyeballs in the result. Tracing back to see how these were included I discovered:

Skull regional_part Viscerocranium Viscerocranium constitutional_part Right_orbit Right_orbit regional_part Right_orbital_compartment Right_orbital_compartment constitutional_part Right_orbital_content Right_orbital_content constitutional_part Right_eyeball

(and similarly for left)

So, removing the single connection described previously did not disconnect the right and left eyeballs from our view. For now these were left in but noted as content issues to be addressed ASAP.

The above issues are content based. They illustrate two issues, 1. Errors in the underlying ontology can lead to errors in the view, and 2. Writing the view query often requires consultation with experts in the underlying ontology.

The next issue faced was related to the query itself. When loading the results into Protege, there were a handful of instances of protege:ExternalClass. These turned out to be instances of reified relationships whose class type was not carried over into the view. The original NeuroFMA query includes a sub-query that acts as a patch of sorts, naming these classes and including them specifically. In the Musculoskeletal view there were a couple of new classes required:

Organ_system_subdivision_part_of_relationship_value Muscleorganpart_of_relationship_value

Once these were added to the query, there were no longer instances of protege:ExternalClass in the results. At this point the results were sent to the view requester for approval/feedback.