[Crm-sig] URI Management [Issue 460]

Pavlos Fafalios fafalios at ics.forth.gr
Mon Sep 27 15:51:56 EEST 2021


Dear Richard,

Thank you for the feedback and comments. Answers inline below:

On Mon, Sep 27, 2021 at 3:13 PM Richard Light via Crm-sig <
crm-sig at ics.forth.gr> wrote:

> On 27/09/2021 11:34, Pavlos Fafalios via Crm-sig wrote:
>
> 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
> following:
>
> *(A) HAVING BOTH UNVERSIONED AND VERSIONED ONTOLOGY URIS  *
>
> 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 <http://www.cidoc-crm.org/versions-of-the-cidoc-crm>).
> *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"*).
>
> I'm happy with the idea of 'latest published' being supported. However, we
> will need to think about what gets returned.
>
> Currently, the latest official version (7.1.1) is later than the latest
> 'published' version. Am I right in assuming that this will not normally be
> the case, i.e. that there will usually be a 'published' version which is
> more recent than the last official version, which has been *both *published
> *and *made to correspond to an official ISO release of the CRM?
>
> If so, what do we do in the current situation?  Does a request for the
> latest 'published' version return 7.1.1?
>
We consider the 'official' version as also being 'published'.
So, let's suppose that there is a next cidoc-crm version 7.3.1 which is
marked as 'published', and another one 7.4 marked as 'draft'.
If SIG decides that the URI http://www.cidoc-crm.org/cidoc-crm/ should
point to the last 'official' (ISO) version, then it will point to 7.1.1
If SIG decides that the URI http://www.cidoc-crm.org/cidoc-crm/  should
point to the last 'published' version, then it will point to 7.3.1.

As it is now (last official or published version is 7.1.1), the URI will
point to 7.1.1.


> 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.
>
>
> *(B) SERVING HTML OR RDF (BASED ON HTTP REQUEST TYPE)*
>
> Different content will be served based on the type of the HTTP request.
> So, if one asks for
>    http://www.cidoc-crm.org/cidoc-crm/
> 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.:
>    http://www.cidoc-crm.org/cidoc-crm/E5_Event
> 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
> request),
> 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
> RDFS.*
> 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
>     http://www.cidoc-crm.org/cidoc-crm/
> for the complete rdfs file, and
>     http://www.cidoc-crm.org/cidoc-crm/E5_Event
> for the rdfs star view of E5_Event.
>
> Yes, I support returning the star-view, for the reasons you give.
>
>
> We will do the same for also the versioned URIs.
>
> *(C) BASE URI (NAMESPACE) FOR CLASSES AND PROPERTIES *
>
> 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.,
> http://www.cidoc-crm.org/cidoc-crm/E5_Event).
> 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
> version,
> 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.,
> http://www.cidoc-crm.org/cidoc-crm/7.1.1/E5_Event).
> (This does not affect the fact that the unversioned ontology URI is
> resolvable)
>
> *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.
>
> I'm a simple soul (in this area, at least), and don't have an informed
> view on how versioned URIs would work as regards reasoning.  However, my
> instinct is to favour unversioned URIs. I'm not sure I would support
> versioned URIs at all.  Just imagine the situation where 12 institutions
> pool their CRM-encoded RDF resources to create a combined knowledge base.
> Now imagine that between them they use 8 different versions of the CRM, and
> this is reflected in their URIs. How on earth could anyone perform
> reasoning on the resulting rat's nest?
>
> Putting it another way, if we are properly maintaining the ontological
> commitments we make when defining a particular CRM class or property, then
> its semantics should remain sufficiently stable over time for 'old'
> assertions to remain valid/meaningful when seen through the lens of the
> 'current' CRM.
>
What you say makes sense to me and justifies a decision to avoid having
versioned base URIs (considering that the semantics of the classes do not
change in different versions ---which seems to be the case).
As you say, direct data integration will be a problem, even for simple
tasks like querying (one will need to apply some
preprocessing/consolidation before integration).
I guess that this is also what Thanasis means in issue 460.
So, now I would also go for Option B1 where we include versioning
information in the RDFS.

Any other thoughts? Any reason for selecting Option B3?

Thanks again for the feedback!

Best regards,
Pavlos

> Thanks for working on this.
>
> Richard
>
>
> *(D) WHAT WE DO WITH RENAMED AND DEPRECATED CLASSES*
>
> *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
> <http://www.cidoc-crm.org/cidoc-crm/7.1.1/E78_Collection>,
> users will get information about
> http://www.cidoc-crm.org/cidoc-crm/E78_Curated_Holding
> <http://www.cidoc-crm.org/cidoc-crm/7.1.1/E78_Curated_Holding>
> (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
> <http://www.cidoc-crm.org/sites/default/files/cidoc_crm_v.7.1.1_0.pdf>).
> Any comments?
>
> *(E) COMPATIBLE MODELS *
>
> 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)
>    and
> 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/
>
>
> _______________________________________________
> Crm-sig mailing listCrm-sig at ics.forth.grhttp://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
> --
> ------------------------------
> *Richard Light*
> richardlight399 at gmail.com
> *@richardofsussex*
> _______________________________________________
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>


-- 
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)
   and
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/dd389510/attachment-0001.html>


More information about the Crm-sig mailing list