[Crm-sig] Issue: CRM compatibility

Stephen Stead steads at paveprime.org
Fri Apr 25 22:12:18 EEST 2008

Dear all

A few thoughts triggered by Nick’s excellent assessment. I have been
thinking about what it means to be compliant for some time and have some
trouble coming up with a set of things that I would expect an application to
be able to do to be compliant. We have spent a lot of time saying we do not
want to know what you are doing or why; that is your business. We are not
here to tell you what to record that is the business of content standards. 

So what the CRM is really about is preserving meaning through transforms of
the data. So what I need to be able to do is to answer the same questions
that could be asked of the original data and get the same answer after
export to the CRM as before it was exported. That is there has been no
semantic loss. However I am not certain that this is true if the data is
very specialised and the application is asking questions that can only be
answered at that level of detail. Maybe it is enough to be able to answer
questions at the level of interoperability. 

So things that are important as a starting point for debate.

1] The output must be render-able with a standard XSLT/tool (like the one
from the website) into a human readable form

2] A complete download of the content of a system should result in an output
that can be imported into a vanilla installation of the same system and
provide the same content. That is all look-up tables, thesauri and online
manuals must come in with the data.

3] At a minimum, certain standard interoperability questions should be
answerable from the exported data. This will stop compatibility at the level
of everything is in a P3 has note E62 String being considered useful. The
questions should include (lots of debate here I feel)

A] Which E2 Temporal Entity’s has the E77 Persistent Item been present at
and the reverse.

B] What does each E55 type used mean.

C] List all E41 Appellation’s that have been used for this E1 CRM Entity
(that we know of!).

D] Who recorded the data.



My personal opinion is that we should not allow for a “subset” export that
does not include the reference data. You might do that operationally but
that does not make you compliant.

I think the logo is important and has to include a tick!




Stephen Stead

Tel +44 20 8668 3075 

Mob +44 7802 755 013

E-mail  <mailto:steads at paveprime.com> steads at paveprime.com


From: crm-sig-bounces at ics.forth.gr [mailto:crm-sig-bounces at ics.forth.gr] On
Behalf Of Nicholas Crofts
Sent: 25 April 2008 10:10
To: crm-sig
Subject: Re: [Crm-sig] Issue: CRM compatibility


Dear all,


A few thoughts about being “CRM compliant”.


For software vendors, being or not being CRM compliant has started to become
an important issue. This is actually a very good sign since it demonstrates
that the CRM has made a real impact and is being taken seriously.
Consequently it is both timely and important that we find ways to clarify
the issue of compliancy. As has been pointed out by others, we cannot allow
the question to remain unsettled for long since a barrage of unsupported
claims and counter claims about compliancy will quickly discredit the
standard and undermine years of hard work.


There are essentially two paradigms by which compliance with a standard can
be established:


1.	By independently verifiable criteria

2.	Certification by a certifying authority. 

The first model is ideal when easily verifiable criteria form part of the
standard itself. This applies most obviously to technical standards which
consist of instructions or rules about how to do something, such as SQL-92,
or XML. Being conformant with the standard simply means that all the rules
are respected. Whether the rules are respected or not is obvious and easy to
check. Often, conformancy may be verified by a battery of technical tests,
sometimes provided in the form of a validation service. e.g. The W3C syntax
validator at http://validator.w3.org/ <http://validator.w3.org/$> 


Something like the second model becomes necessary when the condition that
need to be met are complex or subject to interpretation. Sectrum
accreditation, administered by the Collections Trust (formerly mda), is an
example of this approach. Being compliant with Spectrum is the result of a
formal testing process carried out by the Collections Trust and requires
that software vendors become members of the Spectrum Partners Scheme,
http://www.mda.org.uk/mempf. <http://www.mda.org.uk/mempf>  (for which there
is an annual fee). Similarly, compliance with ISO 9000, 9001 and 9004
standards can be established by a certifying authority, as a result of an
audit which needs to be renewed every three years. (Unlike the Collections
Trust, ISO does not perform the certification itself: audits are carried out
by accredited third-party agencies, in accordance with an established


It is important to note that the certification authority has to be seen to
be both competent and disinterested in order to be accepted as legitimate. 


As I see it, the current with respect to CRM compliance leaves a lot to be


1.	The criteria which constitute CRM compliancy are not clearly

2.	There is no recognised and established body which can legitimately
claim the right to certify that a product is or is not CRM compliant.

3.	Consequently, there is no clearly defined testing procedure by which
CRM compliancy can be established.

It might be thought that ISO 21127, the 'official' version of the CRM,
constitutes a set of independently verifiable rules by which conformance can
be objectively established. I would argue that this is not the case,
primarily because the CRM, as a conceptual model, does not deal with
questions of implementation and use. Implementation requires interpretation
and the CRM can be used in many diverse ways. It is not a simple matter to
define which interpretations and uses are compliant and which are not. There
is also the question of scope. Does an application have to implement all of
the CRM to count as compliant, or just part of it? If a partial
implementation is considered acceptable, what is the minimum requirement? At
present, we do not have clear-cut answers to these questions. 


As for the 'certifying authority', it might be argued that CRM-SIG already
constitutes such a body, since that is where much of the CRM expertise is to
be found. However, as it stands, the CRM-SIG is not a satisfactory candidate
for this role. Firstly, its membership is open and fluctuating. It is not
clear exactly who within the CRM-SIG would be able to certify CRM
compliancy. It would be impractical to expect the CRM-SIG as a whole to
undertake such a task since would be too large a body. Inversely, not all
individuals members of the SIG have the necessary competence and some,
stake-holders with commercial interests, may lack the required neutrality. 


Standards certification is clearly outside the remit of the ISO working
group (ISO TC46/SC4/WG9) which, furthermore, lacks the resources to assume
this sort of task.


Finally, the CIDOC documentation standards group has neither the expertise
nor the stability to assume the role of certification authority.


So what we can we do to improve the situation? To set the ball rolling here
are a few suggestions.


Setting up and running a certification agency is a complicated business, so
we should try to find ways to avoid this if possible by allowing validation
through independently verifiable criteria.


It may be helpful to establish different levels of conformance, starting for
example, from some core elements – as as Martin has suggested – and
proceeding to a 'theoretical' maximum coverage. The CRM-SIG could decide
which elements are core elements and what constitutes the different level of
conformance. The notion of “core elements” should not, I think, be
restricted simply to classes and properties, but should encompass
functionality too - such as handling of shortcuts, query containment for
subclasses, sub-typing, handling of extended data schemas, etc. 


It would be very appealing if a suite of automated tests could be developed
which would allow independent verification of compliance. One way of doing
this might be to have a test dataset, or several graded datasets, which
applications would have to import, modify and export. The results could be
evaluated automatically. This presupposed, of course, that we have at least
one standardised import/export format for representing CRM compatible data.


A 'cosmetic' but psychologically important detail – we might consider
designing a compatibility logo, or certificate that could be used as a
sticker on compatible products. 


Best wishes



martin <martin at ics.forth.gr> wrote:

Dear Edmund,

That is helpful indeed. We have specific datasets that encode simple cases
in a simple schema,
which can be mapped to the CRM, but not all foreseen cases of use of this
schema could be mapped to
the CRM. So, the system (e.g., DC) is not compliant, but the data were.

Another problem are very dedicated systems, such as the cross-reference
lists of Roman Inscriptions
maintained by Clauss-Slaby in Frankfurt, which maps to the CRM, but does not
contain any event. But
then their scope does not extend to events actually.



LEE, Edmund wrote:
> Hello Martin,
> Indeed I think this is an essential area to protect the integrity of the
> CRM. In the recent development of MIDAS Heritage
> (www.midas-heritage.org.uk) for the UK historic environment sector much
> thought and attention was given to compliance.
> Essentially there are two forms of compliance with MIDAS Heritage:
> information system compliance (i.e. the software can provide all the
> necessary features to comply) and dataset compliance (the dataset
> contains all the necessary data, suitable to the objectives of the
> dataset). This reflects the opinion that theses aspects of compliance
> are typically the responsibility of different people - the software
> vendors, and the dataset managers.
> Is that useful? The detail is given in Part One of MIDAS Heritage pages
> 17 - 20.
> Edmund Lee
> Standards and Guidelines Manager 
> Training and Standards Team
> English Heritage
> NMRC, Kemble Drive
> Swindon
> SN2 2GZ
> Tel +44 (0)1793 414719
> Fax +44 (0) 1793 414444
> Find EH guidelines online at www.helm.org.uk 
> or www.english-heritage.org.uk/publications
> -----Original Message-----
> From: crm-sig-bounces at ics.forth.gr [mailto:crm-sig-bounces at ics.forth.gr]
> On Behalf Of martin
> Sent: 21 April 2008 11:43
> To: crm-sig
> Subject: [Crm-sig] Issue: CRM compatibility
> Dear All,
> Recently there seem to be increasing claims of compatibility with the
> CIDOC CRM. May be our
> standard text is not clear enough about that. I suggest to regard as
> minimal compatibility the ability to
> represent at least certain kinds of possibly multiple events associated
> with a Thing or an Actor.
> This needs further elaboration.
> Best,
> Martin


Dr. Martin Doerr | Vox:+30(2810)391625 |
Principle Researcher | 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) |
Vassilika Vouton,P.O.Box1385,GR71110 Heraklion,Crete,Greece |
Web-site: http://www.ics.forth.gr/isl |

Crm-sig mailing list
Crm-sig at ics.forth.gr

nicholas crofts consulting

cultural information management

gestion de l'information culturelle


av. miremont 23c 

ch-1206 genève 

+41 22 557 90 92 

nicholas at crofts.ch 

www.crofts.ch <http://www.crofts.ch/> 


Don't miss CIDOC 2008  www.cidoc2008.gr <http://www.cidoc2008.gr/> 



Sent from Yahoo! Mail
vt=52418/*http:/uk.docs.yahoo.com/nowyoucan.html> . 
A Smarter Email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20080425/bb34a676/attachment-0001.htm 

More information about the Crm-sig mailing list