Q: How would you describe Seevl?
A: We initially defined ourselves solely as a music discovery website, and we’re now developing several products around the data we gathered for building it. Our main focus is to bring context to music, and we want to help people to know more about the cultural and musical universe of the bands they like, to discover new ones and most importantly, to understand the connections between all.
Q: Where does the name “Seevl” come from?
A: It doesn’t mean anything, but it’s “Elvis” read backwards, as we wanted to keep some music-related influence in the name. And, since we hope to change discovery of music information as much as he changed music, we thought it was a catchy name.
Q: What prompted the creation of Seevl.net?
A: Besides the initial academic exercise, the launch of Seevl.net as a company was motivated by 3 problems that we frequently encounter:
- the need to browse different websites to get a complete picture of an artist / band (bio on one website, genres on another, etc.)
- the inability to run fine-grained queries (“what’s that band that played with this guy in the 80s”) easily, with a simple UI
- the lack of explanations in recommendations (when you get an unknown recommendation, it’s useful to know why before listening to it)
Q: What is the business model for Seevl.net? How do you plan to make money?
A: We’re currently building several products around the website – the first one being ContexTube, a Chrome plug-in for YouTube. Some of these products will remain free and be ad-supported (as the website); others will have premium features. We also plan to monetize access to the data (and not the data itself) and services around this, and we’re currently finding the right pricing model for this part.
Q: Who do you see as being the core customers?
A: For the website and consumer products, mostly music geeks, people that love to learn about all the context around music – i.e. not the music itself, but facts about the members, the influences, the other artists active in that timeframe, etc. That is, people that had similar frustrations to ours when going to music websites – or when trying to find information about what they’re listening to.
For the data reuse, mainly businesses that need a simple way to integrate fact-sheets and recommendations into their websites. Rather than extracting data from different sources, we provide them with a simple way to get this – integrated and curated – directly from Seevl.
Q: I’m curious why seevl.net does not include the discographies of artists. Was there a conscious reason that the team chose to omit a listing of songs/albums? Is it in the cards for future development?
A: Indeed, that will be a great addition, and we’re considering MusicBrainz and discogs here. The reason we initially focused on artist information is that we identified that was an area where the lack of integration between sources was more a problem than for discographies where the previous websites already do a great job.
Q: Are you currently seeking funding?
A: In addition to some codebase spinning-out from DERI, we’ve developed the website and some new features (such as the semantic search or ContexTube) with a bit of money and lots of sweat (and Red Bull!). Right now, we’re looking for funding to grow a team and progress in terms of product development and reach future milestones. We have a clear path for next steps, and we hope to get the team that would help us to achieve it in a reasonable timeframe.
Q: What have you learned in the first couple of months? Have you made any significant changes (or do you plan to)?
A: As first time entrepreneurs – we’ve learnt a lot from the business side, especially around customer and product development. We’ve refocused some parts of the system – and are constantly adjusting it – based on the feedback we have. For instance, we initially added a commenting system for each fact, but realized that what users want is a way to add bands that are not listed – and we’re currently working on it.
We’ve also refocused our product timeline and milestones based on what we’ve learnt from this feedback and from the industry, and things are now much clearer than 6 months ago – which is I guess the life of every startup! As a researcher, I also identified interesting similarities between the path for science experiments and the lean startup approach (build, observe, learn, iterate, progress).
Q: What semantic technology are you using? Which standards? Which specific Linked Open Data sets are you leveraging?
A: So far, we’re combining data from the BBC, MusicBrainz, NYTimes, Wikipedia and Freebase. Everything is then integrated using the Music Ontology (and other usual suspects like SKOS), and stored as RDF in a Virtuoso store. Actually, we used RDF because its graph mode was the easiest – and most agile when changes are needed – way to store and query our information. The front-end is thus generated using a set of SPARQL queries (as is the semantic search feature, but hidden behind a hopefully well-designed form). We also provide our data in JSON, and we’re now moving towards JSON-LD – IMO, a clean, object-based (rather than triple-based) serialization of RDF is JSON is the best way to reach the world of Web devs – while keeping advantages of RDF – and I hope JSON-LD will succeed here.
Q: When pulling data from so many sources, how do you deal with issues of data quality and data being out-of-date? For example, I just looked up “Clarence Clemons” in Seevl.net and he’s shown as being in the group “Living people,” but sadly, “The Big Man” of the E-Street Band died earlier this summer.
A: That’s a good point – we are finalising our real-time extraction algorithms, so that the data will be up-to-date on seevl right after it’s being changed on the original source. We also have to deal with conflicting information – when for instance Freebase and Wikipedia tell different information (eg birth date) – so far we display both but we’re figuring out other techniques to deal with that.
Q: Do you anticipate expanding to cover other domains (movies, for example)?
A: For now, our focus is on the music – in terms of expanding the data and market focus. Yet, the architecture is domain agnostic and can be replicated to any dataset and RDF store, pending a few parameters in the system. So that may be a direction if there’s some particular need or customer – but our main focus will remain music.
Q: The Seevl team has just deployed some updates to the data model and data access. Briefly, what core changes were made and what are the implications for your two types of users (i.e. individual music geeks and developers using your API)?
The UI/UX of the browser remains the same, but we improved a lot the performance – by updating some bits and pieces of our RDF architecture – and are now taking full advantage of the Music Ontology (MO). We are using some recent changes we’ve pushed in MO, such as representing Activities as events – so that we can model bands that have been active at several times of their existence (think of some 80′s bands that do a reunion 20 or 30 years later).
For the data access, we initially used our own JSON format, mapped to RDF, and we’re now fully implementing JSON-LD. While still a draft, we really appreciate the way we can model data / graphs / entities in JSON. Our data access is now suited both for RDF-aware developers and Web-devs that do not care (and should not have to) about the triple-based model of RDF and its current syntaxes. The only issue is that we were not able to keep the previous data export, so existing apps have to be updated – while the changes are fairly minor. But that’s worth the effort and will also make easy the integration of new features (such as the discographies discussed earlier).
Q: Thanks much, Alex. Is there anything else you’d like to share with SemanticWeb.com’s readers?
A: As an additional thought on providing SemWeb-based services to end-users, I think we (SemWeb people) should stop thinking in terms of triple-based UI (which is too often the case for semantic web browsers) but in terms of objects (that can be chained). This is also a reason why I think JSON-LD will be successful – its model is IMO more adapted to the usual mindset of thinking of things (as real-world entities) – rather than triples.