Investigate pros and cons of versioning in the ontology URI

[JohannesLipp]

Research practices and related work, and decide whether we should include a version number (e.g., 2020-12-03) in the ontology URI. The base URI https://w3id.org/idsa/core would always be considered as latest and therefore redirect there. Other links allow direct access of later versions, too.

[JohannesLipp]

https://www.w3.org/TR/swbp-vocab-pub/#recipe4 looks promising. Applying this would mean the following for us:

Before:

• Just one (=most recent) ontology.ttl file
• Just one (=most recent) documentation page at https://w3id.org/idsa/core
• Both being silently overwritten with new versions whenever we publish them

After:

• Multiple ontology files like ontology-3.1.0.ttl, ontology-4.0.0.ttl and ontology-4.1.0.ttl
• Multiple documentation pages like http://w3id.org/idsa/core-310, http://w3id.org/idsa/core-400 and http://w3id.org/idsa/core-410
• Users can access any of these documentation pages via its URL, while the base URL always points to the most recent one.
• The "old" ontology URL would stay, and always contain the most recent version.
• Users can access particular ontology versions via the particular documentation page, respectively.

For an example, see https://w3id.org/bpo and https://w3id.org/bpo/1-1/

[JohannesLipp]

@sebbader @maboeckmann @HaydarAk @changqin26 Could you please comment on my suggested approach? Core questions are:

1. Are there any drawbacks with that approach?
2. Who can update our configuration to execute this?

Please note this also includes to use a version number in the ontology URI, like https://w3id.org/idsa/core-400, which people would use in their turtle-files and which would (according to the above-mentioned redirects) return the version 4.0.0, while just https://w3id.org/idsa/core would always return the most recent version.

[changqin26]

I want to make sure that I understand this approach right through an example. If there is a new class in version https://w3id.org/bpo/1-1/, then the IRI of this new class should be "https://w3id.org/bpo/1-1#newclass" in its documentation page, not be "https://w3id.org/bpo#newclass" anymore, right?

[JohannesLipp]

In short: Yes.

You can use prefix bpo: https://w3id.org/bpo/1-1# and subsequently ex:myInstance a bpo:Class in your file. This would serialize to https://w3id.org/bpo/1-1#Class, exactly. You can later upgrade that prefix to, e.g., prefix bpo: https://w3id.org/bpo/1-2, but leave the rest unchanged - this would then use the newer version https://w3id.org/bpo/1-2#Class.

If you want to automatically use the newest version all the time, you would use prefix bpo:https://w3id.org/bpo# without any version identifier, because that one always redirects to the newest one.

[changqin26]

Understood, this versioning method is the same as that of the Asset Administration Shell. I see no obvious drawbacks of this method, just need to manually update ..../1-1 to ...../1-2 for each URL that involves this.

[JohannesLipp]

Input from @clange : Follow https://www.debian.org/releases/ like so:

• stable = latest LTS (currently 4.0.0)
• testing = master branch
• unstable = develop branch

https://w3id.org/idsa/core should always point to the master branch, which is testing.