At the ImageDescription meeting we talked a lot about the difficulty of scoping such technical activities, since problem spaces overlap in ways that create opportunities and frustration in equal measure. The idea of having a “wishlist” association with a person’s homepage or FOAF profile(s) illustrates just this. A related idea is that of a foaf:tipjar, ie. a relationship between a person and a document (or part of a document) which explains how to pay or otherwise reward that person. The idea of public wishlists is associated with the practice of companies such as Amazon, who allow people to expose lists of things they’d like bought for them (eg. as Birthday presents). Danny Ayers has done some work on transforming Amazon wishlists into a FOAF/RDF format. This can also be seen as one half of the concept of bartering explored by Ian Davis, and in earlier FOAFShop scribbles. It is far from clear how all this stuff fits together in a way that best suits incrementally fancy deployment.
Anyway, here are four notions of Wishlist as discussed in Spain.
Sense 1: Wishlists as true descriptions
This notion of a wishlist can be characterised as a relationship between a Person (or Agent) and a description of the world. The idea is that the “wish” is for the description to be true. Any RDF description of the world can be used. For example, I might wish for a job at Microsoft (ie. for the foaf:Person whose foaf:homepage is http://danbri.org/ to have a foaf:workplaceHomepage of http://www.microsoft.com/). Or I might wish to get to know someone (expressible with foaf:knows), or for anything else that RDF can describe. A variation on this design is to express that I wish some RDF-expressible state of affairs not to be a true description of the world.
Sense 2: to own particular things
This is a common sense of wishlist. A wishlist in this sense is just a list of things, associated with a Person or Agent that wishes to own them.
Sense 3: an information-oriented expression of interest
Somewhat different, this one. Idea is that we might want to express informational wishes, for example we might want to leave “questions” in the Web, and have services answer them, notifying us of the answers (via email, RSS/Atom, etc.). This kind of wishlist could be implemented through users publishing queries (expressed in terms of RDF/XML descriptions) alongside their FOAF files.
Sense 4: Wanting to own things that match some particular template description.
This is a hybrid of 2 and 3, and can be seen as a common generalisation of 2. In practice, the notion of wishlist as a “list of items one wants to own” is likely to be implemented through a description of the things on that list. The implicit assumption is that for each thing on the list, there is at most one desired object that matches the description (eg. some particular book with ISBN and title). However in practice there are often multiple objects that meet a description, and it is actually quite difficult to constrain item descriptions so that there is only one possible match.
Instead of saying that one wants to own the car whose numberplate is ABC-FOAF-1 you could say “I’d like to own a wn:Car that is RED and whose foaf:maker has a foaf:homepage of http://www.audi.co.uk/ and which is the foaf:primaryTopic of some specified page.
Senses 2 and 4 could be re-characterised using sense 1, using notions such as foaf:owns (which doesn’t exist at the time of writing). In other words, ownership-oriented wishlist mechanisms can be seen as being based expressions of a desire that “it should be true that … owns …”, for some particular person and entity.
The big question is… what to do next? what would it make sense to add to, or use with, FOAF?