DIDEO and MP working together

The question is how MP and DIDEO work together. I think that the main thing is to always remember the distinction between the evidence base and the knowledge base. To generate a PDDI knowledge base, we do not do inference over the entire evidence base. Rather, just those NP:Assertions that formalize MP:Claims with MP:Data with an MP:Method meeting some belief criteria.

With this in mind, there are three points of DIDEO integration.

  1. One is with the entities represented as OWL RDF in NP:Assertion instances. The use of DIDEO for this is very direct because the NP:Assertions are written in OWL using DIDEO and the resulting RDF is inserted into the evidence base.

  2. Another, is to assign at type to MP:Method instances.The use of DIDEO for the latter is being implemented (e.g., see this draft). The idea is currently that RDF created using MP:Data and MP:Methods will be sent to an OWL DL reasoner to infer the exact evidence type according to DIDEO. This will then be stored in the MP graph such that it is clear that it either is an MP:Method instance, or is the DIDEO evidence type of an MP:Method instance. @jodischneider - can MP:Methods be MP:formalizedAs the same way that MP:Claims are? Maybe that would be a good solution so that we don’t break things from an ontology perspective

  3. Finally, the data attached to MP:Data will need to be represented in a logically consistent manner that is concordant with OBI practices. We have worked through several different data examples such as drug Clearance. I think the trick here is to create the instance representation under an MP:Data instance, but using OBI and DIDEO properties. We can probably discuss departing from the idea of using DIKB specific Data and Material instances which seemed important previously but shouldn’t be necessary so long as the MP:Method connects to a DIDEO evidence type which can be used by client programs to know what exact data and method resources.

@jodischneider and @mbrochhausen - would you please continue the discussion on item #2 above? We need to come to a conclusion about how to refer to the URIs of the DIDEO evidence types from MP:Method.

It seems that MP:Method instances support MP:Data instances and are themselves supported by MP:Material instances. Since MP:Method resources are instances, perhaps it makes the most sense to type the instance. So, we create a resource with a URN that MP:Supports and MP:Data instance and is assigned an rdf:type of MP:Method and an MP:FormalizedAs pointing to the evidence type class URI in DIDEO. The RDF endpoint holding the MP graphs would be able to provide all of the information about the evidence type from DIDEO so long as that ontology is also loaded into the endpoint.

What are your thoughts?

@rdb20 The link in your point #2 above doesn’t work for me. (Example of DIDEO being implemented for typing MP:method ?)

Yes. See the definitions from https://github.com/dbmi-pitt/DIKB-Micropublication/blob/master/data/mp_1.18.owl


:formalizedAs rdf:type owl:ObjectProperty ;

          rdfs:subPropertyOf :supports .


:formalizes rdf:type owl:ObjectProperty ;

        owl:inverseOf :formalizedAs ;
        rdfs:subPropertyOf :supportedBy .

If I understand correctly (there’s some grammatical ambiguity), you’re saying:
X a mp:method
Y a mp:data
Z a dideo:XXX #XXX is the corresponding DIDEO evidence type class
mp:supports Y
X mp:formalizedAs Z

Yes, I think that is what I mean. Unless I am mistaken, this is simple approach to stay true to MP for claim/support graph instances, while retaining a rigorous level of formalism for the evidence type. One question I still have just to be sure is if it is correct to have:

Z a dideo:XXX #XXX is the corresponding DIDEO evidence type class

implying that Z is an instance of the evidence type - I think that makes sense but wanted to call it out for discussion in case it raises concerns about class / instance distinctions. @jodischneider, @mbrochhausen1 or @Bill_Hogan - thoughts