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 <crm-sig-boun...@ics.forth.gr> on behalf of > "melanie.ro...@bnf.fr" <melanie.ro...@bnf.fr> > *Date: *Friday, July 20, 2018 at 8:51 AM > *To: *"mar...@ics.forth.gr" <mar...@ics.forth.gr> > *Cc: *"Crm-sig@ics.forth.gr" <Crm-sig@ics.forth.gr> > *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 <mar...@ics.forth.gr> > A : crm-sig <Crm-sig@ics.forth.gr> > Date : 19/07/2018 18:45 > Objet : [Crm-sig] ISSUE Label-free RDF classes PLEASE VOTE > Envoyé par : "Crm-sig" <crm-sig-boun...@ics.forth.gr> > > ------------------------------------------------------------------------ > > > > > 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: mar...@ics.forth.gr > <mailto:mar...@ics.forth.gr>| > | > 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 > Crm-sig@ics.forth.gr > 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 > Crm-sig@ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig -- *Richard Light*
