[Crm-sig] Document for approval
do_home at btopenworld.com
Tue Aug 12 18:40:16 EEST 2014
None of my emails have made it to the list - probably for a long time - but I haven't been getting a bounce.
Below is the last email which explains the rationale for the paper.
I would add this. We wanted the paper to be as short as possible. The additional information on RDF/Linked data is more about orientation. They answer questions that are not deep and technical but provide some insight at a high level about how some aspects work in practice. The document is not aimed at people who want to start programming. There is little point having detailed technical discussions about the details of RDF and URI with respect to this paper. This misses the point.
We all come from different backgrounds but all already have an understanding of a lot of the issues. The real test is when non CRM-SIG people read it and feedback. Therefore although I have posted this paper to the list I have also given review copies to people who have no dealing and knowledge of CRM i.e. the people that this document is aimed at. We can debate this till the cows come home but the real test is whether we can convey what the CRM is about to people who don't know anything about it but work in an environment where it is relevant for them to know about it.
The first two responses were as follows;
A project manager working on general business projects. The questions were;
1. Did you understand the CRM after reading the document. Ans: Yes
2. Was it at the right level for you. Ans: Yes
3. Do you think it would be useful for other people in other posts: Ans: Yes (e.g. People working with digital content, people working with museum systems (CMS), people who use the data (curators, researchers), Managers of all those roles. Other types of managers might not get it.
4. Did you think it was over complicated: Ans: No
5. Did you think it was too simple: Ans: No
6. Things that could have been done better: Ans: More analogies could be useful.
7. Was the technical content the right level: depends - it was fine for me. Some people might want to know more technical information but memorable examples are more important.
8. General comments:
You can't just skim it or read bits (unless you know the CRM already) you need to read all the way through it to get the benefit from the document.
I haven't got the full response from a second reader yet (a Head Keeper of a Curatorial department) but the initial response was that they felt that they now understood the CRM to the level they needed but that the document could do with a few more examples.
My point being that it may be more useful to give the document to people who are not closely linked with CRM and linked data already and don't already have a firm view about what such a document should contain but the information may be relevant to them in the near future. The document is no use to people who already have a good understanding of these things. They do not need a Primer.
From: Georg Hohmann <georg.hohmann at gmail.com>
To: "crm-sig at ics.forth.gr" <crm-sig at ics.forth.gr>
Sent: Tuesday, August 12, 2014 11:27 AM
Subject: Re: [Crm-sig] Document for approval
> It would be nice if you also could tell me if you thought that there was
> anything positive and useful in the paper that you thought should stay?
It's hard to say as long as the primary focus of the paper is not
clear. To my understanding a primer is a document that provides a
brief overview of the goals, purposes, concepts, documents and sources
about a specific topic. This could be complemented by a rough
walkhtrough by example as Richard noted. There are several primers on
the web that could serve as a model.
There is already a "comprehensive introduction"
(http://cidoc-crm.org/comprehensive_intro.html) to the CRM available,
so first there should be a clear definition of audience to be
addressed by this paper. What is the kind of audience you had in mind?
I would prefer a primer that addresses people not only from the
cultural heritage sector who come in contact with the CRM the first
time. These people should be considered as museums staff(!),
historians, archaeologists, lingustists, librarians, archivists and so
on and not as computer scientists or linked data architects.
Given that, the first part of the paper (Chapter 1-7) could be a good
starting point for a primer with additional examples. Chapter 8-9 may
support the idea of "crm linked data guidlines", but I don't really
see the need for that. The purpose of Chapter 10 is unclear to me, the
part about "The Power of Big Data" doesn't fit (in this way) to the
idea of a primer.
Two additonal remarks:
- Overall it seems a bit odd that a document should be "approved as
CRM-SIG statement" that is obviously work in progress - at least
regarding the many comments, questions and underlinings in the
document itself. Why the hurry?
- As I'm not a frequent participant of the SIG meetings, it's a kind
of suprise to me that the SIG focuses on implementation guidelines. In
the past there has been quite a discussion about this topic, and to my
understanding there was a common sense not to give implementation
recommendations. Now the primer states something like "If you would
like to find out more about the CIDOC CRM and how to implement it",
there is a "CRM Lab" (with unknown/not be specified members) and there
are explicit drafts for rdf(s) implementations and URI schemes. Is
that a paradigm shift I missed?
> From: Georg Hohmann <georg.hohmann at gmail.com>
> To: crm-sig at ics.forth.gr
> Sent: Tuesday, August 12, 2014 8:58 AM
> Subject: Re: [Crm-sig] Document for approval
> 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,
> 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
>> 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
>> 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
>> 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.
>> 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
>> creator of the primer, and for those readers who don't have a spare hour
>> 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
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
Crm-sig mailing list
Crm-sig at ics.forth.gr
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Crm-sig