Remembering the Future

15 Dec 2003 Guy Lukes To start with, I must say that I am not a topic map expert. But in my resent attempt (with Bryan Thompson) to implement a topic map in a relational database, I was shocked to discover that the underlying database structure was only a slight modifications of RDF triples. The Subject is the a-node The predicate is the r-node The object is the x-node All that was missing was a c-node to reify the triple and a set of PSIs to implement subject roles (predicates/r-nodes/roles) to support topicmap merging behavior. This gives you the simplicity of the semantics free RDF triples, with the power of topicmap subjects and merging (if you need it), plus the ability to leverage all work that is going on in the RDF community. Is there something I am missing, that is going to cause be problems down the road? Jan Algermissen It is true that a topic map graph a la Reference Model can be represented using RDF triples but that does not take you very far, because your RDF triples would only represent the particular graph structure an carry no information about the original relationship you are actually representing. You'd still have to put that information somewhere, it is not inside the RDF! If you just need a graph representation technique to store the assertion structures, I suggest you use relational tables and not RDF (which is overly complex for this sort of thing). Here is what I mean by 'relational table': Suppose you have the relationship "Jack is father of Jim", which gives you the following assertion:

                    T
                    |
             R1     |      R2
             |      |      |
x1[jack]-----C1-----A1-----C2-----x2[jim]

T: assertion type father-son
R1:          role father
R2:          role son

Mathematically, an assertion can be understood as an ordered tuple of the form (T,A1,R1,C1,x1,R2,C2,x2,...Rn,Cn,xn) (Note that it is the order that preserves the structure) Here is where relational tables are handy (and extremely efficient for storage) because you can 'translate that tuple into a row in a table representing all assertions of type T: Assertion type T: A | R1-casting |R1-player | R2-casting | R2-player | ---+------------+----------+------------+-----------+ A1 | C1 | x1 | C2 | x2 | <--- this is the above assertion Patrick Durusau Both RDF and topic maps have a substantial amount of work devoted to them and I don't see them as even competing technologies. They use different underlying conceptions of how to organize information and as a result work best in particular and often differing domains. Not trying to start an RDF vs. topic map flame war so note I will not be responding to any posts of that sort. Sole purpose was to point out the the two are distinct and nothing more. Which one you choose depends upon your domain, which is more familiar, etc. Jack Park Patrick, They may be distinct, but that doesn't mean you cannot have both. It is possible to build a triple-store database and a set of mappers such that topic maps can be persisted that way. If the same database is serving other applications, you avail the opportunity for discovery directly from the database itself. Lars Marius Garshol Well, what you describe here does not have any obvious resemblance to topic maps as they are described in ISO 13250:2000 or ISO 13250:2003, nor to anything that is currently scheduled to go into the next edition of ISO 13250. In short, it's not clear that what you describe here could be called topic maps. It certainly does not follow any published standard by that name. Guy Lukes Lars, I am afraid I have misrepresented my goals. I am not trying to " implement a topic map in a relational database". What I am trying to do is develop a data store, for which a variety of input processors can dump data. These inputs could be in RDF, XTM, or more typically some XML language like RSS. The idea is not to directly support a topicmap application, but to provide a data store that "marks all the distinction boundaries for incoming data" and allows merging based on identity. The goal of these input processors is to provide a common repository for heterogeneous data that preserve the identity based information within the input. Output processors could then be written that could cast/collapse this data into a (typically XML based) output format (based on the distinctions that make a difference) and that supports a variety of semantics unanticipated by the input source. These output formats could be XTM, RDF, merged RSS Feeds etc. and involve a great deal of filtering and aggregation. A round trip from XTM to data to XTM would probably not preserve the original syntatic structure (although a system like that is certainly possible). See XML vs RDF NxM vs N+M http://bitsko.slc.ut.us/blog/xml-vs-rdf.html Thomas B. Passin Consider this thought experiment. Take any RDF triple, and replace it with a topic map association with exactly two role-players, where there is one role called "subject" and one role called "object". This, I suggest, is essentially equivalent to the triple. Notice that the roles are implicit in the RDF version, so they cannot be talked about within RDF itself. The topics that would play the corresponding roles as the subject and object could be given an id equal to their RDF URI. The subject indicator - well, who knows? Thompson, Bryan I think that the granularity of Guy's comment was directed at a normalized RDBMS schema that encodes the assertions found in a topic map document. Of course the behaviors (semantics) of those topic map assertions still need to be implemented for a processor to be a "topic map processor". Consider a service that translates a topic map document, e.g., XTM, into this internal model and the re-serializes it, e.g., as a "consistent topic map" using the XTM syntax. I would say that this is a "topic map processor". Guy made the point that the internal model for the processor could be a set of reified triples. Perhaps this was one of the points of the topic maps reference model (or the topic maps processing model) -- that you can re-represent the XTM syntax as a set of assertions using an ARCx (assertion node, role node, casting node, player node). In this context you can see how the ARCx model can be readily aligned with the RDF model as a reified triple, which is what Guy was suggesting below.