search

International-Data-Spaces-Association / InformationModel

The Information Model of the International Data Spaces implements the IDS reference architecture as an extensible, machine readable and technology independent data model.
Apache License 2.0
63 stars 35 forks source link

Feature/fdst41 extension #450

Closed changqin26 closed 2 years ago

changqin26 commented 3 years ago

Please review the extension of Infomodel based on the requirements from IESE. the detailed requirements are in the related emails.

sebbader commented 3 years ago

Hello! I feel a bit unqualified to review these changes as quite a lot of new things are introduced. Can we discuss the motivation first? Or, if you @HaydarAk , have a better picture, can you review this PR?

juliapampus commented 2 years ago

I have some questions: Why do we have objects like ids:pipEndpoint and ids:pxpEndpoint? Isn't the idea behind this endpoint the same as for other endpoints in the Infomodel, e.g. the app, connector, and whatever endpoint? So first, isn't it possible to use one ids:endpoint object with a type label/attribute (e.g. @type: ids:PIP as already partly used here), specifying what the endpoint is for - in general? And second, is this ids:pipEndpoint aligned with the other ones, including the same attributes? In the UsageControlComponent.ttl, it is stated that an endpoint has an ids:interfaceDescription and an ids:endpointURI, although the ids:endpoint has attributes like ids:accessURL or ids:endpointDocumentation. For implementation purpose, it would be great to align this endpoint descriptions.

hosseinzadeha commented 2 years ago

@juliapampus I see your point. I just checked Endpoint.ttl and I see ids:ConnectorEndpoint and ids:AppEndpoint in addition to some app specific attributes all in the same place. Maybe it is better to split them and define object specific endpoint definitions similar to Usage Control component endpoints (for app, connector, etc.). And also, in my opinion there is a slight difference between Documentation and Interface Description. Maybe we need both actually; one providing an explanation for the endpoint and second one defining the input/output parameters together with their data types. However, I agree that it is good to have them as similar as possible.