[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RRID -> SciCrunch (Was: [libtfbs-perl] 01/01: Update metadata; add SciCrunch ID.)





2017-10-25 16:04 GMT+03:00 Steffen Möller <steffen_moeller@gmx.de>:

On 25.10.17 13:47, Michael Crusoe wrote:
>
>
> 2017-10-25 14:34 GMT+03:00 Steffen Möller <steffen_moeller@gmx.de
> <mailto:steffen_moeller@gmx.de>>:
>
>
>     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
>     <steffen_moeller@gmx.de <mailto:steffen_moeller@gmx.de>
>     > <mailto:steffen_moeller@gmx.de <mailto:steffen_moeller@gmx.de>>>:
>     >
>     >     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 <plessy@debian.org
>     <mailto:plessy@debian.org>
>     >     <mailto:plessy@debian.org <mailto:plessy@debian.org>>>
>     >     >> 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
>     >     >> debian-med-commit@lists.alioth.debian.org
>     <mailto:debian-med-commit@lists.alioth.debian.org>
>     >     <mailto:debian-med-commit@lists.alioth.debian.org
>     <mailto:debian-med-commit@lists.alioth.debian.org>>
>     >     >>
>     >   
>      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>
>     > mrc@commonwl.org <mailto:mrc@commonwl.org>
>     <mailto:mrc@commonwl.org <mailto:mrc@commonwl.org>>
>     > +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
> mrc@commonwl.org <mailto:mrc@commonwl.org>
> +1 480 627 9108




--

Reply to: