[Crm-sig] Reuse identifiers of obsolete entities never published

George Bruseker bruseker at ics.forth.gr
Tue Jun 18 01:03:59 EEST 2019

I also support there not being reuse of numbers. There is no end of numbers to choose from.



Dr. George Bruseker

Centre for Cultural Informatics
Institute of Computer Science
Foundation for Research and Technology - Hellas (FORTH)
Science and Technology Park of Crete
Vassilika Vouton, P.O.Box 1385, GR-711 10 Heraklion, Crete, Greece

Tel.: +30 2810 391619   Fax: +30 2810 391638   E-mail: bruseker at ics.forth.gr
URL: http://www.ics.forth.gr/isl

> On Jun 14, 2019, at 9:45 AM, Robert Sanderson <RSanderson at getty.edu> wrote:
> I also agree with Vincent and Richard. Given the very slow rate of change between “official” versions, and the prominence of the intermediate versions, I agree that the condition should be “in a public document” not “in an official version”.
> http://www.cidoc-crm.org/get-last-official-release <http://www.cidoc-crm.org/get-last-official-release> lists 5.0.4, dated 2011, as the last official release.
> The “Current Version” link in the website sidebar lists version 6.2.3.
> And the top most link in the home page under What’s New, refers to the upload of 6.2.6.
> And http://www.cidoc-crm.org/versions-of-the-cidoc-crm <http://www.cidoc-crm.org/versions-of-the-cidoc-crm> lists 6.2.1 as the most recent published version, and the most recent published RDFS file.
> So I believe that it is entirely reasonable for people to be confused as to which identifiers are stable and which are not, and thus we should treat the assignment of a number to a class or property as final. While in draft, it can be xxx as per our typical practice.
> Rob
> From: Crm-sig <crm-sig-bounces at ics.forth.gr> on behalf of Richard Light <richard at light.demon.co.uk>
> Date: Thursday, June 13, 2019 at 5:54 PM
> To: "crm-sig at ics.forth.gr" <crm-sig at ics.forth.gr>
> Subject: Re: [Crm-sig] Reuse identifiers of obsolete entities never published
> Vincent,
> I strongly support your view that we should not re-use identifiers.  The only argument I could give for this practice is the desire for a nice neat sequence of identifiers: and we have already scuppered that aspiration by deprecating previously-published classes and properties (thereby causing gaps to appear). So, please, don't do it!
> Thanks,
> Richard
> On 13/06/2019 16:29, Vincent Alamercery wrote:
> Dear all, 
> during the SIG meeting in Paris, we added the new property "P177 assigned property type" (see http://www.cidoc-crm.org/sites/default/files/CIDOC%20CRM_v6.2.6_Definition_esIP.pdf <http://www.cidoc-crm.org/sites/default/files/CIDOC%20CRM_v6.2.6_Definition_esIP.pdf>).
> This property reuses the already given identifier of the property "P177 ends within" which has been deprecated without ever belonging to a published version (see http://www.cidoc-crm.org/Property/p177-ends-within/version-6.2.2 <http://www.cidoc-crm.org/Property/p177-ends-within/version-6.2.2> and http://www.cidoc-crm.org/sites/default/files/CIDOC%20-%20CRM_v6.2.6_%20Amendments.pdf <http://www.cidoc-crm.org/sites/default/files/CIDOC%20-%20CRM_v6.2.6_%20Amendments.pdf>)
> We had a little discussion on whether or not to reuse this identifier already given. Maybe I'm picky but I'm not really comfortable with this practice. I suggest never to reuse an identifier for the following non-exhaustive reasons:
> Even it's highly not recommended to use a draft version of CIDOC CRM, an entity exists from the moment it appears on a public document. It could then be potentially used by anyone. In a given namespace, an identifier must have to be unique.
> For documentation reason, it's easier to have unique identifiers too to avoid speaking of "the old P177" or "the new P177". For instance, in the issue #345, how to know of which P177 property we are talking about? Think "the new P177" could be deprecated too one day...: http://www.cidoc-crm.org/Issue/ID-345-properties-having-domain-or-range-deprecated-classes <http://www.cidoc-crm.org/Issue/ID-345-properties-having-domain-or-range-deprecated-classes>
> Numbers are infinite, we don't need to save them. ;-)
> Best regards,
> Vincent.
> -- 
> Vincent Alamercery
> Pôle histoire numérique
> @phn_larhra
> LARHRA - UMR 5190
> École normale supérieure de Lyon
> 15 parvis René Descartes
> BP 7000
> 69342 Lyon cedex 07
> France
> Tel : +33 (0)4 37 37 60 73
> vincent.alamercery at ens-lyon.fr <mailto:vincent.alamercery at ens-lyon.fr>
> http://larhra.ish-lyon.cnrs.fr/membre/54 <http://larhra.ish-lyon.cnrs.fr/membre/54>
> http://symogih.org/ <http://symogih.org/>
> http://dataforhistory.org/ <http://dataforhistory.org/>
> _______________________________________________
> Crm-sig mailing list
> Crm-sig at ics.forth.gr <mailto:Crm-sig at ics.forth.gr>
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig <http://lists.ics.forth.gr/mailman/listinfo/crm-sig>
> -- 
> Richard Light
> _______________________________________________
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20190618/85883d63/attachment-0001.html>

More information about the Crm-sig mailing list