We'd also support this direction and the move to standardising RDF guidelines. The need for standardisation of technical representations and encodings of the CRM (particularly RDF) has been a recurrent theme in CRM workshops and papers oriented to implementation issues over the last 10 years (*). We can't really achieve interoperability without this. Encouraging particular communities with shared use cases (as in linked.art) to adopt a set of consistent patterns for mapping instance data to the CRM is also a necessary ingredient of practical interoperability.
Doug Tudhope and Ceri Binding Hypermedia Research Group, University of South Wales (*) eg workshops on CRM implementation issues http://tpdl2013.upatras.gr/ws-crmex.php https://www.topoi.org/wp-content/uploads/2011/02/Programme_Datenwelten.pdf PS just seen Martin's concurrent reply to this thread and this is not taking issue with that, rather arguing that we can make significant progress by some basic implementation (RDF) extensions and mapping patterns, even though they will not solve all the problems ________________________________ From: Crm-sig [crm-sig-boun...@ics.forth.gr] on behalf of Conal Tuohy [conal.tu...@gmail.com] Sent: 01 March 2018 03:02 To: George Bruseker Cc: crm-sig (Crm-sig@ics.forth.gr) Subject: Re: [Crm-sig] Domain and range of P90 One of the "gaps" which puzzles me most is the example you give of encoding the string value of an Appellation. I understand the recommended practice is to attach the string value of a person's name using P3_has_note, or actually, using a custom subproperty of P3_has_note. The semantics of P3_has_note itself are weak; a note is simply an "informal description" of something, so if I have a particular name (an RDF resource) which P3_has_note the literal string "Conal Tuohy", then I should really define subproperties so as to be able to distinguish that string value from a note which really is nothing more than an "informal description" of that name e.g. "A very uncommon name of Irish origin". What puzzles me most about this "gap" in the RDFS specification is that the distinction between a note ABOUT a name, and the actual textual representation OF a name is somehow considered out of scope of the CRM in RDFS. It's puzzling, because the string value of a name is something which really must be encoded in a standard fashion, to achieve interoperability (as an aside, my personal view is that the string literal "Conal Tuohy" could be attached to an Appellation using the rdf:value or rdfs:label predicate defined in the RDFS spec). But the important thing is that the RDFS schema should stipulate how to attach this literal data rather than leave it as an open question. In general these are the kinds of issues which puzzle many people who approach the CRM from a position of having already worked with other RDF ontologies in the cultural heritage space, and find themselves wondering how they are supposed to make these details CRM work in RDF in an interoperable way, without having to pick and choose from a variety of techniques for "finessing" the gaps. These kinds of gaps are serious barriers to interoperability in the Linked Open Data cloud, and they need to be addressed by agreeing on some encoding procedures that can be used consistently by different projects on the web. It would be helpful to CRM adopters in the Linked Data community if these gaps could be filled in a manner which is clear and simple and interoperable. I am not in favour of just offering a menu of possible approaches, especially where individual projects would have to make local customisations to their schema. If there is some particular value in multiple approaches, then they could be published as different "profiles" that encoders could simply adopt, as a whole. I think the recent effort by Richard Light (and other contributors) to collate guidelines on RDF encoding is a great initiative! <https://docs.google.com/document/d/1zCGZ4iBzekcEYo4Dy0hI8CrZ7dTkMD2rJaxavtEOET0/edit> It deserves more input and I hope it will continue to be discussed on the list. I also think the Linked Art project http://linked.art/ with its "profile" of the CRM is another really good way forward. Regards Conal
