Remembering the Future

Tit for Tat has been defeated in a Prisoner Dilemma competition! This has profound implications for philosophy in general, and the theory of Evolutionary Stable Strategies in particular. What's cool is that the new winner is a cooperative strategy between two agents! So, if two agents are better than one, how about "n"? Maybe this is why we live in cities? Who knows

Topics: Arificial Life:

Topics: Section508

The key to solving this problem is to write javascript that reselects the last selected entry and then schedules this javascript to run after a few miliseconds. There is no javascript scroll command, and this fix will not work without the delayed asych execution. I have changed the script tag to 'scrpt' in order to overcome security checks on embedded javascript.

    Private Sub Page_PreRender(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.PreRender
        'build string to set the focus on the current control
        Dim sFocus As String
        If Not focusControl Is Nothing Then
            sFocus = String.Format( _
            "try{{document.getElementById('{0}').focus();}}catch(x){{}}", _
             focusControl.ClientID)
        End If

        'build a string that will autoscroll the list boxes if they have selection that are not visible by default
        Dim sb As New System.Text.StringBuilder

        sb.Append("")
        sb.Append("function AutoScroll(){")
        sb.Append(sFocus)
        sb.Append(" var f = document.forms[0];")
        sb.Append("for (var num=0; num < ")
        sb.Append("f.elements.length;num++)")
        sb.Append("{")
        sb.Append("if (f.elements[num].type.indexOf('select')==0)")
        sb.Append("{")
        sb.Append("var si = f.elements[num].selectedIndex;")
        sb.Append("if (si >= 0) ")
        sb.Append("{")
        sb.Append("var maxi = f.elements[num].selectedIndex;")
        sb.Append("for (var i=maxi; i < ")
        sb.Append("f.elements[num].options.length;i++){")
        sb.Append("if(f.elements[num].options[i].selected){maxi=i}")
        sb.Append("}")
        sb.Append("var ooo = f.elements[num].options[maxi]; ")
        sb.Append("ooo.selected=true;")
        sb.Append("}")
        sb.Append("}")
        sb.Append("}")
        sb.Append("}")
        sb.Append("")

        sb.Append(" ")
        sb.Append("window.setTimeout(""AutoScroll()"",5)")
        sb.Append("")

        Page.RegisterStartupScript("radchk", sb.ToString)

    End Sub

Topics: ASP.NET | Javascript

Early libraries tried to create a whole bunch of categories, then assign each book to a category. It was rather quickly discovered that these fixed categories didn't work very well for the real world, that almost nothing is *about* a single subject, that the whole idea of "about" is very context-based. So when in computing, say as in RDF, we see "rdf:about", or in Topic Maps we see "subjectIndicatorRef", we should be very suspicious, or at least very careful. Nothing has or is just one subject. The statement of subject-hood is contextual.

. . .

I'm still working on this one, so I'm not claiming any answer here. But my feeling is that we shouldn't be looking for a set of fixed categories but rather a particular *approach* to modeling.

I say this because it's patently obvious from a simple look at reality (rather than say, mathematics) that fixed categories simply don't exist except in the most simplistic of views, and definitions are exactly like categories, i.e., they too are contextual, many-layered, recursive.

So the only way I can see to deal with this is to simply stop categorizing, stop defining, and begin to look at processes of categorizing, processes of defining. It's the processes that we need to focus on. I think this is the same thing neuroscience is coming to in trying to understand the human brain: that the brain is not composed of a bunch of Topics, it is composed of a bunch of Associations. That Topics don't exist, except as the confluence of a whole lot of Associations. (I use Topic Map termino- logy here because I am also emphasizing that I think we can still use Topic Map technology to do information or "knowledge" modeling; we just need to alter our approach a bit when talking about subject identity.)

The problem is that almost the entirety of western culture is built upon thousands of years of thinking about things as subjects, as categories, as identifiable "types", when I believe reality is telling us otherwise.

See also:Bernard Vatant

Yes. If identification needs a context, then how do you *identify the context*? Jack Park pushed to me lately some authors who go as far as to say that, in general, the fact that two things are identical (read, the identity of a subject) is formally undecidable. more things change more they are same If we follow those tracks, yes, identity can only be established on a pragmatic basis. IOW there are effective ways to agree on process of identification in a given context, but no universal way to assert the identity of something (or someone). For example, there are many contexts in which I can be identified by various identifiers and protocols (email address, phone number, credit card number, welfare number, passport number ...) but I figure that none of those, or any other, can pretend to carry "my identity" (not even my fully decrypted DNA) in *any context*.

. . .

This has been the succesful approach of Quantum Mechanics in Physics: be agnostic about the existence of entities out there in the physical world, focus on measure protocols. That's why I've been much impressed by the approach developed lately here by Lutz on "Subject Identity Measure". See the identification protocols the same way as measure protocols in certainly the way forward.

See also:Jack Park

Issue is identity, and that's where I think that the Steve Newcomb approach to disclosure of identity rules starts to make sense. Yup. Identity really is context sensitive, and, again, my interpretation at work here, the TMRM permits the derivation of identity through scoped assertions, as addressed in the required disclosures. Maybe there's a better way to accomplish the implementation of context-sensitive identification of subjects, or at least, maybe there's a different way. But, the TMRM, in my view, seems to want to address this particular issue directly.

Topics: Meaning | RDF | TopicMaps

Workflow technology and process support lies at the center of modern information systems architectures. But despite the large number of commercial workflow systems, object-oriented developers implement their business, scientific, or manufacturing processes with home-made workflow solutions. Current workflow architectures are based on requirements and assumptions that don't hold in the context of object-oriented software development. This dissertation proposes micro-workflow, a new workflow architecture that bridges the gap between the type of functionality provided by current workflow systems and the type of workflow functionality required in object-oriented applications.

Topics: Workflow

Welcome to The Third Manifesto (TTM), our proposed foundation for future database systems presented in Foundation for Future Database Systems: The Third Manifesto, 2nd edition, Addison-Wesley, 2000 (ISBN: 0-201-70928-7). A new version of this book is in preparation and planned for publication in 2005.

Topics: SQL

The challenge with the UML model is everything has to be described in the terms of what UML already understands. And that's kind of like saying a thumbtack is like a nail.

. . .

We actually believe that there is a better way. And we didn't make this up, quite frankly. The better way was thoroughly described by the SEI [Software Engineering Institute] out of Carnegie Mellon [University] as domain-specific languages. The notion of domain-specific languages is that you shouldn't say a screw is like a nail except for all of these different things.

What you should do is you should precisely describe a screw. And so instead of having one nearly monolithic metamodel that you map things into that you basically use profiling to describe things as, we think you just describe them precisely as they are.

. . .

So let me give you an example—the sequence designer. In UML they have a generic sequence designer for designing sequences of integrations between anything. We have the notion of a WSDL contract designer, and it has very specific semantics because WSDL has very specific semantics. It looks a lot like a sequence designer.

We will not ship that in the first version, but when we do ship it people will look at that and say, "Hey, that's a sequence designer." Well, it mostly is a sequence designer, but it has very specific semantics towards a problem domain.

Now, why should anybody care about that? Here is the one gem I have learned in the five years of dealing in this space, from some incredibly smart people we've got that have been working in this problem space for 20 years. And that is that the closer the underlying representation is to the model, the more likely it is that you can have a trip-less experience.

And the notion of "round trip," which UML talks about, I think is just wrong. I don't want round trip, I want trip-less. I want the relationship of a view to a database table. It can never be out of synch because it's just a view of the same data. That's what you need to get to from a tooling perspective to make this stuff work.

And that's why, quite frankly, people don't use UML. They may use it to document, they use it to do some initial design, and then it goes by the wayside. And I think, with all respect to Grady [Booch, co-creator of UML], I think we're a long way away from executable UML.

Topics: DSL UML

In a lot of ways, the Core J2EE Patterns book was a correction of a major oversight in the J2EE world, where we naively believed that we could simply take our traditional object systems and throw them at the J2EE container and expect objects to peek back out at us. Distributed systems just don't work that way, and it took several revisions (including several more that occurred after Core J2EE Patterns was released) before we got to some of the fundamental precepts that led us down the Dark Path, such as "Differentiate layers from tiers" and "Avoid round trips".

In the end, part of J2EE's problem was that it went directly for the large-scale, enterprise-class (read: Really Big Money) kinds of systems, where this kind of complexity is warranted and necessary. (Remember, with power comes complexity, and, usually (we hope), with complexity comes power.) Most people getting started in J2EE weren't building those kinds of systems, though, and the complexity became overwhelming and difficult to recognize and sort out.

...

In some respects, the underlying framework of J2EE (the component/container model, the Context approach) is only now coming out, with some explorations by the Spring folks, the NanoContainer folks, the PicoContainer folks, and others too numerous to mention. This is in large part why we're reacting so strongly against J2EE, because the Java space is searching for that simple "underlying story".

Topics: Java | SoftwareArchitecture

If you’re into .NET, Windows Management Instrumentation (WMI) looks like an interesting way to string trip wires in your applications. Want to keep an eye on the inner workings of that hosted .NET application to spot notable user actions or the first signs of a problem? Imagine an WMI event consumer that, for example, pops important events onto an RSS feed or even out to your cell phone.

Topics: Automation | WMI

Ever wanted to unzip a file and use it's content in BizTalk Server?

Topics: Biztalk | Zip