Bookmark Interchange Format (mailing list)

Fabio Vescarelli (developer of smarking.com) has just set up a mailing
list for discussion/development of a format for data interchange
between "Social Bookmarking" services - the iconic example being
del.icio.us

Introductory blog post:
http://blog.smarking.com/2006/03/bookmarks_inter.html

List admin:
http://mailman-mail1.python-hosting.com/listinfo/bif

I might as well give my 2 cents -

It seems to me there are three interelated aspects to the technical
requirements. As it happens there is an existing initiative that may
be able to inform each, so I've bcc'd their respective mailing lists
(below). I'll skip comment on the process for this initiative
(potential rathole), but there are at least 3 to choose from ;-)

So...

1. data model - what is the information to be exchanged?
2. concrete representation - what format?
2. interchange protocol - how is the data passed from A to B?

IMHO...

For 1:
A bookmark identifies a Web resource. In the Social Bookmarking it is
described by through individual user comments and folksonomic tags.
Seems like a Resource Description Framework might be useful. There are
well-established RDF vocabularies for basic annotations (notably
Dublin Core) and describing people such as those doing the bookmarking
(FOAF). There's also a vocabulary for capturing tagging info [1]. RDF
is eminently suitable for a data model.

For 2:
The most deployed format for bookmark-like data is HTML. It's been
demonstrated how this can be used for carrying explicit data through
microformats (uFs). The xFolk microformat [2] is very much in the
bookmarking space, though XFN and XOXO could help with person and
structural aspects. XHTML (with microformat profiles) is eminently
suitable for a format.

For 3:
HTTP is the protocol of the Web, this is the obvious starting point.
But to be useful in a context like this it needs to be be built upon
to cover practical aspects like editing, version control and
authentication. The Atom Publishing Protocol (APP) [3] is being
designed to  cover these, and is eminently suitable for a protocol.

APP can easily carry uFs as a payload. uFs can be deterministically
mapped to RDF models (see GRDDL [4]). All three build on solid
standards. Best of all worlds.

A couple of comments about points raised on the bif list so far: the
notion of folders needs pinning down a little. Presumably we're
talking nested containers, but IMHO leaving this as nested elements in
X(HT)ML is way too vague. It needs to be mapped to something more
portable, that works outside of the local doc context.

Many things like ratings could be derived from other existing vocabs:
hReview allows rating of a resource. Things like specific application
behaviour like search aren't really in scope - if the data is
expressed (and transported) unambiguously, the functionality is
open-ended.

[One little side grumble - the examples of xFolk I've seen all leave
out the profile identifier (html:head/@profile). With it, there's an
explicit statement by the publisher that the uF is in use, that
there's data conforming to the profile. Without it, it's anyone's
guess, not much improvement on scraping.]

Cheers,
Danny.

[1] http://www.holygoat.co.uk/projects/tags/
[2] http://microformats.org/wiki/xfolk
[3] http://bitworking.org/projects/atom/
[4] http://www.w3.org/2004/01/rdxh/spec

"Semantic Web" <semantic-web@w3.org>, "Microformats Discuss"
<microformats-discuss@microformats.org>, "Atom-Protocol Protocol"
<atom-protocol@imc.org>,

--

http://dannyayers.com

Received on Thursday, 30 March 2006 20:34:47 UTC