SBOL 3->2: access is not set on ComponentInstance objects

[jakebeal]

SBOL3 does not have a public/private access distinction, so all SBOL3 SubComponent objects that become SBOL2 Component or FunctionalComponent objects need to have their access set to http://sbols.org/v2#public. This is not currently happening.

While correcting this, it is likely also a good idea to check if the 2->3 conversion is building SBOL3 Interface objects properly.

[jamesamcl]

Ah I know exactly why this is happening, and it wouldn’t have happened in earlier versions of sbolgraph so you wouldn’t have a fixup for it. Thanks for letting me know.

[jamesamcl]

I was just looking at restoring the previous behaviour of setting them all to public, but:

SBOL3 does not have a public/private access distinction, so all SBOL3 SubComponent objects that become SBOL2 Component or FunctionalComponent objects need to have their access set to http://sbols.org/v2#public.

Should they not be set according to the SBOL3 Interface?

Currently 2->3 conversion does not build SBOL3 Interface objects at all, but I will implement this as well.

[jakebeal]

The SBOL3 Interface determines what the direction on an SBOL2 FunctionalComponent should be. For an SBOL Component, however, there is no direction to define.

In either case, direction was never actually linked to access in SBOL2: it was perfectly legal to have private access on an input or output direction. This is part of why we ended up discarding the property for SBOL3.

[jamesamcl]

Thanks - I was getting access and direction confused.

I'm looking at adding interfaces in 2->3 conversion. However, since interfaces are optional in SBOL3, I think these should only be created when necessary to capture the same intent as the SBOL2 representation.

In order to accomplish this I need to establish what the absence of an interface in SBOL3 is equivalent to in SBOL2. Would it be the same as all FunctionalComponents having their direction set to inout?

[jamesamcl]

Or to rephrase: if all of the FunctionalComponents in an SBOL2 ModuleDefinition have their direction set to inout, can I skip creating an SBOL3 Interface for that ModuleDefinition?

[jakebeal]

I just found that we actually wrote more of this in the SBOL3 spec than I thought that we had!

From page 51 of the 3.0.1 specification:

• Every FunctionalComponent in an SBOL 2.x ModuleDefinition with a "direction" property that is not "none" is listed in the Interface of its SBOL 3.x Component. The mapping from direction to interface properties is: "in"–>"inputs", "out"–>"outputs", "inout" –> "nondirectional". Finally, every Component with "access"="public" and "direction"="none" is listed as "nondirectional" in the Interface.
• Every Component in an SBOL 2.x ComponentDefinition with "access"="public" is listed as "nondirectional" in the Interface of its SBOL 3.x Component.

This makes me reverse my recommendation above, since that would not be able to round-trip correctly. I believe that this implies the SBOL3->2 conversion should be:

• Any Feature not in an Interface becomes a ComponentInstance with access=private. Further, if it becomes a FunctionalComponent, then it gets direction=none
• Any Feature in an Interface gets access=public, and if it becomes a FunctionalComponent gets the corresponding direction.