TopicMapsVsRDF

A good paper comparing and contrasting RDF and TopicMaps (and two other formats):

Topic Maps, RDF, OIL, and DAML

also

Ten Theses on Topic Maps and RDF


I apologize for being an ignorant bumpkin, but I found Topic Maps, RDF, OIL, and DAML to be really confusing. http://www.topicmaps.org/ didn't help either.

I understand RDF, a little bit: It's about making it so you can tell machines common sense things, like "A car is a type of automobile," and "A kid was born by a mom and dad," and other little fact pieces like that. Then you have OWL, which makes it so you can say these things in other languages: "When they talk about a "vehicle," it's like what I call an "automobile." " That way, if Ford's and Chrystler's computers talk with each other, with just slightly different names and orders for things, then everything will work together, sort of.

I can understand that.

What I don't get are Topic Maps. I understand it has something to do with telling machines what a conversation is about, and how subjects connect to each other.

Some of my questions, which are not answered on those pages, are:

  • What is a Topic Map?
  • Why do we care about Topic Maps?
  • What's it have to do with wiki?

I think it means something, I'm just not seeing it.

Recommended Forbidden words: Semantics, Ontology, TLA's that you haven't defined (except "XML," which is okay) ISO numbers, "consortium," interchangably, addressible.

Topic Maps are often compared with RDF, even by people who should know better. The only thing they have in common is that they both have something to do with graphs. How they implement graphs, why they use graphs, etc. are completely different. [I'm going to break one rule and use the word "semantics", but you can just substitute "defined meaning" wherever you see it. I found it awkward to keep doing that while writing].

RDF is the Resource Description Framework. I have it on authority (from R.V. Guha himself) that RDF was a sneaky way to get graph theory into XML. It's basically an odd, highly-namespaced, mostly-XML syntax that allows one to express triples, i.e., a (1) relation between a (2) subject and (3) object. RDF operates at a syntax level, and has few semantics of its own. It was given a formal model years after its publication. RSS, OWL, etc. build a layer of semantics on top of RDF (i.e., they define a bunch of new concepts and relations identified by URIs, and use those URIs to make statements). Without that layer, it's just a graph filled with URI references. RDF is not quite XML in any traditional sense; you can't write a DTD for RDF; it needs its own RDF Schema language. Even people in the middle of the RDF community hate the syntax and have tried to come up with alternatives like N3. (I've always thought they should just adopt GXL and get on with life.) Now, what people have done with that syntax is of course much more than simply describe resources. In fact, being limited to describing resources has bit the RDF community when they wanted to describe things that weren't actually resources, like people, unless one's view of the universe is that essentially everything is a resource.

You can't "do" Topic Maps in RDF without implementing the complete set of Topic Map semantics (adding a layer above RDF) and building a processing model compliant with the paradigm. Then you'd be implementing Topic Maps. XTM and RDF are just markup syntaxes. XTM isn't even a representation of a Topic Map, it's an interchange syntax (this leads people to think that they can edit an XTM file with a text editor – you can't, at least not safely). I've found that most of the people trying to compare Topic Maps and RDF are doing so for other than technical reasons, like trying to fit Topic Maps into the Semantic Web community, which is composed almost entirely of RDF zealots.

Topic Maps don't operate at the syntax level, they're a paradigm (in the words of its inventors). Now, some of us got together and created an XML interchange syntax for Topic Maps, and called it XML Topic Maps XTM. But XTM is just one possible Topic Map syntax; one could implement Topic Maps using any suitable technology. The formal model for Topic Maps is not included in its ISO Standard, and people are still arguing today over some of the details. Simply put, a Topic Map document is two things: (1) an internal graph structure; and (2) a map. I'll try to explain this below. Bear with me.

(some of this comment was "moved" to TopicMap)

Versus the ResourceDescriptionFramework

I'd like to cover how the ResourceDescriptionFramework and TopicMaps overlap, if I may. While it's true that they are not identical, they end up covering the same ground in the same way. (I am not covering serialisation here. RDF/XML and XTM's XML are not IMO pertinent.) I may well have got some of the following wrong - I am just learning about TopicMap.

A TopicMap distinguishes two types of "thing": things internal to the map, and things external. Anything inside the map is called a topic, and almost everything is inside the map. Unlike in RDF, URIs are not topics, and are external to the map. They are identified with topics using subject indicators, and any topic can have as many or as few indicators as desired. This implicit identification of multiple URIs can only be achieved in RDF using statements, as is associating more than one URI with a resource.

The closest match to RDF statements is the TopicMap facet. A topic has its language, applicability, security, etc. specified by facets. However, the facet value is not identified with a topic, while in RDF the object of a statement can be a resource, so a TopicMap facet is equivalent to an RDF statement with a literal as its object. XTM removed facets when it became clear how to replicate them with associations.

Associations look like statements, except (a) they are bidirectional, and (b) they are multi-partite, not tripartite. Every association has an association type, and every topic involved in an association has an association role.

  • Instead of saying <dog, is-a-kind-of, animal> and <animal, has-kind, dog>, one might say that dogs and animals are associated, that the association is of type "kind", that the role of dog in this association is "instance", and the role of animal is "general".
  • Instead of saying <job offer, employer, my dad>, <job offer, employee, me>, <job offer, offer, ten bob>, <job offer, date, Tuesday>, one can say that my dad, me, ten bob, and Thursday are associated, that the association is of type "job offer", and that the roles of those associated are employer, employee, offer and date, respectively.

Occurrences describe resources pertinent to a topic. In RDF, this would be achieved with a specific statement connecting the resource of the topic with the resource of the occurrence.

So TopicMaps cover ground with facets, occurrences and associations, while RDF uses statements, implications and reification.

In conclusion, it seems to me that TopicMaps and RDF are very much aligned. The basic structures are different, but they build up to the same point, and teaching a computer to understand enough about one to be useful will take the same level of effort as teaching it the other.

The main benefit of RDF in my eyes is that it has the simplest storage demand you could want - only resources exist. While the rich complexity of a TopicMap will be built on this, all that needs to be stored is URI, literal and statement information about a resource. In PeriPeri, that means a relational database with just seven fields suffices. It also perfectly matches the MetadataSyntax. However, some reinvention of the wheel is required to create non-addressable subjects, and when the amount of stored meta-data grows large, the storage must adapt to usage anyway.

Chris, I think it's interesting (and accurate) that you should equate RDF and TM's facets, as they are very similar. Facets perform the function of attaching metadata to an addressable resource, which is what RDF does. Facets are described in the ISO standard for Topic Maps, but not in XTM (the XML syntax). Why? Because TM facets are basically RDF, and when we wrote XTM we realized we didn't need to explicitly specify facets, as one can express them by assigning Topic occurrences (which can be inline data or links) as metadata to Topics. But that's the limit of the overlap between TM and RDF, the essential triple. As you note, the TM graph is quite a bit more complex. Sadly, TM facets are misnamed and almost didn't make it into the standard; there's some history behind this. Martin Bryan, one of the editors of the ISO standard, wanted full-blown Faceted Classification facets in TM. It wasn't to occur, probably due to the complexity of the solution and the fact that FC facets are not really part of the Topic Map paradigm. So what remained in the standard is the RDF-like "facets", which should have been renamed name-value properties or something. There's one other important difference. There are three kinds of links in XTM (this is described better and in more detail in the XTM 1.0 spec.):

<resourceRef>
A link to a resource, where the subject of the link is the resource itself.
<subjectIndicatorRef>
A link to a resource, where the subject of the link is the subject of resource, not the resource itself.
<topicRef>
A link to a Topic, where the subject of the link is the subject of the Topic.

The last two are identical semantically, except that the <topicRef> must always point to an XTM <topic>, whereas the <subjectIndicatorRef> will generate a Topic in the graph. Now, we are talking syntax here, but the importance of these link types is that it keeps what one is talking about clear. In RDF, one talks about URIs themselves as "meaning something", which is why the W3C has been arguing for years. TMs get around this problem by alleviating poor URIs of that burden, talking instead about Topics, which are objects acting as proxies for subjects. This comes closer to normal knowledge theory, in that things do have a subject, both online and in the meat world. A Topic in a Topic Map acts as a binding point for characteristics to be attributed to that subject, e.g., names in various natural languages, occurrences of the subject (Bill has three kids, his three children are occurrences of the subject "Bill's kids", etc.). And yes, we do find ourselves in the realm of ontologies, in that when we try to make statements about reality we are literally "making ontological commitments," statements we believe to be true. Every element/statement in an RSS document is an ontological commitment.

In summary, yes, there is an overlap between RDF and Topic Maps in that TM facets are a means of creating triples. But Topic Maps are really concerned with representation at a higher level than that. Not quite to OWL, but maybe halfway between RDF and OWL. By adding some semantics to XTM one can emulate OWL. (That's kinda what my project Ceryle does.) – MurrayAltheim

I'm unclear what the problem with using URIs is. I could emulate topics by using local URIs (#…) in my XML/RDF (or unnamed ones in an internal RDF store). Is there a problem with that approach I haven't seen?

I don't see the equivalence. The concept of a Topic in Topic Maps (i.e., within the paradigm or model of Topic Maps) is entirely a different concept than any part of RDF. My point written above is that RDF is essentially the "facet" part of the ISO Topic Map standard, nothing more, a way to attach metadata to resources. If you were to build up a model that emulated all of the model and functionality of Topic Maps you'd have, well, Topic Maps. But it's not simply a matter of hooking up a bunch of URIs, which is where a lot of people (and as I've said above, people who should know better) mistakenly believe that the mere connection of a graph somehow creates a Topic Map. There are a few people in the Topic Map community who are marketing that idea, but it's not correct. Topic Maps are more than the simple sum of the parts, even if all the parts are there. The originators of the Topic Map paradigm initially tried to describe the difference between what one could do with a graph-plus-URIs and Topic Maps as a processing model, but it turned out to be a more profoundly different situation than that. It's akin to saying the human body is composed of a bunch of chemicals and chemical processes, but we know it's more than that (without trying to sound too mystical about it). But admittedly, this is hard to describe. A lot of people think you can represent the graph structure of Topic Maps in RDF. You can. But you don't have Topic Maps. You still need to crank the platform up into the storm and wait for the lightning to strike. – MurrayAltheim

Murray, I don't understand yet why RDF and Topic Maps are so dissimilar. The only thing I understand so far is that Topic Maps can distinguish between a URI, and the thing that the URI is naming. But what else is different? Could you provide small, concrete examples of things that you can express or do with Topic Maps that you can't express or do with RDF? Thanks

I'd still like to hear Murray's answer to that question, but I've been reading Living with topic maps and RDF (which supercedes "Topic maps, RDF, DAML, OIL"), and I'd like to write down my tentative partial answers as I go (I've read until the end of the section "Comparing the technologies", and I'm not sure if I'll read the rest, although I'd like to). Please bear in mind that this is my half-baked understanding from reading one web page, and that I have had no real experience with either topic maps or RDF.

In general, topic maps are a "higher-level" or maybe a "heavy weight" language compared to RDF. That is, it defines semantics for expressing certain things that RDF just doesn't define any way to express. You can still use RDF to express these things, in many cases by adopting an additional RDF vocabulary or an RDF schema which gives you new symbols which have the semantics you desire. However, in some cases this makes it awkward to express these things in RDF even though they're easy to express in topic maps.

Things that are awesome about RDF (compared to topic maps):

  • simpler; there are fundamental types of objects to deal with; mostly, there are just RDF triplets (statements), URIs, literals, and language properties of literals. With topic maps, you have topics and associations. But then within topics, you have special properties: names, occurrences, scopes. Within associations, you have roles.

Things that are awesome about topic maps (compared to RDF):

  • "thingification" or reification, that is, making a statement about a statement, is easier. Example: if you say "I like pears" and then say "that statement is an opinion".
In topic maps, you can just create a new topic node which "points to" the statement that it represents (I think). "I like pears" is an association of type "like" between "I" and "pears". You create a new node which "points to" the association "I like pears". Then you can create an "IS-A" association between that node and "opinion". Apparently in RDF you must remove the triplet like(I,pears) and replace it with 3 statements: subject(statement1,I), object(statement1, pears), predicate(statement1, likes). Only then can you say isa(statement1,opinion). This makes it more confusing to traverse the graph, because if you want to go from the resource I to pears, you don't just go through the node like(I,pears), you must go through subject(statement1,I)</code to the resource <code>statement1, and then go through object(statement1, pears) to the resource pears
  • qualifications (like "the earth is flat" <– says Bob) are easier to do, because reifications are easier to do
  • the semantics of the "name" relation (i.e. here is person A, and their name is "Bayle Shanks") is defined
  • when you refer to a URI, you can make a distinction between "I'm pointing to the document found at that location" (using it as a URL) and "I'm using this address as a way to refer to an abstract concept or object in the world" (using it as a URN). That is, the distinction between referring to a resource itself and using the resource as a placeholder to represent something in the outside world can be made.
  • saying "Tom buttered the bread" is the same as saying "The bread was buttered by Tom". In RDF, you'd have to have two separate relationships, buttered and was-buttered-by, and then use a schema to say that they are inverse relationships.
  • topic maps can handle N-ary relationships, not just binary relationships. For example, "Tom buttered the bread with a knife" – buttered(Tom, the bread, a knife)
  • types of objects are just normal objects. if you have two "types", such as cars and vehicles, you can express that one is a subtype of the other by connecting them with an "IS-A" relation, just the same as you would connect two non-types. By contrast, in RDF, you use the rdfs:subClassOf property, which is part of RDF Schema, but not part of RDF itself.

As you can see, there are many more awesome things about topic maps. But the awesomeness of "simplicity" in RDF might overwhelm these. Or does it? Maybe RDF ends up being more complicated if end up using it to express things that topic maps handle simply.

I sort of feel the thing to do is to develop an "RDF 2.0" which is more like RDF than like topic maps, and which still uses special vocabularies to define most special semantics, but which handles the things that are really clunky to do otherwise.

I'm sort of thinking:

  • have a special "core vocabulary" which defines the binary relations "name", "said by", the unary relation "this is a document whose address is its URI", and others
    • Qualifications/scope and names are then handled using ordinary statements and this vocabulary.
    • The distinction between "using URIs as placeholders" and "using URIs to refer to their documents" will be resolved as follows: by default, a URI is being used as a placeholder. If you want to refer to the document at that location, you must attach the special unary relation "this is a document whose address is its URI" to it
  • use N-ary associations, with roles, rather than triplets
    • but provide a standard/distinguished way to "simplify" a collection of RDF 2.0 statements into RDF 2.0 triplets, and vice versa
  • simple thingification (reification): allow statements to be referenced directly by adding another statement and a special pointer from that statement to the original one.

Basically this gives you all of the awesome stuff in the topic map list, but preserving much of the simplicity of RDF because scopes and occurences are no longer special.

The main complexification of "RDF 2.0" vs. RDF would be by using associations with roles rather than just triplets. But it seems to me that when you want to say something that is an N-ary relation, saying it the triplet way is just so longwinded that it's worth it. In addition I do think the redundancy problem with buttered(Tom,bread) vs. was-buttered-by(bread,Tom) is an indication that

Nevertheless, because there is a distinguished/standardized way to "simplify" a collection of statements into triplets, I think not much would be lost (if implementations prefer triplets, they could just use the execute the simplification mapping at the beginning and end of the computation)

I'd like to learn more about the already-existing mappings between topic maps and RDF before really deciding what my ideal compromise would be, though.


CategorySemanticWeb?

Define external redirect: CategorySemanticWeb

EditNearLinks: MetadataSyntax PeriPeri

Languages: