Overhead for mapping to SBOL 2.0 DOM
Opened this issue · 4 comments
-
Lookup table to keep track of duplicate SO terms with different names
-
Expose CRUD (lookup table, SO terms, SO numbers) to users
-
Unit tests
-
Possible lookup tables with MLab. Option 2 seems to be a standard in mongoDB
Apropos Option 2:
https://stackoverflow.com/questions/4839881/how-to-organise-a-many-to-many-relationship-in-mongodb
https://stackoverflow.com/questions/2336700/mongodb-many-to-many-association
https://stackoverflow.com/questions/5498692/many-to-many-relationships-in-couchdb-or-mongodb
http://blog.markstarkman.com/blog/2011/09/15/mongodb-many-to-many-relationship-data-modeling/
https://www.quora.com/How-can-you-design-a-many-to-many-relationship-schema-in-MongoDB
https://stackoverflow.com/questions/21682980/mongodb-look-up-table-like-sql
Currently testing out the lookup table on a sandbox repository using mLab.
Going the way of option 2:
Hey @eoberortner , we're looking to require users to input a sequence ontology number when they enter a new part (kind of like PIGEON or SEQUENCE properties). Can you guide us as to where you perform logic on those properties in the code?
We're looking to use those when making Eugene SBOL 2.0 compatible.