Fix typos and add language code to code blocks (#70)

bact · web-flow · commit 8e313dfc4969 · 2025-10-01T09:40:57.000+02:00
- debian.md: managment -&gt; management
- user-guide.md: ther -&gt; the

Markdown
- Fix heading levels
- Add language code to code blocks, so it can be rendered with colour highlights
* SourgeForce -&gt; SourceForge
* Fix invalid JSON
diff --git a/content/_index.md b/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"/>
diff --git a/content/crosswalk/trove.md b/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" >}}
diff --git a/content/developer-guide.md b/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.
-
diff --git a/content/tools.md b/content/tools.md
@@ -1,8 +1,8 @@
-### 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.
 
@@ -23,8 +23,7 @@ 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.
@@ -36,13 +35,9 @@ 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
-
-
diff --git a/content/user-guide.md b/content/user-guide.md
@@ -1,6 +1,5 @@
 ---
 title: user guide
-
 ---
 
 ## Generating a CodeMeta file
@@ -12,6 +11,7 @@ You can use the [codemeta-generator](https://codemeta.github.io/codemeta-generat
 A CodeMeta instance file describes the metadata associated with a software object using JSON's linked data (JSON-LD) notation.  A codemeta file can contain any of the properties described on the [CodeMeta terms page](/terms/). Most codemeta files are called `codemeta.json` by convention.
 
 Here is an example of a basic `codemeta.json` that you can put at the root of a Github repo ([link to full example](https://github.com/ropensci/codemetar/blob/master/codemeta.json)):
+
 ```json
 {
     "@context": "https://doi.org/10.5063/schema/codemeta-2.0",
@@ -27,7 +27,7 @@ Here is an example of a basic `codemeta.json` that you can put at the root of a
 
 When creating a CodeMeta document, note that they contain JSON name ("property" in linked-data), value pairs where the values can be simple values, arrays or JSON objects. A simple value is a number, string, or one the literal values *false*, *null* *true*, for example:
 
-```
+```json
 "name" : "R Interface to the DataONE REST API"
 ```
 
@@ -37,13 +37,13 @@ There must be a comma between of these key-value pairs, and no comma at the end
 
 A JSON array is surrounded by the characters `[` and `]`, and can contain multiple values separated by commas:
 
-```
+```json
 "keywords": [ "data sharing", "data repository", "DataONE" ]
 ```
 
 As with any JSON documents, you can add line breaks between values for improved quality. For example, the former key-value pair is this is equivalent to:
 
-```
+```json
 "keywords": [
     "data sharing",
     "data repository",
@@ -53,7 +53,7 @@ As with any JSON documents, you can add line breaks between values for improved
 
 All fields that accept a value of a given type accept an array of values of this type, and vice-versa. For example, a software with two licenses could have this attribute:
 
-```
+```json
 "license": [
     "https://spdx.org/licenses/GPL-3.0",
     "https://spdx.org/licenses/BSD-3-Clause"
@@ -64,7 +64,7 @@ All fields that accept a value of a given type accept an array of values of this
 
 Some properties, such as `author`, can refer to other JSON objects surrounded by curly braces and can contain other JSON values or objects, for example:
 
-```
+```json
 "author": {
     "@id": "http://orcid.org/0000-0003-0077-4738",
     "@type": "Person",
@@ -81,7 +81,7 @@ The [terms page](/terms/) indicates these node types.
 
 The "author" JSON object illustrates the use of the JSON-LD keyword "@id", which is used to associate an IRI with the JSON object.  Any such node object can be assigned an `@id`, and we may use the `@id` to refer to this same object (the person, Peter), elsewhere in the document; e.g. we can indicate the same individual is also the `maintainer` by adding:
 
-```
+```json
 "maintainer": "http://orcid.org/0000-0003-0077-4738"
 ```
 
@@ -129,7 +129,6 @@ JSON-LD operations can later *expand* this reference and *embed* the full inform
 }
 ```
 
-
 ### Nesting objects
 
 We saw before a simple (root) SoftwareSourceCode object:
@@ -205,21 +204,17 @@ because in the latter, `"https://cran.r-project.org"` is the `"url"` of `rmarkdo
 
 Every CodeMeta document must refer to the context file *codemeta.jsonld*, for example via a URL.  This indicates that all terms in the document should be interpreted in the "context" of CodeMeta.  Most terms are chosen to match the equivalent terms in <http://schema.org>, but CodeMeta provides a few additional terms not found in <http://schema.org> which may be helpful for software projects.  CodeMeta also restricts the context to use only those <https://schema.org> terms that are explicitly listed on the [terms](/terms/) page.  Users wanting to include additional terms must extend the context (see [developer-guide](/developer-guide/)).
 
-
 The context file may be modified and updated in the future, if new JSON properties are added or existing ones modified.
-The CodeMeta GitHub repository defines tags to allow specific versions of a file to be referenced, and assigns 
+The CodeMeta GitHub repository defines tags to allow specific versions of a file to be referenced, and assigns
 *digital object identifiers*, or DOIs, to each release tag. Please use the [appropriate release](https://github.com/codemeta/codemeta/releases) of the CodeMeta schema in order to refer to the
 appropriate context file, e.g.
 
-
-```
+```json
 "@context": "https://doi.org/10.5063/schema/codemeta-2.0"
 ```
 
 Release candidate versions may be referred to consistently using their git tag for the raw version, e.g. <https://raw.githubusercontent.com/codemeta/codemeta/2.0-rc/codemeta.jsonld>.  *Please do not refer to the raw GitHub URL for the master branch*, as this is subject to change and will not guarantee a stable metadata file.  
 
-
-
 ## Testing An Instance file
 
 Our [codemeta-generator](https://codemeta.github.io/codemeta-generator/) can also check a codemeta.json file you wrote is valid. To do that, copy-paste your code in the bottom box, and click "Validate codemeta.json".
