On 16/01/2018 13:07, Maria Theodoridou wrote: > > Dear all, > > As being very much involved with mappings to the RDF implementation of > CRM I would benefit a lot from /clear guidance on the whole subject of > "implementing an RDF instantiation of the CRM"/ as Richard states. > I have started an "issues with RDF" document, but on reflection it may be more constructive to make it into a first attempt at the guidance I am asking for. I'll spend this afternoon pulling together material which I can easily find (e.g. the introductory comments in the RDF Schema document), and see what questions that exercise answers.
> In CAA2016 we presented some Methodological tips for mappings to CIDOC > CRM and among others we (a.k.a. Martin) claim the following: > > 4.2 Common database fields: Appellations > The RDF class rdfs:label and CRM class E41 Appellation are > alternative implementations for the same concept in RDF, a > human-readable name for the subject. So, for simplicity, when > mapping contemporary names into RDF, we suggest the use of > rdfs:label tagged with a language attribute. The use of the > E41 Appellation class is required only if there is need to > assign some additional properties to the Appellation such as > properties of use or attribution. > > Instances of E41 Appellation “/are cultural constructs; as > such, they have a context, a history, and a use in time and > space by some group of users./” and thus E41 Appellation is > appropriate for historical names. > I think the principle is valid, but rdfs:label is a property, not a class, so I think that "rdfs:label" should be replaced by "rdf:literal" (or possibly "rdf:plainLiteral"[1]) in the above text. The point I assume that Martin is making is that the value of a /P1_is_identified_by /property can be finessed into a string if you have nothing more interesting to say about that value. > Since then, I got several times questions related to this issue and > apparently there are a few ways to deal with it. One recent e-mail > mentioned "we were advised to use E55_Type > P1_is_indentified_by > > E41_Appellation > P3_has_note > E62_String" and I was asked if this is > the way to go. This is the sort of endless class-property-class-... chain which leads me to question whether the CRM is an efficient way of solving an RDF implementation. :-) Using Martin's short-cut above, you could replace the last three elements of this expression by a string. (Unless, for example, you also want to say for example that the Appellation has an alternative form, in which case the full structure is required ... and useful.) (E55_Type is another question: I would like to tease out how we implement in RDF its stated role of representing "concepts denoted by terms from thesauri and controlled vocabularies".) > If I am not wrong, the different ways to approach this was the main > (probably the only) incompatibility between the Helculaneum data and > WissKI data in Tiblisi. George knows the details. Best wishes, Richard [1] https://www.w3.org/TR/rdf-plain-literal/ > > Looking forward to official guidelines, > > Best > Maria > > > On 16/1/2018 1:12 πμ, Richard Light wrote: >> >> On 15/01/2018 19:52, Martin Doerr wrote: >>> Right. We have often discussed it, but I am not sure if we have >>> written a guideline, and it is not in the right place, or if we have >>> only exchanged e-mails about it. >>> I put is as an issue, in case its new. The point is that we cannot >>> make rdf label a subproperty of p1. >> More generally, I would argue that there should be clear guidance on >> the whole subject of "implementing an RDF instantiation of the CRM". >> I was very pleased with the guidance for recording dates which we >> recently worked on, and assumed that was just an outlier which had >> been missed up to now. If we are seriously expecting implementors to >> produce RDF solutions which embody the CRM, we must provide them with >> comprehensive and specific guidance - maybe a range of implementation >> options. In my understanding of it, the problem areas are mostly at >> the "sharp end" where the actual data comes in. >> >> Best wishes, >> >> Richard >> >>> best, >>> >>> martin >>> >>> On 1/15/2018 6:33 PM, Richard Light wrote: >>>> >>>> Hi, >>>> >>>> It's perhaps telling that I even have to ask this question at this >>>> stage in the game. >>>> >>>> I'm not sure how to encode a person's name in RDF in a >>>> CRM-compliant manner. It's an E41 Appellation, and is linked to >>>> the person by a P1_is_identified_by property, I'm assuming. So >>>> far, so good. >>>> >>>> However, it looks as though I have the choice of not stating that >>>> it is an E41, or of connecting the E41 to its string value via a >>>> property which is nowhere defined in the CRM: >>>> >>>> freeukgen:b65432#born a crm:E21_Person; >>>> crm:P1_is_identified_by "Light, Thomas Edward" . >>>> >>>> or: >>>> >>>> freeukgen:b65432#born a crm:E21_Person; >>>> crm:P1_is_identified_by [ >>>> a crm:E41_Appellation; >>>> {has-string-value} "Light, Thomas Edward" ] . >>>> >>>> The CRM definition gives strings as examples of E41, which implies >>>> that the first form is acceptable. However, my instinct says that >>>> it is wrong to finesse the fact that it is an E41 in this way. If >>>> the E41 /is /to be expressed, as in my second form, I would welcome >>>> advice as to what the value of "{has-string-value}" should be. >>>> >>>> Whichever approach is correct, I am struck by the absence of a >>>> primer which says, in straightforward terms, "this is how you >>>> encode CRM concepts in RDF". If it exists and I have simply missed >>>> it, please point me in its direction and I will spread the word ... >>>> >>>> Best wishes, >>>> >>>> Richard >>>> -- >>>> *Richard Light* >>>> >>>> >>>> _______________________________________________ >>>> Crm-sig mailing list >>>> Crm-sig@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: mar...@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 | >>> -------------------------------------------------------------- >>> >>> >>> _______________________________________________ >>> Crm-sig mailing list >>> Crm-sig@ics.forth.gr >>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >> >> -- >> *Richard Light* >> >> >> _______________________________________________ >> Crm-sig mailing list >> Crm-sig@ics.forth.gr >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig > > -- > > Maria Theodoridou > R & D Engineer > > Information Systems Laboratory & Centre for Cultural Informatics > Institute of Computer Science > Foundation for Research and Technology - Hellas (FORTH) > Science and Technology Park of Crete > Vassilika Vouton, P.O.Box 1385, GR-711 10 Heraklion, Crete, Greece > > Tel.: +30-2810-391731 Fax: +30-2810-391638 E-mail: ma...@ics.forth.gr > URL: http://www.ics.forth.gr/isl > ORCID: http://orcid.org/0000-0002-4623-9186 > > > _______________________________________________ > Crm-sig mailing list > Crm-sig@ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig -- *Richard Light*
