Describing the aggregation service with the function ontology.

[argahsuknesib]

Pitch

The challenge is an extension of the solidlab challenge 84. The solid stream aggregator runs on top of a solid pod(s) to aggregate data streams. These data streams are generated by multiple sensors and devices and stored in the solid pod with the LDES in LDP specification. The solid stream aggregator aggregates over the data stream(s) based on a query to generate an aggregated data stream. The aggregated data stream is stored in the aggregator's solid pod. There is a need to re-trace the original data events which were aggregated to generate the aggregation event. This will enable the provenance of the aggregation event to understand the context of the generated aggregation event. A description will help to discover and re-use the results in other aggregation processes and therefore save computing time. The aggregation service as developed in the challenge 84 currently adds aggregation events in a pod with the LDES in LDP specification without any context of the aggregation service or the query involved to generate the events. The aggregation service should be extended to add a description of the aggregation service. The service can be described with the Function Ontology.

Desired Solution

A first version of the desired solution that can publish the aggregation events with a description of the aggregation service. The desired solution should be able to describe an instance of the aggregation function employed to generate the aggregation results. The function ontology can be used to describe the aggregation function, as well as the instance. The aggregation function's description contains the input parameters (the query, data source, the time window of aggregation, etc.) as well as the output (i.e. the generated aggregation event stream using the aggregation function, the location of the aggregation events). The generated aggregation event stream is stored in the pod following the LDES in LDP specification. The description, therefore, enables us to re-trace the generated aggregation event to the aggregation function employed to generate them. Moreover, it enables us to re-use the aggregation event in other aggregation processes save computing resources.

Acceptance Criteria

A description of the aggregation service is required. The publishing service should be able to generate LDP container(s) based on the aggregation service. In more detail, the following functionality is required :

• A publishing service that can publish the aggregation events with a description of the aggregation service with FnO.
• Functionality to re-trace the original data events from the aggregation event with a GET request.
• Functionality to request the description of the aggregation service used to generate the aggregation event with a GET request.

Scenarios

This is part of a larger scenario

[pheyvaer]

@pbonte Once you are doing with the review of the challenge, can you assign it to me? Thanks!

[argahsuknesib]

The demo is finished with the instructions described in the README of the repository here .

The repository,

• contains the code, along with step-by-step instructions.
• contains a publishing service for aggregation events which have an FnO description.
• demonstration of functionality to get the metadata of the aggregation event, i.e the aggregation function used to generate the event.
• demonstration of functionality to retrace back to the original events which were aggregated to generate the aggregation event.

[pheyvaer]

At first glance I don't see all items listed here in the README. Are they maybe mentioned somewhere else?

[argahsuknesib]

I added the sections on conclusion and lessons learned.