OK, thanks. Should we add a little bit to each package landing page indicating how to link?
On Tue, Jul 7, 2015 at 3:52 PM, Dan Tenenbaum <dtene...@fredhutch.org> wrote: > > > ----- Original Message ----- > > From: "Vincent Carey" <st...@channing.harvard.edu> > > To: "Martin Morgan" <mtmor...@fredhutch.org> > > Cc: "Tim Triche, Jr." <ttri...@usc.edu>, bioc-devel@r-project.org, > "Gabe Becker" <becker.g...@gene.com> > > Sent: Tuesday, July 7, 2015 12:49:24 PM > > Subject: Re: [Bioc-devel] Short URLs for packages? > > > > Has there been a solution to the short URL question? > > > > Yes: https://stat.ethz.ch/pipermail/bioc-devel/2015-April/007464.html > > Dan > > > > On Tue, Mar 24, 2015 at 7:14 AM, Martin Morgan > > <mtmor...@fredhutch.org> > > wrote: > > > > > On 03/24/2015 02:31 AM, Wolfgang Huber wrote: > > > > > >> Before we start a religious war, can we make progress on the > > >> pragmatic > > >> goal of making it possible to provide such URLs to people? > > >> > > >> There are two concepts > > >> - ‘the package' - a specific version, running in a specific > > >> environment, > > >> ‘frozen’, etc. (Gabe) > > >> - ‘the package’ - as a concept and a living artifact (me, Bernd, > > >> Tim) > > >> Both are useful. And having URLs for both would also be useful. > > >> > > > > > > 0. That's (mostly) satisfied with the current scheme and > > > > > > http://bioconductor.org/packages/3.0/bioc/html/BiocGenerics.html > > > http://bioconductor.org/packages/release/bioc/html/BiocGenerics.html > > > http://bioconductor.org/packages/devel/bioc/html/BiocGenerics.html > > > > > > (hey, no www. -- that's four letters already! Perhaps importantly, > > > there's > > > also a hard-coded version for devel, 3.1, and for past releases. So > > > as I > > > understand it the request is for (a) shorter path names and (b) > > > dynamic > > > selection of release vs. devel, mentioned below, for the <6 month > > > period > > > when the package is in devel but not yet release. Also noted is > > > Henrik's > > > earlier proposal mentioned by Sean. > > > > > > > > > 1. 'packages', 'bioc', 'html' all look somehow redundant, so > > > > > > http://bioconductor.org/release/BiocGenerics.html > > > http://bioconductor.org/devel/BiocGenerics.html > > > http://bioconductor.org/3.0/BiocGenerics.html > > > > > > but also > > > > > > http://bioconductor.org/release/BiocGenerics/ (implicit > > > index.html) > > > http://bioconductor.org/BiocGenerics/release/ > > > > > > and their devel and version counterparts would seem quite possible > > > / not > > > profoundly controversial. Landing pages for specific versions > > > 3.22.7 do > > > not currently exist, change little across package minor versions, > > > and would > > > not lead to packages installable via biocLite(), so this idea of > > > Tim's is a > > > non-starter in my opinion. > > > > > > Having the 'version' level of the path before the package provides > > > a > > > logical place to put biocViews for that release. I'd vote for one > > > of the > > > release/BiocGenerics[.html] schemes. > > > > > > > > > 2. Something like > > > > > > http://bioconductor.org/BiocGenerics > > > > > > redirecting to release when available, devel when newly added > > > (Wolfgang's > > > proposal) would in my opinion be confusing, especially since we > > > continue to > > > have so much difficulty with version mismatches in user > > > installations. I > > > don't think having a warning on redirect that 'this package is not > > > available for release' would be effective either at advertising > > > robust > > > software or at enabling use by comparatively naive users. > > > > > > > > > 3. In terms of the 'redundant' parts of the path, these are not > > > completely > > > arbitrary (not that these considerations have to dictate > > > presentation; they > > > do make one suspect that 'add a redirect and everything will be > > > fine' will > > > result in a nice plate of spaghetti, especially if there is some > > > desire to > > > retain backward compatibility). > > > > > > 'packages' separates the package repository from other aspects of > > > bioconductor.org, and group related concepts ('package', 'help', > > > etc.) at > > > a similar hierarchical level. > > > > > > 'bioc' serves to distinguish between software ('bioc/'), annotation > > > ('data/annotation') and experiment data ('data/experiment') > > > packages, and > > > these divide the overall repository into three for the purposes of > > > biocLite() / install.packages() (this conceptual distinction has > > > been > > > useful, I think). > > > > > > > biocinstallRepos() > > > BioCsoft > > > "http://bioconductor.org/packages/3.1/bioc" > > > BioCann > > > "http://bioconductor.org/packages/3.1/data/annotation" > > > BioCexp > > > "http://bioconductor.org/packages/3.1/data/experiment" > > > > > > 'html' distinguishes the landing pages from the package tar balls / > > > binary > > > distributions themselves as returned by > > > contrib.url(biocinstallRepos()), > > > and from their vignette/, man/ and news/ resources. > > > > > > > > > 4. In terms of best practices, it seems like articles are about > > > particular > > > versions and should cite the package as such, for instance if only > > > in devel > > > when the paper is being written as .../3.1/..., but that there is > > > no > > > substantive cost to also referencing 'current version available > > > [after > > > April, 2015] at .../release/.... > > > > > > > > > 5. At the end of the day I find myself casting my lot for landing > > > pages > > > with the form > > > > > > http://bioconductor.org/release/BiocGenerics/ > > > > > > which leads to a little less typing but not the dynamic resolution > > > that > > > started this (version) of the thread. > > > > > > > > > Martin > > > > > > > > > > > >> Wolfgang > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> On Mar 23, 2015, at 18:43 GMT+1, Tim Triche, Jr. > > >> <tim.tri...@gmail.com> > > >>> wrote: > > >>> > > >>> I just meant that the mnemonic link > > >>> > > >>> http://www.bioconductor.org/limma/ (SEO version of limma ;-)) > > >>> > > >>> could dump people at something like > > >>> > > >>> http://www.bioconductor.org/release/limma/3.22.7/ (I'd prefer > > >>> this) > > >>> > > >>> or if need be for backwards compatibility, > > >>> > > >>> http://www.bioconductor.org/packages/3.0/limma/3.22.7/ (seems > > >>> less > > >>> good) > > >>> > > >>> instead of > > >>> > > >>> http://www.bioconductor.org/packages/3.0/bioc/html/limma.html > > >>> (current) > > >>> > > >>> and furthermore the specific version page could note more > > >>> prominently > > >>> that > > >>> the build of limma being referenced at that particular instance > > >>> in time > > >>> may > > >>> or may not be the same as was cited in a paper, used in an > > >>> analysis, > > >>> available for download the previous evening, etc. thus > > >>> citation("limma") > > >>> is > > >>> a Very Good Idea when writing up results that depend upon it. > > >>> Because > > >>> even > > >>> the WEHI guys could theoretically have a bug that impacted > > >>> someone's > > >>> results (as opposed to the usual case of Didn't Read The Fine > > >>> Limma > > >>> Manual) > > >>> > > >>> Does that make more sense? (Probably not, but worth a try) > > >>> > > >>> Statistics is the grammar of science. > > >>> Karl Pearson > > >>> <http://en.wikipedia.org/wiki/The_Grammar_of_Science> > > >>> > > >>> On Mon, Mar 23, 2015 at 9:29 AM, Dan Tenenbaum > > >>> <dtene...@fredhutch.org> > > >>> wrote: > > >>> > > >>> > > >>>> > > >>>> On March 23, 2015 9:18:57 AM PDT, "Tim Triche, Jr." < > > >>>> tim.tri...@gmail.com> > > >>>> wrote: > > >>>> > > >>>>> > > >>>>> Packages are (read: should be, IMHO) published, citable pieces > > >>>>> of > > >>>>>> > > >>>>> research, though. Imagine if a paper you cite were silently > > >>>>> updated > > >>>>> without the doi/citation changing. That wouldn't be good > > >>>>> > > >>>>> I don't disagree, but the existing setup does nothing to > > >>>>> address that. > > >>>>> Citation('limma'), for example, does. > > >>>>> > > >>>>> .../release/... and .../devel/... can change at any time, > > >>>>> potentially > > >>>>> overnight (with or without a new BioC release). The only real > > >>>>> way to > > >>>>> cite an exact version is to cite that exact version, which is > > >>>>> already > > >>>>> the proper way to do things and would remain unaffected by > > >>>>> this, at > > >>>>> least AFAIK. > > >>>>> > > >>>>> Perhaps a useful addendum would be for the mnemonic > > >>>>> > > >>>>> http://bioconductor.org/limma > > >>>>> > > >>>>> To redirect to > > >>>>> > > >>>>> > > >>>>> > > >>>> > http://bioconductor.org/packages/limma/whateverTheMostRecentStableVersionMayBe/ > > >>>> > > >>>>> > > >>>>> And then everything is explicit. > > >>>>> > > >>>>> Does that address the competing issues discussed herein? > > >>>>> > > >>>> > > >>>> > > >>>> Note that 'release' and 'devel' are just symlinks to the current > > >>>> release > > >>>> and devel versions. I.e. currently 3.0 and 3.1 respectively. So > > >>>> you can > > >>>> always link directly to a specific version. > > >>>> > > >>>> Dan > > >>>> > > >>>> > > >>>>> Best, > > >>>>> > > >>>>> --t > > >>>>> _______________________________________________ > > >>>>> Bioc-devel@r-project.org mailing list > > >>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel > > >>>>> > > >>>> > > >>>> > > >>>> > > >>> [[alternative HTML version deleted]] > > >>> > > >>> _______________________________________________ > > >>> Bioc-devel@r-project.org mailing list > > >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel > > >>> > > >> > > >> _______________________________________________ > > >> Bioc-devel@r-project.org mailing list > > >> https://stat.ethz.ch/mailman/listinfo/bioc-devel > > >> > > >> > > > > > > -- > > > Computational Biology / Fred Hutchinson Cancer Research Center > > > 1100 Fairview Ave. N. > > > PO Box 19024 Seattle, WA 98109 > > > > > > Location: Arnold Building M1 B861 > > > Phone: (206) 667-2793 > > > > > > > > > _______________________________________________ > > > Bioc-devel@r-project.org mailing list > > > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > > > > > > [[alternative HTML version deleted]] > > > > _______________________________________________ > > Bioc-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > > [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel