Dear All,
I take George's message for a "*VETO*".
The vote is hereby canceled.
Under these circumstances, the issue will be discussed in the next
meeting. Please provide more objective evidence about costs and methods
of migrating between label versions and other changes, as George argues.
I thank you all for your contributions.
I am particularly pleased that members that tend to be more silent have
expressed detailed opinions, which we will respect further in the process.
All the best,
Martin
On 7/24/2018 12:40 PM, George Bruseker wrote:
Dear all,
I do not want to be obstructionist to progress on a pragmatic issue
but I feel that we should pause the vote process.
It seems to be that both sides have very good points and we need to
find a means to reconcile these as much as possible. Let me try to
abbreviate the main aspects of the points made so far:
As Rob points out, with the labels embedded in the class and property
names, we have a readable RDF and a single RDF of reference. These
are fundamental attributes we should be looking to support.
With a label-less entity/property version, we would have greater
neutrality from labels which is a strength with regards to robustness
against label update and creates linguistic neutrality. On the other
hand it means having two versions of CRM around leading to potential
interoperability problems and extra overhead. It also makes the plain
RDF unreadable in any sense except to the versed few.
Melanie’s point of the cost of change resulting from updates to the
standard is a very fundamental argument and I think a big aspect we
have to bear in mind, with which I believe Rob would concur. If
changes to labels cost user communities significant time and money,
this is a big problem to CRM sustainability. That being said, if the
SIG has historically been conservative about label changes, perhaps it
is not as big an issue as we think.
Before we move forward with creating a version like this:
I suggest that we need to check how many times we have changed class
or property names in the past to see how big an issue this is. From
the point of update robustness/cost to users/community (though not
linguistic flexibility) this is the major issue.
If we decide to make such a version, I would think we would want to
ensure that we have the correct mechanisms in place for ensuring
the management of the versions and the resolution and persistence of
the URIs as per Richard and Francesco’s suggestion. Along those lines,
I believe Francesco’s comments on the URI service and group ontology
development are fruitful. Indeed, joining them to Rob’s extended
questions about previous version names etc., much could be addressed
through a robust service for URI resolution of CRM entities and
properties.
Feel free to disagree with this summary if I have missed or
misinterpreted your points. I think we all share the same aim of
robust interoperability on the data level and just have to find the
right balance. I would invite that we check the label changes and
discuss how to robustly support CRM URI resolution before proceeding
to creating new RDF versions.
Best,
George
On Jul 23, 2018, at 8:11 PM, Francesco Beretta
<[email protected]
<mailto:[email protected]>> wrote:
Dear all,
I also vote YES.
Furthermore, I'd also like to stress the importance to distinguish
between the identifier, which must be stable during the whole life of
a class, or property, and the label(s), which can be multiple,
multilingual and evolve, as everyone knows.
The meaning of the class or property, as it was already stressed on
this list, is provided by the scope note and, in fact, by the scope
note AND the _version_ (or namespace) of CRM. Strictly speaking it's
always about a class in a specific CRM version: "This is the scope
note of E59 Primitive Value of the CIDOC CRM version 6." (cf. note 7
in the document under discussion).
Labels are often confusing. Therefore, it is not in my opinion just
for "convenience of implementation" (as the new document states) that
the RDF serialisation should define "number-only classes and
properties" but it is something fundamental. Therefore, in my
opinion, the alphanumeric form E7 should be the preferred one in the
URI, and of cours the URI with labels, insofar as used in earlier
versions, maintained as condition /sine aqua non/ of interoperability.
At the same time, the human should be always provided with an easy
way of retrieving the label(s) for his/her convenience. This is not
to be provided, in my opinion, by the RDF serialisation as a static
file (which will of course contain the labels) but by a dereferencing
service implemented as a web service where you can send the URI of
the class, or property, and receive a web-page for the human to
read, like this http://ontologies.dataforhistory.org/class/7 but
devoted to the whole CIDOC CRM community and dereferencing the
specified identifiers, like the Agent
<http://dbpedia.org/ontology/Agent> class in the DBPedia ontology.
The dereferencing page by DBPedia of Agent shows, in my opinion, the
limits of an identification for the class provided by the label: the
label in the URI will remain forever even if a better one is found
for the class, problems could be raised with disambiguation (at list
in the human mind, not by the machine), etc. On this same page
<http://dbpedia.org/ontology/Agent>, the property owl:equivalentClass
shows the solution by Wikidata mentioned by Melanie, which is
evidently more robust: https://www.wikidata.org/wiki/Q24229398. Of
course this solution, like the
"http://www.cidoc-crm.org/cidoc-crm/E7"; URI form needs double
dereferencing, for the human and for the manchine in form of a data
stream.
Therefore, in my opinion, in the context of semantic web the issue of
the ongoing discussion is much more about having a *URIs
dereferencing service* then adding labels to URIs specifications in
static documents. REF documents are useful for collective memory and
experts, but in every day life web services are more effective and
useful: just write the URI, and you'll get in tenths of a second the
answer.
In this same context, the CRM version's number should also be always
provided in the URI e.g. http://www.cidoc-crm.org/cidoc-crm/6.2/E7
because the scope note and labels depend on the version, they are not
absolute in the whole class (or property) history, and a URL
redirection could lead easily to the page
"http://www.cidoc-crm.org/Entity/E7-Activity/Version-6.2.1";,
providing at the same time HTML for me to read and RDF data (in XML,
json or whatelse) for consumption by the machine.
The same principle sould be applied to CRM extensions, e.g.
http://www.cidoc-crm.org/crm-geo/1.2/SP2.
In my opinion, this point sould be treated as a part of the
discussion we started in the last SIG in Lyon about improving CRM
versions and extensions management, and we should find in future a
more dynamic, web based way of managing versions and dereferencing.
And discussions... ;-)
All the best
Francesco
Le 23.07.18 à 18:02, Detlev Balzer a écrit :
I also vote YES.
Where natural-language names are desired for readability, why not allow for any
number of non-normative label sets? This would put Chinese or Armenian class
and property names on a par with the English ones, without compromising
interoperability as long as the distinction between URI and label is kept in
mind.
Best,
Detlev
Am 19.07.2018 um 18:39 schrieb Martin Doerr:
Dear All,
The current text "Expressing the CIDOC Conceptual Reference Model in RDF"
(https://docs.google.com/document/d/1zCGZ4iBzekcEYo4Dy0hI8CrZ7dTkMD2rJaxavtEOET0/edit?ts=5b50b922)
contains the phrase:
"In addition, for convenience of implementation we have defined number-only classes
and properties e.g. “E63” or “P2”, and declared each of them to be equivalent to the
corresponding full form"
In the past, this option was provided and widely rejected by users. I do not
know of any installation using it.
It was proposed again because CRM-SIG reserves the right to change labels without changing the code
("E63", "P2" etc.), in cases when the meaning is preserved but the existing
label causes confusion and can be replaced by a more fitting or at least less confusing one. These
changes are very rare, and explicit in the amendment of the respective version.
Those of you who support:
"In addition, for convenience of implementation we have defined number-only classes
and properties e.g. “E63” or “P2”, and declared each of them to be equivalent to the
corresponding full form"
please vote *YES.
*Those of you who support:
"The English label is part of the definition of the RDF classes and properties.
Number-only classes and properties e.g. “E63” or “P2”, are not provided". Other
means of supporting migration between label versions to be discussed.
please vote *NO.
*(Those who believe the issue is not sufficiently formulated please vote "VETO". One or
more "VETO" will stop the e-mail vote as a whole and postpone it to the next physical
meeting)
Best
Martin
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email:[email protected] |
|
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
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
_______________________________________________
Crm-sig mailing list
[email protected] <mailto:[email protected]>
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
_______________________________________________
Crm-sig mailing list
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email: [email protected] |
|
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 |
--------------------------------------------------------------
