[Crm-sig] Document for approval

Georg Hohmann georg.hohmann at gmail.com
Tue Aug 12 13:27:28 EEST 2014


Dear Dominic,

> 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?

Best,
Georg



> ________________________________
> 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,
> Georg
>
>
>
> 2014-08-10 13:16 GMT+02:00 Richard Light <richard at light.demon.co.uk>:
>> 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: 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
>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>>
>>
>> --
>> Richard Light
>>
>> _______________________________________________
>> Crm-sig mailing list
>> Crm-sig at ics.forth.gr
>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>>
> _______________________________________________
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
>


More information about the Crm-sig mailing list