I got an interesting comment from Edwin Stauthamer on my last post about my little epiphany about the semantic Web: 

When I saw the title of your post I thought I finally found a post that could explain what the semantic web is.  Instead of that I read a post about how you found out the fact that the semantic web consists of some technologies and insights you already used and know about for years.

I think this comment is interesting for a few reasons:  It’s pretty obvious that Edwin has heard of the semantic Web, but has very little practical idea about what it is, and also that he’s not aware of what it DOES.  Does is the most interesting part to me, because the “is” is just a means to an end.  I also think that Edwin's view is typical of a lot of people's, definitely very similar to mine up until recently.

So I’m going to take a crack at this.  I know that my definition probably won’t match what you’ll see if you look it up in Wikipedia, but I’ll give you my impression of the core ideas—in probably an unusually object-oriented way, because that’s how my brain works.  Going from simplest to most complex, here's how I view the functionality of the Semantic Web:

• Identifying data objects using URI’s.  This is one of the core tenets of the semantic Web, if not THE core tenant.  It enables everything else.
• Showing objects as they need to be shown.  This means that when you request an object’s data, you get its data.  When you request a visual representation, you get a visual representation.  Same object, usable for different purposes.  (Technical enabler:  content accept HTTP headers)
• The ability to either use property types defined by other people for your objects, or to make up your own brand-new ones if you prefer.  The properties that you use from other places are capable of interoperating with other data on the Web even if the rest of your object doesn’t match.  (Technical enabler:  RDF)
• The ability to define some pretty complex classes with some pretty specific structures. (Technical enabler:  OWL)
• The ability to expose object methods.  This one gets lost in the shuffle, but essentially what it means is that you can set the property of an object so that it points to a Web service endpoint of some type which is functionally equivalent to a method for the object method in a traditional object oriented programming language.  (Techinical enabler:  RDF, RDFS, OWL, SAWSDL and SA-REST)
• The ability to create associations between objects, even to the point that something (probably software) reading the data can see that data associated with one URI is really the same as data associated with another URI (for example, the entity which is referred to by <http://dbpedia.org/resource/Tim_Berners-Lee> is the same as <http://www.w3.org/People/Berners-Lee/card#i>).  It also means that an object property can derive its value from data associated with another URI.  (Technical enabler:  HTTP)
• The ability to crawl through the node structure (data graph) to find data, discern information, and infer facts to understand what it all means (Technical enabler:  all of the above, plus query language and inference engines)

This is a gross oversimplification of things, and I probably butchered the terminology, but it’s what would have made me say “aha” when I saw it a month back.  This really doesn’t touch on how any of this is actually used (use cases), because there are just so many different ways that it would make your head spin.  The way to actually use all of these components could easily fill a book (and they have!)  I tend to think of it as distributed object-oriented programming on steroids, with a distributed database and a cherry on top.

Hope that answers your question a little better Edwin.