It's been years since I've created an ontology (in the computing/informatics sense) but I'm going to give some advice on creating them anyways. When creating an ontology, it can be helpful to connect it up to other related ontologies. In fact, I think this is a requirement for building the semantic web (taking 'ontology' in a broad sense). You may want to ground your ontology (i.e. connect it to more generic or foundational ontologies; towards upper ontologies) or connect it to well known ontologies increasing the potential usefulness and adoption of your ontology. Whatever the reason, there are benefits in doing so if you want the data that your ontology schematizes to be more easily and automatically reusable. The potential downside is that you are forcing your users to endorse the ontology you're connecting to. So how exactly should one connect their ontology into the ontology ecosystem?
Most ontologies out there seem to me to be part of a stack of ontologies built by a single group of people. The ontologies tend to build directly on top of each other, meaning "lower" ontologies directly reference "upper" ontologies. Since the ontologies are developed by a single organization, it seems to make sense to directly connect to them because the organization (arguably) knows exactly what they are attempting to represent or what they mean. The fact that organizations tend to keep their ontologies rather isolated may be caused by a fear to commit to ontologies they didn't create.
The way ontologies are (or at least should be) developed allows the possibility for changes and updates. To accommodate this, one should develop ontologies with versioning. This way, someone using your ontology won't ever have it change on them and the developers can still maintain and change the ontology by introducing new versions. It's as simple as adding a version number to your ontology's url.
But this brings up the problem we face by directly referencing other ontologies. Let's imagine you have an ontology X that makes reference to another ontology Y and that ontology Y has a newer version available. You're planning on updating a term in X to make reference to essentially the same term but in the newer version of Y to keep X up to date. So you update X to the new version of Y even though it basically hasn't changed its meaning. The role an ontology fulfills is to describe a certain subject or topic and this intrinsic meaning has not changed. Yet you still need to change your ontology. Under these conditions, no matter how much concensus is formed around the accuracy of your ontology, you will never know when it is stable. In fact, this leads to a cascading of updates and changes required by upstream ontologies that reference your ontology, and so on. This is not a distributed web-scale ontology design pattern. We need a way to decouple our ontologies.
So, is there a design pattern we can use to avoid these dangers and burdens of connecting to other ontologies? Can we do better than simply identifying good stable ontologies and directly referencing only those ontologies in our own ontology? Yes!
Introducing: Content vs Bridging Ontologies
The key to scalable ontology design is what I call Bridging Ontologies. You write your intended ontology without referencing other ontologies and then create a separate ontology that is mainly made up of owl:sameAs and rdfs:subClassOf relationships between your terms and the target ontology's terms. I call these ontologies Content Ontologies and Bridging Ontologies, respectively. You only need to update your Bridging Ontology when either the source or target ontology changes. The nature of a Bridging Ontology makes it useless for anyone to reference in their own ontologies, which stops any potential cascade of changes throughout the web of ontologies. Of course users would still need to use the Bridging Ontologies and would likely need to collapse/deflate the owl:sameAs relationships into single terms for most visualizing, processing, or reasoning purposes.
I'll go out on a limb here and say that every ontology anyone creates should be isolated in this manner. The vision then becomes a web of ontologies of small Content Ontology nodes that satisfy specific "semantic roles" and then Bridging Ontology edges definied between these Content Ontologies. Since you don't need to adopt all of the Bridging Ontologies that are built for a Content Ontology, it is much easier to reach concensus on the Content Ontologies and then to pick and choose your Bridging Ontologies, choosing to commit (or not) to exactly how that content fits into the big picture. This allows for decoupled semantics rather than traditional inflexible semantics.
Wednesday, December 1, 2010
Tuesday, November 30, 2010
The Universal Model
Imagine a computer model of the universe. The past, the present, the future, every event that has or will ever occur. This is The Universal Model.
Clearly there would be some major limitations on the quality this model. You can't have a perfect model of the present stored in the present (not to mention storing the past 13.7 billion years or the next googols of years predicted by our current best cosmological theories). What I have in mind is a kind of massive service where you can ask for information about the universe and retrieve those answers if they are available. The Universal Model is an abstract model that is, at best, partly built, as needed, in order to fulfill a query about it.
Let me try to flesh the idea out a little more. Imagine any system that needs to "answer a question" of some sort. Maybe you're typing a question into a search box. Maybe you're "asking" Google Earth to display a useful image of downtown Seattle. Maybe you're checking the weather for next weekend. Now, imagine a system that can fulfill the query in terms of questions about the way the universe is, plus some processing. In other words, imagine converting or compiling down the question into explicit questions about the universe. For Google Earth this could amount to rendering the image of what would be seen from a specific point and orientation above Seattle, right now. For the weather, you need to look at the 4D volume of space above the location you're at and from Saturday morning until Sunday evening. You'd then need to process the physical description to extract the amount of cloud and rain that's present, and then convert that into a label saying "sunny" or "partly cloudy" based on the context.
Now, again, since we can't store the whole universe, we need methods to fulfill the queries about The Universal Model. This could be done in a number of ways. If only a small subsection of the model is required, which would be the case in the vast majority of queries, then you could invoke specialized services designed to answer queries of that type. Queries about the nature of the weather on the weekend could be fulfilled by invoking weather models, for example.
Consider an analogy. When one wants to automatically translate a document from one language to another, one method would be to build a language-agnostic conceptual representation of the meaning expressed by the sentence and then to express that conceptualization in the other language. This solution would be extremely powerful because it preserves all relevant information and is scalable. (For any new language, you only need to be able to map it to The Language Model and then express that, in any language you want.) The downside of this approach is that we haven't been able to achieve any kind of mapping like this, partly because we don't know exactly what The Language Model would look like and because language is very context-dependent. Instead we build lower level representations, but not as "low" as The Language Model and then take a shortcut on that level of representation.
This is what would need to be done with The Universal Model as well. We take shortcuts while "translating" our query into an answer. This is a general problem for any sort of "conversion".
(Forgive the MS Paint). The boxes are representations of queries (red) and answers (green). As you get lower in layers, the representations are more abstract, more powerful, and more fully answerable. Each arrow is a conversion. The horizontal arrows are hacky conversions that skip the lower more ideal, powerful, but unobtainable layers and conversions. For both ideal models, we get as close as we can to the ideal, so that we can use "hacks" and shortcuts and ingenious tricks to jump to the other side of the gap. For the NLP example, the top layer could start with a document in spanish and end with a document in english. The bottom layer would be The Language Model.
If, like me, you believe that all propositions are made true or false by the universe, then in the case of The Universal Model, the top layer would be any coherent question. So even our idealistic Language Model could be seen as a special case "hack", albeit at one of the lower levels of this hypothetical universal question answering device, that has The Universal Model at the bottom. The Universal Model is the most ideal model possible.
That's the idea anyways; I'm not sure it fully holds up; Take it with a grain of salt; etc; etc.
I wanted to get the idea out there rather than dwell on it too much and then end up not posting anything. Please comment and refine and clarify the idea further for me if you find it interesting!
Clearly there would be some major limitations on the quality this model. You can't have a perfect model of the present stored in the present (not to mention storing the past 13.7 billion years or the next googols of years predicted by our current best cosmological theories). What I have in mind is a kind of massive service where you can ask for information about the universe and retrieve those answers if they are available. The Universal Model is an abstract model that is, at best, partly built, as needed, in order to fulfill a query about it.
Let me try to flesh the idea out a little more. Imagine any system that needs to "answer a question" of some sort. Maybe you're typing a question into a search box. Maybe you're "asking" Google Earth to display a useful image of downtown Seattle. Maybe you're checking the weather for next weekend. Now, imagine a system that can fulfill the query in terms of questions about the way the universe is, plus some processing. In other words, imagine converting or compiling down the question into explicit questions about the universe. For Google Earth this could amount to rendering the image of what would be seen from a specific point and orientation above Seattle, right now. For the weather, you need to look at the 4D volume of space above the location you're at and from Saturday morning until Sunday evening. You'd then need to process the physical description to extract the amount of cloud and rain that's present, and then convert that into a label saying "sunny" or "partly cloudy" based on the context.
Now, again, since we can't store the whole universe, we need methods to fulfill the queries about The Universal Model. This could be done in a number of ways. If only a small subsection of the model is required, which would be the case in the vast majority of queries, then you could invoke specialized services designed to answer queries of that type. Queries about the nature of the weather on the weekend could be fulfilled by invoking weather models, for example.
Consider an analogy. When one wants to automatically translate a document from one language to another, one method would be to build a language-agnostic conceptual representation of the meaning expressed by the sentence and then to express that conceptualization in the other language. This solution would be extremely powerful because it preserves all relevant information and is scalable. (For any new language, you only need to be able to map it to The Language Model and then express that, in any language you want.) The downside of this approach is that we haven't been able to achieve any kind of mapping like this, partly because we don't know exactly what The Language Model would look like and because language is very context-dependent. Instead we build lower level representations, but not as "low" as The Language Model and then take a shortcut on that level of representation.
This is what would need to be done with The Universal Model as well. We take shortcuts while "translating" our query into an answer. This is a general problem for any sort of "conversion".
If, like me, you believe that all propositions are made true or false by the universe, then in the case of The Universal Model, the top layer would be any coherent question. So even our idealistic Language Model could be seen as a special case "hack", albeit at one of the lower levels of this hypothetical universal question answering device, that has The Universal Model at the bottom. The Universal Model is the most ideal model possible.
That's the idea anyways; I'm not sure it fully holds up; Take it with a grain of salt; etc; etc.
I wanted to get the idea out there rather than dwell on it too much and then end up not posting anything. Please comment and refine and clarify the idea further for me if you find it interesting!
Saturday, October 9, 2010
Installing Node.js + DBSlayer on Windows using VirtualBox
Recently I've been interested in the idea of using server-side javascript because:
Unfortunately, installing all of this was more difficult than I had hoped for, especially because I'm developing on a Windows XP laptop and node.js currently only works in Linux. Fortunately, there are two tutorials that have been written for this exact situation, one for getting node.js onto an Ubuntu VM and another for installing DBSlayer on that same VM. But though these tutorials are pretty good, they didn't work perfectly for me. I'll go over the problems I ran into along the way in hopes that someone (possibly my future self) can benefit from the added tips.
A quick note: I'm relatively new to VirtualBox so I made one awkward mistake that must be quite common. I left my virtual Ubuntu installation CD in my virtual CD drive! If it looks like your virtual drive is not being fully used and it says your 3.1GB drive is full when you have a bigger than 3.1G drive then you've probably made a similar mistake. Took me 2 hours to figure that one out. I guess I should consider myself lucky.
The first problem with the first tutorial that I ran into involved OpenSSL. Along with the other few apt-get installs I needed to do a:
sudo apt-get install libssl-dev
When validating my node.js install using the helloworld.js described in the first tutorial, the script didn't work. The error I saw was:
/home/amcknight/node/helloworld.js:4
res.sendHeader(200, {'Content-Type': 'text/html'});
^
TypeError: Object #<a ServerResponse> has no method 'sendHeader'
at Server. (/home/amcknight/node/helloworld.js:4:6)
at Server.emit (events:27:15)
at HTTPParser.onIncoming (http:885:14)
at HTTPParser.onHeadersComplete (http:88:31)
at Stream.ondata (http:806:22)
at IOWatcher.callback (net:499:29)
at node.js:604:9
Instead I used the first hello world code shown on the node.js front page and everything worked out fine.
As for the second part of the tutorial for installing dbslayer, I recommend running
The error I was getting involved not being able to find a libapr-1.so.0 file. I'm not sure what exactly resolved this problem for me but I eventually started over (and found those two tutorials) and the only difference I can think of is that I used the apt-get update command and installed libssl-dev the second time around. So unfortunately I can't pinpoint the cause, but if it ever happens to me again I'll post a comment about it (or you can).
Other than that, the tutorial should work fine if you fingers are tightly crossed.
Ultimately, these are the relevant commands I ran, in order, and not including the validation steps that are explained on the two tutorial pages. From a clean install of Ubuntu 10.04, taking the steps below should get you up and running.
sudo apt-get install g++
sudo apt-get install git-core
git clone git://github.com/ry/node.git
sudo apt-get install libssl-dev
cd node
./configure
make
sudo make install
cd ..
sudo apt-get install subversion
svn co http://www.dbslayer.org/svn/dbslayer/trunk
dbslayer
sudo apt-get update
sudo apt-get install libapr1-dev
sudo apt-get install libaprutil1-dev
sudo apt-get install libmysqlclient-dev
cd dbslayer
./configure
make
sudo make install
sudo apt-get install mysql-server
dbslayer -s localhost -u root -x YOUR_PASSWORD -c void
- I've recently been introduced to jQuery which is an insanely powerful improvement over the javascript I became familiar with in highschool... like 10 years ago.
- The idea that I can use my (MVC) Model on the server and client side seems pretty elegant. I'd be able to send objects back and forth using AJAX without having two different implementations of the objects.
- The server-side javascript project that sparked my interest, node.js, just looks so easy. Building a web service should take no time at all and deploying the web service looks even easier. You just call:
node myjavascriptfile.js
Unfortunately, installing all of this was more difficult than I had hoped for, especially because I'm developing on a Windows XP laptop and node.js currently only works in Linux. Fortunately, there are two tutorials that have been written for this exact situation, one for getting node.js onto an Ubuntu VM and another for installing DBSlayer on that same VM. But though these tutorials are pretty good, they didn't work perfectly for me. I'll go over the problems I ran into along the way in hopes that someone (possibly my future self) can benefit from the added tips.
A quick note: I'm relatively new to VirtualBox so I made one awkward mistake that must be quite common. I left my virtual Ubuntu installation CD in my virtual CD drive! If it looks like your virtual drive is not being fully used and it says your 3.1GB drive is full when you have a bigger than 3.1G drive then you've probably made a similar mistake. Took me 2 hours to figure that one out. I guess I should consider myself lucky.
The first problem with the first tutorial that I ran into involved OpenSSL. Along with the other few apt-get installs I needed to do a:
sudo apt-get install libssl-dev
When validating my node.js install using the helloworld.js described in the first tutorial, the script didn't work. The error I saw was:
/home/amcknight/node/helloworld.js:4
res.sendHeader(200, {'Content-Type': 'text/html'});
^
TypeError: Object #<a ServerResponse> has no method 'sendHeader'
at Server.
at Server.emit (events:27:15)
at HTTPParser.onIncoming (http:885:14)
at HTTPParser.onHeadersComplete (http:88:31)
at Stream.ondata (http:806:22)
at IOWatcher.callback (net:499:29)
at node.js:604:9
Instead I used the first hello world code shown on the node.js front page and everything worked out fine.
As for the second part of the tutorial for installing dbslayer, I recommend running
sudo apt-get update
first to avoid any errors.The error I was getting involved not being able to find a libapr-1.so.0 file. I'm not sure what exactly resolved this problem for me but I eventually started over (and found those two tutorials) and the only difference I can think of is that I used the apt-get update command and installed libssl-dev the second time around. So unfortunately I can't pinpoint the cause, but if it ever happens to me again I'll post a comment about it (or you can).
Other than that, the tutorial should work fine if you fingers are tightly crossed.
Ultimately, these are the relevant commands I ran, in order, and not including the validation steps that are explained on the two tutorial pages. From a clean install of Ubuntu 10.04, taking the steps below should get you up and running.
sudo apt-get install git-core
git clone git://github.com/ry/node.git
sudo apt-get install libssl-dev
cd node
./configure
make
sudo make install
cd ..
sudo apt-get install subversion
svn co http://www.dbslayer.org/svn/dbslayer/trunk
dbslayer
sudo apt-get update
sudo apt-get install libapr1-dev
sudo apt-get install libaprutil1-dev
sudo apt-get install libmysqlclient-dev
cd dbslayer
./configure
make
sudo make install
sudo apt-get install mysql-server
dbslayer -s localhost -u root -x YOUR_PASSWORD -c void
Saturday, July 17, 2010
Philoinformatics Manifesto
I wrote this draft philoinformatics "manifesto" in April and have been meaning to polish it up and post it.
Yeah... it's July now.
I still intend to clean it up, but I decided to post my draft, as is, just to get it out there for now. Call it the beta version... actually more like alpha. All comments very welcome at this point.
Philoinformatics is a scientific, philosophical, and most of all an engineering discipline with the single goal of radically enhancing philosophy using information systems. If you're thinking about Artificial Intelligence that does philosophy for us then you've got the wrong (but awesome) idea. I'm talking about philosophy being done by people, but being done better, with the whole philosophical process being enhanced from end to end with helpful software made possible by underlying information systems.
We all need to recognize that philosophy as a discipline is devastatingly problematic and requires new life. Philosophy is known to lack proper resolution to patently philosophical problems and is fraught with pervasive disagreement among its experts, among other major problems. Just consider the thousands of man-years of thought put into the Free Will and Determinism topic, for example. Many philosophers do recognize that these and other problems exist and even usually spend some time thinking about them and/or joking about them, but also essentially practice a kind of denial about there existence. Maybe it's because doing philosophy still feels important and individual philosophers are making personal progress in the sense that they are acquiring and refining their own philosophical concepts. Philosophy is a slow and difficult process and philosophers are wasting the vast majority of their time doing what I believe they themselves would agree is a waste of their time if they only had a better way to view the actual landscape of philosophy; the landscape of the content of philosophy.
Despite this heavily pessimistic view of philosophy, I am not advocating for Skeptical Metaphilosophy, the view that philosophy does not have intrinsic value. I also, of course, don't claim to be able to reliably recognize when I or anyone else is specifically wasting their time doing philosophy. What I am advocating is that we build the systems required to show whether there is, where there is, and when there is valuable philosophy to be done. After thousands of years of philosophers spinning their wheels on philosophical problems, I think it's fair to suggest that some focus needs to be put into novel methods for making discipline-wide progress. For those that are able, instead of spending time refining one's own philosophical positions and attempting to make personal philosophical progress, I advocate putting some work into progress for the discipline as a whole.
Speaking of traction, actually imagine a wheel spinning on a road. The wheel spinning is the effort of philosophers and the forward motion is the progress of philosophy. If philosophy isn't making progress because of the nature of the content of philosophy (e.g. "words on holiday" or some other confusion) then that means our wheel is slippery, the problem is intrinsic. If instead philosophy isn't making progress because of the way philosophy is done or the current environment of philosophy (e.g. pervasive repetition of ideas or high barrier to entry for publishing or unknown status of philosophical positions) then that means our road is to slippery, the problem is extrinsic. For progress we need traction, for traction we need both the wheel and the road to have grip. Skeptical Metaphilosophy is the view that our wheel can't be made grippy. Naturalism could be construed as the view that scientifically supported positions are are the only grippy parts of the wheel. Both are about the wheel, philosophy itself. Philoinformatics is an attempt to give the road grip. Set up an environment where philosophy can make all the traction it possibly can. Of course, the wheel could be incurably slippery and giving the road grip won't help, but at least now you know where the grip is missing. In other words, Philoinformatics at bare minimum can provide evidence for or against Skeptical Metaphilosophy.
Philoinformatics is an attempt to face the problems of philosophy head on by building mechanisms for helping people understanding the actual landscape of philosophy. Actually, I intend Philoinformatics to be more general than what I've been advocating. Here's the more general form:
1) Identify Symptoms
2) Identify underlying qualities giving rise to the symptoms
3) Design Systems to modify that quality of philosophy
4) Develop the Systems
As simple as these steps may sound, all four of these steps are quite difficult. You might also notice that despite what I started out saying, Philoinformatics doesn't necessarily need to radically enhance philosophy. Any enhancement will do and would count as work in philoinformatics. But I stand by the "radically" part of the goal because I think philosophy requires radical enhancement and I hope philoinformatics is an avenue for getting us there.
Yeah... it's July now.
I still intend to clean it up, but I decided to post my draft, as is, just to get it out there for now. Call it the beta version... actually more like alpha. All comments very welcome at this point.
Philoinformatics is a scientific, philosophical, and most of all an engineering discipline with the single goal of radically enhancing philosophy using information systems. If you're thinking about Artificial Intelligence that does philosophy for us then you've got the wrong (but awesome) idea. I'm talking about philosophy being done by people, but being done better, with the whole philosophical process being enhanced from end to end with helpful software made possible by underlying information systems.
We all need to recognize that philosophy as a discipline is devastatingly problematic and requires new life. Philosophy is known to lack proper resolution to patently philosophical problems and is fraught with pervasive disagreement among its experts, among other major problems. Just consider the thousands of man-years of thought put into the Free Will and Determinism topic, for example. Many philosophers do recognize that these and other problems exist and even usually spend some time thinking about them and/or joking about them, but also essentially practice a kind of denial about there existence. Maybe it's because doing philosophy still feels important and individual philosophers are making personal progress in the sense that they are acquiring and refining their own philosophical concepts. Philosophy is a slow and difficult process and philosophers are wasting the vast majority of their time doing what I believe they themselves would agree is a waste of their time if they only had a better way to view the actual landscape of philosophy; the landscape of the content of philosophy.
Despite this heavily pessimistic view of philosophy, I am not advocating for Skeptical Metaphilosophy, the view that philosophy does not have intrinsic value. I also, of course, don't claim to be able to reliably recognize when I or anyone else is specifically wasting their time doing philosophy. What I am advocating is that we build the systems required to show whether there is, where there is, and when there is valuable philosophy to be done. After thousands of years of philosophers spinning their wheels on philosophical problems, I think it's fair to suggest that some focus needs to be put into novel methods for making discipline-wide progress. For those that are able, instead of spending time refining one's own philosophical positions and attempting to make personal philosophical progress, I advocate putting some work into progress for the discipline as a whole.
Speaking of traction, actually imagine a wheel spinning on a road. The wheel spinning is the effort of philosophers and the forward motion is the progress of philosophy. If philosophy isn't making progress because of the nature of the content of philosophy (e.g. "words on holiday" or some other confusion) then that means our wheel is slippery, the problem is intrinsic. If instead philosophy isn't making progress because of the way philosophy is done or the current environment of philosophy (e.g. pervasive repetition of ideas or high barrier to entry for publishing or unknown status of philosophical positions) then that means our road is to slippery, the problem is extrinsic. For progress we need traction, for traction we need both the wheel and the road to have grip. Skeptical Metaphilosophy is the view that our wheel can't be made grippy. Naturalism could be construed as the view that scientifically supported positions are are the only grippy parts of the wheel. Both are about the wheel, philosophy itself. Philoinformatics is an attempt to give the road grip. Set up an environment where philosophy can make all the traction it possibly can. Of course, the wheel could be incurably slippery and giving the road grip won't help, but at least now you know where the grip is missing. In other words, Philoinformatics at bare minimum can provide evidence for or against Skeptical Metaphilosophy.
Philoinformatics is an attempt to face the problems of philosophy head on by building mechanisms for helping people understanding the actual landscape of philosophy. Actually, I intend Philoinformatics to be more general than what I've been advocating. Here's the more general form:
1) Identify Symptoms
2) Identify underlying qualities giving rise to the symptoms
3) Design Systems to modify that quality of philosophy
4) Develop the Systems
As simple as these steps may sound, all four of these steps are quite difficult. You might also notice that despite what I started out saying, Philoinformatics doesn't necessarily need to radically enhance philosophy. Any enhancement will do and would count as work in philoinformatics. But I stand by the "radically" part of the goal because I think philosophy requires radical enhancement and I hope philoinformatics is an avenue for getting us there.
Subscribe to:
Posts (Atom)