Represent reference points

[SirkoS]

We had some questions concerning variables the modelling of variables where the property is in relation to some kind of reference point. Take Root mean square deviation of atomic positions (or RMSD) as an example. Here, you have two variants of a molecule (e.g., some protein) and compare the positions of atoms within those molecules. One of the molecules is considered the reference molecule wheras the second one is considered the variant. The observation is then made for the variant to "measure" its deviation from the reference molecule.

For modelling, we now have to make a decision how and where to capture this information. Overall I see three options right now as follows:

For all options we start with a modelling like

• Property: RMSD
• OoI: Protein X

(1) Subclassing Properties

As the number of reference points is rather small, we could subclass those properties for these reference points and mint something like RMSD with respect to Protein A as a subclass of RMSD. This new property would then be used instead of the vanilla RMSD.

That would be rather easy to integrate but the information about the reference point is rather obstructed unless the minted sub-property somehow models it on its own.

(2) New Role for Reference Points

This would require adding a property to I-ADOPT similar to hasMatrix or hasContextObject along the lines of hasReferencePoint. Then we could refer to the reference point as a part the Variable description itself.
So the above model would look like

• Property: RMSD
• OoI: Protein X
• Reference: Protein A

Part of the modelling could be to create a sub-property for hasContextObject. As a reminder, the description for `hasContextObject`` reads

A Variable has an Entity that provides additional background information regarding the ObjectOfInterest.

To me the reference point is one of such background information but has a very distinct role that can not just be subsumed by the generic ContextObject. This might warrant a new property or we go for option (3).

(3) Use a Constraint on ContextObject

As mentioned under (2), I think that the reference point not just be "yet another ContextObject". Another object might be, to put that information in a Constraint of a ContextObject.
So, the Variable description would become

• Property: RMSD
• OoI: Protein X
• ContextObject: Protein A - constrained is reference point

This would not require a change to the I-ADOPT model but still maintain the information.
We could "encourage" this pattern via the Variable Design Patterns which we had started a while back and additionally include this in the "how to model"-tutorial.

---

As you might have guessed from the description, I'm currently tending towards Option 3.
However, I'd like to hear from others. Do you other ideas how to keep the information about the reference points as mentioned above?

[graybeal]

I’d say the number of reference points is rather small so far. So don’t like (1) because too much expansion of core properties.

The diff between (2) and (3) is level of indirection and maybe formality. I wish background were not in defn of hasContextObject, I think this is primary info not background. (And is it a property of the object or of the measurement? But I digress.) Minting new subproperty is rigorous, direct, and clear but like (1) how many types of context objects will there be?

I can’t quite figure out what part of the model is is reference point. Is it a string, a class, a property? Is it controlled and defined by I-ADOPT? If not I don’t like the lack of rigor. If it is controlled you get the same issue as applies to the first 2. So because this is indirect to read I prefer (2).

Secondary question: is RMSD any RMS deviation, or only RMS atomic position deviation? Seems to me the latter, and there are a lot of other RMS deviation types (distance, weight–basically any measurement or observation type). That likely needs modeling too.

[SirkoS]

I’d say the number of reference points is rather small so far. So don’t like (1) because too much expansion of core properties.

Agreed. I added (1) for completeness sake but I feel it is "hiding" some information in arbitrarily broach concepts - this time for Property and not Variable. This would be defeating the entire purpose of I-Adopt, I feel.

The diff between (2) and (3) is level of indirection and maybe formality. I wish background were not in defn of hasContextObject, I think this is primary info not background. (And is it a property of the object or of the measurement? But I digress.) Minting new subproperty is rigorous, direct, and clear but like (1) how many types of context objects will there be?

I can’t quite figure out what part of the model is is reference point. Is it a string, a class, a property? Is it controlled and defined by I-ADOPT? If not I don’t like the lack of rigor. If it is controlled you get the same issue as applies to the first 2. So because this is indirect to read I prefer (2).

In my mind, this would be an class to be instantiated for this specific type of constraint and be part of the I-Adopt specification. Something similar to the following, using ns:ReferencePoint as an example:

ex:VariableA  iop:hasObjectOfInterest ex:OoIX ;
              iop:hasProperty         ex:PropertyY ;
              iop:hasContextObject    ex:ContextObjectZ ;
              iop:hasConstraint [
                 a          iop:Constraint, 
                            ns:ReferencePoint ;
                 constrains ex:ContextObjectZ ;
              ] .

However, I did no yet check whether there would be a suitable concept in some other ontology that could be re-used here.
In my mind, we would not necessarily have to mint a new IRI within the I-Adopt namespace if there's a sufficiently good concept already in general use. (Note: being part of the I-Adopt spec does not mean part of the I-Adopt namespace. We did it like that so far but that's in my mind not mandatory.)

Secondary question: is RMSD any RMS deviation, or only RMS atomic position deviation? Seems to me the latter, and there are a lot of other RMS deviation types (distance, weight–basically any measurement or observation type). That likely needs modeling too.

There's plenty of other Variables similar to this one. I just chose it as an example as Barbara and I were asked about how to model this very Variable.