SynBioHub / synbiohub

Web application enabling users and software to browse, upload, and share synthetic biology designs
https://wiki.synbiohub.org
BSD 2-Clause "Simplified" License
73 stars 23 forks source link

iGEM 2018 Distribution collection #652

Closed jamesscottbrown closed 5 years ago

jamesscottbrown commented 6 years ago

SynBioHub currently has a collection containing the parts from the iGEM 2017 Distribution.

Are you planning to import the parts from the 2018 Distribution? This could be useful to students doing iGEM this year.

cjmyers commented 6 years ago

Sure. I can create this. Is there any reason to keep the 2017 distribution at this point? This is just a Collection that links to the iGEM records, so I don't think anyone would be referencing this collection. If I keep the old one, it might be confusing, since the Members of Other Collections will include both the 2017 and 2018 distributions.

cjmyers commented 6 years ago

Here is the collection in my private repo:

https://synbiohub.org/user/myers/iGEM_2018/iGEM_2018_collection/1/f02adb98c7059047aa877380b11716ca872d82dc/share

Please let me know if you see any problems or if it is okay to post.

jakebeal commented 6 years ago

I think that we should keep the 2017 distribution as well: they are both reference points for many projects. If it's confusing to have both, then that's a UI challenge that SynBioHub needs to be able to handle better.

cjmyers commented 6 years ago

Confusing might be the wrong word. Take a look at this part:

https://synbiohub.org/public/igem/BBa_K592011/1 https://synbiohub.org/public/igem/BBa_K925000/1

Open Member of these Collections. This list will just get longer. I may also though have a problem with the Plasmid and Cell collections, since they do not have the year in the identifier unfortunately. I’ve updated the 2018 version to have the year in the names/ids for the Plasmid and Cell collections:

https://synbiohub.org/user/myers/iGEM_2018/iGEM_2018_Cells_Types/1/84ebdfa40087a6831eaeb157d828f02188a52f01/share https://synbiohub.org/user/myers/iGEM_2018/iGEM_2018_Cells_Types/1/84ebdfa40087a6831eaeb157d828f02188a52f01/share https://synbiohub.org/user/myers/iGEM_2018/iGEM_2018_Plasmids/1/1d69117c70a860421d2547629e503360b7c3a413/share https://synbiohub.org/user/myers/iGEM_2018/iGEM_2018_Plasmids/1/1d69117c70a860421d2547629e503360b7c3a413/share

So, we can keep both, but the question is whether or not it is useful to know what plate/well the part came in with an older distribution. Do these still get used? If so, should we scrape all the distributions and post them all in this way.

On Jul 29, 2018, at 1:33 PM, Jacob Beal notifications@github.com wrote:

I think that we should keep the 2017 distribution as well: they are both reference points for many projects. If it's confusing to have both, then that's a UI challenge that SynBioHub needs to be able to handle better.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SynBioHub/synbiohub/issues/652#issuecomment-408700267, or mute the thread https://github.com/notifications/unsubscribe-auth/ADWD94vCUn9U41BmFoZtxcVFMBS9me_dks5uLg4UgaJpZM4VjQH2.

jamesscottbrown commented 6 years ago

Previous distributions

I agree with Jake that keeping the details of previous distributions is a good idea.

I assume lots of teams will keep the plates in the freezer in case they're useful for the next year's team, and they'll want an index for them.

It would also allow users to do things like check what's changed between years from within SynBioHub, rather than having to scrape HTML tables or download separate excel files from the iGEM website.

Errors

I get an error trying to view the details for some (possibly all) of these parts. For example, this page gives the error:

Error: getType: https://synbiohub.org/public/igem/BBa_J04450/1/4711e114bb66fa516dcb97c86a357d7a7612d921/share not found
at sparql.queryJson.then (/home/deploy/synbiohub/lib/query/local/type.js:17:35)
at process._tickCallback (internal/process/next_tick.js:109:7)
cjmyers commented 6 years ago

Ok, will keep the previous ones, and if you all wish, I can create ALL the previous ones.

As for the error, if you remove the hashcode and /share, it shows up. Looks like this is a bug with share link generation. Namely, references of share links become share links, but this is unnecessary and wrong when it is in the public graph.

On Jul 29, 2018, at 2:24 PM, James Scott-Brown notifications@github.com wrote:

Previous distributions

I agree with Jake that keeping the details of previous distributions is a good idea.

I assume lots of teams will keep the plates in the freezer in case they're useful for the next year's team, and they'll want an index for them.

It would also allow users to do things like check what's changed between years from within SynBioHub, rather than having to scrape HTML tables or download separate excel files from the iGEM website.

Errors

I get an error trying to view the details for some (possibly all) of these parts. For example, this page https://synbiohub.org/public/igem/BBa_J04450/1/4711e114bb66fa516dcb97c86a357d7a7612d921/share gives the error:

Error: getType: https://synbiohub.org/public/igem/BBa_J04450/1/4711e114bb66fa516dcb97c86a357d7a7612d921/share not found at sparql.queryJson.then (/home/deploy/synbiohub/lib/query/local/type.js:17:35) at process._tickCallback (internal/process/next_tick.js:109:7) — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SynBioHub/synbiohub/issues/652#issuecomment-408703389, or mute the thread https://github.com/notifications/unsubscribe-auth/ADWD99VGh6wA3XzZuG1VV1IWfd-Sr7sDks5uLhnxgaJpZM4VjQH2.

jamesscottbrown commented 6 years ago

It seems that collections form a hierarchy. The part you linked is listed as being a member of the collections:

//cds/reporter/chromoprotein  
//function/reporter/pigment  
Cell cjBlue, green chromoprotein  
Plasmid pSB1C3  
iGEM 2017 Distribution Plate 4  
iGEM 2017 Distribution Plate 4 Well 2I  
iGEM 2017 Distribution Plate 4 Well 2K  
iGEM 2017 Part Library  
iGEM Parts Registry  

But this could be written as:

//cds/reporter/chromoprotein  
//function/reporter/pigment  
Cell cjBlue, green chromoprotein  
Plasmid pSB1C3  
iGEM Parts Registry
        iGEM 2017 Part Library  
            iGEM 2017 Distribution Plate 4  
                iGEM 2017 Distribution Plate 4 Well 2I  
                iGEM 2017 Distribution Plate 4 Well 2K  

If the UI let users fold this hierarchical list (and perhaps folded at the level of "iGEM 2017 Part Library" or "iGEM PArts Registry" by default) then growth of this list would be less of a problem.

I have no idea how much effort would be involved in implementing this though.

cjmyers commented 6 years ago

That is not quite the current structure. The structure for 2018 which is same as 2017 (except I added year to Plasmids/Cells):

iGEM 2018 Distribution iGEM 2018 Cell Types

... iGEM 2018 Plasmids ... iGEM 2018 Part Library … iGEM 2018 Plates ... … So, what ends up reported as collections that it is a member of are: Cell type collection Plasmid collection iGEM 2018 Part Library Plate collecton Well Collection So, the Well is a sub-collection of the Plate, this is the only direct sub-collection. They are all though transitive sub-collections of the iGEM 2018 Distribution, which is perhaps the scheme to use. Namely, initially show the root collections, it is a member of (transitively), then allow that to be opened to view the specific sub-collections it is a member of. The SPARQL queries to construct this will be a bit tricky, but it could be done. > On Jul 29, 2018, at 2:31 PM, James Scott-Brown wrote: > > It seems that collections form a hierarchy. The part you linked is listed as being a member of the collections: > > //cds/reporter/chromoprotein > //function/reporter/pigment > Cell cjBlue, green chromoprotein > Plasmid pSB1C3 > iGEM 2017 Distribution Plate 4 > iGEM 2017 Distribution Plate 4 Well 2I > iGEM 2017 Distribution Plate 4 Well 2K > iGEM 2017 Part Library > iGEM Parts Registry > But this could be written as: > > //cds/reporter/chromoprotein > //function/reporter/pigment > Cell cjBlue, green chromoprotein > Plasmid pSB1C3 > iGEM Parts Registry > iGEM 2017 Part Library > iGEM 2017 Distribution Plate 4 > iGEM 2017 Distribution Plate 4 Well 2I > iGEM 2017 Distribution Plate 4 Well 2K > If the UI let users fold this hierarchical list (and perhaps folded at the level of "iGEM 2017 Part Library" or "iGEM PArts Registry" by default) then growth of this list would be less of a problem. > > I have no idea how much effort would be involved in implementing this though. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub , or mute the thread . >
cjmyers commented 6 years ago

One more point to push things even more organized, would be to create a public collection called iGEM Distributions, and make each distribution a member of that collection root collection.

On Jul 29, 2018, at 2:31 PM, James Scott-Brown notifications@github.com wrote:

It seems that collections form a hierarchy. The part you linked is listed as being a member of the collections:

//cds/reporter/chromoprotein
//function/reporter/pigment
Cell cjBlue, green chromoprotein
Plasmid pSB1C3
iGEM 2017 Distribution Plate 4
iGEM 2017 Distribution Plate 4 Well 2I
iGEM 2017 Distribution Plate 4 Well 2K
iGEM 2017 Part Library
iGEM Parts Registry
But this could be written as:

//cds/reporter/chromoprotein
//function/reporter/pigment
Cell cjBlue, green chromoprotein
Plasmid pSB1C3
iGEM Parts Registry iGEM 2017 Part Library
iGEM 2017 Distribution Plate 4
iGEM 2017 Distribution Plate 4 Well 2I
iGEM 2017 Distribution Plate 4 Well 2K
If the UI let users fold this hierarchical list (and perhaps folded at the level of "iGEM 2017 Part Library" or "iGEM PArts Registry" by default) then growth of this list would be less of a problem.

I have no idea how much effort would be involved in implementing this though.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SynBioHub/synbiohub/issues/652#issuecomment-408703832, or mute the thread https://github.com/notifications/unsubscribe-auth/ADWD9yGsV5NexZtzaNcU9coFTt0622iBks5uLhusgaJpZM4VjQH2.

cjmyers commented 6 years ago

Issue with share links to public entries is fixed on dev server. See here:

https://dev.synbiohub.org/user/myers/iGEM_2018/iGEM_2018_Parts/1/6bcef4ec71cc0ff45aeea5448b91e13ad50b3398/share

jamesscottbrown commented 6 years ago

That now works, but has a revealed a text encoding/escaping bug: the page for BBa_K925000 displays the name incorrectly as Δ12d, despite the name column in the table listing members of the collection displaying it correctly as Δ12d.

cjmyers commented 6 years ago

Ok, please log that one in a separate issue, if you don’t mind. I probably won’t get to it for a bit.

On Jul 29, 2018, at 3:47 PM, James Scott-Brown notifications@github.com wrote:

That now works, but has a revealed a text encoding/escaping bug: the page for BBa_K925000 https://dev.synbiohub.org/public/igem/BBa_K925000/1 displays the name incorrectly as Δ12d, despite the name column in the table listing members of the collection https://dev.synbiohub.org/user/myers/iGEM_2018/iGEM_2018_Parts/1/6bcef4ec71cc0ff45aeea5448b91e13ad50b3398/share displaying it correctly as Δ12d.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SynBioHub/synbiohub/issues/652#issuecomment-408708259, or mute the thread https://github.com/notifications/unsubscribe-auth/ADWD9-GN9hVqHv8pZ1_-u8K6Pz0CDGSmks5uLi1sgaJpZM4VjQH2.

jakebeal commented 6 years ago

I also think that taking advantage of hierarchical structure would be a good idea. Sure, these aren't strictly hierarchical, but we should be able to indicate membership of a collection within another collection in a better way than right now, which sort of flattens everything.

cjmyers commented 6 years ago

I’ve posted the 2018 distribution here:

https://synbiohub.org/public/iGEM_Distributions/iGEM_Distributions_collection/1 https://synbiohub.org/public/iGEM_Distributions/iGEM_Distributions_collection/1

If this looks good to you all, then I will move the 2017 distribution to this collection too, and the other years too, if you think it is a good idea.

On Jul 29, 2018, at 4:43 PM, Jacob Beal notifications@github.com wrote:

I also think that taking advantage of hierarchical structure would be a good idea. Sure, these aren't strictly hierarchical, but we should be able to indicate membership of a collection within another collection in a better way than right now, which sort of flattens everything.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SynBioHub/synbiohub/issues/652#issuecomment-408711373, or mute the thread https://github.com/notifications/unsubscribe-auth/ADWD99fEe49wvufmiTj5iBS0L0XqqF7eks5uLjqGgaJpZM4VjQH2.

jakebeal commented 6 years ago

Please test to make sure that when you do this it doesn't break the links coming in from iGEM, since teams are likely using these resources right now.

cjmyers commented 6 years ago

Which links are you referring to? The 2018 distribution did not exist before and 2017 would not be useful for this years team

Chris

Sent from my iPhone

On Aug 1, 2018, at 4:47 AM, Jacob Beal notifications@github.com wrote:

Please test to make sure that when you do this it doesn't break the links coming in from iGEM, since teams are likely using these resources right now.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.

jakebeal commented 6 years ago

If I go to the iGEM parts repository, and ask for the part in SBOL format, that links to something like: http://convert.sbols.org/biobrick.php?part=BBa_J23101

We need to make certain that doesn't break, even as we merge iGEM collection versions together.

cjmyers commented 6 years ago

Ah, that is completely unrelated. The distributions are simply SBOL Collections that refer to the iGEM Registry. The link below is to the iGEM Registry collection, which I don’t plan to change at all.

On Aug 1, 2018, at 10:25 AM, Jacob Beal notifications@github.com wrote:

If I go to the iGEM parts repository, and ask for the part in SBOL format, that links to something like: http://convert.sbols.org/biobrick.php?part=BBa_J23101 http://convert.sbols.org/biobrick.php?part=BBa_J23101 We need to make certain that doesn't break, even as we merge iGEM collection versions together.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/SynBioHub/synbiohub/issues/652#issuecomment-409654882, or mute the thread https://github.com/notifications/unsubscribe-auth/ADWD92W9tHBHXsklC_Z9UnQS28kUaOI4ks5uMeShgaJpZM4VjQH2.

cjmyers commented 5 years ago

Posted here, so closing:

https://synbiohub.org/public/iGEM_Distributions/iGEM_2018_collection/1