Dear all, It is the CRM SIG's practice to encode the English label of a class into the URI of the class itself. We thus find the official URIs of CRM encoded in each official version of CRMbase on the official website: https://cidoc-crm.org/versions-of-the-cidoc-crm
e.g.: http://www.cidoc-crm.org/cidoc-crm/E1_CRM_Entity And this is fine. But once in a while, as we evolve the standard, we change the label of the class. This means we change the URI of the class as well. A classic example: In CRM 6.2.1 http://www.cidoc-crm.org/cidoc-crm/E78_Collection In CRM 7.1.1 http://www.cidoc-crm.org/cidoc-crm/E78_Curated_Holding Obviously, this is something we try not to do very often because it creates a great many implementation headaches. But it occurs and that is okay. When we make such changes, we imply that the name we use to identify the class has changed but not its substance. The intension as defined by the scope remains the same. All previous instances of this class remain instances of this class. For some reason, we want to call it something else. As far as a semantic network is concerned though the new and the old class are two different things, not one. http://www.cidoc-crm.org/cidoc-crm/E78_Collection != http://www.cidoc-crm.org/cidoc-crm/E78_Curated_Holding My question is, should we include something in the RDFS definition that indicates the relation between the old URI and the new URI? To state an equivalency? This way in a semantic network, they could be treated with the same meaning? Apologies if we have discussed this before and decided no, or that it can't be done or shouldn't be done. I don't recall. Best, George -- George Bruseker, PhD Chief Executive Officer Takin.solutions Ltd. https://www.takin.solutions/
_______________________________________________ Crm-sig mailing list [email protected] http://lists.ics.forth.gr/mailman/listinfo/crm-sig
