RDF is everywhere it seems: from Dublin Core to RSS, all to way to FOAF… However, it can be quite painful to parse. Cool tools are starting to emerge however, but google is not yet very good at finding them.
Suppose you have a RDF/XML representation and you want the triples… go to W3C RDF Validation Service and it will do it nicely for you.
On the other hand, the form on this page allows you to go from N3 (the user friendly RDF syntax) to RDF/XML.
Through Downes’, I found this great post about how to be creative. HOWTOs are always interesting and sell magazines, but they are somewhat more interesting in blogosphere because someone you can get to know put his heart into it.
- Ignore everybody
- Creativity is its own reward
- Put the hours in
- If your biz plan depends on you suddenly being “discovered” by some big shot, your plan will probably fail
- You are responsible for your own experience
- everyone is born creative; everyone is given a box of crayons in kindergarten
- Keep your day job
- Companies that squelch creativity can no longer compete with companies that champion creativity
- Everybody has their own private Mount Everest they were put on this earth to climb
- The more talented somebody is, the less they need the props
- Don’t try to stand out from the crowd; avoid crowds altogether
- If you accept the pain, it cannot hurt you
- Never compare your inside with somebody else’s outside
One of the most interesting one is number 5: Nobody can tell you if what you’re doing is good, meaningful or worthwhile. The more compelling the path, the more lonely it is.
Of course, I don’t buy all of it. Being extremely lonely is no way to be creative I think. Nobody gets awfully creative at the bottom of a cave. I do think you have to look for others. The strength of your network is key because it multiplies your own brain power. I guess we go back to Emerson’s independence of solitude. Be in a network, be in a crowd, but do not be a mere node in the crowd, be your own node. It does require courage though, and you have to expect to fail, fail badly even.
Paul Graham wrote an essay called ‘Great Hackers‘. I’m pretentious enough to call myself a hacker (though I do not claim to be great), so I had to jump on it!
Here are some juicy quotes…
Good hackers find it unbearable to use bad tools. They’ll simply refuse to work on projects with the wrong infrastructure.
Great hackers also generally insist on using open source software. Not just because it’s better, but because it gives them more control.
They [great hackers] work in cosy, neighborhoody places with people around and somewhere to walk when they need to mull something over, instead of in glass boxes set in acres of parking lots.
There’s no way around it: you can’t manage a process intended to produce beautiful things without knowing what beautiful is.
And this is the reason that high-tech areas only happen around universities. The active ingredient here is not so much the professors as the students. Startups grow up around universities because universities bring together promising young people and make them work on the same projects. The smart ones learn who the other smart ones are, and together they cook up new projects of their own.
If you’re worried that your current job is rotting your brain, it probably is.
If you’ve been annoyed about the fact that a kilobyte has 1024 bytes and not 1000 bytes, well, you were right all along! What people call a kilobyte is really a kibibyte. (Thanks to Owen for pointing it out to me!)
|Examples and comparisons with SI prefixes
|| 1 Kibit = 210 bit = 1024 bit
|| 1 kbit = 103 bit = 1000 bit
|| 1 MiB = 220 B = 1 048 576 B
|| 1 MB = 106 B = 1 000 000 B
|| 1 GiB = 230 B = 1 073 741 824B
|| 1 GB = 109 B = 1 000 000 000 B
Source: Definitions of the SI units: The binary prefixes
Michael just finished his essay: Principles of Effective Research. I think it is a must read for all Ph.D. students, young researchers, and even idiots like me who always get it wrong. Michael takes a very refreshing view to what research is all about. He is not cynical yet he is true to what research really is. You may never win the Nobel prize if you follow his guidelines, you may never be a guru researcher, but I think you’ll be a good or even excellent researcher. As he explains, being an influent researcher is not a subset of being a good researcher, and that’s a very important statement. In any case, Michael did all of us a favor and I hope that he essay is read by a lot of people. (Power of the network?) I implore you all: link to his essay!!!
Through Downes’, I found an interesting paper on the application of collaborative filtering to e-Learning in ITDL (by Jinan A. W. Fiaidhi).
It makes the point quite well that we must differentiate heterogeneous settings from sane laboratory conditions:
Searching for LOs within heterogeneous repositories as well as within collaborative repositories is far more complicated problem. In searching for such LOs we must first decide on appropriate metadata schema, but which one!
Through Didier and Nielsen, I found a list of Golden Rules for Successful Scientific Research attributed to Dijkstra.
- “Raise your quality standards as high as you can live with, avoid wasting your time on routine problems, and always try to work as closely as possible at the boundary of your abilities. Do this, because it is the only way of discovering how that boundary should be moved forward.”
- “We all like our work to be socially relevant and scientifically sound. If we can find a topic satisfying both desires, we are lucky; if the two targets are in conflict with each other, let the requirement of scientific soundness prevail.”
- “Never tackle a problem of which you can be pretty sure that (now or in the near future) it will be tackled by others who are, in relation to that problem, at least as competent and well-equipped as you.”
Of the three rules, only the last one seems important. The second one appears self-evident: you want to be socially relevant, but not to the point of producing low quality work. This being said, most researchers go to the other extreme and ignore social relevance and their work loses out its motivation. If you tackle a problem that only you care about, don’t expect much recognition. I actually disagree with the first rule: small problems, technical issues actually often hide interesting problems. Always focusing on the management and top level issue is a bad idea I think. Michelangelo was painting a church! In research, do not be so quick to think that there are noble and not-so-noble problems. All problems can be interesting and knowledge of technical issues can bring much insight.
Blogging is a fascinating past-time. Who would have thought? I just read bits and pieces of an essay on Extreme Thinking.
Here’s a fascinating quote:
The key to keeping this independence of solitude is to develop a long-term vision so compelling and well-internalized, that it can override behaviours for which the short-term rewards are significant, but which may be damaging in the long run.
Update: Independence of solitude: I didn’t know this expression. Found 600 or so hits on Google. Seems that maybe the expression comes from Ralph Waldo Emerson.
What I must do is all that concerns me, not what the people think. This rule, equally arduous in actual and intellectual life, may serve for the whole distinction between greatness and meanness. It is the harder, because you will always find those who think they know what is your duty better than you know it. It is easy in the world to live after the world’s opinion; it is easy in solitude to live after our own; but the great person is one who in the midst of the crowd keeps with perfect sweetness the independence of solitude.
Didier reminded me to check Nielsen’s last post on Principles of Effective Research. I take a quote out of it…
The foundation is a plan for the development of research strengths. What are you interested in? Given your interests, what are you going to try to learn? The plan needs to be driven by your research goals, but should balance short-term and long-term considerations. Some time should be spent on things that appear very likely to lead to short-term research payoff. Equally well, some time needs to be allocated to the development of strengths that may not have much immediate pay-off, but over the longer-term will have a considerable payoff.
This is a refreshing view.
Looks like Sean has found a good Canadian e-commerce site for computer stuff: NCIX.com.