[Crm-sig] ISSUE Form and persistence of RDF identifiers
martin at ics.forth.gr
Mon Jan 22 20:20:30 EET 2018
On 1/22/2018 7:12 PM, Robert Sanderson wrote:
> An interesting investigation would be to try and reuse existing terms
> from well-known ontologies, rather than creating yet another one.
> To Martin’s point about just renaming all the things … that sounds
> easy in theory, but in the distributed real world of implementations
> and datasets, in practice it means that everyone needs to support all
> of the different permutations as there’s always some product or some
> piece of data that hasn’t updated to the most recent version.
It is not about renaming all things, it is about not excluding renaming
while preserving the identification code.
An unchanged standard is an illusion, a fiction not worthwhile sticking
to. I use to present it this way:
The good with standards is there are so many!
When you have a standard,
You need to transform to the standard
You need to renew and adapt the standard
You need to transform to the renewed standards
Why not just transform data?
There are too many transformations, you need a standard
> One small benefit would be that new serializations like JSON-LD would
> have more liberty to assert their own mappings over top of the
> alphanumeric designations, rather than feeling beholden to the
> labels. Of course for every other serialization it’s going to be
> completely unintelligible and thereby unusable.
The challenge is a) to understand that mapping, not the standard is the
b) how to standardize the mapping
c) to minimize the needs to map
> *From: *Crm-sig <crm-sig-bounces at ics.forth.gr> on behalf of Richard
> Light <richard at light.demon.co.uk>
> *Date: *Monday, January 22, 2018 at 6:37 AM
> *To: *"crm-sig at ics.forth.gr" <crm-sig at ics.forth.gr>
> *Subject: *Re: [Crm-sig] ISSUE Form and persistence of RDF identifiers
> 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.
> 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.
> 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. 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?
> Best wishes,
> 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,
> *Richard Light*
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email: martin at 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 |
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Crm-sig