sbol3-11706 - Sequence restrictions & locations

[goksel]

For this validation rule:

Should we assume that each feature can have multiple locations?

If that is the case, should the number of locations be the same? If this is the assumption, should the corresponding location types be the same?

This rule may be quite complex to implement for features with multiple locations. It would be very helpful to clarify the validation rule.

Here is the validation rule: sbol3-11706 - If the restriction property of a Constraint is drawn from Table 10 and if the Feature objects referred to by the subject and object properties both have hasLocation properties with Location objects whose hasSequence property refers to the same Sequence, then the positions of the referred Location objects MUST comply with the relation specified in Table 10.

[jakebeal]

Yes, they can have multiple locations, but the number of locations need not be the same.

The relations are all from standard internal calculate, and for many of the relationships the extension to multi-location can be done in a straightforward manner by consider the min and max of the set (e.g., if you have locations [100,200], [300,400], and [500, 600], you can abstract the relation as a relation with [100,600]). The relations this applies to are precedes, strictlyPrecedes, meets, starts, and finishes.

The overlaps, contains, and strictlyContains relations, on the other hand, need to be considered with respect to the set of individual locations.

• The overlaps relation holds for the two sets if it holds for any pair of locations between the two sets.
• The contains and strictlyContains relations hold for the two sets if the relation holds for every member of the object set with respect to at least one member of the subject set.

[jakebeal]

Note that everything I wrote applies to linear sequences, as the interval calculus is defined only for a linear topology. We haven't attempted to define the meaning of these on circular sequences.

[goksel]

Thanks Jake, adding a comment here not to forget so that your explanation goes to the spec in the next version to avoid an unambiguous interpretation of these sequential restrictions.