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

Re: RRID -> SciCrunch



2017-10-25 20:47 GMT+03:00 Steffen Möller <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>>:
>
>
>     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>>>:
>     >
>     >     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>>>:
>     >
>     >             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>>>>:
>     >
>     >
>     >                 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
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.

We face an analogous challenge with unix manual pages. Ideally upstream is the source, but often they get written by users, packagers, etc.
 

>  
>
>     >
>     >     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
>
> "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.

The COOL URI version (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

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! :-)
 

Steffen




--
Reply to: