assymetric reference of properties

Dear collegues,

The Documentation Standards Group of the CIDOC/ICOM
(www.icom.cidoc.org) has created in the past 4 years a Conceptual
Reference Model, the CIDOC CRM
(http://www.ics.forth.gr/proj/isst/Activities/CIS/cidoc/),
which has been communicated to the ISO. It is an object-oriented domain
ontology, aimed at supporting mediation and good practice of system
design
in the cultural heritage area. As such, we see RDFS as a natural
data exchange format. The last outcome of this attempt can be
found on: http://www.ics.forth.gr/proj/isst/Activities/CIS/cidoc/docs/
It has been validated by our parser
(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
(a derivative from the KL-ONE family),
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. (It has
been completely overcome by Description Logics e.g.). In particular in
the light of navigational use, the "equal rights" of domain and range
should be important. May be most applications up to now had been
descriptions of products rather than anything else, and the problem has
not appeared much.


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" for all data models, which
do have the above problem. 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:

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.

Martin Doerr



-- 

--------------------------------------------------------------
 Dr. Martin Doerr              |  Vox:+30(81)391625          |
 Senior Researcher             |  Fax:+30(81)391609          |
 Project Leader SIS            |  Email: martin@ics.forth.gr |
                                                             |
  Centre for Cultural Informatics and Documentation Systems  |
                Institute of Computer Science                |
   Foundation for Research and Technology - Hellas (FORTH)   |
                                                             |
 Vassilika Vouton,P.O.Box1385,GR71110 Heraklion,Crete,Greece |
                                                             |
  Web-site: http://www.ics.forth.gr/proj/isst/index.html     |
--------------------------------------------------------------

Received on Wednesday, 26 January 2000 04:43:55 UTC