[Crm-sig] ISSUE Recording an E41 in RDF
Richard Light
richard at light.demon.co.uk
Tue Jan 16 16:58:18 EET 2018
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 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 |
>>> --------------------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> Crm-sig mailing list
>>> Crm-sig at ics.forth.gr
>>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>>
>> --
>> *Richard Light*
>>
>>
>> _______________________________________________
>> Crm-sig mailing list
>> Crm-sig at 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: maria at ics.forth.gr
> URL: http://www.ics.forth.gr/isl
> ORCID: http://orcid.org/0000-0002-4623-9186
>
>
> _______________________________________________
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
*Richard Light*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20180116/93c9d4d8/attachment-0001.html>
More information about the Crm-sig
mailing list