Dear All,
We never continue an alphanumeric designation when there is a
significant change in definition. You can take for granted that
continuing the
designation means that the change is not significant.
The case below (P148) should be due to an internal processing problem,
and will never reoccur. It is characteristically the last property of
this edition.
The reason, if I am not wrong, was that we got out of sync with the ISO
version with the latest changes. Since the ISO team does in general not
respect our
continuity concerns when there was parallel work, we had some times the
bitter choice between our continuity and not to create a different
branch from ISO for
typical reasons. Probably should have been explicitly justified.
If you sport any other reuse of an alphanumeric code, please inform us.
Since we have discussed for years the issues with changing labels, I
repeat quickly the reasons:
Labels are taken for mnemonics, and people associate, even they
shouldn't, semantics with it.
Therefore labels change when they render better the concept and serious
misunderstandings can be reduced following explicit community requests.
The fact that the alphanumeric code is continued, marks absolutely clear
that this is a change of name and not meaning.
Labels are also translated, and work as mnemonics of the respective
language.
Therefore labels are not part of the definition.
The rest are considerations of use, and a question of utilities, which
cannot dictate our practice.
Anyone working in an IT environment should have access to someone doing
the trivial task of mapping label changes in his S/W,
if he has chosen to include labels in the URIs without "same_as"
statements. Please consider in your requirements, that continuity of
meaning is as important as comprehensibility. We cannot follow advise
which considers only one side of the medal.
F10 was deliberately declared as "F" in FRBRoo to be an FRBRoo concept
"same as" E21, for didactic reasons. There is no continuity break.
Please let me know if there is anything wrong with this.
All the best,
Martin
On 1/18/2018 2:38 PM, Gordon Dunsire wrote:
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:rich...@light.demon.co.uk]
*Sent:* 18 January 2018 12:30
*To:* Carlisle, Philip <philip.carli...@historicengland.org.uk>;
Gordon Dunsire <gor...@gordondunsire.com>; 'Robert Sanderson'
<rsander...@getty.edu>; 'Jim Salmons' <jim.salm...@factminers.org>;
crm-sig@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 <#_E28_Conceptual_Object> Conceptual Object
Range: E75 <#_E75_Conceptual_Object> Conceptual Object Appellation
Subproperty of: E1 <#_E1_CRM_Entity> CRM Entity. P1
<#_P1_is_identified> is identified by (identifies): E41
<#_E41_Appellation> 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://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.
Historic England Logo <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
<%20http:/www.ecclesiastical.com/fororganisations/insurance/heritageinsurance/100-places/index.aspx>.
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-boun...@ics.forth.gr] *On Behalf Of
*Gordon Dunsire
*Sent:* 18 January 2018 09:22
*To:* 'Robert Sanderson'; 'Richard Light'; 'Jim Salmons';
crm-sig@ics.forth.gr <mailto:crm-sig@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
Cheers
Gordon
*From:*Crm-sig [mailto:crm-sig-boun...@ics.forth.gr]
<mailto:[mailto:crm-sig-boun...@ics.forth.gr]> *On Behalf Of
*Robert Sanderson
*Sent:* 17 January 2018 16:52
*To:* Richard Light <rich...@light.demon.co.uk
<mailto:rich...@light.demon.co.uk>>; Jim Salmons
<jim.salm...@factminers.org <mailto:jim.salm...@factminers.org>>;
crm-sig@ics.forth.gr <mailto:crm-sig@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*
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email: mar...@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 |
--------------------------------------------------------------
