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*

Reply via email to