On 23/01/2018 16:07, Martin Doerr wrote: >> 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. I would be interested to (re-)read the arguments. However, I repeat my assertion above that there should also be a label-free version of each CRM class and property identifier. I am perfectly happy that this should be flagged as being the same concept as a variant whose identifier includes a label (i.e. "E2 owl:sameAs E2_Temporal_Entity"). I'm even happy for the label-free identifier not to be the "preferred" form.
Implementers who want their CRM RDF to be valid into the long-term future must surely realise that the convenience of a "human-readable" identifier is negated by the possibility that the CRM SIG might change that identifier at some point in the future - which you are claiming the right to do - and so invalidate their RDF. (Maybe they just need better tools. :-) Linked Data resources with opaque URIs are hardly unusual: take Geonames and the Getty vocabularies as examples.) Has this specific argument been made before, and, if so, how was it rebutted? > 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:-). In that case it might be argued that the multilingual labels are not helpful. And, in fact, we could not meet the uniqueness requirement for SKOS preferred labels, since our labels are not guaranteed to be unique. What we should have are translations of the full scope notes for each class and property. > 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. Having thought about this some more, and started to write an RDF-to-SKOS transformation:-), I have come to the same conclusion. Also, I didn't know about X3ML, which I agree is exactly the right sort of approach for expressing mappings declaratively. Best wishes, Richard > > All the best, > > martin >> >> >> _______________________________________________ >> Crm-sig mailing list >> Crm-sig@ics.forth.gr >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig > -- *Richard Light*
