Conceptual Space Markup Language (CSML)

I've recently come across a great paper by Benjamin Adams and Martin Raubal called Conceptual Space Markup Language (CSML): Towards the Cognitive Semantic Web. I found their paper interesting on many levels because it lies at the nexus of many rather diverse topics that I’m interested in. CSML directly involves Computational Geometry and the Semantic Web, but indirectly involves the philosophy of meaning, mind, and color. Also, as it grows in popularity, I believe force-based organizational algorithms and neural networks will become a heavily used mechanism for generating and using CSML data. Basically, CSML takes Conceptual Spaces, which are already at an interesting intersection of multiple mind sciences and multiple strands of philosophy, and connects it with multiple threads of engineering and informatics.

Wait.
What are Conceptual Spaces?

Conceptual Spaces are multidimensional spaces made up of quality dimensions. Quality dimensions are basically just any property you can think of that has a (pseudo-) continuous range of values. Think: size, mass, brightness, beauty, craziness, unicornity or anything else that you think you can make sense of on some sort of numerical range. You can now consider points and (convex) shapes within your set of quality dimensions, which will correspond to concepts. Consider the classic-cool-colour-cone example to the lower right. That’s a representation of a conceptual space with quality dimensions of hue, value, and saturation. 

But this isn’t just a fancy mathematical model. Structures like this are in some sense actually “held” by neurons in your brain. You may have heard people talk about "levels of reality" (or "levels of description of reality") such as the physical level, biological level, psychological level, sociological level, etc. Well, the idea is that when you look into the brain, which is (of course) very complex, you can look at it "at different levels" (presumably of granularity in this case). Conceptual Spaces are one of those lesser-known but very useful levels between the neuronal level and the psychological level (and below the symbolic level if you think there is one). Other people have much more comprehensive and informative explanations that I’m not going to try to repeat here. If you’re interested in the multitude of potential philosophical implications check out Paul Chruchland’s State-Space Semantics and Meaning Holism. (He’s also got some good stuff to say about colors outside of the classic-cool-color-cone here.)

CSML describes Conceptual Spaces

CSML, the Conceptual Space Markup Language, is an XML serialization of conceptual spaces. CSML brings a whole new engineering dimension to conceptual spaces which fits into the realm of Semantic Web technologies and is actually analogous to OWL, but with radically different implications. In my previous post, which was actually written in June 2008, I dreamed of a “smooth semantic web” that didn’t always require rigid categorization. CSML looks like a better candidate to handle that kind of data. CSML is specifically designed to handle context-dependent meaning and (relative) similarity of concepts, which are both difficult to handle in OWL. (How would you represent a large squirrel and a tiny planet consistently? What about brightness, beauty, craziness, and unicorniness?) After trying to use a few units ontologies for measurement data (at iCAPTURE for Mark Wilkinson) I also have high hopes that CSML can help simplify the problems on that front.

The most exciting part for me is that conceptual spaces lend themselves to fancy techniques for being automatically generated by way of artificial neural networks and force-based organizational algorithms, which brings in a few more of the theoretical engineering topics I’ve been interested in over the years. Starting with similarity data, force-based (or tension reduction) algorithms could help identify quality dimensions. Neural networks can nicely use quality dimension coordinates as input and also learn to precisely place items into conceptual spaces. I can’t wait to see the tools that will be created to allow for generating, reasoning over, and visualizing CSML data and how they will integrate with existing semantic web technologies and machine learning techniques.

Towards a Smooth Semantic Web

This is an almost complete draft I wrote almost 2 years ago. I thought I should publish it because it is basically complete, and because my next post will be about the new language and technologies that will make the "smooth semantic web"  a reality. And for the record, 'smooth semantic web' was a provisional name to be changed before publishing.
Here it is:

The Semantic Web is slowly building up and will eventually grow to a critical mass where it will become useful. How useful is another question. Will it revolutionize the web? Web 3.0? Maybe. Maybe not. But it will definitely have a use and an effect. The current standards such as RDF, OWL, SWRL, SPARQL, and SKOS are good, and still have a ton of potential that is growing exponentially as we speak. But these standards are not enough. OWL and SKOS can only capture so much knowledge. They can capture crystalized categorizations of well defined concepts. But much, if not the vast majority, of knowledge is not found in strict categorization and necessary relationships. So what is missing?

People have made attempts to extend OWL in a few different ways to make it cover a wider range of statable knowledge. People have looked into adding probability, non-monotonicty (time), belief. I propose a different addition which, if adopted, would add a prior layer to OWL, just as the above attempts do.

Consider a music ontology. OWL can support certain relationships such as: Rock ISA Genre, Track isPublishedOn CD, etc. But the certain pieces of knowledge cannot be represented because they haven't been crystallized to the point of being definable, especially when you consider the categorization of instances. Imagine the daunting task of deciding whether certain border line songs count as belonging to a specific genre. But consider the task (still daunting, but not as much) of deciding whether a song is "better classified as Rock than Rap" for instance. It may be difficult to say that a song is Rock, or is Rap, but it may be clear which one it is closer to. Much more can be said.

Notice that we are not talking about probabilities here. It isn't semantically correct to say that a song is "more likely" categorized as Rock than Rap. We are saying that if we were to categorize it as either Rock or Rap, it would be better categorized as Rock than Rap.

You may be wondering what the criterion for "better" is or should be. This itself should be represented within a knowledgebase.

So how would we use this knowledge? SWRL and SPARQL can only handle deductive reasoning, so they won't help. There are two options, the way I see it. Take my smooth knowledge and use some kind of classifying step to derive a regular rigid knowledgebase. The other option is to invent smooth reasoners. I think vector space representations and abduction would be important for this step.

Getting rough data into the semantic web

It's nice when regular relational databases, excel spreadsheets, and other sources that people have created can be attached to the semantic web. But there are problems with the way most data is recorded, especially for data about time. In short, the problem is that people round values. This may seem like a trivial unimportant problem, but I don't think so if you want to be able to use the rough data that makes up most of the world's data. Here are the issues:

1) Datatype granularity. Datatypes allow for a wide range of possible values, but not all values. We may need to know in some situations whether the data value written is an exact match to the value that was intended. For instance, 1/3 can't be represented fully as a double and 3pm today can't be represented as a date without dropping the 3pm part.

2) Granularity used vs datatype granularity. This is a much bigger problem than (1). People often write things to a granularity that is much less fine grained than the datatype granularity. For instance, you may be recording distance to 2 decimal places and storing it as a float. This needs to be taken into account for situations where values are compared. We don't want to say that two things have the same height just because they are almost the same height. Also, people round times to the minute, 5 minutes, 10 minutes, 15 minutes, hour, and many other ways. Are they rounding down? Are they rounding to the nearest? Some other recording method?

An ontology that has commonly used recording methods to describe the data recording process would allow more justified inferences about the data to be made. This would allow a higher level of trust (in the second sense, explained here) when using the data which is going to be of great importance as the semantic web grows.

Pellet + OWLAPI + SWRL

I've found over the last couple of months that there are a LOT of different ways to mess up when trying to use SWRL, Pellet, and OWLAPI. I'll try to list everything I can remember getting stuck on or potentially getting stuck on. Feel free to add your own by comment.

Java Heap Overflow errors:

1. remember that you can add more memory to java in Eclipse for a single project by going to Run -> Open Run Dialog -> Arguments and then adding -Xmx1024M to your VM Arguments (or some other value instead of 1024).
   
   
2. A great solution is to break your data into separated named graphs where you know the information will not be important between the graphs. For me, this fixed everything (especially in FaCT++ where it fixed speed issues as well). I had data about patients that I knew were not the same patient, and I reason about each patient one at a time.
   
   
3. Still not enough? I'm not sure what to say yet, but I have some extremely unthought out guesses: try KAON2 because I heard it scales better (but might only scale for speed), try a database backend with an rdf to sql mapper (such as D2R Server), and try OWL-Lite (if expressive enough for you). None of these guesses might do anything to fix your problem, but they are what I'm going to try next if I hit this problem. Please tell me if these options would or wouldn't help.
   
   
4. If you're using SWRL rules, try the Rete algorithm (if using a version of Pellet pre-1.5.2). Turn Rete algorithm on by writing this line: PelletOptions.USE_CONTINUOUS_RULES = true;
   I've heard there are some specific cases where this algorithm is slower, but it usually isn't.
   
   
5. This probably won't happen to you because you are smarter than me. But make sure when you are trying to write "facts" between individuals you don't refer to classes. Write it like this:
   axioms.add( factory.getOWLObjectPropertyAssertionAxiom( personInd, hasWeightOP, weightInd ) );
   
   and not like this:
   OWLObjectValueRestriction hasWeightTheWeight = factory.getOWLObjectValueRestriction( hasWeightOP, weightInd );
   axioms.add( factory.getOWLClassAssertionAxiom( personInd, hasWeightTheWeight ) );

SWRL rules just won't work:

1. Is your SWRL rule Safe? I saw a few different definitions of "SWRL rule safety" but the one that seems to be right is: Make sure all individuals that are involved are explicitly added! For example, if you have a rule like this:
   Person(?x) ^ drives(?x,?y) ^ Car(?y) -> Driver(?x)
   and you have an instance of person which is also an instance of "drives some Car", but you don't have an the instance of Car that he drives explicitly added, the rule will not return the person instance as a driver instance. For more check this part of the ProtegeWiki: SWRLLanguageFAQ.
   
   
2. Simplify rules as much as possible. Don't use negation (NOT) and don't use disjunction (OR). I've never had a problem with this, or even tried it, but I seem to remember people having problems with this... somewhere.

Reasoning takes too long!

1. I'm still working on this... but reducing expressivity can't hurt. It sounds like OWL-Lite would make a huge difference for speed, but you have to sacrifice so much that personally, it doesn't seem like it's ever worth it unless you want structured tags and don't care about answering queries.
2. Try FaCT++. It was orders of magnitude faster when I used iterative reasoning as explained above.