Re: assymetric reference of properties

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

I disagree that it is necessary.  In RDF, as you say, the extent of a property 
name-space extends beyond the domain (it isn't really global, since RDF 
sensibly requires property-names to be modified by a namespace URI.  However, 
I don't see the problem.  What you are desiring is really a ternary 
relationship: Between the subject, object and domain.  It just so happens that 
OO and many KM systems package this ternary relationship into a 
specially-modified binary one, but there is no intrinsic reason why RDF should 
treat it differently than any other N-ary relationship.  And section 7.3 of 
the M&S spec describes a simple way to turn N-ary relationships into regular, 
binary RDF relationships.  We use this approach all the time without much 
difficulty, and I would certainly prefer it to encoding the domain into the 
property name.

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

Some other people here have complained about this, but I confess I don't see 
the problem here.  I haven't seen a situation where reification is inadequate. 
 But then again, I still don't see the need for treating unreified statements 
as resources, as the SiRPAC and "standard" API folks insist.

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

This should be handled by the application, not at the RDF layer.  An app 
object implementing the range should be able to delegate the property addition 
to the domain object.  In the serialization, of course, the property would 
appear in the domain object's description.  Again, I don't see the problem.

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

I don't believe the domain and range should have equal rights.  Even in pure 
set theory, a mapping (which is all an RDF property is) are strictly from 
domain to range.  If you need the inverse, declare it explicitly.  This is not 
a problem in the semantic net, because query of this net should use 
directed-graph search algorithms that are not affected by "starting point".

Another point: domain and range "equality" would be impossible to mannage as 
the "semantic net" matures into a "web of trust".

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

Again, I believe this should be application-level.

As a general point, I have always found RDF very simple, and very powerful for 
that.  The parts of RDF with which I'm dissatisfied tend to be in areas where 
it caves in too much to requests for more complex features.  I would certainly 
feel that such additions as N-ary relationships, inverse relationships, and 
implicit namespaces are alien and unnecessary.  All such these features can be 
super-imposed on RDF at a higher level.


-- 
Uche Ogbuji
Fourthought, Inc., IT Consultants
uche.ogbuji@fourthought.com	(970)481-0805
Software-engineering, project-management, knowledge-management
http://Fourthought.com		http://OpenTechnology.org

Received on Sunday, 6 February 2000 11:08:44 UTC