Re: Linkbases, Topic Maps, and RDF Knowledge Bases -- help me

[Uche Ogbuji <uche.ogbuji@fourthought.com>]

> > > - Create or use class hierarchies
> > >    RDF: similar to hierarchies in constructs.
> > >    TM: Same as for hierarchies.
> >
> > Both are really type hierarchies, and the class/type confusion is part of
> > the OO pollution.
>
> One kind of hierarchy is the type-instance one, another is the
> class-subclass (or could be called type-subtype).

Here's the problem.  I think that class is quite different than type, and
that the subclass relationship is quite different from subtype.

I was hoping to avoid placing my creds in jeopardy by offering up a
definition of class and type, but I guess I can't avoid it.

A type is a unit, atomic annotation that is most often used as a reference
by constraints imposed by a system *outside* the entitiy in question.

A class is a commonality of behavior or protocol that is structurally
defined *within* the entity.

Therefore, an entity can have a type of "integer", and this might
constrain it as being in the class of "entities that provide protocols for
addition and subtraction, and are further constrained to have no
fractional component".

I think that a lot of my recent and growing skepticism of the power of OO
to model the real world comes from the confusion between types and
classes that is prevalent in languages such as C++ and Java.

The entire "Bird has 'flying' method", "an ostrich entity is of *class*
Bird", "an ostrich cannot fly" conceptual problem is the most common
example of where this conflation screws things up, but there are many others.

If an ostrich entity could be of *type* bird, and at the same time not of
*class" Bird, the *conceptual* problem would be solved, although I
understand that there might be implementation problems remaining.

> Both "type" and "class" have been used for a very long time in logic nad
> philosophy, and their meaning seems to drift around.  Are they the same
> (outside of OO)?  Hmm...

I agree that their meaning drifts, and my definitions are probably as
arbitrary as anyone else's, but at least now you have an idea what I'm
saying about avoiding the blurring of class and type in
knowledge-management systems.


> > Containers are one of the things that pollute RDF's low-level nature, and
> > I think this is part of why they are problematic.  I think that containers
> > should be built at a level on top of RDF.
> >
> I'm not too sure about this.  I mean, you can do any static logic circuit
> with NAND gates, but having other specialized types is very useful and may
> be better for performance.  I don't mind specialized constructs if there
> aren't too many and they are well-designed to help to common jobs.

I'm not saying that they're not useful.  I'm just saying that RDF should
be low-level or high-level, but not both at the same time.  If it
defines containers, it should probably define N-ary relationships, which
are probably as common and useful in typical RDF use-case.

>  Fun discussion!

Jawohl!


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python