######
# # ## ##### ## ##### # # ####
# # # # # # # # # # # #
# # # # # # # ##### # # ####
# # ###### # ###### # # # # #
# # # # # # # # # # # # #
###### # # # # # ##### #### ####
# Plugin version 1.3-SNAPSHOT - https://github.com/dbpedia/databus-maven-plugin
@prefix databus: .
@prefix dataid-mt: .
@prefix dct: .
@prefix dataid: .
@prefix rdf: .
@prefix dataid-cv: .
@prefix xsd: .
@prefix rdfs: .
@prefix dcat: .
@prefix prov: .
@prefix dataid-debug: .
dataid-mt:UNKNOWN a dataid-mt:MediaType ;
dataid:mimetype "UNKNOWN" .
a dataid:DataId ;
rdfs:comment "Metadata created by the DBpedia Databus Maven Plugin: https://github.com/dbpedia/databus-maven-plugin (Version 1.3-SNAPSHOT)\nThe DataID ontology is a metadata omnibus, which can be extended to be interoperable with all metadata formats\nNote that the metadata (the dataid.ttl file) is always CC-0, the files are licensed individually\nMetadata created by https://yum-yab.github.io/webid.ttl#onto" ;
rdfs:label "DataID metadata for cidoc-crm.org/cidoc-crm"@en ;
dataid:associatedAgent ;
dct:conformsTo "http://dataid.dbpedia.org/ns/core#" ;
dct:hasVersion "1.3-SNAPSHOT" ;
dct:issued "2024-01-20T22:44:06Z"^^xsd:dateTime ;
dct:license ;
dct:publisher ;
dct:title "DataID metadata for cidoc-crm.org/cidoc-crm"@en .
dataid-cv:tag rdfs:subPropertyOf dataid:contentVariant .
a dataid:SingleFile ;
dataid:associatedAgent ;
dataid:compression "None" ;
dataid:contentVariant "shaclReport" , "lodeMetadata" ;
dataid:file ;
dataid:formatExtension "ttl" ;
dataid:isDistributionOf ;
dataid:maintainer ;
dataid:preview "@prefix dc: .\n@prefix owl: .\n@prefix sh: .\n@prefix xsd: .\n\n[] a sh:ValidationReport ;\n sh:conforms false ;\n sh:result [ a sh:ValidationResult ;\n sh:focusNode ;\n sh:resultMessage \"dc:publisher of the ontology is missing and will not be displayed\"@en ;" ;
dataid:sha256sum "f8179872cd146fe4ff9c3957e78bb3be9847646049bee9b6d930ccd1b450ec44" ;
dataid:signature "KefXHBAw4rYpucRH6osbIf+8K0PUdq23rboCyK4l7iK3AUO8d15/VXvpRnO70Xx32HfUNFdpAFnija52f1x6Mhr2YGybp4w3qePfCsmqTXWyvI7gW7CJ0vv61tx6NFghHHJ0ZvSjYQNEntgNaMqRbOYWVQW/veGSrlAEIE9TIoxYPIyMT5Y4/AxxQj8/IvpjaXPqR2iz+x6LvX6mr6tMGEN4oiuqfXb6bVFpd2MjfdxnRCx1rQI0/7JTJ9CI5iX9+7KcRUVz6HabYHnZxEEFD61bzU/CuAf0h94WoXhPCLY7f1ZHD8w086icdZaYSASLJHWj+c9OJU65jF51hD5vHw==" ;
dataid-cv:type "shaclReport" ;
dataid-cv:validates "lodeMetadata" ;
dct:conformsTo "http://dataid.dbpedia.org/ns/core#" ;
dct:hasVersion "2024.01.20-224122" ;
dct:issued "2024-01-20T22:44:06Z"^^xsd:dateTime ;
dct:license ;
dct:modified "2024-01-20T22:41:30Z"^^xsd:dateTime ;
dct:publisher ;
dcat:byteSize "5571"^^xsd:decimal ;
dcat:downloadURL ;
dcat:mediaType dataid-mt:ApplicationNTriples .
a dataid:Version .
a dataid:SingleFile ;
dataid:associatedAgent ;
dataid:compression "None" ;
dataid:contentVariant "goodLicense" , "shaclReport" ;
dataid:file ;
dataid:formatExtension "ttl" ;
dataid:isDistributionOf ;
dataid:maintainer ;
dataid:preview "@prefix dct: .\n@prefix sh: .\n@prefix xsd: .\n\n[] a sh:ValidationReport ;\n sh:conforms false ;\n sh:result [ a sh:ValidationResult ;\n sh:focusNode ;\n sh:resultMessage \"No dct:license statement found\"@en ;\n sh:resultPath dct:license ;" ;
dataid:sha256sum "39f3f41f90703342c5dbad7c2ccb1cde489c1e8e58d06534c72fad6f74dfcf3c" ;
dataid:signature "Wy61p1HjM77A4l/+ZUxcrWztMkSOPRW3mWhWv3sCJ2ZMtwgFiKnw/u/7RN4l2AkcjQd6/jw3eac060ADXUaL3l2QBhlvXxjPsjJKvnxq3iAfiMiBazNdeCgp62GkPbpIIZeCkcgFb28AURjxo3tlMqF2Zg095FL1RaaX9s8gLL1HbIUBhKd5YnBD59WjIEsC3gQTd2aJNcDYHL2EACHaTiHaCe2/7e9HCWIAp8SxIL3Tx12UNe6/t9NfP0lGRrSoOsTbE6bb4dIwdCb3sXR4MHsiX6ewnXzTNaMx1gxSY6rp21UVvnScZ0gQl4DKa55mYbK2FFN/xrR00+WYirkD4A==" ;
dataid-cv:type "shaclReport" ;
dataid-cv:validates "goodLicense" ;
dct:conformsTo "http://dataid.dbpedia.org/ns/core#" ;
dct:hasVersion "2024.01.20-224122" ;
dct:issued "2024-01-20T22:44:06Z"^^xsd:dateTime ;
dct:license ;
dct:modified "2024-01-20T22:41:30Z"^^xsd:dateTime ;
dct:publisher ;
dcat:byteSize "654"^^xsd:decimal ;
dcat:downloadURL ;
dcat:mediaType dataid-mt:ApplicationNTriples .
a dataid:SingleFile ;
dataid:associatedAgent ;
dataid:compression "None" ;
dataid:contentVariant "parsed" ;
dataid:file ;
dataid:formatExtension "nt" ;
dataid:isDistributionOf ;
dataid:maintainer ;
dataid:preview " .\n \"RDFs Implementation (September 2022) of CIDOC-CRM 7.1.2\"@en .\n \"CIDOC CRM v7.1.2 implemented in RDFS\\n\\nThis is the implementation incorporating to the decisions of the 53rd CRM-SIG meeting (May 2022)\\nand has been approved for official use.\\nNote that this is NOT a definition of the CIDOC CRM, but a CIDOC CRM compatible implementation\\nof an RDF Schema derived from the authoritative release of the CIDOC CRM v7.1.2 on June 2022\\nhttps://cidoc-crm.org/Version/version-7.1.2 by an automated algorithm. It is intended for an\\nassumed majority of uses. Depending on the application, users may create adequate extensions \\ncompatible with the logical definitions of the CIDOC CRM.\\n\\nCreated by FORTH-ICS September 14, 2022\\nCC BY 4.0 https://creativecommons.org/licenses/by/4.0/legalcode\\n\\nUpdated on: Friday January 19, 2024\\n==========================\\n- Added French labels from translation of version 7.1.2\\n\\nEncoding Rules:\\n1. The RDF spelling rules do not allow blanks. Hence we have replaced them by underscores.\\n For instance \\\"E63_Beginning_of_Existence\\\" or \\\"P2i_is_type_of\\\".\\n\\n2. RDF does not allow to instantiate properties beginning from a range value.\\n Therefore, each CRM property is represented as two RDFS properties.\\n For instance \\\"P2 has type (is type of)\\\" is represented as:\\n \\\"P2_has_type\\\" for the domain to range direction and \\\"P2i_is_type_of\\\" for the range to domain direction.\\n\\n3. The primitive values \\\"E60 Number\\\", \\\"E61 Time Primitive\\\", \\\"E62 String\\\", \\\"E94 Space Primitive\\\" and \\n \\\"E95 Spacetime Primitive\\\" referred in the Model for formal completeness are interpreted as rdfs:literal.\\n\\n4. RDF does not support properties of properties, therefore, users may create their own\\n subProperties for CRM properties that have a type property such as \\\"P3 has note\\\":\\n Instead of P3 has note (P3-1 has type : parts description) declare\\n \\n \\n \\n \\n \\n\\n5. Scope notes are represented as elements.\\n\\n6. In addition this encoding contains labels in languages different from English, \\n which are taken from translations of previous versions of the CIDOC CRM. \\n\\n7. Any other differences in labels, scope notes and semantic relationships of this encoding \\n to the authoritative definition of the CIDOC CRM v7.1.2 (June 2022) are not intended transfer errors. \\n FORTH appreciates your feed-back on such errors.\\n\\n8. CRM time extension 1.0 Encoded in RDFS (http://old.cidoc-crm.org/docs/How_to%20implement%20CRM_Time_in%20RDF.pdf)\\n Since the Time Primitive of the CRM can not directly be implemented in RDF Triple Stores, we define in this extension\\n of 4 properties replacing P81 and P82 adequately using xsd:dateTime. \\n Property P81 is dedicated for modeling the Time-Span's maximum known temporal extent i.e. ongoing_throughout. \\n Property P82 is for modeling the minimum outer bounds of events i.e. at_some_time_within. \\n P81 has its time interval redefined by P81a and P81b. Similarly, we redefine P82 by P82a and P82b.\\n## RDFS Generation Policies\\n\\n### Sources\\n\\nPolicies followed for the RDFS implementation of CIDOC v.7.1.2 were created w.r.t.:\\n\\n- Implementing the CIDOC Conceptual Reference Model in RDF (http://www.cidoc-crm.org/Resources/implementing-the-cidoc-conceptual-reference-model-in-rdf)\\n- How to implement CRM Time in RDF (http://old.cidoc-crm.org/docs/How_to%20implement%20CRM_Time_in%20RDF.pdf)\\n- CIDOC-CRM SIG feedback and the general guidelines:\\n - Each property is declared twice, forward and backwards, unless no inverse name is defined in parentheses, or domain or range is interpreted as literal\\n - All Primitive Values become rdfs:Literal\\n - All IsA declarations from/to and between Primitive values are ignored\\n\\n### Policies\\n\\n#### **A. CIDOC Classes implementation in RDFS**\\n\\nThe 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.\\n\\nIn this version we have followed the following policy regarding CIDOC Classes implementation in RDFS:\\n\\n> 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.\\n\\nAs a result, the following CIDOC classes were not defined in RDFS:\\n\\n- `E59 Primitive Value`\\n- `E60 Number`\\n- `E61 Time Primitive`\\n- `E62 String`\\n- `E94 Space Primitive`\\n- `E95 Spacetime Primitive`\\n\\nAdditionally, the following isA relationships were not defined in RDFS:\\n\\n- `E59 Primitive Value` `subClassOf` `E1 CRM Entity`\\n- `E60 Number` `subClassOf` `E59 Primitive Value`\\n- `E61 Time Primitive` `subClassOf` `E41 Appellation`\\n- `E61 Time Primitive` `subClassOf` `E59 Primitive Value`\\n- `E62 String` `subClassOf` `E59 Primitive Value`\\n- `E94 Space Primitive` `subClassOf` `E41 Appellation`\\n- `E94 Space Primitive` `subClassOf` `E59 Primitive Value`\\n- `E95 Spacetime Primitive` `subClassOf` `E41 Appellation`\\n- `E95 Spacetime Primitive` `subClassOf` `E59 Primitive Value`\\n\\n#### **B. CIDOC Properties implementation in RDFS**\\n\\nThe 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.\\n\\nFurther, 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.\\n\\nAnother aspect considered for the implementation of properties in RDFS is whether a distinct inverse property definition should be provided.\\n\\nIn this version we followed the following policies regarding CIDOC Properties implementation in RDFS:\\n\\n> 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.\\n\\nAs a result, the following properties do not define an inverse direction.\\n\\n- `E1 CRM Entity. P3 has note: E62 String`\\n- `E19 Physical Object. P57 has number of parts: E60 Number`\\n- `E52 Time-Span. P79 beginning is qualified by: E62 String`\\n- `E52 Time-Span. P80 end is qualified by: E62 String`\\n- `E52 Time-Span. P81 ongoing throughout: E61 Time Primitive`\\n- `E52 Time-Span. P82 at some time within: E61 Time Primitive`\\n- `E54 Dimension. P90 has value: E60 Number`\\n- `E53 Place. P171 at some place within: E94 Space Primitive`\\n- `E53 Place. P172 contains: E94 Space Primitive`\\n- `E90 Symbolic Object. P190 has symbolic content: E62 String`\\n\\n> 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.\\n\\nAs a result,\\n\\na) The following **direct forward direction** CIDOC Properties **cannot** be expressed and are **not defined** in RDFS:\\n\\n- `E95 Spacetime Primitive. P169 defines spacetime volume (spacetime volume is defined by): E92 Spacetime Volume`\\n- `E61 Time Primitive. P170 defines time (time is defined by): E52 Time-Span`\\n\\nb) The following **direct backwards direction** CIDOC Properties **cannot** be expressed and are **not defined** in RDFS:\\n\\n- `E94 Space Primitive. P168i defines place (place is defined by): E53 Place`\\n\\n> 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.\\n\\nAs a result, we did not implement a separate backwards/inverse direction for the following CIDOC Properties:\\n\\n- `E53 Place. P121 overlaps with: E53 Place`\\n- `E53 Place. P122 borders with: E53 Place`\\n- `E92 Spacetime Volume. P132 spatiotemporally overlaps with: E92 Spacetime Volume`\\n- `E92 Spacetime Volume. P133 is spatiotemporally separated from: E92 Spacetime Volume`\\n\\nAdditionally, all aforementioned redundant backwards/inverse CIDOC Property direction references, are replaced by the respective direct/forward CIDOC Property direction.\\n\\n- The hierarchical link of `P10i` subPropertyOf `P132i` was replaced with `P10i` subPropertyOf `P132`.\\n\\n#### **C. Labels and appellations**\\n\\nCIDOC-CRM version 7.1.2 defines the below subpropertyOf relations:\\n\\n- `P168 place is defined by` `subPropertyOf` `P1 is identified by`\\n- `P169i spacetime volume is defined by` `subPropertyOf` `P1 is identified by`\\n- `P170i time is defined by` `subPropertyOf` `P1 is identified by`\\n\\nThe 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 \\u2018supplementary\\u2019 RDFS file which one can use if such inconsistencies are not expected.\\n\\nIn 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:\\n\\n- `rdfs:label` subPropertyOf `P1 is identified by`\\n\\nNote 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.\\n\\n#### **D. Implementing Value Intervals**\\n\\nThe following are property pairs needed to simulate the interval-valued primitive values foreseen by the CRM:\\n\\n> 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`.\\n\\nAs a result, we have created the following property definitions:\\n\\n- `E52 Time-Span. P81a end of the begin: rdfs:Literal` (subPropertyOf `E52 Time-Span. P81 ongoing throughout: E61 Time Primitive`)\\n- `E52 Time-Span. P81b begin of the end: rdfs:Literal` (subPropertyOf `E52 Time-Span. P81 ongoing throughout: E61 Time Primitive`)\\n\\n> 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`.\\n\\nConsequently, we have created the following property definitions:\\n\\n- `E52 Time-Span. P82a begin of the begin: rdfs:Literal` (subPropertyOf `E52 Time-Span. P82 at some time within: E61 Time Primitive`)\\n- `E52 Time-Span. P82b end of the end: rdfs:Literal` (subPropertyOf `E52 Time-Span. P82 at some time within: E61 Time Primitive`)\\n\\n> 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`.\\n\\nConsequently, we have created the following property definitions:\\n\\n- `E54 Dimension. P90a has lower value limit: rdfs:Literal` (subPropertyOf `E54 Dimension. P90 has value: E60 Number`)\\n- `E54 Dimension. P90b has upper value limit: rdfs:Literal` (subPropertyOf `E54 Dimension. P90 has value: E60 Number`)\\n\\n#### **E. Multiple ISA custom declaration Classes**\\n\\nThe following are declarations of frequently used multiple instantiations as classes with respective multiple IsA (so far only one):\\n\\n> E1. addition of a new class, defined as subClassOf `E41 Appellation` and `E33 Linguistic Object`, for all Appellations being regarded\\nspecific to or characteristic for a language group and being described indirectly via a URI.\\n\\nAs a result, we have created the following class definition:\\n\\n- `E33_E41_Linguistic_Appellation` subClass of `E33_Linguistic_Object` and `E41_Appellation`\\n\\n#### **F. Translations and Scope notes**\\n\\n> 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:\\n\\n- 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.2) 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.2) does not define any translation in the RDFS file.\\n\\n- 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.\\n\\nCurrently 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.\\n\\n> 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:\\n\\n- Each Paragraph defines a new line\\n- Each element in an unordered list defines a new line\\n- Each element in an ordered list defines a new line prefixed with `'{order}. '`\\n- Each superscript text is separated from its base with `'-'`\\n- Each subscript text is separated from its base with `'_'` (none found)\\n\\n> 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':`.\\n\\nAs a result, the direct/forward property definition was used for the rdfs:comment definition of\\n\\n- `E92 Spacetime Volume. P169i spacetime volume is defined by: rdfs:Literal`\\n- `E52 Time-Span. P170i time is defined by: rdfs:Literal`\\n\\n\\n\"@en .\n .\n \"CRM Entity\"@en .\n \"CRM Entit\\u00E4t\"@de .\n \"\\u039F\\u03BD\\u03C4\\u03CC\\u03C4\\u03B7\\u03C4\\u03B1 CIDOC CRM\"@el .\n \"Entit\\u00E9 CRM\"@fr .\n \"Entidade CRM\"@pt .\n \"CRM \\u0421\\u0443\\u0449\\u043D\\u043E\\u0441\\u0442\\u044C\"@ru ." ;
dataid:sha256sum "e3a80ed301379201b3babe0491652bdbcf7d8b3d4d4768a09799acd2de1c3a94" ;
dataid:signature "GA7B4gGOar8WHmeCsqtyweOfOGiaaP6TSxkru5nN7vJd8FBaVBnyAG5JxjHhYsqeMUmOOpxDI55xJs70+2fvO50iWIvwqMaL8NV3rBAFjbwqF8YNcRp4NBeNe8dDhucWfra4qEZPpIB27q/0REWPaRtO032XttsaKkyEtM/iMmvcXkrsl54gzZXQda1ALjZPHXnpXdNvfKDcf+KIjd51h/U0VZRN0+ANAno1o5C3w1Qd0jBZOEtS+qDJYCCzMMj7xgxlZ5PIixgVVvIOFmmFHplaXYHetkv9lhQOzfvbmtlI287CxFcppetURb5tttYVG9Lfy9OnJDlyrFUJR3ELHw==" ;
dataid-cv:type "parsed" ;
dct:conformsTo "http://dataid.dbpedia.org/ns/core#" ;
dct:hasVersion "2024.01.20-224122" ;
dct:issued "2024-01-20T22:44:06Z"^^xsd:dateTime ;
dct:license ;
dct:modified "2024-01-20T22:41:29Z"^^xsd:dateTime ;
dct:publisher ;
dcat:byteSize "791539"^^xsd:decimal ;
dcat:downloadURL ;
dcat:mediaType dataid-mt:ApplicationNTriples .
dataid-mt:ApplicationJson
a dataid-mt:MediaType ;
dataid:mimetype "application/json" .
a dataid:SingleFile ;
dataid:associatedAgent ;
dataid:compression "None" ;
dataid:contentVariant "orig" ;
dataid:file ;
dataid:formatExtension "owl" ;
dataid:isDistributionOf ;
dataid:maintainer ;
dataid:preview "\n\n \n \n RDFs Implementation (September 2022) of CIDOC-CRM 7.1.2\n CIDOC CRM v7.1.2 implemented in RDFS\n\nThis is the implementation incorporating to the decisions of the 53rd CRM-SIG meeting (May 2022)\nand has been approved for official use.\nNote that this is NOT a definition of the CIDOC CRM, but a CIDOC CRM compatible implementation" ;
dataid:sha256sum "677de8e429cfa45672b555001afc342e34d03e4fd9070a63bb967f5f936716ff" ;
dataid:signature "OsI9tSoRWX4iJzyBs5hi6X2tpBzvMfKseQgtOzxezW/bdIlPRPPj6zYc2o747d05arSIUg+k7sc7QMo8KeB4NOZQJEDnLJKPzqApTKekXzKgrC5xq10+pWA+L2Ds/nEZSXV+G0TfXeAl9TLHm3wckjS7OExZCK/MfLr8BxxSfcUrz8v+tjHTzEutDu9LhOLDa/OuzTjJndFI3rnutvcFcj9GcMZ6NbEFQA3eb9hOkuLfyGdjw4SW/jwXh8ScITlSM17vdKpAyC3ROIXQg4OnKgaKgGNNZjT8AY4ZDL3su/IBLDbQegxr0JKD8YIpBn2gERPrRG0n4Y+GXSb3EUMC2Q==" ;
dataid-cv:type "orig" ;
dct:conformsTo "http://dataid.dbpedia.org/ns/core#" ;
dct:hasVersion "2024.01.20-224122" ;
dct:issued "2024-01-20T22:44:06Z"^^xsd:dateTime ;
dct:license ;
dct:modified "2024-01-20T22:41:26Z"^^xsd:dateTime ;
dct:publisher ;
dcat:byteSize "428029"^^xsd:decimal ;
dcat:downloadURL ;
dcat:mediaType dataid-mt:ApplicationRDFXML .
dataid-mt:TextPlain a dataid-mt:MediaType ;
dataid:mimetype "text/plain" .
a dataid:SingleFile ;
dataid:associatedAgent ;
dataid:compression "None" ;
dataid:contentVariant "profile" ;
dataid:file ;
dataid:formatExtension "txt" ;
dataid:isDistributionOf ;
dataid:maintainer ;
dataid:preview "WARNING: An illegal reflective access operation has occurred\nWARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/local/src/webapp/archivo/archivo/helpingBinaries/profilechecker-1.1.0.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)\nWARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1\nWARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations\nWARNING: All illegal access operations will be denied in a future release\n[main] INFO org.semanticweb.owlapi.rdf.rdfxml.parser.TripleHandlers - Usage of rdf vocabulary: http://www.cidoc-crm.org/cidoc-crm/P100_was_death_of -> http://www.w3.org/1999/02/22-rdf-syntax-ns#type -> http://www.w3.org/1999/02/22-rdf-syntax-ns#Property\n[main] INFO org.semanticweb.owlapi.rdf.rdfxml.parser.TripleHandlers - Usage of rdf vocabulary: http://www.cidoc-crm.org/cidoc-crm/P100i_died_in -> http://www.w3.org/1999/02/22-rdf-syntax-ns#type -> http://www.w3.org/1999/02/22-rdf-syntax-ns#Property\n[main] INFO org.semanticweb.owlapi.rdf.rdfxml.parser.TripleHandlers - Usage of rdf vocabulary: http://www.cidoc-crm.org/cidoc-crm/P101_had_as_general_use -> http://www.w3.org/1999/02/22-rdf-syntax-ns#type -> http://www.w3.org/1999/02/22-rdf-syntax-ns#Property\n[main] INFO org.semanticweb.owlapi.rdf.rdfxml.parser.TripleHandlers - Usage of rdf vocabulary: http://www.cidoc-crm.org/cidoc-crm/P101i_was_use_of -> http://www.w3.org/1999/02/22-rdf-syntax-ns#type -> http://www.w3.org/1999/02/22-rdf-syntax-ns#Property\n[main] INFO org.semanticweb.owlapi.rdf.rdfxml.parser.TripleHandlers - Usage of rdf vocabulary: http://www.cidoc-crm.org/cidoc-crm/P102_has_title -> http://www.w3.org/1999/02/22-rdf-syntax-ns#type -> http://www.w3.org/1999/02/22-rdf-syntax-ns#Property" ;
dataid:sha256sum "fb3829ccec2fbf357b385358adc8a1f8184897a214e8b8a533d0a67cd94f1c59" ;
dataid:signature "WwfOEfxilM2//xlmeK17XfnE1LEJoiEt87hYary5ZPMosdwULacdZpv+6QRKoPAbU+nS82Cko7xOYfQjskO9De2X4QFfsZKmax5hsS8Ubeq9nSOIpi9WroxAmbB/4zBd/3GB3ucT7hCwwuLvbWinev7VxgKZBQfkxKezaC+PAafM65hQ8n0rLnCJKu8qB44daHB8/Apix8ZD0L1te+lOnGB1WunQrNrXvjZ6b7vUUfzh5IFYCm3mi/MLGYFD76Ru/PMWdUJhjE4TAMoVL6MuzbMW2ep2+PRsgXU3l/WETP7OOCwVKo30K1o9ZqVK4PsxcLCchcWHPaxu5qtjYTVISw==" ;
dataid-cv:type "profile" ;
dct:conformsTo "http://dataid.dbpedia.org/ns/core#" ;
dct:hasVersion "2024.01.20-224122" ;
dct:issued "2024-01-20T22:44:06Z"^^xsd:dateTime ;
dct:license ;
dct:modified "2024-01-20T22:41:43Z"^^xsd:dateTime ;
dct:publisher ;
dcat:byteSize "80641"^^xsd:decimal ;
dcat:downloadURL ;
dcat:mediaType dataid-mt:TextPlain .
a dataid:SingleFile ;
dataid:associatedAgent ;
dataid:compression "None" ;
dataid:contentVariant "parsed" , "sorted" ;
dataid:file ;
dataid:formatExtension "nt" ;
dataid:isDistributionOf ;
dataid:maintainer ;
dataid:preview " .\n \"CIDOC CRM v7.1.2 implemented in RDFS\\n\\nThis is the implementation incorporating to the decisions of the 53rd CRM-SIG meeting (May 2022)\\nand has been approved for official use.\\nNote that this is NOT a definition of the CIDOC CRM, but a CIDOC CRM compatible implementation\\nof an RDF Schema derived from the authoritative release of the CIDOC CRM v7.1.2 on June 2022\\nhttps://cidoc-crm.org/Version/version-7.1.2 by an automated algorithm. It is intended for an\\nassumed majority of uses. Depending on the application, users may create adequate extensions \\ncompatible with the logical definitions of the CIDOC CRM.\\n\\nCreated by FORTH-ICS September 14, 2022\\nCC BY 4.0 https://creativecommons.org/licenses/by/4.0/legalcode\\n\\nUpdated on: Friday January 19, 2024\\n==========================\\n- Added French labels from translation of version 7.1.2\\n\\nEncoding Rules:\\n1. The RDF spelling rules do not allow blanks. Hence we have replaced them by underscores.\\n For instance \\\"E63_Beginning_of_Existence\\\" or \\\"P2i_is_type_of\\\".\\n\\n2. RDF does not allow to instantiate properties beginning from a range value.\\n Therefore, each CRM property is represented as two RDFS properties.\\n For instance \\\"P2 has type (is type of)\\\" is represented as:\\n \\\"P2_has_type\\\" for the domain to range direction and \\\"P2i_is_type_of\\\" for the range to domain direction.\\n\\n3. The primitive values \\\"E60 Number\\\", \\\"E61 Time Primitive\\\", \\\"E62 String\\\", \\\"E94 Space Primitive\\\" and \\n \\\"E95 Spacetime Primitive\\\" referred in the Model for formal completeness are interpreted as rdfs:literal.\\n\\n4. RDF does not support properties of properties, therefore, users may create their own\\n subProperties for CRM properties that have a type property such as \\\"P3 has note\\\":\\n Instead of P3 has note (P3-1 has type : parts description) declare\\n \\n \\n \\n \\n \\n\\n5. Scope notes are represented as elements.\\n\\n6. In addition this encoding contains labels in languages different from English, \\n which are taken from translations of previous versions of the CIDOC CRM. \\n\\n7. Any other differences in labels, scope notes and semantic relationships of this encoding \\n to the authoritative definition of the CIDOC CRM v7.1.2 (June 2022) are not intended transfer errors. \\n FORTH appreciates your feed-back on such errors.\\n\\n8. CRM time extension 1.0 Encoded in RDFS (http://old.cidoc-crm.org/docs/How_to%20implement%20CRM_Time_in%20RDF.pdf)\\n Since the Time Primitive of the CRM can not directly be implemented in RDF Triple Stores, we define in this extension\\n of 4 properties replacing P81 and P82 adequately using xsd:dateTime. \\n Property P81 is dedicated for modeling the Time-Span's maximum known temporal extent i.e. ongoing_throughout. \\n Property P82 is for modeling the minimum outer bounds of events i.e. at_some_time_within. \\n P81 has its time interval redefined by P81a and P81b. Similarly, we redefine P82 by P82a and P82b.\\n## RDFS Generation Policies\\n\\n### Sources\\n\\nPolicies followed for the RDFS implementation of CIDOC v.7.1.2 were created w.r.t.:\\n\\n- Implementing the CIDOC Conceptual Reference Model in RDF (http://www.cidoc-crm.org/Resources/implementing-the-cidoc-conceptual-reference-model-in-rdf)\\n- How to implement CRM Time in RDF (http://old.cidoc-crm.org/docs/How_to%20implement%20CRM_Time_in%20RDF.pdf)\\n- CIDOC-CRM SIG feedback and the general guidelines:\\n - Each property is declared twice, forward and backwards, unless no inverse name is defined in parentheses, or domain or range is interpreted as literal\\n - All Primitive Values become rdfs:Literal\\n - All IsA declarations from/to and between Primitive values are ignored\\n\\n### Policies\\n\\n#### **A. CIDOC Classes implementation in RDFS**\\n\\nThe 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.\\n\\nIn this version we have followed the following policy regarding CIDOC Classes implementation in RDFS:\\n\\n> 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.\\n\\nAs a result, the following CIDOC classes were not defined in RDFS:\\n\\n- `E59 Primitive Value`\\n- `E60 Number`\\n- `E61 Time Primitive`\\n- `E62 String`\\n- `E94 Space Primitive`\\n- `E95 Spacetime Primitive`\\n\\nAdditionally, the following isA relationships were not defined in RDFS:\\n\\n- `E59 Primitive Value` `subClassOf` `E1 CRM Entity`\\n- `E60 Number` `subClassOf` `E59 Primitive Value`\\n- `E61 Time Primitive` `subClassOf` `E41 Appellation`\\n- `E61 Time Primitive` `subClassOf` `E59 Primitive Value`\\n- `E62 String` `subClassOf` `E59 Primitive Value`\\n- `E94 Space Primitive` `subClassOf` `E41 Appellation`\\n- `E94 Space Primitive` `subClassOf` `E59 Primitive Value`\\n- `E95 Spacetime Primitive` `subClassOf` `E41 Appellation`\\n- `E95 Spacetime Primitive` `subClassOf` `E59 Primitive Value`\\n\\n#### **B. CIDOC Properties implementation in RDFS**\\n\\nThe 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.\\n\\nFurther, 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.\\n\\nAnother aspect considered for the implementation of properties in RDFS is whether a distinct inverse property definition should be provided.\\n\\nIn this version we followed the following policies regarding CIDOC Properties implementation in RDFS:\\n\\n> 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.\\n\\nAs a result, the following properties do not define an inverse direction.\\n\\n- `E1 CRM Entity. P3 has note: E62 String`\\n- `E19 Physical Object. P57 has number of parts: E60 Number`\\n- `E52 Time-Span. P79 beginning is qualified by: E62 String`\\n- `E52 Time-Span. P80 end is qualified by: E62 String`\\n- `E52 Time-Span. P81 ongoing throughout: E61 Time Primitive`\\n- `E52 Time-Span. P82 at some time within: E61 Time Primitive`\\n- `E54 Dimension. P90 has value: E60 Number`\\n- `E53 Place. P171 at some place within: E94 Space Primitive`\\n- `E53 Place. P172 contains: E94 Space Primitive`\\n- `E90 Symbolic Object. P190 has symbolic content: E62 String`\\n\\n> 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.\\n\\nAs a result,\\n\\na) The following **direct forward direction** CIDOC Properties **cannot** be expressed and are **not defined** in RDFS:\\n\\n- `E95 Spacetime Primitive. P169 defines spacetime volume (spacetime volume is defined by): E92 Spacetime Volume`\\n- `E61 Time Primitive. P170 defines time (time is defined by): E52 Time-Span`\\n\\nb) The following **direct backwards direction** CIDOC Properties **cannot** be expressed and are **not defined** in RDFS:\\n\\n- `E94 Space Primitive. P168i defines place (place is defined by): E53 Place`\\n\\n> 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.\\n\\nAs a result, we did not implement a separate backwards/inverse direction for the following CIDOC Properties:\\n\\n- `E53 Place. P121 overlaps with: E53 Place`\\n- `E53 Place. P122 borders with: E53 Place`\\n- `E92 Spacetime Volume. P132 spatiotemporally overlaps with: E92 Spacetime Volume`\\n- `E92 Spacetime Volume. P133 is spatiotemporally separated from: E92 Spacetime Volume`\\n\\nAdditionally, all aforementioned redundant backwards/inverse CIDOC Property direction references, are replaced by the respective direct/forward CIDOC Property direction.\\n\\n- The hierarchical link of `P10i` subPropertyOf `P132i` was replaced with `P10i` subPropertyOf `P132`.\\n\\n#### **C. Labels and appellations**\\n\\nCIDOC-CRM version 7.1.2 defines the below subpropertyOf relations:\\n\\n- `P168 place is defined by` `subPropertyOf` `P1 is identified by`\\n- `P169i spacetime volume is defined by` `subPropertyOf` `P1 is identified by`\\n- `P170i time is defined by` `subPropertyOf` `P1 is identified by`\\n\\nThe 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 \\u2018supplementary\\u2019 RDFS file which one can use if such inconsistencies are not expected.\\n\\nIn 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:\\n\\n- `rdfs:label` subPropertyOf `P1 is identified by`\\n\\nNote 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.\\n\\n#### **D. Implementing Value Intervals**\\n\\nThe following are property pairs needed to simulate the interval-valued primitive values foreseen by the CRM:\\n\\n> 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`.\\n\\nAs a result, we have created the following property definitions:\\n\\n- `E52 Time-Span. P81a end of the begin: rdfs:Literal` (subPropertyOf `E52 Time-Span. P81 ongoing throughout: E61 Time Primitive`)\\n- `E52 Time-Span. P81b begin of the end: rdfs:Literal` (subPropertyOf `E52 Time-Span. P81 ongoing throughout: E61 Time Primitive`)\\n\\n> 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`.\\n\\nConsequently, we have created the following property definitions:\\n\\n- `E52 Time-Span. P82a begin of the begin: rdfs:Literal` (subPropertyOf `E52 Time-Span. P82 at some time within: E61 Time Primitive`)\\n- `E52 Time-Span. P82b end of the end: rdfs:Literal` (subPropertyOf `E52 Time-Span. P82 at some time within: E61 Time Primitive`)\\n\\n> 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`.\\n\\nConsequently, we have created the following property definitions:\\n\\n- `E54 Dimension. P90a has lower value limit: rdfs:Literal` (subPropertyOf `E54 Dimension. P90 has value: E60 Number`)\\n- `E54 Dimension. P90b has upper value limit: rdfs:Literal` (subPropertyOf `E54 Dimension. P90 has value: E60 Number`)\\n\\n#### **E. Multiple ISA custom declaration Classes**\\n\\nThe following are declarations of frequently used multiple instantiations as classes with respective multiple IsA (so far only one):\\n\\n> E1. addition of a new class, defined as subClassOf `E41 Appellation` and `E33 Linguistic Object`, for all Appellations being regarded\\nspecific to or characteristic for a language group and being described indirectly via a URI.\\n\\nAs a result, we have created the following class definition:\\n\\n- `E33_E41_Linguistic_Appellation` subClass of `E33_Linguistic_Object` and `E41_Appellation`\\n\\n#### **F. Translations and Scope notes**\\n\\n> 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:\\n\\n- 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.2) 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.2) does not define any translation in the RDFS file.\\n\\n- 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.\\n\\nCurrently 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.\\n\\n> 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:\\n\\n- Each Paragraph defines a new line\\n- Each element in an unordered list defines a new line\\n- Each element in an ordered list defines a new line prefixed with `'{order}. '`\\n- Each superscript text is separated from its base with `'-'`\\n- Each subscript text is separated from its base with `'_'` (none found)\\n\\n> 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':`.\\n\\nAs a result, the direct/forward property definition was used for the rdfs:comment definition of\\n\\n- `E92 Spacetime Volume. P169i spacetime volume is defined by: rdfs:Literal`\\n- `E52 Time-Span. P170i time is defined by: rdfs:Literal`\\n\\n\\n\"@en .\n \"RDFs Implementation (September 2022) of CIDOC-CRM 7.1.2\"@en .\n .\n \"This class comprises transfers of the physical custody or the legal responsibility for the physical custody of objects. The recording of the donor or recipient is optional. It is possible that in an instance of E10 Transfer of Custody there is either no donor or no recipient.\\nDepending on the circumstances, it may describe:\\n1. the beginning of custody (there is no previous custodian)\\n2. the end of custody (there is no subsequent custodian)\\n3. the transfer of custody (transfer from one custodian to the next)\\n4. the receipt of custody from an unknown source (the previous custodian is unknown)\\n5. the declared loss of an object (the current or subsequent custodian is unknown)\\nIn the event that only a single kind of transfer of custody occurs, either the legal responsibility for the custody or the actual physical possession of the object but not both, this difference should be expressed using the property P2 has type (is type of).\\nThe sense of physical possession requires that the object of custody be in the hands of the keeper at least with a part representative for the whole. The way, in which a representative part is defined, should ensure that it is unambiguous who keeps a part and who the whole and should be consistent with the identity criteria of the kept instance of E18 Physical Thing.\\nThe interpretation of the museum notion of \\\"accession\\\" differs between institutions. The CIDOC CRM therefore models legal ownership and physical custody separately. Institutions will then model their specific notions of accession and deaccession as combinations of these.\\nTheft is a specific case of illegal transfer of custody.\"@en .\n \"Transfer of Custody\"@en .\n \"Transfer\\u00EAncia de Cust\\u00F3dia\"@pt .\n \"Transfert de la garde\"@fr .\n \"\\u00DCbertragung des Gewahrsams\"@de .\n \"\\u039C\\u03B5\\u03C4\\u03B1\\u03B2\\u03AF\\u03B2\\u03B1\\u03C3\\u03B7 \\u039A\\u03B1\\u03C4\\u03BF\\u03C7\\u03AE\\u03C2\"@el ." ;
dataid:sha256sum "fbd8c064bd1c9c19ff8e62cdbe2ea51e8996fabb6e8266f32975bb25cb0fcc28" ;
dataid:signature "B6cY//xzFJNd9qeuacjp9Hde23SQsiXyMO/Kv6DihTRMlJ5Bi5X3rDPDEJpK685Loicarxp0PbVcRfzf8qUOjgrDOrs4f3WPJWOBnphNPCD34NDyasNF4r7sL5YCg5OBivcNvMRIZXQauAbmx4olyHLsRhaM+1tlnkhB/MhXDiX4zyDft3qQlynm95MQJijNEzdMzgeIKjKexSVjzti7K5/X1RjvigsVAw/BT+U2UL694r9DM2l+w9eGV5KNocPjNMrfm4kTaFPE15aGPfnTU9BaIGkOeECtFwEU7FPk0oViMOKHewaAHyZO3iTRUkEjqYlsoZdxUzQBBPUtb/B/ew==" ;
dataid-cv:tag "sorted" ;
dataid-cv:type "parsed" ;
dct:conformsTo "http://dataid.dbpedia.org/ns/core#" ;
dct:hasVersion "2024.01.20-224122" ;
dct:issued "2024-01-20T22:44:06Z"^^xsd:dateTime ;
dct:license ;
dct:modified "2024-01-20T22:41:26Z"^^xsd:dateTime ;
dct:publisher ;
dcat:byteSize "791539"^^xsd:decimal ;
dcat:downloadURL ;
dcat:mediaType dataid-mt:ApplicationNTriples .
a dataid:SingleFile ;
dataid:associatedAgent ;
dataid:compression "None" ;
dataid:contentVariant "parsed" ;
dataid:file ;
dataid:formatExtension "owl" ;
dataid:isDistributionOf ;
dataid:maintainer ;
dataid:preview "\n\n \n \n \n \n RDFs Implementation (September 2022) of CIDOC-CRM 7.1.2\n \n \n CIDOC CRM v7.1.2 implemented in RDFS" ;
dataid:sha256sum "9a68f4f590b38e642fdba4113063ef6a00207eb524e8d6db7f8bc80d4f271bf3" ;
dataid:signature "WpeA9Jqb3bKa0UxPbzS/PjKfT+f6yWeRdkBLeIJbxiJypGOut9FiqE9cdKg3niIY3+3vY1+LlbrGTQ6C9Whik3i0ibveN9vToHiRnNr41ip6AZ7eV46P3rN8nej6PJD5z0AxrCtJ/D5ZzoLiYNvdxcYZkBqL6A3JzOpxXjZkytUbL006Z29GqFstuwd0AYgzDI79ddsCBWwuFQmPfLi6cX+Bul3+Uw5kE7gbxs+qlmF4oDFJUrGnr9AehRIQqAVhmRepTkFbo+l4euzjhzLMAjB6OokPfpTFj7Qz5NIBF9P020eTHRrdFZ3GNzSSGRBn8ztWDRqbMqaE0+I+8B692A==" ;
dataid-cv:type "parsed" ;
dct:conformsTo "http://dataid.dbpedia.org/ns/core#" ;
dct:hasVersion "2024.01.20-224122" ;
dct:issued "2024-01-20T22:44:06Z"^^xsd:dateTime ;
dct:license ;
dct:modified "2024-01-20T22:41:29Z"^^xsd:dateTime ;
dct:publisher ;
dcat:byteSize "906114"^^xsd:decimal ;
dcat:downloadURL ;
dcat:mediaType dataid-mt:ApplicationRDFXML .
dataid-cv:imports rdfs:subPropertyOf dataid:contentVariant .
a dataid:Dataset ;
rdfs:comment "Archivo Ontology Snapshot for http://www.cidoc-crm.org/cidoc-crm/"@en ;
rdfs:label "http://www.cidoc-crm.org/cidoc-crm/"@en ;
dataid:account databus:ontologies ;
dataid:artifact ;
dataid:associatedAgent ;
dataid:group ;
dataid:groupdocu "## All DBpedia Archivo ontologies from cidoc-crm.org domain\n\nEach artifact in this group deals as the archive for snapshots of one ontology of the [DBpedia Archivo](https://databus.dbpedia.org/ontologies) - A Web-Scale Interface for Ontology Archiving under Consumer-oriented Aspects. Find out more at [http://archivo.dbpedia.org](http://archivo.dbpedia.org). The description for the individual files in the artifact can be found [here](http://dev.dbpedia.org/DBpedia_Archvio#files)." ;
dataid:maintainer ;
dataid:version ;
dct:conformsTo "http://dataid.dbpedia.org/ns/core#" ;
dct:description "## DBpedia Archivo Ontology Snapshot\n\n| Attribute | Value |\n| - | - |\n| Ontology URI | \n| Archivo Ontology Factsheet| [Link](http://archivo.dbpedia.org/info?o=http://www.cidoc-crm.org/cidoc-crm/)\n| Snapshot File URL | \n| Snapshot OWL Version IRI | \n| Snapshot Time | 2024-01-20 22:41:22\n\nThe [DBpedia Archivo Databus agent](https://databus.dbpedia.org/ontologies) generates only basic, static documentation for the archived snapshots of the ontologies.\n\n## Ontology Metadata\n\nDBpedia Archivo extracts metadata from the ontology for well known properties (e.g. dct:description). This subsection shows the content of every property individually using a separate heading.\n\n### rdfs:comment\n\nCIDOC CRM v7.1.2 implemented in RDFS\n\nThis is the implementation incorporating to the decisions of the 53rd CRM-SIG meeting (May 2022)\nand has been approved for official use.\nNote that this is NOT a definition of the CIDOC CRM, but a CIDOC CRM compatible implementation\nof an RDF Schema derived from the authoritative release of the CIDOC CRM v7.1.2 on June 2022\nhttps://cidoc-crm.org/Version/version-7.1.2 by an automated algorithm. It is intended for an\nassumed majority of uses. Depending on the application, users may create adequate extensions \ncompatible with the logical definitions of the CIDOC CRM.\n\nCreated by FORTH-ICS September 14, 2022\nCC BY 4.0 https://creativecommons.org/licenses/by/4.0/legalcode\n\nUpdated on: Friday January 19, 2024\n==========================\n- Added French labels from translation of version 7.1.2\n\nEncoding Rules:\n1. The RDF spelling rules do not allow blanks. Hence we have replaced them by underscores.\n For instance \"E63_Beginning_of_Existence\" or \"P2i_is_type_of\".\n\n2. RDF does not allow to instantiate properties beginning from a range value.\n Therefore, each CRM property is represented as two RDFS properties.\n For instance \"P2 has type (is type of)\" is represented as:\n \"P2_has_type\" for the domain to range direction and \"P2i_is_type_of\" for the range to domain direction.\n\n3. The primitive values \"E60 Number\", \"E61 Time Primitive\", \"E62 String\", \"E94 Space Primitive\" and \n \"E95 Spacetime Primitive\" referred in the Model for formal completeness are interpreted as rdfs:literal.\n\n4. RDF does not support properties of properties, therefore, users may create their own\n subProperties for CRM properties that have a type property such as \"P3 has note\":\n Instead of P3 has note (P3-1 has type : parts description) declare\n \n \n \n \n \n\n5. Scope notes are represented as elements.\n\n6. In addition this encoding contains labels in languages different from English, \n which are taken from translations of previous versions of the CIDOC CRM. \n\n7. Any other differences in labels, scope notes and semantic relationships of this encoding \n to the authoritative definition of the CIDOC CRM v7.1.2 (June 2022) are not intended transfer errors. \n FORTH appreciates your feed-back on such errors.\n\n8. CRM time extension 1.0 Encoded in RDFS (http://old.cidoc-crm.org/docs/How_to%20implement%20CRM_Time_in%20RDF.pdf)\n Since the Time Primitive of the CRM can not directly be implemented in RDF Triple Stores, we define in this extension\n of 4 properties replacing P81 and P82 adequately using xsd:dateTime. \n Property P81 is dedicated for modeling the Time-Span's maximum known temporal extent i.e. ongoing_throughout. \n Property P82 is for modeling the minimum outer bounds of events i.e. at_some_time_within. \n P81 has its time interval redefined by P81a and P81b. Similarly, we redefine P82 by P82a and P82b.\n## RDFS Generation Policies\n\n### Sources\n\nPolicies followed for the RDFS implementation of CIDOC v.7.1.2 were created w.r.t.:\n\n- Implementing the CIDOC Conceptual Reference Model in RDF (http://www.cidoc-crm.org/Resources/implementing-the-cidoc-conceptual-reference-model-in-rdf)\n- How to implement CRM Time in RDF (http://old.cidoc-crm.org/docs/How_to%20implement%20CRM_Time_in%20RDF.pdf)\n- CIDOC-CRM SIG feedback and the general guidelines:\n - Each property is declared twice, forward and backwards, unless no inverse name is defined in parentheses, or domain or range is interpreted as literal\n - All Primitive Values become rdfs:Literal\n - All IsA declarations from/to and between Primitive values are ignored\n\n### Policies\n\n#### **A. CIDOC Classes implementation in RDFS**\n\nThe 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.\n\nIn this version we have followed the following policy regarding CIDOC Classes implementation in RDFS:\n\n> 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.\n\nAs a result, the following CIDOC classes were not defined in RDFS:\n\n- `E59 Primitive Value`\n- `E60 Number`\n- `E61 Time Primitive`\n- `E62 String`\n- `E94 Space Primitive`\n- `E95 Spacetime Primitive`\n\nAdditionally, the following isA relationships were not defined in RDFS:\n\n- `E59 Primitive Value` `subClassOf` `E1 CRM Entity`\n- `E60 Number` `subClassOf` `E59 Primitive Value`\n- `E61 Time Primitive` `subClassOf` `E41 Appellation`\n- `E61 Time Primitive` `subClassOf` `E59 Primitive Value`\n- `E62 String` `subClassOf` `E59 Primitive Value`\n- `E94 Space Primitive` `subClassOf` `E41 Appellation`\n- `E94 Space Primitive` `subClassOf` `E59 Primitive Value`\n- `E95 Spacetime Primitive` `subClassOf` `E41 Appellation`\n- `E95 Spacetime Primitive` `subClassOf` `E59 Primitive Value`\n\n#### **B. CIDOC Properties implementation in RDFS**\n\nThe 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.\n\nFurther, 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.\n\nAnother aspect considered for the implementation of properties in RDFS is whether a distinct inverse property definition should be provided.\n\nIn this version we followed the following policies regarding CIDOC Properties implementation in RDFS:\n\n> 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.\n\nAs a result, the following properties do not define an inverse direction.\n\n- `E1 CRM Entity. P3 has note: E62 String`\n- `E19 Physical Object. P57 has number of parts: E60 Number`\n- `E52 Time-Span. P79 beginning is qualified by: E62 String`\n- `E52 Time-Span. P80 end is qualified by: E62 String`\n- `E52 Time-Span. P81 ongoing throughout: E61 Time Primitive`\n- `E52 Time-Span. P82 at some time within: E61 Time Primitive`\n- `E54 Dimension. P90 has value: E60 Number`\n- `E53 Place. P171 at some place within: E94 Space Primitive`\n- `E53 Place. P172 contains: E94 Space Primitive`\n- `E90 Symbolic Object. P190 has symbolic content: E62 String`\n\n> 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.\n\nAs a result,\n\na) The following **direct forward direction** CIDOC Properties **cannot** be expressed and are **not defined** in RDFS:\n\n- `E95 Spacetime Primitive. P169 defines spacetime volume (spacetime volume is defined by): E92 Spacetime Volume`\n- `E61 Time Primitive. P170 defines time (time is defined by): E52 Time-Span`\n\nb) The following **direct backwards direction** CIDOC Properties **cannot** be expressed and are **not defined** in RDFS:\n\n- `E94 Space Primitive. P168i defines place (place is defined by): E53 Place`\n\n> 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.\n\nAs a result, we did not implement a separate backwards/inverse direction for the following CIDOC Properties:\n\n- `E53 Place. P121 overlaps with: E53 Place`\n- `E53 Place. P122 borders with: E53 Place`\n- `E92 Spacetime Volume. P132 spatiotemporally overlaps with: E92 Spacetime Volume`\n- `E92 Spacetime Volume. P133 is spatiotemporally separated from: E92 Spacetime Volume`\n\nAdditionally, all aforementioned redundant backwards/inverse CIDOC Property direction references, are replaced by the respective direct/forward CIDOC Property direction.\n\n- The hierarchical link of `P10i` subPropertyOf `P132i` was replaced with `P10i` subPropertyOf `P132`.\n\n#### **C. Labels and appellations**\n\nCIDOC-CRM version 7.1.2 defines the below subpropertyOf relations:\n\n- `P168 place is defined by` `subPropertyOf` `P1 is identified by`\n- `P169i spacetime volume is defined by` `subPropertyOf` `P1 is identified by`\n- `P170i time is defined by` `subPropertyOf` `P1 is identified by`\n\nThe 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.\n\nIn 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:\n\n- `rdfs:label` subPropertyOf `P1 is identified by`\n\nNote 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.\n\n#### **D. Implementing Value Intervals**\n\nThe following are property pairs needed to simulate the interval-valued primitive values foreseen by the CRM:\n\n> 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`.\n\nAs a result, we have created the following property definitions:\n\n- `E52 Time-Span. P81a end of the begin: rdfs:Literal` (subPropertyOf `E52 Time-Span. P81 ongoing throughout: E61 Time Primitive`)\n- `E52 Time-Span. P81b begin of the end: rdfs:Literal` (subPropertyOf `E52 Time-Span. P81 ongoing throughout: E61 Time Primitive`)\n\n> 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`.\n\nConsequently, we have created the following property definitions:\n\n- `E52 Time-Span. P82a begin of the begin: rdfs:Literal` (subPropertyOf `E52 Time-Span. P82 at some time within: E61 Time Primitive`)\n- `E52 Time-Span. P82b end of the end: rdfs:Literal` (subPropertyOf `E52 Time-Span. P82 at some time within: E61 Time Primitive`)\n\n> 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`.\n\nConsequently, we have created the following property definitions:\n\n- `E54 Dimension. P90a has lower value limit: rdfs:Literal` (subPropertyOf `E54 Dimension. P90 has value: E60 Number`)\n- `E54 Dimension. P90b has upper value limit: rdfs:Literal` (subPropertyOf `E54 Dimension. P90 has value: E60 Number`)\n\n#### **E. Multiple ISA custom declaration Classes**\n\nThe following are declarations of frequently used multiple instantiations as classes with respective multiple IsA (so far only one):\n\n> E1. addition of a new class, defined as subClassOf `E41 Appellation` and `E33 Linguistic Object`, for all Appellations being regarded\nspecific to or characteristic for a language group and being described indirectly via a URI.\n\nAs a result, we have created the following class definition:\n\n- `E33_E41_Linguistic_Appellation` subClass of `E33_Linguistic_Object` and `E41_Appellation`\n\n#### **F. Translations and Scope notes**\n\n> 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:\n\n- 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.2) 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.2) does not define any translation in the RDFS file.\n\n- 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.\n\nCurrently 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.\n\n> 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:\n\n- Each Paragraph defines a new line\n- Each element in an unordered list defines a new line\n- Each element in an ordered list defines a new line prefixed with `'{order}. '`\n- Each superscript text is separated from its base with `'-'`\n- Each subscript text is separated from its base with `'_'` (none found)\n\n> 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':`.\n\nAs a result, the direct/forward property definition was used for the rdfs:comment definition of\n\n- `E92 Spacetime Volume. P169i spacetime volume is defined by: rdfs:Literal`\n- `E52 Time-Span. P170i time is defined by: rdfs:Literal`" ;
dct:hasVersion "2024.01.20-224122" ;
dct:issued "2024-01-20T22:44:06Z"^^xsd:dateTime ;
dct:license ;
dct:publisher ;
dct:title "http://www.cidoc-crm.org/cidoc-crm/"@en ;
dcat:distribution , , , , , , , , , , , , , , , , , , , .
dataid-cv:validates rdfs:subPropertyOf
dataid:contentVariant .
a dataid:SingleFile ;
dataid:associatedAgent ;
dataid:compression "None" ;
dataid:contentVariant "pelletInfo" , "FULL" ;
dataid:file ;
dataid:formatExtension "txt" ;
dataid:isDistributionOf ;
dataid:maintainer ;
dataid:preview "WARNING: An illegal reflective access operation has occurred\nWARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$2 (file:/usr/lib/pellet/cli/target/pelletcli/lib/guice-4.0.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)\nWARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$2\nWARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations\nWARNING: All illegal access operations will be denied in a future release\n[main] WARN org.semanticweb.owlapi.util.SAXParsers - http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit not supported by parser type org.apache.xerces.jaxp.SAXParserImpl\n[main] WARN org.semanticweb.owlapi.util.SAXParsers - entityExpansionLimit not supported by parser type org.apache.xerces.jaxp.SAXParserImpl\n[main] WARN org.semanticweb.owlapi.util.SAXParsers - http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit not supported by parser type org.apache.xerces.jaxp.SAXParserImpl\n[main] WARN org.semanticweb.owlapi.util.SAXParsers - entityExpansionLimit not supported by parser type org.apache.xerces.jaxp.SAXParserImpl\n[main] INFO org.semanticweb.owlapi.rdf.rdfxml.parser.TripleHandlers - Usage of rdf vocabulary: http://www.cidoc-crm.org/cidoc-crm/P100_was_death_of -> http://www.w3.org/1999/02/22-rdf-syntax-ns#type -> http://www.w3.org/1999/02/22-rdf-syntax-ns#Property" ;
dataid:sha256sum "2c8f24cade8cfad7a37d66637607043742187ed84cbf162474c3f0c750fa7402" ;
dataid:signature "lOYHAVym7jCuRyATjRCutKshBIAOM/8NqGeU22B4K1lhJq1Qt5OKeUJd3GbZWts2ooH8Io/Ai4ZduHWBjVkC2A8U94e5X5q976p/6hY+PP6pafE9I96j6ABHCHZUGaE+f9z+tNcHUnRi+w8PZ0XU1GT/X0FzxngYUnNJJ0fM3JiGXq9Z0B3beRPZTcaRStqgdhHNkxjR0rbXQrFTBKrsUM3sK84Ex6o5cx8Q4t5x31r6Q99mgwADUmFErCOosyalDslnAfFoarCea4boHhxDRBCogsOAHQkAbLco1hrtC+Z4u4xUnVT2EB4KaVXZPcV7J38Xyt2DyWFYz/b+jtrDlQ==" ;
dataid-cv:imports "FULL" ;
dataid-cv:type "pelletInfo" ;
dct:conformsTo "http://dataid.dbpedia.org/ns/core#" ;
dct:hasVersion "2024.01.20-224122" ;
dct:issued "2024-01-20T22:44:06Z"^^xsd:dateTime ;
dct:license ;
dct:modified "2024-01-20T22:41:37Z"^^xsd:dateTime ;
dct:publisher ;
dcat:byteSize "81827"^^xsd:decimal ;
dcat:downloadURL ;
dcat:mediaType dataid-mt:TextPlain .
dataid-cv:axioms rdfs:subPropertyOf dataid:contentVariant .
a dataid:Group .
a dataid:SingleFile ;
dataid:associatedAgent ;
dataid:compression "None" ;
dataid:contentVariant "meta" ;
dataid:file ;
dataid:formatExtension "json" ;
dataid:isDistributionOf ;
dataid:maintainer ;
dataid:preview "{\n \"http-data\": {\n \"accessed\": \"2024.01.20; 22:41:26\",\n \"best-header\": \"application/rdf+xml\",\n \"content-length\": \"428028\",\n \"e-tag\": \"\\\"687fc-60f4eaee88121\\\"\",\n \"lastModified\": \"Fri, 19 Jan 2024 16:07:56 GMT\"\n },\n \"logs\": {\n \"nir-header\": \"{'Date': 'Sat, 20 Jan 2024 22:40:41 GMT', 'Server': 'Apache/2.4.7 (Ubuntu)', 'Location': 'http://cidoc-crm.org//cidoc-crm/', 'Content-Length': '322', 'Keep-Alive': 'timeout=5, max=100', 'Connection': 'Keep-Alive', 'Content-Type': 'text/html; charset=iso-8859-1'}\"," ;
dataid:sha256sum "8cad7d2b1170c0ab574e9925f7be6a6ccf148fd35851539c8878497c8eb8842b" ;
dataid:signature "ErXPFrM5k/EBVNqh5mjTS2lV7DWNFybDykhWqdbMYNS5AHnGXfwNdoPyeBEazwCAoGOnCIETkJkVKGl1qXIGIP7Rsg3cbWb3aeUYWinZHJDOwaf7KhWtZ8c1S3J4USpZlEAcWefP2ATJgypr3YsTM/GskylBAu7va7IF18wzmdHi7dVYUbZxsuyQJqARe0Xqa4qbFJzil4IoSFnRiygsyGBk918i3jpyb/x0DXD1FXMT/coC0q8IRUDejcju4RoOw2Z1A9ur8yFsC70mLCUdAqye5IigoC4BzjbaeZnKeRJoEEGULzxOeqmeTp5GuyCHUtueY9MqwRq2S0g2AtuzMA==" ;
dataid-cv:type "meta" ;
dct:conformsTo "http://dataid.dbpedia.org/ns/core#" ;
dct:hasVersion "2024.01.20-224122" ;
dct:issued "2024-01-20T22:44:06Z"^^xsd:dateTime ;
dct:license ;
dct:modified "2024-01-20T22:41:43Z"^^xsd:dateTime ;
dct:publisher ;
dcat:byteSize "1422"^^xsd:decimal ;
dcat:downloadURL ;
dcat:mediaType dataid-mt:ApplicationJson .
a dataid:SingleFile ;
dataid:associatedAgent ;
dataid:compression "None" ;
dataid:contentVariant "new" , "diff" ;
dataid:file ;
dataid:formatExtension "nt" ;
dataid:isDistributionOf ;
dataid:maintainer ;
dataid:preview " \"CIDOC CRM v7.1.2 implemented in RDFS\\n\\nThis is the implementation incorporating to the decisions of the 53rd CRM-SIG meeting (May 2022)\\nand has been approved for official use.\\nNote that this is NOT a definition of the CIDOC CRM, but a CIDOC CRM compatible implementation\\nof an RDF Schema derived from the authoritative release of the CIDOC CRM v7.1.2 on June 2022\\nhttps://cidoc-crm.org/Version/version-7.1.2 by an automated algorithm. It is intended for an\\nassumed majority of uses. Depending on the application, users may create adequate extensions \\ncompatible with the logical definitions of the CIDOC CRM.\\n\\nCreated by FORTH-ICS September 14, 2022\\nCC BY 4.0 https://creativecommons.org/licenses/by/4.0/legalcode\\n\\nUpdated on: Friday January 19, 2024\\n==========================\\n- Added French labels from translation of version 7.1.2\\n\\nEncoding Rules:\\n1. The RDF spelling rules do not allow blanks. Hence we have replaced them by underscores.\\n For instance \\\"E63_Beginning_of_Existence\\\" or \\\"P2i_is_type_of\\\".\\n\\n2. RDF does not allow to instantiate properties beginning from a range value.\\n Therefore, each CRM property is represented as two RDFS properties.\\n For instance \\\"P2 has type (is type of)\\\" is represented as:\\n \\\"P2_has_type\\\" for the domain to range direction and \\\"P2i_is_type_of\\\" for the range to domain direction.\\n\\n3. The primitive values \\\"E60 Number\\\", \\\"E61 Time Primitive\\\", \\\"E62 String\\\", \\\"E94 Space Primitive\\\" and \\n \\\"E95 Spacetime Primitive\\\" referred in the Model for formal completeness are interpreted as rdfs:literal.\\n\\n4. RDF does not support properties of properties, therefore, users may create their own\\n subProperties for CRM properties that have a type property such as \\\"P3 has note\\\":\\n Instead of P3 has note (P3-1 has type : parts description) declare\\n \\n \\n \\n \\n \\n\\n5. Scope notes are represented as elements.\\n\\n6. In addition this encoding contains labels in languages different from English, \\n which are taken from translations of previous versions of the CIDOC CRM. \\n\\n7. Any other differences in labels, scope notes and semantic relationships of this encoding \\n to the authoritative definition of the CIDOC CRM v7.1.2 (June 2022) are not intended transfer errors. \\n FORTH appreciates your feed-back on such errors.\\n\\n8. CRM time extension 1.0 Encoded in RDFS (http://old.cidoc-crm.org/docs/How_to%20implement%20CRM_Time_in%20RDF.pdf)\\n Since the Time Primitive of the CRM can not directly be implemented in RDF Triple Stores, we define in this extension\\n of 4 properties replacing P81 and P82 adequately using xsd:dateTime. \\n Property P81 is dedicated for modeling the Time-Span's maximum known temporal extent i.e. ongoing_throughout. \\n Property P82 is for modeling the minimum outer bounds of events i.e. at_some_time_within. \\n P81 has its time interval redefined by P81a and P81b. Similarly, we redefine P82 by P82a and P82b.\\n## RDFS Generation Policies\\n\\n### Sources\\n\\nPolicies followed for the RDFS implementation of CIDOC v.7.1.2 were created w.r.t.:\\n\\n- Implementing the CIDOC Conceptual Reference Model in RDF (http://www.cidoc-crm.org/Resources/implementing-the-cidoc-conceptual-reference-model-in-rdf)\\n- How to implement CRM Time in RDF (http://old.cidoc-crm.org/docs/How_to%20implement%20CRM_Time_in%20RDF.pdf)\\n- CIDOC-CRM SIG feedback and the general guidelines:\\n - Each property is declared twice, forward and backwards, unless no inverse name is defined in parentheses, or domain or range is interpreted as literal\\n - All Primitive Values become rdfs:Literal\\n - All IsA declarations from/to and between Primitive values are ignored\\n\\n### Policies\\n\\n#### **A. CIDOC Classes implementation in RDFS**\\n\\nThe 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.\\n\\nIn this version we have followed the following policy regarding CIDOC Classes implementation in RDFS:\\n\\n> 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.\\n\\nAs a result, the following CIDOC classes were not defined in RDFS:\\n\\n- `E59 Primitive Value`\\n- `E60 Number`\\n- `E61 Time Primitive`\\n- `E62 String`\\n- `E94 Space Primitive`\\n- `E95 Spacetime Primitive`\\n\\nAdditionally, the following isA relationships were not defined in RDFS:\\n\\n- `E59 Primitive Value` `subClassOf` `E1 CRM Entity`\\n- `E60 Number` `subClassOf` `E59 Primitive Value`\\n- `E61 Time Primitive` `subClassOf` `E41 Appellation`\\n- `E61 Time Primitive` `subClassOf` `E59 Primitive Value`\\n- `E62 String` `subClassOf` `E59 Primitive Value`\\n- `E94 Space Primitive` `subClassOf` `E41 Appellation`\\n- `E94 Space Primitive` `subClassOf` `E59 Primitive Value`\\n- `E95 Spacetime Primitive` `subClassOf` `E41 Appellation`\\n- `E95 Spacetime Primitive` `subClassOf` `E59 Primitive Value`\\n\\n#### **B. CIDOC Properties implementation in RDFS**\\n\\nThe 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.\\n\\nFurther, 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.\\n\\nAnother aspect considered for the implementation of properties in RDFS is whether a distinct inverse property definition should be provided.\\n\\nIn this version we followed the following policies regarding CIDOC Properties implementation in RDFS:\\n\\n> 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.\\n\\nAs a result, the following properties do not define an inverse direction.\\n\\n- `E1 CRM Entity. P3 has note: E62 String`\\n- `E19 Physical Object. P57 has number of parts: E60 Number`\\n- `E52 Time-Span. P79 beginning is qualified by: E62 String`\\n- `E52 Time-Span. P80 end is qualified by: E62 String`\\n- `E52 Time-Span. P81 ongoing throughout: E61 Time Primitive`\\n- `E52 Time-Span. P82 at some time within: E61 Time Primitive`\\n- `E54 Dimension. P90 has value: E60 Number`\\n- `E53 Place. P171 at some place within: E94 Space Primitive`\\n- `E53 Place. P172 contains: E94 Space Primitive`\\n- `E90 Symbolic Object. P190 has symbolic content: E62 String`\\n\\n> 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.\\n\\nAs a result,\\n\\na) The following **direct forward direction** CIDOC Properties **cannot** be expressed and are **not defined** in RDFS:\\n\\n- `E95 Spacetime Primitive. P169 defines spacetime volume (spacetime volume is defined by): E92 Spacetime Volume`\\n- `E61 Time Primitive. P170 defines time (time is defined by): E52 Time-Span`\\n\\nb) The following **direct backwards direction** CIDOC Properties **cannot** be expressed and are **not defined** in RDFS:\\n\\n- `E94 Space Primitive. P168i defines place (place is defined by): E53 Place`\\n\\n> 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.\\n\\nAs a result, we did not implement a separate backwards/inverse direction for the following CIDOC Properties:\\n\\n- `E53 Place. P121 overlaps with: E53 Place`\\n- `E53 Place. P122 borders with: E53 Place`\\n- `E92 Spacetime Volume. P132 spatiotemporally overlaps with: E92 Spacetime Volume`\\n- `E92 Spacetime Volume. P133 is spatiotemporally separated from: E92 Spacetime Volume`\\n\\nAdditionally, all aforementioned redundant backwards/inverse CIDOC Property direction references, are replaced by the respective direct/forward CIDOC Property direction.\\n\\n- The hierarchical link of `P10i` subPropertyOf `P132i` was replaced with `P10i` subPropertyOf `P132`.\\n\\n#### **C. Labels and appellations**\\n\\nCIDOC-CRM version 7.1.2 defines the below subpropertyOf relations:\\n\\n- `P168 place is defined by` `subPropertyOf` `P1 is identified by`\\n- `P169i spacetime volume is defined by` `subPropertyOf` `P1 is identified by`\\n- `P170i time is defined by` `subPropertyOf` `P1 is identified by`\\n\\nThe 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 \\u2018supplementary\\u2019 RDFS file which one can use if such inconsistencies are not expected.\\n\\nIn 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:\\n\\n- `rdfs:label` subPropertyOf `P1 is identified by`\\n\\nNote 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.\\n\\n#### **D. Implementing Value Intervals**\\n\\nThe following are property pairs needed to simulate the interval-valued primitive values foreseen by the CRM:\\n\\n> 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`.\\n\\nAs a result, we have created the following property definitions:\\n\\n- `E52 Time-Span. P81a end of the begin: rdfs:Literal` (subPropertyOf `E52 Time-Span. P81 ongoing throughout: E61 Time Primitive`)\\n- `E52 Time-Span. P81b begin of the end: rdfs:Literal` (subPropertyOf `E52 Time-Span. P81 ongoing throughout: E61 Time Primitive`)\\n\\n> 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`.\\n\\nConsequently, we have created the following property definitions:\\n\\n- `E52 Time-Span. P82a begin of the begin: rdfs:Literal` (subPropertyOf `E52 Time-Span. P82 at some time within: E61 Time Primitive`)\\n- `E52 Time-Span. P82b end of the end: rdfs:Literal` (subPropertyOf `E52 Time-Span. P82 at some time within: E61 Time Primitive`)\\n\\n> 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`.\\n\\nConsequently, we have created the following property definitions:\\n\\n- `E54 Dimension. P90a has lower value limit: rdfs:Literal` (subPropertyOf `E54 Dimension. P90 has value: E60 Number`)\\n- `E54 Dimension. P90b has upper value limit: rdfs:Literal` (subPropertyOf `E54 Dimension. P90 has value: E60 Number`)\\n\\n#### **E. Multiple ISA custom declaration Classes**\\n\\nThe following are declarations of frequently used multiple instantiations as classes with respective multiple IsA (so far only one):\\n\\n> E1. addition of a new class, defined as subClassOf `E41 Appellation` and `E33 Linguistic Object`, for all Appellations being regarded\\nspecific to or characteristic for a language group and being described indirectly via a URI.\\n\\nAs a result, we have created the following class definition:\\n\\n- `E33_E41_Linguistic_Appellation` subClass of `E33_Linguistic_Object` and `E41_Appellation`\\n\\n#### **F. Translations and Scope notes**\\n\\n> 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:\\n\\n- 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.2) 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.2) does not define any translation in the RDFS file.\\n\\n- 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.\\n\\nCurrently 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.\\n\\n> 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:\\n\\n- Each Paragraph defines a new line\\n- Each element in an unordered list defines a new line\\n- Each element in an ordered list defines a new line prefixed with `'{order}. '`\\n- Each superscript text is separated from its base with `'-'`\\n- Each subscript text is separated from its base with `'_'` (none found)\\n\\n> 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':`.\\n\\nAs a result, the direct/forward property definition was used for the rdfs:comment definition of\\n\\n- `E92 Spacetime Volume. P169i spacetime volume is defined by: rdfs:Literal`\\n- `E52 Time-Span. P170i time is defined by: rdfs:Literal`\\n\\n\\n\"@en .\n \"D\\u00E9but d\\u2019existence\"@fr .\n \"est la forme alternative de\"@fr ." ;
dataid:sha256sum "8f0302f7b93aaefdbc83baec8012050168e09fe3f530349b00ff0c229629f014" ;
dataid:signature "IoNiRSiaKAtQIp9ECUtwAgvs71w54oqfARWH5Z9asE+/uiJYTfZAFDDoApiIpUi7fFcGyUn87ZlpEizfSPhydr3vqrZ9ThOs9m87vBbRO7cNeA9RQsXXIvjVz+EmMS54uo3v+rilnMJx+7+86PZN+K6C3oejXP8KramdObBbiE2Q60tlXmNoTeGqttX6sxbtadIrTGkzKpQaoM6rmC1qnKvS4v9bxeWcafCWz89+Ca74/qfeULF+MIL/aNCEzOoEcu3wz4sI3yV1f8AJOCX6NJnnLH2f9nVcXyMZ9nW4OclWxiYmjGlwjws8RnJbVJOwFyHulL9Sr9XT9fDr0TnTYw==" ;
dataid-cv:triples "new" ;
dataid-cv:type "diff" ;
dct:conformsTo "http://dataid.dbpedia.org/ns/core#" ;
dct:hasVersion "2024.01.20-224122" ;
dct:issued "2024-01-20T22:44:06Z"^^xsd:dateTime ;
dct:license ;
dct:modified "2024-01-20T22:41:29Z"^^xsd:dateTime ;
dct:publisher ;
dcat:byteSize "17514"^^xsd:decimal ;
dcat:downloadURL ;
dcat:mediaType dataid-mt:ApplicationNTriples .
a dataid:SingleFile ;
dataid:associatedAgent ;
dataid:compression "None" ;
dataid:contentVariant "new" , "diff" ;
dataid:file ;
dataid:formatExtension "" ;
dataid:isDistributionOf ;
dataid:maintainer ;
dataid:preview "" ;
dataid:sha256sum "01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b" ;
dataid:signature "OYdJMYtfPkvVvAU9hhHjrEi9+F1gXJFdulE9EgKuR2lqY3xERmLdazYBXeDHuO4lN6PiFPKha5rOxudghRJE/mOLTjlgeSrxE22XA1855WwF45kVRNGoWrgrdDukqb0JQjfgM78VsuXNhZTzm4PNWrtaXnx2orfLrp+Qj6axSebFRRCFt8MDxELOlqOQFCB+6DbgPSXVEv3WEdfVKvl1ieX82ZshEJBrMUu5cCuhAm+KkfJY+nyAWzD552QnTf1xMI6yxSX/W9pA1kPvV4aWDBCtvVs+6wGKRGxQ6xaDSXOuqOjK8bwoY4a1PPW1P1DMADeiSqJP+bE0v3Sfp/FWZg==" ;
dataid-cv:axioms "new" ;
dataid-cv:type "diff" ;
dct:conformsTo "http://dataid.dbpedia.org/ns/core#" ;
dct:hasVersion "2024.01.20-224122" ;
dct:issued "2024-01-20T22:44:06Z"^^xsd:dateTime ;
dct:license ;
dct:modified "2024-01-20T22:41:29Z"^^xsd:dateTime ;
dct:publisher ;
dcat:byteSize "1"^^xsd:decimal ;
dcat:downloadURL ;
dcat:mediaType dataid-mt:UNKNOWN .
dataid-cv:triples rdfs:subPropertyOf dataid:contentVariant .
a dataid:SingleFile ;
dataid:associatedAgent ;
dataid:compression "None" ;
dataid:contentVariant "generatedDocu" ;
dataid:file ;
dataid:formatExtension "" ;
dataid:isDistributionOf ;
dataid:maintainer ;
dataid:preview "