[Crm-sig] Document for approval
georg.hohmann at gmail.com
Tue Aug 12 10:58:29 EEST 2014
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,
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
- 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.
2014-08-10 13:16 GMT+02:00 Richard Light <richard at light.demon.co.uk>:
> 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. :-)
> On 08/08/2014 16:49, martin wrote:
> Dear All,
> Please have a look at this document:
> on page:
> and let us know if you approve it as CRM-SIG statement
> or propose improvements.
> Best wishes,
> Dr. Martin Doerr | Vox:+30(2810)391625 |
> Research Director | Fax:+30(2810)391638 |
> | Email: martin at 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 at ics.forth.gr
> Richard Light
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
More information about the Crm-sig