Re: rdf:value and RDF Schema (was: typed containers in RDF Schema)

Dear Pat,

First of all I would like to thank you for taking the trouble answering 
my questions. As I browsed
through the mailing list I found that you have many times in the past 
explained almost the same things
over-and-over.

pat hayes wrote:

>> Then every concrete horse that is an instance of class "horse" would 
>> inherit properties
>
>
> No. There is no notion of property inheritance in RDFS. It is 
> important to not fall into the trap (because it is a trap) of thinking 
> of RDFS classes in OOP terms. RDFS is simply a general-purpose 
> assertional description language; if you like, a kind of database 
> formalism. It is not a structured object-oriented programming language. 

I believe that I can understand that now. I think that the main feature 
of RDFS that distinguishes it from other OO aproaches is that it is 
property-centric:
(http://www.w3.org/TR/rdf-schema/#ch_rdfs) "... One benefit of the RDF 
property-centric approach is that it is very easy for anyone to say 
anything they want about existing resources, which is one of the 
architectural principles of the Web [BERNERS-LEE98 
<http://www.w3.org/TR/rdf-schema/#rdfnotcite>]. "

Most OO approaches are class-based; class (in other approaches) is both 
a type and a set; in RDFS class is only a set - there is no notion of type.
"Types" of resources are flexible and dynamical; they are defined on the 
"fly" whenever a new property is "defined" (or stated if you prefer).
This is a major obstacle for implementing RDFS hierarchies using the 
normal OO view of classes, as I am trying to do (see below).

>> from both super-classes of class "horse". This is the well-known 
>> multiple inheritance
>> and is perfectly ok to OO people.
>>
>> However, multiple inheritance is different from multiple typing, i.e. 
>> an object to be an
>> instance of multiple classes, which (may be I'm wrong) is not so 
>> popular to OO people.
>
> An aside, but can you say why? I would have thought that the only 
> technical problems would arise from multiple inheritance. Certainly 
> those are the most pressing problems in implementing an RDFS reasoner. 

I explain below my current efforts.

>> The previous WD for RDF schema stated the above fact explicitly:
>> (http://www.w3.org/TR/2000/CR-rdf-schema-20000327/#s2.3.1) "...A 
>> resource may be an instance of more than one class. ..."
>>
>> I think that this multiple-typing issue creates a lot of problems for 
>> developers, since most systems out there do not
>> confront to multiple (conjunctive) typing of objects.
>
>
> Can you elaborate on what the problems are and what kind of systems 
> you are referring to?  And, RDF *permits* multiple typing, but it does 
> not *enforce* it., So if you have a hierarchy that has no multiple 
> typing then that would be legal RDF. 

What I'm currently trying to do is the following:

Import an RDF(S) document into the CLIPS production system, which has an 
OOPL called COOL.
Then model RDF resources and properties as objects in the COOL language.
Then, I'll be able to use a deductive rule language that I have 
developed in CLIPS (called X-DEVICE 
<http://www.csd.auth.gr/%7Elpis/systems/x-device.html>) to query and 
reason about RDF data.

However, I am experimenting if I can "turn around" the RDF model into 
the usual OO model, i.e. classes with properties (and not properties
as first-class objects). It turns out that the liberty allowed in RDFS 
makes this task difficult.

One of the difficulties is that if one has established a class schema 
and a new schema comes up that adds properties to existing classes,
then the class definitions must be re-defined. Such dynamic class 
re-definitions are not easy in most OO systems (although I managed
to overcome this - however there are a lot of technical and 
CLIPS-specific details about how this can be done).

One other major difficulty is the multiple-typing problem; when a 
resource is defined as of type A, then the "constructor" of class A
must be invoked to create it. When a resource has multiple types, then 
which constructor should be called?
Of course, this problem is due to the fact that I consider a class to be 
a type and not a mere set.
The only way around multiple-typing in my approach is to turn it into 
multiple-inheritance with the trick of creating a "transparent" or 
"blank" class.
This is not the ultimate solution though, because what will happen if 
later a new schema is imported that adds a new type to a resource?
This would require dynamic redefinition of the class-hierarchy! (May be 
I'll be able to come around this as well, but with tricky hacks).

Another difficulty in implementing RDFS semantics is the notion of 
classes of classes (or meta-classes as I prefer to call them,
using an old-fashioned OODB term). Most OOP languages (including CLIPS) 
do not support meta-classes, so in order to implement
them one has to use tricks. The trick I used that a metaclass is 
implemented both as an instance of an existing class and as a new class.
Luckily, CLIPS does not complain if an object and a class exist with the 
same name simultaneously.
There exist some systems, that support meta-classes (without restricting 
the depth level of the "instantation" hierarchy)
like ADAM, an OODB bulit on top of Prolog:

N.W. Paton, ADAM: An object-oriented database system implemented in 
Prolog, Proc. 7th British National Conf. on Databases CUP (1989) 147-161.

which I have used for an earlier implementation of X-DEVICE.

Finally, the concept of subproperties is also difficult to implement 
when properties are not first-class objects. One way to
overcome this is the following:

If A is a subproperty of B
and the domain of A is class T
Then include B as a property of T as well
and alter the retrieval method of B,
     so that whenever someone requests the value of the B property for 
an object of class T,
                then retreive and return the value of property A instead.

This can be done transitively for all indirect superproperties of A.

>> One way to overcome this (of course) is to generate a "transparent"
>> class that has multiple super-classes and then make the multi-typed 
>> object an instance of this new class.
>>
>> i.e.
>>
>> from the following:
>>
>> ?x rdf:type A
>> ?x rdf:type B
>>
>> generate the following (inside the application):
>>
>> _001 rdfs:subClassOf A
>> _001 rdfs:subClassOf B
>> ?x rdf:type _001
>>
>> An application should generate such "transparent" classes, when:
>> a) A resource is stated to belong to multiple classes.
>> b) A property has multiple domain or range constraints
>>
>> The above can result is numerous system-generated classes (the upper 
>> limit is the PowerSet of all classes?).
>
>
> I would not recommend this strategy other than as a last resort. I do 
> not follow why you think it is necessary. Can you elaborate on what 
> applications of RDF you have in mind that would require it?

Please, see above.

>> I wonder if the RDF working group have considered this when allowing 
>> multiple types for a resource and the
>> very much related issue of multiple (conjunctive) domain and range 
>> constraints.
>>
>> I would like to notice that if multiple typing is not allowed in RDF, 
>> then the author of an RDF Schema must himself/herself
>> manually add such classes. May be this is the reason for allowing 
>> multiple typing; to release the burden from the RDF Schema
>> author.
>
> No, the reason to allow it is that even the simplest ontologies 
> usually require it. For example, consider a database of employee 
> records, Employees, let us suppose, can be grouped by job title, by 
> department, or by seniority. All of these could be defined in terms of 
> class membership. It would be ridiculous to insist that only one of 
> the properties could be allowed to be the one that defined 'the' 
> class, or that we had to introduce explicit intersection classes for 
> all the possible combinations. 

So, this is a reason why the system should automatically generate such 
intersection classes on-demand, transparently to the user.
Or, another solution would be to re-design the whole thing to follow the 
RDF property-centric and set-based philosophy. This would save
a lot of effort in importing RDF data, but would require extensive 
modifications to the implementation of my existing X-DEVICE rule language,
which is class-based.

The trade-off is there and so the decision would ultimately be based on 
how much dynamicity and flexibility could I handle at run-time.

Thank you again for your answers.

Nick.


-- 
**************************************************************
* Dr. Nick Bassiliades                                       *
*                                                            *
* Programming Languages And Software Engineering (PLASE) Lab *
* Logic Programming and Intelligent Systems (LPIS) Group     *
*                                                            *
* Dept. of Informatics, Aristotle University of Thessaloniki *
* 54006 Thessaloniki, Greece                                 *
*                                                            *
* Tel: +30310998418    E-mail: nbassili@csd.auth.gr          *
* Fax: +30310998419    URL:    http://www.csd.auth.gr/~nick  *
**************************************************************