[Crm-sig] Document for approval
do_home at btopenworld.com
Tue Aug 12 17:51:32 EEST 2014
Dear Georg (take two!),
That's a no then. ;-) However, I can now see more clearly your issues, so thank you for this additional email.
The paper makes it very clear that CRM can be implemented using different models and is independent of technology. I am happy to make this a stronger statement if you feel that it needs it. In Section 5 is states - "It is independent of any technical implementation framework".
The use of RDF in this paper is simply as a device for showing examples. "Real" examples are important and users of the document have asked for them, and actually asked for more examples to be inserted. Whenever I make presentations to the Directors of the BM they ask for concrete examples. I am not sure why people are reluctant to provide them and why you wouldn't.
Commonly, because museums and other CH organisations are slowly entering the linked data world, people want to know what the connection is between CRM and linked data. It would be a mistake to try and show many different examples using different schemas in a Primer (I accept that you wouldn't provide any examples but I will come on to that later). This means that all the information that managers hear about linked data from all sorts of different sources can be associated with and have a connection with CRM information (from the Primer). This is an important point because if people don't understand that there is a connection then it might not be included/mentioned in organisational digital strategy policies that include a linked data strategy. It is therefore, without making any recommendations, extremely expedient to use linked data as the representational example and to make this valid association while still stating that it is neutral as to technology
- which it is (we currently have BM CRM data in two different models one of which is not RDF). RDF just becomes a vehicle for showing how it works in practice. One aim of the primer should be to get people to use the CRM. What is the most likely way that they may use it?
The common factor underlying some of your criticisms (for which I am very grateful that you have taken the time to provide) seem to imply a reluctance to give a non-technical audience some technical information. The idea of the Primer is not to teach people RDF or linked data but to show that CRM has real practical application and show that it is not just a theoretical and conceptual thing - something still assumed by some people. I am not sure why there is a problem with non-technical people seeing technical examples. This division is often cited as one of the reasons why the Digital Humanities is not progressing as it was envisaged. Digital Humanities needs Digital Humanists/Curators. For example, Unsworth 2002 statement.
"Those representations — ontologies, schemas, knowledge representations, call them what you will — should be produced by people trained in the humanities. Producing them is a discipline that requires training in the humanities, but also in elements of mathematics, logic, engineering, and computer science"
Many technical people get very upset about showing supposedly “non-technical” people, technical examples. However, if we don't start introducing our curators (and humanists generally) to these things and continue to keep this knowledge separate, how can they participate in the discussions and the work more fully?The examples are very basic in any case, but why shouldn't curators (I am a curator) take an interest in some computer science and technology? Isn't that what Unsworth's quote is saying. This happens in other disciplines.
There is no particular hurry or deadline. It would be good to have a Primer though and some people have got together in their own spare time to contribute some time towards producing one. That must be a good thing, and something that we can all be positive about.
The CRM Lab was constituted at the CRM-SIG and has terms of reference which are on the site. The link is here http://www.cidoc-crm.org/docs/29th-meeting-presentations/CRMLab%20Terms%20of%20Reference09.docx . The aims include;
1.Education of end users.
2.Implementation of CRM within new projects.
3.Specification and development of new tools to support the use of the CRM.
4.Specification of processes of good practice
The Primer was an agreed output from one of the SIG meetings.
Thanks very much for your comments and I will certainly attend to some of the issues that you have kindly spotted.
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