Here the latest attempt of an RDF version of the CIDOC CRM. It is semantically correct, checked with our RDF parser (see http://www.ics.forth.gr/proj/isst/RDF)

On transforming the Model from the textual formulation, which is conformant with the TELOS knowledge representation language, we encountered the following problems:

1.) In TELOS and other oo-models, property names are in the scope of the domain class. This causes a certain complexity due to inheritance, which means, that actually property names must be unique within all subclasses of the domain class also. In RDF, property names are global to the defined scope of the application. Hence we had to change multiply appearing names. We did that by adding the name of the domain class, e.g.: Place.is identified by (identifies) : Place Appellation becomes "place_is_identified_by_.identifies."

2.) The RDF spelling rules do not allow blanks. Hence we have replaced them by underscores (see above).

3.) The RDF spelling rules do not allow parenthesis. The inverse name is here seperated by dots, any better idea welcome.

4.) The primitive values "Number" and "String", referred in the Model for formal completeness are interpreted as rdf: literal. After these minor obstackles (questions of taste left open), the RDF version is a complete equivalent of the CRM, except for :

5.) Links on links are not formally foreseen in RDF, the "reification" did not seem to us to map things like dynamic roles. We have left this question open. In any case, a "role class" can be inserted for that purpose.

6.) The references to the metamodel in the CRM have been ommitted, as they are not functional for an application of the model. A really clumsy behavior however exhibits RDF with respect to inverse links. Even though RDF Schema declares properties in an unbiased way, i.e. declaring it between a domain and a range, the application of  the schema does not allow to declare an instance of it from the side of the range. Actually this leads to pseudo-heterogeneities, as the same property must be declared twice, once from the domain and once from the range. This seems to be a legacy from database schemata, were fields belong to a table or class. In a semantic net however, and in metadata declaration aimed at mediating between different formats for the same contents, it appears to our opinion as inappropriate.

Example:

<?xml version="1.0"?>
<rdf:RDF xml:lang="en"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/TR/1999/PR-rdf-schema-19990303#"
xmlns:self="">

<rdfs:Class rdf:ID="Artist">
</rdfs:Class>

<rdf:Property rdf:ID="creates">
<rdfs:range rdf:resource="#Artifact"/>
<rdfs:domain rdf:resource="#Artist"/>
</rdf:Property>

<rdf:Property rdf:ID="is_created_by">
<rdfs:range rdf:resource="#Artist"/>
<rdfs:domain rdf:resource="#Artifact"/>
</rdf:Property>

<rdfs:Class rdf:ID="Artifact">
</rdfs:Class>

<rdf:Description about="http://some.artist.info.collection/Monet">
<rdf:type rdf:resource="#Artist"/>
<self:creates rdf:resource="http://artifact.collection/haystacks"/>
</rdf:Description>

<rdf:Description about="http://artifact.collection/haystacks">
<rdf:type rdf:resource="#Artifact"/>
<self:is_created_by rdf:resource="http://some.artist.info.collection/Monet"/>
</rdf:Description>

</rdf:RDF>

In the CRM we have foreseen an "inverse name" to be able to create appropriate equivalent links/relations/properties/fields with all data models, which do have the problem of properties attached only to one side. I.e. as convenient, users may either use the name "is identified by" for the property in the first example, or the name "identifies" for the its inverse.
The simultaneous provision of both links as above, without further formal semantics, seems not to be very satisfactory.
I can imagine 3 solutions, which I am going to propose to the RDF community:

a) A statement is introduced in RDFS, stating that property B is the inverse of property A. This would allow at least to formally exchange information about the inverse equivalence of A and B.

b) RDF descriptions are extended to declare property instances of the inverse of a property type. This would avoid double declaration, lead to redundance-free models, but make an arbitrary decision to from where the "original" property is read. The use of the inverse property type becomes less comprehensive to read for humans.

c) RDFS is extended to register two names for each property, a forward and a backward one, as we propose in the CRM, and RDF descriptions allow for either use according to the direction of use. The latter seems to us the most appropriate solution.
Comments welcome.

In the mean-while, we cannot bypass the problem, so we must create double properties. In order to understand, which pairs belong together, we may use "reification" statements, or introduce some encoding, like a leading or trailing link-id.
Comments welcome.