CIDOC CRM v7.1.3 implemented in RDFSThis is the implementation approved by the 58th CRM-SIG meeting (March 2024)as the current RDFS version for the CIDOC CRM namespace.Note that this is NOT a definition of the CIDOC CRM, but a CIDOC CRM compatible implementationof an RDF Schema derived from the authoritative release of the CIDOC CRM v7.1.3 on February 2024https://cidoc-crm.org/Version/version-7.1.3 by an automated algorithm. It is intended for anassumed majority of uses. Depending on the application, users may create adequate extensions compatible with the logical definitions of the CIDOC CRM.Created by FORTH-ICS February 13, 2024CC BY 4.0 https://creativecommons.org/licenses/by/4.0/legalcodeEncoding Rules:1. The RDF spelling rules do not allow blanks. Hence we have replaced them by underscores. For instance E63_Beginning_of_Existence or P2i_is_type_of .2. RDF does not allow to instantiate properties beginning from a range value. Therefore, each CRM property is represented as two RDFS properties. For instance P2 has type (is type of) is represented as: P2_has_type for the domain to range direction and P2i_is_type_of for the range to domain direction.3. The primitive values E60 Number , E61 Time Primitive , E62 String , E94 Space Primitive and E95 Spacetime Primitive referred in the Model for formal completeness are interpreted as rdfs:literal.4. RDF does not support properties of properties, therefore, users may create their own subProperties for CRM properties that have a type property such as P3 has note : Instead of P3 has note (P3-1 has type : parts description) declare 5. Scope notes are represented as elements.6. In addition this encoding contains labels in languages different from English, which are taken from translations of previous versions of the CIDOC CRM. 7. Any other differences in labels, scope notes and semantic relationships of this encoding to the authoritative definition of the CIDOC CRM v7.1.3 (February 2024) are not intended transfer errors. FORTH appreciates your feed-back on such errors.8. CRM time extension 1.0 Encoded in RDFS (http://old.cidoc-crm.org/docs/How_to%20implement%20CRM_Time_in%20RDF.pdf) Since the Time Primitive of the CRM can not directly be implemented in RDF Triple Stores, we define in this extension of 4 properties replacing P81 and P82 adequately using xsd:dateTime. Property P81 is dedicated for modeling the Time-Span s maximum known temporal extent i.e. ongoing_throughout. Property P82 is for modeling the minimum outer bounds of events i.e. at_some_time_within. P81 has its time interval redefined by P81a and P81b. Similarly, we redefine P82 by P82a and P82b.## RDFS Generation Policies### SourcesPolicies followed for the RDFS implementation of CIDOC v.7.1.3 were created w.r.t.:- Implementing the CIDOC Conceptual Reference Model in RDF (http://www.cidoc-crm.org/Resources/implementing-the-cidoc-conceptual-reference-model-in-rdf)- How to implement CRM Time in RDF (http://old.cidoc-crm.org/docs/How_to%20implement%20CRM_Time_in%20RDF.pdf)- CIDOC-CRM SIG feedback and the general guidelines: - Each property is declared twice, forward and backwards, unless no inverse name is defined in parentheses, or domain or range is interpreted as literal - All Primitive Values become rdfs:Literal - All IsA declarations from/to and between Primitive values are ignored### Policies#### **A. CIDOC Classes implementation in RDFS**The CIDOC-CRM model defines classes, that in Triple Stores are typically implemented as primitive values. These classes are all subclasses of `E59 Primitive Value` and in RDFS they are interpreted as Literal. There are some classes in the CIDOC-CRM model that are both subclasses of `E59 Primitive Value` and E41 Appellation. So far we have followed the decision by CRM-SIG in Issue 394: Solution for Dualism of E41 Appellation and rdfs:label in 28-11-2018 wrt the question whether these classes should be implemented as rdfs:Class or still be interpreted as rdfs:Literal.In this version we have followed the following policy regarding CIDOC Classes implementation in RDFS:> A1. CIDOC Classes that are subClasses of `E59 Primitive Value` are interpreted as rdfs:Literal regardless of whether they are also subClasses of another Class.As a result, the following CIDOC classes were not defined in RDFS:- `E59 Primitive Value`- `E60 Number`- `E61 Time Primitive`- `E62 String`- `E94 Space Primitive`- `E95 Spacetime Primitive`Additionally, the following isA relationships were not defined in RDFS:- `E59 Primitive Value` `subClassOf` `E1 CRM Entity`- `E60 Number` `subClassOf` `E59 Primitive Value`- `E61 Time Primitive` `subClassOf` `E41 Appellation`- `E61 Time Primitive` `subClassOf` `E59 Primitive Value`- `E62 String` `subClassOf` `E59 Primitive Value`- `E94 Space Primitive` `subClassOf` `E41 Appellation`- `E94 Space Primitive` `subClassOf` `E59 Primitive Value`- `E95 Spacetime Primitive` `subClassOf` `E41 Appellation`- `E95 Spacetime Primitive` `subClassOf` `E59 Primitive Value`#### **B. CIDOC Properties implementation in RDFS**The decisions in policy A affect the implementation of CIDOC Properties in RDFS. A property cannot define an rdfs:Literal as rdfs:domain, and the backwards direction of a property with an rdfs:Literal as rdfs:range cannot be created for the exact same reason.Further, the property ranges defined as rdfs:Literal in this implementation do not inherit the properties of the superclasses defined in the CIDOC Model. A separate guideline will describe how to instantiate such properties if at all needed.Another aspect considered for the implementation of properties in RDFS is whether a distinct inverse property definition should be provided.In this version we followed the following policies regarding CIDOC Properties implementation in RDFS:> B1. CIDOC Property backwards/inverse direction is **not** defined, whenever no inverse name for the property has been specified in parentheses in the official CIDOC documentation and property domain is not equal with property range.As a result, the following properties do not define an inverse direction.- `E1 CRM Entity. P3 has note: E62 String`- `E19 Physical Object. P57 has number of parts: E60 Number`- `E52 Time-Span. P79 beginning is qualified by: E62 String`- `E52 Time-Span. P80 end is qualified by: E62 String`- `E52 Time-Span. P81 ongoing throughout: E61 Time Primitive`- `E52 Time-Span. P82 at some time within: E61 Time Primitive`- `E54 Dimension. P90 has value: E60 Number`- `E53 Place. P171 at some place within: E94 Space Primitive`- `E53 Place. P172 contains: E94 Space Primitive`- `E90 Symbolic Object. P190 has symbolic content: E62 String`> B2. CIDOC Property forward direction is **not** defined whenever property domain is interpreted as rdfs:Literal (A.1). Similarly, CIDOC Property backwards/inverse direction is **not** defined, whenever property range is interpreted as rdfs:Literal (A.1). Further, the instances of classes interpreted as rdfs:Literal, cannot express in RDFs their **inherited** properties that could be expressed according to CIDOC Model.As a result,a) The following **direct forward direction** CIDOC Properties **cannot** be expressed and are **not defined** in RDFS:- `E95 Spacetime Primitive. P169 defines spacetime volume (spacetime volume is defined by): E92 Spacetime Volume`- `E61 Time Primitive. P170 defines time (time is defined by): E52 Time-Span`b) The following **direct backwards direction** CIDOC Properties **cannot** be expressed and are **not defined** in RDFS:- `E94 Space Primitive. P168i defines place (place is defined by): E53 Place`> B3. Whenever no backwards/inverse property name is specified and property domain matches with property range, then the forward/direct property direction should be used for **both** directions and **no backwards/inverse property** needs to be defined.As a result, we did not implement a separate backwards/inverse direction for the following CIDOC Properties:- `E53 Place. P121 overlaps with: E53 Place`- `E53 Place. P122 borders with: E53 Place`- `E92 Spacetime Volume. P132 spatiotemporally overlaps with: E92 Spacetime Volume`- `E92 Spacetime Volume. P133 is spatiotemporally separated from: E92 Spacetime Volume`Additionally, all aforementioned redundant backwards/inverse CIDOC Property direction references, are replaced by the respective direct/forward CIDOC Property direction.- The hierarchical link of `P10i` subPropertyOf `P132i` was replaced with `P10i` subPropertyOf `P132`.#### **C. Labels and appellations**CIDOC-CRM version 7.1.3 defines the below subpropertyOf relations:- `P168 place is defined by` `subPropertyOf` `P1 is identified by`- `P169i spacetime volume is defined by` `subPropertyOf` `P1 is identified by`- `P170i time is defined by` `subPropertyOf` `P1 is identified by`The range of P168, P169i and P170i is `E94 Space Primitive`, `E95 Spacetime Primitive` and `E61 Time Primitive` respectively, which are all subclasses of `E41 Appellation` and interpreted as `rdfs:Literal` in RDFS, i.e. these three properties are datatype properties. However, the P1 property has range E41 Appellation, i.e. this property is an object property. Since OWL 2 distinguishes between object subproperties (https://www.w3.org/TR/2012/REC-owl2-syntax-20121211/#Object_Subproperties), data subproperties (https://www.w3.org/TR/2012/REC-owl2-syntax-20121211/#Data_Subproperties) and annotation subproperties (https://www.w3.org/TR/2012/REC-owl2-syntax-20121211/#Annotation_Subproperties), and also in OWL-DL the subject and object of a subproperty statement must be either both datatype properties or both object properties (see here (https://www.w3.org/TR/owl-ref/#subPropertyOf-def)), we do not include these three subPropertyOf relations in the provided RDFS implementation to avoid inconsistencies when reasoning with OWL 2 and OWL DL. Instead, we provide them in a separate ‘supplementary’ RDFS file which one can use if such inconsistencies are not expected.In addition, since in the current practice, the property `rdfs:label` is widely used to denote appellations (see CRM-SIG Issue 394 (http://cidoc-crm.org/Issue/ID-394-solution-for-dualism-of-e41-appellation-and-rdfslabel)), the following `subPropertyOf` relation was also included in the supplementary RDFS file:- `rdfs:label` subPropertyOf `P1 is identified by`Note that according to the RDF Schema 1.1 specification, the domain (or range) of a property does not necessarily need to be subClassOf or equal to the domain (or range) of its superproperties. By including this subproperty relation, one can either directly use `rdfs:label` for providing a non-URI identifier/appellation for an instance of `E1 CRM Entity`, or use `P1 is identified by` for associating an additional URI-identifier with an instance of `E1 CRM Entity`, or use `P1 is identified by` and create an intermediate node (i.e. a URI-identifier for instance of `E41_Appellation`) for providing more detailed information about this appellation.#### **D. Implementing Value Intervals**The following are property pairs needed to simulate the interval-valued primitive values foreseen by the CRM:> D1. addition of two new properties, defined as subproperties of `E52 Time-Span. P81 ongoing throughout: E61 Time Primitive`, for the maximum known temporal extent boundaries specification of `E61 Time Primitive`.As a result, we have created the following property definitions:- `E52 Time-Span. P81a end of the begin: rdfs:Literal` (subPropertyOf `E52 Time-Span. P81 ongoing throughout: E61 Time Primitive`)- `E52 Time-Span. P81b begin of the end: rdfs:Literal` (subPropertyOf `E52 Time-Span. P81 ongoing throughout: E61 Time Primitive`)> D2. addition of two new properties, defined as subproperties of `E52 Time-Span. P82 at some time within: E61 Time Primitive`, for the minimum outer bounds specification of `E61 Time Primitive`.Consequently, we have created the following property definitions:- `E52 Time-Span. P82a begin of the begin: rdfs:Literal` (subPropertyOf `E52 Time-Span. P82 at some time within: E61 Time Primitive`)- `E52 Time-Span. P82b end of the end: rdfs:Literal` (subPropertyOf `E52 Time-Span. P82 at some time within: E61 Time Primitive`)> D3. addition of two new properties, defined as subproperties of `E54 Dimension. P90 has value: E60 Number`, for the upper and lower boundaries specification of `E60 Number`.Consequently, we have created the following property definitions:- `E54 Dimension. P90a has lower value limit: rdfs:Literal` (subPropertyOf `E54 Dimension. P90 has value: E60 Number`)- `E54 Dimension. P90b has upper value limit: rdfs:Literal` (subPropertyOf `E54 Dimension. P90 has value: E60 Number`)#### **E. Multiple ISA custom declaration Classes**The following are declarations of frequently used multiple instantiations as classes with respective multiple IsA (so far only one):> E1. addition of a new class, defined as subClassOf `E41 Appellation` and `E33 Linguistic Object`, for all Appellations being regardedspecific to or characteristic for a language group and being described indirectly via a URI.As a result, we have created the following class definition:- `E33_E41_Linguistic_Appellation` subClass of `E33_Linguistic_Object` and `E41_Appellation`#### **F. Translations and Scope notes**> F1. **Translations** Each RDFS Class or Property definition is accompanied by a set of translations expressed as rdfs:labels separated by xml:lang tags. The translation label used for each language is **the most recent** still **valid** translation. Still valid translation may be interpreted in the following ways:- The English label of the `CurrentVersion` that the current RDFS file is referring to is *almost equal* (accepting only differences regarding multiple spaces) to the English label of the `TranslationVersion` that the translated label was created for. For example, in order to accept a translation for `E22 Human-Made Object` in the CurrentVersion (7.1.3) we should have a translation for E22 that was created based on a CIDOC version that used the same name for E22. The class name of E22 was changed from `E22 Man-Made Object` to `E22 Human-Made Object` in version 6.2.7. So the only **valid** translations would be these that were created based on version 6.2.7 or later. Currently no such translation has been created, so `E22 Human-Made Object` in CurrentVersion (7.1.3) does not define any translation in the RDFS file.- Another option is to qualify translations as **valid** based on the scope note comparison of `CurrentVersion` and `TranslationVersion`. Since scope notes include formatting information, the comparison should ignore formatting changes.Currently in this version we follow the option to qualify translations as valid based on the comparison of the respective labels in the corresponding CIDOC versions.> F2. **Scope notes** are defined as rdfs:comment and include only the text of the official CIDOC-CRM version in English language. Since scope notes are not just simple texts but include formatting data, a simple removal of the formatting data does not always produce a readable format. Therefore we followed the below simple conventions for the transformation of CIDOC-CRM scope note text into a readable rdfs:comment:- Each Paragraph defines a new line- Each element in an unordered list defines a new line- Each element in an ordered list defines a new line prefixed with ` {order}. `- Each superscript text is separated from its base with ` - `- Each subscript text is separated from its base with ` _ ` (none found)> F3. **Scope notes of Inverse Properties**. Scope notes for the inverse/backwards direction of properties are not defined as they are covered by the definition of the direct/forward direction definition. Whenever the direct/forward property direction of a property `Pxxx` is not defined due to policy **B1**, then its scope note is used as scope note for the inverse/backwards property `Pxxxi`, and labeled as `Scope note for Pxxx :`.As a result, the direct/forward property definition was used for the rdfs:comment definition of- `E92 Spacetime Volume. P169i spacetime volume is defined by: rdfs:Literal`- `E52 Time-Span. P170i time is defined by: rdfs:Literal`