JOIN/SIGN UP
Already a Member? |
GET INVOLVED
Understanding and Engaging in COVESA Expert Groups & Projects |
COLLABORATIVE PROJECTS
HISTORICAL
SDV Telemetry Project |
We use cookies on this site to enhance your user experience. By using this site, you are giving your consent for us to set cookies. |
This is a preliminary page intended to trial using the Artifact design methodology (simplified) to guide and describe the project. At this stage it is a brainstorming WIP
Formulating the design problem
Improve (or solve) a <problem>
by designing an <artifact>
that satisfies <requirements>
in order to achieve <goal(s)>
Tip: Specific issue or challenge that requires a solution or improvement.
Data format incompatibility between data middleware and reasoner
Tip: Ultimate objective(s) that a solution aims to achieve, typically formed by the stakeholders' desires. In the context of COVESA, the goal of an artifact is inherit from the general COVESA goals defined as an alliance. In other words, each artifact will represent (minor or major) steps towards an ultimate goal.
Enabling the data exchange between data middleware and reasoner via websocket
Tip: Criteria and specifications that the artifact must meet to address the identified problem and achieve the set goals. Typically presented as functional and non-functional.
Functional:
Flexibility in JSON schema:
The converter should be able to handle different JSON schemas and adapt to changes in the schema without requiring significant modifications to the code.
Dynamic mapping:
The converter should support dynamic mapping between JSON and RDF, allowing for different mappings based on the specific JSON schema and the desired RDF representation.
RDF generation:
The converter should generate RDF data that adheres to the desired RDF representation, including appropriate subject-predicate-object triples.
Handling complex data structures:
The converter should be able to handle complex JSON data structures, such as nested objects and arrays, and convert them into appropriate RDF representations.
Error handling and reporting:
The converter should handle any errors that occur during the conversion process and provide meaningful error messages or logs to aid in debugging.
Non-functional:
Reliability:
The converter should be reliable and robust, ensuring that data is accurately converted without loss or corruption.
Maintainability:
The converter should be designed in a way that allows for easy maintenance, updates, and bug fixes, ensuring long-term sustainability.
Usability:
The converter should have a user-friendly interface or API, making it easy for developers or administrators to configure, monitor, and interact with the converter.
Tip: Represents the tangible outcome of a design that aims to solve the problem and fulfils the specified requirements and goals.
Convertor