iGEM 2018 Distribution collection #652
Comments
jamesscottbrown
changed the title
|
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. |
|
Here is the collection in my private repo: Please let me know if you see any problems or if it is okay to post. |
|
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. |
|
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 ***@***.***> 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 <#652 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADWD94vCUn9U41BmFoZtxcVFMBS9me_dks5uLg4UgaJpZM4VjQH2>.
|
Previous distributionsI 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. ErrorsI get an error trying to view the details for some (possibly all) of these parts. For example, this page gives the error: |
|
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 ***@***.***> 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 <#652 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADWD99VGh6wA3XzZuG1VV1IWfd-Sr7sDks5uLhnxgaJpZM4VjQH2>.
|
|
It seems that collections form a hierarchy. The part you linked is listed as being a member of the collections: But this could be written as: 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. |
|
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
<each cell type>
<part>
...
iGEM 2018 Plasmids
<each plasmid>
<part>
...
iGEM 2018 Part Library
<part>
…
iGEM 2018 Plates
<each plate>
<part>
...
<each well>
<part>
…
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 <#652 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADWD9yGsV5NexZtzaNcU9coFTt0622iBks5uLhusgaJpZM4VjQH2>.
|
|
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 ***@***.***> 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 <#652 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADWD9yGsV5NexZtzaNcU9coFTt0622iBks5uLhusgaJpZM4VjQH2>.
|
|
Issue with share links to public entries is fixed on dev server. See here: |
|
That now works, but has a revealed a text encoding/escaping bug: the page for BBa_K925000 displays the name incorrectly as |
|
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 ***@***.***> 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 <#652 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADWD9-GN9hVqHv8pZ1_-u8K6Pz0CDGSmks5uLi1sgaJpZM4VjQH2>.
|
|
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. |
|
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 ***@***.***> 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 <#652 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADWD99fEe49wvufmiTj5iBS0L0XqqF7eks5uLjqGgaJpZM4VjQH2>.
|
|
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. |
|
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 ***@***.***> 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.
|
|
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. |
|
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 ***@***.***> 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 <#652 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADWD92W9tHBHXsklC_Z9UnQS28kUaOI4ks5uMeShgaJpZM4VjQH2>.
|
|
Posted here, so closing: https://synbiohub.org/public/iGEM_Distributions/iGEM_2018_collection/1 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: