Re: RRID -> SciCrunch
On 26.10.17 08:26, Michael Crusoe wrote:
>
>
> 2017-10-25 20:47 GMT+03:00 Steffen Möller <steffen_moeller@gmx.de
> <mailto:steffen_moeller@gmx.de>>:
>
>
> On 25.10.17 18:52, Michael Crusoe wrote:
> >
> >
> > 2017-10-25 19:21 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>>>:
> >
> >
> > On 25.10.17 17:49, Michael Crusoe wrote:
> > >
> > >
> > > 2017-10-25 18:19 GMT+03:00 Matus Kalas <Matus.Kalas@uib.no
> <mailto:Matus.Kalas@uib.no>
> > <mailto:Matus.Kalas@uib.no <mailto:Matus.Kalas@uib.no>>
> > > <mailto:Matus.Kalas@uib.no <mailto:Matus.Kalas@uib.no>
> <mailto:Matus.Kalas@uib.no <mailto:Matus.Kalas@uib.no>>>>:
> > >
> > > On 2017-10-25 15:12, Michael Crusoe wrote:
> > >
> > > 2017-10-25 16:04 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>>
> > <mailto:steffen_moeller@gmx.de <mailto:steffen_moeller@gmx.de>
> <mailto:steffen_moeller@gmx.de <mailto: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>
> > <mailto:steffen_moeller@gmx.de
> <mailto:steffen_moeller@gmx.de>> <mailto:steffen_moeller@gmx.de
> <mailto:steffen_moeller@gmx.de>
> > <mailto:steffen_moeller@gmx.de <mailto:steffen_moeller@gmx.de>>>
> > > <mailto:steffen_moeller@gmx.de
> <mailto:steffen_moeller@gmx.de>
> > <mailto:steffen_moeller@gmx.de <mailto:steffen_moeller@gmx.de>>
> > > <mailto:steffen_moeller@gmx.de
> <mailto:steffen_moeller@gmx.de> <mailto: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?
> > >
>
> <snip>
>
>
> > > CWL tool descriptions can and should be maintained
> collectively;
> > > preferably they are offered to upstream for inclusion just
> like
> > other
> > > Debian instigated patches and manual pages are sent up.
> > I agree. And in a way this is why I find it problematic to
> statically
> > ship those wrappers when there are newer versions already
> available on
> > the CWL github. We need an update mechanism, I think, not
> only at
> > build
> > time but also for the already installed packages - but then
> again,
> > this
> > very much contradicts the concepts of a stable release. So, I
> > still need
> > to make my mind up about this all.
> >
> >
> > CWL tool descriptions will stabilize quickly enough. CWL
> executors are
> > not required to use the descriptions in /usr/share/commonwl (or any
> > other location); they merely assist users in getting started
> with the
> > software already on their system. At anytime they can write
> their own,
> > download a different one, or copy and improve the system installed
> > version.
>
> Do the CWL wrappers ship with a URL from which to download the latest
> version as part of the CWL description? Like a "this document lives
> here" line that you may refer to as an "origin" field or so?
>
> I skimmed through the CWL spec and could not find it. There was an
> issue
> https://github.com/common-workflow-language/common-workflow-language/issues/170
> <https://github.com/common-workflow-language/common-workflow-language/issues/170>
> that I interpreted as requesting the very same but I admit to have
> somewhat failed to explicitly grasp how that schema would be
> adapted for
> automated updates.
>
>
> Specific recommendations on CWL metadata have not been formalized; the
> closest is http://www.commonwl.org/user_guide/rec-practices/ but that
> hasn't gone through any peer review.
>
> Even with that, there is no "origin" like mechanism on where to look
> for updates.
I propose something as simple as "wget".
>
> We face an analogous challenge with unix manual pages. Ideally
> upstream is the source, but often they get written by users,
> packagers, etc.
The origin of a man page is supposed to be with the source tree of the
wrapped tool. The CWL wrappers may end up as part of the source tree,
too, I agree. But as of today, this is not the case and specs still
evolve, and especially for tools that are not much further developed I
see the maintenance of their CWL wrappers outside that source tree.
Maybe we can somehow formalize an update instruction in
debian/README.source, in analogy to regular patches that should be
described there.
>
>
>
> >
> >
> > >
> > > Back to the topic: I agree with Steffen that if we
> mean the link
> > > pairs as Provider + ID (as opposed to ID_type +
> ID_value), then
> > > SciCrunch makes more sense than RRID.
> >
> >
> > From https://identifiers.org/rrid/RRID:SCR_001156
> <https://identifiers.org/rrid/RRID:SCR_001156>
> >
> > "Proper citation
> >
> > khmer, RRID:SCR_001156"
> >
> > So please don't strip off RRID :-)
>
> I may be in demand of some further brainwash here. When put in a
> paper,
> the "RRID:" prefix needs to appear. But for our Debian-internal
> referencing that is in a single formal field not in a free text area,
> and not together with any other identifiers, I was even tempted to
> omit
> the "SRC_" and leading 0s :o)
>
>
> The beauty of keeping the prefix ("RRID:SCR_001156") is that search
> engines with no knowledge of our file format can still discover and
> understand this reference.
Right. I admit not to have thought about these fellas as I was not keen
on having the Debian packaging sources directly indexed by google - but
why not. And now I get (do I ?) what you are after in the first place.
But Yaml wants a blank after the colon (just confirmed with yamllint) so
we cannot have "RRID:SCR_001156" but it would need to be "RRID:
SCR_001156". So, how about having it as
- Name: SciCrunch
Entry: RRID:SCR_001156
?
>
> The COOL URI version (https://identifiers.org/rrid/RRID:SCR_001156
> <https://identifiers.org/rrid/RRID:SCR_001156>) takes it a step
> further, as it is also an endpoint to discover information about the
> resource without needing to know anything else about it
Hm. The task pages should show them. And the package trackers. And maybe
also our source tree for the resources that have a COOL URI. But I
seriously do not think that our packaging instructions should be a prime
target for search engines - they are only for us.
>
> I understand that this is a trade-off between length and utility; but
> I highly doubt anyone is typing these in manually. In fact, I hope
> they don't manually enter these due to the chance of transcription
> error! :-)
They are copy and pasted. Since the complete URI is not on the
respective pages, the constant part (that is not constantly constant)
would need to be manually prepended and I wary the inconsistencies
across many Debian packages with respect to those still cooling URIs.
>
>
>
> Steffen
>
>
>
>
> --
> 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: