Merge branch 'master' into add-spdx3

Author: bact

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/trove.md

@@ -3,7 +3,6 @@ title: "Crosswalk for Trove Software Map"
 image: "/img/sourceforge.png"
 ---
 
-[Trove Software Map](https://sourceforge.net/p/easyhtml5/tracinst/Software%20Map%20and%20Trove/#what-is-trove). Trove is the system used by SourceForge.net to classify software projects.  
-
+[Trove Software Map](https://sourceforge.net/p/easyhtml5/tracinst/Software%20Map%20and%20Trove/#what-is-trove). Trove is the system used by SourceForge.net to classify software projects.
 
 {{< crosswalk name="Trove Software Map" >}}

content/developer-guide.md

@@ -7,7 +7,7 @@ methodology for creating software package descriptions. For example, this guide
 designing software to generate or read CodeMeta JSON software descriptions.
 
 Users that only require instructions for manually creating CodeMeta software descriptions may wish to
-review the upcoming [User Guide](/user-guide/). 
+review the upcoming [User Guide](/user-guide/).
 
 ## CodeMeta Overview
 
@@ -47,43 +47,46 @@ An example usage of the CodeMeta document is for the author of research software
 
 The producer of an  CodeMeta Document, i.e. the creators of the software, must use the JSON names from the CodeMeta context file. The consumer of the  CodeMeta Document can use these same JSON names from the  CodeMeta Document for any necessary processing tasks.
 
-As an alternative to using the producer supplied JSON names, the consumer can use the [JSON-LD API](https://www.w3.org/TR/json-ld-api/) to translate the JSON names to their own local JSON names that may be in use by their local processing scripts. This is done by first using the JSON-LD *expand* function that replaces each JSON name in the  CodeMeta Document with it's corresponding IRI from the CodeMeta context file. For example, the producer's  CodeMeta Document may contain the following line:
+As an alternative to using the producer supplied JSON names, the consumer can use the [JSON-LD API](https://www.w3.org/TR/json-ld-api/) to translate the JSON names to their own local JSON names that may be in use by their local processing scripts. This is done by first using the JSON-LD *expand* function that replaces each JSON name in the  CodeMeta Document with it's corresponding IRI from the CodeMeta context file. For example, the producer's CodeMeta Document may contain the following line:
 
+```json
       "codeRepository": "https://github.com/DataONEorg/rdataone"
+```
 
 Using the JSON-LD API *expand* function, this is converted to:
 
-     "http://schema.org/codeRepository": "https://github.com/DataONEorg/rdataone
+```json
+     "http://schema.org/codeRepository": "https://github.com/DataONEorg/rdataone"
+```
 
 Next, the consumer can use their own context file that maps from each IRI to their own local JSON names. For example, the consumer may have a context that maps the local JSON name 'repository' (as in `package.json` documents used by NPM, see [/crosswalk/node/]) to "http://schema.org/codeRepository", so using the JSON API *compact* function would result in a new  CodeMeta Document with the entry:
 
+```json
      "repository": "https://github.com/DataONEorg/rdataone"
+```
 
 When the CodeMeta Document has been compacted, it can then be used by the consumer for any necessary processing, using the local JSON names.
 
 Note that this expansion and compaction process assumes that both the producer and consumer JSON-LD context files share overlapping sets of IRIs.
 
-
 ## Crosswalk Table
 
 ## Tools and Integrations
 
-
 To facilitate automated ingest of research software into repositories such as [figshare](https://figshare.com/), [Zenodo](https://zenodo.org/), the [Knowledge Network for Biocomplexity](https://knb.ecoinformatics.org/) and others, these repositories will update
 their submission processes to use CodeMeta Document which will provide the metadata necessary for the submission and indexing of the software.  
 
 Tools will be created that assist in the generation of CodeMeta documents. For example, a tool written in the R language would generate a CodeMeta document from an R package that was authored to support a research project, automatically collecting available metadata and possibly prompting the user for any additional required metadata. The CodeMeta document would then be used to assist in publishing the software to a repository. An example CodeMeta document is shown in Appendix C.
 
 ## Generating Citations from a CodeMeta documents
 
- [ TBD ]
-
+[ TBD ]
 
 ## Extending the CodeMeta Context
 
-CodeMeta explicitly defines the terms it uses from <http://schema.org>, rather than merely extending <http://schema.org> with a few additional terms.  To use additional terms from <http://schema.org> not listed on the [terms page](/terms/) (or terms from any other context), you must extend your context appropriately.  For instance, to combine codemeta (v2.0-rc) with all terms available in schema.org, you would do: 
+CodeMeta explicitly defines the terms it uses from <http://schema.org>, rather than merely extending <http://schema.org> with a few additional terms.  To use additional terms from <http://schema.org> not listed on the [terms page](/terms/) (or terms from any other context), you must extend your context appropriately.  For instance, to combine codemeta (v2.0-rc) with all terms available in schema.org, you would do:
 
-```
+```json
 "@context": ["https://raw.githubusercontent.com/codemeta/codemeta/2.0-rc/codemeta.jsonld", "http://schema.org/"]
 ```
 
@@ -96,7 +99,7 @@ The intent of JSON-LD is to provide a mechanism to represent linked data using s
 For example, in the CodeMeta document, the JSON-LD "@id" keyword is used to associate an IRI with a JSON object. When the JSON-LD CodeMeta document is serialized to RDF, this becomes the graph node identifier, or the subject of the resulting RDF triple. If an @id is not specified for a JSON object, then a blank node identifier is assigned to the resulting graph node for the output RDF graph. The JSON object `role` from the example
 CodeMeta document:
 
-```
+```json
       "roleCode":[
          "originator",
          ...
@@ -105,19 +108,19 @@ CodeMeta document:
 
 is serialized to RDF as:
 
-```
+```n3
 _:b1 <https://codemeta.github.io/terms/roleCode> "originator" .
 ```
 
 When the JSON-LD "@type" keyword is applied to a simple JSON type, the serialized RDF will have that type appended to the object, for example, the following entry from the example CodeMeta document:
 
-```
+```json
 "dateCreated":"2016-05-27"
 ```
 
 is serialized to the following RDF ([N-Triples format](https://www.w3.org/TR/n-triples/)):
 
-```
+```n3
 _:b0 <http://schema.org/dateCreated> "2016-05-27"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
 ```
 
@@ -126,7 +129,7 @@ In this case, the "@type" was specified in the context file.
 When the JSON-LD "@type" is applied to a JSON object, the type information is serialized to RDF with
 an RDF type statement, for example, this JSON object from the sample CodeMeta document:
 
-```
+```json
 "author":[
   {
      "@id":"http://orcid.org/0000-0002-3957-2474",
@@ -139,10 +142,9 @@ an RDF type statement, for example, this JSON object from the sample CodeMeta do
 
 is serialized to RDF as:
 
-```
+```n3
 <http://orcid.org/0000-0002-3957-2474> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema.org/Person> .
 
 ```
 
 This example shows the "@type" keyword being used in the CodeMeta document.
-

content/jsonld.md

@@ -1,5 +1,5 @@
 ---
-title: "The Codemeta JSON-LD Representation"
+title: "The CodeMeta JSON-LD Representation"
 ---
 
 

content/terms.md

@@ -1,6 +1,5 @@
 ---
-title: Codemeta Terms
-
+title: CodeMeta Terms
 ---
 
 ## Terms from Schema.org
@@ -13,7 +12,7 @@ These terms are all recognized properties of <https://schema.org/SoftwareSourceC
 
 {{< properties-description matchParentType="schema:(Person|Thing|Review|Role)">}}
 
-## Codemeta terms
+## CodeMeta terms
 
 The CodeMeta project also introduces the following additional properties, which lack clear equivalents in <https://schema.org> but can play an important role in software metadata records covered by the CodeMeta crosswalk.
 

content/tools.md

@@ -1,10 +1,10 @@
-### Tools
+# Tools
 
 This page lists some existing tools to help with CodeMeta files
 
-#### File Generation
+## File Generation
 
- Some of the early tools still need a little updating to use the latest version of the codemeta context.
+Some of the early tools still need a little updating to use the latest version of the codemeta context.
 
 {.table .table-striped}
 
@@ -23,26 +23,21 @@ tool | language | codemeta version | maintainer | notes
 [AutoCodemeta Generator](https://w3id.org/autocodemeta) | Javascript | 3.0.0 | [dgarijo](http://github.com/dgarijo) | Optimized version of CodeMeta Generator that automatically creates a codemeta file from a given repository
 [Somef](https://github.com/KnowledgeCaptureAndDiscovery/somef) | Python | OEG developers | [dgarijo](http://github.com/dgarijo) | Tool that automatically extracts software metadata from repositories and scientific publications.
 
-#### Integrations
-
+## Integrations
 
 Integrations indicate existing platforms & services which understand CodeMeta descriptions. These do not provide a user-facing software tool for generating codemeta.json, but can ingest
 existing codemeta.json files automatically.
 
 {.table .table-striped}
 
-Name | Description |  Authors | Language | Codemeta Version
+Name | Description |  Authors | Language | CodeMeta Version
 -----|-------------|----------|----------|--------------------
 [Fidgit](https://github.com/arfon/fidgit): | An ungodly union of GitHub and Figshare | Arfon Smith, Kaitlin Thaney, Mark Hahnel | Ruby | 0.1.0
 [Software Heritage](https://docs.softwareheritage.org/devel/swh-indexer/metadata-workflow.html#adding-support-for-additional-ecosystem-specific-metadata)|The metadata indexers | SWH team | Python | 2.0
 
-
 Pending:
 
-
 - JOSS
 - Zenodo
 - DataCite
 - Figshare
-
-