 So, on our behalf, I want to expose you to proposal of the solution to the problem of citations infrastructure in Debian. And actually, there are three aspects of citations we have. First one is software referencing. How do we reference the software? And the papers associated with the software which describe the methods which are implemented. Usually, this is what happens with scientific software. And how do we reference actually Debian? We've been in existence for 17 years, right, and we don't have means how to reference it appropriately. There is just a, Debian Matt has from Andreas, I believe, there is BIP file which has some BIP tags references for Debian entries. But there is nothing, and that's funny. And there is miscellaneous bibliographies. So what is our current status, that visibility? Or we can have software references at the moment. We can find them only on blends. And newer Debian, because we suck it out from there, but that's where they are present and visible. But besides that, there are 434 BIP files which are distributed within Debian system. It's quite substantial amount, but they're spread all around the system. And there is one RAS file. I didn't even check either its RAS as bibliography, but at least it has that extension. And because of that, we don't have them readily available in terms that we could just have our system not to go somewhere else online, but just have the references on the system. We don't have that. And we cannot use them readily. So we cannot just, oh, let's reference this software, or that software. Or I know that these package, they work on something cool what I work on and let's just reuse their bibliography, which happens quite often, but we cannot do that. And easy solution is, oh, previous discussions. Michael brought it up two years ago, and as always, it was really productive. And just it remains at the same state besides that we have blends references. And possible solutions were discussed that we provide references file within our Debian packaging, and or either we ship BIP files under user share BIP text references, or we place that stuff in copyright because it's relevant. Although there were suggestions or ideas that it might give a little bit of wrong aftertaste that, oh, this is free software with free license, but there is for some reason there is reference and it might be in a bet. But I actually think it's quite opposite, right? That it's free and with references, it's just great, right? It doesn't give any bad feelings about it. And format, either our standard RFC 822, which is filled column, which is used in tasks files of the blends or BIP tag, which has been there for decades, right? And everybody is using it. I'm not sure, is anyone using actual RIS for doing referencing? Not just to import from the map, also, see, no one. Well, I will not even ask either, you use BIP. So, and to accomplish those ideas, it was suggested to have DH install references which put the stem in the right location. So we're suggesting something simple, but which might work, and which we somewhat done already. So there is Debin Biblography.Git repository on Git Debin. Oh, what did I put? Git on Russian.com. Sorry, it's gitdebin.org. I didn't have internet, I typed it in and I ended up with the wrong URL. So what we suggest is if there is a software which ships bibliography files, place them and use your share BIP. That's easy location, easy to remember and easy to add to BIP inputs or BIP tag. So you can just use it right there on the system and provide the reference in the copyright file, which is native location for people to look for information associated with the package, right? Can I use it or who wrote it, right? Who is responsible for it? That's where the information is and the reference there is to our kind of feeling that it's the most native place. And to have one little tiny utile, the BIP collect or whatever it will be called, but now it's called that way. So what is the content of that package at the moment? We've provided basic Debin.BIP file, which contains references. Oh, where is it? Here we go. So references to Debin. We have social contract, DFSG, constitution policy. We have little example, which uses those to construct example, just simple one, right? And this is just a start, but at least it lists basic documents we use in Debin and we can reference them in the publications we make easily because BIP file is right there, right? This is not my software. This is the BIP file, right? And there is a little to the BIP collect, which is very important because if you run it on your system, it will give you the list of just extracts all the references from copyright files in the packages you have. Also that if you adjust it slightly, which we haven't done because I didn't get there, yet you can scan the whole archive, right? All those copyright files, they're extracted, they're available. So once a day, maybe twice a day, at least for installed system with 4,000 packages, although with solid state drive it took two seconds to just extract them because it's simple job. And so you run it on the full archive and provide updated BIP file online for the system. And there we actually even diverged with MyCo in maybe either it was to ship this Debin-software.BIP within this package. So it's not there yet, but who knows? But at least it will be available online. So any blends, let's say they can just suck it out from the web and use it, right? Or anyone who is interested, they just run it and extract all the references for the software which is on their system. Or alternatively if they request for specific software which is not installed, but it just queries and goes to extracted copyright file online and just gets it from there. And then you create this tailored bibliography for your system which you create once when you start, let's say, writing publication and you're done. Later on you can just maybe there should be a function to update so which will read it in and produced out. And that's pretty much it. Yeah, so it will provide bibliography in this package which doesn't have even ITP because we wanted to discuss it first. So it will provide bibliography of Debin documents ready to use bibliography for all available software in terms after we put all that information to copyright files, of course. And initiate use of the unified location for all bibliographies which will be user share, BIP or whatever we agree upon. Because now they're all around and people to use it, they will need to. First of all, nobody sees them. And if there is a directory which lists all the bibliography files, you can easily construct some mega archive already of bibliography fees or do a search, right? So it makes things much easier. That's probably it. Yeah, question comments please. I'm not sure I get the use case. If people are going to use your tool, it doesn't matter whether it's in the copyright file or references file or whatnot because the user interface is running the tool, right? Right. If we agree that we have to have these references in either copyright file or references file, then we can tune it up to look everywhere possible. But is it necessary? That's the question. So the question is, do you want a user interface or a standard location? We have standard locations, right? It's for referencing the corresponding software. We have a copyright file for bibliographies which are associated with the software, which are often shipped with sources of the products, right? They will go into user share BIP. So if you are in the same field, you can just use it, right? Or we can provide even packages for bibliographies, right? It just occurs to me that you said that no one's doing anything yet, right? This isn't implemented yet. Everybody on ISC says you should upload it tonight. Could be done. This is already, it's cut and paste. This is running. It lacks ITP number and main page. Generally, I think we should have a buff on that tomorrow or something, and you flush it out or something. Or not. I mean, if there's further comments, but I think it's probably worthwhile to discuss this further, or just you uploaded it. It sounds really cool. Does anyone else have any thoughts? I guess I'm feeling that if we could keep it out of the copyright file because we had a good user interface, you know, it'd be finer. Is the copyright file really a benefit? Well, the benefit is that we can do it now, even before people leave the room, because the copyright file is the file where you put information, who did that, what are the terms, right? So it's somewhat native form, or native location to put things. And then in addition, it's already present on the web, right? So it can be put into, there is pending redo of the Debian website, and whoever is going to win that, he can just put references everywhere, because it's natively there. And with the machine readable copyright, you can simply add to the top-level header references and then put indented BipTec snippet. And there is nothing to invent. All you have to do is grab and done. So the advantage is simplicity, and that's the proof of concept pretty much, but it's there. There was a comment on ISE why, well, Charles Plessy is pushing for Debian metadata.yaml or whatever you pronounce it. So to store all the metadata in that file, so they're asking why not using that? Oh, first of all, this is who it is. It sucks everything from the Debian right into that database, and from copyright file, right? And it will be in the copyright file. So, of course, it's... But now, this simple tool, it will run on the system without even an internet location, you don't need any database, it just gets it from... Now, I think the idea is to, next to the control and the copyright file have a metadata file in a YAML format, which is, I don't know, what is it, XML? Do we have any package which ships it? It's like... YAML is like JSON. It's XML with different syntax. The structure's file format, not RFC, but something else, and he's pushing to have all the metadata there, so you could also put the reference there. But I'm not sure whether it's also implemented. So, yeah, as I said, I think it's just pretty much a matter of taste, and it might make sense to have a buff or something on that to, well, difficult to have it videotaped, so we'll see. Well, we could discuss this probably for hours, like should we use YAML, should we use XML, and stuff like that. No. Probably either you just go ahead, or there must be really good reasons for that. I'm just looking when there is some more commands. Having just everything in a BIP file means other tools can also access it more easily, and not filter it out of Davion Control or YAML Advantage. We will parse this for you. Well, we will parse this for UDD, no matter of taste. Yeah, that's pretty important, I guess, but I'm not sure. So apparently they already implemented in Davion Met, the YAML stuff, and they're using it in UDD. I guess that's something which should be really done, having it in the universal, what's it, universal? Ultimate Davion database. So, eventually we'll converge, right? If there's already a Davion mechanism for metadata, that'd be better than the copyright file. Well, copyright file is the source of that metadata, right? Some of the metadata. The control file is some other metadata. Right, and that's where we look for the information how to reference software or the work, right? So that, at least for us, it sounds like logical location. Maybe the one point? No. No, sorry, my fault. Go on. Let's say if you have more, maybe, records, right? Let's say for software, FSL, manual, FSL, how to. You have many of those records. That might be logical to put aside into really bibliography file or some metadata, right? But whenever you look for something now to reference something, software, you look now in copyright file just to find who is the author. And that's why reference for us, at least, it looks like really reasonable location. I agree. It's a very simple, elegant way to do it if there's no other reason to have a metadata file shipped as the Debian med people seem to be doing in YAML. Maybe there's a broader Debian need for a metadata file that would need to be addressed in policy. And if these other interests don't want to use the copyright file, now we've got metadata all over the place. Wow. So I would suggest we need to... Well, one thing I want to say, policy describes current practice. So I think somebody should implement it and then have it in policy. And yeah, please stand up. I think that what you're... I'm wondering if your worry is about the fact that the old copyright files that were not machine parsable, I agree that putting a bib tech in there would be weird. But now that we have these or we're moving to these machine parsable copyright files, it seems like that's as good a place to put it as any because there's structured fields of data in there. I mean, my initial reaction was the same as yours. Why put it in the copyright file? That seems like the wrong place to put it because you're looking for licensing information there. But now that the copyright file is extended to include other things. Or structured data. Some licenses actually... Sometimes they enforce you, right? Attribution license. And they might enforce you how you attribute the work and they might enforce you to provide the reference. Then copyright is the logical place to have it, right? Some works they don't enforce you. They just beg for it or ask for it, right? Still logical place, right? So it's just whenever they don't ask or it's not that they don't care, but it remains the logical place to have it. I think that's a good point. I mean, I also put that on the agenda for the roundtable. Sort of like, so I think we could make a five minute break and then just go on with the roundtable and maybe start with that anyway. And yeah. So thanks a lot for the presentation and see you in five to ten minutes. Thank you.