Martin,
As we close this discussion (which I agree has been very productive) I
would like to make the following points:
* widely-used systems such as WikiData and Geonames manage quite
happily with numeric identifiers. We should look at how they manage
to disclose the meaning of each URI to their users
* in my experience, real-life instances of CRM-encoded data can
involve chains of class-property-class-property-... which can be
quite long. If each individual class and property URI includes its
label, these chains will become unwieldy to read, leading to
criticisms of the CRM as 'too verbose' (as against the potential
'too cryptic' criticisms which Rob points out :-))
* I strongly support Francesco's suggestion that we use this
discussion as a spur to move beyond a static expression of the CRM
in RDFS to a web-based framework which actively supports its users
Best wishes,
Richard
On 24/07/2018 21:38, Martin Doerr wrote:
> 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 |
> --------------------------------------------------------------
>
>
> _______________________________________________
> Crm-sig mailing list
> [email protected]
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
*Richard Light*
