diff --git a/.github/styles/Vocab/EVES/accept.txt b/.github/styles/Vocab/EVES/accept.txt index b0678ea..2c71ec1 100644 --- a/.github/styles/Vocab/EVES/accept.txt +++ b/.github/styles/Vocab/EVES/accept.txt @@ -29,3 +29,4 @@ DPoP SPARQL SSI Catena-X +e\.V\. diff --git a/.github/workflows/link_checker.yml b/.github/workflows/link_checker.yml index 566f30f..bfd5d8f 100644 --- a/.github/workflows/link_checker.yml +++ b/.github/workflows/link_checker.yml @@ -24,7 +24,7 @@ jobs: restore-keys: lychee-cache- - name: Check links - uses: lycheeverse/lychee-action@f81112d0d2814ded911bd23e3beaa9dda9f8ca55 # v2.3.0 + uses: lycheeverse/lychee-action@8646ba30535128ac92d33dfc9133794bfdd9b411 # v2.8.0 with: args: >- --cache diff --git a/.github/workflows/markdown_linter.yml b/.github/workflows/markdown_linter.yml index 7f66ba3..f9a1236 100644 --- a/.github/workflows/markdown_linter.yml +++ b/.github/workflows/markdown_linter.yml @@ -15,7 +15,7 @@ jobs: uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2 - name: Run markdownlint - uses: DavidAnson/markdownlint-cli2-action@db4f21d957a58a0515c3e6b0fb16b2a13e97a1e6 # v19.1.0 + uses: DavidAnson/markdownlint-cli2-action@ce4853d43830c74c1753b39f3cf40f71c2031eb9 # v23.0.0 with: config: .markdownlint.json globs: "**/*.md" diff --git a/.lycheeignore b/.lycheeignore new file mode 100644 index 0000000..c5746a7 --- /dev/null +++ b/.lycheeignore @@ -0,0 +1,10 @@ +# Forward references to EVES specs not yet written +EVES-009/eves-009.md + +# Placeholder/example URLs used in spec text (not real endpoints) +https://assets.envited-x.net/ +https://metadata.envited-x.net/ +https://ipfs.envited-x.net/ + +# GitLab blocks automated requests with 403 +https://gitlab.com/tezos/tzip/ diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index 70cfc98..c6309f6 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -15,9 +15,17 @@ repos: - id: markdownlint args: ["--config", ".markdownlint.json"] - - repo: https://github.com/pre-commit/mirrors-prettier - rev: v4.0.0-alpha.8 + - repo: local hooks: - id: prettier + name: prettier + entry: npx prettier --write --ignore-path .prettierignore + language: system types_or: [markdown, json, yaml] - args: ["--prose-wrap", "preserve"] + + - repo: https://github.com/errata-ai/vale + rev: v3.9.6 + hooks: + - id: vale + args: ["--no-exit"] + types: [markdown] diff --git a/.prettierignore b/.prettierignore index 9014560..2cec42d 100644 --- a/.prettierignore +++ b/.prettierignore @@ -1,5 +1,6 @@ node_modules/ EVES/EVES-003/example/ EVES/EVES-003/tzip21-schemas/ +EVES/EVES-003/erc721-schemas/ .github/styles/ *.zip diff --git a/.vale.ini b/.vale.ini index 7cf1e7b..28fa30a 100644 --- a/.vale.ini +++ b/.vale.ini @@ -10,3 +10,15 @@ BasedOnStyles = Vale, Google, proselint, write-good Google.Acronyms = NO Google.We = NO Vale.Spelling = NO +# EVES specs quote field names like "name", "tags" β€” comma placement doesn't apply +Google.Quotes = NO +# NOTE/TODO in blockquotes is standard RFC/spec style +proselint.Annotations = NO +# EVES uses spaced em-dashes (` β€” `) consistently +Google.EmDash = NO +# Filenames contain "..." which is not prose typography +proselint.Typography = NO +# "e.V." is the German legal abbreviation (eingetragener Verein) +Google.Spacing = NO +# Occasional emphasis is acceptable in specs +Google.Exclamation = NO diff --git a/CLAUDE.md b/CLAUDE.md new file mode 100644 index 0000000..234f017 --- /dev/null +++ b/CLAUDE.md @@ -0,0 +1,61 @@ +# CLAUDE.md + +## Project overview + +EVES (ENVITED-X Verifiable Ecosystem Specifications) defines standards for the ENVITED-X Data Space. +Each specification lives in `EVES/EVES-NNN/eves-nnn.md` with associated examples, schemas, and assets. + +## Setup + +```sh +npm install +pre-commit install +``` + +## Quality checks + +Before every commit, run: + +```sh +make lint # markdownlint + frontmatter validation +make format-check # Prettier formatting +``` + +Pre-commit hooks enforce: trailing whitespace, end-of-file newlines, valid YAML/JSON, no merge conflicts, markdownlint, and Prettier formatting. + +CI additionally runs Vale prose linting (`spelling_linter.yml`) and link checking (`link_checker.yml`). + +### Vale prose lint rules + +The project uses Vale with Google, proselint, and write-good styles (see `.vale.ini`). +Several rules are disabled because they conflict with technical specification conventions (see comments in `.vale.ini`). + +Key active rule that causes CI failures: + +- Use "for example" instead of "e.g." or "i.e." (`Google.Latin`) + +To run Vale locally: install [Vale](https://vale.sh/docs/install), then `vale sync && vale EVES/`. + +### Markdown lint rules + +See `.markdownlint.json`. Maximum line length is 300 characters (tables and code blocks are exempt). +HTML elements ``, `
`, ``, `` are allowed. + +## File conventions + +- Specification documents use YAML frontmatter with fields: `eves-identifier`, `title`, `author`, `status`, `type`, `created`, `requires`, `replaces` +- JSON schemas go in `eves-nnn-schemas/` directories (excluded from Prettier in `.prettierignore`) +- Example files go in `example/` directories (excluded from Prettier in `.prettierignore`) +- Commit messages follow [Conventional Commits](https://www.conventionalcommits.org/) with scope: `feat(EVES-003): ...`, `fix(ci): ...` +- Branches follow `feat/eves-nnn-description` naming + +## Ontology references + +The ENVITED-X ontologies are maintained in [ontology-management-base](https://github.com/ASCS-eV/ontology-management-base). +Current versions: `envited-x/v3/`, `manifest/v5/`, `hdmap/v6/`. + +The Gaia-X ontology follows the Loire (25.11) release. Key naming: + +- `envited-x:ResourceDescription` (subclass of `gx:VirtualResource`) carries the GX compliance metadata +- `gx:name`, `gx:description` are used in the `envited-x:ResourceDescriptionShape` SHACL +- `gx:license`, `gx:copyrightOwnedBy`, `gx:resourcePolicy` remain GX-native properties diff --git a/EVES/EVES-001/eves-001.md b/EVES/EVES-001/eves-001.md index 98a8d41..bc9abc3 100644 --- a/EVES/EVES-001/eves-001.md +++ b/EVES/EVES-001/eves-001.md @@ -64,7 +64,7 @@ Each EVES must pass through the following stages: - **Future Changes**: Only changes designated as a minor editorial update by Editors are allowed in this stage. 5. **Deferred/Rejected** - - **Deferred**: The EVES is paused for future discussion (e.g., lack of resources, overshadowed by another proposal). + - **Deferred**: The EVES is paused for future discussion (for example, lack of resources, overshadowed by another proposal). - **Rejected**: Consensus cannot be reached, or the specification is fundamentally misaligned with ENVITED-X goals. 6. **Superseded** @@ -85,20 +85,20 @@ Each EVES must pass through the following stages: ### 2. EVES Numbering - EVES documents follow sequential numbering, starting from EVES-001, EVES-002, and so on. -- Numbers must be unique and stable once assigned (i.e., no recycling of identifiers). +- Numbers must be unique and stable once assigned (that is, no recycling of identifiers). ### 3. EVES Types Each EVES must declare one of the following **type** fields in its YAML header: 1. **Standards** - - Defines technical specifications or protocols recommended for ecosystem adoption (e.g., data formats, APIs). + - Defines technical specifications or protocols recommended for ecosystem adoption (for example, data formats, APIs). 2. **Informational** - Provides context, best practices, or reference material without strict normative requirements. 3. **Process** - - Outlines procedural or governance rules applicable to the ENVITED community (e.g., this EVES-001). + - Outlines procedural or governance rules applicable to the ENVITED community (for example, this EVES-001). ### 4. Roles and Responsibilities @@ -121,7 +121,7 @@ Each EVES must declare one of the following **type** fields in its YAML header: - A subset of EVES Editors with voting rights as full ASCS e.V. ENVITED members. - Provide the final decision on moving an EVES from Candidate to Final. -- Must meet quorum requirements (e.g., at least two Approvers) to grant or deny Final status. +- Must meet quorum requirements (for example, at least two Approvers) to grant or deny Final status. ### 4.5 Conflict Resolution diff --git a/EVES/EVES-002/eves-002.md b/EVES/EVES-002/eves-002.md index eef6537..70d90e9 100644 --- a/EVES/EVES-002/eves-002.md +++ b/EVES/EVES-002/eves-002.md @@ -36,10 +36,10 @@ The ENVITED-X Data Space is built on the following core modules: - **Purpose**: - Establish trust by verifying user and organization identities. - - Enable permission management (e.g., membership validation, terms of service acceptance). + - Enable permission management (for example, membership validation, terms of service acceptance). - **Key Features**: - Credentials are issued via [SimpulseID](https://identity.ascs.digital) and stored in W3C-compliant wallets like [Altme](https://altme.io). - - Future support for contract-based credentials (e.g., purchase or download permissions). + - Future support for contract-based credentials (for example, purchase or download permissions). - **Standards**: - Gaia-X Trust Framework. - W3C Verifiable Credentials and DIDs. @@ -52,7 +52,7 @@ The ENVITED-X Data Space is built on the following core modules: - Enable real-time credential checks during system interactions. - **Functionality**: - Tracks the **uuid** of credentials to ensure privacy. - - Manages credential statuses (e.g., active/inactive for revocation). + - Manages credential statuses (for example, active/inactive for revocation). - **Use Cases**: - Credential validation during login. - Whitelisting users for minting and accessing assets. @@ -99,11 +99,11 @@ The interaction between modules can be summarized as follows: 1. **Credential Issuance**: - A user or organization requests a credential via SimpulseID following the process in EVES-008. - Credential metadata includes identity, permissions, and additional attributes. - - Credential is stored in a wallet (e.g., Altme) and referenced by uuid in the registry contract. + - Credential is stored in a wallet (for example, Altme) and referenced by uuid in the registry contract. 2. **Login and Validation**: - User logs in to ENVITED-X. - - The system validates the credential (e.g., membership status) via the registry contract. + - The system validates the credential (for example, membership status) via the registry contract. 3. **Asset Registration**: - User uploads simulation assets to ENVITED-X following the process in EVES-003. @@ -142,7 +142,7 @@ Future EVES will provide detailed specifications for each module. 1. [SimpulseID](https://identity.ascs.digital) 2. [Altme Wallet](https://altme.io) -3. [Tezos FA2.1 Standard](https://gitlab.com/tzip/tzip/-/blob/master/proposals/tzip-21/tzip-21.md) +3. [Tezos FA2.1 Standard](https://gitlab.com/tezos/tzip/-/blob/master/proposals/tzip-21/tzip-21.md) 4. [Etherlink Bridge](https://www.etherlinkbridge.com/bridge) 5. [EVES-003: ENVITED Asset Definition and Upload Process](../EVES-003/eves-003.md) 6. [Gaia-X Trust Framework](https://docs.gaia-x.eu/policy-rules-committee/compliance-document/24.11/) diff --git a/EVES/EVES-003/erc721-schemas/erc721_token_metadata-schema.json b/EVES/EVES-003/erc721-schemas/erc721_token_metadata-schema.json new file mode 100644 index 0000000..b0bb876 --- /dev/null +++ b/EVES/EVES-003/erc721-schemas/erc721_token_metadata-schema.json @@ -0,0 +1,209 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "$ref": "#/definitions/asset", + "title": "ERC-721 Token Metadata", + "definitions": { + "asset": { + "type": "object", + "additionalProperties": true, + "required": [ + "name", + "image" + ], + "properties": { + "name": { + "type": "string", + "description": "Identifies the asset to which this NFT represents." + }, + "description": { + "type": "string", + "description": "Describes the asset to which this NFT represents." + }, + "image": { + "type": "string", + "format": "uri-reference", + "description": "A URI pointing to a resource with mime type image/* representing the asset. Maps to TZIP-21 displayUri." + }, + "animation_url": { + "type": "string", + "format": "uri-reference", + "description": "A URI pointing to the actual asset content (e.g. asset.zip download URL). Maps to TZIP-21 artifactUri." + }, + "external_url": { + "type": "string", + "format": "uri-reference", + "description": "A URI pointing to an external page with additional information about the asset (e.g. domain metadata on IPFS). Maps to TZIP-21 externalUri." + }, + "background_color": { + "type": "string", + "pattern": "^[0-9a-fA-F]{6}$", + "description": "Background color of the item on OpenSea. Must be a six-character hexadecimal without a pre-pended #." + }, + "minter": { + "type": "string", + "description": "The DID of the LegalEntity (OrganizationParticipant) responsible for minting the asset, as defined in EVES-008 (e.g. did:ethr::
). EVES extension." + }, + "creators": { + "type": "array", + "description": "The primary person, people, or organization(s) responsible for creating the intellectual content of the asset.", + "uniqueItems": true, + "items": { + "type": "string" + } + }, + "contributors": { + "type": "array", + "description": "The person, people, or organization(s) that have made substantial creative contributions to the asset.", + "uniqueItems": true, + "items": { + "type": "string" + } + }, + "publishers": { + "type": "array", + "description": "The person, people, or organization(s) primarily responsible for distributing or making the asset available to others in its present form.", + "uniqueItems": true, + "items": { + "type": "string" + } + }, + "date": { + "type": "string", + "format": "date-time", + "description": "A date associated with the creation or availability of the asset." + }, + "type": { + "type": "string", + "description": "A broad definition of the type of content of the asset." + }, + "language": { + "type": "string", + "description": "The language of the intellectual content of the asset as defined in RFC 1766. EVES extension." + }, + "rights": { + "type": "string", + "description": "A statement about the asset rights, e.g. an SPDX license identifier." + }, + "rights_uri": { + "type": "string", + "format": "uri-reference", + "description": "Links to a statement of rights (e.g. full license text or smart contract DID). Maps to TZIP-21 rightsUri. EVES extension." + }, + "identifier": { + "type": "string", + "description": "A string or number used to uniquely identify the asset. Ex. URL, URN, UUID, ISBN, DID, etc." + }, + "formats": { + "type": "array", + "items": { + "$ref": "#/definitions/format" + } + }, + "attributes": { + "type": "array", + "items": { + "$ref": "#/definitions/attribute" + }, + "description": "OpenSea-style attributes describing traits of the asset." + } + } + }, + "format": { + "type": "object", + "additionalProperties": false, + "properties": { + "uri": { + "type": "string", + "format": "uri-reference", + "description": "A URI to the asset represented in this format." + }, + "hash": { + "type": "string", + "description": "A checksum hash of the content of the asset in this format." + }, + "mimeType": { + "type": "string", + "description": "Media (MIME) type of the format." + }, + "fileSize": { + "type": "integer", + "description": "Size in bytes of the content of the asset in this format." + }, + "fileName": { + "type": "string", + "description": "Filename for the asset in this format. For display purposes." + }, + "duration": { + "type": "string", + "format": "time", + "description": "Time duration of the content of the asset in this format." + }, + "dimensions": { + "$ref": "#/definitions/dimensions", + "description": "Dimensions of the content of the asset in this format." + }, + "dataRate": { + "$ref": "#/definitions/dataRate", + "description": "Data rate which the content of the asset in this format was captured at." + } + } + }, + "attribute": { + "type": "object", + "additionalProperties": false, + "properties": { + "trait_type": { + "type": "string", + "description": "Name of the trait." + }, + "value": { + "description": "Value of the trait.", + "oneOf": [ + { "type": "string" }, + { "type": "number" } + ] + }, + "display_type": { + "type": "string", + "description": "Display type hint for the trait (e.g. number, boost_percentage, boost_number, date)." + } + }, + "required": [ + "trait_type", + "value" + ] + }, + "dataRate": { + "type": "object", + "additionalProperties": false, + "properties": { + "value": { + "type": "integer" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "value" + ] + }, + "dimensions": { + "type": "object", + "additionalProperties": false, + "properties": { + "value": { + "type": "string" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "value" + ] + } + } +} diff --git a/EVES/EVES-003/eves-003.md b/EVES/EVES-003/eves-003.md index ec63216..02779df 100644 --- a/EVES/EVES-003/eves-003.md +++ b/EVES/EVES-003/eves-003.md @@ -6,14 +6,15 @@ discussions-to: https://github.com/ASCS-eV/EVES/issues/4 status: Review type: Standards created: 2024-11-19 -requires: ["EVES-001"] +requires: ["EVES-001", "EVES-007", "EVES-008"] replaces: None --- ## Abstract This specification defines the structure of an asset in the ENVITED-X Data Space and outlines the process for uploading assets to ensure compliance, security, and interoperability. -It leverages existing specifications, such as the Gaia-X Trust Framework, the Gaia-X 4 PLC-AAD Ontologies, and implements privacy layers, validation, and metadata mapping aligned with [Tezos TZIP-21](https://docs.tezos.com/architecture/governance/improvement-process#tzip-21-rich-contract-metadata). +It leverages existing specifications, such as the Gaia-X Trust Framework, the ENVITED-X Ontologies, and implements privacy layers, validation, and metadata mapping aligned with +[Tezos TZIP-21](https://docs.tezos.com/architecture/governance/improvement-process#tzip-21-rich-contract-metadata) and [ERC-721][26] token metadata following the [OpenSea Metadata Standards][23]. ## Motivation @@ -30,10 +31,10 @@ This EVES addresses the need for clear guidelines to onboard assets and synchron ### 1. Digital Asset Definition The `envited-x:SimulationAsset` defines a digital asset within the domain of simulation including the core simulation data and all necessary files for describing, evaluating, and visualizing the dataset. -All simulation assets MUST be derived from a common `envited-x` ontology defined in the [Gaia-X 4 PLC-AAD Ontology Management Base][1]. -A data space portal SHALL display the currently supported version of the ontologies like e.g.: `https://ontologies.envited-x.net/envited-x/v2/ontology#`. +All simulation assets MUST be derived from a common `envited-x` ontology defined in the [ASCS Ontology Management Base][1]. +A data space portal SHALL display the currently supported version of the ontologies such as: `https://w3id.org/ascs-ev/envited-x/envited-x/v3/`. Each simulation asset SHALL be compliant with the [Gaia-X Ontology and SHACL shapes 2210][2]. -The `gx` turtle shacle shapes are derived from the [Gaia-X Trust Framework Schema][3] and the respective application/ld+json [Gaia-X Trust Framework Shapes][4]. +The `gx` turtle SHACL shapes are derived from the [Gaia-X Trust Framework Schema][3] and the respective application/ld+json [Gaia-X Trust Framework Shapes][4]. A [GaiaX Compliant Claims Example][5] MAY be generated using the [GaiaX 4 PLC-AAD Claim Compliance Provider][6]. The example implementation in the πŸ“ `example/` folder is based on release v0.2.3 of the [ASCS HD-Map Asset Example][7]. @@ -54,15 +55,15 @@ Tooling such as the [ENVITED-X Simulation Asset Tools][20] MAY automate the crea Every `asset.zip` MUST contain the following top-level folders mapped to `envited-x` artifact categories: -| Folder | `envited-x` Category | Required | `envited-x` Access Role | Description | -| --------------------- | ------------------------------ | ----------- | ----------------------- | ----------------------------------------------- | -| `simulation-data/` | `envited-x:isSimulationData` | MUST | `envited-x:isOwner` | Core simulation data (e.g., `.xodr`, `.xosc`) | -| `documentation/` | `envited-x:isDocumentation` | MUST | `envited-x:isPublic` | Documentation files (e.g., `.pdf`, `.txt`) | -| `metadata/` | `envited-x:isMetadata` | MUST | `envited-x:isPublic` | Domain metadata (e.g., `hdmap_instance.json`) | -| `media/` | `envited-x:isMedia` | MUST | `envited-x:isPublic` | Visualizations, images, GeoJSON, 3D previews | -| `validation-reports/` | `envited-x:isValidationReport` | RECOMMENDED | `envited-x:isPublic` | Quality checker reports (e.g., `.xqar`, `.txt`) | -| _(root)_ | `envited-x:isLicense` | MUST | `envited-x:isPublic` | LICENSE file at the asset root | -| _(root)_ | `envited-x:isManifest` | MUST | `envited-x:isPublic` | `manifest_reference.json` at the asset root | +| Folder | `envited-x` Category | Required | `envited-x` Access Role | Description | +| --------------------- | ------------------------------ | ----------- | ----------------------- | ------------------------------------------------------ | +| `simulation-data/` | `envited-x:isSimulationData` | MUST | `envited-x:isOwner` | Core simulation data (for example, `.xodr`, `.xosc`) | +| `documentation/` | `envited-x:isDocumentation` | MUST | `envited-x:isPublic` | Documentation files (for example, `.pdf`, `.txt`) | +| `metadata/` | `envited-x:isMetadata` | MUST | `envited-x:isPublic` | Domain metadata (for example, `hdmap_instance.json`) | +| `media/` | `envited-x:isMedia` | MUST | `envited-x:isPublic` | Visualizations, images, GeoJSON, 3D previews | +| `validation-reports/` | `envited-x:isValidationReport` | RECOMMENDED | `envited-x:isPublic` | Quality checker reports (for example, `.xqar`, `.txt`) | +| _(root)_ | `envited-x:isLicense` | MUST | `envited-x:isPublic` | LICENSE file at the asset root | +| _(root)_ | `envited-x:isManifest` | MUST | `envited-x:isPublic` | `manifest_reference.json` at the asset root | > **Note:** The `envited-x` categories and access roles are formally defined in the [ENVITED-X Ontology][21] which extends the generic [Manifest Ontology][22]. > The `envited-x:ExtendedLinkShape` constrains the allowed values for both `manifest:hasCategory` and `manifest:hasAccessRole`. @@ -146,12 +147,12 @@ IPFS is a peer-to-peer content delivery network built around the innovation of c #### CID v1 -Artifacts uploaded to IPFS e.g. using services like [Pinata][9] MUST use the content identifier version [CID v1][11]. +Artifacts uploaded to IPFS, for example using services like [Pinata][9] MUST use the content identifier version [CID v1][11]. In Pinata this is achievable through the API using the `pinataOptions` parameter, as outlined in the [documentation][10]. #### File Naming -Uploaded file names MUST exclude extensions (e.g., use `file` instead of `file.json`) to avoid issues such as double extensions during downloads (e.g., `file.json.json`). +Uploaded file names MUST exclude extensions (for example, use `file` instead of `file.json`) to avoid issues such as double extensions during downloads (for example, `file.json.json`). ### 3. Privacy Layer @@ -198,7 +199,9 @@ The following process is implemented in the [ENVITED-X Data Space][12] portal de - Create `envited-x_manifest.json` by replacing relative paths in `manifest_reference.json` with IPFS/envited-x.net URLs. - Replace the paths of items in `hasReferencedArtifacts` to the correct filePaths. - Replace `@id` from `manifest_reference.json` with generated database `UUID` in `envited-x_manifest.json`. This also applies for referenced artifacts. -- Create `tzip21_token_metadata.json` and map the metadata fields OPTIONALLY use an application/ld+json conform to the [tzip21 ontology][19]. +- Create the chain-specific token metadata file and map the metadata fields: + - **Tezos (TZIP-21):** Create `tzip21_token_metadata.json` OPTIONALLY conforming to the [tzip21 ontology][19] as application/ld+json. + - **EVM (ERC-721):** Create `erc721_token_metadata.json` following the [OpenSea Metadata Standards][23]. #### Step 3: Preview Data @@ -210,8 +213,12 @@ The following process is implemented in the [ENVITED-X Data Space][12] portal de - It is RECOMMENDED to use signed CIDs for the upload to IPFS according to [EIP-712][13]. - Upload `isPublic` information and `envited-x_manifest.json` to IPFS. - It is RECOMMENDED to verify that CIDs from the IPFS service or software returns the same CIDs as the pre-calculation. -- Upload `tzip21_token_metadata.json` to IPFS. -- Mint token with linked metadata. +- Upload the chain-specific token metadata file to IPFS: + - **Tezos:** Upload `tzip21_token_metadata.json`. + - **EVM:** Upload `erc721_token_metadata.json`. +- Mint token with linked metadata: + - **Tezos:** Mint an FA2.1 token with the TZIP-21 metadata URI as the token metadata. + - **EVM:** Mint an [ERC-721][26] token where `tokenURI()` resolves to the ERC-721 metadata JSON on IPFS. The contract SHOULD implement [ERC-5192][25] for soulbound (non-transferable) tokens if applicable. The contract SHOULD emit [ERC-4906][24] `MetadataUpdate` events when metadata changes. - The wallet/SDK will provide feedback if a token was minted successfully. #### Step 5: Listener and Database Synchronization @@ -219,9 +226,9 @@ The following process is implemented in the [ENVITED-X Data Space][12] portal de - Use a listener to detect mint events and synchronize data with the ENVITED-X Data Space portal database. - A data space like the ENVITED-X Data Space MUST check if the asset was uploaded through its respective portal: - `UUID` from step 2) has an entry in the database. - - Confirm that `contract` + `CID` and `minter` of tzip21_token_metadata.json are the same as in the database. + - Confirm that `contract` + `CID` and `minter` of the token metadata file (`tzip21_token_metadata.json` or `erc721_token_metadata.json`) are the same as in the database. - Confirm that the entries `UUID` and `@id` of the asset are unique. - - OPTIONALLY check if the EIP-712 signature of the tzip21_token_metadata.json matches the user who initiated the mint (SHALL only be known to the respective portal). + - OPTIONALLY check if the EIP-712 signature of the token metadata file matches the user who initiated the mint (SHALL only be known to the respective portal). - If the asset is not yet in DB OPTIONALLY mark it as foreign asset and add the `publisher` information to the DB. - It is RECOMMENDED to verify the asset in reverse order as in step 1). - Only public information of assets can be verified if uploaded through another portal than ENVITED-X data space. @@ -231,7 +238,7 @@ The following process is implemented in the [ENVITED-X Data Space][12] portal de #### @id and CID as the Primary Identifier - The CID of the uploaded `asset.zip` serves as the unique identifier detecting identical datasets across all systems. -- In addition the unique identifier `@id` of the `envied-x:SimulationAsset` in the `domainMetadata.json` SHALL be used for identification of the digital assets. +- In addition the unique identifier `@id` of the `envited-x:SimulationAsset` in the `domainMetadata.json` SHALL be used for identification of the digital assets. - The CIDs MAY be signed by the user according to EIP-712. - A UUID MUST be generated for the `envited-x_manifest.json` pre-mint to link the asset with the ENVITED-X database securely. - The DID of the member associated with the user minting the asset MUST be known. @@ -246,37 +253,100 @@ If additional non-public information needs to be stored in the database before m [EVES-007](../EVES-007/eves-007.md) defines the ENVITED-X Blockchain Identifier URN Schema. The synchronization between the smart contract as in the [Marketplace Contract Reference Implementation][18] and the ENVITED-X database relies on: -1. The contract identifier on Tezos (current Ghostnet contract): - `urn:blockchain:tezos:NetXnHfVqm9iesp:contract:KT1PCaD2kmgCHy15wQ1gpqZUy9RLxyBVJdTF` -2. Search `CID` of `tzip21_token_metadata.json` and the complete `asset.zip` in database. +1. The contract identifier using the [EVES-007](../EVES-007/eves-007.md) URN schema: + - **Tezos** (current Ghostnet contract): + `urn:blockchain:tezos:NetXnHfVqm9iesp:contract:KT1PCaD2kmgCHy15wQ1gpqZUy9RLxyBVJdTF` + - **EVM** (Etherlink L2): + `urn:blockchain:eip155:42793:contract:0x646B92C8f21e55DF67E766047E4bD7bEdF8DfA14` +2. Search `CID` of the token metadata file (`tzip21_token_metadata.json` or `erc721_token_metadata.json`) and the complete `asset.zip` in database. 3. Compare if signature on CID is a `user` belonging to the `member` and if member is owner of token. 4. Check: Uniqueness of CID in database. -### TZIP-21 Token Metadata +### 6. Token Metadata -#### TZIP-21 Rich Metadata Mapping + + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119][16]. + +This section defines how EVES-003 asset metadata is mapped to chain-specific token metadata formats. +The core EVES-003 fields (derived from the ENVITED-X manifest and domain metadata) are identical regardless of target chain; only the serialization format differs. + +The minter MUST be a `simpulseid:OrganizationParticipant` (LegalEntity) identified by their `did:ethr` DID as defined in [EVES-008][28]. +The natural person performing the mint is linked to the organization through the `memberOf` credential property. + +#### TZIP-21 Rich Metadata (Tezos) Attributes not in the table are static and the same for every mint as in the πŸ“ `example/tzip21_token_metadata.json`. Examples are the first five tags or "publishers", which is always ENVITED-X and the ASCS if the mint is conducted through the [website][12]. -| TZIP-21 | EVES-003 | Comment | -| ------------- | -------------------------------------------------------- | -------------------------------------------------------------------------- | -| "name" | envited-x:DataResource:gx:name | | -| "description" | envited-x:DataResource:gx:description | | -| "tags" | $TAG = format:formatType + " " + format:version | "tags": ["GaiaX","ASCS","ENVITED-X","EVES","nft", "$TAG"] | -| "minter" | Member DID (CAIP-10) associated with user | Returned by the View from the SimpulseID revocation registry | -| "creators" | Name of the company | Taken from the company profile the user belongs to | -| "date" | [System date-time][14] | | -| "rights" | manifest:hasLicense:gx:license | [SPDX identifier][15] | -| "rightsUri" | manifest:hasLicense:licenseData:hasFileMetadata:filePath | Full os license text URL OR policy smart contract did | -| "artifactUri" | | | -| "identifier" | Simulation Asset @id | Unique identifier from the domainMetadata.json | -| "externalUri" | Uploaded domainMetadata.json to IPFS | | -| "displayUri" | "manifest:hasArtifacts:Link" of category "isMedia" | Always use the first media image | -| "formats" | artifactUri, externalUri, displayUri, envited-x_manifest | | -| "attributes" | Reverse domain notation for ontologies + URL | All ontologies from top level nodes in files referenced in formats section | - -**>Note:** Some of the information need to be extracted from the `gx:LegalParticipant`. +| TZIP-21 | EVES-003 | Comment | +| ------------- | --------------------------------------------------------- | ------------------------------------------------------------------ | +| "name" | envited-x:hasResourceDescription β†’ gx:name | | +| "description" | envited-x:hasResourceDescription β†’ gx:description | | +| "tags" | $TAG = format:formatType + " " + format:version | "tags": ["GaiaX","ASCS","ENVITED-X","EVES","nft", "$TAG"] | +| "minter" | LegalEntity DID from [EVES-008][28] | did:ethr:\:\ of the OrganizationParticipant | +| "creators" | Name of the company | Taken from the company profile the user belongs to | +| "date" | [System date-time][14] | | +| "rights" | envited-x:hasResourceDescription β†’ gx:license | [SPDX identifier][15] | +| "rightsUri" | manifest:hasLicense β†’ manifest:hasFileMetadata β†’ filePath | Full license text URL OR policy smart contract DID | +| "artifactUri" | | | +| "identifier" | Simulation Asset @id | Unique identifier from the domainMetadata.json | +| "externalUri" | Uploaded domainMetadata.json to IPFS | | +| "displayUri" | manifest:hasArtifacts β†’ Link of category "isMedia" | Always use the first media image | +| "formats" | artifactUri, externalUri, displayUri, envited-x_manifest | | +| "attributes" | Reverse domain notation for ontologies + URL | All ontologies from top level nodes in files referenced in formats | + +> **Note:** Some of the information needs to be extracted from the `gx:LegalParticipant` via the SimpulseID `ParticipantCredential`. + +#### ERC-721 Metadata (EVM) + +ERC-721 token metadata follows the [OpenSea Metadata Standards][23] which extend the minimal [ERC-721][26] `tokenURI()` JSON schema with additional fields. +Attributes not in the table are static and the same for every mint as in the πŸ“ `example/erc721_token_metadata.json`. + +| ERC-721 / OpenSea | EVES-003 | Comment | +| ----------------- | --------------------------------------------------------- | ------------------------------------------------------------------- | +| "name" | envited-x:hasResourceDescription β†’ gx:name | | +| "description" | envited-x:hasResourceDescription β†’ gx:description | | +| "image" | manifest:hasArtifacts β†’ Link of category "isMedia" | Always use the first media image. Maps to TZIP-21 "displayUri" | +| "animation_url" | | Maps to TZIP-21 "artifactUri" | +| "external_url" | Uploaded domainMetadata.json to IPFS | Maps to TZIP-21 "externalUri" | +| "attributes" | Tags + ontology attributes as trait_type/value pairs | See mapping note below | +| "minter" | LegalEntity DID from [EVES-008][28] | did:ethr:\:\ (EVES extension) | +| "creators" | Name of the company | Taken from the company profile (EVES extension) | +| "publishers" | Name of the publishing organizations | (EVES extension) | +| "date" | [System date-time][14] | (EVES extension) | +| "type" | "EVES-003" + EVES URL | (EVES extension) | +| "language" | Language of the asset content | [RFC 1766][16] language tag (EVES extension) | +| "rights" | envited-x:hasResourceDescription β†’ gx:license | [SPDX identifier][15] (EVES extension) | +| "rights_uri" | manifest:hasLicense β†’ manifest:hasFileMetadata β†’ filePath | Full license text URL OR policy smart contract DID (EVES extension) | +| "identifier" | Simulation Asset @id | Unique identifier from the domainMetadata.json (EVES extension) | +| "formats" | artifactUri, externalUri, displayUri, envited-x_manifest | (EVES extension, same structure as TZIP-21) | + +**Attributes mapping note:** TZIP-21 uses a flat `"tags"` string array and a separate `"attributes"` array with `name`/`value`/`type` objects. +In ERC-721, both are merged into the OpenSea-style `"attributes"` array using `"trait_type"`/`"value"` objects. +Each TZIP-21 tag becomes an attribute (for example, `{"trait_type": "Format", "value": "ASAM OpenDRIVE 1.6"}`), +and each TZIP-21 attribute's `name`/`value` maps to `trait_type`/`value` +(for example, `{"trait_type": "Ontology", "value": "https://w3id.org/ascs-ev/envited-x/hdmap/v6/"}`). + +> **Note:** Fields marked as "(EVES extension)" are not part of the base ERC-721 or OpenSea standard but are defined by EVES-003 +> for interoperability with the ENVITED-X Data Space. +> Marketplaces will display `name`, `description`, `image`, `animation_url`, `external_url`, and `attributes` natively; +> EVES extension fields are consumed by the ENVITED-X portal. + +#### ERC-7572 Contract-Level Metadata (EVM) + +For EVM-based deployments, the marketplace contract SHOULD implement [ERC-7572][27] by exposing a `contractURI()` function +that returns a URI to a JSON document describing the contract/collection. +This has no TZIP-21 equivalent as Tezos handles collection-level metadata differently through FA2.1 contract storage. + +The `contractURI()` response SHOULD include at minimum: + +- `name`: the collection name (for example, "ENVITED-X Simulation Assets") +- `description`: a description of the collection +- `image`: a collection image/logo URI +- `external_link`: URL to the ENVITED-X Data Space portal + +The contract SHOULD emit a `ContractURIUpdated()` event as defined in [ERC-7572][27] when the contract-level metadata is changed. #### Custom SPDX license identifier @@ -287,6 +357,8 @@ Examples are the first five tags or "publishers", which is always ENVITED-X and This specification introduces new processes for asset uploads and is fully compatible with existing ENVITED-X systems. No retroactive changes to previous assets are required. +The addition of EVM/ERC-721 support is additive and does not alter the existing Tezos/TZIP-21 metadata path. +Existing assets minted on Tezos remain valid without modification. ## Future Improvements @@ -294,29 +366,36 @@ The compatibility with the current release of the [Gaia-X Policy Rules Complianc ## References -- [Gaia-X 4 PLC-AAD Ontology Management Base][1] -- [Gaia-X Ontology and SHACL shapes 2210][2] +- [ASCS Ontology Management Base][1] +- [Gaia-X Ontology and SHACL shapes][2] - [Gaia-X Trust Framework Schema][3] - [Gaia-X Trust Framework Shapes][4] - [GaiaX Compliant Claims Example][5] -- [GaiaX 4 PLC-AAD Claim Compliance Provider][6] +- [GaiaX Claim Compliance Provider][6] - [ASCS HD-Map Asset Example][7] - [IPFS][8] -- [Pinata Documentation][10] +- [Pinata][9] +- [Pinata API Documentation][10] +- [CID v1 Content Addressing][11] - [ENVITED-X Data Space Portal][12] - [EIP-712][13] +- [SPDX License List][15] - [RFC 2119: Key Words for Use in RFCs to Indicate Requirement Levels][16] - [Gaia-X Policy Rules Compliance Document (Release 24.11)][17] - [Marketplace Contract Reference Implementation][18] +- [TZIP-21 Ontology][19] - [ENVITED-X Simulation Asset Tools][20] - [ENVITED-X Ontology][21] - [Manifest Ontology][22] -- [ENVITED-X Simulation Asset Tools][20] -- [ENVITED-X Ontology][21] -- [Manifest Ontology][22] +- [OpenSea Metadata Standards][23] +- [ERC-4906: EIP-721 Metadata Update Extension][24] +- [ERC-5192: Minimal Soulbound NFTs][25] +- [ERC-721: Non-Fungible Token Standard][26] +- [ERC-7572: Contract-Level Metadata via contractURI()][27] +- [EVES-008: ENVITED-X Identity and Credential Framework][28] [1]: https://github.com/ASCS-eV/ontology-management-base/ -[2]: https://github.com/GAIA-X4PLC-AAD/ontology-management-base/tree/main/gx +[2]: https://github.com/ASCS-eV/ontology-management-base/tree/main/artifacts/gx [3]: https://registry.lab.gaia-x.eu/v1/api/trusted-schemas-registry/v2/schemas/gax-trust-framework [4]: https://registry.lab.gaia-x.eu/v1/api/trusted-shape-registry/v1/shapes/jsonld/trustframework# [5]: https://github.com/GAIA-X4PLC-AAD/gaia-x-compliant-claims-example @@ -324,16 +403,22 @@ The compatibility with the current release of the [Gaia-X Policy Rules Complianc [7]: https://github.com/ASCS-eV/hd-map-asset-example/releases/tag/v0.2.3 [8]: https://ipfs.tech/ [9]: https://pinata.cloud/ -[10]: https://docs.pinata.cloud/web3/pinning/pinata-metadata#pinataoptions +[10]: https://docs.pinata.cloud/api-reference/endpoint/ipfs/pin-file-to-ipfs [11]: https://docs.ipfs.tech/concepts/content-addressing/#version-1-v1 [12]: https://envited-x.net/ [13]: https://eips.ethereum.org/EIPS/eip-712 [14]: https://json-schema.org/understanding-json-schema/reference/string#dates-and-times -[15]: https://softwareengineering.stackexchange.com/a/450839/443441 +[15]: https://spdx.org/licenses/ [16]: https://datatracker.ietf.org/doc/html/rfc2119 [17]: https://docs.gaia-x.eu/policy-rules-committee/compliance-document/24.11/ [18]: https://github.com/ASCS-eV/smart-contracts/tree/main/contracts/marketplace/ -[19]: https://github.com/GAIA-X4PLC-AAD/ontology-management-base/tree/main/tzip21 +[19]: https://github.com/ASCS-eV/ontology-management-base/tree/main/artifacts/tzip21 [20]: https://github.com/openMSL/sl-5-8-asset-tools [21]: https://github.com/ASCS-eV/ontology-management-base/tree/main/artifacts/envited-x [22]: https://github.com/ASCS-eV/ontology-management-base/tree/main/artifacts/manifest +[23]: https://docs.opensea.io/docs/metadata-standards +[24]: https://eips.ethereum.org/EIPS/eip-4906 +[25]: https://eips.ethereum.org/EIPS/eip-5192 +[26]: https://eips.ethereum.org/EIPS/eip-721 +[27]: https://eips.ethereum.org/EIPS/eip-7572 +[28]: ../EVES-008/eves-008.md diff --git a/EVES/EVES-003/example/envited-x_manifest.json b/EVES/EVES-003/example/envited-x_manifest.json index 568d366..f8a4a58 100644 --- a/EVES/EVES-003/example/envited-x_manifest.json +++ b/EVES/EVES-003/example/envited-x_manifest.json @@ -1,13 +1,14 @@ { - "@context": { - "envited-x": "https://ontologies.envited-x.net/envited-x/v2/ontology#", - "manifest": "https://ontologies.envited-x.net/manifest/v4/ontology#", - "gx": "https://registry.lab.gaia-x.eu/development/api/trusted-shape-registry/v1/shapes/jsonld/trustframework#", - "sh": "http://www.w3.org/ns/shacl#", - "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#", - "xsd": "http://www.w3.org/2001/XMLSchema#", - "skos": "http://www.w3.org/2004/02/skos/core#" - }, + "@context": [ + "https://w3id.org/ascs-ev/envited-x/manifest/v5/", + { + "envited-x": "https://w3id.org/ascs-ev/envited-x/envited-x/v3/", + "gx": "https://w3id.org/gaia-x/development#", + "skos": "http://www.w3.org/2004/02/skos/core#", + "sh": "http://www.w3.org/ns/shacl#", + "xsd": "http://www.w3.org/2001/XMLSchema#" + } + ], "@id": "urn:uuid:896f0b9d-5626-4ddb-9d28-568f4af63603", "@type": "envited-x:Manifest", "manifest:hasManifestReference": { @@ -33,30 +34,27 @@ } }, "manifest:hasLicense": { - "@type": "manifest:License", - "gx:license": { - "@value": "MPL-2.0" + "@type": "manifest:Link", + "manifest:iri": { + "@id": "https://www.mozilla.org/en-US/MPL/2.0/" }, - "manifest:licenseData": { - "@type": "manifest:Link", - "manifest:hasAccessRole": { - "@type": "manifest:AccessRole", - "@id": "envited-x:isPublic" - }, - "manifest:hasCategory": { - "@type": "manifest:Category", - "@id": "envited-x:isLicense" + "manifest:hasAccessRole": { + "@type": "manifest:AccessRole", + "@id": "envited-x:isPublic" + }, + "manifest:hasCategory": { + "@type": "manifest:Category", + "@id": "envited-x:isLicense" + }, + "manifest:hasFileMetadata": { + "@type": "manifest:FileMetadata", + "manifest:filePath": { + "@value": "https://www.mozilla.org/en-US/MPL/2.0/", + "@type": "xsd:anyURI" }, - "manifest:hasFileMetadata": { - "@type": "manifest:FileMetadata", - "manifest:filePath": { - "@value": "https://www.mozilla.org/en-US/MPL/2.0/", - "@type": "xsd:anyURI" - }, - "manifest:mimeType": { - "@value": "text/html", - "@type": "xsd:string" - } + "manifest:mimeType": { + "@value": "text/html", + "@type": "xsd:string" } } }, @@ -192,7 +190,7 @@ }, "sh:conformsTo": [ { - "@id": "https://ontologies.envited-x.net/hdmap/v3/ontology" + "@id": "https://w3id.org/ascs-ev/envited-x/hdmap/v6/" } ], "manifest:hasAccessRole": { diff --git a/EVES/EVES-003/example/erc721_token_metadata.json b/EVES/EVES-003/example/erc721_token_metadata.json new file mode 100644 index 0000000..1a8b262 --- /dev/null +++ b/EVES/EVES-003/example/erc721_token_metadata.json @@ -0,0 +1,96 @@ +{ + "name": "TestfeldNiedersachsen_ALKS_ODR_sample", + "description": "simple hdmap example file on Testfeld Niedersachsen for ALKS scenario", + "image": "ipfs://bafybeief5r2xgciehzhx6c4kbooifsnbjpiifjei36lpi3kzcdmpr2wvue", + "animation_url": "https://assets.envited-x.net/bafybeifo6ve5i6542vi6ruuflxdqtcmcisdtwlqefq2e5a33tljsaqxhpm", + "external_url": "ipfs://bafkreicuwg3s4uvei2iu2p5eobozghdodtwhwoi6qiawhwqj3nflrk6dxi", + "attributes": [ + { + "trait_type": "Standard", + "value": "GaiaX" + }, + { + "trait_type": "Publisher", + "value": "ASCS" + }, + { + "trait_type": "Ecosystem", + "value": "ENVITED-X" + }, + { + "trait_type": "Specification", + "value": "EVES" + }, + { + "trait_type": "Token Type", + "value": "nft" + }, + { + "trait_type": "Format", + "value": "ASAM OpenDRIVE 1.6" + }, + { + "trait_type": "Ontology", + "value": "https://w3id.org/ascs-ev/envited-x/hdmap/v6/" + }, + { + "trait_type": "Ontology", + "value": "https://w3id.org/ascs-ev/envited-x/envited-x/v3/" + } + ], + "minter": "did:ethr:0x14a34:0x50916c8e454722d2357916d4250500102288bb03", + "creators": [ + "Automotive Solution Center for Simulation e.V." + ], + "publishers": [ + "Automotive Solution Center for Simulation e.V.", + "ENVITED-X Data Space" + ], + "date": "2025-02-17T00:00:00+00:00", + "type": "EVES-003 https://github.com/ASCS-eV/EVES", + "language": "en", + "rights": "MPL-2.0", + "rights_uri": "https://www.mozilla.org/en-US/MPL/2.0/", + "identifier": "did:web:registry.gaia-x.eu:HdMap:DjHgK5ErTBow1Ya3J05tW9l12skGWgZn6kA9", + "formats": [ + { + "uri": "https://assets.envited-x.net/bafybeifo6ve5i6542vi6ruuflxdqtcmcisdtwlqefq2e5a33tljsaqxhpm", + "hash": "bafybeifo6ve5i6542vi6ruuflxdqtcmcisdtwlqefq2e5a33tljsaqxhpm", + "mimeType": "application/zip", + "fileSize": 7711664, + "fileName": "Testfeld_Niedersachsen_ALKS_xodr_sample.zip" + }, + { + "uri": "ipfs://bafkreicuwg3s4uvei2iu2p5eobozghdodtwhwoi6qiawhwqj3nflrk6dxi", + "hash": "bafkreicuwg3s4uvei2iu2p5eobozghdodtwhwoi6qiawhwqj3nflrk6dxi", + "mimeType": "application/ld+json", + "fileSize": 6574, + "fileName": "hdmap_instance.json" + }, + { + "uri": "ipfs://bafkreigxkhnuuyjrb2nyduivdaqbrbuw7zcjf6aaslvlufvmgv5bfsh6u4", + "hash": "bafkreigxkhnuuyjrb2nyduivdaqbrbuw7zcjf6aaslvlufvmgv5bfsh6u4", + "mimeType": "application/ld+json", + "fileSize": 21630, + "fileName": "manifest_reference.json" + }, + { + "uri": "ipfs://bafkreie2yjoudxlayordup63se7wbj6vroaoyqzcuixqcchpmd23ufno6u", + "hash": "bafkreie2yjoudxlayordup63se7wbj6vroaoyqzcuixqcchpmd23ufno6u", + "mimeType": "application/ld+json", + "fileSize": 5572, + "fileName": "envited-x_manifest.json" + }, + { + "uri": "ipfs://bafybeief5r2xgciehzhx6c4kbooifsnbjpiifjei36lpi3kzcdmpr2wvue", + "hash": "bafybeief5r2xgciehzhx6c4kbooifsnbjpiifjei36lpi3kzcdmpr2wvue", + "mimeType": "image/png", + "dimensions": { + "value": "1095x850", + "unit": "px" + }, + "fileSize": 2397906, + "fileName": "Testfeld_Niedersachsen_ALKS_..._impression-01.png" + } + ] +} diff --git a/EVES/EVES-003/example/tzip21_token_metadata.json b/EVES/EVES-003/example/tzip21_token_metadata.json index bf3b760..9c64139 100644 --- a/EVES/EVES-003/example/tzip21_token_metadata.json +++ b/EVES/EVES-003/example/tzip21_token_metadata.json @@ -11,7 +11,7 @@ "nft", "ASAM OpenDRIVE 1.6" ], - "minter": "did:pkh:tezos:NetXnHfVqm9iesp:tz1cZaiTjNSN7x4VZjTQGYBVz4p8eEcVcYkz", + "minter": "did:ethr:0x14a34:0x50916c8e454722d2357916d4250500102288bb03", "creators": [ "Automotive Solution Center for Simulation e.V." ], @@ -71,13 +71,13 @@ ], "attributes": [ { - "name": "https://ontologies.envited-x.net/hdmap/v4/ontology#", - "value": "https://github.com/GAIA-X4PLC-AAD/ontology-management-base/releases/tag/v0.0.4", + "name": "https://w3id.org/ascs-ev/envited-x/hdmap/v6/", + "value": "https://github.com/ASCS-eV/ontology-management-base/releases/tag/v0.1.6", "type": "uri" }, { - "name": "https://ontologies.envited-x.net/envited-x/v2/ontology#", - "value": "https://github.com/GAIA-X4PLC-AAD/ontology-management-base/releases/tag/v0.0.4", + "name": "https://w3id.org/ascs-ev/envited-x/envited-x/v3/", + "value": "https://github.com/ASCS-eV/ontology-management-base/releases/tag/v0.1.6", "type": "uri" } ] diff --git a/EVES/EVES-003/tzip21-schemas/tzip21_token_metadata-schema.json b/EVES/EVES-003/tzip21-schemas/tzip21_token_metadata-schema.json index c432f41..fc5c416 100644 --- a/EVES/EVES-003/tzip21-schemas/tzip21_token_metadata-schema.json +++ b/EVES/EVES-003/tzip21-schemas/tzip21_token_metadata-schema.json @@ -6,6 +6,7 @@ "asset": { "type": "object", "additionalProperties": true, + "required": ["name"], "properties": { "description": { "type": "string", @@ -13,8 +14,7 @@ }, "minter": { "type": "string", - "format": "tzaddress", - "description": "The tz address responsible for minting the asset." + "description": "The DID of the LegalEntity (OrganizationParticipant) responsible for minting the asset, as defined in EVES-008 (e.g. did:ethr::
)." }, "creators": { "type": "array", @@ -72,7 +72,7 @@ "language": { "type": "string", "format": "https://tools.ietf.org/html/rfc1766", - "description": "The language of the intellectual content of the asset as defined in RFC 1776." + "description": "The language of the intellectual content of the asset as defined in RFC 1766." }, "identifier": { "type": "string", diff --git a/EVES/EVES-004/eves-004.md b/EVES/EVES-004/eves-004.md index 77403df..11a2332 100644 --- a/EVES/EVES-004/eves-004.md +++ b/EVES/EVES-004/eves-004.md @@ -50,7 +50,7 @@ This specification distinguishes between two formal roles: **Editors** and **App #### 1.5 Standards Enforcers (Editors) -- Verify that proposals align with overarching governance and standards (e.g., Gaia-X, W3C, Tezos TZIPs). +- Verify that proposals align with overarching governance and standards (for example, Gaia-X, W3C, Tezos TZIPs). - Ensure interoperability within the ENVITED ecosystem. #### 1.6 Approvers @@ -135,7 +135,7 @@ Approvers operate on top of the Editors’ responsibilities, taking an active ro 1. **Application Process**: - Anyone interested in becoming an EVES Editor can open a discussion in the ENVITED GitHub organization. - - Tag the current editors group (e.g., `@eves-editors`) in the discussion for visibility. + - Tag the current editors group (for example, `@eves-editors`) in the discussion for visibility. 2. **Eligibility**: - Applicants MUST demonstrate familiarity with the EVES process, template, and standards as defined in [EVES-001](../EVES-001/eves-001.md) and this document. @@ -155,7 +155,7 @@ The following points clarify limits to the Editor and Approver roles: 1. **Creation of New EVES** - Neither Editors nor Approvers drive the creation of new EVES; the community identifies needs, and authors propose solutions. 2. **Technical Designs or Implementations** - - They do not craft or own the underlying technical designs (e.g., code libraries). + - They do not craft or own the underlying technical designs (for example, code libraries). The community or EVES authors lead the design, while Editors and Approvers review it for feasibility. 3. **Promotion or Adoption** - They are not tasked with marketing or ensuring the adoption of specific EVES. diff --git a/EVES/EVES-005/eves-005.md b/EVES/EVES-005/eves-005.md index ca26b82..e9b58e8 100644 --- a/EVES/EVES-005/eves-005.md +++ b/EVES/EVES-005/eves-005.md @@ -68,7 +68,7 @@ The negotiation process follows the dataspace protocol state machine with the fo Access to the contracted asset is authorized only when the VC is valid and a corresponding registry entry is found and valid. - **TERMINATED:** - If any error occurs (e.g., invalid signatures, mismatched payloads, or a timeout) or if either party cancels the negotiation, the process transitions to the terminated state. + If any error occurs (for example, invalid signatures, mismatched payloads, or a timeout) or if either party cancels the negotiation, the process transitions to the terminated state. ### 2. Detailed Process Flow Example @@ -105,7 +105,7 @@ The negotiation process follows the dataspace protocol state machine with the fo - **Verifiable Credential Format:** The contract VC conforms to the SD-JWT VC specification (see [SD-JWT-based Verifiable Credentials (SD-JWT VC)](https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-00.html) and [OpenID for Verifiable Credential Issuance - draft 15](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html)). - It is intended for storage in wallets (e.g., Altme) and can be presented to endpoints running the [ssi-to-oidc-bridge](https://github.com/GAIA-X4PLC-AAD/ssi-to-oidc-bridge). + It is intended for storage in wallets (for example, Altme) and can be presented to endpoints running the [ssi-to-oidc-bridge](https://github.com/GAIA-X4PLC-AAD/ssi-to-oidc-bridge). - **Decentralized Registry and Scaling:** Following the method outlined in [EVES-006](../EVES-006/eves-006.md) and inspired by [this paper](https://arxiv.org/pdf/2501.17089), a blockchain-based registry on Etherlink is used to store the hash and UUID of finalized VCs. @@ -113,7 +113,7 @@ The negotiation process follows the dataspace protocol state machine with the fo - **Automation and Encrypted Inbox:** An encrypted inbox system β€” optionally secured with DID keys - is used to exchange contract-related VCs. - The design minimizes manual interaction by automating transitions (e.g., from OFFERED to ACCEPTED under preset criteria) while still allowing explicit user confirmation when needed. + The design minimizes manual interaction by automating transitions (for example, from OFFERED to ACCEPTED under preset criteria) while still allowing explicit user confirmation when needed. - **State Machine Integration:** The process adheres to the dataspace protocol state machine with the following states: @@ -205,14 +205,14 @@ Initial implementation steps include: 2. **VC Generation and Signing:** Implement services to generate SD-JWT VCs for contract offers and acceptances. - Both provider and consumer systems must support signing operations and storage (e.g., in wallets like Altme). + Both provider and consumer systems must support signing operations and storage (for example, in wallets like Altme). 3. **Blockchain Registry Integration:** Integrate with the decentralized registry on Etherlink to store the hash and UUID of finalized contract VCs. The provider must record a registry entry to transition the state from AGREED to FINALIZED. 4. **Automated State Transitions:** - Where possible, automate state transitions (e.g., from OFFERED to ACCEPTED or AGREED) while allowing manual intervention if necessary. + Where possible, automate state transitions (for example, from OFFERED to ACCEPTED or AGREED) while allowing manual intervention if necessary. 5. **Operator Fee Management:** The ENVITED-X Data Space operator reviews registry entries to verify successful contracts. diff --git a/EVES/EVES-006/eves-006.md b/EVES/EVES-006/eves-006.md index bd6d318..5aa79e3 100644 --- a/EVES/EVES-006/eves-006.md +++ b/EVES/EVES-006/eves-006.md @@ -99,8 +99,8 @@ This specification extends ENVITED-X functionality without modifying existing co ## References 1. [Etherlink Documentation](https://docs.etherlink.com/) -2. [Tezos FA2.1 Standard](https://gitlab.com/tzip/tzip/-/blob/master/proposals/tzip-21/tzip-21.md) -3. [Optimistic Rollups in Tezos](https://research.tezos.com/optimistic-rollups) +2. [Tezos FA2.1 Standard](https://gitlab.com/tezos/tzip/-/blob/master/proposals/tzip-21/tzip-21.md) +3. [Smart Optimistic Rollups in Tezos](https://docs.tezos.com/architecture/smart-rollups) 4. [Bridging FA Tokens on Etherlink](https://docs.etherlink.com/bridging/bridging-fa) 5. [ERC-721 Standard](https://ethereum.org/en/developers/docs/standards/tokens/erc-721/) 6. [Rio Protocol Announcement](https://research-development.nomadic-labs.com/rio-announcement.html) diff --git a/EVES/EVES-007/eves-007.md b/EVES/EVES-007/eves-007.md index 8628952..a3f1437 100644 --- a/EVES/EVES-007/eves-007.md +++ b/EVES/EVES-007/eves-007.md @@ -53,7 +53,7 @@ urn:blockchain:{chain_namespace}:{chain_id}:contract:{contract_address} > **_NOTE:_** > -> - The **namespace** follows **CAIP-2** (e.g., `tezos`, `eip155` for Ethereum). +> - The **namespace** follows **CAIP-2** (for example, `tezos`, `eip155` for Ethereum). > - The **chain_id** follows **CAIP-10**, ensuring unique chain differentiation. > - **Smart contracts (KT1, 0x) are explicitly named** under the `contract` identifier. @@ -160,7 +160,7 @@ It is fully backward-compatible with Tezos, Ethereum, and Etherlink **without re 1. [CAIP-2: Blockchain Namespace Specification](https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-2.md) 2. [CAIP-10: Blockchain Account Specification](https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-10.md) -3. [Tezos TZIP-21](https://gitlab.com/tzip/tzip/-/blob/master/proposals/tzip-21/tzip-21.md) +3. [Tezos TZIP-21](https://gitlab.com/tezos/tzip/-/blob/master/proposals/tzip-21/tzip-21.md) 4. [Ethereum ERC-721 Standard](https://eips.ethereum.org/EIPS/eip-721) 5. [Etherlink Documentation](https://docs.etherlink.com/) 6. [Etherlink Network Information](https://docs.etherlink.com/get-started/network-information/) diff --git a/EVES/EVES-008/eves-008.md b/EVES/EVES-008/eves-008.md index 5e7231a..f12256f 100644 --- a/EVES/EVES-008/eves-008.md +++ b/EVES/EVES-008/eves-008.md @@ -104,13 +104,13 @@ did:ethr:: Entity types and their DID patterns: -| Entity | Example DID | -| ---------------------- | -------------------------------- | -| Participant (ASCS) | `did:ethr:0x14a34:0x5091...bb03` | -| Participant (e.g. BMW) | `did:ethr:0x14a34:0x9d27...1048` | -| Natural person | `did:ethr:0x14a34:0xb2F7...b39a` | -| Infrastructure service | `did:ethr:0x14a34:0x4612...46d1` | -| Program definition | `did:ethr:0x14a34:0x28b9...422D` | +| Entity | Example DID | +| ------------------------------ | -------------------------------- | +| Participant (ASCS) | `did:ethr:0x14a34:0x5091...bb03` | +| Participant (for example, BMW) | `did:ethr:0x14a34:0x9d27...1048` | +| Natural person | `did:ethr:0x14a34:0xb2F7...b39a` | +| Infrastructure service | `did:ethr:0x14a34:0x4612...46d1` | +| Program definition | `did:ethr:0x14a34:0x28b9...422D` | **Key management**: Signing DID documents MUST expose P-256 keys as `JsonWebKey` verification methods. The primary signing key is published as `#controller`; optional secondary keys appear as `#delegate-N`. @@ -151,7 +151,7 @@ Example credential `@context`: } ``` -The SimpulseID context uses `@vocab: simpulseid:` which resolves bare `@id` values to the `simpulseid:` namespace. W3C terms (e.g., `VerifiableCredential`, `issuer`, `validFrom`) remain bare; all domain types MUST use prefixed CURIEs (e.g., `simpulseid:ParticipantCredential`, `harbour:CRSetEntry`). +The SimpulseID context uses `@vocab: simpulseid:` which resolves bare `@id` values to the `simpulseid:` namespace. W3C terms (for example, `VerifiableCredential`, `issuer`, `validFrom`) remain bare; all domain types MUST use prefixed CURIEs (for example, `simpulseid:ParticipantCredential`, `harbour:CRSetEntry`). #### 3.3 Schema and Ontology @@ -202,8 +202,8 @@ Membership credentials MUST use `urn:uuid:` identifiers to avoid RDF graph merge **`member` vs `memberOf` convention**: -- `schema:member` is used **on the membership object**, pointing **to the member** (e.g., `AscsBaseMembership.member = `). -- `schema:memberOf` is used **on the person**, pointing **to the organization** they belong to (e.g., `Administrator.memberOf = []`). +- `schema:member` is used **on the membership object**, pointing **to the member** (for example, `AscsBaseMembership.member = `). +- `schema:memberOf` is used **on the person**, pointing **to the organization** they belong to (for example, `Administrator.memberOf = []`). Implementers MUST NOT interchange these properties. diff --git a/EVES/README.md b/EVES/README.md index fdb4622..74503c7 100644 --- a/EVES/README.md +++ b/EVES/README.md @@ -48,7 +48,7 @@ _-> This document, providing an overview of the repository._ ## How to Use This Repository 1. **Explore Specifications**: - - Navigate to `SUMMARY.md` to view an overview of the specifications specifications. + - Navigate to `SUMMARY.md` to view an overview of the specifications. - Check the EVES `status` for work in progress and contribute to discussions. 2. **Propose a New EVES**: diff --git a/EVES/resources/eves-template.md b/EVES/resources/eves-template.md index 34f2c98..1075de8 100644 --- a/EVES/resources/eves-template.md +++ b/EVES/resources/eves-template.md @@ -24,7 +24,7 @@ _Provide the detailed technical or procedural content of the EVES. This section ### 1. Lifecycle (if applicable) -_Define the lifecycle or steps related to the EVES, e.g., stages for a process or implementation details for standards._ +_Define the lifecycle or steps related to the EVES, for example, stages for a process or implementation details for standards._ ### 2. Key Definitions or Components (if applicable) @@ -48,7 +48,7 @@ _Provide guidelines or requirements for how this EVES will be implemented, if ap ## Template Instructions -- Replace `00X` with the EVES number (e.g., `001`, `002`). +- Replace `00X` with the EVES number (for example, `001`, `002`). - Replace placeholder text (in square brackets `[]`) with actual content. - Delete this section ("Template Instructions") after completing the document. - Use consistent formatting to align with repository standards. diff --git a/EVES/resources/style-guide.md b/EVES/resources/style-guide.md index b9be8b0..c837986 100644 --- a/EVES/resources/style-guide.md +++ b/EVES/resources/style-guide.md @@ -32,7 +32,7 @@ All EVES must adhere to the following structure, as defined in EVES-001: status: [Draft/Final/Other] type: [Process/Standards/Informational] created: YYYY-MM-DD - requires: [List of EVES this depends on, e.g., "EVES-001"] + requires: [List of EVES this depends on, for example, "EVES-001"] replaces: None --- ``` diff --git a/README.md b/README.md index 987eaa6..11c99c3 100644 --- a/README.md +++ b/README.md @@ -3,7 +3,7 @@ The goal of the EVES project is to specify and provide high-quality documentation for developing, distributing and using standard-compliant co-simulation artifacts and data. It is an initiative of the Automotive Solution Center for Simulation e.V. (ASCS) targeting the ecosystem around the [ENVITED-X Data Space](https://staging.envited-x.net/). -The specifications itself are written as independent documents based on so-called "improvement protocols" typically used in de-centralized standardization efforts, e.g. in blockchain domains. These individual specification documents stand for themselves but can inherit from one another by reference. +The specifications itself are written as independent documents based on so-called "improvement protocols" typically used in de-centralized standardization efforts, for example in blockchain domains. These individual specification documents stand for themselves but can inherit from one another by reference. All EVES documents are written in markdown format, sequentially numbered and stored in the [EVES folder](./EVES/). The process on how to write, submit or change specifications in defined in [EVES-001](./EVES/EVES-001/eves-001.md).