BigBlueHat

Brad and I have been discussing web architecture, programming methodologies, and frameworks recently. REST is certainly our architectural style of choice, and the edge of the diving board for the necessary shift in thinking gets closer daily.

During our discussions over the last several weeks, we’ve learned a few great things:

1. We want to build what’s next — not just buzz or hype, but what you want next or the next thing that would make your life easier.
2. It will likely be semantic, addressable, and built on technology from the early 1990’s — when TBL envisioned the Web, his initial idea was to make it both readable (as it is now) and writable (as it’s slowly becoming). Our objective is to fulfill that with the products we build. In addition, the more meaning (semantics) and “future-proofing” we can throw into the mix, the better for all.
3. Friendly, documented, simplicity should describe all we do — simplicity takes more education, intention, and forethought than complexity, but the payoff is unparalleled. Because education is needed, the more obvious and documented the functionality of a program, the more usable the program.

With those items in our heads, we’ve begun looking at the way we write, code, and manage our time and resources. Sometimes its painful to compare what you’d like to be doing with what you’ve done, but the value of the analysis is valuable beyond quantification.

What triggered this post was a quote I found today while looking for something else:

When people ask me what I do for a living, I say that I research what the web of the future could be. At that point, they ask me to give them an example of what that would mean for them. My usual reply is “if we are successful, the only difference you’ll perceive is that you won’t feel as constantly lost as you feel today”. At that point they smile, happy to meet a technologist who thinks it’s his fault, not theirs, if they can’t do something with his software.

No matter what technology or platform we build the future of the web upon, we need to learn how to write the software that delivers those smiles: anything short of that will be a failure.

from Piggy Bank, Cocoon and the Future of the Web

It’s a sentiment we share, and one we’re hard at work attempting to achieve. We’ll share more about how we’re getting closer to our goals as we work/fight our way to them.

Resource Description Framework (or RDF) is something that’s long held my interest. RDF stores things like we thing in triples. Triples are very similar to sentences. They have subject (resources), predicates (traits or aspects that express relationship to the object), and objects.

Without going into to much more technical information, imagine that your computer had access to data stored in a similar method that your mind stores information (once you know a language anyway). Applications could then create relationships between things that have similar subjects, predicates, or objects–”if the sky is blue, what else is blue?”

In the book, Practical RDF, I picked up this “rule of thumb” for when to use RDF:

Use RDF if “the data is of interest, descriptive, and not easily discovered by any other means.” — page 11, Practical RDF

That said, RDF seems to be best suited for data that’s not available in the document, but that the computer may need to know about (now or later). Things like “last modified,” “program used to create,” “mood of author upon creation of piece,” or whatever.

As the “Semantic Web” (or “Web 3.0“) finally begins to become a reality, you may run into the letters, RDF, as you wonder around the web. In any case, RDF will likely form the backdrop for many programs you use. If you’re using Mozilla Firefox or Thunderbird, it already does.

I personally hope to see RDF take a bigger role in our data processing and distribution as the web becomes more open and useful for more than just browsing.