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.
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.
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.