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

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

> > *My own opinion* is that RDF, XLink and Topic maps are all complementary,
> > but that XTM tends to overlap with all of them, and might just be otiose
> > (or might be the perfect intersection of the three, depending on your
> > opinion).
>
> I don't really see this so-called lower-level for RDF, higher level for
> Topic Maps.  They may be ***used*** that way by convention, but that's a
> different matter.

No.  My view of it has nothing to do with convention (I doubt there's any
such thing as convention, at least with regard to RDF).  I really don't
see how they can be seen any other way than RDF low, TM high.  But on to
your list below.

> I see Xlink more as infrastructure that's useful for
> either (potentially, at least), just as Hytime is infrastucture that can
> support ISO-flavor topic maps.

No.  There are many examples of how XLinks-as-infrastructure lead to
contrivance in expressing Topic Maps.  One I've mentioned is reification
at the same level as the rest of the model.  RDF is rather more natural in
expressing such KR graphs (even though even RDF gets things a twisted
often enough).

> Look at the kinds of things you probably want to do wth these systems:
>
> - Assign properties
>     RDF: made for it, duck soup.
>     TM: Just as simple with ISO TMs using facets.  For some reason I have
> never understood, facets were removed in XTM, so now you have to assign
> properties using appropriate relationships.  Quite doable, but more clumsy.

This is pretty much too elementary for the current comparison.  Neither
RDF nor XTM is required for this.  Plain old XML attributes fit the bill.

> - Make assertions about objects (or resources or ...)
>    RDF: Very feasible, although you may have to do some reification.

The "may have to do some reification" is the low-level part.  RDF provides
a single component: the directed graph between decorated nodes.  You have
to build higher level pieces, such as TM associations or units of
measurement.

>    TM: easy with built-in associations.

But these are only conceptually suited to a subset of assertions, IMO.  I
don't find them very general.

> - Create associations
>    RDF: very doable, but there is no native construct for assocations per
> se.

Again low level.  You can build constructs for associations using RDF.

>    TM: made for it, duck soup.

Yes, because it's designed at this higher level.

> - Create or use type hierarchies.
>    RDF: built-in machinery.
>    TM: almost built-in machinery.  You have to roll your own, but the
> constructs are there.

I can't resist pointing out that both RDF and TM show some pollution from
the object-oriented world in their treatments of types.

I'd like to see  an RDF 2 less concerned with setting forth rules for
canned forms of  relationships and rather providing a richer basis on
which such rules can be defined.  I'd like to use delegation, and I'd
like to be able to  express dynamic relationships in a model at a
reasonably low  level.  This would bring  the tremdous power of what the
RDBMS folks call  aggregate functions into  RDF-based KR.  An example is
an RDF "average rating" predicate for a Web site.

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

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

<rdf:Description
  about="http://spam.com#Malatesta"
  type="http://art.org#Patron">
[...]

> - Inferencing:
>    RDF: feasible but must be layered on top of RDF (as it is now).

I don't understand this qualification.  Looks like a tautology to me.

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

> - Constructs for various container structures.
>    RDF: strong

Hmm.  I'm not so sure about that.

>    TM: weaker, only has the equivalent of bags.

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.  Note that another thing that
robs RDF of "assembler language" simplicity: aboutEachPrefix, is an
example of something that would have been better implemented on top of RDF
using dynamically synthesized predicates.

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)

I think another possible layer 5) RDF Logic needs a good deal more
incubation.

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

> - Merge maps or documents.
>    RDF: conceivable but no particular provisions.
>    TM: strong built-in machinery (once the XML folks get through arguing
> about the ins and outs of it).

Again low-level/high level.  The RDF model defines a universe as is.  You
can break off bits of this universe as you like, and merge them back using
whatever rules you please.  TM's approach is one option.

> -  Easy to read fragments.  Of course this is a matter of taste to some
> degree.  For me, TMs are easier to read than RDF.

It surely depends on the serialization.  If you take advantage of RDF's
abbreviations, you can easily have serialized RDF that looks just like
"plain" XML, and is thus even easier to read than the XTM equivalent.


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