Merge branch 'master' into patch-1

Author: bact

.github/workflows/check.yml

@@ -4,10 +4,6 @@ on:
   # Runs on pushes targeting any branch and on pull requests
   push:
   pull_request:
-  schedule:
-    # rebuild every day at 2:13 UTC, to apply any change to the crosswalk
-    # table made in https://github.com/codemeta/codemeta
-    - cron: "13 2 * * *"
 
   # Allows you to run this workflow manually from the Actions tab
   workflow_dispatch:

.github/workflows/deploy.yml

@@ -4,6 +4,10 @@ on:
   # Runs on pushes targeting the default branch
   push:
     branches: ["master"]
+  schedule:
+    # rebuild every day at 2:13 UTC, to apply any change to the crosswalk
+    # table made in https://github.com/codemeta/codemeta
+    - cron: "13 2 * * *"
 
   # Allows you to run this workflow manually from the Actions tab
   workflow_dispatch:
@@ -49,7 +53,7 @@ jobs:
             --minify \
             --baseURL "${{ steps.pages.outputs.base_url }}/"
       - name: Upload artifact
-        uses: actions/upload-pages-artifact@v1
+        uses: actions/upload-pages-artifact@v3
         with:
           path: ../website
 
@@ -63,5 +67,4 @@ jobs:
     steps:
       - name: Deploy to GitHub Pages
         id: deployment
-        uses: actions/deploy-pages@v2
-
+        uses: actions/deploy-pages@v4

README.md

@@ -1,6 +1,6 @@
 # CodeMeta Website
 
-This website is written in [Hugo](https://hugodocs.info).  Hugo is a static website engine, which is fast, popular, and easy to install and theme. See the [Hugo docs](https://hugodocs.info) for a quick orientation on how the site is organized.
+This website is written in [Hugo](https://gohugo.io/).  Hugo is a static website engine, which is fast, popular, and easy to install and theme. See the [Hugo docs](https://gohugo.io/documentation/) for a quick orientation on how the site is organized.
 
 Before building the site, you should run the `make` command, in order to download the crosswalk locally; which is used by Hugo to generate the content of crosswalk pages.
 

codemeta.json

@@ -2,7 +2,7 @@
   "@context": ["http://purl.org/codemeta/2.0", "http://schema.org"],
   "@type": "SoftwareSourceCode",
   "identifier": "codemetar",
-  "description": "The 'Codemeta' Project defines a 'JSON-LD' format for describing\n  software metadata, as detailed at <https://codemeta.github.io>. This package\n  provides utilities to generate, parse, and modify 'codemeta.jsonld' files \n  automatically for R packages, as well as tools and examples for working with\n  'codemeta' 'JSON-LD' more generally.",
+  "description": "The 'CodeMeta' Project defines a 'JSON-LD' format for describing\n  software metadata, as detailed at <https://codemeta.github.io>. This package\n  provides utilities to generate, parse, and modify 'codemeta.jsonld' files \n  automatically for R packages, as well as tools and examples for working with\n  'codemeta' 'JSON-LD' more generally.",
   "name": "codemetar: Generate CodeMeta Metadata for R Packages",
   "issueTracker": "https://github.com/ropensci/codemetar/issues",
   "license": "https://spdx.org/licenses/MIT",

content/_index.md

@@ -2,22 +2,19 @@
 title: "The CodeMeta Project"
 ---
 
-
 ## Motivation
 
 Research relies heavily on scientific software, and a large and growing fraction of researchers are engaged in developing software as part of their own research ([Hannay et al 2009](https://doi.org/10.1109/SECSE.2009.5069155 "How do scientists develop and use scientific software?")). Despite this, _infrastructure to  support the preservation, discovery, reuse, and attribution of software_ lags substantially behind that of other research products such as journal  articles and research data. This lag is driven not so much by a lack of  technology as it is by a lack of unity: existing mechanisms to archive,  document, index, share, discover, and cite software contributions are heterogeneous among both disciplines and archives and rarely meet best practices ([Howison 2015](https://doi.org/10.1002/asi.23538 "Software in the scientific literature: Problems with seeing, finding, and using software mentioned in the biology literature")).  Fortunately, a rapidly growing movement to improve preservation, discovery, reuse and attribution of academic software is now underway: a recent [NIH report](http://softwarediscoveryindex.org), conferences and working groups of [FORCE11](https://www.force11.org/), [WSSSPE](http://wssspe.researchcomputing.org.uk/) & [Software Sustainability Institute](http://www.software.ac.uk/), and the rising adoption of repositories like [GitHub](https://github.com), [Zenodo](https://zenodo.org), [figshare](https://figshare.com) & [DataONE](https://www.dataone.org) by academic software developers. Now is the time to improve how these resources can talk to each other.  
 
-
 ## What can software metadata do for you?
 
 What metadata you want from software is determined by your use case.  If your primary concerns are credit for academic software, then you're most interested in _citation_ metadata.  If you're trying to replicate some analysis, you worry more about versions and dependencies than about authors and titles.  And if you seek to discover software you don't already know about that is suitable for a particular task, well then you are interested more in keywords and descriptions. Frequently, developers of scientific software, repositories that host that software, and users themselves are interested in more than one of these objectives, and others besides.
 
 Different software repositories, software languages and scientific domains denote this information in different ways, which makes it difficult or impossible for tools to work across these different sources without losing valuable information along the way.  For instance, a fantastic collaboration between GitHub and figshare provides researchers a way to import software on the former into the persistent archive of the latter, getting a permanent identifier, a DOI in the process.  To assign a DOI, figshare must then pass metadata about the object to DataCite, the central DOI provider for all repositories.  While this makes DataCite a powerful aggregator, the lack of a crosswalk table means that much valuable metadata is currently lost along the way, such as the original software license, platform, and so forth. Any tool or approach working across software repositories faces similar challenges without a crosswalk table to translate between these.
 
-
 For more detail, [visit the project on GitHub](https://github.com/codemeta/codemeta) or check back here soon.
 
-#### Special thanks to our supporters
+## Special thanks to our supporters
 
 <img width="50px"  src="/img/nsf.jpg"/>
 <img width="50px"  src="/img/datacite.png"/>

content/crosswalk/cargo.md

@@ -0,0 +1,13 @@
+---
+title: "Crosswalk for Rust Package Manager"
+image: "/img/cargo.png"
+date: "2020-03-05"
+---
+
+[Cargo](https://doc.rust-lang.org/cargo/) is the Rust package manager.
+
+The `Cargo.toml` file for each package is called its manifest. Cargo uses the metadata in the manifest to download Rust package’s dependencies, compile packages, make distributable packages, and upload them to crates.io, the Rust community’s package registry.
+
+The manifest format is described in [the Cargo Book](https://doc.rust-lang.org/cargo/reference/manifest.html).
+
+{{< crosswalk name="Rust Package Manager" >}}

content/crosswalk/dcat-2.md

@@ -0,0 +1,15 @@
+---
+title: "Crosswalk for DCAT 2 vocabulary"
+image: "/img/w3c.png"
+date: "2019-04-23"
+---
+
+Data Catalog Vocabulary (DCAT) is an RDF vocabulary designed to facilitate interoperability between data catalogs published on the Web.
+
+[DCAT 2](https://www.w3.org/TR/vocab-dcat-2/) is superseded by DCAT 3,
+but DCAT 3 does not make DCAT 2 obsolete.
+DCAT 3 terms preserve backward compatibility with DCAT 2.
+
+{{< crosswalk name="DCAT-2" >}}
+
+See crosswalk for [DCAT 3](dcat-3).

content/crosswalk/dcat-3.md

@@ -0,0 +1,15 @@
+---
+title: "Crosswalk for DCAT 3 vocabulary"
+image: "/img/w3c.png"
+date: "2025-04-24"
+---
+
+Data Catalog Vocabulary (DCAT) is an RDF vocabulary designed to facilitate interoperability between data catalogs published on the Web.
+
+[DCAT 3](https://www.w3.org/TR/vocab-dcat-3/) is a W3C Recommendation.
+DCAT 3 supersedes DCAT 2, but DCAT 3 does not make DCAT 2 obsolete.
+DCAT 3 terms preserve backward compatibility with DCAT 2.
+
+{{< crosswalk name="DCAT-3" >}}
+
+See crosswalk for [DCAT 2](dcat-2).

content/crosswalk/debian.md

@@ -5,6 +5,6 @@ date: "2017-06-01"
 
 ---
 
-The [Debian package system](https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_archive_meta_data) defines archive metadata that is used by the popular `apt` package managment system on Debian and Ubuntu Linux distributions.  
+The [Debian package system](https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_archive_meta_data) defines archive metadata that is used by the popular `apt` package management system on Debian and Ubuntu Linux distributions.  
 
 {{< crosswalk name="Debian Package" >}}

content/crosswalk/publiccode.md

@@ -0,0 +1,10 @@
+---
+title: "Crosswalk for publiccode.yml"
+image: "/img/publiccode.png"
+date: "2025-08-10"
+
+---
+
+The [publiccode.yml](https://github.com/publiccodeyml/publiccode.yml) spec defines metadata for public sector OSS software projects, used by national and international catalogs to index, present, and facilitate the reuse of open source software developed by or for public administrations.
+
+{{< crosswalk name="publiccode" >}}