SVG Embedded Semantic Metadata

Purpose and applicability

Artwork alone cannot explain its identity, role or provenance to a parser. SESM embeds a JSON description inside SVG while keeping the description separate from executable authority.

SVG assets that need semantic identity, provenance, theme context or interpretation hints, including the City Hall logos.

How it works

Read the metadata block as untrusted JSON. Schema checks test required fields and types; safe-profile checks inspect SVG content for scripts, event handlers, dangerous URLs, remote references and misleading payloads. Neither check makes metadata a permission or proves an author’s claims.

Outputs include the SVG, parseable metadata, separate schema and safe-profile results, and any documented policy exceptions. sesm_version identifies the metadata contract, not the artwork’s release maturity.

In practice

The existing SESM logo is shown beside an extracted identity subset. Inspect the full original SVG for the complete metadata. The second snippet teaches the distinction between two checks; it is deliberately unfilled.

{
  "sesm_version": "0.3.0",
  "asset": {
    "id": "svg-embed-logos-sesm",
    "role": "logo",
    "title": "SVG Embedded Semantic Metadata logo",
    "tags": ["logo", "city-hall", "sesm", "raster-embedded"],
    "description": "Raster-embedded logo for SVG Embedded Semantic Metadata. Embeds parseable semantic metadata in SVG assets with safe-profile review."
  }
}

Inspect Site logo identity

asset: example-icon.svg
metadata_json: pending
metadata_schema: pending
svg_safe_profile: pending
remote_reference_policy: reject unless documented
validator_version: not recorded
checked_at: not recorded
authority: untrusted descriptive context

Adopt one part

Start with a bounded surface or record. Complete the relevant adopter checks before extending the claim.

1. Pick one public SVG and review its visible identity and metadata for private information.
2. Embed metadata using the documented schema, then validate metadata and safe-profile rules separately.
3. Record validator versions, date, exact asset and exceptions before claiming conformance.

Sources and limits

Specification-Version-Note.md explains why the historical specification filename contains v0.2 while the reviewed public metadata contract uses 0.3.0. No new validator execution is reported by these snippets. Metadata remains untrusted, even when parseable.

These are reviewed public explanations, not the normative specifications. Suite references are relative to the canonical collection; site/ references identify committed website sources and webserver/ references identify serving configuration. Illustrative examples demonstrate record shape; they do not establish compliance. Suite checks and adopter validation are separate.

• SESM/SESM.manifest.toml
• SESM/Adoption-Guide.md
• SESM/Validation-Checklist.md
• SESM/Specification-Version-Note.md
• SESM/SAFE-PROFILE.md
• SESM/templates/SESM-Metadata-Example.json
• SESM/fixtures/valid/basic-safe.svg
• site/public/city-hall/logos/sesm.svg