SUO: BUG Gotcha! (was Architectures for Intelligent Systems)
I think I have found the bug case which prevent archiving:
Two messages from the same source, answering the same message ID
arriving at about the same time, are confused by the MHonArc as
duplicate irrespective of the content and one is NOT archived.
It occurred to my message below, just like one from Matthew days ago.
Who is in charge of MHonArc maintenance for the site?
Cheers.
>
> Dear Matthew,
>
> Quoting you from: http://suo.ieee.org/email/msg08341.html
>
> > > No, I, for myself, would trust more a purely syntactical process that
> > > will identify leaf nodes in a tree of concepts that would have been
> > > setup according to some parsing + semantic rules (however crude).
> >
> > MW: Well this is the key difference between us, since I would not.
> >
> > MW: History suggests that you can only automate what you first
> > understand. I.e. if you (someone) can't do it reliably by hand, you can't
> > expect to do it reliably automatically.
>
> Not entirely true, by "tinkering" with an automated procedure you may
> *discover* and then *understand* structures and relationships that would
> never show up in a purely "manual" processing.
>
> > > Of course, but I just mean that the lattice of "basic" concepts and
> > > attributes will not be very "hairy" nor of much "height".
> >
> > MW: How much is not much, a subtype/supertype hierarchy of 5, 50, 500
> > levels?
>
> The exact figure does not matter, more is the fact that the lattice of
> "basic" concepts is much less complicated than the lattice of *all*
> concepts (by which factor I cannot tell now either) which makes it
> more "intuitively" understandable by the end users.
>
> Intelligibility is a VERY IMPORTANT point about which I have not yet
> argued much, but I really value that.
>
> > > The response is above, however, as I did not check yet, it may be
> > > that some existing formalisms are "intrinsically" unamenable to
> > > the above capability.
> >
> > MW: I don't see it working then. Your approach to integration would
> > seem to be that concepts with the same attributes would be the same
> > concept.
> >
> > MW: Unfortunately this is not true. If you take something like the
> > humble pump, you will find that the important attributes about it
> > are different at different stages, during design, manufacture,
> > delivery, installation, operation, maintenance and disposal. So
> > when you come across pump in these different contexts you are
> > going to get some different view points (rather like the famous
> > story of the 3 blind men and the elephant).
> >
> > MW: It is already a difficult task to integrate the data for a pump
> > thoughout its life when you KNOW that it is all about the same thing.
>
> You really need to check how the |><| closure works.
>
> Excerpt below from: http://suo.ieee.org/email/msg08132.html
>
> > Reminding the definitions from Hillman (also from Wille), we can state
> > that the barebones of an ontology is just a relation R, i.e. a subset
> > of the product XxY, where:
> >
> > - The elements of X are all the "things" in the universe actually known
> > to the ontology "owner". In CG parlance these would be individual markers.
> > Some subsets of X are the 'extents' of the known 'concepts' (Hillman)
> > as well as the 'extensions' of the known 'words' (Peirce) or of what
> > Peirce call 'true symbols', that is concepts with compound names.
> > But not all subsets are extensions of proper concepts or true symbols.
> >
> > - The elements of Y are all the 'attributes' (common parlance) or 'predicates'
> > (Hillman) or 'characters' (Peirce) actually known to the ontology "owner".
> > Some subsets of Y are the 'intents' of the known 'concepts' (Hillman)
> > as well as the 'comprehensions' of the known 'symbols' (Peirce).
> > But not all subsets are comprehensions of proper concepts or true symbols.
> >
> > According to Hillman what makes a subset a proper concept is the fact that it
> > is closed under <||> if taken from X and closed under |><| if taken from Y.
> > (duality allows to halve the amount of demonstrations, see Hillman's)
> >
> > Where: |> A = {y : (x ,y) in R for all x in A}
> > <| B = {x : (x ,y) in R for all y in B}
> > <||> A = {x : (x ,y) in R for all y in |> A}
> > |><| B = {y : (x ,y) in R for all x in <| B}
>
> ---------
>
> > > Ah! Yes, the famous 4D vs 3D debate, I will have a look.
> > > Is there anything similar and as nasty as that outside
> > > spatio-temporal ontologies?
> >
> > MW: It happens nearly everywhere, all the time. The problems above
> > arise from the different ways that change can be seen. These are not
> > the only two. I know of at least a couple of other ways.
> .../...
> > MW: I still do not see how you will be able to automate the generation
> > of the mapping between them, though I'm sure there is one.
>
> OK, for this *I* will have to check, but I am optimistic with my position.
>
> > > Within the broker, given the semantic is *totally* formalised, it
> > > should be possible to devise that kind of conversions automatically
> > > thru the inference engine, but as I know just as well as you, this
> > > will really tax its capabilities for non trivial cases.
> >
> > MW: Again you seem to be saying that if you have been able to define
> > an ontology in terms of some basic set of semantics then you can create
> > the mapping between them. Yes of course. This is easy.
>
> I am glad you agree at least on that (modulo the performance requirements
> of the inference engine which, I think, may not be trivial either)
>
> > The difficult bit is creating some set of initial semantics (with well
> > understood, agreed and defined meaning) and creating the definition of
> > your source ontolgies in terms of that set of semantics.
> >
> > MW: If you actually read ISO 18876 you would see that.
>
> I am not really worried by the "initial semantics" because, strangely,
> there will not be that much "meaning" in it, mostly rules about how
> the names, concepts and properties are to be shuffled around and that
> is well within the capabilities of the inference engine.
>
> What I mean is, that though the "meanings" can be puzzling when viewed
> from a philosophic, metaphysic, semiotic, etc... perspective, it is no
> more a problem if you can define what you want not in terms of "meanings"
> but in terms of (somehow) syntactic transformations upon the internal
> representations, for which *you* can figure out if the output of a rule
> does result in the change you meant to get.
>
> > > A meta-remark: You seem quite "scared" by unknown territories and
> > > not willing to advance until you are fairly sure that *all* problems
> > > will be solvable.
> >
> > MW: Rather when I do an experiment I change the variables one at a time,
> > rather than all simultaneously. I think you have too many unknowns in
> > what you are proposing, and would suggest small steps before big leaps.
>
> Only a big leap will take you over a large ditch...
>
> > > There is always the possibility of a hardship, the case you just need
> > > will not work, but that's life, isn't it?
> >
> > MW: Again, the virtue is in giving yourself the opportunity to learn from
> > your mistakes.
>
> That's not too kind of you to assume I will fail ;-)
>
> > > Right! There are three solutions:
> > >
> > > - Your "philosophy" can be mapped back and forth to the
> > > broker "philosophy"
> > > and your description of it is precise enough to allow it to do that!
> > > - Your problem domain is still amenable to the broker
> > > "philosophy" and,
> > > if you really need your work done, you convert to the
> > > broker "philosophy".
> > > - You stay out of the game.
> >
> > MW: Again, you are really just saying that it will be easy, once the
> > hard bit has been done.
>
> Tautological!
>
> > > Probably not so bad, as I explained in Tim King response, you can
> > > always replace a missing information by a structurally equivalent
> > > but uninformative one that will allow the broker logic to proceed,
> > > just making the concepts matching less reliable.
> >
> > MW: OK so now it is easy if we first develop an integration ontology
> > and then recreate all our existing ontologies in terms of that. Well
> > I think we all knew that.
>
> Yes, but the point is, is the "recreate" step automated or not?
>
> > > NO, NO, NO!
> > > The fact that adhering to a common formalism indeed allow you
> > > to do that SHOULD NOT BE AN EXCUSE for doing it.
> >
> > MW: You really can't have it both ways. Either you have integrated
> > them, in which case they do interoperate, or you haven't integrated
> > them and they don't interoperate (or at least not reliably).
>
> I think you are still REALLY missing some point about my approach.
>
> The BIG thing is "incrementality", as Philippe Martin pointed out
> I have not been clear enough about that.
>
> When you start "interoperating" you actually don't do anything!
> You just wait for some "unknown" word to appear within the flow
> of messages that convey the "normal" interaction between the
> remote parties, then, and only then, do you care to ask for
> some updating of you local ontology with names and concepts
> from the other side, and only just enough to make sense of the
> the newly appeared word.
>
> > > There are other reasons to keep all ontologies decoupled.
> > > Local variants of the same ontology will have their uses, and yet,
> > > they *will still be able to share* knowledge!
> >
> > MW: Decoupling is not the same as not being integrated.
>
> You can have BOTH, keep the "meanings" you are used to
> locally while still being able to use different meanings
> when the statements come from the remote party.
>
> > > Just as an example, assume that two sites use the same ontology but
> > > at different revision level, for historical reasons etc... (you
> > > should know about that kind of "reasons" just as well as me!)
> >
> > MW: They are still integrated if there is a mapping between the versions,
> > and they are not if no such mapping exists.
>
> If both have a consistent definition the mapping is implicit
> thru the "initial semantics" (see above).
>
> > > The difference of revision level is NO MORE than any other kind
> > > of difference in both the domains (old vs new) and the contexts
> > > (rev1.word vs rev2.word), so it is *manageable* by the broker
> > > logic without any special considerations!
> >
> > MW: Yes, if they are integrated then a broker can sort it out.
>
> There are NO MORE integration problems of ANY kind! (modulo stupidity, see below)
>
> This is not the "right wording" anymore, there is a DEFINITION
> problem for each and every ontology, but once this is solved
> the ontology is potentially integrated with ANY other!
>
> > > Two concepts (humanly intended to be the same) from two different
> > > ontologies will just have to have *enough* common and "sensible"
> > > attributes to make that work.
> >
> > MW: Why should they? I can't say this matches with my practical experience.
> > In fact my experience is quite the reverse. I am constantly amazed at how
> > differently people manage to describe what they agree is the same thing.
>
> "People" are not ontology builders. There will certainly be some learning
> curve for REAL ontology builders, but this will be quite intuitive,
> they will figure out quickly what must and must not be included among
> their concepts if they want to interoperate SATISFACTORILY with most other
> "unknown" ontologies. And those rules of thumb and habits will make sense,
> the realistic aim CANNOT be to give "ontology power" to complete idiots.
>
> > > Yes, they must have feathers, beak and any other zoological
> > > or behavioral
> > > attributes (laying eggs, flying) that may define them but NOT
> > > ALL attributes
> > > need to be present on each side for a match to occur.
> >
> > MW: So how do you decide which ones are necessary, and which ones
> > are optional (automatically).
> .../...
> > MW: How? Where? I am not familiar with this term |><|.
>
> See above.
>
> When the set of attributes for the "new" concept is included in the
> set of attributes for the "local" matching concept the |><| closure
> does it by itself.
> To ensure that, take off the set of attributes for the "new" concept
> any concept which is "peculiar" to the other side, that is, for which
> no "local" attribute is as or more general.
>
> But again this an OVERLY detailed point, may be when asking here you have
> not yet read about the "design" argument below in the previous message.
>
> I don't want to be too nasty, but this is NO WONDER that neither you,
> nor most of the other members of the SUO list (probably having the same
> thinking habits as you) did not came nor are likely to come to any solution
> to the problems you are trying to solve. You are just no good at design!
>
> THERE IS A RIGHT "TIMING" TO ANSWER QUESTIONS ALONG A DESIGN PROCESS!!!
>
> - If you try to answer too early you don't have enough matter
> to meaningfully investigate the point.
>
> - If you answer the question too late you may discover that you have
> to backtrack on many other answers because they are invalidated by
> the response you just found.
>
> Unfortunately there is NO rule that allows anyone
> to figure out the right timing, this is ART!
>
> > > But when a "bird of B" concept appear in a statement where, for the
> > > statement to make sense (I know, I know, I must define how the broker
> > > can figure out what makes sense, but I will *not* try to explain this
> > > here *nor* in any further messages)
> >
> > MW: Yes, but this is where the "magic" is required it seems to me, which
> > is why I am skeptical.
>
> See above and below, "magic" is in the DESIGN!
>
> > > the said bird must fly, we first
> > > ask B if, by any chance, he has a name for flying birds, by issuing
> > > some "reverse" query, sending all the attributes of the "bird of B"
> > > comprehension *plus* the 'flying' property.
> > >
> > > B will then answer with the full list of attributes for the
> > > |><| closure
> > > of this set in *his* FCA lattice and, a name if and only if
> > > he has one.
> > > Because it might well be that B knows about flying birds, has
> > > some more
> > > attributes that he know are always present for flying birds but did
> > > *not* care to give a name to this concept.
> >
> > MW: Well I still don't see how you get two concepts to match, when one
> > has a particular attribute as essential, and another has it as irrelevant.
> > You might reasonably deduse that the concepts are close, and infer a
> > supertype of each that includes flying and non-flying birds, but I really
> > think the two groups of people have different concepts, and it is only
> > us that is trying to relate them to OUR concept that includes both.
>
> NO attribute is essential or irrelevant per se, you DID NOT care to
> understand the FCA closure idea that's why you have trouble.
>
> > > There is never any GUARANTEE for that, design is an ART!!!
> >
> > MW: Oh, so this is the bit that isn't automated. I'm sorry, but in this
> > sense an art is just a science that we don't understand well yet and so
> > we are dependent on the abilities of skilled artisans. My point is that
> > ontology has not got beyond that point either. I doubt if we will automate
> > either much before the other.
>
> You are TOTALLY MISTAKEN, the design I am talking about is the design of
> the broker logic, NOT the design of any ontology.
>
> PLEASE READ MORE CAREFULLY.
>
> > > The key is BOOTSTRAPPING the translation process.
> > >
> > > Only a VERY small number of attributes and properties will have to be
> > > agreed upon, all the others will be constructed from these.
> >
> > MW: I have been trying to identify these for a number of years. So I have
> > some idea of the task. What to you is a very small number? 10, 100, 10,000,
> > 100,000, 1,000,000?
>
> Why should I have to find (and prove) the value of this number now?
> Again see the DESIGN argument.
>
> > > What's more, if you have no hope of any success, why are you
> > > watching SUO?
> >
> > MW: I've been working on the (EPISTLE) "small" vocab you can use to
> > integrate other
> > ontologies for a good part of the last 15 years. I know how much of a
> > struggle
> > it is to get as far as we have, and how hard it is not to be just hopelessly
> > ambiguous.
> >
> > MW: It is not that I have no hope of success, quite the reverse, I am
> > certain
> > that success will be achieved, just not when - though my guess is 10+ years
> > from here (based on experience developing other standards).
>
> You are RIGHT about that: "based on experience developing other standards"
>
> But THIS IS NOT THE WAY TO GO! (you just unwillingly proved it!)
>
> > > HAND-CRAFTING!!!
> > > No one will ever get anywhere unless quitting that!
> >
> > MW: I agree that we need to get to a point where the process can be
> > automated,
> > at least as far as possible. But you cannot automate what you do not first
> > understand. Otherwise it is just garbage in/ garbage out.
>
> Just the other way around, already stated at the beginning of this reply.
> You come to understand what you try to automate!
>
> > MW: However, you too are proposing a "good enough" ontology in your base
> > concepts.
>
> I am not really proposing a "good enough" ontology.
> I am proposing a "good enough" logical framework (to be defined,
> but I have some hints) and a "good enough" automated process (to
> be fully defined too) to find out about "basic" concepts and attributes.
>
> >How will you ensure it is "good enough"?
>
> Running it, because, as opposed to a STATIC proposal if it is
> not "good enough" it will just not "take off", there will be no doubt.
>
> > > Only the "paradigm" can be a real problem and that's not even sure.
> >
> > MW: 4D vs 3D just happens at a high level. The same problems occur all
> > over the place, they are no easier or harder to solve.
>
> There will be NO MORE such problems for the broker.
> This will be the problem of the 4D or 3D designer, if they succeed
> in casting what they "mean" into the *core formalism* that will do!
>
> > > There will be choices to be made AGAINST the "philosophy" and
> > > "metaphysic" of some people, but that only mean they will not
> > > like the basic concepts offered. That is not really worrying
> > > if they still CAN rebuild the concepts they want from the
> > > "common" concepts, just like you may choose either the metric
> > > system or avoirdupoids but you have to settle for one to make
> > > sense of a number on a blueprint, and stick to the convention.
> >
> > MW: You seem to have an idea of one central set of concepts. Why?
> > Why not allow different sets of central concepts with a mapping between
> > paradigms. The different basic metaphysical positions can then operate
> > on a peer basis. Nothing is central really, and by the way, you have
> > no chance of getting enough people to agree with "your" set of concepts
> > even if they are generated automatically.
>
> Neither the metric system nor avoirdupoids is "central" either but
> one must be choosen.
>
> Is someone is willing to design ANOTHER broker along any other paradigms
> while still providing the cross-conversions with my proposal that's fine.
> But if he comes later HE will have to provide the compatibility layers,
> just a "realistic" market constraint.
>
> > > > Drafts for Parts 1&2 at http://www.iso18876.org/.
> > >
> > > Thanks, I downloaded it and will have a look.
> >
> > MW: Good. I think you will find that our approaches are not so far apart,
>
> They are MUCH MORE that you seem to guess.
>
> Best.
>
> -- Jean-Luc Delatre
> --------------------------------------------------------------
> "If everything seems to be going well,
> you have obviously overlooked something." - Stephen Wright.
> --------------------------------------------------------------
> http://perso.club-internet.fr/jld/ -- GSM: +33 6 11 24 06 29