Without a doubt, the URL vs. URI post is by the most visited page on this blog. Even so, there’s still a lot of confusion on the topic and so I thought I’d break it down in less words. The original post was slightly misleading in that I attempted to compare URI to URL, when in fact it should have defined the relationship between URI, URL, and URN. In this post, I hope to clear that in more concise terms. But first, here’s a pretty picture:

Remember that URI stands for Uniform Resource Identifier, which is used to identify some “thing”, or resource, on the web. Both URLs and URNs are specialization’s (or subclasses if you will), of URI. You’d be correct by referring to both a URL or URN as a URI. In applictaion terms: if your application only calls for an identifier, you should be free to use either a URL or a URN. For brevity, you can state that the application simply requires a URI and the use of a URL or URN would statisfy that requirement.

Now if your application needs a URI that dereferencable over the web, you should be aware of the difference between URN and URL. A URL is location bound and defines the mechanism as to how to retrieve the resource over the web. A URN is just a name and isn’t bound to a network location. For example, you may have a URN for a books ISBN number in the form of urn:isbn:0451450523. The URN is still a valid URI, but you cannot dereference it, it’s just a name used to provide identity. So to put in simpler terms:

• A URI is used to define the identity of some thing on the on the web
• Both URL and URN are URIs
• A URN only defines a name, it provides no details about how to get the resource over a network.
• A URL defines how to retrieve the resource over the web.
• You can get a “thing” via a URL, you can’t get anything with a URN
• Both URL and URN are URIs as the both identify a resource

There some other items that need clarification based on some comments I’ve received from the original post:

• Elements of a URI such as query string, file extension, etc. have no bearing on whether or not a URL is a URI. If the URI is defines how to get a resource over the web, it’s a URL.
• A URL is not limited to HTTP. There are many other protocol schemes that can be plugged into a URL.
• If a URL defines a scheme other than HTTP, it does not magically become a URI. The URI defines how to get the resource, whether it be HTTP, FTP, SMB, etc., it’s still a URL. But because the URL identifies a resource, it’s a URI as well.

Yeah, I’ve probably repeated myself a few times, but I wanted to stress a few points.

There’s also been some confusion about when to use the term URI. As I stated in the original post explained above, it depends on what you’re doing. If everything your application does involves accessing data over the web, you’re most likely using URL exclusively. In that case, it wouldn’t be a bad thing to use the term URL. Now, if the application can use either a network location, or a name, then URI is the proper term. For example, XML namespaces are usually declared using a URI. The namespace may just be a name, or a URL that references a DTD or XML Schema. So if you’re using a URL for identity and retrieval, it’s probably best to use URI.

When it comes to manipulating photographs, I live in Photoshop. One feature of all Adobe products that I like is the ability to annotate images and other documents using their eXtensible Metadata Platform, or XMP. XMP is a collection of RDF statements that get embedded into a document that describe many facets of the document. I’ve always wanted to be able to somehow get that data out of these files and doing something with it for application purposes.

There are projects like Jempbox, which work on manipulating the XMP data but offers no facilities to extract the XMP packet from image files. The Apache XML Graphics Commons is more the ticket I was looking for. The library includes and XMP parser that performs by scanning a files for the XMP header. The approach works quite well and supports pretty much every format supported by the XMP specification. The downside of XML Graphics Commons is that it doesn’t property read all of the RDF statements. Some of the data is skipped or missed completely. To top it off, neither framework allows you to get at the raw RDF data.

What I really wanted to do was to get the XMP packet in its entirety and load it into a triples store like Sesame or Virtuoso. This of course means that you want to have the data available as RDF. Rather than inventing my own framework to do all of this, I found the Aperture Framework. Aperture is simply amazing framework that can extract RDF statements from just about anything. Of course, the one thing that is missing is XMP support. So, I set out on implementing my own Extractor that can suck out the entire XMP packet as RDF. It’s based on the work started in the XML Graphics Commons project, but modified significantly so that it pulls out the RDF data. Once extracted, it’s very easy to store the statements into a triple store and execute SPARQL queries on it.

Right now the, this  XMPExtractor can read XMP from the following formats:

• JPEG Images (image/jpeg)
• TIFF Images (image/tiff)
• Adobe DNG (image/x-adobe-dng)
• Portable Network Graphic (image/png)
• PDF (application/pdf)
• EPS, Postscipt, and Adobe Illustrator files (application/postscript)
• Quicktime (video/quicktime)
• AVI (video/x-msvideo)
• MPEG-4 (video/mp4)
• MPEG-2 (video/mpeg)
• MP3 (audio/mpeg)
• WAV Audio (audio/x-wav)

On the downside, I’ve found that if you use the XMPExtractor with a Crawler, you’ll run into some problems with Adobe Illustrator files. The problem is that the PDFExtractor mistakes these files for PDFs and then fails. But as long as you’re not using Illustrator files, you should be ok. There’s also a few nitpicks with JPEG files and the JpgExtractor in that the sample files included in the XMP SDK are flagged as invalid JPEG files. However, every JPEG file I created from Photoshop and iPhoto seem to work fine. But after a little more testing, I’ll look at offering it up as a contribution to the project.

I’ve been doing a lot of diagrams related to some of the projects that I have doing with RDF and other Semantic Web technologies. Rather that cut and paste PNG icons into OmniGraffle, I decided to start putting together a stencil. Here’s what it looks like so far:

It’s not much right now, but I’ll try and keep it up to date as I add more icons from the W3C site and other sources. It should be up on GraffleTopia soon.

Update: And here’s the direct link to the stencil.

Sometimes, you can let things slide, but there are other time when terms are just used so incorrectly that it has to be called out. One thing that always gets me is the gross misuse of the term REST. For those who know what REpresentation State Transfer (REST) means then you know that, although the REST architectural style is commonly used with HTTP, it is not bound to any specific protocol.

One of the things that starts my head spinning is seeing how the term “REST” is so often used in place of thing they really mean in order to toss out buzzwords. When I’m involved in technical discussions or read articles on the web, I start to feel like Inigo Montoya when I hear the term “REST”. More often than not, someone is probably referring about HTTP, or even HTTPS, but you can never be too sure. Here’s a few of my favorite statements:

We’ll send it over REST

Oh no you won’t! Given that REST is not a protocol, I find this kind of statement simply mind boggling. One can assume that someone would like to return data over HTTP. However, it is entirely possible to create a RESTful application over other protocols such as XMPP, RMI, or something else. It helps top be specific when you’re involved in a technical discussion.

We’ll make a REST request

Are you sure? What exactly does a REST request look like? If you can’t request data from a URI like rest://example.com/foo, then you’re not making a “REST request.” As stated above, be specific as to what protocol you’re using.

We’ll return it as a REST object

This one pains me more than the other two. Seriously, what kind of “objects” are RESTful? Is is XML, JSON, binary, what? Again, there is no such thing. There are only resources and representations, and it’s the representations of those resources you need to be specific about. What, exactly, are you sending over the wire?

We’ll just add some methods to our REST server

OMFG! For real, a REST server? Even though the Facebook claims to have one of those, it doesn’t make improper use of term valid. You can’t serve “REST,” plain and simple.

Just so that I can continue beating the horse: you can’t send jack over REST. REST is not HTTP and HTTP is not REST. If you have a web API that you’re exposing over HTTP in a RESTful fashion, why can’t it just be called an HTTP Service or API server? Correct use of the term REST is just as important as implementing a RESTful application correctly. Sadly, the same folks who use the term REST incorrectly are also not creating applications can claim to be RESTful.

There’s been a long running rant about how using Mono is um, bad. But I just don’t get it. Now we have Richard M. Stallman coming out against Mono and C# with an argument that sounds kinda like “we shouldn’t use it just because we shouldn’t.” Hmm, Ok. [ok, that is way too much of an over simplification and taking some things out of context. However, I'm still not sure what's bad: C#, Mono, or both?]

The odd thing about the post if that it focuses on C#, but none of the other languages that the the Mono CLR supports. Second, he goes on to state that “If we lose the use of C#, we will lose them [the applications] too.” Given that C# is an ECMA standard (as is the CLR itself), I think the conerns about not being able use C# are unwarrented. If we have to worry that the ECMA would allow Microsoft to pull rank on C#, then web developers should be rethinking thier use of JavaScript.

But the wierd thing is that Stallman doesn’t make the same point about any other langauage that the Mono CLR supports. For example, if Tomboy were written in the Boo programming language but remain on the Mono CLR, would evertyhing be ok? Why is there such a profound hatred of C# and not other lanagues supported by the CLR? Why not come out against the use CIL? Or is Stallman just not making his point clear enough?

As somone who uses Ubuntu 9.0.4 on a daily basis, I can apprciate what Mono has to offer from an end user perspecitive. I’m a HUGE fan of GnomeDo, which has turned out to be a better implementation of Quicksilver than Quicksilver. Then of course there’s Banshee, which is blosoming into an excellent media player. And also there F-Spot for photo management. I could go on, but the point is here that there are a lot of really great applications for GNOME that happen to be built on Mono.

Overall, I find that the post is weak on sound technical and legal arguments and high as a kite on FUD. Where’s the meat? Specifically, what can Microsoft go after that’s not GNOME if people start rewriting Mono applications in C++? Jo Shields has a lengthy, but excellent, post called Why Mono Doesn’t Suck. Jo’s post makes a lot of really good points about Mono if you don’t have a short attention span.

In the end, i think that a Mono is ultimately a good thing for Linux on the desktop. Anything that gives developers better productivity, and choice is a good. Part of being free is being able to make a choice: we should be free to choose whether or not we actually want to use applications developed with Mono.

For the past two weeks, I’ve been enjoying 64-bit Ubuntu 9.04 on my HP 8530w. It’s very fast, and ext4 is helps considerably with boot times. Overall, I find this release to be pretty good. But, there’s one item that irks me to no end and that is the much touted “MAPI” support for Evolution.

For starters, the MAPI support is not installed by default, but it’s a post-install add-on. No big deal really, but it is misleading to say that it’s included in the release when it’s actually just in the repos. Next up is that fact that it simply doesn’t work. In fact, the Evolution-MAPI plugin is alpha quality at best. For starters, just setting up an account is busted. Each time I’d go to authenticate, Evolution would simply crash. Then I found this post which suggested using the IP address instead of the host name, which actaully worked.

When Evolution connects to the Exchange server, the initial load is PAINFULLY slow. The other thing is that folder structure is weird as well. In my case, my inbox was buried under 4 other sub-folders. The good news is that I can see email, with caveats. For example, replies or forwards are not prefixed with “re:” or “fw:”, even if they were in Outlook. Second, any meeting request acceptance or decline doesn’t get prefixed with “accepted:” or “decline:”, you just see the subject of the original meeting request. Which brings me to calendar and contacts. While I can see my calendars, they don’t get translated into my local time zone. This is kind of a problem. Contacts kinda work. I can see some of them, but for the most part, Evolution crashes before I can successfully select a contact.

Yeah, I know I should probably file some bugs. But be advised that if you’re upgrading to 9.04 to gain Exchange 2007 support, this isn’t the release you want. Here’s to hoping that things improve significantly in Karmic Koala.

I’ve been a long time user of Eclipse, but also a critic of SWT – the UI toolkit that Eclipse uses. While Eclipse has always been a very productive tool on OS X, SWT has always lagged a bit behind other platforms. But the great thing about Eclipse 3.5, and SWT in general, is that it is now using Cocoa instead of Carbon. Additionally, the SWT guys have paid attention to a lot of little details, such as sheets and Mac-looking drag and drop indicators to name a few. There’s a lot that’s gone into this SWT release that makes me rethink my position on Swing.

One other thing to point out is that the Eclipse 3.5 release candidates are friggin’ snappy as hell. Startup times on all three platforms are very good and responsiveness is simply better overall. This is a release I’m really looking forward to.

Well, it’s official: Life has been canceled. This was such a great show, but now gone. Considering that NBC put this great show on at a time when two ratings juggernauts (Lost and American Idol) are already dominating Wednesday night, it’s no wonder Life did lousy ratings-wise. Yep, I watched Lost on Wednesdays, but religiously DVR’d Life. But whatever.

Well, there’s not much else worth watching on NBC nowadays other than 30 Rock and Southland. I’d throw Heroes in there too, but Heroes is a mere shadow of its former self. You’re dropping the ball NBC.

Over the past few weeks, I’ve been taking a deep dive into the Semantic Web.  As some will tell you, a number of scalability and performance issues with the Semantic Frameworks have not been fully addressed. While true to some extent, there’s been a large amount of quality research out there, but it is actually somewhat difficult to find.  Part of the reason is that much of this research is published on the web in PDF. To add insult to injury, these are PDFs without associated meta data nor hyperlinks to associated research (which is not to say that prior research isn’t properly cited).

Does this seem slightly ironic? The Semantic Web is built on the hypertext-driven nature of the web. Even though PDF is a readable and relatively open format, it’s still a rather sucktastic hypertext and on-screen format (especially when it’s published as a two-column layout).  PDFs are an agnostic means of publishing a document that was authored in something like Microsoft Word or LaTex. They are generated as an afterthought and most do not take the time to properly hyperlink these PDFs to external sources. Why is this bad? Given that we’re using the document web (or rather the “Page Ranked” web) of today, this makes it a bit more challenging to locate this kind of information on the web. In a sense, this is akin to not eating your own dog food. If knowledge isn’t properly linked into the web as it works today, it effectively doesn’t exist. Guys like Roy T. Fielding get this, and it’s most likely why his dissertation is available as HTML, as well as PDF variants.

As a friendly suggestion to the Semantic Web research community: please consider using XHTML to publish your research. Or even better, XHTML with RDF/A. Additionally, leverage hyperlinks to cite related or relevant works. It’s not enough anymore to use a purely textual bibliography or footnotes. The document web needs hyperlinks.

There’s a lot of cool and important stuff being worked on but this knowledge is not being properly disseminated. No doubt, in some cases publishing to two different formats can be a lot of work. But in the long term the payoffs are that information is widely available and you’re leveraging the Semantic Web as it was meant to be.

This weekend, we decided to take our daughter to her first movie in a real theater. This was the first time my and I had set foot into a movie theater in about three years (Yeah, we haven’t been out to see a movie since she was born). Sadly, we quickly realized that we haven’t missed much as all.

If memory serves me correctly, the Lowes at the Loop is actually a relatively decent theater. At least, three years ago anyway. First off all, all you can smell is the stench of pop corn. Second, the volume in the theater is simply way too loud. For a movie like Madagascar, there’s no need for it to be that loud. The child of mine simply did not approve. Lastly, the picture quality sucked! It didn’t help that they had technical issues with the projector which delayed the showing for 15 minutes. Once the lights dimmed and movie started, the color was just dull and washed out. Add to that the screen is smeared with candy and whatever other crap people throw at it. It was just a very unpleasant experience that ruined a decent movie and we had to leave half-way through because it just too damn loud.

The funny thing is that I think we have a much more enjoyable experience at home. I only have a 37-inch Sony Bravia XBR-6 coupled with a Sony BDP-S350 Blu-ray player. With just the TV and Blu-ray player alone, I’d say that the viewing experience is already better better than what we had at the Lowes. The family opinion is that the picture quality on the “teenie” 37-inch screen is far better than what we saw at the Lowes. Plus, there’s no funk on the screen. And the best part is that we have it all to ourselves without people on cell phones, etc.! While it’s true that a Blu-ray is more expensive than a DVD, prices are coming down. But when you consider that that two adult tickets cost $20, it makes the Blu-ray price pretty attractive. Anyway, my wife and I are pretty sure that movies will be viewed at home from this point forward, because yes, Blu-ray is that good.