Another Word For It Patrick Durusau on Topic Maps and Semantic Diversity

March 22, 2010

A Common Model

Filed under: Topic Map Software — Patrick Durusau @ 8:37 pm

I had someone tell me today that topic map software can’t be written without common model.

That came as news to me. All these years I had thought:

  • XML documents can have different DTDs/Schemas
  • SQL databases can have different schemas

Now I find out that XML and SQL software isn’t possible without a common model.

But XML and SQL software exist and continues to be written.

I wonder what their authors know that the common model advocates don’t?

5 Comments

  1. Patrick, please be aware that there are common models behind both technologies.

    For XML you have the XML Information Set (http://www.w3.org/TR/xml-infoset/) and for SQL databases you have at least the relational algebra.

    There is NO standard without a common model in the background. You can’t standardize without the agreement on a shared understanding of the “thing you want to standardize”. This even holds for Topic Maps. You need a common model as base.

    We can discuss whether the current TMDM is the perfect common model, but I have the impression that for a lot of applications the TMDM seems to be very feasible. But I can also imagine applications which needs more flexibility, esp. in terms of subject identification resp. equality.

    Comment by Lutz Maicher — March 23, 2010 @ 4:53 am

  2. Lutz, I will let readers compare the XML Information Set and relational algebra to the TMDM for themselves to determine the flexibility of the “common” model. That really doesn’t merit further comment from me.

    Although, as I said in In Praise of Legends (and the TMDM in Particular), legends are necessary for blind interchange of topic maps with an expectation of correct processing.

    I too think the TMDM is useful for a wide variety of cases.

    And I think the TMDM is easy to extend to deal with complex subject identity without the use of TMQL. More on that in a later post.

    The question of standards depends on what you want to standardize. If you want to standardize fixed data processing models, I suppose, but that isn’t terribly interesting. That isn’t what the XML standard did, unless you think it has a fixed model at the same level of granularity as the TMDM?

    I have long maintained the TMDM and other legends are absolutely necessary to make the TMRM useful. I simply resist the notion that any one legend is going to be the universal model for all subjects.

    What is so terrifying about that position?

    Comment by Patrick Durusau — March 24, 2010 @ 4:31 pm

  3. An addendum:

    Lutz, the real difference in our positions is that I don’t think there is such a thing as the ultimate data model. Several times every year I am sure someone comes up with the new data model. Some of them catch on, most don’t. For years the SQL folks were wannabes, then were on top and now are being challenged by the no-SQL folks.

    But the point is that if we can create legends (of which the TMDM is one) that allow us to know what subjects are being represented by those data models and how to identify them, then we stand some chance of both sharing and re-using data without having to convert to yet another new data model. And, we may be able to combine data from several data models.

    BTW, I also don’t think there is a universal method for subject identification, just to get that out of the way as well. There are methods that work better for some communities than others.

    Rather than telling people that I have the best data model or the best method for subject identification, I would rather ask them what data model and method of subject identification best meets their needs. Which I can then use to add data from other data models and other methods of subject identification.

    I think focusing on the needs of users, as novel as that may sound, in the long run is a better strategy.

    Comment by Patrick Durusau — March 24, 2010 @ 7:52 pm

  4. > That isn’t what the XML standard did, unless you think it has a fixed model at
    > the same level of granularity as the TMDM?

    That really is what I think, and I suspect Lutz, too.

    > I simply resist the notion that any one legend is going to be the universal
    > model for all subjects.
    >
    > What is so terrifying about that position?

    Nothing. I just think you are being misleading when you compare the TMDM with a SQL/XML schema, instead of with the relational model/XML infoset. It’s more appropriate, and a lot more useful!, to think of it as the latter.

    Comment by Lars Marius Garshol — March 28, 2010 @ 4:05 pm

  5. Interesting. I will have to think about that proposition for a while.

    My initial reaction, mind you only an initial reaction, is that neither the relational model nor the XML infoset define any content models. The TMDM, on the other hand, does. That may not be a meaningful distinction but it is one that comes to mind.

    And, I am mindful that because the TMDM does define content models (at least in my view), that enables blind interchange.

    Hmmm, for comparison purposes, would we say that the XML infoset enables blind interchange in any particular situation? Granting that once you have a schema and an instance governed by that schema, blind interchange becomes possible, but that is XML infoset + Schema. Yes?

    I have been reading (off and on), Jeffrey Ullman’s Principles of Database Systems (1980) In “The Three Great Data Models” (Chapter 3), he compares relational, network and hierarchical models. At that time, most commercial systems were either network or hierarchical models.

    If what you say is true about the TMDM, then that should also be true when compared to the network and hierarchical models. As I say, I haven’t thought of it that way but there should be common characteristics that place something in one camp or the other. (or perhaps somewhere in between)

    Comment by Patrick Durusau — March 28, 2010 @ 6:33 pm

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress