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
