Dear all, i would second Richards opinion about this paper. In the first half, it is a "primer" to the CRM itself, in the the second half, it becomes a linked data implementation guide.
The second part of this paper is in my opinion problematic on several levels. First of all I think it was always a good decision not to "approve" and "ideal" implementation of the CRM. In fact, the second part does right that in outlining an implementation of the CRM in RDF / Linked Data. If we consider this part as some kind of "good practice", there are several points that would be at least inconvenient dealing with RDF and Triple Stores. These are just a few things I found skimming through the text: - The proposed URI schema (p12) does not reflect the structure of a triple stores and knowledge graphs. In the example given the URIs themselves reflect paths inside a graph from a given starting point. It seems that "object" is a favourite starting point, and also "thesauri". But who decides on which point to start? For example, "http://collection.[domain]/id/object/[idenitifier]/material"; might also be "http://collection.[domain]/id/material/[identifier]";. Additionaly, using class names inside a URI becomes instantly painful when it comes to multiple inheritance. To implement the URI scheme in the given format would imply to use a triple store against its internal structure. - The figure on p.12 ("Here is the RDF view") shows an instance "http://collection.amuseum.org/id/object/1234"; that is connected to itself(!) by the property P1. The instance "http://collection.amuseum.org/id/object/1234"; in this figure is rdf:type E22 Man-made Object and also rdf:type E42 Identifier. - The figure on p.14 mixes up authority terms with classes and instances. It shows that the "type" of a production should be expressed as directly by assigning a "P2 has type". I think something like "Engraving" would be a "E29 Design or Procedure". The property "P7 took place at" has the range "E53 Place" and not some theaurus term as indicated. A thesaurus of production types is an instance of "E32 Authority Document". - The figure on p.15 shows a red property "PX" which is not mentioned in the surrounding text. Properties about properties can not be expressed in RDF(S) and so it is very problematic to mention them at all with any hint on how to deal with them. The "Production Association" has two properties "P2 has type". Therefore the distinction between "Person (Authority)" and "Person (Made for)" would be implecit knowledge and not represented by the graph without further information. As stated in this figure, "Person (Authority)" and "Person (Made for)" is the same. - The "Bibliographic Object" in the figure on p.20 has two rdf:type properties with range http://purl.org/ontology/bibo/Journal - The paper lacks information on how to deal with datatypes. In many figures (e.g. p19) the information where to put the name of a person or the title of an image as a string or literal is missing. If they are mentioned, the usage is not very consistent when you look at the figures in the annex. The "Inscripton"-figure (p.18) uses rdfs:label to represent the string of the translation which is attached to an instance of "E33 Linguistic Object". The scope note of E33 says: "The text of an instance of E33 Linguistic Object can be documented in a note by P3 has note: E62 String". The construct of assigning appellations and identifiers with "E41 Appellation" and its subclasses is mentioned once on p.11, but it is missing in every figure. In my opinion the current state and focus of this paper is far from being photo-ready and it is a way too early for any kind of approval. Best regards, Georg 2014-08-10 13:16 GMT+02:00 Richard Light <[email protected]>: > Hi, > > While I was happy to spend over an hour reading this document, and while I > understood and agree with its content, I'm not sure that someone who started > by knowing nothing of the CRM would achieve either of these things. > Sometimes "less is more", and I think this document tries to do too much. > > The first sentence states the document is for "cultural heritage managers, > professionals, researchers and scholars". If that is the case, one could > argue that the arguments should be made conceptually, and that the technical > details of RDF, Linked Data, etc. could be removed entirely, or just > mentioned in passing in a brief "implementation" section. Putting this > point another way, if the document were for "cultural heritage systems > developers, web programmers and data integrators", in what ways would it be > different? I would certainly hope that it would be. > > The primer should start from a position that is meaningful to the intended > audience (e.g. by taking an example of an object as it might be catalogued > in two rather different systems) and lead them in a logical way through to > an understanding of the intellectual harmonisation which the CRM offers. It > might be useful to write a training brief for the primer: "by the end of > this document you will know/understand A, B, and C, and will be able to do > X, Y and Z". And a one-page Executive Summary might be useful, both for the > creator of the primer, and for those readers who don't have a spare hour to > enhance their knowledge. :-) > > Richard > > > On 08/08/2014 16:49, martin wrote: > > Dear All, > > Please have a look at this document: > http://www.cidoc-crm.org/docs/CRMPrimer_v1.1.pdf > on page: > http://www.cidoc-crm.org/technical_papers.html > > and let us know if you approve it as CRM-SIG statement > or propose improvements. > > Best wishes, > > Martin > > -- > > -------------------------------------------------------------- > Dr. Martin Doerr | Vox:+30(2810)391625 | > Research Director | Fax:+30(2810)391638 | > | Email: [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] > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > > > -- > Richard Light > > _______________________________________________ > Crm-sig mailing list > [email protected] > http://lists.ics.forth.gr/mailman/listinfo/crm-sig >
