[Crm-sig] ISSUE Form and persistence of RDF identifiers

Gordon Dunsire gordon at gordondunsire.com
Thu Jan 18 14:38:28 EET 2018


All

 

[My first response was blocked because the thread was “too long”; here it is again]

 

I agree with Philip [and Richard]

 

If the domain or range of a FRBRoo property is changed, or there was a significant change in definition, we would deprecate the old version and declare a new URI. This hasn’t happened yet, but would beg the question of what to use as a new URI – perhaps add a version number to the alphanumeric part. For that reason we would advise the FRBR Review Group to mint a new alphanumeric designation.

 

Cheers

 

Gordon

 

From: Richard Light [mailto:richard at light.demon.co.uk] 
Sent: 18 January 2018 12:30
To: Carlisle, Philip <Philip.Carlisle at HistoricEngland.org.uk>; Gordon Dunsire <gordon at gordondunsire.com>; 'Robert Sanderson' <RSanderson at getty.edu>; 'Jim Salmons' <jim.salmons at factminers.org>; crm-sig at ics.forth.gr
Subject: Re: [Crm-sig] ISSUE Form and persistence of RDF identifiers

 

Phil,

This is alarming.  I have always assumed that a superseded class or property would simply be flagged as "deprecated" and a new one minted to replace it. There is absolutely no need to re-use numbers, and I am hoping someone will come forward to say that this was a mistake, and not a change which accords with CRM-SIG policy.  Otherwise, as you say, we can have no confidence in the CRM as a persistent RDF framework, whether or not the class and property identifiers include a textual component.  Is this an isolated case, or does anyone know of other cases where domain and range (and indeed meaning) of a class or property has been changed after its initial publication?

(The textual component is, in any case, only meant to be guidance and is explicitly stated not to be unique: 'is identified by' below is a good example of this.)

Best wishes,

Richard

On 18/01/2018 10:29, Carlisle, Philip wrote:

Hi all,

I agree that using the number alone as the identifier would be the way forward particularly with regards to the changing of the name of a class or property.

 

However this would only work if the domain/range and scope of the class or property remain the same.

 

There is at least one instance of a property in the CRM where the number has been retained but the context of the property has completely changed.

 

The property in question is P148.

 

In the CRM version 4.2.2 we had: 

 

P148 is identified by (identifies)

 

Domain:                                E28 Conceptual Object

Range:                   E75 Conceptual Object Appellation

Subproperty:        E1 CRM Entity. P1 is identified by (identifies): E41 Appellation

Quantification:    many to many (0,n:0,n)

                                 

Scope note:           This property identifies a name used specifically to identify an E28 Conceptual Object. 

 

This property is a specialisation of P1 is identified by (identifies) is identified by.

 

Examples:             

*	The publication „Germanisches Nationalmuseum (GNM), Fuehrer durch die Sammlungen” (broschiert), Prestl 1995 (E73) is identified by ISBN 3-7913-1418-1 (E75)

 

 

According to the appendix of CRM 5.1.2 as amendments to CRM 4.2.5 the property P148  changed to

 

P148  has been changed

 

BEFORE

 

P148 is identified by (identifies)

 

Domain:                                E28 Conceptual Object

Range:                   E75 Conceptual Object Appellation

Subproperty:        E1 CRM Entity. P1 is identified by (identifies): E41 Appellation

Quantification:    many to many (0,n:0,n)

                                 

Scope note:           This property identifies a name used specifically to identify an E28 Conceptual Object. 

 

This property is a specialisation of P1 is identified by (identifies) is identified by.

 

Examples:             

*	The publication „Germanisches Nationalmuseum (GNM), Fuehrer durch die Sammlungen” (broschiert), Prestl 1995 (E73) is identified by ISBN 3-7913-1418-1 (E75)

AFTER

 

P148 has component (is component of)

Domain:                                E89 Propositional Object

Range:                   E89 Propositional Object

Superproperty of:                

Subproperty of:                   

 

Quantification:    (0:n,0:n)

 

Scope note:          This property associates an instance of E89 Propositional Object with a structural part of it that is by itself an instance of E89 Propositional Object.

 

Examples:             The Italian text of Dante’s textual work entitled “Divina Commedia” (E33) P148 has component The Italian text of Dante’s textual work entitled “Inferno” (E33) 

 

 

In the document as amendments to CRM 5.0.3 we have, unbelievably, the following:

 

P149 is identified by (identifies)

It is decided to create a subproperty of P1 to connect E28 with E75 as follows

 

                P149 is identified by: E75

 

Domain:                                E28 <>  Conceptual Object

Range:                   E75 <>  Conceptual Object Appellation 

Subproperty of:   E1 <>  CRM Entity. P1 <>  is identified by (identifies): E41 <>  Appellation 

Quantification:    many to many (0,n:0,n)

 

Scope note:           This property identifies an instance of E28 Conceptual Object using an instance of E75 Conceptual Object Appellation.

 

Examples:             The German edition of the CIDOC CRM (E73) is identified by ISBN 978-3-00-030907-6 (E75) 

 

 

In this instance if the URI http://www.cidoc-crm.org/cidoc-crm/P148 had been in use in any implementation based on CRM 4.2.2 the change in label, domain and range would not have been picked up by an automatic update.

 

Furthermore at no point would it have been obvious that all instances of http://www.cidoc-crm.org/cidoc-crm/P148, in the original meaning, should be replaced with http://www.cidoc-crm.org/cidoc-crm/P149

 

This may have been an oversight on the part of the CRM-SIG however I would strongly suggest that in future if the SIG want to change a property or class that they check with those system owners who’ve actually been using the CRM in the real world to ensure that these whims do not affect the smooth running of any current implementations. 

 

If the aim of the CRM is to facilitate data exchange it would imply that each implementation should be able to rely on the properties and classes not changing their fundamental essence.

 

Re-use and re-assignment of numbers and labels is, to my mind, exceptionally bad practice.

 

Phil

 

Phil Carlisle

Knowledge Organization Specialist

Listing Group, Historic England

Direct Dial: +44 (0)1793 414824

 

 <http://thesaurus.historicengland.org.uk/> http://thesaurus.historicengland.org.uk/ 

 <http://www.heritagedata.org/blog/> http://www.heritagedata.org/blog/

 

Listing Information Services fosters an environment where colleagues are valued for their skills and knowledge, and where communication, customer focus and working in partnership are at the heart of everything we do.

 

 

	
	

 

	

 <http://www.historicengland.org.uk/> 

We help people understand, enjoy and value the historic environment, and protect it for the future. Historic England <http://bit.ly/1OuxROd>  is a public body, and we champion everyone’s heritage, across England.
Follow us:  Facebook <https://www.facebook.com/HistoricEngland>   |  Twitter <https://twitter.com/HistoricEngland>   |  Instagram <https://www.instagram.com/historicengland/>      Sign up to our newsletter <http://bit.ly/1p49z1e>      

Help us create a list of the 100 places which tell England's remarkable story and its impact on the world. A History of England in 100 Places <https://historicengland.org.uk/100places>  sponsored by Ecclesiastical. 



This e-mail (and any attachments) is confidential and may contain personal views which are not the views of Historic England unless specifically stated. If you have received it in error, please delete it from your system and notify the sender immediately. Do not use, copy or disclose the information in any way nor act in reliance on it. Any information sent to Historic England may become publicly available.

 

From: Crm-sig [mailto:crm-sig-bounces at ics.forth.gr] On Behalf Of Gordon Dunsire
Sent: 18 January 2018 09:22
To: 'Robert Sanderson'; 'Richard Light'; 'Jim Salmons'; crm-sig at ics.forth.gr <mailto:crm-sig at ics.forth.gr> 
Subject: Re: [Crm-sig] ISSUE Recording an E41 in RDF

 

All

 

It is for this reason that the IFLA declaration of URIs for the FRBRoo extension to CRM drops the name, and uses only the notation:

 

 <http://metadataregistry.org/schemaprop/list/schema_id/94.html> http://metadataregistry.org/schemaprop/list/schema_id/94.html

 

Cheers

 

Gordon

 

From: Crm-sig [mailto:crm-sig-bounces at ics.forth.gr] <mailto:[mailto:crm-sig-bounces at ics.forth.gr]>  On Behalf Of Robert Sanderson
Sent: 17 January 2018 16:52
To: Richard Light <richard at light.demon.co.uk <mailto:richard at light.demon.co.uk> >; Jim Salmons <jim.salmons at factminers.org <mailto:jim.salmons at factminers.org> >; crm-sig at ics.forth.gr <mailto:crm-sig at ics.forth.gr> 
Subject: Re: [Crm-sig] ISSUE Recording an E41 in RDF

 

 

Here’s a quick addition …

 

The RDF representation uses the names of the classes and predicates in the URIs that identify them.  This means ;l

that when the names change, the URIs change and this invalidates all of the previous uses.  As the SIG considers only the number to be important, there is a mismatch of expectations around persistence and versioning.

 

Examples: E78_Collection versus E78_Curated_Holding and the recent thread about renaming translation_of.

 

Rob

 

…

 

 

-- 
Richard Light 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20180118/2198d7c3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 6074 bytes
Desc: not available
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20180118/2198d7c3/attachment-0001.jpg>


More information about the Crm-sig mailing list