Hi Richard, Thanks for bringing up persistence, as I think it’s an important discussion with direct relevance on this topic. I don’t think that URI persistence is a function of form, obscurity or language, but of the will of the maintainers to keep the URI available. http://cidoc-crm.org/ns/E22_Man_Made_Object can be just as persistent as http://cidoc-crm.org/ns/E22. Or http://cidoc-crm.org/ns/A3F59536-4C30-4AD1-AEC7-E9EEC93411A5.
As is frequently demonstrated, URI persistence is made more likely by use. Use is more likely when the URI is usable: Usability is the degree to which a software can be used by specified consumers to achieve quantified objectives with effectiveness, efficiency, and satisfaction in a quantified context of use. [Wikipedia definition of Usability] In other words, usability is a metric based on how well the audience can effectively, efficiently and happily achieve their objectives. You can either make many people happy by including the labels, or you can make everyone equally unhappy by not including them. The arguments in favor of having the codes as separate terms in fact *double the cost of that persistence*, and open the door to multiplying it many times by requiring the persistence of both E78_Collection and E78_Curated_Holding, of M14_Medium_Of_Performance and M14_Medium_of_Performance. If you believe that the aim is to ensure persistence, then you should be in favor of as few terms to maintain as possible, thereby maximizing the likelihood that they will survive. And given the above, you should pick the term with the label included over the term without the label. That is, in fact, exactly the logic that led to my vote of no :) Secondly, if you think that the terms should be understandable for as long as possible, then “E22” is much less likely to be understood in the future than “E22_Man_Made_Object”. The code alone *requires* the documentation in order to be understood. The form with the label can be understood by approximately 20% of the world’s population and is unlikely to die out any time soon. 80% of linguistic content on the web is in English. English is typically treated as the lingua franca of computing, and especially on the web given its origins and ASCII-centric early nature. Yes, that’s not fair, diverse or equitable, but it’s also impossible to dispute. Rob From: Crm-sig <[email protected]> on behalf of Richard Light <[email protected]> Date: Monday, July 23, 2018 at 9:20 AM To: "[email protected]" <[email protected]> Subject: Re: [Crm-sig] ISSUE Label-free RDF classes PLEASE VOTE Rob, I don't think that's particularly fair. The goal is not, as I am sure you realise, to make CRM-encoded data as obscure as possible. It is to ensure that the Linked Data identifiers which we publish are as persistent as they need to be, in the context of cultural heritage documentation which may be around long after we're all dead. Best wishes, Richard On 23/07/2018 16:42, Robert Sanderson wrote: I agree that the opaque terms equally disadvantage everyone. No one has any benefit at all. Following this line of thinking, we could be even more opaque by using UUIDs instead of almost memorable numbers, requiring that everyone use software tools to work with the CRM and no one could look at the data directly with any way of understanding it without those internationalized and accessible tools. This would enforce the best practice of multilingualism and not unfairly advantage people who have memorized the numbers or can speak English. Rob From: Crm-sig <[email protected]><mailto:[email protected]> on behalf of "[email protected]"<mailto:[email protected]> <[email protected]><mailto:[email protected]> Date: Friday, July 20, 2018 at 8:51 AM To: "[email protected]"<mailto:[email protected]> <[email protected]><mailto:[email protected]> Cc: "[email protected]"<mailto:[email protected]> <[email protected]><mailto:[email protected]> Subject: Re: [Crm-sig] ISSUE Label-free RDF classes PLEASE VOTE Dear Martin, dear all, On behalf of BnF, I vote YES. The DOREMUS project demonstrated that label-free classes and properties are very important, as renaming them is very costly, as well as damaging for dissemination. For instance, the renaming of "M14_Medium_Of_Performance" into "M14_Medium_of_Performance" (no capital "o") was a nightmare for our IT people as well as for those users who had already begun disseminating our data. Plus, opaque names encourage users to go and read the documentation so as to really understand the scope of what they are using, instead of just assuming the meaning of a class or property based on the label only. That is especially true for non-native English speakers: I believe supporting multilinguism was precisely the reason why WikiData opted for opaque codes, and I think this was a sound decision. Best wishes, Mélanie Roche Metadata Department Bibliothèque nationale de France De : Martin Doerr <[email protected]><mailto:[email protected]> A : crm-sig <[email protected]><mailto:[email protected]> Date : 19/07/2018 18:45 Objet : [Crm-sig] ISSUE Label-free RDF classes PLEASE VOTE Envoyé par : "Crm-sig" <[email protected]><mailto:[email protected]> ________________________________ Dear All, The current text "Expressing the CIDOC Conceptual Reference Model in RDF" (https://docs.google.com/document/d/1zCGZ4iBzekcEYo4Dy0hI8CrZ7dTkMD2rJaxavtEOET0/edit?ts=5b50b922) contains the phrase: "In addition, for convenience of implementation we have defined number-only classes and properties e.g. “E63” or “P2”, and declared each of them to be equivalent to the corresponding full form" In the past, this option was provided and widely rejected by users. I do not know of any installation using it. It was proposed again because CRM-SIG reserves the right to change labels without changing the code ("E63", "P2" etc.), in cases when the meaning is preserved but the existing label causes confusion and can be replaced by a more fitting or at least less confusing one. These changes are very rare, and explicit in the amendment of the respective version. Those of you who support: "In addition, for convenience of implementation we have defined number-only classes and properties e.g. “E63” or “P2”, and declared each of them to be equivalent to the corresponding full form" please vote YES. Those of you who support: "The English label is part of the definition of the RDF classes and properties. Number-only classes and properties e.g. “E63” or “P2”, are not provided". Other means of supporting migration between label versions to be discussed. please vote NO. (Those who believe the issue is not sufficiently formulated please vote "VETO". One or more "VETO" will stop the e-mail vote as a whole and postpone it to the next physical meeting) Best Martin -- -------------------------------------------------------------- Dr. Martin Doerr | Vox:+30(2810)391625 | Research Director | Fax:+30(2810)391638 | | Email: [email protected]<mailto:[email protected]>| | Center for Cultural Informatics | Information Systems Laboratory | Institute of Computer Science | Foundation for Research and Technology - Hellas (FORTH) | | N.Plastira 100, Vassilika Vouton, | GR70013 Heraklion,Crete,Greece | | Web-site: http://www.ics.forth.gr/isl | -------------------------------------------------------------- _______________________________________________ Crm-sig mailing list [email protected]<mailto:[email protected]> http://lists.ics.forth.gr/mailman/listinfo/crm-sig ________________________________ Exposition Picasso et la danse<http://www.bnf.fr/fr/evenements_et_culture/anx_expositions/f.picasso_et_danse.html> - du 19 juin au 16 septembre 2018 - BnF - Bibliothèque-musée de l'Opéra Avant d'imprimer, pensez à l'environnement. _______________________________________________ Crm-sig mailing list [email protected]<mailto:[email protected]> http://lists.ics.forth.gr/mailman/listinfo/crm-sig -- Richard Light
