CRAN and Bioconductor URLs

[maelle]

Would it make sense to add CRAN (canonical of course) URLs to

• software requirements (unless the requirements is a GitHub version?)

• the relatedLinks of the package itself?

[cboettig]

Good question. Somewhat related to #82. Including both in relatedLinks seems like a good start at least.

Might be worth considering making the CRAN canonical url http://schema.org/sameAs the @id DOI, provided these really are identical? likewise, could use the CRAN url in software requirements in @id as the 'official' identifier for said package. Otherwise, at least including it in url sounds good.

👍

[maelle]

Reg. softwareRequirements should e.g.

    {
      "@type": "SoftwareApplication",
      "identifier": "testthat",
      "name": "testthat",
      "provider": {
        "@id": "https://cran.r-project.org",
        "@type": "Organization",
        "name": "Central R Archive Network (CRAN)",
        "url": "https://cran.r-project.org"
      }
    }

become

    {
      "@type": "SoftwareApplication",
      "identifier": "testthat",
      "sameAs": "https://CRAN.R-project.org/package=testthat",
      "name": "testthat",
      "provider": {
        "@id": "https://cran.r-project.org",
        "@type": "Organization",
        "name": "Central R Archive Network (CRAN)",
        "url": "https://cran.r-project.org"
      }
    }

[maelle]

Note to self: only add relatedLink depending on a badge in README (CRAN or BioConductor)

[maelle]

Example of a README with a BioConductor badge https://github.com/theislab/destiny

I can't think of another way than README badges to make sure a package is the one that's on CRAN/BioConductor. Without this check one could create an EML package that has nothing to do with ropensci/EML and the relatedLink would be the CRAN page of EML. Quite unlikely (if you're aware of codemeta probably you're aware of name availability issues) but still.

[maelle]

When creating a codemeta for an installed package currently there won't be a provider link as relatedLink because I'm not sure how to assess the origin of the installed package (in the absence of a README, although of course one could try and find the README... although there must be a better way to assess where an installed package comes from)

[maelle]

Probably using Repository: CRAN from DESCRIPTION 🤔

[maelle]

if the package comes from BioConductor not sure it's always in a biocViews, in any case looking at DESCRIPTION from EBImage I don't see a Repository field

[maelle]

Too bad https://github.com/r-lib/sessioninfo/blob/fbefa94ec62153844d26f95b0427957a0a2b33c3/R/package-info.R#L71 isn't exported but that's what I should use to check the provider.

[maelle]

Ok so I think it works as expected now for creating a codemeta.json for a string.

library("codemetar")

# installed from CRAN
create_codemeta("usethis", verbose = FALSE)$relatedLink
#> [1] "https://CRAN.R-project.org/package=usethis"

# installed from CRAN
create_codemeta(find.package("ggplot2"), verbose = FALSE)$relatedLink
#> [1] "http://ggplot2.tidyverse.org"              
#> [2] "https://CRAN.R-project.org/package=ggplot2"

# installed from GitHub 
create_codemeta("desc", verbose = FALSE)$relatedLink
#> [1] "https://github.com/r-lib/desc/commit/387b732"

# installed from BioConductor
create_codemeta("EBImage", verbose = FALSE)$relatedLink
#> [1] "https://bioconductor.org/packages/release/bioc/html/EBImage.html"

# installed locally
create_codemeta("codemetar", verbose = FALSE)$relatedLink
#> [1] "https://codemeta.github.io/codemetar"

Created on 2018-04-23 by the reprex package (v0.2.0).

Actually in the case of a package installed locally for which one creates a codemeta.json as above, one could argue it'd make sense to use sameAs instead of relatedLink? 🤔