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
61 stars 35 forks source link

Implement proper versioning in ids namespaces #570

Open sebplorenz opened 2 years ago

sebplorenz commented 2 years ago

The correct version number is often missing for ids or idsc namespace in the .ttl files. E.g. the Participant.ttl has been changed several times recently but still refers to the default namespace, as can be seen here:

https://github.com/International-Data-Spaces-Association/InformationModel/blob/5293315deaf69cc7fa6559a291ffd52ba73dc7dc/model/participant/Participant.ttl#L8

Expected behaviour: a specific version of the model should be referenced in the namespace of the .ttl files when they are updated.

JohannesLipp commented 2 years ago

FYI: If we update the base-URI in line 7 to include a version number, we must also do this for the base-prefix in line 1.

lcomet commented 2 years ago

@sebplorenz for the implementation of versioning in the ontology we followed the best practices according to this guideline We have this versioning information in the owl:versionInfo tag, in different serializations, in the complete ontology available here Ontology Documentation

Could you please indicate me what do you think about this approach? Or do you think we still need to include the owl:versionInfo tag in each component of the model, e.g. Participant.ttl, Artifact.ttl, etc.

sebplorenz commented 2 years ago

@lcomet I'm not an ontology expert, but I thought that this

https://github.com/International-Data-Spaces-Association/InformationModel/blob/5293315deaf69cc7fa6559a291ffd52ba73dc7dc/model/participant/Participant.ttl#L8

should be 

@prefix ids: <https://w3id.org/idsa/core/4.2.2> .

Shouldn't it?

lcomet commented 2 years ago

@sebplorenz Thank you for your reply. As far as I understand, it is discouraged to include the versioning information in the URI as it is going to affect the ontology interoperability. Therefore we include the versioning information in the metadata, i.e. in the owl:versionInfo tag.

@JohannesLipp Do you have any comments about this issue? I referenced the document about best practices in the versioning of ontologies, please see the link in my previous comment. More specifically, I refer to this portion of information: "the version IRI is independent of the URI of the ontology (“https://w3id.org/example#”). It is discouraged to include version numbers as part of the ontology URI, as it would deeply affect the interoperability of its instances." An example is given in section 2.4 (page 4) of the document.

The problem here, I think, is that in the different components of the ontology, e.g. Participant.ttl has no information about the specific version. That information is in resulting the Ontology after importing all the components of the model, i.e https://github.com/International-Data-Spaces-Association/InformationModel/blob/develop/Ontology.ttl, and which is independent of the documentation.

sebplorenz commented 2 years ago

OK. That means, as a "user" of the Infomodel I create an SD of a Participant (with the latest changes), with a reference 

@prefix ids: <https://w3id.org/idsa/core/4.2.0>

in my participant SD, right?

JohannesLipp commented 1 year ago

After a discussion with @PHochmann and @clange , we agreed on the following:

  1. Including a version number in older version's prefix namespaces is a bad idea, because this would make same concepts from different versions different, although they might not have changed. (e.g. https://w3id.org/idsa/core-300#Participant and https://w3id.org/idsa/core-400#Participant would become completely different things even though they are (nearly) the same).
  2. Establishing multiple namespaces due to different versions would enable the option of mixing concepts from multiple versions in instances, which we must avoid.
  3. Workaround for resolving concepts from specific (older) version: Users can, in their resolve engines, on-the-fly replace https://w3id.org/idsa/core/XXX with https://w3id.org/idsa/core-400/XXX to access the particular version, if needed.
  4. The IM already has a property modelVersion that allows manual specification of IM version numbers, where needed. @lcomet please relax the domain of that property from ids:Message to the most general concept possible (e.g., rdfs:Class). @changqin26 please tell us the most general thing that CodeGen supports, thanks!