CX-0084 Federated Queries in Data Spaces v1.2.0

ABSTRACT

This document provides a standard for a semantically-driven and state-of-the-art compute-to-data architecture for Catena-X, the so-called Knowledge Agents (KA) approach. It builds on well-established W3C-standards of the semantic web, such as OWL, SPARQL, SHACL, RDF etc. and makes these protocols usable to formulate powerful queries to the data space. Those queries can be used to answer business questions directly (comparable to a search engine) or they can be embedded in apps to include query results into workflows with more advanced visualization etc. The document addresses all stakeholders in Catena-X context that want to exchange data via the knowledge agents approach (data providers and consumers as well as app- and enablement service providers).

FOR WHOM IS THE STANDARD DESIGNED

The standard is relevant for the following roles:

• data & service provider/consumer
• business application provider

COMPARISON WITH THE PREVIOUS VERSION OF THE STANDARD

• External links have been changed to improve readability.
• The examples have been updated to reflect recent developments. In addition, the Asset Content Description subsection has been added.
• Code snippets and text updates in Agent-Related EDC Assets

1 INTRODUCTION

1.1 AUDIENCE & SCOPE

This section is non-normative

The standard is relevant for the following roles:

• Business Application Provider
• Enablement Service Provider
• Data Consumer
• Data Provider

In the following, we call one of the following affected stakeholders/solutions Knowledge Agent (KA)-enabled if it passes the Conformity Assessment Criteria (CAC, see Section 1.2 and Chapter 2):

• Business Application Provider: Applications that use KA technology on behalf of a Dataspace Participant (e.g. a Fleet Monitor, an Incident Reporting Solution).

• Enablement Service Provider: Services to assist Dataspace Participants/Applications in processing data based on KA technology (e.g. a Graph Database, a Virtual Graph Binding Engine, an EDC Package). As a second path, Companies are addressed that want to provide compute resources (for example by a server or other KA-enabled Applications or Services) based on instances/configurations of KA-enabled EDC Packages, for example a Recycling Software Specialist

• Data Consumer: Companies that want to use data and logic (for example by KA-enabled Applications or Services) based on instances/configurations of KA-enabled EDC Packages, such as a Recycling Company or a Tier-2 Automotive Supplier

• Data Provider: Companies that want to provide data (for example by a backend database or other KA-enabled Applications or Services) based on instances/configurations of KA-enabled EDC Packages, for example an Automotive OEM. Companies that want to provide functions (for example by a REST endpoint or other KA-enabled Applications or Services) based on instances/configurations of KA-enabled EDC Packages, for example a Tier1 Sensor Device Supplier

The CAC formulated in this standard comprise the following scope:

• Query and Search (Basic Mechanism, Integration in User Experiences)
• Services for making use of various federated data sources being part of a data space (Data & Function Provisioning, Logic Development & Provisioning)
• Semantic Modelling
• Publishing, Negotiation, Transfer Protocols and Policy Enforcement via IDS (EDC) connector

1.2 CONTEXT AND ARCHITECTURE FIT

This section is non-normative

The main objective concerning the approach described in this section is to create a state-of-the-art compute-to-data architecture for automotive use cases (and beyond) based on standards and best practices around GAIA-X and W3C. To reach this aim, full semantic integration, search and query with focus on relations between entities and data sovereignty is focused. In contrast to a simple file-based data transfer, this shifts the responsibility for the

1. access,
2. authorization to the data and
3. processing of the data

from the application development to the provider and hence ultimately, the actual owner of the data.

Figure 1: Basic Overview about Knowledge Agents approach

The most important concepts needed for the realization are summarized in Figure 1. The App in the figure serves the consumer by gathering, analyzing, and presenting the knowledge about business questions such as: How much of a certain material can be found in a specific vehicle series? It is assumed that the data which is needed to answer such questions is distributed over the network and cannot be found at one central place.

To help collecting the data over the network, Skills are introduced. A Skill is a pre-formulated query (or: procedure) with limited scope such as: List all vehicle series that contain material produced in a certain location. The Skill is used to access all federated data instances via the tenant (= authentication and authorization scope) of the caller.

A skill receives input in the form of a data set (we use a JSON notation in the following example):

[{"material":{"type":"literal","value":“Rubber”},"location":{"type":"literal","value":“Phuket”}}]

which drives the control flow, the filtering and aggregating of the information, and finally producing an output data set, for example:

[
  {"series":{"type":"uri","value":"OEM#4711"},"oem":{"type":"uri","value":"OEM"},"weightKg":{"type":"literal","datatype":"http://www.w3.org/2001/XMLSchema#float",”3.2”}},
  {"series":{"type":"uri","value":"EMO:0815"},"oem":{"type":"uri","value":"EMO"},"weightKg":{"type":"literal","datatype":"http://www.w3.org/2001/XMLSchema#float",”1.4”}}
]

In order to obtain the correct results in a federated system, all the participants of the skill execution need to have common understanding over the vocabulary (see following chapter). Relying on these conventions, an executor of a skill can calculate which providers are able to contribute or yield the necessary information in which sequence such that the resulting distributed operation will be performant.

This coordinating job is taken over by the Matchmaking Agent, an endpoint that is mandatory for any KA-enabled Dataspace Participant. For that purpose, the Matchmaking Agent supports the SPARQL specification (see chapter 3) with the effect that the dataspace can be traversed as one large data structure. Hereby, the Consumer-Side Matchmaking Agent will – as driven by the built-in federation features of SPARQL - interact with the KA-enabled EDC in order to negotiate and perform the transfer of Sub-Skills which are partial expressions of the original SPARQL command to other Dataspace Participants.

In turn, upon successful transfer of the Sub-Skill, the Provider-Side Matchmaking Agent(s) will be activated by their respective EDC. The precondition for this activation is of course that the Provider EDC first needs to offer a so-called Graph Asset:

Graph Assets are a variant of ordinary Data Assets (see the ANNEX) in the Catena-X EDC Standard; while Data Assets typically refer to an actual backend system (e.g., an Blob in an Object Store, an AAS server, a REST endpoint), Graph Assets introduce another intermediary instance, the so-called Binding Agent.

Simply put, the Binding Agent is a restricted version of the Matchmaking Agent (which speaks a profile, i.e., a subset of SPARQL specification, see the ANNEX) which is just focused on translating Sub-Skills of a particular business domain (Bill-Of-Material, Chemical Materials, Production Sites, etc.) into proper SQL- or REST based backend system calls. This scheme has several advantages:

• For different types of backend systems, business domains and usage scenarios, different Binding Agent implementations (Caching Graph Store, SQL Binding Engine, REST Binding Engine) can be switched-in without affecting both the shared dataspace/semantic model and the mostly immutable backend systems/data models as well.
• Access to the backend systems can be optimized by JIT compilation technology.
• The same backend system/data model can be used in various Graph Assets/Use Cases and different roles and policies.
• Access to the backend system is decoupled by another layer of security, such that additional types of policies (role-based row-level and attribute-level access) can be implemented in the interplay of Matchmaking and Binding Agents.
• There is a clear distinction between advanced graph operations (including type inference and transitive/recursive traversal also via EDC) on the Matchmaking Level and efficient, but more restricted and secure graph operations on the Binding/Data Level.

As mentioned earlier, essential for the realization of the idea is the creation, governance and discoverability of a well-defined semantic catalogue (the Federated Catalogue) which together with the data inside the Graph Assets forms a Federated Knowledge Graph. In this context, the definition of a Knowledge Graph (KG) as "a multi relational graph composed of entities and relations which are regarded as nodes and different types of edges, respectively" is extended with aspect of federation. We see a Federated KG as a KG where entities and relations reside physically distributed over multiple systems connected through a network and a common query language. We see semantic metadata as structural information to scope the entities and relations of the KG based on ontological principles. This is the agreement, necessary for the successful interplay of the distributed parties within the data space.

To summarize, the Knowledge Agent standard shall achieve the following abilities:

• the ability to define well-formed and composable computations/scripts (skills) which operate over various assets of various business partners.
• the ability to invoke and dynamically distribute these (sub-)skills over the relevant partners/connectors using an extensible agent interface.
• the ability to safely provide data and service assets via appropriate agent implementations which "bind" the skill to the backend execution engines (rather than mapping data).
• the ability for an agent/connector/business partner to decide
  • whether to hide particular data and computations inside a sub-skill
  • whether to delegate/federate particular computations/sub-skills to other agents
  • whether to migrate or clone an agent/asset from a partner
• the ability to describe data and service assets as well as appropriate federation policies in the IDS vocabulary in order to allow for a dynamic matchmaking of skills and agents.
• the ability to define domain/use case-based ontologies which form the vocabulary used in the skill definitions.
• the ability to visualize and develop the ontologies and skills in appropriate SDKs and User Experience components.

1.3 ARCHITECTURE OVERVIEW

This section is non-normative

This chapter gives an overview how the concept elaborated in previous chapter should be implemented. In this context generic building blocks were defined (see Figure 3) which can be implemented with different open source or COTS solutions. In the scope of Catena-X project these building blocks are instantiated with a reference implementation based on open source components. The detailed architecture that follows this reference implementation can be found as a high-level architecture in the Knowledge Agent KIT.

Figure 2: KA building blocks (Solid-Lines Denote Standard-Affected Layers & Components)

In the following paragraphs, all building blocks relevant for this version of the standard are introduced:

Ontology models

Ontologies, as defined by W3C Web Ontology Language OWL 2 standard, provide the core of the KA catalogue. OWL comes with several interpretation profiles for different types of applications. For model checking and data validation (not part of this standard), the Rule Logic (RL) profile is used. For query answering/data processing (part of this standard), the Existential Logic (EL) profile (on the Dataspace Layer) and the Query Logic (QL) profile (on the Binding Layer) is used. Furthermore, RDF Terse Triple Language TTL format is used to divide/merge large ontologies into/from modular domain ontology files.

The actual guidelines for how these domain ontologies are designed such that they are consistent with other is described in the sibling standard CX - 0067 Ontology Models to realize federated query in Catena-X.

Semantic Models are hosted in the Ontology Hub that is a central service to the dataspace based on git over http.

Data Consumption Layer/Query Definition

This layer comprises all applications which utilize provided data and functions of business partners to achieve a direct business impact and frameworks which simplify the development of these applications. Thus, this layer focuses on using a released Semantic Model (or a use-case/role-specific excerpt thereof) as a vocabulary to build flexible queries (Skills) and integrating these Skills in data consuming apps. Skills can be easily integrated in these apps as stored procedure. Hence, skill and app development can be decoupled to increase efficiency of the app development process.

SPARQL 1.1 specification is used as a language and protocol to search for and process data across different business partners. As a part of this specification, the QUERY RESULTS JSON and the QUERY RESULTS XML formats are used to represent both the answer sets generated by SPARQL skills and the sets of input parameters that a SPARQL skill should be applied to. For answer sets, additional formats such as the QUERY RESULTS CSV and TSV format may be supported. Required is the ability to store and invoke SPARQL queries as parameterized procedures in the dataspace; this is a KA-specific adaption to the SPARQL endpoint (the so-called KA-MATCH profile, see ANNEX) that is also captured in the concise OpenAPI specification. This API allows for an extended response behaviour which introduces a warning status (matching the HTTP response status code “203 - Non-Authoritative Information”) and an additional response header “cx_warning” that lists abnormal events or trace information that appeared during the processing in a data-sovereign manner.

Dataspace Layer

The base technology for building data spaces is the Eclipse Dataspace Connector (EDC) which should be extended to operate as a HTTP/S contracting & transfer facility for the SPARQL-speaking Matchmaking Agent. To resolve dataspace offers and addresses using the ontological vocabulary, the Matchmaking Agent keeps a default meta-graph, the Federated Catalogue, that is used to host the Semantic Model and that is regularly synchronized with the relevant dataspace information including the offers of surrounding business partners/EDCs.

The EDC interacts with the so-called Matchmaking Agent which is the first stage of SPARQL processing. It operates as the main invocation point to the Data Consuming Layer (using the KA-MATCH SPARQL profile). Furthermore, It operates as the main bridging point between incoming EDC transfers (from an “Agent Source” in the KA-TRANSFER SPARQL profile) and the underlying Binding Layer (speaking the KA-BIND SPARQL profile). And it implements federation by delegating any outgoing SERVICE/GRAPH contexts back to the EDC (using the KA-TRANSFER profile).

Figure 3: Standard-Affected Dataspace Components

Since EDC and Matchmaking Agent are bidirectionally coupled, implementations could merge Data Plane and Matchmaking Agent into a single package, the so-called Agent Plane. Agent Planes and ordinary Data Planes can co-exist due to our design choices.

The so called Federated Catalogue is an RDF data storage facility for the Matchmaking Agent. It could be an in-memory triple store (that is restored via downloading TTL and refreshing dataspace catalogues upon restart), a dedicated graph database using btree index files or even an ordinary relational database that has been adapted to fit to the chosen Matchmaking Agent implementation. One example of such an interface is the Eclipse RDF4J SAIL that is common for many SPARQL and RDF persistence engines.

The Federated Catalogue should initially download the complete Semantic Model that has been released for the target environment from the Ontology Hub. It should also contain a list of business partners and their roles which form the surrounding dataspace neighborhood of the tenant. For that purpose, it could use BPDM and Self-Description Hub services in order to lookup EDC addresses and additional domain information (sites, geo addresses). It should then be frequently updated with “live” information by invoking the EDC data management API to regularly obtain catalogue information. The portion of the Semantic Model describing these meta-data (Business Partners, Sites, Addresses, Use Cases, Use Case Roles, Connectors & Assets) is called the Common domain ontology and is mandatory for all releases/excerpts of the Semantic Model.

All relevant profiles and asset descriptions are explained in detail in the ANNEX. The interplay of the components and their respective interfaces in Figure 3 forms the basis of interoperability between EDC and backend systems within a single business partner's environment as well as interoperability between multiple business partners' dataspace segments.

Therefore, the Conformity Assessment (CA) as well as the individual Conformity Assessment Criteria (CAC) envisaged in this standard (see #2-conformity-assessment-criteria) have a focus on verifying the capabilities and functionalities of exactly these interfaces:

• between Consuming Application and Matchmaking Agent (KA-MATCH protocol profile - see #22-cac-for-matchmaking-agent)
• between Matchmaking Agent and Binding Agents (KA-BIND protocol profile - see #24-cac-for-binding-agents and #22-cac-for-matchmaking-agent)
• between EDC and Matchmaking Agent (Management API, Negotiation API, Endpoint Callback, KA-TRANSFER Invocation and Delegation - see #21-cac-for-edc and #22-cac-for-matchmaking-agent)
• between Federated Catalogue and EDC (Management/Catalogue API - see #21-cac-for-edc and #23-cac-for-federated-catalogue)
• between Matchmaking Agent and Federated Catalogue (Storage API - see #23-cac-for-federated-catalogue and #22-cac-for-matchmaking-agent)
• between Federated Catalogue and Core Services (raw download from git branch/tag - see #23-cac-for-federated-catalogue and #25-cac-for-ontology-hub)

Backend Systems

Legacy IT landscape of data space participants consisting of various backend systems, such as PLM, ERP, ObjectStores mostly located in the Enterprise Intranet and hosted/goverened by the business departments. Here, the actual data sources of all Catena-X participants is originated where they are served using custom, but mission-critical business or technological APIs in specific, transaction-oriented formats. From the standpoint of Knowledge Agents, also Digital Twin servers and registries such as following the IDTA AAS standards can be regarded as backend systems.

Virtualization Layer

The data virtualization layer fulfills the function of making the company internal, department-hosted data available for cross-company data exchange scenarios, e.g. via data lakes, data warehouses or other enterprise middleware. Instead of connecting each and every backend system separatly to an external data source/sink (such as Catena-X) it often makes sense to have this additional layer on top of backend systems which orchestrates data demand and supply across the systems. Depending on company IT architecture different technologies, such as virtual SQL databases, API gateways and extraction & transformation pipelines, can be used to build up this layer.

A special case of a virtualisation is the AAS-KA Bridge which makes the AAS API accessible to the upcoming binding layer in a generic manner. This will be elaborated in a later version of this standard.

Binding Layer

Finally, the missing link between the Dataspace Layer and the Virtualization Layer is the Binding Layer. Hereby rather than mapping the data between different formats (e.g. Data Tables in CSV Format to and from Data Graphs in the TTL format) which is a mostly resource-consuming data transformation process, binding rather rewrites the actual queries (e.g. SPARQL into SQL, SPARQL into GraphQL or REST). In order to make this query rewriting not too complicated, a restricted subset of SPARQL is envisaged.

A special case of a binding is the KA-AAS Bridge which maps between SPARQL modules in the same layer and AAS (as the target API). This will be elaborated in a later version of this standard.

1.4 CONFORMANCE

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED, REQUIRED, SHOULD and SHOULD NOT in this document document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.5 PROOF OF CONFORMITY

This section is non-normative

Certification against this standard is particulary relevant for Enablement Service Providers that provide solutions based on Knowledge Agents technology. All other data space participants (see audience & scope: data providers, data consumers, app providers) do not require certification but may use this standard as additional source of information if they want to use KA technology. To validate that the standards are applied correctly, Catena-X employs Conformity Assessment Bodies (CABs). Please refer to the association homepage for the process of conformity assessment and certification.

The Conformity Assessment Criteria (and proposed Conformity Assessment Methods) will be listed in Chapter 2 for the respective building blocks that are relevant for KA Enablement.

Corresponding to this standard, a testbed blueprint is provided in the Knowledge Agent KIT that covers most of the following CACs and CAMs. Up till now there is no operated testbed available. Thus, until this situation is resolved CAB may accept a self-assessment that all CACs are fulfilled by respective Enablement Service Provider.

1.6 Examples

The following examples are based on the Behaviour Twin use case (CX-0059 Use Case Behaviour Twin Endurance Predictor v1.3.0).

Data Binding

The following is an example binding in the OBDA format which translates between RDF triples (over the Catena-X domain ontologies related to vehicles and reliablity) and an underlying relational SQL database.

[PrefixDeclaration]
cx-common:          https://w3id.org/catenax/ontology/common#
cx-core:            https://w3id.org/catenax/ontology/core#
cx-vehicle:         https://w3id.org/catenax/ontology/vehicle#
cx-reliability:     https://w3id.org/catenax/ontology/reliability#
cx-taxo:            https://w3id.org/catenax/taxonomy#
uuid:        urn:uuid:
bpnl:        bpn:legal:
owl:        http://www.w3.org/2002/07/owl#
rdf:        http://www.w3.org/1999/02/22-rdf-syntax-ns#
xml:        http://www.w3.org/XML/1998/namespace
xsd:        http://www.w3.org/2001/XMLSchema#
json:             https://json-schema.org/draft/2020-12/schema#
obda:        https://w3id.org/obda/vocabulary#
rdfs:        http://www.w3.org/2000/01/rdf-schema#

[MappingDeclaration] @collection [[
mappingId vehicles
target uuid:{catenaXId} rdf:type cx-vehicle:Vehicle ; cx-vehicle:vehicleIdentificationNumber {localIdentifiers_van}^^xsd:string; cx-vehicle:manufacturer bpnl:{localIdentifiers_manufacturerId}; cx-vehicle:productionDate {manufacturingInformation_date}^^xsd:date.
source SELECT "catenaXId", "localIdentifiers_van", "localIdentifiers_manufacturerId", "manufacturingInformation_date" FROM "HI_TEST_OEM"."CX_RUL_SerialPartTypization_Vehicle" vehicles

mappingId partsvehicle
target uuid:{childCatenaXId} cx-vehicle:isPartOf uuid:{catenaXId} .
source SELECT "catenaXId", "childCatenaXId" FROM "HI_TEST_OEM"."CX_RUL_AssemblyPartRelationship" vehicleparts

mappingId   loadspectrum
target      uuid:{catenaXId}/{targetComponentId}/{metadata_componentDescription} rdf:type cx-reliability:LoadSpectrum; cx-core:id cx-taxo:{metadata_componentDescription}; cx-core:name {metadata_projectDescription}^^xsd:string; cx-reliability:description {metadata_routeDescription}^^xsd:string; cx-reliability:countingValue {header_countingValue}^^xsd:string; cx-reliability:countingUnit {header_countingUnit}^^xsd:string; cx-reliability:countingMethod {header_countingMethod}^^xsd:string; cx-reliability:channels {header_channels}^^json:Object; cx-reliability:classes {body_classes}^^json:Object; cx-reliability:values {body_counts_countsList}^^json:Object .
source SELECT "catenaXId", "targetComponentId", "metadata_projectDescription", "metadata_componentDescription", "metadata_routeDescription", "metadata_status_date", "header_countingValue", "header_countingUnit", "header_countingMethod", "header_channels", "body_counts_countsList", "body_classes" FROM "HI_TEST_OEM"."CX_RUL_LoadCollective" loadspectrum

...

]]

Function Binding

The following is an example binding in the RDF4J Repository Configuration Language which translates between RDF triples (over the Catena-X domain ontologies related to reliability and behavioural simulations) and an underlying relational REST backend performing a lifetime prognosis.

#
# Rdf4j configuration for a rul-specific remoting
#
@prefix rdf:            <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix rdfs:           <http://www.w3.org/2000/01/rdf-schema#>.
@prefix rep:            <http://www.openrdf.org/config/repository#>.
@prefix sr:             <http://www.openrdf.org/config/repository/sail#>.
@prefix sail:           <http://www.openrdf.org/config/sail#>.
@prefix sp:             <http://spinrdf.org/sp#>.
@prefix xsd:            <http://www.w3.org/2001/XMLSchema#> .
@prefix json:           <https://json-schema.org/draft/2020-12/schema#> .
@prefix dct:            <http://purl.org/dc/terms/> .
@prefix cx-fx:          <https://w3id.org/catenax/ontology/function#>.
@prefix cx-common:      <https://w3id.org/catenax/ontology/common#>.
@prefix cx-core:        <https://w3id.org/catenax/ontology/core#>.
@prefix cx-vehicle:     <https://w3id.org/catenax/ontology/vehicle#>.
@prefix cx-reliability: <https://w3id.org/catenax/ontology/reliability#>.
@prefix cx-behaviour:   <https://w3id.org/catenax/ontology/behaviour#>.

[] rdf:type rep:Repository ;
   rep:repositoryID "rul" ;
   rdfs:label "Remainig Useful Life Functions Repository" ;
   rep:repositoryImpl [
      rep:repositoryType "openrdf:SailRepository" ;
      sr:sailImpl [
         sail:sailType "org.eclipse.tractusx.agents:Remoting" ;
         cx-fx:supportsInvocation cx-behaviour:RemainingUsefulLife;
         cx-fx:callbackAddress <http://tiera-remoting-agent:8081/rdf4j-server/callback>;
      ]
   ].

cx-behaviour:RemainingUsefulLife rdf:type cx-fx:Function;
  dct:description "Remaining Useful Life is an asynchronous batch invocation."@en ;
  dct:title "Remaining Useful Life" ;
  cx-fx:targetUri "http://service-backend:5005/api/rul2";
  cx-fx:invocationMethod "POST-JSON";
  cx-fx:invocationMethod "POST-JSON";
  cx-fx:invocationIdProperty "header.notificationID,content.requestRefId";
  cx-fx:callbackProperty "header.respondAssetId".

cx-behaviour:countingUnit rdf:type cx-fx:Input;
  dct:description "Counting Unit of Load Spectrum."@en ;
  dct:title "Loadspectrum Counting Unit";
  cx-fx:dataType xsd:string;
  cx-fx:argumentName "content.endurancePredictorInputs.0.classifiedLoadSpectrum{https://w3id.org/catenax/ontology/behaviour#observationType}.header.countingUnit".

cx-behaviour:countingValue rdf:type cx-fx:Input;
  dct:description "Counting Value Name of Load Spectrum."@en ;
  dct:title "Loadspectrum Counting Value";
  cx-fx:dataType xsd:string;
  cx-fx:argumentName "content.endurancePredictorInputs.0.classifiedLoadSpectrum{https://w3id.org/catenax/ontology/behaviour#observationType}.header.countingValue,content.endurancePredictorInputs.0.classifiedLoadSpectrum{https://w3id.org/catenax/ontology/behaviour#observationType}.body.counts.countsName".

cx-behaviour:countingMethod rdf:type cx-fx:Input;
  dct:description "Counting Method of Load Spectrum."@en ;
  dct:title "Loadspectrum Counting Method";
  cx-fx:dataType xsd:string;
  cx-fx:argumentName "content.endurancePredictorInputs.0.classifiedLoadSpectrum{https://w3id.org/catenax/ontology/behaviour#observationType}.header.countingMethod".

cx-behaviour:headerChannels rdf:type cx-fx:Input;
  dct:description "Channels of Load Spectrum."@en ;
  dct:title "Loadspectrum Channels";
  cx-fx:dataType json:Object;
  cx-fx:argumentName "content.endurancePredictorInputs.0.classifiedLoadSpectrum{https://w3id.org/catenax/ontology/behaviour#observationType}.header.channels".

cx-behaviour:bodyClasses rdf:type cx-fx:Input;
  dct:description "Classes of Load Spectrum."@en ;
  dct:title "Loadspectrum Classes";
  cx-fx:dataType json:Object;
  cx-fx:argumentName "content.endurancePredictorInputs.0.classifiedLoadSpectrum{https://w3id.org/catenax/ontology/behaviour#observationType}.body.classes".

cx-behaviour:bodyCountsList rdf:type cx-fx:Input;
  dct:description "Counts List of Load Spectrum."@en ;
  dct:title "Loadspectrum Counts List";
  cx-fx:dataType json:Object;
  cx-fx:argumentName "content.endurancePredictorInputs.0.classifiedLoadSpectrum{https://w3id.org/catenax/ontology/behaviour#observationType}.body.counts.countsList".

  ...

cx-behaviour:RemainingUsefulLifeResult rdf:type cx-fx:Result;
  dct:description "The asynchronous notification response."@en ;
  dct:title "Asynchronous notification response." ;
  cx-fx:callbackProperty "header.referencedNotificationID";
  cx-fx:outputProperty "content.endurancePredictorOutputs";
  cx-fx:output cx-behaviour:remainingOperatingHours;
  cx-fx:output cx-behaviour:remainingRunningDistance.

cx-behaviour:remainingOperatingHours rdf:type cx-fx:ReturnValue;
  dct:description "Predicted Operating Hours of Remaining Useful Life Response"@en ;
  dct:title "Remaining Useful Life Operating Hours" ;
  cx-fx:valuePath "0.remainingUsefulLife.remainingOperatingHours";
  cx-fx:dataType xsd:float.

cx-behaviour:remainingRunningDistance rdf:type cx-fx:ReturnValue;
  dct:description "Predicted Distance of Remaining Useful Life Response"@en ;
  dct:title "Remaining Useful Life Distance" ;
  cx-fx:valuePath "0.remainingUsefulLife.remainingRunningDistance";
  cx-fx:dataType xsd:int.

Asset content description

The Asset Content Description explicitly states what data the asset provides. SHACL (Shape Constraint Language) is used to describe the content. As shown in the following examples, both data and functions can be described. At the same time, input parameters for functions can be described using the cx-sh:hasAsArgument property to specify what data is required as input (see federated query). This description allows automatic detection of data and its assets in a query. The descriptions are linked to assets using sh:shapesGraph property (see Agent-Related EDC Assets)

Asset content description of load spectrum data:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix schema: <http://schema.org/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix edc: <https://w3id.org/edc/v0.0.1/ns/> .
@prefix cx-common: <https://w3id.org/catenax/ontology/common#> .
@prefix cx-core: <https://w3id.org/catenax/ontology/core#> .
@prefix cx-vehicle: <https://w3id.org/catenax/ontology/vehicle#> .
@prefix cx-fx: <https://w3id.org/catenax/ontology/function#> .
@prefix cx-behaviour: <https://w3id.org/catenax/ontology/behaviour#> .
@prefix cx-reliability: <https://w3id.org/catenax/ontology/reliability#> .
@prefix cx-sh: <https://w3id.org/catenax/ontology/schema#> .
@prefix cx-taxo: <https://w3id.org/catenax/taxonomy#> .
@prefix : <https://w3id.org/catenax/taxonomy#GraphAsset?oem=BehaviourTwinReliability&shapeObject=> .

:LoadSpectrumShape a sh:NodeShape ;
    sh:targetClass  cx-reliability:LoadSpectrum;
    sh:property :observationOfShape, 
                :countingValueShape, 
                :countingUnitShape, 
                :countingMethodShape, 
                :channelsShape, 
                :classesShape, 
                :valuesShape.

:observationOfShape a sh:PropertyShape;
    sh:path cx-reliability:observationOf;
    sh:in (cx-taxo:GearOil cx-taxo:GearSet cx-taxo:Clutch).

:countingValueShape a sh:PropertyShape;
    sh:path cx-reliability:countingValue.

:countingUnitShape a sh:PropertyShape;
    sh:path cx-reliability:countingUnit.

:countingMethodShape a sh:PropertyShape;
    sh:path cx-reliability:countingMethod.

:countingMethodShape a sh:PropertyShape;
    sh:path cx-reliability:countingMethod.

:channelsShape a sh:PropertyShape;
    sh:path cx-reliability:channels.

:classesShape a sh:PropertyShape;
    sh:path cx-reliability:classes.

:valuesShape a sh:PropertyShape;
    sh:path cx-reliability:values.

Asset content description of prognosis (remaining useful life) function:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix schema: <http://schema.org/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix edc: <https://w3id.org/edc/v0.0.1/ns/> .
@prefix cx-common: <https://w3id.org/catenax/ontology/common#> .
@prefix cx-core: <https://w3id.org/catenax/ontology/core#> .
@prefix cx-vehicle: <https://w3id.org/catenax/ontology/vehicle#> .
@prefix cx-fx: <https://w3id.org/catenax/ontology/function#> .
@prefix cx-behaviour: <https://w3id.org/catenax/ontology/behaviour#> .
@prefix cx-reliability: <https://w3id.org/catenax/ontology/reliability#> .
@prefix cx-sh: <https://w3id.org/catenax/ontology/schema#> .
@prefix cx-taxo: <https://w3id.org/catenax/taxonomy#> .

# Prognosis Function
:PrognosisFunctionShape rdf:type sh:NodeShape ;
    sh:targetClass cx-behaviour:PrognosisFunction;
    sh:property [
        cx-sh:hasAsArgument cx-reliability:countingMethod;
        sh:path cx-behaviour:countingMethod;
    ];
    sh:property [
        cx-sh:hasAsArgument cx-reliability:countingValue;
        sh:path cx-behaviour:countingValue;
    ];
    sh:property [
        cx-sh:hasAsArgument cx-reliability:countingUnit;
        sh:path cx-behaviour:countingUnit;
    ];
    sh:property [
        cx-sh:hasAsArgument cx-reliability:channels;
        sh:path cx-behaviour:headerChannels;
    ];
    sh:property [
        cx-sh:hasAsArgument cx-reliability:classes;
        sh:path cx-behaviour:bodyClasses;
    ].

:RemainingUsefulLifeShape rdf:type sh:NodeShape ;
    cx-sh:extensionOf :PrognosisFunctionShape;
    sh:targetClass cx-behaviour:RemainingUsefulLife ;
      sh:property[
        cx-sh:hasAsArgument cx-reliability:observationOf;
        sh:path cx-behaviour:observationType;
        sh:in ( cx-taxo:GearSet cx-taxo:GearOil );
    ];
    sh:property :RemainingUsefulLifeResultShape.

:RemainingUsefulLifeResult rdf:type sh:PropertyShape;
    cx-sh:outputOf :RemainingUsefulLifeShape;
    sh:path cx-behaviour:RemainingUsefulLifeResult .

Federated Query

The following is an example of a parameterised query in SPARQL (using the Catena-X reliability and behaviour domains) that, given a vehicle identification number (@van), performs a lifetime prognosis for its differential gear over two dataspace hops (respective OEM and SUPPLIER) based on previous asset content descriptions.

PREFIX sh: http://www.w3.org/ns/shacl#
PREFIX schema: http://schema.org/
PREFIX rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns#
PREFIX rdfs: http://www.w3.org/2000/01/rdf-schema#
PREFIX xsd: http://www.w3.org/2001/XMLSchema#
PREFIX json: https://json-schema.org/draft/2020-12/schema#
PREFIX cx-sh: https://w3id.org/catenax/ontology/schema#
PREFIX cx-common: https://w3id.org/catenax/ontology/common#
PREFIX cx-core: https://w3id.org/catenax/ontology/core#
PREFIX cx-reliability: https://w3id.org/catenax/ontology/reliability#
PREFIX cx-schema: https://w3id.org/catenax/ontology/schema#
PREFIX cx-vehicle: https://w3id.org/catenax/ontology/vehicle#
PREFIX cx-behaviour: https://w3id.org/catenax/ontology/behaviour#
PREFIX cx-taxo: https://w3id.org/catenax/taxonomy#

################################################################
# Sample for a Provider-Deployed Goal-Oriented SparQL Skill which
#  - Depending on the targetted result
#  - Finds the right supplier prognosis asset and its preconditions
#  - jumps into the OEM-owned reliability asset to obtain the required data
#  - feeds the gathered data back into the respective supplier connector/agent 
#    to perform a behavioural prognosis
# Author: cgjung
# (c) 2023-2024 Catena-X assocation
################################################################

SELECT DISTINCT ?van ?supplier ?vehicle ?assembly ?operatingTime ?mileage ?prognosis WHERE {

  VALUES (?van ?aggregate ?result_type) { 
      ("@van"^^xsd:string "Differential Gear"^^xsd:string \<@resultType\>) 
  }

  # Determine the prognosis assets
  ?output sh:path ?result_type.
  ?output cx-sh:outputOf ?functionShape. 
  ?assetFunction cx-sh:shapeObject ?functionShape.
  ?functionConnector cx-common:offers ?assetFunction.
  ?functionShape cx-sh:extensionOf* ?parentFunctionShape.
  ?functionShape sh:targetClass ?function.
  ?parentFunctionShape sh:property ?functionProperty.
  ?functionProperty cx-sh:hasAsArgument ?argument.
  ?functionProperty sh:in ?parameters.
  ?parameters rdf:rest*/rdf:first ?ls_type.

  # Determine the target
  ?assetData cx-sh:shapeObject ?nodeShape.
  ?dataConnector cx-common:offers ?assetData.
  ?nodeShape sh:property ?propertyShape.
  ?propertyShape sh:path ?argument. 
  ?propertyShape sh:in ?parameters_target.
  ?parameters_target rdf:rest*/rdf:first ?ls_type.

  SERVICE ?dataConnector { 
    GRAPH ?assetData { 
        ?vehicle rdf:type cx-vehicle:Vehicle;
            cx-vehicle:vehicleIdentificationNumber ?van.

         ?assembly rdf:type cx-vehicle:Part;
            cx-vehicle:name ?aggregate;
            cx-vehicle:isPartOf ?vehicle;
            cx-vehicle:supplier ?supplier.
            
         ?teleAnalysis rdf:type cx-reliability:Analysis;
             cx-reliability:analysedObject ?assembly;
             cx-reliability:operatingHoursOfVehicle ?operatingTime;
             cx-reliability:mileageOfVehicle ?mileage;
             cx-core:startDateTime ?recordDate;
             cx-reliability:result [
                 cx-core:id ?ls_type;
                 cx-core:name ?ls_name;
                 cx-reliability:countingValue ?ls_value;
                 cx-reliability:countingUnit ?ls_unit;
                 cx-reliability:countingMethod ?ls_method;
                 cx-reliability:channels ?ls_channels;
                 cx-reliability:classes ?ls_classes;
                 cx-reliability:values ?ls_values
             ].
     }
  }

  SERVICE ?functionConnector {
    GRAPH ?assetFunction { 
      SELECT ?prognosis WHERE {
        ?invocation a ?function;
              cx-behaviour:sender <bpn:legal:BPNLOEM>;
              cx-behaviour:senderConnector <edc://sender>;
              cx-behaviour:recipient <bpn:legal:BPNLSUPPLIER>;
              cx-behaviour:recipientConnector <edc://recipient>;
              cx-behaviour:targetDate ?recordDate;
              cx-behaviour:timeStamp ?recordDate;
              cx-behaviour:component ?assembly;
              cx-behaviour:observationType ?ls_type;
              cx-behaviour:statusDate ?recordDate;
              cx-behaviour:statusOperatingHours ?operatingTime;
              cx-behaviour:statusMileage ?mileage;
              cx-behaviour:countingValue ?ls_value;
              cx-behaviour:countingUnit ?ls_unit;
              cx-behaviour:countingMethod ?ls_method;
              cx-behaviour:headerChannels ?ls_channels;
              cx-behaviour:bodyClasses ?ls_classes;
              cx-behaviour:bodyCountsList ?ls_values;
              ?result_type ?prognosis.
      }
    }
  } # SUPPLIER#CATALOG

} # SELECT

2. Conformity Assessment Criteria

This section is normative

2.1 CAC for EDC

CAC	Component	Normative Statement	Proposed Method
2.1.1	EDC Control Plane	MUST conform to the CX EDC Standard	See CX-0018
2.1.2	EDC Control Plane	MUST support the “HttpProxy” transfer process type which instruments/switches between different data planes according to the asset "type".	Configuration Review EDC property edc.dataplane.selector.* destinationtypes should contain HttpProxy Data Consumers: CAB offers a TESTGRAPHASSET and a TESTSKILLASSET. Assessed Party successfully negotiates and initiates a "HttpProxy" transfer for each of those assets. Data Providers: Assessed Party offers a TESTGRAPHASSET. CAB successfully negotiates and initiates a "HttpProxy" transfer. Skill Providers: Assessed Party offers a TESTSKILLASSET. CAB successfully negotiates and initiates a "HttpProxy" transfer.
2.1.3	EDC Control Plane	MUST register at least one KA-Enabled Data Plane	Configuration Review Data Consumers: EDC property dc.dataplane.selector. sourcetypes should contain "HttpData". Data Providers: EDC property dc.dataplane.selector. sourcetypes should contain "cx-common:Protocol?w3c:http:SPARQL". Skill Providers: EDC property dc.dataplane.selector.* sourcetypes should contain "cx-common:Protocol?w3c:http:SKILL".
2.1.4	EDC Control Plane	SHOULD support dynamic endpoint callback listeners. OR MUST register at least one Matchmaking Agent callback endpoint as listener	Code/Configuration Review EDC extension org.eclipse.edc:transfer-pull-http-dynamic-receiver is installed OR edc.receiver.http EDC property points to the Matchmaking Agent callback endpoint
2.1.5	EDC Control Plane	MAY support an extended validation endpoint for extended graph policies which need access to a runtime context	Assessed Party demonstrates an endpoint which accepts a valid transfer token together with a JSON object representing the runtime context.
2.1.6	EDC Data Plane	MUST conform to the CX EDC Standard, specifically MUST implement the “HttpProxy” transfer process type in combination with the “HttpData” asset type	See CX-0018
2.1.7	EDC Data Plane	MUST support the “HttpProxy” transfer process type in combination with the "cx-common:Protocol?w3c:http:SPARQL" and cx-common:Protocol?w3c:http:SKILL asset types. The registered Source implementation MUST support Graph Asset specifications and support the KA-TRANSFER protocol listed in the ANNEX. In particular it must process the “cx_header” parameter MUST support the “header:Accepts” and “header:Host” asset address properties. MUST require the “proxyBody”, “proxyQueryParams” and “proxyMethod” asset address properties to be true. MUST require the “proxyPath” asset address properties to be false. MUST rewrite the query (as parameter or body) to replace all occurrences of the asset:prop:id property by the “baseUrl” property MAY rewrite the query driven by additional asset address properties (“sh:shapeGraph”) MAY validate the query using an extended validation endpoint in the Control Plane and by deriving additional runtime context from parsing the query and the payload MUST delegate to the Matchmaking Agent using the KA-MATCH profile	Code/Configuration Review Data Provider: Assessed Party offers a TESTGRAPHASSET. CAB performs the transfer and evaluates the result. Skill Provider: Assessed Party offers a TESTSKILLASSET. CAB performs transfers in remote and local mode and evaluates the results. Data Consumer: CAB offers a TESTGRAPHASSET and a TESTSKILLASSET. Assessed Party performs transfers to each of them (both remote and local mode for TESTSKILLASSET) and evaluates the results.

2.2 CAC for Matchmaking Agent

CAC	Component	Normative Statement	Proposed Method
2.2.1	Matchmaking Agent	MUST support an endpoint callback conforming to the CX EDC Standard	See CX-0018 Assessed Party demonstrates a self-call with a TESTENDPOINTDATAREFERENCE tailored to a CAB-given endpoint. A subsequent self-call with a TESTENDPOINTSPARQL should hit the given CAB target.
2.2.2	Matchmaking Agent	MUST execute “Service <url>” contexts where the url starts with the “edc” or “edcs” schema, by parsing the sub-context or the url for an assetName (url#assetName or “GRAPH <assetName>”) and subsequently engage into a "HttpProxy" negotiation/transfer process with the Control plane addressed by the url when replacing the “edc” scheme with “http” and the “edcs” scheme with “https” respectively MAY perform simultaneous negotiations/transfers due to “Service ?url” calls when "?url" is bound to multiple addresses.	CAB offers TESTGRAPHASSET Assessed Party performs a TESTSERVICESPARQL to demonstrate successful delegation
2.2.3	Matchmaking Agent	MUST support the “/agent” GET endpoint of the KA-MATCH SPARQL profile	CAB offers TESTSKILLASSET Assessed Party performs a parameterized TESTGETSKILL request to successfully demonstrate invocation variants and error behaviour
2.2.4	Matchmaking Agent	MUST implement the “/agent” POST endpoint of the KA-MATCH SPARQL profile	CAB offers TESTSKILLASSET Assessed Party performs a parameterized TESTPOSTSKILL request to successfully demonstrate invocation variants and error behaviour
2.2.5	Matchmaking Agent	MUST implement the “/agent/skill” POST endpoint of the KA-MATCH SPARQL profile	Assessed Party invokes the endpoint using a TESTSKILL to successfully register a skill. Assessed Party then performs a parameterized TESTGETREGISTEREDSKILL request to successfully demonstrate invocation.
2.2.6	Matchmaking Agent	MAY perform a realm-mapping from the tenant domain (Authentication Scheme, such as API-Key and Oauth2) into the dataspace domain (EDC tokens)	Assessed Party demonstrates three TESTAUTHENTICATION calls, a successful one with a valid authentication code/token and two failing calls one with an invalid and one with a lacking code/token
2.2.7	Matchmaking Agent	SHOULD operate on the Federated Catalogue as an RDF store.	Assessed Party adds CAB control plane to its list of synchronized connectors. CAB changes its catalogue. Assessed Party demonstrates the DATASPACE skill reflecting that change
2.2.8	Matchmaking Agent	SHOULD be able to process Ontology models along the CX Ontology Standard and OWL-EL profile	See CX-0067 Assessed Party performs a TESTONTOLOGIYEL query.

2.3 CAC for Federated Catalogue

CAC	Component	Normative Statement	Proposed Method
2.3.1	Federated Catalog	MUST contain the Catena-X Ontology relevant to the respective release.	CAB accesses the Catena-X Ontology in the Ontology Hub. Assessed Party performs a TESTONTOLOGY retrieval to validate they are equivalent.
2.3.2	Federated Catalog	MUST contain data instantiating the Catena-X Common Domain Ontology (cx-common) related to the business partners of the assessed tenant	Assessed Party adds CAB control plane to its list of synchronized connectors. Assessed Party performs a TESTCATALOGUE retrieval to validate the available instance data against the BPNLs including the CAB
2.3.3	Federated Catalog	MUST frequently update catalogue data instantiating the Common Domain Ontology of the Semantic Model	Assessed Party adds CAB control plane to its list of synchronized connectors. Assessed Party performs a TESTCABASSETS retrieval to demonstrate that both catalogues are synchronized.

2.4 CAC for Binding Agents

CAC	Component	Normative Statement	Proposed Method
2.4.1	Data Binding Agent (Only relevant for Enablement Service Provider)	MUST implement the POST endpoint of the KA-BIND SPARQL profile	Assessed Party performs a TESTBINDINGSPARQLPOST call to demonstrate profile support
2.4.2	Data Binding Agent (Only relevant for Enablement Service Provider)	MAY implement the GET endpoint of the KA-BIND SPARQL profile	Assessed Party performs a TESTBINDINGSPARQLGET call to demonstrate profile support
2.4.5	Data Binding Agent (Only relevant for Enablement Service Provider)	SHOULD be able to process Ontology models along the CX Ontology Standard and OWL-QL profile	See CX-0067 Assessed Party performs a TESTONTOLOTYQLDATA query.
2.4.3	Function Binding Agent (Only relevant for Enablement Service Provider)	MUST implement the POST endpoint of the KA-BIND-F profile	Assessed Party performs a TESTFUNCTIONBINDINGSPARQLPOST call to demonstrate profile support
2.4.4	Function Binding Agent (Only relevant for Enablement Service Provider)	MAY implement the GET endpoint of the KA-BIND-F profile	Assessed Party performs a TESTFUNCTIONBINDINGSPARQLGET call to demonstrate profile support
2.4.6	Function Binding Agent (Only relevant for Enablement Service Provider)	SHOULD be able to process Ontology models along the CX Ontology Standard and OWL-QL profile	See CX-0067 Assessed Party performs a TESTONTOLOGYQLFUNCTION query.

2.5 CAC for Ontology Hub

CAC	Component	Normative Statement	Proposed Method
2.5.1	Ontology Hub (only for Core Service Provider)	MUST implement the git/http protocol	Assessed Party authorizes the CAB for acccess. CAB uses a git client to perform the most common git operations (clone, checkout, commit/push, fetch). CAB verifies the folder layout and compliance of the files with the TTL standard.
2.5.2	Ontology Hub (only for Core Service Provider)	MUST offer a public raw http/get access to the Catena-X ontology	CAB uses an http client such as curl to test the raw file access and checks the file for compliance with the TTL standard.
2.5.3	Ontology Hub (only for Core Service Provider)	MUST be able to host Ontology and Use Case models along the CX Ontology Standard	See CX-0067 CAB uploads a reference set of ontology and use case models.

3 REFERENCES

3.1 NORMATIVE REFERENCES

• CX-0018 Dataspace Connectivity v3.0.0
• CX-0067 Ontology Models to realize federated query in Catena-X v1.1.0
• OWL 2 Web Ontology Language Profiles (Second Edition)
• SPARQL 1.1 Query Language
• SPARQL Query Results JSON Format
• SPARQL Query Results XML Format
• Turtle - Terse RDF Triple Language
• Functional Requirements for Internet Resource Locators
• Functional Requirements for Unique Resource Names
• Uniform Resource Locators
• Internationalized Resource Identifiers
• git/http

3.2 NON-NORMATIVE REFERENCES

This section is non-normative

• CX-0059 Use Case Behaviour Twin Endurance Predictor v1.3.0
• W3C Semantic Web Body of Standards
• SPARQL Query Results CSV/TSV Format
• Eclipse RDF4J Framework
• Ontop Virtual Knowledge Graphs

3.3 REFERENCE IMPLEMENTATIONS

This section is non-normative

The Knowledge Agents EDC presents a reference implementation that satisfies the EDC, Matchmaking Agent and Federated Catalogue criteria.

The Knowledge Agents presents reference implementations that satisfy the Binding Agents criteria.

The Ontology repository and its redirection over https://w3id.org/catenax presents a reference implementation that satisfies the Ontology Hub criteria.

ANNEXES

SPARQL Profiles

The SPARQL Protocol And RDF Query Language is a query language and protocol for the Semantic Web. SPARQL provides powerful constructs to search, filter, traverse and even update globally dispersed information written in the Resource Description Framework. In particular, it operates very well with self-contained sources which have been modelled using the Web Ontology Language OWL2.

OWL2 provides several profiles (language restrictions and/or computational barriers) with decreasing degrees of complexity and expressivity: RL (rule logic), EL (existential logic) and QL (query logic). The lower the degree, the more reasoning engines are likely to support the given profile in practical applications.

In that tradition, this document proposes three profiles for SPARQL

• KA-BIND for binding large-volume (virtual) data lakes and API gateways to RDF processing
• KA-MATCH building on KA-BIND for orchestrating non-trivial computations on the individual and sovereign RDF processors
• KA-TRANSFER for tunneling KA-MATCH invocations through inter-company HTTP proxy infrastructure

These profiles are meant to standardize the usage of SPARQL as a scripting language in Dataspaces.

Dataspaces are a peer-to-peer technology and requires to form contract agreements between multiple parties based on the actual data chains.

In Catena-X, for example, a Dataspace that is based on IDS/GAIA-X infrastructure, these data chains follow the deep supply chains of the Automotive Industry in order to derive previously impossible use cases in the areas of Traceability, Distributed Simulation, etc.

The profiles defined in this document are implemented in the KA API specification

Figure 4: SPARQL profiles

KA-BIND

KA-BIND restricts SPARQL 1.1 in the following manner

• POST-GET: the endpoint should support the http verbs POST and GET
• CONTENT-TYPE: the endpoint should support at least "application/sparql-result+json" (default) and "application/sparql-result+xml" media types in its responses (and resolve the request Accepts header accordingly). The endpoint should support the "application/sparql-query" media type.
• ONLY-SELECT: only the Query Form SELECT is supported
• OWL-QL: only interoperates with the OWL2 QL profile
• DEFAULT-GRAPH: operates only on the default graph: No graph references (no GRAPH contexts, no FROM or TO clauses)
• NO-FEDERATION: no federation, i.e. interaction with remote services (no SERVICE contexts)
• BOUND-PREDICATES: no variables in the predicate of triple patterns
• NO-LITERAL-SUBJECT: no literals in the subject of triple patterns
• BOUND-TYPE-OBJECT: if the predicate is rdf:type/a then the object cannot be a variable
• NO-INVERSE: no inverse predicates (InversePath)
• NO-TRANSITIVITY: no transitive predicates (OneOrMorePath, ZeroOrMorePath, ZeroOrOnePath)
• NO-NEGATION: no negated predicates (NegatedPath)
• NO-BLANK-SOURCE-NODE: no blank nodes in the source documents (but working with anonymous nodes in the query is still allowed)

KA-BIND-F

KA-BIND-F (Function Restricted KA-BIND) restricts KA-BIND in the following manner:

• VALUES_STATEMENTS: The WHERE body of the SELECT query must consist of a (possibly empty) series of VALUES statements followed by a (possibly empty) series of triple patterns.

KA-MATCH

Let DRN (Dataspace Resource Name) be the subset of URN (Unique Resource Name which is a subset of IRI - Internationalized Resource Identifier) that denotes assets in the Dataspace. Examples in long and short-form are

GraphAsset?oem=Telematics2022
https://w3id.org/catenax/ontology/common#GraphAsset?oem=Telematics2022
SkillAsset?oem=ListVehicles
https://w3id.org/catenax/ontology/common#SkillAsset?oem=ListVehicles

GDRN (Graph Dataspace Resource Name) is the subset of DRN which denote proper graph assets.

SDRN (Skill Dataspace Resource Name) is the subset of DRN which denote skill assets.

Let DRL (Dataspace Resource Locator) be the subset of URL (Unique Resource Locator which is also a subset of IRI) that denotes connector addresses in the Dataspace. For that purpose, we introduce the schemes "edc" and "edcs" meaning that a party has to apply the proper dataspace protocols (which could be transferred via http or https respectively) in order to manage and access the resources under these addresses.

Examples are

edc://private.connector:8282
edcs://public.connector/protocol

If the DRL contains with an anchor part (#), we call the DRL qualified and that anchor part must url-encode a valid DRN.

Examples are

edc://private.connector:8282#GraphAsset%3Foem%3DTelematics2022
edcs://public.connector/protocol#SkillAsset%3Foem$3DListVehicles
edcs://public.connector/protocol#SkillAsset%3Foem$3DListVehicles?productionDate=2023&(vehicleSeries=213&vehicleSeries=215)

If the DRL contains parameters, the "(" character is only allowed in the beginning of parameter keys, the ")" character is only allowed at the end of parameter values. Opening and closing parenthesis need to match.

KA-MATCH restricts SPARQL in the following manner

• LIMITED-FEDERATION: any SERVICE context which binds to a DRL
  • if the DRL is unqualified, it must have EXACTLY ONE GRAPH sub-context which points to a GDRN. You may use only KA-BIND inside of that GRAPH context.
  • If the DRL is qualified:
    • if it anchors a SDRN then the context must only contain a sequence of BIND statements, because the SERVICE represents a (multi-valued) skill call.
    • it must NOT have ANY GRAPH sub-context. You may use only KA-BIND inside of the service context.
• OWL-EL: only interoperates with the OWL2 EL profile
• LIMITED-GRAPH: GRAPH references (FROM, TO or GRAPH contexts) must point to a GDRN or qualified DRL anchoring a GDRN.
• NO-LITERAL-SUBJECT: no literals in the subject of triple patterns

KA-MATCH extends SPARQL in the following manner

• POST-GET-OPTIONS: the endpoint should support the http verbs POST, GET and OPTIONS - the latter for the purpose to control cross-domain scripting (which is optional, so returning an error status is sufficient).
• POST-SKILL: There MUST be a sub-path "/skill" to the SPARQL endpoint which accepts a non-empty body of media type "application/sparql-query" and contains a valid KA-MATCH SPARQL text. It also requires a query parameter "asset" which is a valid SDRN. It returns a success code when these conditions are met and the text could be successfully stored. In that case, you may use the asset SDRN (for example as the anchor of a qualified DRL) in future GET and POST calls. The query text can contain variable references.
• ASSET-TARGET: In both the GET and POST Http Verbs, you may use the query parameter "asset" which should be set to some qualified DRL (global dataspace asset) or DRN (local asset). If the body of the request (POST) or the query parameter (POST or GET) is a valid SPARQL query (media type "application/sparql-query") then the asset MUST anchor a valid GDRN (in which case the query should be executed as if the TO/FROM clause would be set to the GDRN). Otherwise, the asset MUST anchor a valid SDRN (in which case the previously store query text from POST-SKILL is executed). We call the query text from either the query parameter (GET), the body (POST) or the skill asset lookup (GET and POST) the resolved query.
• PARAMETRIZED-QUERY: The resolved query may contain variable references (literals or iris starting with @ e.g., "@troubleCode"^^xsd:string or <@vin^^cx:Vehicle>). For each referenced variable, there must be either at least one correspondingly-named query parameter (GET, POST) or the media type of the body (POST) is one of "application/sparql-results+json" or "application/sparql-results+xml" and the variable is bound there. For variables bound as query parameters, there is the option to build tuple-based combinations by using open parentheses as the prefix of a variable/parameter name "(" and a closing parentheses ")" as the suffix of a substitution.
• RUN-MODE: In combination with ASSET-TARGET, the query parameter "runMode" can be used and take any of three values "consumer", "provider" or "all" (which is the default). This determines the preferred execution location of the protocol and may result in an error (Status Code >=400 and <500) depending on the actual contracts and policies associated to the affected asset.
• QUERY-LANG: The query parameter "queryLn" can be used, but is currently fixed to the value "SPARQL".
• WARNINGS: KA-MATCH may indicate a successful result that has been generated with additional warnings regarding the execution with the status code "203". Both in that case as well as in case of technically unsuccessful calls (Status Code <200 or >299), a response header “cx_warning” bound to a JSON structure that lists abnormal events or trace information that appeared during the processing.

The cx_warning JSON structure is a list of objects which contain at least the following properties

• source-tenant
• source-asset
• target-tenant
• target-asset
• problem
• context

[{"source-tenant":"http://consumer-control-plane:8181/management","source-asset":"urn:x-arq:DefaultGraph","target-tenant":"edcs://knowledge.dev.demo.catena-x.net/oem-edc-control/BPNL00000003COJN","target-asset":"GraphAsset?oem=Telematics20222","problem":"Failure invoking a remote batch: Result may be partial.","context":"1414472378"}]

Depending on data sovereignty rules, the individual fields may be shaded or replaced by pseudonyms such that they could be looked up via different (organizational) channels if needed.

KA-TRANSFER

KA-TRANSFER is a variant of KA-MATCH which allows to proxy the payloads over headerless or fixed-header protocols by implementing the following "WRAP-HEADERS" strategy:

KA-MATCH Component	KA-MATCH Name	KA-TRANSFER Component	KA-TRANSFER Name	Description
Request Header	Accept	Request URL Query Parameter	cx_accepts	This header is integral part of the protocol, since federating agents may require a particular result format in their internal processing.
Response Header	cx_warnings	Response multi-part body	cx_warnings	This header is integral part of the protocol in order to annotate and analyze a robust distributed processing which is always subject to unforeseen failures.

Agent-Related EDC Assets

In the following, we describe the convention how agent-related assets should be defined and represented in EDC.

Agent-related assets are

• Graph Assets: Assets providing access to a binding agent. We recommend to start the identification of each graph asset using the prefix "GraphAsset".
• Skill Assets: Assets providing access to logic that is stored in the matchmaking agent. We recommend to start the identification of each skill asset using the prefix "SkillAsset".

Since asset ids are used in some technical background, they should not contain colons (' : '), we recommend to identify them via url-type parameters, e.g., "GraphAsset?owner=content&property=value".

The asset definition in EDC is formulated in JSON-LD and consists of two parts:

• the "asset" part containing a description that is part of any published/offered catalogue that contains the asset.
• the "dataAddress" part containing EDC internal routing configuration for performing data transfers from/to the asset.

The following is an example of a valid graph asset definition. Please note that due to technical reasons, a valid definition needs to carry redundant information (such as about the type of asset) in order to mitigate version upgrades in the Catena-X standard body.

{
    "@context": {
        "cx-common": "https://w3id.org/catenax/ontology/common#",
        "cs-taxo": "https://w3id.org/catenax/taxonomy#",
        "edc": "https://w3id.org/edc/v0.0.1/ns/",
        "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
        "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
        "sh": "http://www.w3.org/ns/shacl#",
        "dct": "https://purl.org/dc/terms/"
    },
    "@type": "Asset",
    "@id": "cx-taxo:GraphAsset?supplier=BehaviourTwinRUL", 
    "properties": {
        "cx-common:name": "Lifetime Prognosis Service for Gearboxes",
        "cx-common:description": "A sample graph asset/offering referring to a specific prognosis resource.",
        "cx-common:description@de": "Ein Beispielasset für eine Prognosefunktion.",
        "cx-common:version": "1.11.16",
        "cx-common:contenttype": "application/json, application/xml",
        "cx-common:publishedUnderContract": "Contract?supplier=Graph",
        "dct:type": "cx-taxo:GraphAsset",
        "rdfs:isDefinedBy": "<https://w3id.org/catenax/ontology/common>,<https://w3id.org/catenax/ontology/core>,<https://w3id.org/catenax/ontology/function>,<https://w3id.org/catenax/ontology/behaviour>,<https://w3id.org/catenax/ontology/reliability>",
        "cx-common:implementsProtocol": "cx-common:Protocol?w3c:http:SPARQL",
        "sh:shapesGraph": 
            "@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
            @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
            @prefix schema: <http://schema.org/> .
            @prefix sh: <http://www.w3.org/ns/shacl#> .
            @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
            @prefix edc: <https://w3id.org/edc/v0.0.1/ns/> .
            @prefix cx-common: <https://w3id.org/catenax/ontology/common#> .
            @prefix cx-core: <https://w3id.org/catenax/ontology/core#> .
            @prefix cx-vehicle: <https://w3id.org/catenax/ontology/vehicle#> .
            @prefix cx-fx: <https://w3id.org/catenax/ontology/function#> .
            @prefix cx-behaviour: <https://w3id.org/catenax/ontology/behaviour#> .
            @prefix cx-reliability: <https://w3id.org/catenax/ontology/reliability#> .
            @prefix cx-sh: <https://w3id.org/catenax/ontology/schema#> .
            @prefix cx-taxo: <https://w3id.org/catenax/taxonomy#> .
            @prefix : <https://w3id.org/catenax/taxonomy#GraphAsset?oem=BehaviourTwinReliability&shapeObject=> .

            :LoadSpectrumShape a sh:NodeShape ;
                sh:targetClass  cx-reliability:LoadSpectrum;
                sh:property :observationOfShape, 
                            :countingValueShape, 
                            :countingUnitShape, 
                            :countingMethodShape, 
                            :channelsShape, 
                            :classesShape, 
                            :valuesShape.

            :observationOfShape a sh:PropertyShape;
                sh:path cx-reliability:observationOf;
                sh:in (cx-taxo:GearOil cx-taxo:GearSet cx-taxo:Clutch).

            :countingValueShape a sh:PropertyShape;
                sh:path cx-reliability:countingValue.

            :countingUnitShape a sh:PropertyShape;
                sh:path cx-reliability:countingUnit.

            :countingMethodShape a sh:PropertyShape;
                sh:path cx-reliability:countingMethod.

            :countingMethodShape a sh:PropertyShape;
                sh:path cx-reliability:countingMethod.

            :channelsShape a sh:PropertyShape;
                sh:path cx-reliability:channels.

            :classesShape a sh:PropertyShape;
                sh:path cx-reliability:classes.

            :valuesShape a sh:PropertyShape;
                sh:path cx-reliability:values.",
        "cx-common:isFederated": "true^^xsd:boolean"
    },
    "dataAddress": {
        "id": "cx-taxo:GraphAsset?supplier=BehaviourTwinRUL", 
        "@type": "DataAddress",
        "baseUrl": "{{tierARemotingAgent}}/repositories/rul",
        "type": "cx-common:Protocol?w3c:http:SPARQL",
        "proxyPath": "false",
        "proxyMethod": "true",
        "proxyQueryParams": "true",
        "proxyBody": "true",
        "authKey": "{{supplierBackendAuthKey}}",
        "authCode": "{{supplierBackendAuthCode}}",
        "cx-common:allowServicePattern": "{{tierARemotingAgent}}/repositories/rul"
    }
  }

Common Asset Properties

In particular, the "asset" part of each asset description has a natural correspondence in the RDF representation of the Federated Catalogue. To define this correspondence in the following, we assume the following prefix abbreviations to denote complete IRIs.

Prefix	Namespace	Property Domain
edc	https://w3id.org/edc/v0.0.1/ns/	EDC annotations
rdf	http://www.w3.org/1999/02/22-rdf-syntax-ns#	RDF type annotations
rdfs	http://www.w3.org/2000/01/rdf-schema#	RDF schema annotations
dct	https://purl.org/dc/terms/#	Dublin Core annotations
owl	http://www.w3.org/2002/07/owl#	OWL model annotations
xsd	http://www.w3.org/2001/XMLSchema#	XML schema annotations
json	https://json-schema.org/draft/2020-12/schema#	JSON schema annotations
sh	http://www.w3.org/ns/shacl#	SHACL constraints
cx-common	https://w3id.org/catenax/ontology/common#	Catena-X common annotations
cx-taxo	https://w3id.org/catenax/taxonomy#	Catena-X taxonomy declarations

The "asset" part itself mainly consists of a "properties" section which is a set of string-based key-value pairs. In the following table, we list those keys which are of relevance for both Graph and Skill Assets and hence are mapped to an RDF expression.

Property Key	Mandatory	Description	RDF Representation	Example Property Value
edc:id, @id	yes	Plain Id of the Asset	BIND(<value> as ?asset). ?asset cx-common:id "value".	GraphAsset?oem=TelematicsSample
edc:name	yes	Default Name of the Asset	?asset cx-common:name "value"^^xsd:string.	Telematics Data 2022
edc:name@de	no	German Name of the Asset	?asset cx-common:name "value"^^xsd:string@de.	Telematik Daten 2022
edc:description	no	Default Description of the Asset	?asset cx-common:description "value"^^xsd:string.	Telematics Data for Series 213 from 20022
edc:description@de	no	German Description of the Asset	?asset cx-common:description "value"^^xsd:string@de.	Telematik Daten für BR 213 aus 20022
edc:contenttype	yes	Mime Type of Asset response	?asset cx-common:contentType "value".	application/sparql-results+json, application/sparql-results+xml
dct:type	yes	Type IRI of the asset	?asset dct:type <value>.	cx-taxo:GraphAsset for Graphs, cx-taxo:SkillAsset for Skills
rdfs:isDefinedBy	yes	Use Case / Domain Ontology IRIs	?asset rdfs:isDefinedBy value.	https://w3id.org/catenax/usecase/behaviourtwin
cx-common:version	no	Version of the Asset	?asset cx-common:version "value".	1.9.3-SNAPSHOT (Prefix changed in 1.1.0 from edc:version)
cx-common:implementsProtocol	yes	Asset Protocol IRI	?asset cx-common:implementsProtocol <value>.	cx-common:Protocol?w3c:http:SPARQL
cx-common:publishedUnderContract	no	Contract IRI	?asset cx-common:publishedUnderContract <value>.	Contract?oem=GraphContract
cx-common:satisfiesRole	yes	Use Case Role IRI	?asset cx-common:satisfiesRole <value>.	Role?oem=BehaviourTwin
cx-common:isFederated	yes	Determines whether this asset should be synchronized in the Federated Catalogue	?asset cx-common:protocol value.	true^^xsd:boolean

Graph Assets and Addresses

Graph assets need a asset content description in terms of the constraint language SHACL

Property Key	Mandatory	Description	RDF Representation	Example Property Value
sh:shapesGraph	yes	SHACL Description of Graph	?asset sh:shapesGraph <graph>. (where the constraints can be accessed via GRAPH <graph> )	SHACL TTL

The "dataAddress" part for Graph Assets also consists of a set of string-based key-value pairs. Since that part is not public, it will not have an RDF representation. In the following table, we list those keys which are of relevance for Graph Assets.

Property Key	Mandatory	Description	Example Property Value
edc:id	yes	Plain Id of the Graph Asset must coincide with @id and edc:id of "asset" part	GraphAsset?oem=TelematicsSample
edc:type	yes	Asset Protocol IRI must coincide with cx-common:implementsProtocol of "asset" part	cx-common:Protocol?w3c:http:SPARQL
edc:baseUrl	yes	URL of the binding Agent	https://knowledge.dev.demo.catena-x.net/conforming-agent/bind
edc:proxyPath	yes	must be set to “false”	false
edc:proxyMethod	yes	must be set to “true”	true
edc:proxyQueryParams	yes	must be set to "true"	true
edc:proxyBody	yes	must be set to "true"	true
edc:authKey	no	optional authentication header	X-Api-Key, Authorization
edc:authCode	no	optional authentication value	my-api-key, Basic Adm9axmJhcg==
cx-common:acceptsContentType	no	optional fixed Accepts header forwarded to the endpoint	application/sparql-results+json

Skill Assets and Addresses

The following is an example of a Skill Asset.

{
    "@context": {
        "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
        "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
        "cx-taxo": "https://w3id.org/catenax/taxonomy#",
        "cx-common": "https://w3id.org/catenax/ontology/common#",
        "dct": "https://purl.org/dc/terms/",
        "sh": "http://www.w3.org/ns/shacl#"
    },
    "properties": {
      "name": "Lists Vehicles By Production Date and Series",
      "description": "A sample skill asset/offering operating on vehicle/part ontology.",
      "cx-common:version": "1.9.3-SNAPSHOT",
      "contenttype": "application/json, application/xml",
      "cx-common:publishedUnderContract": "Contract?oem=Skill",
      "dct:type": {
        "@id": "cx-taxo:SkillAsset"
      },
      "rdf:type": "cx-common:SkillAsset",
      "rdfs:isDefinedBy": "<https://w3id.org/catenax/usecase/behaviourtwin>,<https://w3id.org/catenax/ontology/common>,<https://w3id.org/catenax/ontology/core>,<https://w3id.org/catenax/ontology/vehicle>,<https://w3id.org/catenax/ontology/part>",
      "cx-common:implementsProtocol": "cx-common:Protocol?w3c:http:SKILL",
      "cx-common:distributionMode": "cx-common:SkillDistribution?run=all",
      "cx-common:isFederated": "true^^xsd:boolean"
    },
    "privateProperties": {
          "cx-common:query":"SELECT ?s WHERE { ?s a <https://w3id.org/catenax/ontology/vehicle#Vehicle>; <https://w3id.org/catenax/ontology/part#productionDate> ?date. FILTER(year(?date) = \"@productionYear\"^^xsd:integer.)}"
    },
    "dataAddress": {
      "id":"SkillAsset?oem=ListVehicles",
      "@type": "DataAddress",
      "type": "cx-common:Protocol?w3c:http:SKILL",
      "proxyPath": "false",
      "proxyMethod": "true",
      "proxyQueryParams": "true",
      "proxyBody": "true"
  }
}

Skill assets need a public self-description which determines whether the skill can be invoked locally (at the site of the consumer), remotely (at the site of the provider) or both

Property Key	Mandatory	Description	RDF Representation	Example Property Value
cx-common:distributionMode	yes	Distribution mode of the skill	?asset cx-common:distributionMode <value>	cx-common:SkillDistribution?run=provider cx-common:SkillDistribution?run=consumer cx-common:SkillDistribution?run=all

Please note that according to the mirroring roles of provider and consumer, the "cx-common:distributionMode" setting mirrors the approriate "runMode" query parameter (RUN-MODE) in the KA-MATCH protocol profile. That is, a "runMode=consumer" invocation requires a "cx-common:distributionMode" of "cx-common:SkillDistribution?run=consumer" or "cx-common:SkillDistribution?run=all". A "runMode=provider" invocation requires a "cx-common:distributionMode" of "cx-common:SkillDistribution?run=provider" or "cx-common:SkillDistribution?run=all". A "runMode=all" will resolve to "runMode=consumer" if "cx-common:distributionMode" is set to "cx-common:SkillDistribution?run=consumer". It will resolve to "runMode=provider" if "cx-common:distributionMode" is set to "cx-common:SkillDistribution?run=provider". Else it will resolve to either "runMode=consumer" or "runMode=provider" depending on the consumer preferences/configuration.

Skill assets also use the "privateProperties" section of the "asset" definition which is a set of string-based key-value pairs that is only visible to the publisher.

Property Key	Mandatory	Description	RDF Representation	Example Property Value
cx-common:query	yes	A valid KA-MATCH SPARQL query	SELECT ?s WHERE { ?s a <https://w3id.org/catenax/ontology/vehicle#Vehicle\>. }

The "dataAddress" part for Skill Assets consists of the following properties.

Property Key	Mandatory	Description	Example Property Value
edc:id	yes	Plain Id of the Skill Asset must coincide with @id and edc:id of "asset" part	SkillAsset?oem=ListVehicles
edc:baseUrl	yes	must be empty
edc:proxyPath	yes	must be set to “false”	false
edc:proxyMethod	yes	must be set to “true”	true
edc:proxyQueryParams	yes	must be set to "true"	true
edc:proxyBody	yes	must be set to "true"	true‚

Legal

Copyright © 2024 Catena-X Automotive Network e.V. All rights reserved. For more information, please visit here.