Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

doc: add guidance on quality assets #567

Merged
merged 6 commits into from
Jan 23, 2024
Merged

doc: add guidance on quality assets #567

merged 6 commits into from
Jan 23, 2024

Conversation

arnoweiss
Copy link
Contributor

@arnoweiss arnoweiss commented Dec 14, 2023 •
edited
Loading

Description

The Quality Use-Case requires a disambiguous detailed definition of the assets.

Todos:

  • Completion of the four asset types in the kit
  • addition of the quality assets in the taxonomy
  • explanation of the two remaining s3-dataadress-properties
  • Decision on additional properties

The following properties were discussed before but left out.

Property Example Description
creationDate <someDatetimeInSpecifiedFormat> The idea is that an updated dataset should be registered new. Whether this is the correct update pattern remains to be discussed
originator/publisher <someBpn> This should be clear from the connector that serves the data and is explicitly stated in the catalog-response
keywords quality, OemName Introducing search criteria makes sense in general but should be done via well-defined properties instead of a generic one.
curatorOrganizationName <someString> EDC Properties are not primarily aimed at humans but rather algorithms processing them and this should thus be left out. Also, it's redundant to the BPN.
usecase QUALITY_opco-int_1023 Landscape is known from runtime context and as a filter criterion the dct:type property should be used.

Pre-review checks

Please ensure to do as many of the following checks as possible, before asking for committer review:

@markuskeidl
Copy link
Contributor

Quality currently has 7 (8) relevant aspect models / asset types, see https://eclipse-tractusx.github.io/docs-kits/kits/Quality-Kit/Adoption%20View%20Quality%20Kit#semantic-models

Quality Task, Vehicles (inlcudes Product Description), Claim Data, Diagnostic Data, Manufacturerd Parts Quality Information, Party Analyses, and Quality Task Attachement.

@arnoweiss arnoweiss mentioned this pull request Jan 17, 2024
Merged
@arnoweiss arnoweiss marked this pull request as ready for review January 17, 2024 16:58
@arnoweiss arnoweiss requested review from markuskeidl, ClaudiaKilian and SebastianBezold and removed request for markuskeidl January 17, 2024 16:58
markuskeidl
markuskeidl reviewed Jan 22, 2024
View reviewed changes
docs-kits/kits/Quality-Kit/Software Development View/page_software-development-view.md Outdated
| `https://purl.org/dc/terms/conformsTo` | `{"@id":"<urnOfTheCorrespondingAspectModel>"}` | This property is QM-specific. It holds the exact aspect-model-URN that defines the schema of the presented dataset including its version. The version in here refers to the data model's version while the EDC-property `cx-common:version` defines the version of the underlying API serving the data. |
| `http://www.w3.org/ns/dcat#qualifiedRelation` | `{"dct:isPartOf": {"@id": "<idOfTheCorrespondingQualityTask>"}}` | This property is QM-specific. All Asset types defined in this Kit must include this property as it links the data behind an asset with the correct QualityTask. Note that the id of the QualityTask must be used, not the id of the EDC-Asset shielding said QualityTask. |
| `https://w3id.org/edc/v0.0.1/ns/type` | `AmazonS3` | This property signifies the EDC dataplane that the QM data will be transferred over. The expectation that this would be signaled via the dcat:DataSet-dcat:distribution property of the catalog currently isn't implemented in the EDC. Thus the data must be replicated here and is presented via the same property that the consumer-side `transferprocesses` API uses for this same signal. |
| `https://w3id.org/catenax/ontology/common#version` | `"1.0"` | CX-0018 recommends to use cx-common:version to signify the API's version. Since QM has a tight connection between the API and the datamodel, this value could describe the version of the CX-API-standard for the Quality use-case. Creation is currently in progress as CX-0123 v1.0.0. |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Version is fine, but I think we need to make sure that the Quality KIT clearly states what versions are included in the current release and which versions should be use. As of now, this information is missing, I think.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cx-common:version is the version of CX-0123.
CX-0123 will likely link to CX-0018 v2.1.0.
CX-0018 demands DSP 0.8.

I don't see any trouble here. Should I explain the logical reason above in the Kit?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, understood and fine for me.

markuskeidl
markuskeidl suggested changes Jan 22, 2024
View reviewed changes
Copy link
Contributor

@markuskeidl markuskeidl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See my inline comments

@arnoweiss arnoweiss requested a review from markuskeidl January 22, 2024 14:54
markuskeidl
markuskeidl approved these changes Jan 23, 2024
View reviewed changes
docs-kits/kits/Quality-Kit/Software Development View/page_software-development-view.md Outdated
| `https://purl.org/dc/terms/conformsTo` | `{"@id":"<urnOfTheCorrespondingAspectModel>"}` | This property is QM-specific. It holds the exact aspect-model-URN that defines the schema of the presented dataset including its version. The version in here refers to the data model's version while the EDC-property `cx-common:version` defines the version of the underlying API serving the data. |
| `http://www.w3.org/ns/dcat#qualifiedRelation` | `{"dct:isPartOf": {"@id": "<idOfTheCorrespondingQualityTask>"}}` | This property is QM-specific. All Asset types defined in this Kit must include this property as it links the data behind an asset with the correct QualityTask. Note that the id of the QualityTask must be used, not the id of the EDC-Asset shielding said QualityTask. |
| `https://w3id.org/edc/v0.0.1/ns/type` | `AmazonS3` | This property signifies the EDC dataplane that the QM data will be transferred over. The expectation that this would be signaled via the dcat:DataSet-dcat:distribution property of the catalog currently isn't implemented in the EDC. Thus the data must be replicated here and is presented via the same property that the consumer-side `transferprocesses` API uses for this same signal. |
| `https://w3id.org/catenax/ontology/common#version` | `"1.0"` | CX-0018 recommends to use cx-common:version to signify the API's version. Since QM has a tight connection between the API and the datamodel, this value could describe the version of the CX-API-standard for the Quality use-case. Creation is currently in progress as CX-0123 v1.0.0. |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, understood and fine for me.

SebastianBezold
SebastianBezold approved these changes Jan 23, 2024
View reviewed changes
Copy link
Contributor

@SebastianBezold SebastianBezold left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.
You could think of putting dcat:Datasets and properties like in single backticks.
This is already done in the tables, but not in plain text.
Might make it easier to read. Still good without it though!

carslen
carslen approved these changes Jan 23, 2024
View reviewed changes
Copy link
Contributor

@carslen carslen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@carslen carslen merged commit 204cfdd into eclipse-tractusx:main Jan 23, 2024
4 checks passed
@ClaudiaKilian
Copy link
Contributor

Looks very good , thank you both.
Flattening rules are in preparation for the next KIT version

This was referenced Mar 15, 2024
Closed
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@markuskeidl markuskeidl markuskeidl approved these changes

@carslen carslen carslen approved these changes

@SebastianBezold SebastianBezold SebastianBezold approved these changes

@ClaudiaKilian ClaudiaKilian Awaiting requested review from ClaudiaKilian

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@arnoweiss @markuskeidl @ClaudiaKilian @SebastianBezold @carslen