This research provides comprehensive documentation of five major research software metadata standards, designed to support the development of a unified LinkML schema for CodeRepository and Software entity types.
buildInstructions - Installation/build documentationcontinuousIntegration - CI/CD pipeline URLissueTracker - Bug tracking system URLdevelopmentStatus - Per repostatus.org enumerationmaintainer - Dedicated maintenance contactsoftwareSuggestions - Optional dependenciesreferencePublication - Academic publications describing softwaremessage - Custom citation instruction textpreferred-citation - Specific citation format recommendationreferences - Works this software builds uponrepository-artifact - Package registry (PyPI, Docker Hub, etc.)commit - Git commit hash for versioncontact - Maintainer contact informationprovenanceOrigin - Where code was originally foundarchiveUrl - Location in Software Heritage archiveswhHash - Cryptographic content identifierbranches, releaseTags - VCS metadata| Category | Fields | Key Examples |
|---|---|---|
| Identification & Naming | 10 | name, description, keywords, applicationCategory |
| Versioning & Temporal | 13 | version, dateCreated, dateReleased, releaseNotes |
| Authorship & Attribution | 14 | authors, contributors, maintainers, funders |
| Technical Specifications | 13 | programmingLanguages, softwareRequirements, OS |
| Repository & Distribution | 8 | codeRepository, downloadUrl, artifactRepository |
| Build, Testing & CI/CD | 8 | buildInstructions, continuousIntegration, testFramework |
| Licensing & Rights | 5 | licenses, licenseUrl, copyrightHolder |
| Citations & References | 10 | referencePublications, preferredCitation |
| Relationships & Hierarchies | 9 | hasPart, isPartOf, hasSourceCode |
| Content & Documentation | 6 | supportingData, softwareHelp, reviewRecords |
| Specialized (SWH) | 10 | provenanceOrigin, swhHash, archiveUrl |
| Zenodo-Specific | 9 | zenodoRecordId, accessRights, relationType |
For a basic software metadata schema (11 fields):
``
name, description, url, codeRepository, version,
datePublished, authors, licenses, developmentStatus,
issueTracker, readme
For research software (24 fields):
`
[Minimal] + abstract, keywords, identifier,
programmingLanguages, softwareRequirements,
operatingSystems, runtimePlatforms, maintainers,
funders, referencePublications, buildInstructions,
continuousIntegration, applicationCategory
For archival/preservation (47+ fields):
`
[Research software] + dateCreated, dateModified,
releaseNotes, contributors, softwareSuggestions,
testFramework, buildSystem, memoryRequirements,
storageRequirements, sponsors, publisher,
copyrightHolder, hasPart, isPartOf, relatedLinks,
fileFormat, downloadUrl, artifactRepository, commit
CreativeWork (base)
├── Software (extends CreativeWork)
│ ├── SoftwareSourceCode (code + development metadata)
│ └── SoftwareApplication (packaged + distribution metadata)
├── CodeRepository (repository-specific)
└── Person, Organization (Actor classes)
`
2. Slot/Field Organization
Use shared slots for common patterns:
identifiable - identifier, sameAs, url
temporal - dateCreated, dateModified, datePublished
authored - authors, contributors, maintainers
technical - programmingLanguages, requirements, OS
3. Enumeration Patterns
Define enumerations for:
DevelopmentStatus (active, inactive, suspended, abandoned, etc.)
LicenseType (SPDX identifiers)
ProgrammingLanguage (common languages)
OperatingSystem (Windows, Linux, macOS, etc.)
CitationType (journal-article, software, dataset, etc.)
4. Nested Object Classes
Define reusable objects:
Person (with name parts, email, ORCID, affiliation)
Organization (with name, URL, ROR ID)
ComputerLanguage (name, version, URL)
SoftwareRequirement (name, version spec, URL)
Citation (flexible structure for different work types)
ScholarlyArticle (journal metadata, DOI, authors)
5. Validation & Patterns
Include patterns for:
Semantic versioning (MAJOR.MINOR.PATCH)
SPDX license expressions
ORCID URLs (https://orcid.org/XXXX-XXXX-XXXX-XXXX)
ISO date formats (YYYY-MM-DD)
URIs (HTTP/HTTPS URLs, DOIs)
6. Multi-valued Fields
Mark as multivalued:
keywords, authors, contributors, licenses
softwareRequirements, operatingSystems, references
relatedPublications, relatedLinks, relatedDatasets
Next Steps for Implementation
1. Define base classes using recommended inheritance hierarchy
2. Create common slots for shared patterns (identifiable, temporal, authored)
3. Implement Person and Organization with full contact fields
4. Build Software and CodeRepository primary classes
5. Add validation rules for versions, licenses, URLs
6. Define mapping module for cross-standard translation
7. Create serializers for CodeMeta JSON-LD and CFF YAML export
8. Build validator against standard constraints
9. Test with real software (numpy, scipy, gdal, etc.)
10. Document crosswalks between CFF ↔ CodeMeta ↔ Schema.org
Supporting Documents
Three comprehensive reference documents have been created:
1. research_software_metadata_standards.md
Complete field definitions for all 5 standards
Coverage matrix showing field availability
Examples and use cases
Interoperability recommendations
2. codemeta_field_examples.md
Full CodeMeta JSON-LD example (production-ready)
Complete CITATION.cff example
Field-by-field mappings
Object structure definitions
Conversion pathways
3. linkml_software_schema_fields.md
127 comprehensive fields organized by category
YAML-ready field definitions with sources
Object structure recommendations
Use case-specific field selections
LinkML implementation guidelines
Validation patterns
Conclusion
The five standards analyzed provide complementary perspectives on software metadata:
CodeMeta: Comprehensive, standard-aligned, developer-friendly
CFF: Human-readable, citation-focused, GitHub-native
Schema.org: Web-standard, SEO-friendly, widely adopted
Zenodo: Preservation-focused, DOI-enabled, institutional
Software Heritage: Provenance-focused, archive-optimized, immutable
A unified LinkML schema incorporating insights from all five can provide:
Completeness: 127 fields covering all metadata needs
Interoperability: Mappable to CodeMeta, CFF, Schema.org, Zenodo
Flexibility: Minimal required fields, extensive optional extensions
Validation: Strong patterns for versions, licenses, identifiers
Preservation: Provenance and archival metadata support
The recommended approach is a graduated implementation: start with essential fields (11), extend to research software standard (24), and optionally add archival/preservation fields (47+).
References & Sources
CodeMeta Project: https://codemeta.github.io/
Citation File Format: https://citation-file-format.github.io/
Schema.org: https://schema.org/SoftwareSourceCode
Zenodo: https://zenodo.org/
Software Heritage: https://softwareheritage.org/
FAIR Impact RSMD Guidelines: https://fair-impact.github.io/RSMD-guidelines/
Repostatus: http://www.repostatus.org/
SPDX Licenses: https://spdx.org/licenses/
LinkML: https://linkml.io/
Document Locations
All reference documents saved to:
`
/home/mohammadi/Documents/Claude/Projects/Infrastructure and Tooling/
├── research_software_metadata_standards.md (comprehensive standard analysis)
├── codemeta_field_examples.md (technical examples and mappings)
└── linkml_software_schema_fields.md (field inventory for implementation)