Of Fish, Shell-Fish and Fish Py

FluidDB is dead; long live Fluidinfo.

Whither fdb?

Obviously, fdb should become fi; it’s perfect. Thirty-three-and-a-third per cent shorter is 33⅓% better for a command-line command. And fi is just so beautiful. It could almost become a ligature: how perfect would fi be?

Except, of course, there’s one tiny problem. In Unix shells, fi is reserved as the closing counterpart to if. Even if I could make fi kinda, sorta work, I wouldn’t want to. The closing counterpart to if should be fi; it’s part of the cosmic order.

So what to do? The procrastinator’s dictum to the rescue:

Why put off till tomorrow that which doesn’t really need to be done until the day after that?

Why does fdb need to change at all? It could be a throwback, a reminder of glories past, a piece of Fluidinfo’s cultural legacy (along with the fluiddb superuser).

That’s what I thought.

Until I decided to put fdb into the sky. I’ve long thought it would be cool to have a browser-based version of fdb that anyone could simply use without installation. “No software”, as Salesforce.com likes to say.

For better or for worse, I tend to use Google’s App Engine to write web apps at the moment, so I went to register a new app there.

In Search of a Google App Engine App Name¶

Unfortunately, registering a new app is a bit like picking a domain; most of the desirable onare are gone already, not helped by the fact that all google usernames are considered taken. Add to that a minimum-of-six-characters requirement, and fdb looks to be in trouble.

As I was doing all this, I was chatting online with Terry (@terrycojones), who is the leading advocate of taking the DB out of FluidDB, and who, while entirely willing for me to plough my own furrow, had a very clear preference for expunging the db from fdb too.

Clearly, in reality, fdb is a shell for Fluidinfo. Unix has a long history of shells. In roughly chronological order I have used sh (the original “Bourne” shell), csh (the C shell), tcsh, ssh (Simon’s shell; not the Secure Shell; though I use that daily too), and now, always, nearly exclusively, bash, the truly wonderful Bourne-Again Shell. I’ve also dabbled with ksh, zsh and no doubt various others that fall into the large things-I-used-to-know category.

So give this, what would you call a shell for Fluidinfo? It just has to be fish. It’s screaming out to be fish. The only problem is that it’s thirty-three per cent worse (33% more typing).

Well, the fact that it’s 33% worse and a bit fishy.

Well, the fact that it’s 33% worse and a bit fishy and isn’t actually long enough to be a Google App Engine ID. (Too long and yet too short; not long enough and yet altogether too long. Such a paradox.)

FDB’s Fate Sealed by a Typo¶

As I was checking availability on App ID after App ID, I eventually got to shell-fish. Now shell-fish is just silly. I mean, it’s redundant (shell-Fluidinfo shell?). It’s hyphenated. It’s even fishier than fish. It sounds like a drunken version of selfish. Clearly, no person in his right mind was never going to choose shell-fish.

But then, instead of clicking the “Check Availability Button”, I typed return. And discovered that shell-fish was available. And that I had registered it.

Now, give me some credit. I do appreciate that this wasn’t really it. I could have changed it. But it could have been worse. I checked availability of fishnet (taken) and fish-net (available) and countless dozens I’ve have to go back to the IRC logs to recall so memorable were they. But in the end, I wasn’t convinced that I was gong to do better than shell-fish. And it does lock in fish, which is the perfect name for the Fluidinfo Shell—well, except for being 33% worse, and fishy, and not available as a Google App Engine ID, and . . .

Shell-Fish¶

So there it is. If you wish to be a guinea pig, head on over to http://shell-fish.appspot.com, where you can try fish online. It’s mostly the same as fdb was, and fish is, except that

• you don’t need to prefix commands with fdb (or fish), obviously.
• you are subject to the Google App Engine, 5–10 second maximum for an HTTP request. This can be an issue; timeouts are not uncommon, especially for complex queries, and when Fluidinfo is under load.

It’s almost certainly buggy and subject to change.

Right now, if you don’t log in, you will use the Fluidinfo test user. Before too long (when registrations are fixed), it’ll be a different user. But you can log in using your own Fluidinfo credentials if you like.

The way you do that is that you log into the appliction using a Google Account. (My app doesn’t get to see your Google password.)

Then, if you go into settings, you can add one or more Fluidinfo accounts by specifying your username and password. (You can also choose whether to use the default, Fluidinfo-style full paths for all tags and namespaces (njr/rating etc.) or whether your own tags and namespaces will be abbreviated to rating etc., at the cost of having to use a leading / for other people’s (/ntoll/rating etc.).

IMPORTANT: PASSWORD SECURITY

If you register a Fluidinfo username and password, shell-fish will store these in Google’s data store. I’m not particularly comfortable either with asking people for their passwords or with storing them, but I don’t think there’s much alternative at the moment. (There may be in an OAuth future.)

Obviously, before you hand over your password, you need to consider a few things:

• Do you trust me? I could steal your password.
• Do you trust fish? Even if you think me worthy of your trust, do you consider me competent? [Disclosure: sometimes, I make mistakes. See the discussion above on how shell-fish got its name.]
• Are you happy with your password living in Google’s data store?

On the last point, I have taken what might be called minimal precautions. I do not store your password in plain text, partly so that should anyone happen to gain access to Google’s data store, they won’t just be able to read your password, and even more so that if I browse the shell-fish Google data store, I won’t inadvertantly see your password. (I’d have to decide to be evil.)

But I should also admit that what I’ve done to the password, while presumably technically qualifying as encryption, would probably be more accurately termed obfuscation. Let’s put it this way: it’s better than ROT-13, but it’s not as strong as PGP.

The other thing to know is that when you remove a user from your shell-fish settings, I simply the datastore (well, shell-fish tells the data store) to delete the record. I certainly don’t have access to it after that; whether a DrEvil@google.com could recover it, I know not.

Of Fish, Shell-Fish and Fish Py¶

So there it is.

I am in the process of changing the name of fdb to fish. (In fact, I’ve done it locally, but I don’t plan to push it to Github for a few days.)

The web app shell-fish is available at http://shell-fish.appspot.com for brave early adopters. I’m fiddling with it all the time. It will change a lot (most importantly, I hope it will end up looking more like a scrolling terminal than a one-shot search engine—think Goosh rather than Google. But right now, it’s very Google.

As fdb becomes fish, so will fdb.py become fish.py (geddit?).

One more thing . . . Amazon Product Pages¶

I’ll blog about this separately, but even if you don’t want to use fish per se, you might be interested in one neat little experimental feature.

At the top of the page in shell-fish, there’s a link called az-fish (though it might become amazon-fish). This is bookmarklet. Don’t click on it on the page; rather drag it to your tool bar. (It works even if you don’t give fish details of your Fluidinfo account.)

Then, click it when you are on an Amazon product page for a book, an eBook, a CD or an MP3 track. (I’ve only tested it on Amazon UK and Amazon US; it will probably need to tweaked for others, especially for non-English others.) It will take the URL and give it to fish (at shell-fish), which will attempt to figure out the about tag for the corresponding book, album or track in Fludiinfo, using its new amazon command (which may eventually become a thing command.)

How cool is that?

Choice and Conformity in fdb

I’ve just pushed a new version of fdb.py to the GitHub repository.

The main change in this version is that I’ve added support for allowing the user to choose whether to use what we might call Unix-style paths or Fluidinfo-style paths.

Until now, fdb.py has, as part of its shell-like functionality, deliberately provided an alternative view of Fluidinfo from the underlying structure. The main features of this “Unix-style view” are as follows:

• Full (absolute) fdb.py tag paths start with a leading slash. So my rating tag would be /njr/rating rather than njr/rating.
• A tag path without a slash is taken to be a relative path, currently always relative to the user’s namespace (though there are alternate versions where there is a notion of a current working namespace (CWD) which can be changed with a cd command). Thus, when using my credentials, the Fluidinfo tag njr/rating can be referred to as rating while ntolls rating is ntoll/rating.
• /about is provided as a synonym for the special tag fluiddb/about (the about tag).
• /id is provided as a pseudo-tag that will report the value of the object’s Fluidinfo ID.

This was not carried all the way: I didn’t re-write queries, but, for me at least, it saved much typing and pain when using fdb from the command line.

This release (1.33) maintains this behaviour by default, but allows the user to configure or tell the system that she would prefer to use genuine, regular all-American Fluidinfo-style paths. There are two ways to invoke this alternative behaviour:

• If you would always prefer to user regular Fluidinfo-style paths, the best thing to do is to add a third line to the credentials file that fdb uses saying

  unix-style-paths false

  (I need hardly add that using true instead of false sets the opposite preference.)

• Alternatively, if you just want to override the configured or default behaviour for a one-off command, use the command-line flags -F. Similarly, to override the behaviour to force Unix-style paths, use -U.

When you choose Fluidinfo-style-paths, this is what happens:

• Only command-line commands are affected: if you use fdb.py through the API, nothing changes unless you work quite hard.
• Any time you specify a path, it needs to be an absolute path. In Terry’s world, absolutely all paths are absolute.
• /about is not accepted as a synonym for fluiddb/about
• The only special case is /id. Since this is a useful pseudo tag (in my view), and since it has no namespace, the same trick works as when using unix-style paths. Thus you can request the tag /id and it will return the object ID.
• Output as well as input is affected, i.e. tag paths will be reported without a leading slash.

Examples¶

Old (default) behaviour:

$ fdb tags -a "Eiffel Tower"
Object with about="Eiffel Tower":
/objects/93bd1999-0998-49cc-8004-af457ce34ce4
  /njr/location = "Paris"
  /fluiddb/about = "Eiffel Tower"
  /njr/index/about

Behaviour with -F or with unix-style-paths false

$ fdb tags -F -a "Eiffel Tower"
Object with about="Eiffel Tower":
/objects/93bd1999-0998-49cc-8004-af457ce34ce4
  njr/location = "Paris"
  fluiddb/about = "Eiffel Tower"
  njr/index/about

Setting and showing tags (old/default behaviour):

$ fdb tag -a "Eiffel Tower" rating=7
$ fdb show -a "Eiffel Tower" rating
Object with about="Eiffel Tower":
  /njr/rating = 7

Behaviour with -F or with unix-style-paths false

$ fdb tag -F -a "Eiffel Tower" njr/rating=8
$ fdb show -F -a "Eiffel Tower" njr/rating
Object with about="Eiffel Tower":
  njr/rating = 8

The same behaviour works with untag:

$ fdb untag -F -a "Eiffel Tower" njr/rating
zero:$ fdb show -F -a "Eiffel Tower" njr/rating
Object with about="Eiffel Tower":
  (tag njr/rating not present)

I may have missed something, but as far as I can see, this works reliably. If I have missed something, let me know.

So: if you’ve always liked the look of fdb but disliked its unix-style paths, now might be a good time to get it. And if you already use it, but would prefer to use Fluidinfo-style paths, just add

unix-style-paths false

as the third line of your credentials file.

fdb.py 1.30 — Embryonic /values API support

I’ve just pushed a new version of fdb.py to the GitHub repository.

This release doesn’t change the command line but does add support for the (not-so) new /values API.

The /values API is a huge step forward for Fluidinfo, and I should have started adding support ages ago. It allows bulk reading and writing of tags on groups of objects that can be specified with a Fluidinfo query vastly more efficiently than was possible before.

There are a few things to note about the implementation:

• It is inconsistent with the rest of fdb.py at present; I aim to remedy this (see below).
• In particular, all strings must be unicode for the new calls (input and output), tags being written must already exist (ouch!) and any tags must be specified using full (absolute) Fluidinfo paths with no leading slash (unlike everywhere else in fdb.py).
• The new calls are not exploited by the command line commands show or tag, so those will run no faster. Obviously, I plan to change this over time, too.

Examples¶

The following code shows simple use of the two main new calls, get_values and tag_by_query.

import fdb

db = fdb.FluidDB()

# Get about tag and njr/rating for objects njr has rated < 2:
values = fdb.get_values(db, u'njr/rating < 2',
                        [u'fluiddb/about', u'njr/rating'])
print u'Low ratings:\n'
for v in values:
    print unicode(v), u'\n'

# Tag those same objects with njr/dislike = True.
# (Currently requires njr/dislike to exist; easy to create using
# the command line to tag a single object.

fdb.tag_by_query(db, u'njr/rating < 2',
                 {u'njr/dislike': True})

#
# Now get the ones that are disliked:
#
values = fdb.get_values(db, u'has njr/dislike',
                        [u'fluiddb/about', u'njr/rating', u'njr/dislike'])
print u'Disliked:\n'
for v in values:
    print unicode(v), u'\n'

When run, this produces the following (for me, right now; you won’t be able to run it as-is, because you don’t have write access to my dislike tag.)

$ python ex.py
Low ratings:

   fluiddb/about: book:foucaults pendulum (umberto eco)
              id: a98f2c80-ae5f-405a-a319-d47122ae9da3
      njr/rating: 1

   fluiddb/about: The_Beatles
              id: 5157c69e-ceaf-4e7c-9423-d67751d029d3
      njr/rating: 1

   fluiddb/about: book:beloved (toni morrison)
              id: 1ab066e8-c2a1-4769-9121-e3346849e7e4
      njr/rating: 1

   fluiddb/about: book:the lord of the rings (jrr tolkien)
              id: ff873602-e9a8-4f9a-a7d4-c0cfc394a120
      njr/rating: 1

   fluiddb/about: book:oranges are not the only fruit (jeanette winterson)
              id: 7aed1e67-a88e-439d-8a56-b2ab52c838ab
      njr/rating: 0

Disliked:

   fluiddb/about: book:foucaults pendulum (umberto eco)
              id: a98f2c80-ae5f-405a-a319-d47122ae9da3
     njr/dislike: True
      njr/rating: 1

   fluiddb/about: The_Beatles
              id: 5157c69e-ceaf-4e7c-9423-d67751d029d3
     njr/dislike: True
      njr/rating: 1

   fluiddb/about: book:beloved (toni morrison)
              id: 1ab066e8-c2a1-4769-9121-e3346849e7e4
     njr/dislike: True
      njr/rating: 1

   fluiddb/about: book:the lord of the rings (jrr tolkien)
              id: ff873602-e9a8-4f9a-a7d4-c0cfc394a120
     njr/dislike: True
      njr/rating: 1

   fluiddb/about: book:oranges are not the only fruit (jeanette winterson)
              id: 7aed1e67-a88e-439d-8a56-b2ab52c838ab
     njr/dislike: True
      njr/rating: 0

How fdb.py Will Change¶

Obviously, the fact that these calls are inconsistent with the rest of fdb.py is unfortunate; in fact, it’s plain terrible. I plan to make a number of changes to make this situation better.

First, I plan to change the whole of fdb.py to use unicode internally. This shouldn’t affect the command line much, except for making from unicode cases work better, but will affect users of the fdb.py API.

Secondly, I plan to allow users to use full, fdb.py-style absolute or relative paths for tags, to make it consistent with the rest.

Thirdly, like elsewhere in fdb.py, it will create tags if they don’t exist, as required.

Finally, I plan to add an option to fdb.py to allow the user to choose whether to use fdb.py/Unix-style paths or 100%-genuine, @terrycojones-approved Fluidinfo-style absolute paths only, with no leading slashes, requiring fluiddb/about and disallowing relative paths. I plan to make this choice available both through configuration option and a command-line flag (in the case of the command line), and with an extra initialization parameter for use of the API. The configuration will affect both specification of tags by the user and reporting of tags by the system. So there will be choice. (Maybe Terry will be so pleased he’ll add tag-creation-by-tag-writing for me as a “thank you”.)

Personally, I will continue to use Unix-style paths, because I find it so inconvenient not to have relative paths and to have to add fluiddb/ just to refer to the about tag; but others may prefer conformity.

For those who have been following the mailing list, I will also aim to add a few other aggregation functions (currently there is only count).

Pretty Good Uniqueness

Software developers are neurotic about uniqueness—no two files may share the same path, no two users the same ID. That’s probably good: we like money and email to go to right person.

Over in the Real World™, people are more relaxed. We tolerate quite a lot of ambiguity, relying partly on context to remove it, and partly on clarification when necessary–“Paris, France, not Paris, Texas”. We even tolerate a certain level of confusion and error as a reasonable price to pay for not always having to refer to each other by National Insurance number.

Terry Jones (not the Python, nor the Qu’ran burning pastor, but @terrycojones, the unorthodox visionary behind Fluidinfo) frequently says that he wants to make working with information in computers more like working with information in the Real World™. It’s a useful goal.

Almost from the first moment I heard about Fluidinfo, with its model of information sharing based on tagging common objects, I’ve been interested in (some might might say obsessed with) the question of how to map Real-World™ objects and concepts (like Paris, Animal Farm, The Eiffel Tower, Existential Philosophy and the ring on my finger) to Fluidinfo objects, romantically identified, as they are, by 128-bit integers (hubristically so-called ‘universally unique identifiers’ [UUIDs]) such as 6387ab3f-e3d5-4ca9-bd13-ae3f-fd9c1830.

Fluidinfo’s about tag (fluiddb/about, to give it its full name) was created specifically to make it easier to decide where to put information in Fluidinfo. Every object in Fluidinfo, when it’s created, can optionally have this about tag set to a unicode string and Fluidinfo guarantees that about tags are unique, i.e. that no two different objects will ever share an about tag. As a result, you can directly address objects in Fluidinfo by specifying an about tag. For example, http://fluiddb.fluidinfo.com/about/Paris is the URL for the Fluidinfo object with the about tag “Paris” (UUID 17ecdfbc-c148-41d3-b898-0b5396ebe6cc, since you ask).

Fluidinfo, by Terry’s very specific design, does not force anyone to use about tags in any specific way. Any Fluidinfo user can attach any information to any Fluidinfo object she likes. If user jacqui decides to attach information about Paris, Texas to the Paris object above, and gemma chooses to use it to store information about Paris, France, that is entirely fine. It’s even fine of Fluidinfo user anarchist decides to store information about Birmingham (Alabam), or existential philosophy, or her entire record collection on the same object. There will be no one from Fluidinfo complaining or banning or undoing (though it’s possible that those with acute hearing may perceive a quiet “tsk, tsk” sound emanating from the author of this blog).

I believe, however, that most Fluidinfo users will want there to be conventions for about tags that will encourage information about the same thing to be stored on a well-defined common object, and for information about different things to be stored on different objects. Of course, we won’t always get those conventions right first time, and they will evolve over time, but my feeling is that a few hours of thinking can avoid many, many hours of trial error. The question is: what should those conventions be?

My feeling is that what we need to aim for is “pretty good uniqueness”, a concept that might be compared loosely to “pretty good privacy” or “probabilistically approximately complete” learning. I don’t have a formal definition, nor even a very good rule of thumb, but I think we need to aim for a set of about tag conventions that are easy to use and which mean that collisions are very rare, but that we should not aim for absolute uniqueness, as to do so would lead inexorably to conventions that are much less appealing to humans. In other words, we should aim to make about tag conventions lie in a sweet spot somewhere between the computer programmer’s “absolute, guaranteed, uniqueness in all circumstances” and the Real-World™, human-style “let’s not worry about it too much and just deal with collisions when they occur”.

The nearest I have to a rule of thumb is that when you’re uploading a reasonably large quantity of data to Fluidinfo (say, some tens of thousands of objects), most of the time, you should not encounter a conflict. I’m not sure how to quantify this. If 1% of items have conflicting about tags, I’m pretty clear that this is much to high a collision rate. And I’m pretty clear that 1-in-a-billion is OK. My guess is that it is probably good enough to aim for collision rates below about 1-in-a-million. But that’s just a feeling.

This can be made more concrete with some examples. One convention I suggested that seems to be being used quite widely and successfully is for books (as works, rather than individual editions, printings etc.). The basic form of this is to combine a ‘book:’ prefix with a normalized title and author. The normalization aims to remove ambiguity with case, punctuation etc., to make it more likely that different people will arrive at the same about tag, without significantly affecting uniqueness or legibility. So an example about tag for a book is:

book:nineteen eighty four (george orwell)

Notice that the (troublesome) hyphen that we would normally include when writing “nineteen eighty-four” has been removed, as have capitals (there’s a library available to do the standardization, which can be used in python) or online.)

[The original version of the convention (book-1) also removed all accents from letters in an effort to reduce further the likelihood of minor variations; however, when Nicholas Tollervey (@ntoll) and Terry started publishing large volumes of book data that included some non-European names it became clear that this convention sometimes went a normalization too far, so the (so-far undocumented) book-u variant convention was born, in which letters are mapped to lower case, but accents are preserved. (This is supported in the python library, but not yet in the web app.)]

These conventions for about tags for books seem to me to hit the sweet spot I was talking about. Book titles, alone, are definitely not sufficiently unique in two different respects: first, it is not uncommon for different authors to write books with the same title; secondly book titles (alone) are frequently shared with other (non-book) items, like films, people, places etc. However, by combining a prefix (book:) that specifies the class of object, together with the title and the author (all normalized), we get something that feels, for practical purposes, pretty good uniqueness. I would be surprised if there are not examples of pairs of books that share both author and title, but I suspect those are so rare that they will cause us little trouble and (personally) feel quite content to do some ad hoc disambigation to handle those cases.

Indeed, the pattern of a class prefix, a main identifier, and a disambiguator, feels like a useful pattern for many kinds of Real-World™ entities to me. I’ve been discussing films, for example, with Michael Hawkes, in the comments on another blog post, and there is seems that using either film:title (year) or film:title (director) will probably work well. Again, there might be cases in which two directors sharing a name produce films of the same name, or in which two films of the same name are produced in the same year, but these seem likely to be so rare that ad hoc disambiguation of those cases might be acceptable. It is also, of course, not a coincidence that in the real world films are often identified by title and year or title and director. Michael and I both lean toward year as probably the better disambiguator, so I suspect I will soon be proposing film:title (year) as a convention; though American readers might prefer a “movie:” prefix.

For me, the other great virtue of this style of about tag is that it is very easy to construct the canonical about tag using only information that the user might reasonably expect to have at hand, rather than depending on some kind of external lookup. To labour the point, if I want to tag a book, I probably know the title and author, and can certainly find that information in the book. With a film, I concede, it would be less unusual to know the title but not the year or director, but even there, this data is easily available from multiple sources, crucially including from the film itself.

Perhaps unsurprisingly, there are those who feel that the whole notion of trying to organize, specify, or guide conventions is objectionably authoritarian and/or pointless, and that it would be much better simple to see what emerges organically. (Terry has been known to accuse me of “fascist librarian” tendencies, though I sure he means it in the nicest possible way.) Terry and I both studied so-called genetic algorithms, in which evolutionary processes are simulated on computers to tackle search and optimization tasks, and we are both impressed with the power of evolutionary mechanisms. I, however, fear that Fluidinfo doesn’t have the luxury evolutionary timescales to succeed, and therefore tend to favour trying to help evolution along a little. If you don’t, just ignore all this, do your own thing, and pay no attention to the annoying tsking from Scotland.

fdb.py version 1.28

I just pushed a minor revision of fdb.py to github.

One of the tests was failing as a result of an API change (deleting a tag that isn't on an object now causes returns a 204 (NO CONTENT) rather than a 404 error).

All tests should pass again now. Thanks to Joseph Marques for pointing out the problem.

The Music of FluidDB I: Albums, Tracks and Songs

I have been thinking for a while about what conventions for tagging kinds musical entities in FluidDB. The kinds of things I have in mind include recordings of music, pieces of music (compositions), artists and composers. My firmest conclusion so far is that it’s complicated and I can’t tackle it all in one go.

In particular, classical music feels very complicated to me, with a common situation for a classical “record” being recordings of several pieces with somewhat variable names, often by different composers, being played often by a somewhat fluid and ambiguous collection of musicians.

In this post, therefore, I’m going to try to tackle what feels like a simpler problem by restricting myself to considering non-classical music and three kinds of entities—albums, tracks and songs.

My basic suggestion is to adopt conventions very similar to those I have been championing for books, in the form of the book-1 convention.

Books (Recap)¶

Recall that book-1 convention for about tags for books in English has the following basic components:

• the prefix book:
• the title of the book, normalized using NACO-like conventions, which standardize to lower case, remove most punctuation and accents and regularize spacing;
• the author, again normalized in a NACO-like manner, in parentheses.

For example, Alice in Wonderland, by Lewis Carroll, uses the about tag

book:alice in wonderland (lewis carroll)

So far this convention seems to have worked quite well. Its virtues include:

• it is simple to construct with only easily available information (the stuff you can see if you have the book or a normal reference to it)
• it is unique for the almost all books
• it is clearly identified as a book (and thus disambiguated from a film, for example).

The next stage beyond a single-author book is multi-author books, and there the convention is simply to list the authors, in the order they appear on the book, separated by semicolons. For example, The Feynman Lectures on Physics, by Richard P. Feynman, Robert B. Leighton and Matthew Sands uses the about tag:

book:the feynman lectures on physics (richard p feynman; robert b leighton; matthew sands)

Albums, Tracks and Songs¶

Recorded non-classical music consists primarily of albums—a named collection of tracks, normally purchased together—and individual tracks, sometimes known as singles or songs.

At the simplest level, the conventions I am going to propose for about tags for albums and tracks are very similar to those for books but using the prefixes album: and track:. So the album, The Dark Side of the Moon, by Pink Floyd, is

album:the dark side of the moon (pink floyd)

and the track The Great Gig in the Sky, from that same album, is

track:the great gig in the sky (pink floyd)

But there are number of points to discuss.

Albums¶

The suggested about tag for albums is fairly straightforward. The main complication/ambiguity I can see concerns multi-volume sets. So, on vinyl, for example, Neil Young’s Decade has three disks; and it is a double CD. This is quite an easy case: I think we ignore the ‘disk’ number entirely where an just regard double and triple albums as albums. So all of Decade is:

album: decade (neil young)

For multi-volume collections that are normally sold separately, simply include the volume number. So, for example, The Tatum Group Masterpieces Volume 1, by Art Tatum, Benny Carter, Louis Bellson, becomes

album:the tatum group masterpieces volume 1 (art tatum; benny carter; louis bellson)

The NACO-like normalization conventions were described in this post and are implemented in the abouttag library.

The handling of artists is in principle quite simple, though in practice slightly hard to automate completely. My suggestion is that whenever there is a list of musicians, as with authors, they are simply separated with semicolons (and a space); any ampersands or ands are removed. In the case of groups, the group name is simply used. The interesting and slightly troubling cases are those where a group combines with person. The most common case of this is exemplified by Diana Ross and the Supremes. My suggestion is that such cases are left intact, other than normalization, using ‘and’ rather than ampersand (&). So the album “Reflections” becomes

album:reflections (diana ross and the supremes)

There are probably awkward corner cases, but I think this handles most.

The biggest problem I foresee is that it will hard to automate the construction of the standard form of an artist from something like iTunes metadata because the input (from Gracenote) doesn’t separate out a list of artists in any remotely consistent way, so I think standardizing them will require a degree of human intervention. This is not, however, in any way particular to this suggested convention; it’s fundamentally to do with the fact that some artists identified as a list of people, and others have a group name, and telling these apart is hard, even without complication such as the band Alice Cooper!

Here are a few examples of the sorts of album about tags I’m suggesting:

• The Black Balloon, by John Renbourn album:the blank balloon (john renbourn)
• The Composer, by Thelonious Monk album:the composer (thelonious monk)
• Fleetwood Mac, by Fleetwood Mac album:fleetwood mac (fleetwood mac)
• Wu Wei, by Pierre Bensusan album:wu wei (pierre bensusan)
• The Tatum Group Masterpieces Volume 1, by Art Tatum, Benny Carter, Louis Bellson album:the tatum group masterpieces volume 1 (art tatum; benny carter; louis bellson)
• Ms. Right, by Duck Baker album:ms right (duck baker)
• ‘Round About Midnight, by The Miles Davis Quintet album:round about midnight (the miles davis quintet)
• A Matter Of Time, by Gordon Giltrap & Martin Taylor album:a matter of time (gordon giltrap; martin taylor)
• Musiques / Solilaï, by Pierre Bensusan album:musiques solilai (pierre bensusan)
• Live Au New Morning, by Bensusan & Malherbe album:live au new morning (bensusan; malherbe)
• Eye To The Telescope, by KT Tunstall album:eye to the telescope (k t tunstall)
• Grace & Danger, by John Martyn album:grace & danger (john martyn)
• Alas, I Cannot Swim, by Laura Marling album:alas i cannot swim (laura marling)
• Lady In Autumn: The Best Of The Verve Years, by Billie Holiday album:lady in autumn the best of the verve years (billie holiday)

Tracks¶

I was originally minded to suggest using song: as the prefix for individual album tracks, notwithstanding the fact that this is slighty inappropriate for instrumental pieces. This was until I realised that we will certainly want to have entries for songs themselves (independent of artist) in FluidDB. Given this, I think we have little choice but to fall back to track, which is more perhaps more appropriate anyway.

I think there are couple of points to made about tracks. The first is that I do not propose to tie them to albums. Thus if an artist records a track (piece/song), I suggest that in the common case we don’t distinguish between different records. When you talk about Billie Holiday’s recording of God Bless the Child, you actually talk about all her records of that song, in the general case.

track:god bless the child (billie holiday)

Similarly, if, as is quite common, a track is qualified by (live) or [live], I suggest that be omitted in the standard case.

The other reasonably common complication, particularly for folk music, is the medley. In this case, my suggestion is just hand the track name to the NACO-like normalization routine and use what it produces. In most cases, this works fine.

To try to illustrate lots of common cases, here is a fairly long list of examples:

• Rhythm-a-Ning, by Thelonious Monk track:rhythm a ning (thelonious monk)
• Round Midnight, by Thelonious Monk track:round midnight (thelonious monk)
• Straight, No Chaser, by Thelonious Monk track:straight no chaser (thelonious monk)
• Bourrée I and II, by John Renbourn track:bourree i and ii (john renbourn)
• Medley: The Mist Covered Mountains of Home / The Orphan / Tarboulton, by John Renbourn track:medley the mist covered mountains of home the orphan tarboulton (john renbourn)
• Monday Morning, by Fleetwood Mac track:monday morning (fleetwood mac)
• Poussière d’Amants, by Pierre Bensusan track:poussiere damants (pierre bensusan)
• Doherty’s - Return to Milltown - Tommy People’s, by Tony McManus track:dohertys return to milltown tommy peoples (tony mcmanus)
• Jackie Coleman’s - The Milliner’s Daughter - Rakish Paddy - Connor Dunn’s, by Tony McManus track:jackie colemans the milliners daughter rakish paddy connor dunns (tony mcmanus)
• Blues in C, by Art Tatum, Benny Carter, Louis Bellson track:blues in c (art tatum; benny carter; louis bellson)
• S’Wonderful, by Art Tatum, Benny Carter, Louis Bellson track:swonderful (art tatum; benny carter; louis bellson)
• Makin’ Whoopee, by Art Tatum, Benny Carter, Louis Bellson track:makin whoopee (art tatum; benny carter; louis bellson)
• (I’m Left With the) Blues in my Heart, by Art Tatum, Benny Carter, Louis Bellson track:im left with the blues in my heart (art tatum; benny carter; louis bellson)
• The Nine Maidens a. Clarsach b. The Nine Maidens c. The Fiddler, by John Renbourn track:the nine maidens a clarsach b the nine maidens c the fiddler (john renbourn)
• Ms. Right, by Duck Baker track:ms right (duck baker)
• ‘Round Midnight, by The Miles Davis Quintet track:round midnight (the miles davis quintet)
• Ah-Leu-Cha, by The Miles Davis Quintet track:ah leu cha (the miles davis quintet)
• Across The Pond, by Gordon Giltrap & Martin Taylor track:across the pond (gordon giltrap; martin taylor)
• G & T Blues, by Gordon Giltrap & Martin Taylor track:g & t blues (gordon giltrap; martin taylor)
• Abide With Me / Old Gloryland, by Stefan Grossman & John Renbourn track:abide with me old gloryland (stefan grossman; john renbourn)
• Badhra, by Anouar Brahem, John Surman, Dave Holland, track:badhra (anouar brahem; john surman; dave holland)
• Biodag Aig Mac Thomais/The Nine Pint Coggie/The Spike Island Lasses, by Tony McManus track:biodag aig mac thomais the nine pint coggie the spike island lasses (tony mcmanus)
• Three Pieces By O’Carolan;The Lamentation Of Owen Roe O’Neill; Lord Inchiquin; Mrs Power (O’Carlan’s Concerto), by John Renbourn track:three pieces by ocarolan the lamentation of owen roe oneill lord inchiquin mrs power ocarlans concerto (john renbourn)
• Heman Dubh, by Pierre Bensusan track:heman dubh (pierre bensusan)
• Le Voyage pour L’Irelande, by Pierre Bensusan track:le voyage pour lirelande (pierre bensusan)
• 50 Ways To Leave Your Lover, by Paul Simon track:50 ways to leave your lover (paul simon)
• La Danse Du Capricorne 1, by Pierre Bensusan track:la danse du capricorne 1 (pierre bensusan)
• Reels - “The Pure Drop”/”The Flax In Bloom”, by Pierre Bensusan track:reels "the pure drop" "the flax in bloom" (pierre bensusan)
• Mille Vallées, by Bensusan & Malherbe track:mille vallees (bensusan; malherbe)
• Bamboo Shoot (Improvisation), by Bensusan & Malherbe track:bamboo shoot improvisation (bensusan; malherbe)
• Black Horse And The Cherry Tree, by KT Tunstall track:black horse and the cherry tree (k t tunstall)
• Universe & U, by KT Tunstall track:universe & u (k t tunstall)
• Sigmund Freud’s Impersonation Of Albert Einstein In America, by Randy Newman track:sigmund freuds impersonation of albert einstein in america (randy newman)
• Mr. President (Have Pity On The Working Man), by Randy Newman track:mr president have pity on the working man (randy newman)
• I Love L.A., by Randy Newman track:i love l a (randy newman)
• The Blues, by Randy Newman track:the blues (randy newman)
• Through-Us-All, by Isaac Guillory track:through us all (isaac guillory)
• A Terrible Pickle, by Dean Friedman track:a terrible pickle (dean friedman)
• Money, by Pink Floyd track:money (pink floyd)
• Take Five, by Dave Brubeck Quartet track:take five (dave brubeck quartet)
• Pirates (So Long Lonely Avenue), by Rickie Lee Jones track:pirates so long lonely avenue (rickie lee jones)
• The Returns, by Rickie Lee Jones track:the returns (rickie lee jones)
• Chuck E’s In Love, by Rickie Lee Jones track:chuck es in love (rickie lee jones)
• Harry’s House/Centerpiece, by Joni Mitchell track:harrys house centerpiece (joni mitchell)
• I’s A Muggin’ (Rap), by Joni Mitchell track:is a muggin rap (joni mitchell)
• Miles Beyond, by Mahavishnu Orchestra track:miles beyond (mahavishnu orchestra)
• A Surfer Courted Me, by Martha Tilston and the Woods track:a surfer courted me (martha tilston and the woods)
• Lookin’ On, by John Martyn track:lookin on (john martyn)
• The Captain And The Hourglass, by Laura Marling track:the captain and the hourglass (laura marling)
• Le Chien Sur Les Genoux de la Devineresse, by Anouar Brahem, Barbaros erkose, Kudsi Erguner & Lassad Hosni track:le chien sur les genoux de la devineresse (anouar brahem; barbaros erkose; kudsi erguner; lassad hosni)
• A Prayer, by Madeleine Peyroux track:a prayer (madeleine peyroux)
• Was I?, by Madeleine Peyroux track:was i (madeleine peyroux)
• (I Got A Man Crazy For Me) He’s Funny That Way, by Billie Holiday track:i got a man crazy for me hes funny that way (billie holiday)
• Lover Man (Oh, Where Can You Be?), by Billie Holiday track:lover man oh where can you be (billie holiday)
• St. Louis Blues, by Billie Holiday track:st louis blues (billie holiday)

Songs¶

[UPDATE 2011/01/19: I have modified this recommendation since it was first posted, after thinking more about the lack of consistency in how composers are identified.]

I have given less thought to songs (as distinct from tracks, or recordings of songs), but the obvious convention would seem to be to use the song: prefix, followed by the normalized song title, followed by the composer or composers in brackets, again in whatever order they are normally listed. The only real complication I can see there is the fairly common case in which music and lyrics are given separate credits. In that case, I think I suggest simply listing the music composer ahead of the lyrics composer.

The slightly subtle question concerns ow to standardize the composer’s name. I the case of artists (and authors) my normal recommendation is to start from the name as it appears on the work, so John Martyn, J. D. Salinger etc. This works well because you just have to look at the work to see how it is written; and for this reason, there’s a well-defined, standard place to look (the work).

Composers are more awkward, because it is much less clear where to look. If you own a record, the easy thing to do is to look at the sleeve, or the liner notes, or sometimes on the record (or CD) itself. But the same song can be recorded many times and the composer won’t always be displayed consistently. You could also look at the sheet music. Or in Wikipedia. In short, there is no consistency. A quick look through the first half dozen make it clear there’s not even consistency on a single CD in many cases.

In this case, therefore, my recommendation is to use surnames only. So in a simple case, Summertime by George Gershwin, is

song:summertime (gershwin)

The Lennon/McCartney partnership would produce, for example

song:hey jude (lennon; mccartney)

A case in which lyrics and music are credited separately would be Officer Krupke, from Westside Story, by Leonard Bernstein (music) and Stephen Sondheim (lyrics). So this would be:

song:office krupke (bernstein; sondheim)

The reason I’ve gone for surname only is that it seems to involve very little loss of precision (it will be rare indeed for two songs with the same title to have different composers with the same surname but different forenames), and to use the smallest amount of information that is commonly available. I think this is probably a fairly good convention.

Comments Invited¶

As ever, I’d be interested in thoughts from anyone, in the blog comments or directly. I haven’t pushed an updated version of the abouttag library containing these to github yet, but will probably do so in a few days unless there is significant push-back.

100 Bestsellers in FluidDB: So What?

This evening I published another hundred books to FluidDB. This time it was a list of the 100 best-selling books of the last 12 years, as published by the ever-wonderful Guardian Data Store. I published them as a table, mostly using the conventions documented in this post. If you’re using a modern browser (almost anything other than Internet Explorer) you can see a visualization of the FluidDB object for the table at abouttag.com/butterfly/about/table:bestsellers-1998-2010 and the best-selling book (Dan Brown’s The Da Vinci Code, depressingly) at abouttag.com/butterfly/about/book:the da vinci code (dan brown).

There’s a tag on each book that hyperlinks to the next, so you you could even click through all hundred if you really wanted.

So What?¶

Why should you or anyone else care that I’ve published this data to FluidDB? After all, the Guardian made the data available on Google docs, so anyone can do anything with it anyway. What’s the benefit of having it in FluidDB? I’m going to try to show a few things that might convince you there’s something interesting about putting this sort of data in FluidDB.

1. Query¶

The most obvious thing is that you can query data in FluidDB from anywhere with internet access without even having an account. For example, the query to find the best-selling book from the list in FluidDB is this:

miro/bestsellers-1998-2010/rank = 1

You can issue this query from anything that can talk to FluidDB and it should return the object corresponding to The Da Vinci Code, by Dan Brown. Here are a few ways of doing just that.

• You can use the FluidDB Explorer and just paste the query into the query box. It should locate the object (identifying it by its about tag, which is book:the da vinci code (dan brown) and also by its FluidDB ID, which is e7fee95f-4dcd-458b-8893-b56352d455cf. If you then click on either the about tag or the object ID, the explorer will give you a list of tags on the object, and tell you there are too many to show (which isn’t really true). If you then click ‘Load all tag values’ it will get them and show them to you.

• You can use my python library fdb, which has a command line tool with it and type:

  fdb show -q 'miro/bestsellers-1998-2010/rank = 1' /miro/bestsellers-1998-2010/title /miro/bestsellers-1998-2010/author

  This produces the following output:

  1 object matched
  Object e7fee95f-4dcd-458b-8893-b56352d455cf:
    /miro/bestsellers-1998-2010/title = "The Da Vinci Code"
    /miro/bestsellers-1998-2010/author = "Dan Brown"

• You can use curl at the command line (which is a utility installed on most systems by default) and type

  curl 'http://fluiddb.fluidinfo.com/values?query=miro/bestsellers-1998-2010/rank%3D1&tag=miro/bestsellers-1998-2010/title&tag=miro/bestsellers-1998-2010/author'

  which produces:

  {
    "results":
    {
      "id":
      {
        "e7fee95f-4dcd-458b-8893-b56352d455cf":
        {
          "miro/bestsellers-1998-2010/author": {"value": "Dan Brown"},
          "miro/bestsellers-1998-2010/title": {"value": "The Da Vinci Code"}}
      }
    }
  }
  

  (I’ve reformatted this slightly, but otherwise this is the exact output from FluidDB.).

• You could even just use the query directly in your browser’s URL bar. Pasting the following into the address bar should work in almost all browsers

  http://fluiddb.fluidinfo.com/values?query=miro/bestsellers-1998-2010/rank%3D1&tag=miro/bestsellers-1998-2010/title&tag=miro/bestsellers-1998-2010/author

  again, producing:

  {
    "results":
    {
      "id":
      {
        "e7fee95f-4dcd-458b-8893-b56352d455cf":
        {
          "miro/bestsellers-1998-2010/author": {"value": "Dan Brown"},
          "miro/bestsellers-1998-2010/title": {"value": "The Da Vinci Code"}}
      }
    }
  }
  

  In quite a few browsers, even the following will work:

  http://fluiddb.fluidinfo.com/values?query=miro/bestsellers-1998-2010/rank=1&tag=miro/bestsellers-1998-2010/title&tag=miro/bestsellers-1998-2010/author

2. More interesting queries¶

Regular readers of this blog will recall that I previously published a rather larger set of 1,000 books to FluidDB. These were again originally from the Guardian (though pre-dated the data store/data blog) and this time consisted of the the Guardian’s 1,000 novels that everyone must read. (See this post and this post for details.)

So an obvious question is: which of that original Guardian 1,000 books are in the 100 bestsellers of the last 12 years? The following FluidDB query will tell you:

has miro/books/guardian-1000 and has miro/bestsellers-1998-2010/title

(If I’d picked my tags better, this query would have been even simpler, but it’s not bad.)

As an illustration, if I issue that query, again asking for author and title, I get the following (using fdb):

fdb show -q 'has miro/books/guardian-1000 and has miro/bestsellers-1998-2010/title' /about /miro/books/title /miro/books/author

7 objects matched

Object ce180ce3-29b5-4abc-a031-64015b162f6a:
  /fluiddb/about = "book:birdsong (sebastian faulks)"
  /miro/books/title = "Birdsong"
  /miro/books/author = "Sebastian Faulks"

Object a2fa68ae-d409-422f-887a-dbdb7c1b4f18:
  /fluiddb/about = "book:atonement (ian mcewan)"
  /miro/books/title = "Atonement"
  /miro/books/author = "Ian McEwan"

Object d5ff7995-2ae6-4ba8-8549-ea1d0726484c:
  /fluiddb/about = "book:the kite runner (khaled hosseini)"
  /miro/books/title = "The Kite Runner"
  /miro/books/author = "Khaled Hosseini"

Object c64aeced-1505-4bb3-ab8a-0ce4c6a70ba3:
  /fluiddb/about = "book:white teeth (zadie smith)"
  /miro/books/title = "White Teeth"
  /miro/books/author = "Zadie Smith"

Object 7e076540-3e14-4232-8c46-13863bae77ec:
  /fluiddb/about = "book:the curious incident of the dog in the night time (mark haddon)"
  /miro/books/title = "The Curious Incident of the Dog in the Night-Time"
  /miro/books/author = "Mark Haddon"

Object 5be745bd-500d-458b-b4e6-dd08972b73f6:
  /fluiddb/about = "book:to kill a mockingbird (harper lee)"
  /miro/books/title = "To Kill A Mockingbird"
  /miro/books/author = "Harper Lee"

Object 3b416fa5-51ab-4160-9820-240a0591c3a2:
  /fluiddb/about = "book:the time travelers wife (audrey niffenegger)"
  /miro/books/title = "The Time Traveler's Wife"
  /miro/books/author = "Audrey Niffenegger"

(I’ve added some blank lines, but otherwise this is the raw output from fdb.)

Or perhaps I’d like to know all the books that sold over 2,000,000 copies. For that, the relevant FluidDB query is just:

miro/bestsellers-1998-2010/volume > 2000000

Again, illustrating with fdb, and this time asking only the for the about tag that FluidDB uses to identify the object, we get this (faintly depressing) list:

 fdb show -q 'miro/bestsellers-1998-2010/volume > 2000000' /about8 objects matched

Object b2ff54a0-d94e-4fe1-951f-a4bd839ba219:
  /fluiddb/about = "book:harry potter and the half blood prince childrens edition (j k rowling)"

Object e7fee95f-4dcd-458b-8893-b56352d455cf:
  /fluiddb/about = "book:the da vinci code (dan brown)"

Object 04033298-9be8-41b8-b9ef-d1b11b1adfb9:
  /fluiddb/about = "book:harry potter and the philosophers stone (j k rowling)"

Object 60c5bbea-2568-4a68-825f-ffc4cfb20f88:
  /fluiddb/about = "book:harry potter and the prisoner of azkaban (j k rowling)"

Object 9258d0da-a65a-471b-abdb-277b68ea1ea0:
  /fluiddb/about = "book:harry potter and the chamber of secrets (j k rowling)"

Object 04a4b407-7f21-450b-83c3-2d840ef6a133:
  /fluiddb/about = "book:deception point (dan brown)"

Object 23d5a20a-ba28-43b8-9265-2afd8c4019ee:
  /fluiddb/about = "book:twilight (stephenie meyer)"

Object 36bc89a5-d91c-4cdf-9389-ff2fbe833d59:
  /fluiddb/about = "book:angels and demons (dan brown)"

3. Combining Data Sources¶

One of the things that is really interesting about this example is to look at the seven books that overlap. For example, Audrey Niffenegger’s wonderful book, The Time Traveller’s Wife is on both lists. A core idea of FluidDB is that different information comes to be associated by being placed on the same FluidDB object. The about tag (fluiddb/about) can be used to choose the object. In the case of novels, that object is identified [1] by an about tag of the form book:title (author)—in this case, book:the time travelers wife (audrey niffernegger). Obviously, there’s room for ambiguity with case and punctuation etc., but there’s a library and a website that will sort most of that out for you.

When I uploaded data on the Guardian 1000 books, (as the miro user) there wasn’t all that much information—author, title, year and the fact that it was on the Guardian 1000 list is pretty much all that was there. For example, here is what Aldous Huxley’s Brave New World looks like:

(Live version here)

In the case of the best-sellers, the dataset contained a bit more information including sales volume, publisher, average selling prices and total sales value.

The marvellous thing is that books that are on both lists automatically get all the data from both sources, simply because they both chose the same FluidDB objects (e.g., the one with the about tag book:the time travelers wife (audrey niffernegger), which you can see live here in a modern browser), or as it is at the time I write:

When I published the second list, I found that it included books that I had already rated in FluidDB. For example, I had already (personally, as njr) rated Small Island, by Andrea Levy, and as a result, when (as the miro user) I published the list of bestsellers, my njr/rating was already on some of them.

I think this is a powerful example of the potential of FluidDB, one that would be even more potent if it had been someone other than I (albeit as Miró) who had published to the at least one of two lists previously. But the point is, anyone following the convention about where to put data about books in FluidDB could equally easily have published the data with the same result. As usage of the system increased, we will see this more and more.

Go Explore; Go Tag¶

This post just scratched the surface, but I hope it begins to show the real and tangible benefits of publishing data to FluidDB. The data becomes capable of being queried. Multiple data sources combine, sometimes in ways that had not been foreseen. It can be accessed visually, from a command line, or programmatically. And you can add your own data, whether it be annotations, ratings, comments, associations or whatever.

So go explore; and if you like, get an account and start tagging/publishing.

[1]

Regular readers will know that I am a rather strong advocate of conventions for about tags in FluidDB in general, and for this convention for books in particular. Anyone can publish any data to FluidDB using any objects or conventions they like; but, as this post illustrates, there are real benefits when different datasets concerning overlapping things use common conventions.

The FluidDB People App from @paparent

>

@paparent, author of the very useful FluidDB Explorer, has produced a simple app that shows the locations of FluidDB people on a Google Map. It’s inspired by the Djangopeople application, but so far has only the map.

If you’d like to add yourself (the more the better) you just need to add three tags into FluidDB—two to give your latitude and longitude, and one to tell @paparent’s app about you.

To do this all you need is a FluidDB account and some way of writing to FluidDB. It’s pretty easy using the command line from my fdb.py library, so I thought I’d quickly document how to do it.

The People application expects you to tag your user object in FluidDB with numeric tags in your namespace called people/latitude and people/longitude. So for me (njr), I had to do this:

fdb tag -a 'Object for the user named njr' people/latitude=55.8817504514
fdb tag -a 'Object for the user named njr' people/longitude=-3.10550451279

(You can see the tags on my object here, assuming you’re using a browser that isn’t Internet Explorer.)

The application collects users on the FluidDB objects with the about tag collection:peopleapp (UUID 62397fb0-6f96-404a-a8fa-ee3758cfa7f2) and looks for tags called peopleapp. So for me, that meant doing the following:

fdb tag -a 'collection:peopleapp' peopleapp

And that’s it.

Notes¶

A few things might not be clear, so I’ll explain them briefly.

1. My library, fdb.py, automatically creates namespaces and tags as required, so there was no need to create the njr/people namespace or any of the tags: when you write to them, fdb.py assumes you’d like them to exist.
2. I’ve left my username off the tags because fdb.py assumes that the tags you refer to are yours unless you stick a / at the start. So when I say people/latitide, fdb.py adds in njr/ at the start for me. If I want to refer to (say) paparent‘s latitude in fdb.py, I say /paparent/people/latitude. (This is slightly non-standard in FluidDB, but very convenient.)
3. The final tag command doesn’t set a value: this is fine, as FluidDB doesn’t require tags to have values (or, more accurately, allows null values, which is what this command sets). @paparent‘s people app doesn’t require a value on the tag, so this is enough.
4. In case it isn’t clear, the -a 'Object for the user named njr' is specifying the object to be tagged by its about tag. FluidDB creates an object for each user, and always gives it an about tag of this form.

So: go add yourself!

UPDATE¶

@paparent has added instructions for how to add yourself to the map using his FluidDB Explorer and Holger Durer (@HDurer) has written a blog post about how to use his emacs mode fluiddb.el to add yourself to the map without having to leave the comfort of emacs. How wonderful is that?