I just had a vivid day dream about my future computer: a 12+ inch hi-res tablet with an open OS (Android is good, something with full support for GNU would be even better), with wireless power/charging (e.g. on table top), and with wireless connection to a big external display (say 27" 2560x1440) as a second screen.
Then I could be ready to give up a real computer. And it would be a step towards the paperless office: I could finally review papers (say in PDF) on the computer, as opposed to printing them out and scribbling notes on paper, which is clearly slow and wasteful.
Estimated time of arrival: 2015-2020 for mass-market hardware. If Steve Jobs was still alive and kicking, I'd be expecting Apple to do it.
In relationships, it seems sometimes that people only see the bad things and never notice the good ones. I just formed a theory for why this is. (I'll use Adam and Eve to explain, but I don't see any reason that it has to be these genders in particular, just two people.)
When Adam does something good, such as buying flowers or cleaning the bathroom, Eve can thank him, smile, and it's done, off everybody's mind, a small pleasant memory.
When Adam does something bad, such as forgetting to clean the bathroom or burping loudly, but it's not so bad that Eve would feel like raising it as a criticism (fearing that would be creating a bad feeling), Adam may not notice that it was perceived as bad, and Eve will be left with this unfinished matter on her mind, waiting in the back ready to pop up, souring her mood. When enough of these small unfinished matters accumulate, the last straw (just as insignificant as the others) leads to an outburst of criticism, which focuses on all those small bad things left not-dealt-with, and ignores all the small good things that were closed with a thanks and a smile.
I believe this is a natural course of life — we can't really bring up every small bad thing that someone does.
If the partners keep this natural course of things in mind, it could lessen the violence of the outbursts without keeping any pent-up issues waiting to explode later and with more strength.
This should apply in situations other than couple relationships as well (e.g. in a workplace), but it seemed easiest to describe in terms of two people.
It's not likely to be a new insight, but it's new to me. 8-)
Slashdot again has a story about software patents. This time I also chimed in in the comments, and I also decided to blog this.
I wouldn't say that the problem with software patents is that the product is trivial to copy or distribute, or that software is an expression of an idea, therefore it should be covered by copyright.
The problem is that most of the software patents are obvious solutions to their problems. A patent is about a clever solution to a problem. How to change oil to movement? Engine - patentable. How to quickly sort an array of items? Qsort, should be patentable. How to compress data well? LZW was patented. These are not trivial algorithms. How to make it more convenient for users to shop? One-click. Fucking obvious.
A software solution should be patentable if it couldn't be produced by a moderately skilled programmer in a reasonable time, given a description of the problem. Students and hobbyists and OSS volunteers and small software firms are often cited as victims of software patents. But they are likely to infringe on patents not because software patents are evil, but because so many of them are obvious solutions that get replicated without thinking.
Also, the evolution of software is so fast that I'd reduce the term of patent monopoly, but I'd still grant software patents.
Recently, I had an idea that very short googling hasn't proven already implemented. The Web seems to be moving from hierarchical categories to tags, at least for some applications, like photo annotations. I wonder if this approach could work for a generic OS filesystem.
The idea is that instead of /home/jacek/jokes.html I'd have jokes.html with the tags home and jacek. The current directory of a program would be replaced by the current set of tags. A few examples:
cd /
ls # shows all files without tags and all tags
cd home/jacek # same as cd jacek/home
ls # shows all my files with no additional tags but home and jacek, and all my tags
cd pictures
ls # shows all my pictures with no other tags, and all tags of my pictures
lsall # shows all my pictures, regardless of tags
cd flowers
lsall # shows all my pictures of flowers
cd ..jacek # current tags home, pictures, flowers
lsall # shows all pictures of flowers by any user (tags home and pictures)
ls # shows all tags of users' pictures (and all pictures not tagged with a username)
cd /bin
ls # shows all the programs with no other tags
/bin/bash # would run file bash with tag bin only
bash # would run file bash with the first matching tag set from $PATH
# (. means current tag set)
The system would, of course, have restrictions on some tags, e.g. a user can only create files with tags home and their username, and user Alice cannot create files with tag Bob, etc. In fact, the username tags would probably be user:Alice and user:Bob, so that I can tag my pictures of Alice and Bob simply with these words. There are things to be ironed out, but the idea intrigues me. Sadly, I'm no good hacker and it would take me ages to make something workable like this, which I can't afford at this time.
Does anybody else also think this might be a neat idea? And please point me to the implementations, done 5 years ago already, that everybody knows about but me. 8-)
On Monday, I gave a lightning talk at a W3C meeting, and it's reproduced here. Check out the accompanying slides.
(slide2) Yesterday, we heard about how we should first innovate, get adoption, then standardize. For some technologies we seem to have a switch there (slide 3) - we innovate, then we push for standardization and expect adoption to follow. (slide 4) I'm up here to say that this need not be as crazy as it might seem at first.
(slide 5) A showcase for standardization are the train tracks. (slide 6) Developed from a common idea but with different rail gauges (slide 7) in different places because why should you even ask anyone who's 1000 miles away from you?
(slides 8-11) The network grows and in a few years you bump into a neighbor who happens to have a different gauge. (slide 12) You can make people change trains, (slide 13) or you can even build double gauge railways, but that's limited, you can't go everywhere so (slide 14) ultimately you'll decide to standardize. It's expensive and painful, but in the end better.
(slide 15) That's innovation, adoption, standardization.
(slide 16) But in internet time and world? You innovate, create tracks. A guy across the world does as well. (slide 17) Space doesn't matter, you're as good as neighbors. And your customers will want to run their trains on your tracks, and the other guy's tracks. In fact, they won't give you business (adoption) if you don't have the same gauge as the competition.
(slide 18) Looks like you need to standardize before you can hope for growth and adoption. (slide 19) But in internet time and world, rebuilding your product for a different standard (slide 20) is not as expensive and painful as changing hundreds of miles of steel bolted to wood.
(slide 21) Early standardization results in buggy, suboptimal standards, but since change is not so expensive any more, (slide 22) we can evolve and re-standardize.
(slide 23) Maybe this formula isn't so bad, if we enhance it a bit? (slide 24)
I was just asked by a colleague how to do a Web Service ping, to see if it's alive. He started with SOAP services and then went to HTTP services. For the latter it's easy - if there's any GET operation, just do that and see what happens, it should be safe. But for SOAP services, in absence of any operations marked safe, I suggested this:
Just send the service a message with a mandatory (mustUnderstand) header that you know the service won't understand, for example <ex:FailWithMustUnderstandFault s:mustUnderstand="true"/>. It should even specify that if a SOAP processor understands and processes this header, this must result in generating a mustUnderstand fault, and performing no other processing on this message.
This would be unnecessary if everybody agreed on a Ping operation, but that's not going to happen; and it only checks that the SOAP engine is running correctly, as opposed to any services deployed in it. Could it be useful anyway? 8-)
Tim Bray writes On Beyond Java — the JVM, basically thinking about the role JVM could play with many languages built on top of it, not just Java. I think that the comparison to mainframes is slightly misdirected, though — I'd compare JVM not to the mainframe, but to the PC CPU.
Mainframes were bulky and complex, whereas PCs are (were) basically memory, video and keyboard all connected to the CPU. We used to have many different CPUs with different machine languages and programs soon started to be written in an interoperable way, using compilers. Nowadays we have mostly i86, yet programming languages stay CPU-neutral — no reason to go changing that.
So on to virtual machines (JVM, CLR) — I'd say they are the new CPU: way smarter (garbage collection is good, threads are good etc.), but still basically machines that execute bytecode (the new machine language). So where we had Intel vs. Motorola vs. IBM earlier, we now have Sun vs. Microsoft. Unless the silicon makers start making successful CPUs with virtual machine capabilities (multicore CPUs should have no problem being the VM), they may go the way of memory makers — I don't care who made the commodity chip I'm sticking into my computer.
So I'm waiting for the first language compiled both for JVM and CLR. This might involve a lot of base library juggling or perhaps standardization (I'm talking the java.lang, or java.* or even javax.* here, dunno the MS equivalent) — how about that for a next gen programming language? 8-)
So I have been ongoing'ed. 8-) Tim Bray writes about the frustration of picking a password so that paranoid systems will allow it and you will actually be able to use it at the same time, and he quoted my reply to him (cutting it a bit too much, I'd say). So here it is in full (slightly edited):
I'm not sure if it affects the security of the password significantly, but when creating a password I choose random keys that are easy to write — alternating the fingers and trying it out. The commonly used passwords, even historical ones, are completely in my muscle memory.
This is also a fairly good defense against shoulder surfers trying to see what I'm typing — I type it very fast, usually sans mistakes, and it's random enough that a looking person won't get it.
I've recently been advocating, mostly internally in DERI, that we stick to URI instead of adopting IRI in our stuff. Except I'm not so sure anymore.
My reasons were that URI is already known and familiar and that IRIs and URIs are basically equivalent to a machine (as for a machine a hex-encoded UTF-8 representation of '€', for instance, is as readable as the real thing) and we're working on the semantic web, right? The web for machines, right?
As for human-oriented purposes, IRIs are better for presentation of internationalized resource identifiers, but the acronym is not appealing (or is it just me?). So I guess I'll attempt to use (and teach my students to use) the third option, the nice word "address". Or do you have any other suggestions? 8-)
Just midnight thoughts: It has occurred to me (and not for the first time) that the common understanding of what the Semantic Web is seems dangerously close to Artificial Intelligence. In fact, to solve problems like automatic data and process integration and useful reasoning, I feel we require something equivalent to strong AI (human-equivalent), even though I can't quite formalize this feeling.
I have said numerous times (with tongue strongly in cheek) that Semantic Web is the new name for AI, to get more money.
But as the Web is a useful (albeit unreliable and perhaps somewhat hacky) constraint of the great hypertext systems envision earlier, the Semantic Web should also be a useful (if somewhat unreliable and hacky) constraint of AI. Do we know the constraints?
I just read about the Page Hijack Exploit: 302, redirects and Google, where the temporary redirect HTTP code allows search engine to use wrong URIs for web pages. In this post, I suggest an alternative solution to this problem.
An excerpt of the description of the problem:
- When both pages arrive at the reception of the "index" they are spotted by the "duplicate filter" as it is discovered that they are identical.
- The "duplicate filter" doesn't know that one of these pages is not a page but just a link. It has two URLs and identical content, so this is a piece of cake: Let the best page win. The other disappears.
As a solution, Claus suggests that search engines should treat differently temporary redirects across domains. This would probably work well enough, but a different solution seems to be apparent from the point 14 above that might be considered cleaner:
The problem is in the step where duplicates are encountered and the search engine doesn't look at where the URIs came from before keeping only one and throwing away the duplicates. If the search engine knows one URI was direct and another was a redirect (of any form) then the redirect URI should be thrown away, not the direct one. So the solution is to keep some kind of provenance info available to the "duplicate filter" so it can make a better informed decision about throwing away URIs.
Continuing on the topic of MEST, I've had reactions from Savas and Jim and also a few comments on my previous post, from which it seems I wasn't clear enough in my post.
Basically, I was baffled until recently about what exactly MEST is meant to be. Yesterday I thought it might be about the imperative of SOAP's MustUnderstand semantics, i.e. MustUnderstand headers in SOAP messages must be processed according to their specification or the receiver must not process the message at all. After reading the replies, I'm getting the impression that MEST is really just a catchy name intended to promote the lower-level message passing network interface as opposed to any abstractions built on top of that.
So here's a question to the MEST folks: does MEST imply/require the imperative semantics or should ProcessMessage (AndDoWhatISay) really be named HereIsAMessage (DoWhatYouWillWithIt)?
By the way, I'm highly encouraged by the fact that at least some of the MEST people actually seem to read my blog. 8-)
In the latest post on the MEST thread, Chris Ferris says:
IMO, the semantics of messages in pub/sub aren't ProcessMessage, they are (or should be) more along the lines of SomethingInterestingHappened. Note the past tense. I think that is the key to achieving a loosely coupled enterprise.
I think the proposed name SomethingInterestingHappened (intentionally) leaves out the imperative and that's wrong. I'm not aware of any MustUnderstand semantics in the traditional message passing systems, and that's perhaps exactly what SOA(P) gives us. In other words, ProcessMessage represents a way for a sender of a message to be sure the recipient will do what the sender says (given compliant SOAP processors).
Provoked by a comment, Chris introduces pub/sub into the MEST debate of what the SOA interface is/should be. While I agree pub/sub is often very useful, it's just one thing that could be done with what people call ProcessMessage semantics. Others include providing a wxf:Get operation on services.
Apparently, Rich Salz and Dave Orchard are working on a URN scheme for QNames (via Tobbi). Read on for my thoughts on this proposed scheme.
This kind of approach has been suggested a number of times before (I don't remember who did that suggesting, though) and my major complaint is that this generic way of turning QNames to URIs disregards the fact that QNames are typed. In reality, a QName can be used to identify an XML element, XML attribute, XML Schema element or attribute declaration (these two may possibly be unified with the previous two), XML Schema type, WSDL interface, WSDL service and many other things, and just from looking at a QName we don't know what it is supposed to mean.
The proposed scheme takes the stance that one resource can be both an XML element, XML Schema type and WSDL interface. The existing ways of turning QNames into URIs outside of RDF (c.f. XML Schema Component Designators and URI References for WSDL constructs, for RDF see the last paragraph of this post) result in long and possibly user-unfriendly URIs that are unambiguous in what they identify.
At first, I didn't like these long URIs and I also thought that one resource can have multiple orthogonal aspects (XML Schema type, WSDL interface) but nowadays I believe that this is more confusing than useful. In effect, if the QName URN scheme (or something similar) becomes standard, it will effect in a good practice of not using same QNames (as in same namespace and local name, disregarding the prefix) for different constructs, leading to the policy of, let's say, prefixing the local names with type identifiers, like ns:ifaceStockQuote and ns:typeStockQuote for a WSDL interface of a stock quote service and the XML Schema type of an actual stock quote. I don't like such "good practices" and policies.
Dave writes on his blog that there is no single way of turning QNames to URIs, but I don't see the requirement. According to the TAG finding on the use of QNames as identifiers, where there is a compelling reason to use QNames instead of URIs for identification, it is imperative that specifications provide a mapping between QNames and URIs
. Therefore whenever we see a QName being defined, we also know from the language spec what URI it means, and those URIs will likely not have the ambiguity problem (judging by the XML Schema and WSDL solutions). We don't ever really see a QName without knowing its type (and the associated algorithm for turning a QName into a URI).
So basically, I think that while it's very simple, the proposed QName URN scheme leads to harmful ambiguities in the meaning of URIs.
As for RDF's use of QNames, they use them as a shortcut for URIs. They basically start from URIs and in the XML syntax turn them into QNames for the dubious readability benefit, whereas elsewhere they use relative and base URIs for the same URI-shortening effect. They don't create QNames to identify things, they create QNames to represent (almost arbitrary) URIs, and the proposed QName URN scheme goes in the other direction, therefore there's less connection between the two than Dave implies.
I'm currently in Belmont, California in the W3C Workshop on Constraints and Capabilities for Web Services. We're basically talking about policies (not just WS-Policy, but these folks are here as well). Read on for my thoughts on this and for links to other participants.
I hope the outcome is a future W3C working group on Web Services Policy language that would be chartered to come up with a framework for capturing non-functional capabilities, constraints and preferences (cc&p's) for web resources and web services, including semantic web resources and semantic web services. I mention SWS explicitly because this policy language might in fact become a significant part of semantic web services description language.
I would discourage the use of the policy language for expressing the functional cc&p's just for practical purposes (to keep the purpose simple and clear), including choreographical constraints and the constraints on the content of the message bodies.
We (DERI) have an accepted position paper here, where you can read in section 3 what we see as non-functional capabilities, constraints and preferences.
Finally, I'm very glad for this opportunity to see again many cool folks, including co-chair Mark Nottingham, alphabetically Glen Daniels, Paul Downey, Dave Orchard, and Jeffrey Schlimmer, mentioning only those whose blogs I can readily link to, and many others, especially the W3C folks. If you feel left out, send me a link to your blog. 8-)
Although in English, this entry is mainly targeted at my Czech readers. I've been trying for some time now to push the idea that the European money (€) should be called "evro" in Czech, because Europe is "Evropa" in Czech and the name of the money is the first part of that in all languages I know of.
The Greek have it this way even in their own alphabet. The Slovenians seem to call it "evro" - see Bank of Slovenia's page on Evro (in Slovenian). I don't know of other close countries that don't call Europe with "euro" at the beginning.
So the call to all the Czech who like their language: Nazývejme evropskou měnu hezky česky "evro"!
With some delay, I've read JimW's post on WSDL operations. I guess I belong to the other camp and my usual example on why operations matter follows.
Expanding on Jim's example of
MessageX op1(MessageA) MessageX op2(MessageB)
I suggest we consider the situation where two different operations take the same messages and actually return the same messages (in format):
int plus(TwoInts) int minus(TwoInts)
This is currently allowed in WSDL2. Does that mean, though, that if I send the service two ints, it returns an int and I don't know which operation was executed?
If we want the answer to be yes (as I believe Jim's opinion to be) we must clearly disallow such WSDLs, and explain clearly why we do this and how to model a service that does adding and subtracting with numbers. My only problem with this direction is that many people will need education to grasp it.
There's been a lot of talk on the difference between Web Services and Distributed Objects. Just to chime in, my opinion is that Web Services are the communication infrastructure on which Distributed Objects systems can be built. Efforts like WS Resource Framework go in that direction, I think.
Stefan writes Even more on WSDL vs. IDL (apparently as a follow-up to Jim and Mark).
According to Jim, The killer differentiator is that for a given WSDL portType (or soon "interface" in WSDL 2.0) there is no implication that the portType is "implemented" by a specific class at the back-end.
Why precisely does he think there is such an implication for IDL?
In my opinion, IDL (in cooperation with the actual wire format specs like IIOP and COM/DCOM) only defines that something will receive messages of some form and produce others.
In a pseudo protocol, a message
"invoke operation add with the parameters int 3 and int 5"
is guaranteed to be replied to with a message of the form
"result of operation add is int x"
I don't think IDL specifies that there will be an actual object with the method named add that will be invoked because what exactly is an object? I can code such a beast in machine language and it will still work even though my machine language has no notion of objects.
If there is any difference between IDL and WSDL, it's that WSDL is more explicit about not depending on what the implementation looks like, and Web Services have much lower entry barrier than, say, CORBA or COM.