[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: PMTM4 templates vs. TMCL (was: Re: [topicmaps-comment] RE: OASISvs W3C)
(I don't like the subject line of this note. PMTM4 and constraint languages are orthogonal issues. There is no "PMTM4 vs. TMCL [Topic Map Constraint Language]". At least not in my mind.) Lars Marius Garshol <larsga@garshol.priv.no> writes: > To summarize before I begin to address the different > issues, we seem to have identified three issues > related to TMCL: > 1. shall TMCL constraints be part of the topic map? > 2. shall TMCL constraints be expressed using the > association template mechanism of PMTM4? > a) are PMTM4 association templates powerful enough > for what is needed? > b) does this use of PMTM4 association templates > introduce dangerous structural issues into the > topic map architecture? > I start by discussing 1., which SRN seems to have > addressed, then move on to 2.b), which I thought he > intended to address. > * Steven R. Newcomb > | > | PMTM4 merely explains how sets of constraints -- > | constraints that might be expressed in TMCL -- > | actually participate in the Topic Map as topics. > This immediately raises the first question. Should > the topic map schema be part of the topic map, or > should it not? This can be argued both ways, and I > think we're not yet ready to draw a conclusion. I'm surprised. I've never heard any argument suggesting that any that subject that is a class of anything that's in a topic map be anything other than a topic. I've never heard any argument in favor of allowing a role subject, for example, to be represented as anything other than a topic. Roles would have to be accounted for in any schema for a topic map. Surely the purpose of any sort of schema is to establish classes of things. For me, at least, the idea that instances of things in a topic map can have classes that somehow magically exist but are not themselves topics is absurd. The effect of such a rule would be to prohibit the topic map from making assertions about them: from explaining them, from defining them, from showing other instances of them, from subclassing them, etc. etc. It would place these things out of reach. Indeed, it would falsify the primary claim of topic maps, that literally anything that is relevant to any subject is automatically aggregated around that subject's identity points (i.e., that subject's topic). If the classes declared by topic map schemas are exempt from this rule, then the Topic Maps paradigm is well and truly broken and wrong. You claim that the question of whether a schema should appear in the topic maps that it governs can be argued both ways. OK. Please state, for the record, exactly what are the *advantages* * for users, * for single authors, * for sets of collaborating authors, * for topic map aggregators, * for topic map owners, and * for topic map systems implementers, of *not* establishing, as part of the Topic Maps standard, exactly how the subjects that are the classes established in a schema shall appear in the graphs of the topic map that they govern, in such a way that * these classes are topics, like any other topics, and * these class topics are directly and specially related to the instances that they govern, and * the instances of things that they govern are directly and specially related to the classes that govern them. I'll be interested to see how you argue that these are not fundamental requirements for any reasonable model of what topic maps mean. We can't make our model account for something that isn't part of our model. > | In any case, even leaving PMTM4 aside for the > | moment, the specification of how the role-player > | constraint topics are connected to the associations > | that they constrain is quite orthogonal to the > | issue of how those constraints are expressed (e.g., > | in TMCL). > Agreed. > | The constraints that will be established by TMCL > | expressions will also be reifiable as topics. > This will necessarily be true, since they will have addresses. > | Neither the Topic Maps paradigm nor PMTM4 constrain > | how the subjects of topics can be expressed > | ("indicated"). TMCL is going to be a perfectly > | good way of expressing such subjects, and, I hope, > | better than most. > That has to be the goal for all of us. > | I would be deeply disappointed in the outcome of > | the TM standardization process if we abandoned one > | of the cardinal requirements that has always driven > | the design of TMs. That requirement is that any > | subject that affects the meaning of a topic map > | must be reified as a topic in that same topic map. > I agree that the topic that reifies the class of > which other topics are instances must be part of the > topic map. This is not the same as requiring the > constraints on that class to be part of the topic > map. I think you misunderstood me. I did not propose to require that each constraint be the subject of a topic. I was only making the routine observation that constraints, like everything else, can be the subjects of topics. > Let's say that there is a constraint which states > 'all topics which are instances of the class > "country" must have a base name in the scope > "native-name"'. Does there need to be a topic in the > topic map which represents this constraint? (I'm > trying to make sure we are arguing about the same > thing here.) If this is necessary, why is it > necessary? The answer to your question is, "No. I do not propose that there must be a topic in the topic map that represents this constraint." What PMTM4 proposes is quite different from what you evidently think it proposes (obviously, this needs to be made a lot clearer -- thanks for helping). PMTM4 proposes that the set of constraints on any role-player be the subject of a topic whose subject is a class of which the role-player must be an instance. But I have some questions for you, now. It seems to me that your example of a constraint statement is not very explicit about exactly what it's constraining. Suppose there is a topic that violates this constraint: it's an instance of the class "country" that doesn't have a base name in a scope that has the "native-name" topic as one of its components. A. Is this constraint really just a constraint on the class-instance association that establishes that this topic is a country? In other words, does the existence of this class-instance association trigger the validity check that finds this violation? In still other words, does the fact that "country" plays the class role require that the topic that plays the "instance" role participate in certain other relationships? If so, I say "Hallelujah." This seems to me a sensible, simple, useful, and implementable approach, at least for the near term. B. Or is this constraint an example of a far more general notion of constraint. I'm imagining this "far more general notion of constraint" to be something like this: Each constraint statement imposes its constraint on the entire topic map. Each constraint statement describes a prohibited constellation of relationships and/or lacks of relationships. If such a constellation of relationships exists, no one relationship within that constellation of relationships is considered to be the thing that is violating the constraint; it's the combination of relationships and lacks of relationships that is what's being prohibited. The B approach is tremendously more powerful than the A approach for detecting complex problems and imposing very sophisticated constraints. But I still think we should start with the A approach. If we start with the B approach, we will endanger our chances of success. Here, I'm speaking with the sad voice of experience, and out of a genuine concern for the success of TMCL. I'd much rather we did something relatively easy that results in a standard that succeeded in the marketplace, than that we did something extremely difficult that resulted in a standard that failed in the marketplace. It's an easy choice to make, really. I think we should lay an early, simple, sturdy foundation on which we can build greater power and complexity in the future. I believe that the best way forward is to begin by providing a way to constrain the instances of relationship types. It doesn't make sense to begin by constraining topics. The only meaningful constraints we could impose on topics would be *constraints on the set of relationships in which a topic plays various roles*. This would be a constellation of relationships. It would be Approach B, basically. We're not ready to impose useful constraints on *sets of relationships* until we have demonstrated that we can impose useful constraints on *a single type of relationship*. We must learn to walk before we can learn to run. Once we can constrain specific relationships, we'll be in a position to impose constraints on sets of relationships. > | * recognized player of role classes are topics <<-- this is the one > | we're talking about. > > This is only true while you are wearing PMTM4 spectacles. > Non-believers don't see it the same way. I hope you're not intending to imply that PMTM4 distorts one's vision of what topic maps mean, or that PMTM4 represents some sort of religious dogma that beclouds the minds of its adherents. I shouldn't complain about your remark, though, because it has inspired me to say a few words about my own path to true enlightenment (for me, enlightenment is, of course, PMTM4). I have always thought that topics were what topic maps were all about. And it's true that topics are what topic maps are all about! Furthermore, there are millions of people who can understand topic maps precisely because the topic-centric view is very close to their own established patterns of thought. I myself am such a person. But the topic-centric perspective on topic maps does not by itself reveal the fundamental simplicity of the structure of topic maps. It conceals the fact that topics are *related* to their names, and they are *related* to their occurrences, in exactly the same way that they are *related* to other topics. It conceals the fact that there is a fundamental and necessary distinction between subject-constituting and subject-indicating resources. It conceals the fact that scope is only and entirely about relationships. I know that it conceals these things because I didn't see them for years, and, believe me, I was looking! (If this confession reveals that I'm not really very bright, so be it.) There is another perspective on topic maps that is at least as valid as the "topic-centric" perspective: the "assertion-centric" (or, if you prefer, "association-centric") perspective. PMTM4 reflects the assertion-centric perspective. Topics have characteristics because of the assertions that give them those characteristics. Topics themselves are nothing more or less than nexuses -- arbitrary addressable pieces of subject-indicating or subject-constituting information -- about which assertions are being made. The assertions are where all the action is. The assertions are the roads on the map. I came from the topic-centric perspective to the assertion-centric perspective. That's why PMTM4 is, for me, enlightenment. Many others are different from me. They have found the Topic Maps paradigm incredibly liberating because it has brought them from an assertion-centric perspective (such as the RDF perspective, or a hyperlink-centric perspective) to a topic-centered one. True enlightenment is to fully grasp and enjoy both perspectives simultaneously. *Both* perspectives are *essential*. The question, "Are topic maps about topics, or are they about assertions about topics?" is really a waste of time and energy. Which brings me to my dark suspicion. I suspect that the real issue about TMCL boils down to this: Should TMCL begin by supporting the topic-centric perspective or by limiting its initial support to the assertion-centric perspective? Ultimately, we must have one or more constraint languages that will serve both perspectives. You'll get no argument about that from me. All the same, it's very clear, at least to me, that we must support the assertion-centric perspective before we can support the topic-centric perspective. > The proposed PMTM4 has _two_ data models: a core > model, and a model that corresponds to topic maps as > we know them (let's call it the Standard Application > in this thread). Association templates, as far as I > have understood, are used to build the Standard > Application. This means that if TMCL is to use PMTM4 > association templates to define constraints the same > constraints that were used to define the topic map > data model will also be used _inside_ the model built > using them. No. First of all, PMTM4 is the core model, full stop. True, it has a couple of association templates in it -- but only the ones needed to define association templates. Yes, this is recursive. No, this doesn't cause a problem. It's merely a bootstrap technique, and it works. It's analogous to using a C++ compiler that's written in C++ to compile itself. It's done all the time, and it's a very good practice, for many reasons. We have also proposed that we standardize certain association templates as the Standard Application. These templates are not part of PMTM4, and PMTM4 does not depend on them. If PMTM4 is adopted, the Standard Application, and all other applications, will depend on PMTM4, but not the reverse. > This corresponds to having ISO 10303 use some schema > language (let's call it IMPRESS[2]) to define how > entity instances are related to their characteristics > (in this case their attribute values and their > entities). The data model of ISO 10303 will then be > built using IMPRESS. ISO 10303 also has a schema > language which is used to define entities. The > situation where PMTM4 association templates are TMCL > corresponds to using IMPRESS both to define the basic > model, and also to define schemas for applications of > ISO 10303. This means that the same thing that is > used to say "entity instances must have entities" > would be used to describe the structure of entities. > Instead, what ISO 10303 does is to define the basic > model without using any form of schema > language. There is a schema language for ISO 10303, > called EXPRESS, but this works entirely _within_ the > already defined data model, and cannot change it in > any way. RDF, RDBMSs, SGML, XML, LDAP, and so on and > so forth, all follow the same approach. > I'm sorry if this was hard to understand. I've done > my best to try and explain, but I find it difficult > to explain clearly. I appreciate what you're saying, I think. The topic maps paradigm is different from all these other standards and formalisms. It claims to do -- and it actually does -- something that none of these other approaches were attempting to do: provide a unifying framework for literally *all* assertions about literally *everything*. Therefore, the paradigm must "eat its own dog food", as the dreadful expression goes. The Topic Maps paradigm must fully encompass knowledge of itself, in a fashion which is completely consistent with its encompassment (if that's a word) of every other kind of thing, and, at the same time, in a fashion which reflects the special issues surrounding detailed self-knowledge. PMTM4 shows how Topic Maps eats its own dog food. So far, I don't believe anything else that has been proposed truly does. I'm open to the possibility that another model can also do this trick. I'll certainly resist the adoption of any model that doesn't eat the dog food. If nothing else, PMTM4 demonstrates that the dog food can be eaten. -- Steve -- Steven R. Newcomb, Consultant srn@coolheads.com voice: +1 972 359 8160 fax: +1 972 359 0270 1527 Northaven Drive Allen, Texas 75002-1648 USA
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC