[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Linkbases, Topic Maps, and RDF Knowledge Bases -- help me
- From: "Thomas B. Passin" <email@example.com>
- To: xml-dev <firstname.lastname@example.org>
- Date: Sat, 07 Apr 2001 09:30:47 -0400
Uche Ogbuji says -
> > - 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). The type-instance is
natively supported in TM, but it is a great temptation to use it for
type-subtype relationships anyway. You could declare class-subclass
hierarchies in TM (no matter what you thought a class is supposed to be) but
there is no native semantics for them.
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...
> > - Declare that one thing is an instance of type.
> > RDF: Very feasible
> > TM: built-in, duck soup
> Why is this "very feasible" in RDF? It's built in as well:
Well taken, forgot about that one.
> > TM: feasible but must be layered on top, primarily no doubt by
> > the nature of various association topics. May become built-in in the
> > future.
> Oh. I think I see what you mean now, but it's just another example of why
> RDF is low-level. Inferencing itself can be built using RDF constructs in
> a variety of ways.
How is this different in level, though, from TM, abut which the same xould
> 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.
> Perhaps RDF should be broken into 4 specs:
> 1) RDF Model (ditch the containers, aboutEachPrefix and all that other
> 2) RDF Library (useful collection of constructs built on (1), such as
> containers and N-Ary relationships such as measured relationships and
> general associations.
> 3) RDF Schemas
> 4) RDF Serialization (XML and LISP serializations for RDF)
> > - Filter.
> > RDF: no particular built-in machinery.
> > TM: built-in, elaborate machinery (scopes)
> Again, this is because RDF is lower level. You can build "scopes" on top
> os RDF in many ways. One popular approach that has been discussed on
> www-rdf-interest has been "contexts", which are similar to TM scopes.
Yup, each can be "extended" to supply things the other already has.