Cart
[Home] [By Thread] [By Date] [Recent Entries]
> > > - 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@f... +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
|
