Handle multiple revisions of components in the Component Library
It is possible for many different revisions of an object to contain the same semantic types. The question is how to handle this in the Component Library.
Imagine you have two different KARS
one with a component, urn:lsid:someauth:namespace:24:10
and the other with a component, urn:lsid:someauth:namespace:24:11
both of which have equivalent semantic types.
These two components should show up properly in the Ontology tree in the Component Library but since they would be in the same place there is a collision. For this reason, LSID cannot be used as the identifier in the Component Library. The new Library Index has a unique Library Index ID (LIID) for each item that shows up in the Component Library tree. With this LIID we can associated multiple LSIDs with any given LIID (see LIBRARY_LSIDS table in the sql).
This problem is not limited to LSID revisions. But also objects that have the same name and the same semantic type.
#1 Updated by Aaron Aaron over 12 years ago
As a first solution to this problem I have added a context menu item to components in the Ontologies of the Component Library. This menu item shows the current default LSID (i.e. the LSID that will be used when you drag the component to the canvas or perform any LSID specific right click operations on the Library Item) and it has a secondary drop down that shows any other LSIDs that are associated with that Library Item. From the secondary drop down menu the user can select the new default LSID they wish to be associated with the current Library Item.
To see this in action:
create a new workflow and save it to a KAR making sure to add a semantic type
change the new workflow (so the LSID revision is rolled) and save again to a different KAR
then go to the ontology and find the component under whichever semantic type (aka ontology class) where you put it
right click on the component