 All right, start whenever you want. All right, so, I mean, we have a good problem. And the problem is that we just have a lot of tools. It's a great problem to have. It's really a testament though that, you know, community is working, so we have fantastic contributions. But we kind of need to make these tools a little bit easier to navigate, to find them and so on. And so there are some things that we probably need to do as soon as possible. And I just want to talk about them. I thought of some proposals. I don't know if these are optimal proposals. This is why I want to have this discussion. And John, can you enable screen sharing please? Yeah, I just enabled it. Sorry about that. That's fine. Rename themself now too. All right, so this is what I kind of want to talk about. This is outline for today's discussion. So there are two subjects really, the tool panel and tool maintenance issues. So they're different in scope to maintenance. That's obviously how you see the main tool panel. Tool panel is more of a deployment domain and so on. So let's talk about tool panel. So I spent some time actually understanding how this works and because last time I personally touched tool panel and we just had to underscore conf.xml. So that was easy. So that was probably 10 years ago. So the current structure of the tool panel and if you look at any of the instances, it's not really, if you haven't used Galaxy before, it's very hard to orient yourself here, especially of course there's a search, but in many cases you don't really know what you're searching for. And so this is what precipitated that idea to propose some structure. And this is this PR, which was the PR to IUC. There were some, a lot of back and forth comments and after that I think we settled on more or less that structure. Obviously, it's subjective and anybody on this call for example, probably can propose some other structures as well. So there is really no reason to have just one structure, but with the current infrastructure, the way it's put up, the way it's set up, I don't think it's gonna be easy to have different structures for tool panel. So this is probably a good start. And we've been thinking about this. So this is for example, an image from the current grant that supports Galaxy development here in the US. And this was sort of one of the ideas how the panel can be restructured. And in this case, it's really not restricted to tools. It's restricted to activities. Activities in this case, different kinds of analyses, different data types, whether you wanna operate with text or BAM or Fast 5 or something like this. There was of course two tools in the workflows and there is this ability which we have to some extent right now is customize, make a custom list. So this is an example in this mock up how this can work. So another thing that I kinda wanna say is that two panel is not sacred. And I have a tunnel vision in that sense because I've seen Galaxy in this form for the past for quite many years. But in reality, it's a little bit narrow. And so I think interferes with descriptive tool names. So there are various things that we can do about this. I couldn't find that image, but there was a mock up from Friberg where there is an overlay on top of the tool panel. So there's overlay here with different tool categories. So at least you can see everything at once. That's already very helpful. So there are many possible solutions to this problem. And so I also, I spent some time sort of figuring out how this works because I wanna understand why it's so difficult to, for example, order tools. And I also wanted to understand this particular problem. I mean, if Nate or new one cannot easily figure out how to sort tools, that means there is an issue clearly. So please correct me because I, again, I might not completely understand how this works, but we have three essentially tool configuration files now, depending on the instance. And so this one, the shared tool lives on CVMFS. That's the most comprehensive of them. It has a more extensive structure than the tool conf and integrated tool panel. So there's a history here, obviously. Initially there was tool conf, then there was integrated tool panel after the development of toolshed. And then there was this idea to unify tool distribution across usegalaxy.star instance. So this is how it came up. And so challenges here, usability challenges that you all know it's really difficult to order. I think I don't think there is a clear understanding of what sort of goes before this. Maybe it's not clear understanding in my head. So again, please correct me. And any instance you go, it has loose tools. So for example, this is main and there is coolly bum wise here. I don't know if you go to .eu, you also have a situation where you have some tools like map annotation ID. So there are these loose tools and they're probably were put in some category in the underlying tool conf. But in this, sometimes they have more of these loose tools. Sometimes they have less of these loose tools and so on. So it's not ideal. But then what can we actually do? So it's not an easy problem to solve because in order to restructure to a panel, you need somebody who understands all the tools and we don't have such a person. We might have people who understand genomic tools but then we have people who responsible for proteomic tools or once we go to climate science, for example. So we really need kind of the main knowledge but we still need to start. And the solution I came up with is just to find some XML editor and sort of start reshuffling to get to more or less that form. And so this is sort of for me, this is what I'm gonna try to play with in the next week or so and then create a PR out of this. I'm not sure where yet. And then if we can as a community go back and forth around this maybe in a month or two we'll have a more meaningful structure for the tool panel. So before we jump to tools, what's the feeling? How can what are the good avenues for solving this? I think a lot of it can build off of work we tried pursuing with the tool suites integration that Julien had started before she left. Unfortunately we can't use any of that work but I think we have a lot of design ideas for how we can at least present the tools in the panel that we just need time to pursue. Maybe we can put them on the roadmap for the UIUX team next quarter or something and prioritize them if we really wanna push it. Well, but was Julien's work relying on some kind of a tagging of tools? So it did a couple of different things, right? So it allowed user-based toolbox organization it also allowed preconfigured admin-based organization where you essentially had multiple views of the toolbox and those were seeded by the usegalaxy.eu tool suites, right? So they have RNAseq.usegalaxy.edu and so on. So you would have multiple views of the toolbox and a lot of the infrastructure that was going in place to make that happen could be leveraged to allow user-sortable toolboxes and you could imagine building admin sorted toolboxes on the fly and really customizing not the loading necessarily but the display of the toolbox on the fly. Yeah, well, of course the way.eu goes around this problem is that they have these application specific domains. Yeah, exactly. So instead of having to run a separate web process for each toolbox, you would just run multiple process however many processes you actually need but they would all have all of the toolbox filtering. Well, I don't know if it's realistic to put this on UI, UX, working group for the next four months because I think there are lots of more urgent UI needs but here at least I think we can just start doing this. At least I'll start doing this and if anybody has better ideas and then so I'll do a PR soon with this and are we constrained to only sort of two levels in the hierarchy if you go to your listing? I mean, I wonder, for example, things that are, I don't know, sort of, I don't know what the right categories are but machine learning tools to me are very different than text processing tools different than genomics tools and then with genomics we have mapping and map data tools, assembly tools but then there's like computational chemistry. I wonder if we could have kind of a limited set of sort of top level categories and then with each of those you'd have a broader set and with each of those you'd have the individual tools. I don't know if we're constrained to those two levels or hierarchy. So any constraint there is artificial. It's yeah, that's just what we've always had. Yeah, so in the current structure I thought that, you know, just for example, like get data or interactive tools they will be this level. So these are just labels but then the actual tools will be within these categories and here we at this point we are constrained to two layers but I don't think that's a fundamental restriction. Anton, have you looked at the EDM ontology organization at the toolbox? Yes, and this is one way when I've seen screenshots and we can, this is again one question to IUC is that shall we require two authors to explicitly set this? However, I don't know how useful that is because, I mean, it's useful because it provides some structure, right? So some objective way to perhaps sort the tools and also it provides a way to automate generation of this kind of layouts but some categories they're kind of like meaningless like kind of version. Yeah, that was my main question. How useful is it actually? Okay. I still think the idea of, you know, organizing things in that way might make a lot more sense than modifying these XML files, right? So if you have the Anton, well, what you built here, right, is the Anton ontology. If we could sort of encode that in the tools as the galaxy ontology and then maybe have some sort of legacy mapping for older tools, I think that gives us a lot more structure to work with in terms of rendering it on the client side than sort of figuring out how we keep integrated tool panel in sync or whatever. I mean, it just feels like the tagging approach, it feels like a more rich path for keeping this going and keeping things in sync. Yeah. And if I can say something that's also connected to Mike's point about the number of levels you can go because with something like EDM, basically you have several layers and one category can appear in multiple branches which is something we normally don't do that in the fixed structure like this. So that's another advantage that we could have using something like EDM or our own EDM or similar to EDM. Does anybody have kind of a tree with EDM structure so we can look at it as they're... I mean, you can create this on your own and there's a EDM viewer. Because, you know, this is one of the reasons I wanted to have this channel because doing this is brutal. It's... I mean, it will only apply to use Galaxy.org, right? I mean, it's not something that's shared easily because you have to add the XML file and the ontologies would give you the opportunity to just order within the ontologies. And can we modify them? Can we modify EDM? Yes, it's a community project. I mean, I don't know if we can do things like, you know, SAM tools because that's not really an ontology, but I don't know, we could add our own ontology, for instance. Yeah, that's what I'm kind of thinking. That could be the default view and then we can have a layer of customization on top of that. But the main thing is to separate sort of the config file loading from the presentation completely. So what that means that essentially we need to go through all tool XMLs and add these exclusive tags. Well, I mean, for the older tools, that may not be possible. I mean, yes, new tools should have them, but we could augment the tool loading to sort of dynamically attach tags if we wanted and just sort of have an admin or even, you know, a core and admin configured file to sort of add additional tags for older tool IDs. I don't think... So you will have a mapping file between tool IDs and EDAM categories? For the old stuff, yeah. Yeah, and again, we could also... Yeah, it doesn't need to be EDAM. I mean, EDAM is great, but it's maybe not the structure you have here, right? So I think we should be sort of free to sort of come up with additional annotations and ontologies, but... Okay, because, you know, this is monkey job. I mean, I just spent some time doing this yesterday. I think I went crazy, but so this is not ideal solution to this problem. So how can we... So that should... Then this is completely then in IUC's domain. And I'm thinking is it possible to have some items from this on the tool working group roadmap for the next four months? Is somebody from the tool working group there? I was just talking to Alex. I thought he was... I thought he was in here. Anton, are you online working too? Oh, maybe. I mean, I don't know. It seems like the tool working group has a few people and this seems like something that can be split. And the IUC has draft EDAM annotations already, or did we... We didn't merge them, did we? I think it's still open PR can dig it out. Alex is joining and he's the organizer for the tools working group right now. I mean, does anyone wanna sort of offer a counterpoint to tagging tools as like a better path forward? Cause I could sort of see admin's local instances wanting to have very fine grand control the way they do now. Like this works for a huge tool set but maybe for a smaller tool set, it's not ideal. We could also have like hierarchical tags, right? So you could have local tags, upstream tags. So instance local tags upstream, sort of like the tags we present or EDAM has and then you could have personal tags and the order would just sort of cascade, right? And you could prioritize based on that. So like if I tag something as RNAseq and it's select random lines, it should still show up in RNAseq for me, right? That kind of thing. So what's the first step here? This is agreeing for so. So if it exists for new tools, then we need to start creating mapping for all tools now. I mean, yeah, I think we wanna sort of decide if we should just take this document you have here as the ontology or if we wanna try to merge it with EDAM in some way. I mean, I'm not married to this document. This was just something that was sort of logical to me but I'm not insisting on it in any way. It's an example. It's an example that makes sense more than what I've seen from EDAM for sure. But if we can augment things and kind of create our own ontology, then perhaps we should start with that. Yeah, I haven't really worked with the ontology formats and stuff. I would wonder if you could like sort of create our own ontology and just sort of stick an EDAM term in wherever so like we have variation data up top and then BCF tools like if there's a way to just sort of stick an existing EDAM term in there or not, I don't know. But I mean, it seems like from a programming perspective, it should be easy. I think this is more of a curation problem. Speaking of curation problem, Alex is here now. What's up? Anton, do you wanna give the brief? Yes, so the question is we need to be able to reorganize tool panel in a kind of a bloodless way. And in order to do that, we need to start tagging tools. Well, new tools are tagged. The old tools are not tagged. So for the old tools, we need to create mapping from two IDs to the categories that we want to create. And so the question to two group was, is that something that can be put on the roadmap for the next four months? Is this round ends in August? I mean, the architect who's already there, it's just going and adding the lines, right? How does this work? So it's a tag, right? So and if you want to have multiple categories, I mean, how it doesn't decide which goes first and how does this work? So I think what you guys are talking about is it's just in the shed file for all of the tools. And that is just the YAML. So I suspect the way it's ordered is just the actual order of tags within that YAML file. I haven't had the experience of like checking on that, but that's what I believe it would be, which would make this a pretty simple. We're talking about the E-DOM tags that are in... Ah, got it. I misunderstood. In that case, I don't know off the top of my head. So they are, I mean, you have the tags that describe operations that are part of the XML. And then it's us basically deciding how we order things. And currently that's hard-coded in code base, but we can decide these things. Although I would like to make a point of alphabetical ordering because that's just the natural thing. Yeah. So I actually, I wrote a PR that does that already. I can upstream it. We can get in at 2109. So I have a question about how we might actually use this. Let's say you go through this process and you go ahead and you tag it according to the scheme that you've just described. And we run something that retroactively goes through all the old tools and tags them. So using it going forward, what do you think of the idea of storing a query against those tags and that being a category or something like that? Like you say, that way it could be user defined or administrator defined. Like here's a category of things that are relevant to this Galaxy instance. Select these tags, omit those tags. You have some kind of selection criteria, like a query. And then you save that as the quote category. Is that kind of where your ultimate goal is by tagging that kind of flexibility? What's the goal? So you get a tag. That's my questions. What are you gonna do with those tags and you're done? Is it gonna be a canned ordering arrangement or are you looking to make something a little more flexible for the administrator so that he can describe what his category structure is gonna be for himself? Well, from the user perspective, the scenarios like this, you have just give me all tools which work on text. And from these tools, which work on tabular text or give me all tools that are RNA seek. But I only wanna look at the mappers. I don't care about counting transcripts. I just wanna see mappers which are RNA seek specific. That's what we need. Got you. So ultimately, that's your goal is you do want to have like robust kind of querying against this data set. And so that's gonna inform the nature of the tags that you put down there. So just pulling the ontological stuff isn't enough, right? You need formatting tags. You need any other characteristics that might be able to search against, right? Like I said, output type tags, what input type tags or I guess you could just use the existing fields, but I'm just trying to get a scope of what your end goal is with the tag. I mean, like we're trying to improve the current situation. Yes. And if I may suggest... These are all fancy things we can do, but like we're trying to improve the current situation. We should... Those are different tags. We should limit... The tagging is the mechanism that will give you a lot of flexibility in the future. I agree with you, but that's a good way to go about it. I was curious about what you intended to do with it once you had it. So those are different tags though. You have item topics and operations. Those are separate actual tags on the XML. And if we want to, we can also add data as another tag in which case you can structure by all of that. We should try it, I think, we should try to limit the amount of tags and be a little less ambitious because drilling down from, give me first all of this, then select these tags, then select these tags. This sounds great in principle, but the problem with that is that you will expect to have exhaustive coverage. We have thousands of tools and if we have all these multi-layers of tags and many, many tags, there is no way in hell, pardon my French, we'll be able to tag all the tools we have now and every single tool with all of these layers, especially when we come up with an idea of these tools. And we see the amountology side of hierarchical, right? So they have solved that problem. So if you do something that's bioinformatics, mapping, whatnot, you get all the preceding hierarchy as well, right? I mean, we also, in terms of data types, we track that, right? In our EDAM, we have EDAM terms on our data types, but probably we should just stick with the galaxy on, I mean, we effectively have an ontology because our data types have an inherited structure. So these things, we don't need to annotate, right? We'll just sort of get them by default. I have kind of a, maybe consider a stupid question, but you said, I think Anton said before, the purpose of tagging all of this is to present the user with an exhaustive list of all the possible tools, but just thinking like, is there a real productive scenario where they would actually want to do that? I mean, it's, I think it's mostly new users that use the categories and everybody else searches. But yeah, I mean, that's a good point because I think new users would more benefit from the activities part that Anton also mentioned, where you say, I wanna do an analysis or something like that. Yeah, exactly. I'm thinking like, if I'm a user, I'm coming in thinking, okay, this is the analysis I wanna do, and here are popular pipelines with different tools mixed and matched. I'm not really thinking about, okay, what are all the tools I could use to map SAM to, or BAM to SAM, or to FASTQ, et cetera. I mean, that's something that can be driven by what John said, our data technology. So we know what's in and what's going out. So, you know, you wanna convert SAM to BAM, that's not difficult to show you the tools that in principle can do it. I mean, obviously not all SAM into BAM out is a straight conversion, but yeah. I also like to just quickly jump in and say this, we don't have to do every tool all at the same time, like this can be a process. So yes, we have thousands of tools, but if we just start with the top couple hundred, that's pretty feasible to do in a little while, and we have that list based on what tools are run on main on EU and... The other thing is like, we can start with you. I mean, our first ontology can be just what, is the Shetool Conf now, right? So that'd be the default that we start off of. Or the Anton ontology that we just saw. Yes. I mean, we need to start from, for example, what can I do now? So can I do, should I start editing two YAML files? I mean, if we wanna deploy a new, freshly organized tool panel tomorrow, then yeah, it's gotta be a manual editing of integrated toolconf and those sorts of things. No, but actually, so I suppose if we want to do tagging, then can I already start doing this? I mean, I would say we need to create a spreadsheet with eDOM terms and tool IDs and we'll figure out a way to integrate that, right? Like that's... Maybe I'm wrong. Someone from the IUC should tell me to shut up if I'm wrong. But I mean, I feel like, we don't wanna go in and, I mean, we do wanna upgrade, annotate the tools as we're upgrading the tools, but we probably want all the old versions to also have tags, right? So that's something we need to do in core. And so there we just take a spreadsheet, we take tool IDs, we take maybe the latest version, and then we just sort of attach those tags as we load the tools in. And that I think is something we could just do from a spreadsheet. Can I jump in on this? We... I link the poor request on tools IUC that's from Bjorn a couple of minutes ago. And here we are not adding actually eDOM tools directly, but the idea is to have bio tools IDs. And this is the same concept, basically what we did with using Conda for tool dependency. So leverage an existing ecosystem and join a community and do the work together with other people. So the bio tools is a link and basically a collection of all the possible bioinformatics tools. And there the tools have, so basically our underlying tools. So some tools will be there. And the pages for some tools, then there's the links for the eDOM ontology. So we don't have to do all the annotation of the tools in the tools XML, but we just link to the bio tools ID and the rest of the annotation of eDOM or the input data types, et cetera, it's done. Upstream in bio tools. And we join a larger ecosystem of people that do that. And for the tools that are not on bio tools, either we add them to bio tools. So if there are galaxies specific, we can still add eDOM ontology on the tool XML. That's a fallback. Do we know if we can take the bio tools database, I mean, is the bio tools database open source? Can we like pull that information down so we don't have to make API requests when we are loading up the eDOM information, for instance, because this has been a... Yeah, if I think it's all stored on GitHub, the underlying database, I would need to take it up but it's Hervé manager that is one of the MBR, are the core APIs now of the bio tools. So it's something we could easily extrapolate. The only thing is obviously this is constantly updated. So you would need some, I don't know, salary job to download every now and then to keep it updated. We could ship on with it and then have like a, we used to have like a, I'm not sure it's still there, but like a Linfile updating script that you could set on a cron job or whatever to update if folks want for local instances. Yeah, and the same is true for the eDOM ontology. Yeah. Looking at the PR, by the way, should we just before we start going back and doing this retroactively make this part of the PR of the PR checks just to double, just to make sure that they always have the tags to require that, just that we don't have this problem going forward in the CI tools. Well, yeah. So Plenimo and also just whatever CI checks are done. I know they're mostly the same but there are a couple of differences on IUC and that way we can figure this out for retroactive tools but also not have this problem going forward. Yeah, I think this should be added to the IUC standard if it's not already. I think maybe we added something like a strong recommendation for eDOM but not bio tools. It's bio, yeah, I'm nervous. Does bio tools allow non-bioinformatic tools and can we add new tools? Those would be the two, because I... You of course can add new tools. There's just think a process you open it for request to do. And I haven't done it but I'm pretty sure you can do that as a community project. It's not a closed system at all. About the non-bio tools, I'm not sure about this. Answer that. I mean, it says bioinformatics and life sciences but I think that is probably how you know, Galaxy is as well. Accepting other things but came from there. So we're gonna need a way in the interface to provide a secondary or tertiary layer of organization anyway, right? Because we want people to be able to organize their own toolboxes so I'm not sure this matters that much, right? We're gonna have multiple layers of organization. That was kind of the point I was trying to get at is like if we can just store, we can just cache the list, you know and then we can very quickly make some kind of query structure on the client that lets you filter, order, do whatever the hell you want, you know, if we have those tags, if we have enough data points to filter on, yeah. Even with a hierarchy, we can still make it conform to the priority structure that Marius is referencing with the, you know, the hierarchal tags, that's fine. We can still make it, we can still make the algorithm, you know, respect that. So with bio tools, because, you know some tools won't have, won't be in bio tools, what they'll be like loose tools, like this. What's gonna happen to them if we automate this process? Right, so for those, we would have like a local Galaxy mapping that we ship with Galaxy or with some something else that we're gonna have to have multiple layers, that's what I was pointing out there. Yeah. We could just ship that with the code base or whatever. I wanna like, I think that if you take a tool like SAM tools, right? Doesn't it do a lot of different things and it's just gonna have one bio tools entry. I really think tagging on the tools themselves and the tool IDs are more useful than trying to resolve the bio tools information. I mean, by all means, I think we should be putting the bio tools IDs on all the tools. But I think in terms of the tagging and the work that we're sort of handing off to the tools group, I think that we should be tagging tool IDs, not tool suites. So I just want to come back and say that, because I know like GATK, right? That's gonna be one bio tool and it's gonna be a bunch of different things, right? Probably that's true for a lot of these categories of things. Yes, it's gonna be true for many of them, but I don't think that is right. I mean, I don't know if it's exactly right, but for instance, some tools is split up into individual commands. GATK anyway is not the thing anymore. It's now the individual programs, right? It's GATK, MuTag, GATK, whatnot. They have their individual things now. Okay, I mean, I could be wrong. I was just, that was just my... I mean, I'm not sure, right? I mean, I just briefly searched some tools because it's a good point, like if they're all lumped together, even though they have different functionality, that doesn't help us. And there's four pages of GATK tools. Yeah. Yeah, and also bad tools is split up into many individual tools. So, yeah. I just want to share a comment that one of the participants in GCC training shared. I tried to find the text. I couldn't find it. I'll look for it later. But they have two complaints about the tool panel. One was that if you go to the tool panel, for example, there is a statistics and visualization label, which has like a great background and there are three headers underneath, statistics, machining and grass and display data. If you expand one of those, you get a list of tools. The complaint was that these are not visually separated. The suggestion was, for example, maybe put a horizontal line because if I scroll down, I don't know whether I'm still looking at the tools under statistics or the next section has started. So if there's a widget that can visually separate the tools from other tools and headers, from different headers and led labels, that would make, I think, life easier for a new person using Galaxy. The other... It's incident, I guess that's... It's not visually distinguishable enough. We could have another like a line underneath the expanded category. Or maybe a background color or four, yeah. But I mean, this is like details we can discuss. I mean, that doesn't even need to be discussed. You can just float the headers and the names above, right? Yeah, I was going to say that. Float the header, that would be the... Because I don't... The boxes can be really big, right? So I don't... Well, it's not going to solve our problem that we're trying to address here. And so it's just... Just what I'm sort of looking here and I don't know if that's possible. I'm looking for something practical we can do tomorrow. So what can we start to address this issue? If John... If we sort of go with John's proposal, then we need to start that spreadsheet. So... And I'm not sure what the structure of that spreadsheet would be. So you have a tool ID and then you have several columns for different category sets or... Well, it seems like there was pushback in that we should be doing bio tools, not EDOM in a spreadsheet. So... But then... I'm skeptical, but I mean, if Nikola says we should start annotating everything with bio tools and make sure that the bio tools database is synchronized there. It feels like more work to me, but we should probably pick one of those two paths. If we're going to make you do a bunch of work. Can you get more things automatically via bio tools and you can update them? So these are two problems that we have if we annotate directly in the tool X, right? So you would add a term because, you know, you reorganize or like, I don't know, something was wrong. So you have to bump the tool version while for bio tools, that's, you know, you just update the data and you get the new thing. I mean, it doesn't have to be that way. We can also ship things to augment it, but that would be the advantage with bio tools. You can update it over time. Can we just pull the data from bio tools and bring it into our own format? So that we don't depend too much on them. Like what John said is I actually also would have some concerns if we only rely on that or wire it up too much with their information. So maybe we could set up a generic way and then just add a little bit of additional code to just pull it. I think that's not a bad thing to look at like, you know, how we get the data in for the E-DOM, you know, that's just something we download and as far as I understand it for bio tools is the same. So for E-DOM and bioinformatics, that's it. So it's terminal node where I don't understand something here. Because then we can tag all tools with just one category. One but you tag with multiple. So it'd be bioinformatics, data, chemistry, I don't know, something. Yeah, and you also, I mean, you're now in the green thing, which is kind of what it is, but you also have operation, which might be interesting. Yeah, is the operation gonna give you more at the second level Anton, if you go back to operation, are they gonna be more in there? Yeah, so you have mapping, indexing, these are things we do, right? What are the blue? What are the filled in? Oh, those are ones that you can say. Okay, you can dig deeper. Alignment is really, it's folder recognition is also alignment. It's a structure alignment, it's interesting. Yeah. Yeah, I think this is a... For example, what would BWEA be? You know, an alignment and a local alignment and yeah, I think that's where you fall into, right? But you can also go to BIO Tools BWEA and check. At least they have read mapping. It's actually very confusing, to be honest with you, right Bob? Yeah, and so the other thing I wanna say is if we go down the BIO Tools route, I mean, many of the developers are friends of mine, and I appreciate the statement that this is all open source and downloadable, but I've heard complaints over many years that they weren't making the data accessible, other than via download, and the JSON on the main page. So hopefully this has been fixed, but I think we should... I'm gonna put the link in the description, right? The link is in the chat, you can download it. It's all JSON-LED. Wait, this shouldn't be... Okay, all right. So it has been solved, thanks. That's all I wanna say. It sounds like it, right? I mean, I just found it, so yeah. Updated 13 years ago. Yeah, 13 days ago, I mean, sorry. Yeah, no, no, that's good. I was just reporting on a sort of historical artifact of things I'd heard in the past. Yeah, the entire thing was closed in the beginning, right? They said, no, you need to make it open source, but we have to clean it up, which is like whatever. 13 years, 13 days, a completely different situation. No, I meant to say 13 days, I really did, yeah. More than half 10 minutes to go. So, but my question is following. In the short term, in order to clean this up, that sounds like only manual manipulation of XMN can help us here. If we wanna change it like tomorrow. I mean, John's idea of spreadsheet is maybe still not a bad idea because then whatever mechanism we decide on, we can do that relatively automatically. And this automatic process, would it run into problems with this? I mean, I'm tempted to say we would just disregard all of this, right? The set of installed tools is a list and we use tags to render the panel. Completely, complete separation in presentation of the toolbox from loading. Yes, okay, but that's not happening tomorrow. Yeah, one thing that we could also do tomorrow is I think the idea of loading the section title as you scroll down the panel would help a lot. I think that random comment from K-Von was good, right? It seems like a quick CSS fix. Yeah, I liked it too. Do we expect a whole lot of huge categories like that? Cause I thought, Anton, you were saying you wanted to break down categories to have much fewer tools in each one. Yes. Okay, I mean, it's still probably a good fix for now. I also have work ready to PR that sorts within the categories if we want. So to alphabetize within the categories, we can get that in today if we want. But there were some issues with the like sub labels and things like that. So using labels, I obviously can't alphabetize those because then you lose any notion of what the label was supposed to indicate. So, yeah, well, PR it. Okay, all right. So one thing we have 10 minutes. I just want to briefly talk about something that we can do easily and that's tool maintenance. I mean, easily because there's a clear path. We don't need a new framework for doing this. So we have a tools which functionally correct, meaning that they have tools so they satisfy all IUC requirements. But they have just, they vary dramatically in terms of how friendly they are. So this is a table computer. It's a very complicated tool. And it's, I mean, it's just a slide, but it has gigantic health section with examples. So it's, you can use it. And there is this thing, which is probably as complex as table, I mean, melting, explaining somebody how to melt a table. That's a chapter in a kind of a data frame manual. But that's, you know, that's it. So I think that we should not allow these tools to go through. Wait, I mean, this is a very, very simple function and it's described appropriately. Yes, well, for you. The main function summarizes the unique variable value combination on the single line. Well, example, give me an example. I want to look at it, you know, if you go, for example, to like, you know, pandas melt, there will be a picture of it. So, so it's, yes, you can understand this. But from this, I, if I, I mean, I know what melt is, but I don't know what this tool would do. For example, what happens if I have a link is for? Well, yes, but, you know, yes, link. Okay. So the links, links not great because I can also die and go away, which is what we have a lot. So, I mean, I'm not trying to piss whoever wrote this tool. I actually don't know who that is, but just, this is probably not a good example. That's what I'm trying to say very politely here. I mean, I would like to see, because again, there are galaxy quirks to it. What happens if you have headers and column names, for example, or, you know. It says it on the top, right? Input should have column headers. Is that a place to put that information? No, that's not idea. That's true. And people don't read. That's true. My experience. People don't read. So. Yeah, I mean, it was the help section, which is typically for here, you put in the parameter help, but also have a validator on the data type feature. It had columns to find. They, they definitely don't read if there's nothing to read. Look at that one. And, and another thing that we can do is to synchronize names a little bit better, because if you look at this, for example, so here it's split file according to those, it's one sentence, but in, in other cases, it's tail compute, compute separation on table data. So two different sentences. There's a two name and then description. And then we have things which is one. So it would be nice to settle on one way of doing this. And I have this in this PR, which I pushed some ideas on how we can do that. Because that's all clarity. It's, and of course, it would also help if this is alphabetically sorted, but hopefully Denon's PR will take care of that. So what I'm proposing here is maybe we can do a paper cut on just going through tools and we can organize this paper cut maybe by tool category. So for example, let's go and curate all text processing tools. Just do it. And it's not that difficult to, we're not changing behavior. We're just making sure that help makes sense. You know, a lot of those formatting issues really are just formatting issues. You know, if you, it's, it's possible to just make that thing that's bold right now always be capitalized the way you're asking for it just with CSS change. It's, it's, you know, those are, those are things you don't even have to like edit. No, no, you'll have to edit. There is no way to, I mean, if this is, it needs to be intelligently curated here. Yeah. You cannot use, she cannot change the linguistic structure of the sentence with CSS as far as I can. No, I'm not suggesting we change the linguistic structure of the CSS. I thought you just mentioned that your complaint was that some of them were lowercase and some were uppercase. Yeah. Some tools are lowercase and some are uppercase. So when I, I mean, these types of names that we shouldn't be touching if there is an official. That's not my complaint. I don't. Sorry. I misunderstood. I beg your pardon. My complaint is that lack of help sections. Sure. Hey, what do you think about, I know people don't read, but sometimes people leave comments. I mean, what do you think about the concept of having like a, like a, like a wiki style description that people can update? Well, there is, we can go. I mean, it's a big, it's not working that way, right? There is an endless kind of a pathway of improvement here. For example, having restructured text as they're formatting for this is not ideal. It would be much better than markdown. And I mean, there's all sorts of things that we can do. I'm just trying to be practical here. Sure. And I think one practical way to do this would be to just make an interface. And if somebody says, Hey, how do I use this tool? And then they find out and then could edit it and change it and put instructions there. I don't know. Like if they were authorized to do so. I don't know. Just trying to offer you. Well, they can do it on GitHub now. What's that? They can do it on GitHub now. They can do it. They are. I'll put it right on the interface so you can just edit it, you know? Oh. I don't know. Sounds like, sounds like something we don't want to do right now. Do we have other things? We need to be, we need to stay focused here. Well, we do render those links to the bio tools, right? So it does sort of seem bio tools captures a bunch of information about how to get help on the tool it looks like. So maybe they, that would be something to pass onto them like wiki style content. Yeah. We could also work on the examples and have a button to, I mean, we had the, what was that called again? I mean, we could use the test data to run a tool. We had this also in the user interface at one point. These are great examples, right? All these. The automatic tour. Yeah. Yeah. I think that's a web book, right? So yeah, may or may not be activated. Yeah. I mean, we could think about promoting this if you will find a way to like, tell people like what it does if that's helpful. I don't know. I think we need to do sort of incremental improvement here. We need to start going some direction with small things to start. And I think a small thing to start is just the edit the damn thing. It's just a lot of tools to edit. So that needs to be, it cannot be one person. Just to mention the second feedback that GCC training was the search capability wasn't good. Yeah. And we know that. Something unfortunate. So these were the two visual separation of tools, headers and search. But then again, if we, you know, if we tag tools and search would work much better as well. So it's all kind of a circular thing. Okay. Well, it's almost an hour. Thank you for listening to me blabbing about this. So, but I still think that whoever schedules paper cuts, let's think about this. And so how does this work exactly? Do I submit a proposal for paper cuts? Make an issue. A message Dave. A message Dave. Okay. Well, I know how to do that. You can create a GitHub issue and tag it as paper cuts. Right? I mean, the PIS can also decide that this is a priority and we have to look on an outside of paper cuts because I don't know if this is a great community project. I mean, what, it could theoretically work in the same way that you, that Maria said that PR and had the big list of tools that we had to work on with the check offs as it, as it, as we worked through it. And that's the only way I could see this as a paper cut is a single like list that someone can check off that anyone in the community can check off so we don't start overlapping. Okay. Which PR? Okay. I don't remember the name of the PR. It had, there was some massive one with, I think it was checking tools on, on anvil or something with cloud-based tools and there was a check list on it. Well, actually, so anvil is one of the reasons why we need to get, get a hold on this tool panel because for example, for anvil specifics we don't need many tools. So we need to restructure panel ability to do that. Okay. It's an hour. Thank you very much. So I'll try to follow up with this and see you in two weeks. Bye everyone.