That's how it's done, and that's why it's called "semantic web" instead of "semantic centralized project". You can use an ontology defined by others, the same way that you hiper-link to web pages published by others.
the Semantic Web is a publishing medium; the creation of content is left to the will of the publishers (ideally the creation of metadata should be computer-assisted, but there are other possibilities). Your "second problem" is precisely what the S.W. is intended to solve; it doesn't require people to agree in the data format, everybody can define their own.
That article has interesting points, but it fails in its critic that semantic web will never take off because it requires that everybody agrees on the same ontology. The semantic web allows people to publish their own ontologies, and the best tools should be those that learn to extract interesting info from various sources. This is what S.W. is all about, not yet-another-universal-standard.
This comment is informative. These European "return laws" are not driven by ethnic group, they allow descendants of people on the country to claim for citizenry.
From the article: "Since Boba Fett is a clone of Jango Fett, and Jango Fett is played by Temura Morrison, doesn't it make sense that he should sound like him, too?"
It doesn't. I know some twin sisters, and their voices are quite different.
The "save and organize links" is stupid in a web engine: you usually decide that a web page is worth saving after you have read it, and then you are no longer seeing the results of the search. It is far better to have a separate tool like Furl and Spurl, that you activate with a bookmarklet.
If this gets popular enough, its abolutely trivial to, and someone will, write a program that creates a wide variety of dummy "interests", but also include their own music and the music of the people they agreed to promote. Thusly the system will have been corrupted.
Not necessarily. iRate uses a collaborative filtering rating system, which results are computationally personalized for every user. This means that, even if there are people creating dummy profiles, that if you don't like the music promoted by these "interests" then they will not influence the recommendations that you get. (And if you do like the suggestions of these "dummy" profiles, well, then the system is working as expected).
But Python is a language intended to be meaningful to humans. That's the difference with your usual programming language, and that's why Python needs the tab/space awareness.
But that assumes that your mathematician have the will and the knowledge to "invest it wisely"; it is perfectly possible for the matematician that the "invest money" is not at all an interesting one and that the imposed burden of following stock prices and market trends would make it a pain in the ass. If that is case a grant will be much more desirable since it will be given to you for achieving results in precisely the math problems that you like.
Re:Some may, but I think you're being a bit unfair
on
Capturing Genesis
·
· Score: 1
To suggest that all of humanity is built from the basic building blocks of elements and chemicals causes us to neglect much of the human experience.
Actually doing that is not a scientific requirement at all. Economics, for example, doesn't require that kind of analysis; it keeps "human actions" as an indivisible object of study, and build a (somewhat) successful theory in top of it.
Reductionism is not the only way to proceed on science. As Sycraft-fu points out, the only required thing is testability - the possibility to build experiments that can disprove your current theory.
I would add that strict logic reasoning is a must, and analytic separation of a fact in its composing parts is a natural way to progress. But science doesn't implies that everything must be decomposed that way, and that humans "are built from the basic building blocks and chemicals". Science is also able to adopt "holistic" (systemic) procedures. See Complex systems and systems theory for some examples.
No; that was the old way that money used to work, before monarchy started to forge coins. When money meets authority, the theory changes: money is a procedure, distributed among people and accounting software (different kinds of "agents"). In our modern society money isn't a physical object that can be traded, is a promise of the money "owner" to act in a planned, foreseeable way. Money keeps its value because there is an authority warranting that the correct procedures will be kept (before those were the governments, nowadays the banks have more power).
In this "generalised" theory of money, there is nothing that implies that the planned acts should be that of exchange. For example, slashdot moderation points are a kind of money certified and managed by the/. site owners; but these points are not tradeable and are not useable outside of this web.
How many times do those guys fall from their segways? What is the maximum speed of this vehicle? I think it could be very painful and injure-prone to drive one of those on a street as it is intended.
Then the software should be developed according to both it's users and it's contractors. Sure the management want their workers to be as most productive as possible, so they should specify what the software should accomplish and let the 'how' decisions to the usability engineer, who should do early interaction prototiping.
Not true. At least, as far as we know according to his words:
However, halfway through, someone called and needed another feature/field. Then another call. And another.
His users wanted (not needed!) those features, and did not specifically define them before the project started.
And how do you decide whether or not the need the features they want? That's basically the problem that they specifically should have defined before the project started.
If the users are constantly changing their minds about what they want
That's a disrespectful attitude towards your users. Usually the users know quite precisely WHAT they want (and even have been doing it for years), is just that they don't know HOW a computer can help to achieve it more easily.
That's the problem an interaction designer must overcome by interviewing her users, watching their 'analogic' process and doing interface prototiping. Only after the problem is well known by both the users and the developers a good design can be achieved. The strategy of doing "basic" things and then adding bells and whistles simply doesn't work well, as (for example) Microsoft products show.
Good rant!;-) But that only applies to software designed to by used by its programmer. (It doesn't need to be open sourced, nor all OSS is meant for that use). My points are valid for software designed to be used by other people who don't want to learn the inner details of the whole system (something that OSS can be). Now, once it's working, then refine and refactor to make the conceptually-simple things simple. That could be a good idea if not for the fact that it's impossible to build a good UI with that strategy. Refine & refactoring is a software design strategy, which leads to good code structure and maintainability; but for good interaction design, the only valid strategy is early prototiping with real user testing (or major software redesign: dropping completely the old interface and building a new one from scratch). The user conceptual model for an application is the first thing that must be precisely defined, before writing a single line of code or class diagram; and this user model will be different from that of the implementor.
Sadly this is a fact that seem impossible to teach to most OSS developers; and even when they try to put user feedback, they do it in a wrong "feature bloat" way instead of a proper goal-task-tool analisys.
Well, Nielsen is not the only player in the HCI game. And his early essays have good material in them, although now are mainly advertising for his webpage usability services.
I maintain that 99.99% of config options could and should be solved by redesigning the interface. In the case of window focus, probably the best solution is to get rid of the windowing paradigm (which in my opinion has exceeded too far it's useful lifespan).
Read "The humane interface" if you want to learn about a successful interface built from the ground up without windows nor pointing devices. The resulting system is very near in concept to the Command Line interface, but whit 30 years of usability lore added in it; and "Zoomworld" could be a nice replacement for almost all situations where a desktop is better than a command interface.
That's how it's done, and that's why it's called "semantic web" instead of "semantic centralized project". You can use an ontology defined by others, the same way that you hiper-link to web pages published by others.
the Semantic Web is a publishing medium; the creation of content is left to the will of the publishers (ideally the creation of metadata should be computer-assisted, but there are other possibilities). Your "second problem" is precisely what the S.W. is intended to solve; it doesn't require people to agree in the data format, everybody can define their own.
And who's to say that the Semantic Web metadata will not be populated with statistical text analysis and hyper-text analysis?
That article has interesting points, but it fails in its critic that semantic web will never take off because it requires that everybody agrees on the same ontology. The semantic web allows people to publish their own ontologies, and the best tools should be those that learn to extract interesting info from various sources. This is what S.W. is all about, not yet-another-universal-standard.
This comment is informative. These European "return laws" are not driven by ethnic group, they allow descendants of people on the country to claim for citizenry.
What difference? They're both formed from the same genetic material.
From the article: "Since Boba Fett is a clone of Jango Fett, and Jango Fett is played by Temura Morrison, doesn't it make sense that he should sound like him, too?"
It doesn't. I know some twin sisters, and their voices are quite different.
The "save and organize links" is stupid in a web engine: you usually decide that a web page is worth saving after you have read it, and then you are no longer seeing the results of the search. It is far better to have a separate tool like Furl and Spurl, that you activate with a bookmarklet.
If this gets popular enough, its abolutely trivial to, and someone will, write a program that creates a wide variety of dummy "interests", but also include their own music and the music of the people they agreed to promote. Thusly the system will have been corrupted.
Not necessarily. iRate uses a collaborative filtering rating system, which results are computationally personalized for every user. This means that, even if there are people creating dummy profiles, that if you don't like the music promoted by these "interests" then they will not influence the recommendations that you get. (And if you do like the suggestions of these "dummy" profiles, well, then the system is working as expected).
But Python is a language intended to be meaningful to humans. That's the difference with your usual programming language, and that's why Python needs the tab/space awareness.
The lightsabers will be replaced with pogo sticks!
Interesting application. Is a Windows implementation of the "command" feature of the interface described in The Humane Environment.
But that assumes that your mathematician have the will and the knowledge to "invest it wisely"; it is perfectly possible for the matematician that the "invest money" is not at all an interesting one and that the imposed burden of following stock prices and market trends would make it a pain in the ass. If that is case a grant will be much more desirable since it will be given to you for achieving results in precisely the math problems that you like.
Actually doing that is not a scientific requirement at all. Economics, for example, doesn't require that kind of analysis; it keeps "human actions" as an indivisible object of study, and build a (somewhat) successful theory in top of it.
Reductionism is not the only way to proceed on science. As Sycraft-fu points out, the only required thing is testability - the possibility to build experiments that can disprove your current theory.
I would add that strict logic reasoning is a must, and analytic separation of a fact in its composing parts is a natural way to progress. But science doesn't implies that everything must be decomposed that way, and that humans "are built from the basic building blocks and chemicals". Science is also able to adopt "holistic" (systemic) procedures. See Complex systems and systems theory for some examples.
In this "generalised" theory of money, there is nothing that implies that the planned acts should be that of exchange. For example, slashdot moderation points are a kind of money certified and managed by the /. site owners; but these points are not tradeable and are not useable outside of this web.
"flashlight separate from weapons" is part of the gameplay. Live with it.
That's only because you're not editing them with the proper tool.
The next version of Mac OS X will have an application to program automatic tasks with a GUI, without using AppleScript.
But the iTunes version still is native for Windows, which is what the gp stated.
How many times do those guys fall from their segways? What is the maximum speed of this vehicle? I think it could be very painful and injure-prone to drive one of those on a street as it is intended.
So, you're saying that the meaning of life, the universe and everything is blindingly obvious????
Then the software should be developed according to both it's users and it's contractors. Sure the management want their workers to be as most productive as possible, so they should specify what the software should accomplish and let the 'how' decisions to the usability engineer, who should do early interaction prototiping.
Not true. At least, as far as we know according to his words:
However, halfway through, someone called and needed another feature/field. Then another call. And another.
His users wanted (not needed!) those features, and did not specifically define them before the project started.
And how do you decide whether or not the need the features they want? That's basically the problem that they specifically should have defined before the project started.
If the users are constantly changing their minds about what they want
That's a disrespectful attitude towards your users. Usually the users know quite precisely WHAT they want (and even have been doing it for years), is just that they don't know HOW a computer can help to achieve it more easily.
That's the problem an interaction designer must overcome by interviewing her users, watching their 'analogic' process and doing interface prototiping. Only after the problem is well known by both the users and the developers a good design can be achieved. The strategy of doing "basic" things and then adding bells and whistles simply doesn't work well, as (for example) Microsoft products show.
Good rant! ;-) But that only applies to software designed to by used by its programmer. (It doesn't need to be open sourced, nor all OSS is meant for that use). My points are valid for software designed to be used by other people who don't want to learn the inner details of the whole system (something that OSS can be).
Now, once it's working, then refine and refactor to make the conceptually-simple things simple.
That could be a good idea if not for the fact that it's impossible to build a good UI with that strategy. Refine & refactoring is a software design strategy, which leads to good code structure and maintainability; but for good interaction design, the only valid strategy is early prototiping with real user testing (or major software redesign: dropping completely the old interface and building a new one from scratch). The user conceptual model for an application is the first thing that must be precisely defined, before writing a single line of code or class diagram; and this user model will be different from that of the implementor.
Sadly this is a fact that seem impossible to teach to most OSS developers; and even when they try to put user feedback, they do it in a wrong "feature bloat" way instead of a proper goal-task-tool analisys.
I maintain that 99.99% of config options could and should be solved by redesigning the interface. In the case of window focus, probably the best solution is to get rid of the windowing paradigm (which in my opinion has exceeded too far it's useful lifespan).
Read "The humane interface" if you want to learn about a successful interface built from the ground up without windows nor pointing devices. The resulting system is very near in concept to the Command Line interface, but whit 30 years of usability lore added in it; and "Zoomworld" could be a nice replacement for almost all situations where a desktop is better than a command interface.