Simon says ...

My requirements for purchasing music online

I've been a CD buyer so far for various reasons. First I like albums. I mostly listen to whole albums and to me they are conceptual coherent works which should be enjoyed in one piece. Artwork, lyrics, even the choice of the CD case are part of a design decision, part of the whole work (probably not the case most the time anyway). Apart from that I'm a collector. When I buy something I like to have something physical in my hands (does that make me a capitalist?). And I like to put this thing into my shelf, having a visible collection.

But all that aside there are also reasons why I don't like buying music online because of how music is sold online. Let's first step back and look at what you can actually buy: you buy the right to download a specific track or set of tracks from a specific platform often for a certain number of times only and often with DRM (although that is going away fortunately). I don't know about you but I never liked those conditions. Maybe it is more likely that my CDs start going bad than exhausting the number of allowed downloads being caused by hard drive crashes. But think about what else might happen: you might loose your account data for the shop's website (ok, they can send you that), your account might get hacked, the website might go out of business. Or you happen to be somewhere else on the world and don't have your music collection with you so you just want to quickly download some tunes again.

Doesn't this last point seem quite realistic in today's mobile world? We don't always run around with all of our data these days. Rather the trend seems to be to put it online. For music there are various websites which help you with that. Some let you upload your collection of files and allow you to access it anytime, or even let your friends access it in places where that is legal. Others don't even require you to upload your collection but just scan the files on your drive and provide you with access to the files they have on their drives already.

Let's carry this idea a bit further. What if ownership of music was more decentralised? What if what you bought was a certificate saying that you own a certain piece of music and you could go to any music shopping / streaming / download website (the difference wouldn't matter anymore) to require access to it. We would need services confirming those certificates (and not only the original shop you bought it from in case that goes out of business). And we would need an identifier infrastructure to be clear which piece of music the certificate actually talks about. MusicBrainz could probably provide that. Maybe they need to work a bit more on the level of detail of their data but maybe that doesn't matter anymore with online music because most people don't seem to care about editions and remasters anymore. So which level of abstraction in FRBR or similar models is concerned is something to figure out. But the music industry also didn't really embrace MusicBrainz so far, they prefer re-inventing the wheel and building up their own identifier system. At least that was the plan some time ago, did they give up on it again?

So, how likely is that this happens? Not very likely I think because people would need to agree here and the music industry would probably be scared of the idea of losing control.
Also it seems like they waited too long with changing things anyway and now people prefer to just download songs and not pay for them. But to me it seems like something that suits the people's needs while still being on a totally legal basis. I could still own stuff (which is not the case with flat-rate models) and have convenient access to it wherever and whenever I feel like it.

SWIG UK

So today I went to SWIG UK. It had some great talks, some slightly dry talks and lots of interesting people.
The talks which impressed me most were the one by Orri Erling (supported by Yrjänä Rankka) and the one by Leigh Dodds. Not so much content-wise because basically both was a program manager presenting their company's flagship product.
The reason Orri's talk impressed me is because even though he is blind he managed to give his talk in the self-confident manner of a business man and it became clear that this self-confidence is backed by decades of experience in the computer sector. So not only did he not seem too strongly influenced by his disability but, on the contrary, he seemed like the most charismastic person in the room.
Leigh's talk I really liked because of the style. It was a high-level, abstract introduction to the Talis platform but nonetheless he kept it quite entertaining by using clear language, metaphors and comparisons. Apart from that his slides only contained headlines and very few more words, the background being filled with supporting metaphorical images. This is a style I see more and more on Slideshare. It's not very good for understanding what's going on if you didn't attend the talk but people still don't seem to realise that you don't have much time to read all the text on a slide while they talk. You can only concentrate on one thing at a time.

The talks were video recorded and I think the videos as well as the slides will appear on the page of the event on the site of the CREW project − which is also where they were supposed to get annotated live.

Events for November

I knew I've come to the right place.

On 11 November I'll be attending SWIG UK. That's gonna be my first conference thing so I'm curious as to what to expect. It's also the first time I will see Semantic Web people live. ;-)

Then, on the 30th of the same month I will finally see Threshold for the first time. They will rock Poole together with Galahad − tried to get into them without success so far but maybe the gig will change that.

Looking forward very much to both events!

Update (22/10/2008): Rejoiced too soon: the Threshold concert got rescheduled to January. Oh well, better late than never.

Update (25/10/2008): And now the Threshold concert got cancelled completely.

England

Tomorrow I'm off to Southampton, England to finish my degree there. Unfortunately not at the University of Southampton (where they do lots of Semantic Web stuff) but at Solent. Still, I'm looking forward to meeting interesting people, doing exciting projects and seeing some of the many British artists I like live (Threshold are already on my radar for November ;-) ).

Garbasail project, part 3

Finally! After some last works on our garbasail we made it to the beach and let it fly. :-)

The last things we had to do was taping the diagonal lines, making the corners a bit stronger with more duct tape, preparing the handlebar (we used one from a bike :-) ), cutting the strings and tying them to the handlebar and the garbasail.

Yesterday we tried it out on the beach in Zandvoort, Netherlands then. The weather was perfect, there was lots of space, strong wind and the garbasail did exactly what we hoped for. It was strong enough to drag us across the beach but not too strong to handle or to break.
Though, after the first two "flights" it did get all tangled up. Untangling it wasn't easy since we didn't want to get into the strings while it was blowing up. We would have needed more people to handle this. Nonetheless, we had about 4 to 5 really good rides and a lot of fun.

I put the photos of our flights and some construction details up on Flickr. This is the first time I use Flickr - I didn't know their interfaces are such a mess. But all in all it's easier than just having a few pictures in the blog entries.

Semantic Web security considerations

Apart from the problem of trust and how a Semantic Web agent might rate new information it receives, there are some quite concrete security concerns to be aware of when engineering a Semantic Web application.

Always be careful when you allow for external data to be loaded into your RDF store. Sure this applies everywhere, but people might not be as aware of it for RDF stores and so far I haven't seen any discussion of it.

It might always be a good idea to keep the external data you load separate from the data especially created for the store. You could put it into another repository for example. This should prevent the external data from getting into your inferencing, applying of rules, SPARQLing and other kinds of deducing knowledge that will influence the behaviour of your application. If your application requires the external data to get into the mix, then you really have to deal with context, trust and rating.
In the same way you should of course never put confidential data (user passwords and email addresses) in the same repository as publicly accessible data.

In your store you might use quads to associate triples with a graph URI. Then, when retrieving RDF data from external documents, you could store it using the URI of the document as the graph URI. That way you will always know where the data came from and can treat it in this context. Be careful though: some RDF formats allow you to define named graphs inside of documents. When parsing those documents, your API might probably already associate the triples with a named graph and then, when you store them, store several quads: one for each named graph they're attached to (since you provide a graph URI yourself). As far as I'm aware, the Sesame API would in this case overwrite any graph URIs that the document attached to the triples - your mileage may vary. :-)
So, the problem here is: if in any way the graph URIs in the documents get into your store, then the documents can inject foreign-document data. That is: document A contains triples which are associated with a graph URI which is the URI of document B, thus some data in document A will end up in your store as being from document B (if that's how you interpret the graph URIs).
Doesn't sound very threatening? Why would someone do that? Well, an example: there's a new semantic search website for travel stuff, called UpTake. Read about it on ReadWriteWeb or Paul Miller's blog post on ZDNet. They pull in information about hotels and places to stay and reviews and stuff from lots of sites. Now imagine one of their sources wanted to say something bad about another competing source or about a hotel. How could they do that? Just say "they suck"? No, not effective enough. If other reviews are mostly positive, it will just be regarded as noise. So instead they could publish wrong facts about their competitor as if they stated them. If UpTake would read in an RDF document from them which contains a named graph and that graph is given the URI of a document of the competitor, then there's a danger that they store the data in the graph as coming from the competitor's document.
You could call this vulnerability named graph spoofing or context spoofing. There might be good use cases for accepting named graphs inside externally loaded documents but be careful when you treat graph URIs to mean source documents.

Another danger comes from the power of the N3 format. Note that N3 can do much more than just express the RDF model. In fact, N3 is said to be a Turing-complete language. So if your library can understand all of N3, then it might not only use its formulae (rules) for inferencing (which alone can bring enough trouble) but really execute the N3. Thus, you could get N3 injections.

Apart from security holes, there are other possible attacks. You might want to put limits on SPARQL access: size limits for the requests, size limits for the replies, time limits for the replies, maximum number of requests per day per IP address, etc. There's a reason people don't offer direct SQL read-access to their public data on their database servers. It could provide the users with endless possiblities but it might just as well let them crash your server.