[Crm-sig] URI Management [Issue 460]

Pavlos Fafalios fafalios at ics.forth.gr
Mon Sep 27 13:34:40 EEST 2021

Dear all,

We (at FORTH) have started working on the URIs management issue, i.e. on
how to provide resolvable URIs for the different versions of CIDOC-CRM and
its compatible models. We would like to hear you opinion about the


The URI http://www.cidoc-crm.org/cidoc-crm/ will always resolve to the *last
official* version of CIDOC-CRM ('official' according to the definition here
*A question (also raised by George) is if we want to point to the last
'published' version* (which is *"a stable version of the standard and can
be used for implementation, referencing and any other official purpose"*).

In parallel, each version will have its own versioned URI, e.g.,
http://cidoc-crm.org/cidoc-crm/7.1.1/ for version 7.1.1,
http://cidoc-crm.org/cidoc-crm/6.2.9/ for version  6.2.9, etc. etc.


Different content will be served based on the type of the HTTP request. So,
if one asks for
will get either the HTML content
<http://cidoc-crm.org/versions/cidoc_crm_v7.1.1.html> of the last official
version (using text/html content type),
or the RDFS of the last official version (using rdf/xml content type).

We will do the same for also the versioned URIs.

Now, if one requests a specific class or property, e.g.:
will either navigate to the part of HTML content of the last official
version which describes this particular class
<http://cidoc-crm.org/versions/cidoc_crm_v7.1.1.html#E5> (text/html
or (for the case of rdf/xml) will get the entire RDFS of the last official
version OR the star-view of that particular class (i.e., subclasses,
superclasses, incoming properties, outgoing properties).
*So, a question here is if we want to provide the star-view or the entire
In our opinion, it's much better to provide the star view. Otherwise it
makes no sense to request the URI (using rdf/xml) including the
class/property name since the result is the same for any class/property
name. So, in this case, one should request
for the complete rdfs file, and
for the rdfs star view of E5_Event.

We will do the same for also the versioned URIs.


Now the controversial issue :)

What base URI should we use for the classes and properties of each version
when serving RDF content? There are three options:

*Option B1*. Always use an unversioned base URI, i.e.,
http://www.cidoc-crm.org/cidoc-crm/ for all ontology versions. This means
that the class/property URIs are unversioned (e.g.,
Then, we have to use 'owl:versionInfo' for providing information about the
underlying cidoc-crm version (then we also expect that a KB will contain
RDF data using only one particular cidoc-crm version).

*Option B2*. Always use a versioned base URI, e.g.,
http://www.cidoc-crm.org/cidoc-crm/7.1.1/ for the last official ontology
http://www.cidoc-crm.org/cidoc-crm/6.2.1/ for ontology version 6.2.1,
etc. etc.
This means that the class/property URIs are versioned (e.g.,
(This does not affect the fact that the unversioned ontology URI is

*Option B3*. Provide both, one RDFS file having unversioned base URI and
one RDFS file having versioned base URI (similar to the approach followed
by Erlangen).
In this case, the RDFS file having the unversioned base URI will be updated
after each new ontology (official/published) release.

We (Pavlos and Elias) support B2 for the following reason:
When one builds a knowledge base (RDF dataset) using cidoc-crm, he/she
considers a particular version of the model. There is no mix of model
versions (or, at least, there should be no mix of model versions---unless
there is a particular use case we are not aware of). Without considering a
versioned base URI, it is very difficult (maybe impossible in some cases)
to know which version of cidoc-crm was used for creating an RDF dataset.
Also, option B3 does not always solve the problem.

Thanasis has already made a point about not using versioned base URI:
*"I am suggesting that classes do not need versions at all. Doing reasoning
on a per class and per version basis would be bad practice, no? One would
expect that the whole RDF/OWL representation would be used for reasoning. I
think class URIs are only used as identifiers. This also avoids the problem
of ensuring correct older versions for deprecated classes."*

Thanasi, could you please elaborate more on this? It's not clear to us
why/how reasoning considering a particular ontology version is affected
when versioned URIs are used for the classes and properties.


*1/ Renamed*: When resolving a class/property (of a specific version) which
has been renamed, we can point the user to the information about the
renamed class (since semantics stay the same). For example:
when asking for http://www.cidoc-crm.org/cidoc-crm/E78_Collection
users will get information about
(once URI resolving has been implemented)

*2/ Deprecated*: When resolving a class/property (of a specific version)
which has been deprecated, we (Pavlos and Elias) suggest not returning
anything (404 response code).  In our opinion, this makes sense since the
ontology version does not anymore contain the requested class/property. In
the case of HTML content type, we can also point the user to the Migration
Instructions (page 229
Any comments?


The plan is to follow the same approach for the compatible models. Here, it
seems that having versioned URIs for the ontology and the extension models
solves the problem of how to point to specific versions (as mentioned by
Francesco). We just need to include the versioned namespaces of the
considered models in the RDFS.

Looking forward to your comments and feedback!

Best regards,
Pavlos and Elias

Dr. Pavlos Fafalios
Postdoctoral research fellow
Project ReKnow <https://reknow.ics.forth.gr/> (MSCA Individual Fellowship)

Centre for Cultural Informatics / Information Systems Laboratory
Institute of Computer Science (ICS)
Foundation for Research and Technology (FORTH)
Visiting Lecturer
Department of Management Science & Technology (MST),
Hellenic Mediterranean University (HMU)

Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece
Email: fafalios at ics.forth.gr
Tel: +30-2810-391619
Web: http://users.ics.forth.gr/~fafalios/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20210927/79e17c65/attachment.html>

More information about the Crm-sig mailing list