2017-10-25 20:47 GMT+03:00 Steffen Möller <[email protected]>: > > On 25.10.17 18:52, Michael Crusoe wrote: > > > > > > 2017-10-25 19:21 GMT+03:00 Steffen Möller <[email protected] > > <mailto:[email protected]>>: > > > > > > On 25.10.17 17:49, Michael Crusoe wrote: > > > > > > > > > 2017-10-25 18:19 GMT+03:00 Matus Kalas <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>>: > > > > > > On 2017-10-25 15:12, Michael Crusoe wrote: > > > > > > 2017-10-25 16:04 GMT+03:00 Steffen Möller > > > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[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]> <mailto:[email protected] > > <mailto:[email protected]>> > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[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? > > > > <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 > > -- 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
