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

["Thomas B. Passin" <tpassin@home.com>]

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.
> <rdf:Description
>   about="http://spam.com#Malatesta"
>   type="http://art.org#Patron">
> [...]
>
>
> >    TM: feasible but must be layered on top, primarily no doubt by
defining
> > 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
be said?

> 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
> sauce)
> 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)
>
Sounds good.

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

 Fun discussion!

Cheers,

Tom P