Thursday, January 12, 2006

Don’t Invent XML Languages 

ongoing · Don'’t Invent XML Languages: "....if you embark on designing a new XML language, there'’s a substantial probability that your effort will not be rewarded with success.

[Sidebar: Of course, to mitigate that risk, when you'’ve finished designing your language, you have to take your show on the road and sell that sucker. You can no more hope to succeed without marketing than can any other technology. Some of us like marketing and selling, so for us this is not a big downside. But it will be for others.]

So right there is a good reason not to embark on this kind of thing: it'’s really hard, really time-consuming, and there's an excellent chance that it won'’t produce the results you were hoping for. In this life it'’s generally a good idea to stay away from projects which are difficult, unpleasant, and have a high chance of failure. And so far I'’ve just talked about the personal expenditure of time.

Software Pain · If you'’re going to design a new language, you'’re committing to a major investment in software development. First, you'’ll need a validator. Don't kid yourself that writing a schema will do the trick; any nontrivial language will have a whole lot of constraints that you can'’t check in a schema language, and any nontrivial language needs an automated validator if you're going to get software to interoperate. Second, if you're designing a language that will be human-authored, you'’re going to have to arrange for there to be authoring software. This either means writing an authoring package from scratch (we'’re talking huge money and time and pain), or customizing one of the generalized XML-authoring tools, which is only moderately-less-huge time and money and pain. Finally, there's the payload software; you wouldn't be designing a language if you didn't want to do something with it, other than author and validate it. Someone's going to have to write that software. Software is expensive."

And this would seem to be true also of any semantic web vocabulary. Unless you believe in the vision of a fractal tangle web of meaning emerging over the web as a whole, bit by tiny bit, each new bit taking on the meaning contained in the links by which it is connected to all the rest.

Wednesday, January 11, 2006

Workshop on Logics for Resource Bounded Agents at ESSLLI06 

Workshop on Logics for Resource Bounded Agents at ESSLLI06: "Workshop description
Logics of knowledge and belief, as well as other attitudes such as desire or intention, have been extensively studied. However, most of the treatments of knowledge and belief make strong and idealised assumptions about the reasoners. For example, traditional epistemic logic say that agents know all logical consequences of their knowledge. Similarly, logics of action and strategic interaction are usually based on game theoretic models which assume perfect rationality. Models based on such assumptions can be used to describe ideal agents without bounds on resources such as time, memory, etc, but they fail to accurately describe non-ideal agents which are computationally bounded. The workshop aims to provide a forum for advanced PhD students and researchers to present and discuss possible solutions to the problem of formally capturing the properties of knowledge, belief, action, etc. of non-idealised resource-bounded agents with colleagues and researchers who work in logic, computer science and other areas represented at ESSLLI."

I believe that for many years to come, any notion of semantic understanding by machines will be severely resource bounded. Many say the limitations are so severe that it is pointless to speak of it. Others, as this workshop suggests, believe that it is possible to deal with severe limitations and still work with "knowledge, belief, action, etc."

Science and Consciousness Review : Information Integration Theory of Consciousness 

Science and Consciousness Review : Information Integration Theory of Consciousness: "Abstract

BACKGROUND: Consciousness poses two main problems. The first is understanding the conditions that determine to what extent a system has conscious experience. For instance, why is our consciousness generated by certain parts of our brain, such as the thalamocortical system, and not by other parts, such as the cerebellum? And why are we conscious during wakefulness and much less so during dreamless sleep? The second problem is understanding the conditions that determine what kind of consciousness a system has. For example, why do specific parts of the brain contribute specific qualities to our conscious experience, such as vision and audition?

PRESENTATION OF THE HYPOTHESIS: This paper presents a theory about what consciousness is and how it can be measured. According to the theory, consciousness corresponds to the capacity of a system to integrate information. This claim is motivated by two key phenomenological properties of consciousness: differentiation - the availability of a very large number of conscious experiences; and integration - the unity of each such experience. The theory states that the quantity of consciousness available to a system can be measured as the Phi value of a complex of elements. Phi is the amount of causally effective information that can be integrated across the informational weakest link of a subset of elements. A complex is a subset of elements with Phi>0 that is not part of a subset of higher Phi. The theory also claims that the quality of consciousness is determined by the informational relationships among the elements of a complex, which are specified by the values of effective information among them. Finally, each particular conscious experience is specified by the value, at any given time, of the variables mediating informational interactions among the elements of a complex.

TESTING THE HYPOTHESIS: The information integration theory accounts, in a principled manner, for several neurobiological observations concerning consciousness. As shown here, these include the association of consciousness with certain neural systems rather than with others; the fact that neural processes underlying consciousness can influence or be influenced by neural processes that remain unconscious; the reduction of consciousness during dreamless sleep and generalized seizures; and the time requirements on neural interactions that support consciousness.

IMPLICATIONS OF THE HYPOTHESIS: The theory entails that consciousness is a fundamental quantity, that it is graded, that it is present in infants and animals, and that it should be possible to build conscious artifacts."

This could have implications also for semantics. To know the meaning of a statement is in some sense to be conscious of what is meant by the statement. Without that, you can do mechanical symbolic manipulation or analysis only.

Tuesday, January 10, 2006

ongoing · On XML Language Design 

ongoing · On XML Language Design: "If you’re going to be designing a new XML language, first of all, consider not doing it. But if you really have to, this piece discusses the problems you’re apt to face and offers some advice on improving your chances of success.

Expect Semantic Gaps · “There are only two hard things in Computer Science: cache invalidation and naming things” said Phil Karlton. Designing an XML vocabulary is all about agreeing on names for things, and thus it’s hard. ¶

The disease’s symptoms are semantic gaps, painfully familiar to anyone who’s done application integration at a large scale. It’s astounding how similar-sounding things can have completely different meanings; the example that burns brightest in my mind right now happened in the Atom Working Group last year; we spun our wheels for weeks and weeks trying to agree what an entry’s “Last-Updated” date really meant. No, I’m not kidding.

Agreeing on what the objects you’re dealing with is are, and on what to name them, is often a process that can try the patience of saints; and few saints are engaged in XML language building."

ITworld.com - Taking the 'I' out of Identity 

ITworld.com - Taking the 'I' out of Identity: "As is often the case with seemingly intractable problems, revisiting basic assumptions is always a worthwhile exercise. The big assumption here is that to do business electronically with someone, you need to know who they are. Is that really true?

Sometimes it most definitely is true of course but there are a significant number of use cases where it is not true. Sometimes lurking behind the phrase 'we need to know who they are' lies the real substance of the concern which is 'we need to know they can pay' or, more generically 'we need to know that the person/thing we are interacting with can conduct a value exchange.'

The cracking noise you can hear in the background is the rending of two concepts that tend to be bound together. The concept of identity on one hand and the separate concept of 'ability to conduct value exchange' on the other. People turn up with cash. They can clearly pay. People turn up with checkbooks. They can clearly pay. People turn up with credit cards, they can clearly pay..."

Sunday, January 08, 2006

The Social Side of Services 

The Social Side of Services: "Another way of stating this is that SOA success is based, in part, on achieving a critical mass of useful services. The technical line of reasoning for reaching and managing this critical mass typically goes like this:

1. For services to operate as a collective, they have to know about each other.
2. For services to know about each other, they must either be hardwired together or be able to dynamically find one another.
3. Hardwiring would be bad, as it implies high coupling and potential difficulties in replacing one service implementation with another somewhere down the line.
4. To facilitate dynamic discovery, then, services need a place that they can advertise themselves and meet other services.
5. Of course—a registry!

This line of reasoning usually fails because it ignores the hard problem of how services are created. It assumes that development teams will bring new services into being and that, because those services will want to interact with each other, the real problem is just providing a state-of-the-art registry to support those interactions. Over the years, I’ve seen plans and proposals for some pretty sophisticated registries, usually involving registration and query capabilities for all kinds of extensible service properties."

"For services to operate as a collective, they have to know about each other." - Is SOA in the same boat as the Semantic Web?

This page is powered by Blogger. Isn't yours?