An XML namespace maps some URI to a local name you use in your XML document when defining elements.  In RDF/XML, they might refer to a particular URL where a vocabulary has been published, but that isn’t a requirement. It really just needs to be some valid URI- whether it is a URL or URN doesn’t matter, since the parser doesn’t look up that link.  To define this mapping, simply put the “xmlns” attribute on any XML node using the namespace you are defining. Namespaces are often declared in the document’s root element so they can apply to the whole document. This common practice leads to the misconception that xmlns attributes must be in the root, but that isn’t the case, they can be placed in any node in your XML document.

Namespace Syntax

The basic syntax for this attribute is:

xmlns:localName = “http://www.myuri.com/path”

Once that is done, whenever you define an element in your XML doc, you use the local name prefix on it, like so:

<localName:myNode></localName:myNode>

Since that can get verbose, you will find in practice that the local name is often only one or two characters long.

It is possible to specify a namespace in an XML document and not add the localName portion when you define it, like so:

xmlns = “http://www.myuri.com/path”

This is now the default namespace for everything under it.  Other namespaces can still be used, but when a localName isn’t specified that is the assumed namespace for all elements that don’t explicitly declare the local name.

That’s all there is to it.  Now your XML document can have element names that don’t collide. When combined with the semantic web notion of vocabularies, and using XML to express RDF, namespaces provide an especially elegant solution. You can create an RDF/XML document that draws from many different vocabularies and not worry about confusion because each vocabulary has its own namespace.

An Example

I’ll finish up this post with a simple XML namespace example published by the W3 Schools.

<root
xmlns:h="http://www.w3.org/TR/html4/"
xmlns:f="http://www.w3schools.com/furniture">

<h:table>
  <h:tr>
    <h:td>Apples</h:td>
    <h:td>Bananas</h:td>
  </h:tr>
</h:table>

<f:table>
  <f:name>African Coffee Table</f:name>
  <f:width>80</f:width>
  <f:length>120</f:length>
</f:table>

</root>

If you care about global climate change, reducing fossil fuels should be a priority- so add plastics to your list. But even worse than the resources it takes to produce plastic, is the time it takes for that plastic to break back down. In human terms, this is never. All the plastic stuff you have sitting around you right now will likely still be in that same form (at a molecular level) when you die, and will remain intact throughout your children’s and grandchildren’s lives.  Where does all this go? Landfills and the Great Pacific Garbage Patch.  When it is sitting in the ocean, that plastic breaks down into polymers and poisons the ecosystem.

The thing I’m finding so alarming about plastic is the lack of awareness or concern for this giant problem.  Sure we have a lot of ecological challenges, but there are lots of people working on the energy production problem or wildlife conservation. I don’t know any professional organization dedicated to this plastics problem, and manufacturers just keep cranking out plastic goods- then packaging them in plastic!

What can we do? First is to simply bring awareness to the issue.  Once you can see the plastic surrounding you and think of the implications of that, you might change some of your buying habits. Alissa Hansen has been able to take this to an extreme- the Hansen family consumes almost no plastics, which is an interesting and difficult experiment.  Just try to not consume plastic all day.  The difficulty of doing that will illustrate just how pervasive plastic is, and the difficulty in trying to live “plastic free”.

Recycling you say?  Sadly, few plastic products can be fully recycled, something they don’t often tell you. I’ve been recycling for years and thought that was good enough, but it turns out that only types 1 and 2 can be recycled, and even those have some issues. You may have seen the newer, plant based plastics- Starbucks uses it for Frappacino cups. It can biodegrade, which makes it much, much better than petroleum based plastics. That is the type of innovation we’ll need to reduce the giant island of trash in our ocean.

But yes, ultimately I too am a hypocrite- we have plenty of plastics around my house. Just taking a shower this morning, I could count 3 plastic bottles around me. We still buy orange juice (if you don’t want to squeeze it yourself, you pretty much can’t find non-plastic containers to buy OJ in). But you know what? I- you- the world- can’t change all at once.  Like it or not, plastics and cheap disposable plastic goods and packaging are part of our infrastructure. What we need to do is change that infrastructure- something that can only be done though time, perseverance, and consensus.  I want manufacturers to use less plastic, finding eco-friendly alternatives. I don’t have the time to make everything from scratch and remove myself from the supermarket economy. Most of us don’t.

So then, what can you do about it? Here are a few ways you can help start the reversal of this ecological calamity:

1. Use all plastics you already own to their full extent. Ideally, items like Tupperware can last your entire life.  Other items, like resealable plastic bags can be used at least several times before they need to be tossed.
2. Look for alternative packaging.  While we still buy OJ, there are other products like Peanut Butter, where you can reward companies that use glass over plastic. If everyone did this, manufacturers would certainly get the message and use paper, glass, and metals instead of plastics.
3. Spread awareness.  Even if you don’t blog, you can bring up the problem with family and friends. I’ve done this within my own family, and like me, they see the world a little differently after bringing consciousness to the plastic abounding around them.
4. Recycle. Yeah, I know its not perfect, but it is better than nothing. You should be recycling all your glass, tin, and plastics. I send all plastics to the recycling plant, and let them sort it out. Meaning, I don’t analyze the plastic number (1 and 2 can be recycled, but you will find all sorts of numbers of plastic). I figure at the very least I’m putting pressure on recycling plants to push for more 1 and 2 plastics.
5. All the little things.  Like, we bring bags to the grocery store- and even if we didn’t we’d opt for paper over plastic. When you go out to eat and order a soda- ask the waiter to not bring that plastic straw. Or if you don’t finish your meal, see if there is a non-plastic (including Styrofoam) box for the leftovers. Even better, bring your own container. Opportunities to reduce and eliminate plastic use happen all the time, it just need to occur to you to do it.

Looking around me now, I can see so many plastic products- my keyboard, the mouse, the computer tower, my headphones, my reusable Starbucks cup, even some decorative R2D2 Pez dispensers. All that and more in 3 square feet of office.  All of that is a problem, I admit, but for now I’m going to take care of these items and use them until they cease to function. In the meantime, I consider disposable plastic packaging enemy #1. That is the first beast of the plastic horde we must slay. But to do that, we need more people to join the battle.

Like many powerful concepts, RDF is fundamentally simple but can get quite complex in implementation. Many available articles focus on these intricacies and complexities. My intention in this article is to clearly and simply describe RDF in its most basic and abstract form.

First, consider a simple statement in English like, “This article’s author is Rob Dixon.” If you remember high-school English class, you might recall that sentences have a subject and a predicate. The subject is what the sentence is about- in my example that is “this article”. The predicate is the information about the subject, so in this case “author is Rob Dixon.”  The word “author” is called the simple predicate (in RDF, this word is actually called the “predicate”, so don’t get confused by the terminology).  The last part of the sentence, my name, is the sentence’s object- that which receives the action of a verb. In my sentence the implied verb is “authored by,” so the object is me.

So we’ve taken the basic sentence, “This article’s author is Rob Dixon,” and have broken it down into three parts:

{subject, predicate, object}

This is an RDF triple.  The example sentence as an RDF triple is:

{this article, author, Rob Dixon} 

The information in the sentence can be expounded upon, and all you need to do is string together multiple triples.  So, “This article’s author is Rob Dixon, who lives in Denver” can become two triples: {this article, author, Rob Dixon} and {Rob Dixon, lives in, Denver}.

Pretty simple, right? It is, but you can imagine that once you start stringing many of these triples together they can form complex structures. That is why one of the primary ways RDF is visualized is with a graph, where subjects and objects are represented as shapes with the predicate displayed as a line connecting the two.

Another complexity is actually identifying what the subject, predicate, and object actually mean, without ambiguity.  In my example, I used the words “this article” to make it human readable, but that is in fact a poor way to identify the article.  It is much better to use the article’s URL: http://www.robdixoniii.com/introduction-to-rdf. A more useful RDF triple is then:

{http://www.robdixoniii.com/introduction-to-rdf, author, Rob Dixon}.

But when you think about it, you’ll realize that the other components of the triple have the same problem. What exactly do I mean by author? Which Rob Dixon? After all, there are many in this world. For this reason, every component of the triple can be a resource specified by a URI, like the URL of this article. In fact, the predicate must be a URI according the specification.  This is important, because we all know that English words have different meanings when used in different contexts. This set of resources used by some RDF graph is called a vocabulary.

Since it would be a hassle to always have to define your vocabulary, there are predefined vocabularies published by a variety of sources. One popular vocabulary is the Dublin Core. It defines many common concepts, like authorship, so you don’t have to. Technically, you don’t really have to define your vocabulary, just make it a URI.  So I could say my predicate “author” is “http://www.robdixoniii.com#author“. The fact that that URI doesn’t resolve to a resource doesn’t impact the validity of the RDF.

When completely converted into resources, the sentence “This article’s author is Rob Dixon,” turns into the RDF triple:

{http://www.robdixoniii.com/introduction-to-rdf, http://www.robdixoniii.com#author, http://www.robdixoniii.com}

Now we are back to a technical looking construct that doesn’t look so “semantic” anymore. It is though, just in a way a computer can interpret. There are ways to express RDF in more human readable formats and there are shorthand notations so you don’t see the full URI of each item in a triple, but I don’t want to go into written notations of RDF here- just know there are many.

At its core, there are four simple rules that define RDF:

1. An RDF triple is a subject, predicate, and object, in that order.
2. An RDF triple represents a complete and unique fact (in the formal logic sense, but practically the reason why URIs are part of the specification).
3. An RDF triple can be combined with other RDF triples, however that operation doesn’t change the meaning of any individual triple.
4. The subject component of the triple must be either a blank node or a URI. The predicate must be a URI, and the object can be a blank node, a URI, or a literal value.

A good way to practically define it, if not exactly explain it, is by listing specific technologies that fall under the semantic web moniker: RDF, OWL, SPARQL, RDFS, XML.  These are among the core technologies that facilitate the semantic web.  Frameworks and specifications that enable machines to process a web of data.  Understanding these technologies is akin to understanding just what the semantic web is, but it still doesn’t explain what the semantic web is, especially to a non-technical person.  If these technologies are to fulfill their full potential, non-technical people need to understand what the heck this semantic web is all about. Investors, business owners, managers, and even hobbyists could get great value out of this technology, but they won’t invest time or resources in a concept the don’t understand.  Having defined it twice already, I think the question still remains: what is the semantic web?

Buried in the Wikipedia entry is a good description: “The semantic web is a vision of information that can be readily interpreted by machines, so machines can perform more of the tedious work involved in finding, combining, and acting upon information on the web.” Terrabytes of data are published on the web daily, but the vast majority of it is configured for human consumption.  Machines can read the content, but they can’t relate it to other content or put it in context- at least without a human writing a program that does those things.

If you are a software developer, you are likely familiar with relational databases.  That’s because most modern business applications store their data in a relational database. The reason is that they provide awesome data fidelity- the program using the data can “understand” how items of data relate. If I’m building a music distribution application, I likely have individual items of data to represent a song, an artist, and an album. With a relational data store, my application can know that an album is a collection of songs and that an album is written by an artist.

The prevalence of relational databases in application development highlights the fact that not only is the data important, but its relationship to other data is just as important.  They work extremely well, but are limited- they model data for a particular domain, namely the domain of the application being written (in the example above, music albums).  This means that for my application to use any data, it must be imported into the relational database, which has a schema unique to the application, so someone must write an explicit mapping from an external source into the custom database.

Web services that return data are another popular data source, and they are typically interfaced using an application programming interface (API). At first it might seem that web based APIs fulfill the description of the semantic web as defined by Berners-Lee, and some of them indeed might, but it is generally not the case. Why? Because just like with the relational database, an explicit mapping will be created by a developer to interface with the API for their application.  Also, APIs are proprietary interfaces which return data in a format defined by whomever wrote it.  For machines to truly act “intelligently” data needs to be presented in a uniform manner, regardless of technology or application domain.

Another key aspect of the semantic web, possibly the most important, is the web part.  Both a relational database and a web-based API represent endpoints to closed, non-distributed systems. What we are talking about with the semantic web are applications that have the entire internet as a data source, and can make intelligent connections between that data, even though the application has never been programmed with the relationship explicitly. In short, we’re talking about building applications that can use the web like a human can.

Let’s say I wanted to create a web-based application that is the ultimate music research system.  I want it to know every album published, the credits for every track, all the artwork, and even song lyrics.  One approach I could take is to create a relational database and attempt to fill it up with all this data.  New music is published all the time and from a variety of sources, how can my application keep up? Furthermore, how does the data get from the Internet into my relational database? Traditionally, some sort of connector tool or importer tool is written for this purpose.  But new sites and data sources are created all the time, and creating a custom import mapping for each is a whole lot of work, and limits the data sources my application can use.

A semantic web application by contrast, could simply be told to use allmusic.com, amazon.com, wikipedia.org, iTunes, songlyrics.com, and many other systems known to have some authority on the subject of music and song publishing.  I could ask it, “What albums did Fleetwood Mac release in 1969?” and it would semantically connect the question to the data provided on those sites, aggregate it, and give me an answer.  When I see “English Rose” in the result set, I could then ask, “what is track 7 and who wrote it?”  Back to those data sources to come tell me: “Black Magic Woman” and “Peter Green“. You could keep going: “What are the lyrics to that?”, “Where was Peter Green born?”, etc. Unlike my relational database, which would certainly have boundaries (I doubt it would contain the birth place of every band member), the semantic web application can keep going, relating question after question, as long as the data sources it uses contains the data and relationships.  And many prominent sites, like Wikipedia publish their content in semantic formats and do contain all of this data.

The notion of an application understanding relationships between things without a developer explicitly defining them is an odd one to those of us used to developing traditional software systems, and exactly how that occurs is the secret sauce provided by the technologies I mentioned earlier: RDF, SPARQL, OWL.  However, it can be summarized in a word: metadata.

While a lot of progress has been made building structures semantic applications understand out of plain text (text to ontology), the ultimate promise of a semantic web does require some publishing guidelines. Publishers will ideally publish RDF/XML in addition to their human readable content. Detractors of the technology view this as a difficult barrier to widespread adoption, but I would point to protocols like RSS or ATOM.  Ultimately, publishing RDF/XML should be just as easy and ubiquitous as those syndication feeds. Any developer wanting to do so already has a wealth of tools at their disposal.

Although there are major content providers (like Wikipedia) that do publish data in a semantic web format like RDF/XML, it remains to be seen if these technologies will be universally adopted. One thing is for certain though: our current World Wide Web is dumb.  Its full of text, images, and videos that have no context or relationship to each other. Humans can sift through this data and make sense of it, machines can’t.  Google (and Bing) are about the closest thing there is, but even those amazing systems don’t make the Internet semantic.  As good as their algorithms are, the relationships they create between content on the web is imprecise.  It must be, because its the search indexing algorithm that is defining relationships.  In the semantic web, the content publisher defines them, in a very precise way.  Google at its best can only make assumptions based on the content of the page, the links in the page, and links to the page.  It would be much better if the publisher explicitly defined how their published data is related.  Then think of how accurate those search engines could be.

When people think about the future of computers, I think Star Trek comes to mind. In that universe, people can ask a computer any arbitrary question and get back an answer (or at least a request for disambiguation or clarification), not a giant list of possible places an answer might be, which is the state of our current web.  Furthermore, I can give that computer any arbitrary instruction like “make dinner reservations for me at the best French restaurant in town on Thursday sometime after 7PM” and it could do exactly that.

That future is not too far off.  Transcribing speech is something that even your smartphone can do well now.  Programs can parse that transcription into an ontology- a specific vocabulary in a context. Combining these with semantic web technologies to achieve those futuristic results is ultimately what we are trying to do.

URI vs. URL

A good place to start is with a special type of URI: the Uniform Resource Locator, or URL. How is a URL different from a URI? The answer is that a URL is a URI that you can provide to a system or program (like a web browser) and in return you get a resource (like a web page, image, or video). Its all in the name really, the URI is just an identifier, while the URL is a URI that specifies some resource. In other words, it locates a resource.  URIs in and of themselves do not necessarily specify a resource.

What good is a URI if it doesn’t specify a resource, you ask?  If it isn’t a URL, then the URI is a URN, a Uniform Resource Name. That is, it doesn’t locate a resource, but simply names one. This allows even non-digital resources (like physical books) to be specified using a URI.  A URI can be constructed using the ISBN number of a book. That URI is a URN, since it can name the book, but can’t locate it (even if the system knows the location, the program can’t physically walk down an isle and get the book for you, which is the intended meaning of “locate” here).

General URI Syntax

A common misconception is that the first section of the URI is for specifying a protocol. It actually denotes the URI’s scheme. Some very popular schemes (like http) are tied directly to a protocol (Hypertext Transfer Protocol), but this doesn’t have to be the case (the file scheme for example, isn’t tied to a protocol).

The most basic and abstract definition of a URI, as defined by the IETF is actually quite simple. The generic syntax (brackets denote optional parts) is:

<scheme name> : <hierarchical part> [ ? <query part>] [ # <fragment part>]

That’s it.  However things get complicated because schemes can define unique  syntax to be used on the right side of that colon, the only real rules being that they respect the ‘?’ and ‘#’ characters used to indicate the query and fragment parts. Anyone can create a URI scheme that fits their exact needs.  If intended to be a standard, that scheme can be registered with the IANA. Most schemes like to add the familiar “//” after the first colon, but it isn’t required. If you work on the web, you are probably familiar with the schemes: http, https, ftp, file, and mailto. There are many, many more: the Wikipedia page on the subject lists just how many there are.

Authorities and Paths

While the hierarchical part of a URI can be custom defined, in practice it often has 2 parts: The authority and the path.

The authority part specifies a hostname. On the web, this is typically a domain name or IP address. It bears mentioning that domain names themselves have their own syntax and specifications which are specified by ICANN (not IANA or IETF).  The authority part can also include login credentials or a port number.

The path is expressed using the typical “/” notation we are all used to, and is conceptually like directories in a file system. In some cases, paths do indeed correspond to a files on a server, but not as a rule. Often paths are meant to model some domain, as with REST services, but there are no rules for structuring paths. They are arbitrary logical hierarchies defined by whomever is designing them.

URI Diagram

Keeping in mind that schemes can be custom defined, the general URI format is illustrated (using an example URI from Wikipedia) below: