[Crm-sig] Domain and range of P90

Martin Doerr martin at ics.forth.gr
Thu Mar 1 17:24:13 EET 2018


Dear Doug,

On 3/1/2018 3:14 PM, Douglas Tudhope wrote:
> 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.
That is exactly my proposal. CRM-SIG normally works reactively: When a 
good community practice emerges, this is taken up.

Best,

Martin
>
> 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-bounces at ics.forth.gr] on behalf of Conal 
> Tuohy [conal.tuohy at gmail.com]
> *Sent:* 01 March 2018 03:02
> *To:* George Bruseker
> *Cc:* crm-sig (Crm-sig at 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 
> <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
>
>
>
> _______________________________________________
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig


-- 
--------------------------------------------------------------
  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...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20180301/99b572e6/attachment-0001.html>


More information about the Crm-sig mailing list