annotations / recommendations for restaurants: ChefMoz

Dan Brickley danbri at w...
Sun May 6 07:22:00 UTC 2001

(copying RDFWeb list for info / archival)

I've been looking again at modelling strategies for recommending
real-world objects in RDF apps, trying to figure out how (if at all) the
Annotea or ILRT RDF annotation systems might be tweaked to better do this.
So here are some rough notes / proposals regarding restaurant reviews.

This topic cropped up on the collaborative filtering list a while back,
and is now all the more interesting because of the existence of ChefMoz,
the Open Directory database of restaurant reviews and descriptions. (free data dumps)

(based on the main open directory rdf dumps)

I believe restaurant reviews provide a very useful use case for RDF
annotations (and modelling generally), since they force us to distnguish
between the description of the restaurant and the description of the web
pages / web site run by that restaurant. Annotea and similar vocabularies
are excellent for the latter task -- the challenge will be to find a way
to do RDF annotations in a way that is both cross domain (ie. does
restaurants, jobs, CVs...) and that integrates with document-oriented
annotation systems.

Last year Libby Miller and I sketched a technique for doing something
similar in the context of RSS (RDF Site Summary), showing how RSS data
feeds could be used to syndicate information about Jobs, in a way that
distinguished the job (and its properties) from a Web page advertising
that job. I propose that a very similar technique could work for us in the
annotations field, ie. that we can extend our document-oriented
annotation vocabs in a way that allows job, restaurant etc information to
be plugged in. The RSS proposal is at ('Extending and querying RSS
channels'). The basic idea I have in mind for "doing jobs, food etc" is to
use a node standing for the restaurant or whatever, and make up[ a generic
relation between that and a page or document described using something
like the Annotea vocab. The relation could be called 'foaf:homepage' or
whatever; in the RSS example we used 'advertises', which is rather
application specific. We would also need to have RDF classes representing
the many kinds of thingwhose online representation we were annotating. I
propose that we can use WordNet for this. For example:

etc. This would provide us with 1000s of category terms for use with RDF
annotations, arranged in a hierarchy. Restaurants would be a special case
of a general representational strategy: annotations would either be
directly about some document or document sub-section, or else be about
"the Restaurant/Job/Song/Video/... whose foaf:homepage is [document URI]".
IMHO this modelling strategy provides better attachment points for the
kind of information available for eg in the DMoz data (see

OK that was a bit rambly, hope I'm making some kind of sense here!
I should also mention that I have just written a little converter that can
translate between the Squish RDF query language (see RSS paper above) and
the Algy language used in EricP's RDF server (ie. Annotea). So I'm hopeful
that we can start doing some concrete testing of vocabulary design ideas
soon, and through that come to a better understanding of the tradeoffs


More information about the foaf-dev mailing list