It seems to me that lists are adequate to represent most of the content in our web sites. And blogs serve adequately as lists. In addition, content can be exported in standard formats. Blogs are easy to manipulate. And, additionally they make sense by themselves. With processors like Yahoo! Pipes out there now, content from blogs can be processed in useful ways.
My content content of lists of
--my bio (a singleton)
--my various degrees
--my publications
--work experience
--books I've read
--photos
--book's I've read
--movies I've seen
an so on.
I'm going to create a blog corresponding to each list I wish to maintain and use Yahoo! Pipes like software to create a coherent web site out of them. Why do I need to maintain a resume? I'll just have a processor merge feeds I need to create a resume, export the result into a format from which I can generate PDF and send it around.
There are various other ways in which other can use my content to create mashups. Why should people add to their HTML pages anymore! Just blog and mash.
Showing posts with label feeds. Show all posts
Showing posts with label feeds. Show all posts
Saturday, December 01, 2007
Saturday, February 17, 2007
Disseminating Research
One suggestion:
---------------------
It would be awesome if instead of maintaining an HTML publications page, a researcher maintained ATOM or RSS feeds of her publications. Yes, there could be multiple feeds, e.g., by area of research. This way fellow researchers could subscribe to her feeds for updates. They could mashup her feed with others through a service such as Yahoo! pipes to create more interesting feeds. Plus, with the growing set of tools and services around feeds, it should be easier to maintain feeds than HTML pages.
The other day I tried to create a Yahoo! pipes mashup of the feeds of fellow researchers whose papers I frequently cite. However, since there were no feeds available, I just couldn't do it. Hence, consider this an exhortation upon all researchers to start publishing feeds. They have much to gain from it, and nothing to lose.
One idea:
-------------
Entering bibitems in bibliographies and managing them is so tedious and error-prone, don't you think? Well, here is a solution that alleviates this burden to an extent. An author should make the accurate bibtex of her publications dereferencable by URIs. Then, any other author's local bibliography should logically consist of only id:URI pairs. A bibtex processor should be smart enough to fetch using those URIs (and automatically "populate", if needed, each bibitem in the bibliography for offline use).
A point to note is that the information in a paper's bibtex is a subset of the information in the corresponding entry of the author's publication feed. As long as each entry has its own URI, a bibtex processor can fetch an entry in the feed directly, and process it to extract the relevant elements. Hence, a paper's author has to work no harder to create the bibtex.
Authors often move from institution to institution, and therefore the mappings from URI to URLs could change. How to manage these mappings without imposing any additional burden on authors, I'll need to think about.
---------------------
It would be awesome if instead of maintaining an HTML publications page, a researcher maintained ATOM or RSS feeds of her publications. Yes, there could be multiple feeds, e.g., by area of research. This way fellow researchers could subscribe to her feeds for updates. They could mashup her feed with others through a service such as Yahoo! pipes to create more interesting feeds. Plus, with the growing set of tools and services around feeds, it should be easier to maintain feeds than HTML pages.
The other day I tried to create a Yahoo! pipes mashup of the feeds of fellow researchers whose papers I frequently cite. However, since there were no feeds available, I just couldn't do it. Hence, consider this an exhortation upon all researchers to start publishing feeds. They have much to gain from it, and nothing to lose.
One idea:
-------------
Entering bibitems in bibliographies and managing them is so tedious and error-prone, don't you think? Well, here is a solution that alleviates this burden to an extent. An author should make the accurate bibtex of her publications dereferencable by URIs. Then, any other author's local bibliography should logically consist of only id:URI pairs. A bibtex processor should be smart enough to fetch using those URIs (and automatically "populate", if needed, each bibitem in the bibliography for offline use).
A point to note is that the information in a paper's bibtex is a subset of the information in the corresponding entry of the author's publication feed. As long as each entry has its own URI, a bibtex processor can fetch an entry in the feed directly, and process it to extract the relevant elements. Hence, a paper's author has to work no harder to create the bibtex.
Authors often move from institution to institution, and therefore the mappings from URI to URLs could change. How to manage these mappings without imposing any additional burden on authors, I'll need to think about.
Monday, January 23, 2006
Aspect Oriented Programming (AOP)
AOP's value lies in producing uncluttered code through a separation of concerns. Point cuts and related advice are coded separately from the places where they will be applicable, and are weaved into the instruction stream, typically at runtime. One of the first thoughts that I had was about a programmer's understanding of the functionality of a system designed and coded using AOP. How does a programmer understand the functionality and the flow of a program when they are distributed across different files with nothing to relate them? I had raised these questions in a review I once wrote for an AOP related paper.
The answer is that a programmer doesn't need to understand the functionality of the entire program; if concerns are well-separated, then he need only understand the code that implements the functionality he is responsible for, possibly in conjunction with other programmers who are also responsible for that functionality. You will notice that I am, more or less, equating functionality with concern. An advice can be weaved in one concern only by another concern. A programmer doesn't need to care what advice is being weaved by other concerns, that being the whole idea about separation of concerns.
In the Jan/Feb 2006 issue of IEEE Software magazine, there appears an article about AOP in the point-counterpoint section. The counterpoint argues that unlike hierarchical design, AOP obscures the understanding of a software module. I don't believe that is the case for reasons outlined above. I view AOP as sitting on top of hierarchical design with various aspects as peers. (Perhaps AOP itself can use some hierarchical design concepts as it matures). Another argument made against AOP is that it is hard to identify non-trivial aspects. Most examples describe rather trivial aspects such as logging, profiling, and synchronization. I find this argument valid. However, I believe this to be just an initial hump which will be overcome as systems designers get used to thinking about in terms of aspects. To conclude, I agree with its detractors to the extent that AOP has yet to prove its value, but I also agree with its supporters that it will see widespread adoption.
BTW, the paper I reviewed did not achieve a separation of concerns. In such cases, understanding program behavior would be a challenge second to none.
The answer is that a programmer doesn't need to understand the functionality of the entire program; if concerns are well-separated, then he need only understand the code that implements the functionality he is responsible for, possibly in conjunction with other programmers who are also responsible for that functionality. You will notice that I am, more or less, equating functionality with concern. An advice can be weaved in one concern only by another concern. A programmer doesn't need to care what advice is being weaved by other concerns, that being the whole idea about separation of concerns.
In the Jan/Feb 2006 issue of IEEE Software magazine, there appears an article about AOP in the point-counterpoint section. The counterpoint argues that unlike hierarchical design, AOP obscures the understanding of a software module. I don't believe that is the case for reasons outlined above. I view AOP as sitting on top of hierarchical design with various aspects as peers. (Perhaps AOP itself can use some hierarchical design concepts as it matures). Another argument made against AOP is that it is hard to identify non-trivial aspects. Most examples describe rather trivial aspects such as logging, profiling, and synchronization. I find this argument valid. However, I believe this to be just an initial hump which will be overcome as systems designers get used to thinking about in terms of aspects. To conclude, I agree with its detractors to the extent that AOP has yet to prove its value, but I also agree with its supporters that it will see widespread adoption.
BTW, the paper I reviewed did not achieve a separation of concerns. In such cases, understanding program behavior would be a challenge second to none.
Subscribe to:
Posts (Atom)