I agree with Detlev's proposal. Also, I believe that versions should not
be included in the class URIs. These are not normally used to retrieve
reasoning rules but only to identify classes, right? Resolving the class
URI should return all versions of the class.
All the best,
Thanasis
On 16/01/2020 19:28, Detlev Balzer wrote:
Martin Doerr <mar...@ics.forth.gr> hat am 16. Januar 2020 um 13:27 geschrieben:
(...)
At FORTH we will implement anything that is regarded good practice, and
does not create a manual overhead we cannot manage.
For formal specifications such as ontologies, there is a widely adopted pattern
for change management which goes like this:
http://www.cidoc-crm.org/cidoc-crm/ always resolves to the latest version, while
http://www.cidoc-crm.org/cidoc-crm/{version}/ always resolves to the particular
{version} given in the URI.
There can be any number of versions, and the latest one is both referenced
through the un-versioned namespace and through the one with the most recent
version number (or publication date, if that is used for versioning).
Alternatively, the most recent version could be labelled explicitly as the
current one, e.g. http://www.cidoc-crm.org/cidoc-crm/current/
Application developers must then decide what kind of stability they prefer:
stability of the namespace URI, or stability of the content retrieved from a
URI. Evidently, one cannot have both.
Maintenance effort for this pattern is minimal: Just publish each new version
under its versioned namespace and then, any time another version comes out,
adjust the non-versioned namespace so that it will resolve to the most recent
version. Most modern Web frameworks have a URL routing facility which makes
this fairly easy.
I should not forget to say that LOD best practice also demands that URIs
support content negotiation, as assumed throughout all recommendations in the
http://linkeddatabook.com/
Best,
Detlev
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
