Closed ccamel closed 7 months ago
The recent updates enhance and introduce schemas for various credentials, focusing on digital resources, services, and governance. Key additions include domain information across multiple credentials, the introduction of schemas for orchestration service execution and its order, and a new execution status. These changes aim to enrich the metadata and interoperability of digital credentials within a structured ecosystem.
Files | Change Summary |
---|---|
docs/schemas/credential-dataset-description.md docs/schemas/credential-digital-resource-publication.md docs/schemas/credential-digital-resource-rights.md docs/schemas/credential-digital-service-authentication.md docs/schemas/credential-digital-service-description.md docs/schemas/credential-zone-description.md |
Added domain information for specified properties in various credentials. |
docs/schemas/credential-governance-text.md |
Updated sidebar_position and added a new Domain entry. |
docs/schemas/credential-orchestration-service-execution-order.md docs/schemas/credential-orchestration-service-execution.md |
Introduced schemas for Orchestration Service Execution and its Order with detailed properties. |
script/cli/templates/schema.md.j2 |
Enhanced schema template to display domain information for properties. |
src/schema/orchestration-service/... |
Introduced RDF schema definitions for orchestrating service execution orders and details. |
src/thesaurus/digital-service-execution-status.ttl |
Added a new concept InExecution for Digital Service execution progress. |
π°β¨
In the digital fields where data streams flow,
New schemas bloom, and credentials grow.
With each update, a richer tale we weave,
Of services orchestrated, in the web we believe.
Here's to the changes, may they guide us right,
Through the digital maze, into the light.
πππ
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
This PR is a redesign of the concepts of execution order and execution result, which, after discussion with @amimart, appears to have ambiguities and inaccuracies. The redesign aims to clarify these concepts and to unambiguously define the relationships they have with other ontology concepts.
Orchestration Services
To understand the redesign, it's essential first to recall the different kind of resources we have:
It's important to understand that digital services are consumables, meaning these are services that can only be invoked by an orchestration service. One cannot issue orders directly to a digital service without going through an orchestration service. Orchestration services listen for transactions on the chain and respond according to directives (orders) presented in the form of a Verifiable Credential (VC).
The VC Orchestration Service Execution Order
This VC instructs an Orchestration Service to carry out an execution. It's crucial to understand here that the order is expressed without necessarily showing the resources that will be involved in the processing. Indeed, this is subject to interpretation by the Orchestration Service, which, based on the elements of the command provided, determines the resources engaged or not. (if you love logic theory, this is an approach by intention - https://en.wikipedia.org/wiki/Extensional_and_intensional_definitions).
The VC Orchestration Service Execution
This VC represents an ongoing or final execution of an Orchestration Service relative to an Orchestration Service Execution Order. Here, the VC contains references to the resources involved, both consumed and produced. The VC also reflects the progress.
Workflow Overview
I'll briefly describe the orchestration workflow involving these two Verifiable Credentials (VCs).
OSEO (Orchestration Service Execution Order)
When a user wants to initiate an orchestration, they select the orchestration service and create (and sign) an Orchestration Service Execution Order Credential, specifying the orchestration service as the subject. The user must provide all the required arguments. Then, they submits this VC to the blockchain.
OSE (Orchestration Service Execution)
Once the OSEO is recorded on the blockchain, the orchestration service is notified and begins execution. Based on its understanding of the order, it identifies the resources needed, then creates (and signs) an OSE with an
InExecution
status, which is submitted to the blockchain. This OSE certifies the rights & permissions granted for the proper execution of the workflow. The OSE is updated to reflect the service's completion status, eitherFailed
orDelivered
.In more complex scenarios where the orchestration involves a workflow, multiple OSEs are issued to describe the processing chain in a hierarchical manner.
Summary by CodeRabbit
InExecution
to denote ongoing digital service execution.