Dear Richard,
On 1/22/2018 4:37 PM, Richard Light wrote:
On 19/01/2018 13:36, Martin Doerr wrote:
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.
OK, thanks for the explanation. Though I don't understand why 'ISO'
(who, exactly?) was doing active development work on the CRM. I
thought that they simply took the SIG's work through the ISO
formalization process.
ISO working group decisions supersede ours. They will listen to
arguments of our liaison people, but often it is better to accept than
to risk another year of discussions about a label.
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.
I think that this argument is perfectly valid for the 'Definition of
CRM' document. However, by publishing an RDFS expression of the CRM
we are moving, whether we like it or not, into the realm of
'utilities'. People are picking up and using our RDFS definitions in
a variety of ways. In this particular implementation context, I would
argue that we should ensure that there is a label-free version of each
CRM class and property. Also, our guidance on the use of our RDFS
implementation should recommend the use of this label-free version, on
the grounds that we cannot guarantee the stability of the version
which includes a label.
The issue was decided in the 27th meeting, as documented in the agenda.
We had produced label-free definitions with language labels, as you
propose, which caused an outcry from implementers that saw only numbers
and had not tools showing the display labels. Since there is no new
evidence to the issue, I'd propose to stay as we are and I'll try to
make the respective discussion thread accessible, so that all the old
arguments can be read again.
The current RDFS reads, e.g.:
<rdfs:Class rdf:about="E2_Temporal_Entity"><rdfs:label
xml:lang="fr">Entité temporelle</rdfs:label><rdfs:label
xml:lang="en">Temporal Entity</rdfs:label><rdfs:label
xml:lang="ru">Временная Сущность</rdfs:label><rdfs:label
xml:lang="el">Έγχρονη Οντότητα</rdfs:label><rdfs:label
xml:lang="de">Geschehendes</rdfs:label><rdfs:label
xml:lang="pt">Entidade Temporal</rdfs:label><rdfs:label
xml:lang="zh">时间实体</rdfs:label><rdfs:comment>
as outcome of a long-standing discussion...........
This talk of preferred labels and your mention of the labels in other
languages leads me to wonder whether anyone has produced a SKOS
version of the CRM.
Your suggestions well taken, but I do not see what this would offer in
contrast to the current international display labeling as shown above.
This might be a useful exposition of the logic of the CRM, expressed
in a format which is widely used and supported. We could have
'preferred labels' for each concept in as many languages as we like.
A SKOS version would be no use for instance data, because each SKOS
concept is itself an instance, in OWL terms, but it might be a
powerful tool for expressing relationships between concepts in
different schemes, i.e. exactly the purpose for which the CRM was
originally created. Thoughts, anyone?
CRM classes are not**terms. The CRM is an ontology of relationships.
Classes are only auxiliary for relationships. Therefore we delete
classes without relationships. The classes belong to a completely
artificial language. Therefore I'd argue there is nothing like a
"preferred label". People must understand the scope notes, nothing
else. The purpose for which the CRM was and is created is to mediate
data structures, i.e. between relations connection "fields", not between
"terms". If this is not clear enough from the CRM introduction, please
let us know how to improve the text:-).
Therefore, to my opinion, it is impossible in SKOS to represent the
logic of the CRM. A pure class-class-mapping is usually misleading.
However the X3ML mapping language can map relationships in a declarative
way.
All the best,
martin
Best wishes,
Richard
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
--
*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 |
--------------------------------------------------------------
