Variants of this issue do come up often with people really trying to implement
and indeed the lack of a consolidated implementation guide, to my knowledge,
leads to incompatible implementations and this undermines the integration and
interoperability we want to support. So I too think it should be raised as an
issue.
------ Original message------From: Maria TheodoridouDate: Tue, Jan 16, 2018
14:14To: [email protected];Cc: Subject:Re: [Crm-sig] ISSUE Recording an E41
in RDF
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. 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.
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.
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.
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
[email protected]http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
-------------------------------------------------------------- Dr. Martin Doerr
| Vox:+30(2810)391625 | Research Director |
Fax:+30(2810)391638 | | Email:
[email protected] |
| 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
[email protected]http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
Richard Light
_______________________________________________Crm-sig mailing
[email protected]http://lists.ics.forth.gr/mailman/listinfo/crm-sig
-- Maria Theodoridou R & D Engineer
Information Systems Laboratory & Centre for Cultural InformaticsInstitute of
Computer ScienceFoundation for Research and Technology - Hellas (FORTH)Science
and Technology Park of CreteVassilika Vouton, P.O.Box 1385, GR-711 10
Heraklion, Crete, GreeceTel.: +30-2810-391731 Fax: +30-2810-391638 E-mail:
[email protected]: http://www.ics.forth.gr/islORCID:
http://orcid.org/0000-0002-4623-9186
