Closed changqin26 closed 2 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?
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.
@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.
Please review the extension of Infomodel based on the requirements from IESE. the detailed requirements are in the related emails.