2017-10-25 16:04 GMT+03:00 Steffen Möller <[email protected]>: > > On 25.10.17 13:47, Michael Crusoe wrote: > > > > > > 2017-10-25 14:34 GMT+03:00 Steffen Möller <[email protected] > > <mailto:[email protected]>>: > > > > > > On 25.10.17 10:56, Michael Crusoe wrote: > > > Sorry, I missed the bit where we are deprecating RRID. Can someone > > > explain? > > > > Because of https://arxiv.org/ftp/arxiv/papers/1707/1707.03659.pdf > > <https://arxiv.org/ftp/arxiv/papers/1707/1707.03659.pdf> and > > some web googling from which I gathered that the "Research Resource > > IDentifiers" are not only provided by SciCrunch. Admittedly, I fail > to > > find that page now that I want to find it :o/ > > > > > > There is no conflict here. scicrunch.org <http://scicrunch.org> is the > > post-pilot phase of what is described in that paper. > > > > > > > > Personally, I could not care less, let those catalog providers fight > > that out among themselves. However, I find that the notion of > > SciCrunch > > clearly identifies the provenance of that information, while "RRID" > to > > me is more of a concept coined by (https://www.force11.org), not a > > provider. And with several initiatives following the same purpose, I > > found that by using SciCrunch not RRID, we would be the most > > provider-neutral. And then again, it is only something local to the > > Debian packaging, not publicly visible, so nobody should truly > > care and > > the use of SciCrunch imho serves us best on a technical level. > > > > > > RRIDs share a single name space that allow for multiple providers, sci > > crunch being the current main provider for software tools and > > databases and other registries responsible for the other types. By > > referring to RRIDs generically then there is no conflict. > > > > See https://www.ebi.ac.uk/miriam/main/datatypes/MIR:00000558 for an > > overview > > > > Please rename this field to RRID, or better yet just have a list of > > URIs like we do in CWL so you don't have to care if it is a RRID, DOI > > or whatever :-) > > > > http://www.commonwl.org/v1.0/CommandLineTool.html#SoftwarePackage > > > This is what we are doing. The field is called "Registry" (not RRID, so > we can also refer to Wikis and other catalogs) and allows for an > arbitrary unordered number of (Name, Entry) tupels, in complete analogy > to the CWL, I tend to think.
Well, no. In CWL we don't separate the provider from the identifier. That's the whole point about COOL URIs. I've CC'd Stian as he explains this better than I do. > The entry named "SciCrunch", not "RRID" > (which would contradict the grouping we both outlined above), references > the SCR_nnn identifiers. For the CWL it reads "The name of the software > to be made available. If the name is common, inconsistent, or otherwise > ambiguous it should be combined with one or more identifiers in the > |specs| field." and for Debian the identifier is always given together > with a human-readable short name. This way, it needs minimal extra logic > to create the task pages and there is minimal overhead when the URL > changes (like it has done for bio.tools or hopefully will do for > OMICtools). > > Issue settled? > Not yet :-) > > Related to your comment (and very, very close to my heart) is the > question if we do everything sufficiently well to map the CWL workflows > to Debian packages. We could for instance add references to > CWL-workflow-database-entries for the workflows that a particular Debian > packages is used in, so we can test them when the package updates - er, > before the package updates in the distribution. > We are good here; you can determine the packages used in any given CWL description that includes a SoftwareRequirement that is mappable directly or indirectly to a package. For automated testing you would need a way to specify "normal" or expected results; CWL v1.0.x doesn't have that concept. A researchobject.org RO that contains/references those results with the corresponding CWL workflow would however fulfill this role. > > > > > > > > > > > The https://www.force2017.org/ starts today in Berlin which should > > gather people who know best - is anybody following this list > > attending? > > > > Steffen > > > > > > > > > > 2017-10-22 14:34 GMT+03:00 Steffen Möller > > <[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>>: > > > > > > Args, I have only now updated > > > > > > https://wiki.debian.org/UpstreamMetadata > > <https://wiki.debian.org/UpstreamMetadata> > > > <https://wiki.debian.org/UpstreamMetadata > > <https://wiki.debian.org/UpstreamMetadata>> > > > > > > to reference SciCrunch by their name. > > > > > > Many thanks and sorry > > > > > > Steffen > > > > > > On 22.10.17 12:20, Andreas Tille wrote: > > > > Hi Charles, > > > > > > > > wasn't Steffen just doing heaps of uploads with > > > > > > > > - - Name: RRID > > > > + - Name: SciCrunch > > > > > > > > As far as I understood we now are deprecating RRID. > > Should the > > > > UDD importer warn about this? > > > > > > > > Kind regards > > > > > > > > ANdreas. > > > > > > > > On Sun, Oct 22, 2017 at 08:20:50AM +0000, Charles Plessy > > wrote: > > > >> This is an automated email from the git > > hooks/post-receive script. > > > >> > > > >> plessy pushed a commit to branch master > > > >> in repository libtfbs-perl. > > > >> > > > >> commit b070d2137c24b20e577107ae6b5bda6ef78e9800 > > > >> Author: Charles Plessy <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>> > > > >> Date: Sun Oct 22 17:20:06 2017 +0900 > > > >> > > > >> Update metadata; add SciCrunch ID. > > > >> --- > > > >> debian/upstream/metadata | 8 +++++--- > > > >> 1 file changed, 5 insertions(+), 3 deletions(-) > > > >> > > > >> diff --git a/debian/upstream/metadata > > b/debian/upstream/metadata > > > >> index 5c3740b..900ee5a 100644 > > > >> --- a/debian/upstream/metadata > > > >> +++ b/debian/upstream/metadata > > > >> @@ -1,4 +1,4 @@ > > > >> -Contact: Boris.Lenhard at bccs.uib.no > > <http://bccs.uib.no> <http://bccs.uib.no> > > > >> +Contact: b.lenhard at imperial.ac.uk > > <http://imperial.ac.uk> <http://imperial.ac.uk> > > > >> Homepage: http://tfbs.genereg.net/ > > > >> Name: TFBS > > > >> Reference: > > > >> @@ -12,6 +12,8 @@ Reference: > > > >> Number: 8 > > > >> Pages: 1135-1136 > > > >> Year: 2002 > > > >> - URL: > > > > > http://bioinformatics.oxfordjournals.org/cgi/ > content/abstract/18/8/1135 > > <http://bioinformatics.oxfordjournals.org/cgi/ > content/abstract/18/8/1135> > > > > > <http://bioinformatics.oxfordjournals.org/cgi/ > content/abstract/18/8/1135 > > <http://bioinformatics.oxfordjournals.org/cgi/ > content/abstract/18/8/1135>> > > > >> + URL: > > > > > https://github.com/ComputationalRegulatoryGenomicsICL/TFBS.git > > <https://github.com/ComputationalRegulatoryGenomicsICL/TFBS.git> > > > > > <https://github.com/ComputationalRegulatoryGenomicsICL/TFBS.git > > <https://github.com/ComputationalRegulatoryGenomicsICL/TFBS.git>> > > > >> Repository: http://www.ii.uib.no/svn/lenhard/TFBS/ > > <http://www.ii.uib.no/svn/lenhard/TFBS/> > > > <http://www.ii.uib.no/svn/lenhard/TFBS/ > > <http://www.ii.uib.no/svn/lenhard/TFBS/>> > > > >> -Watch: http://tfbs.genereg.net/TFBS-(.*)\.tar\.gz > > <http://tfbs.genereg.net/TFBS-(.*)\.tar\.gz> > > > <http://tfbs.genereg.net/TFBS-(.*)\.tar\.gz > > <http://tfbs.genereg.net/TFBS-(.*)\.tar\.gz>> > > > >> +Registry: > > > >> + - Name: RRID > > > >> + Entry: SCR_015774 > > > >> > > > >> -- > > > >> Alioth's /usr/local/bin/git-commit-notice on > > > /srv/git.debian.org/git/debian-med/libtfbs-perl.git > > <http://git.debian.org/git/debian-med/libtfbs-perl.git> > > > <http://git.debian.org/git/debian-med/libtfbs-perl.git > > <http://git.debian.org/git/debian-med/libtfbs-perl.git>> > > > >> > > > >> _______________________________________________ > > > >> debian-med-commit mailing list > > > >> [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > >> > > > > > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ > debian-med-commit > > <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ > debian-med-commit> > > > <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ > debian-med-commit > > <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ > debian-med-commit>> > > > >> > > > > > > > > > > > > > > > -- > > > Michael R. Crusoe > > > Co-founder & Lead, > > > Common Workflow Language project <http://www.commonwl.org/> > > > https://impactstory.org/u/0000-0002-2961-9670 > > <https://impactstory.org/u/0000-0002-2961-9670> > > > [email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > +1 480 627 9108 <tel:%2B1%20480%20627%209108> > > > > > > > > > > -- > > Michael R. Crusoe > > Co-founder & Lead, > > Common Workflow Language project <http://www.commonwl.org/> > > https://impactstory.org/u/0000-0002-2961-9670 > > [email protected] <mailto:[email protected]> > > +1 480 627 9108 > > -- Michael R. Crusoe Co-founder & Lead, Common Workflow Language project <http://www.commonwl.org/> https://impactstory.org/u/0000-0002-2961-9670 [email protected] +1 480 627 9108
