[Bioc-devel] Short URLs for packages?

Vincent Carey stvjc at channing.harvard.edu
Tue Jul 7 21:49:24 CEST 2015 

Has there been a solution to the short URL question?

On Tue, Mar 24, 2015 at 7:14 AM, Martin Morgan <mtmorgan at 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.triche at 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 <dtenenba at fredhutch.org>
>>> wrote:
>>>
>>>
>>>>
>>>> On March 23, 2015 9:18:57 AM PDT, "Tim Triche, Jr." <
>>>> tim.triche at 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 at r-project.org mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>>>
>>>>
>>>>
>>>>
>>>         [[alternative HTML version deleted]]
>>>
>>> _______________________________________________
>>> Bioc-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>
>>
>> _______________________________________________
>> Bioc-devel at 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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

	[[alternative HTML version deleted]]

More information about the Bioc-devel mailing list