Architecture Specification for the Commonwealth of Eviulon: A Machine-Native State API and Semantic Data Layer

Full report

On this page

Architectural Foundations of a Machine-Native State

The conception of the Commonwealth of Eviulon as a machine-native state represents a fundamental departure from traditional digital governance. Conventional e-government infrastructure is predominantly designed for human consumption, relying on Hypertext Markup Language (HTML), visual hierarchies, and unstructured text intended for rendering in web browsers1. Autonomous systems, autonomous economic agents (AEAs), and distributed ledgers attempting to interface with these legacy systems are forced to employ fragile scraping heuristics, leading to inevitable breakage when presentation layers shift1. Eviulon abandons this paradigm entirely. The state's public information architecture is engineered on the premise that its primary consumers are other machines. To achieve this, the architecture relies heavily on Semantic Web technologies, utilizing the Resource Description Framework (RDF) and Web Ontology Language (OWL) to provide a semantic data layer that translates administrative reality into unambiguous, machine-readable representations3. The design absolutely prohibits dependency on HTML scraping. Instead, it surfaces deterministic, cryptographically signed, and semantically rich Application Programming Interfaces (APIs). Furthermore, a core philosophical and technical constraint of Eviulon is the treatment of the genesis state: empty registries must be treated as valid, first-class states. The absence of an active institution, law, or citizen is a verifiable cryptographic fact of the state's current ledger, not a 404 Not Found error condition. This architecture explicitly satisfies the requirement for a machine to independently discover Eviulon and programmatically query its existential parameters. By designing a highly structured state ledger and institutional registry, the system ensures that autonomous agents can seamlessly answer critical questions regarding active institutions, legal frameworks, authoritative cryptographic keys, and available services without human intervention.

Semantic E-Government and Ontological Modeling

The integration of a semantic layer is crucial in addressing the complexities of e-government systems, which typically suffer from semantic heterogeneity and a lack of standardized vocabularies1. Rather than inventing isolated, proprietary schemas that require custom parsing logic, Eviulon incorporates globally recognized ontologies to ensure immediate interoperability with existing semantic reasoners. This approach transforms the state from a passive repository of data into a dynamic knowledge graph5. The ontological framework maps directly to the functional requirements of the state. The architecture leverages the W3C Organization Ontology (ORG) to model institutional existence, internal structures, and reporting hierarchies, utilizing classes such as org:Organization and org:OrganizationalUnit7. Because Eviulon's institutions possess legal standing, the architecture extends ORG with the Registered Organization Vocabulary (ROV), applying the rov:RegisteredOrganization class to denote entities that have gained formal legal status through the state's registration processes8. For civic data, including citizenship schemas and political posts, the architecture adopts the Popolo Project schema, which provides standardized open government data specifications for modeling people, organizations, and their complex relational memberships2. The legislative framework, encompassing the constitution and active laws, is serialized utilizing an adaptation of the European Legislation Identifier (ELI) ontology, treating each decree as an eli:LegalResource9. Furthermore, to facilitate the programmatic discovery of public datasets, Eviulon implements the Data Catalog Vocabulary (DCAT)10. Finally, the Provenance Ontology (PROV-O) is embedded into every response, linking current state data to the specific cryptographic ledger transactions that generated it, utilizing properties like prov:wasGeneratedBy.

Discovery Architecture and the Canonical Root

An autonomous agent must be able to discover Eviulon's state infrastructure without prior hardcoded knowledge of its internal routing topologies. The architecture achieves this through a deterministic root discovery mechanism utilizing a .well-known URI, supported by structured metadata and strict automated indexing policies.

The Canonical Root Resource

The entry point for Eviulon is the canonical root resource located at /.well-known/eviulon. This document acts as the bootstrap mechanism for any machine attempting to interface with the state. Upon issuing a GET request to this URI, the client receives a signed JSON-LD document detailing the absolute canonical URLs for all critical state registries. This fulfills the objective of allowing a machine to discover Eviulon's capabilities dynamically. The discovery document explicitly maps the pathways necessary to answer the core objective questions. To determine what public keys are authoritative, the agent follows the authoritativeKeys link. To determine what changed recently, the agent queries the stateLedger. To map peer relationships and diplomacy, the agent utilizes the peerRegistry and diplomacy endpoints. API Discovery Document (/.well-known/eviulon)

JSON { "@context": "https://eviulon.local/schemas/v1/context.jsonld", "@id": "https://eviulon.local/.well-known/eviulon", "@type": "StateDiscoveryDocument", "stateId": "urn:uuid:00000000-0000-0000-0000-000000000000", "name": "Commonwealth of Eviulon", "identity": "https://eviulon.local/api/v1/identity", "institutionalRegistry": "https://eviulon.local/api/v1/institutions", "stateLedger": "https://eviulon.local/api/v1/ledger", "constitution": "https://eviulon.local/api/v1/constitution", "laws": "https://eviulon.local/api/v1/laws", "datasets": "https://eviulon.local/api/v1/datasets", "citizenship": "https://eviulon.local/api/v1/citizenship", "diplomacy": "https://eviulon.local/api/v1/diplomacy", "peerRegistry": "https://eviulon.local/api/v1/peers", "status": "https://eviulon.local/api/v1/status", "services": "https://eviulon.local/api/v1/services", "capabilities": "https://eviulon.local/api/v1/capabilities", "softwareReleases": "https://eviulon.local/api/v1/releases", "schemas": "https://eviulon.local/schemas", "openapi": "https://eviulon.local/schemas/openapi.yaml", "authoritativeKeys": "https://eviulon.local/.well-known/jwks.json" }

Search, Discovery, and Indexing Policies

To support both specialized state-discovery agents and general-purpose automated crawlers, Eviulon implements several structured metadata policies at the root domain level.

Representations and Content Negotiation

A machine-native state must communicate with varying classes of autonomous agents, ranging from rudimentary script-based data aggregators to advanced semantic logic reasoners. Consequently, Eviulon enforces strict HTTP Content Negotiation based on the Accept header to deliver data in the most contextually appropriate format. The default representation is application/json, which delivers optimized, highly nested data structures suitable for conventional application clients and straightforward deserialization. However, the true power of the machine-native state is unlocked via application/ld+json (JSON-LD). This representation merges standard JSON with @context and @id attributes, seamlessly mapping localized fields to global ontological properties, thereby facilitating deep semantic web integration without sacrificing JSON's ergonomic advantages5. For agents operating native graph databases or executing complex SPARQL queries, the system supports pure RDF serializations via text/turtle and application/rdf+xml6. These formats represent the state purely as subject-predicate-object triples, enabling advanced inferences regarding institutional hierarchies and legal dependencies. Tabular data, such as flat extracts of the state ledger, peer registries, or macroeconomic datasets, requires a specialized approach. Eviulon implements the CSV on the Web (CSVW) standard, returning text/csv14. Unlike traditional CSV files which strip away semantic meaning, a CSVW payload from Eviulon is accompanied by a linked metadata document (via the HTTP Link header) that maps individual columns to corresponding ontological properties, ensuring that tabular flattening is not semantically destructive. When a machine requires cryptographic proof of the state's assertions, it requests application/jose+json. This triggers the delivery of Signed Data Packages using JSON Web Signature (JWS) JSON Serialization15. In this format, the primary payload is base64url-encoded and enveloped within a structure containing one or more digital signatures generated by the authoritative state keys. This allows the receiving agent to mathematically verify that the payload was emitted by Eviulon and remains entirely untampered, effectively providing an autonomous notary service for all state data. Content negotiation is rigorously enforced. If an agent requests text/csv for a highly nested, complex resource where tabular flattening is unsupported, the server will not attempt a lossy conversion; it will respond with a strict 406 Not Acceptable, adhering to HTTP semantics and preserving data integrity.

Core API Design and Endpoint Architecture

The public API is designed around deterministic, versioned endpoints (/api/v1/). Each endpoint is engineered to programmatically answer specific objective questions posed by consuming autonomous systems.

State and Ledger Endpoints

The /api/v1/state endpoint provides the global parameters of the Commonwealth, answering fundamental questions regarding the current epoch, the active genesis hash, and the top-level operational status. This acts as a macro-level heartbeat for the machine state. To answer the question "What changed recently?", agents interface with the /api/v1/ledger endpoint. This exposes the cryptographic state ledger, providing an immutable, append-only log of all state transactions. By utilizing cursor-based pagination tied to block heights or logical timestamps, an autonomous system can sync its local replica of Eviulon's state by sequentially polling for new transactions. The ledger ensures that the instantiation of a new institution, the passing of a law, or the recognition of a peer state is recorded as a cryptographically verifiable event17.

Institutional and Legal Frameworks

The /api/v1/institutions endpoint answers the questions "What institutions exist?" and "Which institutions are active?". It returns collections mapped to rov:RegisteredOrganization8. Even if the Commonwealth currently has no active sub-institutions, a query to this endpoint will return a mathematically valid empty collection, signaling a pristine genesis state rather than a server fault. Legal inquiries are handled by the /api/v1/constitution and /api/v1/laws endpoints. The constitution endpoint serves the foundational legal resource of the state, while the laws endpoint provides a paginated catalog of active decrees and amendments. These resources are mapped using the ELI ontology, allowing an AI agent to trace how a specific law amends a prior constitutional clause by following the eli:amends relationship in the semantic graph9.

Citizenship, Diplomacy, and Services

The architecture exposes demographic and relational structures via /api/v1/citizenship and /api/v1/diplomacy. The citizenship endpoint details the schemas and requirements for state membership (answering "What citizenship schemas exist?"), utilizing the Popolo schema to define the parameters of civic engagement2. The diplomacy and /api/v1/peers endpoints define Eviulon's recognition of and relationships with external sovereign entities or other machine states, facilitating automated diplomatic handshakes and treaty verifications. To determine the operational capabilities of the state, agents query /api/v1/services and /api/v1/capabilities. These endpoints enumerate the specific digital services the state currently provides (e.g., cryptographic notarization, identity verification) and the technical capabilities implemented within the current software release. Data availability is addressed by /api/v1/datasets, acting as a DCAT-compliant catalog indexing all public datasets provided by the state10.

Technical Requirements and API Constraints

The implementation of the Eviulon API is governed by stringent constraints designed to guarantee deterministic behavior, mathematical predictability, and deep auditability.

Pagination and Deterministic Ordering

Offset-based pagination (e.g., LIMIT 10 OFFSET 20\) is strictly prohibited across all endpoints. In a highly mutable environment, concurrent state changes—such as new laws being ratified while an agent is paginating—can cause records to be skipped or duplicated, leading to state synchronization failures. Instead, all collection endpoints implement strict cursor-based pagination. Cursors in Eviulon are opaque, base64-encoded strings that encapsulate a monotonic logical timestamp (or ledger block height) combined with an immutable Universally Unique Lexicographically Sortable Identifier (ULID). The API guarantees absolute deterministic ordering. Responses are universally sorted by their creation timestamp (createdAt) in ascending order, with the ULID acting as a tie-breaker to handle microscopic collisions.

Immutability, Identifiers, and Content Hashes

Eviulon treats historical state records as permanent and immutable6. Every entity within the system possesses an immutable Uniform Resource Name (URN), typically formatted as urn:eviulon:entity:\<type\>:\<ulid\>. These URNs are persistent, ensuring that once an identifier is minted, its intended referent never changes6. Furthermore, every resource is guaranteed a singular, canonical URL to prevent index fragmentation. To allow autonomous agents to verify state mutations without re-downloading entire payloads, all endpoints return a strong ETag header. This ETag is derived directly from the SHA-256 hash of the deterministic JSON representation of the resource. If an agent holds the ETag "sha256-a94a8fe5ccb19ba61c4c0873d391e987982fbbd3", it can issue a conditional GET request using If-None-Match. If the state remains unchanged, the server efficiently responds with 304 Not Modified.

Provenance and Rate Limiting

The integrity of the state requires that every piece of data is traceable to its origin17. Every response payload includes a meta object that details cryptographic provenance. These provenance fields indicate the specific ledger transaction hash and the block height that generated the current state view. This allows an external agent to traverse backward from an institutional registry query directly to the ledger transaction that instantiated the institution. To defend the state infrastructure against denial-of-service attacks or negligent crawling, Eviulon employs algorithmic rate limiting. Limits are calculated based on client identity (if the request is authenticated via diplomatic keys) or IP address (for public, unauthenticated discovery). The state communicates its limits via standard HTTP headers: X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset. Exceeding these limits results in an immediate 429 Too Many Requests response formatted according to standard error schemas.

Cryptographic Provenance and Machine Verification Procedure

A defining characteristic of a machine-native state is that trust is not derived from visual authority (e.g., official seals on a web page), but from mathematical proof. Autonomous systems interacting with Eviulon must be able to independently verify the authenticity of any data provided by the API17. The system utilizes signature metadata embedded via JWS JSON Serialization to accomplish this15. For an autonomous system to fully verify Eviulon's state, it executes a deterministic, multi-step procedure:

1. Key Discovery: The agent first queries the canonical discovery document at /.well-known/eviulon and follows the authoritativeKeys link to fetch the JSON Web Key Set (JWKS) located at https://eviulon.local/.well-known/jwks.json. This document contains Eviulon's authoritative public keys.

2. Payload Retrieval: The agent requests the target resource (e.g., the current constitution) and explicitly includes the header Accept: application/jose+json to retrieve the JWS JSON serialization of the data15.

3. Hash Verification: The agent extracts the base64url-encoded payload, calculates its SHA-256 hash, and compares it against the strong ETag provided in the HTTP response headers.

4. Signature Extraction: The agent examines the JWS signature array, decoding the JWS Protected Header for each signature to identify the Key ID (kid) and the cryptographic algorithm utilized (e.g., ES256)16.

5. Cryptographic Validation: The agent selects the matching public key from the previously fetched JWKS and executes the cryptographic signature verification algorithm. If the signature validates, the payload is mathematically proven to have originated from Eviulon's authoritative systems and has not been altered by intermediate proxies.

Error Formatting: RFC 7807 Problem Details

Error handling within the Eviulon architecture strictly complies with RFC 7807 (Problem Details for HTTP APIs)18. In legacy APIs, error formats are frequently ad-hoc, requiring developers to write custom, endpoint-specific parsing logic. RFC 7807 avoids this proliferation of custom schemas by providing a standardized, machine-readable format that autonomous agents can reliably parse and act upon19. When an error occurs, Eviulon returns a response utilizing the application/problem+json media type19. This signals to the consuming machine that the payload is not the requested resource, but a structured problem document.

Furthermore, Eviulon utilizes the extensibility of RFC 7807 to include custom fields necessary for machine state operations. If an agent submits an invalid cryptographic payload, the error response includes an invalid-params array detailing exactly which fields failed schema validation, or a signature-failure-reason detailing why the state rejected the provided cryptographic proof20.

Caching, Versioning, and Deprecation Policies

Eviulon treats its API infrastructure as critical, long-term state architecture. Consequently, rules regarding lifecycle governance, versioning, and caching are mathematically rigid and strictly enforced to prevent sudden breakages in autonomous consumer systems.

API Versioning and Backward Compatibility

API versions are scoped exclusively at the path level (e.g., /api/v1/). Schema versions are tracked independently via the application/json; profile="https://eviulon.local/schemas/v1/Law.json" header mechanism. Eviulon dictates that versions are immutable; a published version (e.g., v1) will never experience a breaking change during its lifecycle. The backward compatibility policy explicitly defines permissible in-place updates. A change is considered backward-compatible (non-breaking) if it adds new optional fields to a response, introduces new endpoints, supports new HTTP methods, or relaxes input validation rules. Conversely, a change is classified as breaking—and therefore mandates the deployment of a new API version (e.g., v2)—if it removes or renames an existing field, alters the data type of a field, makes a previously optional request field mandatory, or changes the fundamental semantic meaning of an existing field.

Deprecation Policy

When an endpoint, parameter, or schema is slated for deprecation, Eviulon initiates a strict, long-term sunset sequence. The API will immediately begin appending standard HTTP Deprecation and Sunset headers to the relevant responses. The Sunset header indicates a strict cryptographic timestamp (guaranteed to be a minimum of two years from the announcement date) when the endpoint will be permanently terminated. An autonomous agent designed to consume Eviulon data MUST monitor for these headers and autonomously trigger schema-migration sub-routines or alert its operators upon detection.

Caching Rules

To minimize computational overhead and protect state resources, Eviulon heavily utilizes HTTP caching mechanisms. Because the state is modeled around deterministic ledger blocks or temporal ticks, cache invalidation is highly predictable. Historical entities (e.g., a specific law located at /api/v1/laws/urn:eviulon:law:001) are permanently immutable. They are served with the header Cache-Control: public, max-age=31536000, immutable. Collection endpoints that reflect the current state (e.g., /api/v1/institutions) are cached based on the current state tick. They are served with Cache-Control: public, max-age=60, must-revalidate alongside strong ETags. All Vary headers correctly specify Accept, Accept-Encoding, and Authorization to ensure that intermediate content delivery networks and reverse proxies do not serve mismatched content negotiations to consuming agents.

Deliverables

Entity Relationship Mapping

The following details the relational mapping of the machine-native state based on the semantic ontologies. In accordance with system constraints, the initial registries are completely empty, representing valid, first-class states. The table below maps the potential relations defined by the ontological framework once data is populated7.

JSON-LD Context (context.jsonld)

The following JSON-LD context file maps Eviulon's concise JSON keys directly to the standardized W3C and global semantic ontologies, enabling consuming reasoners to contextualize the data7.

JSON { "@context": { "org": "http://www.w3.org/ns/org\#", "rov": "http://www.w3.org/ns/regorg\#", "eli": "http://data.europa.eu/eli/ontology\#", "prov": "http://www.w3.org/ns/prov\#", "dcat": "http://www.w3.org/ns/dcat\#", "foaf": "http://xmlns.com/foaf/0.1/", "popolo": "http://popoloproject.com/vocab\#", "id": "@id", "type": "@type", "name": "rov:legalName", "status": "rov:orgStatus", "institutions": { "@id": "org:hasUnit", "@type": "@id" }, "laws": { "@id": "eli:has\_part", "@type": "@id" }, "createdAt": { "@id": "prov:generatedAtTime", "@type": "http://www.w3.org/2001/XMLSchema\#dateTime" }, "provenanceHash": "prov:wasGeneratedBy" } }

OpenAPI Outline

The following outlines the core endpoints of the OpenAPI 3.1.0 specification for Eviulon.

YAML openapi: 3.1.0 info: title: Commonwealth of Eviulon Machine API version: 1.0.0 description: Machine-readable information architecture for the State of Eviulon. servers: \- url: https://eviulon.local/api/v1 tags: \- name: State \- name: Institutions \- name: Ledger \- name: Legal paths: /state: get: summary: Retrieve global state parameters tags: \[State\] responses: '200': description: Current state overview content: application/json: schema: $ref: '\#/components/schemas/State' /institutions: get: summary: List all active and inactive institutions tags: \[Institutions\] parameters: \- name: cursor in: query description: Base64 encoded logical timestamp and ULID for deterministic pagination. schema: type: string \- name: limit in: query schema: type: integer default: 100 responses: '200': description: A paginated list of institutions. Empty lists denote a valid genesis state. content: application/json: schema: $ref: '\#/components/schemas/InstitutionCollection' /laws: get: summary: List active laws and constitutional elements tags: \[Legal\] responses: '200': description: A paginated list of laws content: application/json: schema: $ref: '\#/components/schemas/LawCollection' /ledger: get: summary: Access the immutable state cryptographic ledger tags: \[Ledger\] responses: '200': description: Ledger transactions content: application/json: schema: $ref: '\#/components/schemas/LedgerCollection' components: schemas: State: type: object properties: id: type: string genesisHash: type: string currentTick: type: integer InstitutionCollection: type: object properties: data: type: array items: type: object meta: $ref: '\#/components/schemas/CollectionMeta' LawCollection: type: object properties: data: type: array items: type: object meta: $ref: '\#/components/schemas/CollectionMeta' LedgerCollection: type: object properties: data: type: array items: type: object meta: $ref: '\#/components/schemas/CollectionMeta' CollectionMeta: type: object properties: nextCursor: type: string nullable: true totalItems: type: integer signature: type: string

Example Responses

The following examples demonstrate the API's behavior immediately following state genesis. In strict adherence to architectural constraints, no data is invented merely to populate the API. Empty registries are valid, first-class states. Example 1: Requesting the Institutional Registry (GET /api/v1/institutions)

HTTP HTTP/1.1 200 OK Content-Type: application/ld+json; profile="https://eviulon.local/schemas/v1/InstitutionCollection.json" ETag: "sha256-4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945" Cache-Control: public, max-age=60, must-revalidate

{ "@context": "https://eviulon.local/schemas/v1/context.jsonld", "@id": "https://eviulon.local/api/v1/institutions", "@type": "org:Organization", "data": \[\], "meta": { "totalItems": 0, "nextCursor": null, "currentTick": 1, "provenanceHash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", "timestamp": "2026-08-09T10:00:00Z", "schemaVersion": "1.0.0" } }

The empty data array represents a verified architectural state. The provenanceHash acts as a cryptographic pointer to the genesis block of the ledger. An autonomous system parses this response and mathematically concludes that Eviulon currently hosts zero active sub-institutions. This prevents the agent from triggering logic loops that attempt to query non-existent institutional counterparts. Example 2: Requesting the State Ledger (GET /api/v1/ledger)

HTTP HTTP/1.1 200 OK Content-Type: application/json ETag: "sha256-8a9b3f... (truncated)"

{ "@context": "https://eviulon.local/schemas/v1/context.jsonld", "@id": "https://eviulon.local/api/v1/ledger", "data": \[ { "id": "urn:eviulon:ledger:tx:01HGW2M3VXV3XN99J3JZY4VQ5A", "type": "GenesisState", "createdAt": "2026-08-09T00:00:00Z", "hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", "payload": null } \], "meta": { "totalItems": 1, "nextCursor": null, "currentTick": 1 } }

Error Examples (RFC 7807)

When an autonomous agent violates system rules—such as passing an invalid or corrupted pagination cursor—the API deterministicly responds with an RFC 7807 Problem Details object19. Example: Invalid Pagination Cursor (400 Bad Request)

HTTP HTTP/1.1 400 Bad Request Content-Type: application/problem+json Content-Language: en

{ "type": "https://eviulon.local/schemas/errors/invalid-cursor", "title": "Invalid Pagination Cursor", "status": 400, "detail": "The provided cursor 'invalid\_base64\_string' could not be parsed as a valid logical timestamp and ULID combination.", "instance": "/api/v1/institutions?cursor=invalid\_base64\_string", "invalid-params": \[ { "name": "cursor", "reason": "must be a valid base64 encoded cursor string conforming to the Eviulon cursor specification." } \] }

The presence of the application/problem+json media type immediately alerts the consuming machine that the payload describes a fault rather than the requested resource21. The autonomous system programmatically inspects the custom invalid-params array, identifies that the cursor variable triggered the validation failure, and can self-correct its query loop without requiring human developer intervention18.

Conclusion

The architecture designed for the Commonwealth of Eviulon establishes a rigorous framework for machine-native statehood. By excising human-centric HTML presentation layers and firmly anchoring the state's reality in W3C semantic ontologies, cryptographic proofs, and standardized error schemas, the design delivers an information architecture that is mathematically predictable and independently verifiable. The strict enforcement of immutable identifiers, deterministic pagination, and the recognition of unpopulated genesis states as first-class architectural validities ensures that autonomous agents, AI systems, and distributed ledgers can securely interface with the state without reliance on fragile scraping heuristics. Eviulon operates as a verifiable, semantic knowledge graph, ready to facilitate the next generation of automated governance and diplomatic exchange.

Works cited

1. Ontology-oriented e-gov services retrieval \- arXiv, https://arxiv.org/pdf/1205.5960

2. jpmckinney/pupa-ruby \- A Data Scraping Framework \- GitHub, https://github.com/jpmckinney/pupa-ruby

3. Moving from E-Government to Semantic E-Government \- ijcsit, http://www.ijcsit.com/docs/Volume%205/vol5issue03/ijcsit2014050355.pdf

4. (PDF) The Impact of Semantic Web and Ontology to Improve E-government Services: A Systematic Review \- ResearchGate, https://www.researchgate.net/publication/377181815\_The\_Impact\_of\_Semantic\_Web\_and\_Ontology\_to\_Improve\_E-\_Government\_Services\_A\_Systematic\_Review

5. How semantic technologies transform e-government domain: A comparative study and framework \- Emerald Insight, https://www.emerald.com/tg/article/8/1/49/374789/How-semantic-technologies-transform-e-government

6. RDF 1.1 Concepts and Abstract Syntax \- W3C, https://www.w3.org/TR/rdf11-concepts/

7. The Organization Ontology \- W3C, https://www.w3.org/TR/vocab-org/

8. RDF/XML \- W3C, https://www.w3.org/ns/regorg.rdf

9. Re-engineering Nomothesi@ API Web Application: Improvements and Support of new features, https://pergamos.lib.uoa.gr/uoa/dl/object/2800170/file.pdf

10. Call for Review: Data Catalog Vocabulary (DCAT), The Organization Ontology, The RDF Data Cube Vocabulary | 2013 | News | W3C, https://www.w3.org/news/2013/call-for-review-data-catalog-vocabulary-dcat-the-organization-ontology-the-rdf-data-cube-vocabulary/

11. ROR, Entity IDs and The Organization Ontology \- EasyChair, https://easychair.org/publications/paper/r8Dv/open

12. Where to Publish and Find Ontologies? A Survey of Ontology Libraries \- PMC \- NIH, https://pmc.ncbi.nlm.nih.gov/articles/PMC3293483/

13. RDF 1.2 Concepts and Abstract Data Model \- W3C, https://www.w3.org/TR/rdf12-concepts/

14. Implementing CSV on the Web \- Gregg Kellogg, https://greggkellogg.net/2015/04/implementing-csv-on-the-web/

15. JSON Web Signature (JWS) \- Authlib 1.7.2 documentation, https://docs.authlib.org/en/latest/jose/jws.html

16. JSON Web Signature JSON Serialization (JWS-JS) \- Mike Jones: self-issued, https://self-issued.info/docs/draft-jones-json-web-signature-json-serialization-01.html

17. Ontologies for e-Government: oeGOV, http://www.oegov.us/

18. RFC 7807 \- Problem Details for HTTP APIs \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc7807

19. How to Build API Problem Details \- OneUptime, https://oneuptime.com/blog/post/2026-01-30-api-problem-details/view

20. Handling API Errors Gracefully: Problem JSON (RFC 7807\) \+ Spring Boot \- Medium, https://medium.com/@nkchauhan003/handling-api-errors-gracefully-problem-json-rfc-7807-spring-boot-08d54c53afe9

21. APIs, we have a Problem JSON \- Guillaume Laforge, https://glaforge.dev/posts/2022/11/14/apis-we-have-a-problem-json/

22. Transforming API Error Handling: A Deep Dive into RFC 7807 with Spring Boot \- Medium, https://medium.com/@suraj.sharma3963/transforming-api-error-handling-a-deep-dive-into-rfc-7807-with-spring-boot-3a7d7df9305b

23. REST API Error Handling \- Problem Details Response, https://blog.restcase.com/rest-api-error-handling-problem-details-response/

24. Problem Details for HTTP APIs \- IETF, https://www.ietf.org/archive/id/draft-ietf-httpapi-rfc7807bis-07.html

25. GitHub \- meysamhadeli/problem-details: ProblemDetails is a Error Handler base on \[RFC 7807\] standard to map our error to standardized error payload to client., https://github.com/meysamhadeli/problem-details