I was tempted to call this “Semantic Web project idea number 4a”, because it’s not a big leap from my last one. Perhaps if I generalize the idea more it will sound separate enough, but as you’ll see, my example builds on the last example.
A big theme of semantic web evangelism is the value of combining multiple web resources into something greater than the sum of their parts, especially when one of those resources is in RDF. As I mentioned before, using this technology to help people find products they need is a great basis for an application, because in addition to benefiting the users it can earn a commission for the developer. Building an ontology from a taxonomy and then combining it with other resources has a lot of potential, but if we focus on the quest for tunes, there’s already at least one ontology that looks ready to use, and using an existing ontology for such an application would be a great demonstration of the value of the semantic web.
For an online music store to incorporate into an application, Amazon is the most obvious choice, because they have an API and because they bought cdnow.com. Other obvious choices are iTunes and my new favorite, emusic. (You won’t find the latest Justin Timberlake or Fergie hits there, but they have tons of great stuff from a wide variety of categories, and you get 30 DRM-free MP3s a month for $9.99 or 50 for $14.99 after the 25 free songs you get for signing up.)
My first thought for a public resource to use for such an application was MusicBrainz, an open content database of album information, because I knew that they have an RDF interface. It turns out that the RDF interface has been deprecated in favor of a REST web service, which would still be invaluable to someone who wants to use a music database with a public API to help people find music.
A better place to start, though, especially for a semweb geek, would be Frédérick Giasson and Yves Raimond’s Music Ontology Specification. They’ve even defined properties for musicbrainz, amazon, myspace, and other web-related music resources, which should make it easier to define relationships between these resources to connect information.
Much of what I wrote in my last posting still applies here, especially the value of Amazon’s existing taxonomy as a resource. The advantages of working with an existing ontology instead of building one from a taxonomy should be obvious, but remember that many of the if-you-build-it-they-will-come OWL ontologies out there haven’t been applied to much real world data. By doing so yourself, you’ll be in a position to deliver feedback to the ontology designers that should be reflected as the ontology evolves. The Music Ontology has a Google discussion group, which will be handy for this.
If you build an application around this ontology and some music, I think it would be easier to create some real value if you aim for depth more than breadth. Pick a category of music that you know and care about and create something for people who are interested but know less than you do about that music.
Of course, your application doesn’t have to be about music. Find one or more related ontologies and one or more related e-commerce sites and build an application that shows that the former can add value to the latter. Perhaps, if you’re behind the development of one of these ontologies, you owe it to your ontology’s potential users to do such a project, if only on a small scale, to show that your work is more than an academic exercise.
Using an existing ontology to make an e-commerce site easier to navigate will prove the potential value of the semantic web far more than any “Web n” essays for which n > 2.
On this topic, don’t miss Frederic’s Musicbrainz Relation Database mapped in RDF using the Music Ontology.