Posted Monday, September 7th, 2009 at 20:39 under Design.

FluidDB Terminology

Introduction

This post explains the terminology I’ve come up with after two weeks working in Net::FluidDB.

There’s no Perl in this post because albeit my laboratory is said module what I want to communicate are abstractions, not some particular implementation. We talk here about nouns and verbs, and introduce a model to some extent.

Note the focus is on a chosen terminology, this post does not explain the involved concepts themselves. The high-level docs explain FluidDB as such.

Objects

We start with objects. Objects are the central entities in FluidDB. They have an id, which is a meaningless UUID, and an about attribute, which is an optional arbitrary string.

An object knows the paths of the existing tags on it, that’s a set of strings called tag_paths. The following section explains what is a tag and a path.

Tags

The next most important entity in FluidDB is the tag. For example, “fxn/was-here”.

Tags have a description, which is a string attribute, and can be indexed, a boolean. They have also an object, explained later.

Tags have a path, “fxn/was-here”, and a name. The name is the rightmost fragment of the path, “was-here” in the previous example.

Each tag belongs to a namespace. Namespaces are explained later.

To tag an object you associate a tag and (optionally) a value to it.

In an object-oriented language tagging an object could look like this:

    object.tag(rating, 10)

The method name is a verb, and the first argument is a tag.

A library may provide a convenient way to tag an object given a tag path:

    object.tag("fxn/rating", 10)

There “fxn/rating” acts as an identifier, it points to the tag with that path, if any. In fact that’s what the REST API asks for, but that’s low-level stuff, the schema we are presenting runs at a higher level.

In a dynamic language you can have such a dynamic signature. In a statically typed language you would probably have different methods for different signatures. But that’s not important for the mental model we are building.

Tags in FluidDB are not typed. You could tag an object as having an “fxn/rating” of 10, and tag another object as having an “fxn/rating” of “five stars”. Values are typed.

Values

Tagging involves an object, a tag, and optionally a value. Values are typed. There’s some technical stuff related to encodings and such, but for the purposes of this post I think we do not need to go further.

Namespaces

To organize tags FluidDB provides namespaces.

Namespaces have a description, which is a string attribute, and an object, explained later.

Namespaces can contain other namespaces, and tags. Tags cannot, tags are leaves.

The namespace_names attribute of a namespace is the possibly empty set of the names of its children namespaces. The tag_names attribute of a namespace is the possibly empty set of the names of its tags.

Each namespace that is not top-level has a parent. A concrete implementation may define the parent of a root namespace to be some sort of null object.

Any namespace has a path, and a name, akin to tags. The namespace with path “fxn/reading/books” has name “books”. Its parent has path “fxn/reading”, and name “reading”.

You can compute the path of any child namespace or tag from the path of the containing namespace and their respective names.

Permissions

Each possible action on each existing tag and namespace has a permission associated with it. A permission consists of a policy and an exception list, to be applied to a certain category and action.

The policy may be open, or closed, and the exception list is a set of usernames. (Note: FluidDB in general lacks ordered collections, read “set” when you see “list”.)

Policies

Each possible action on tags and namespaces have a default set of permissions. When you create a tag or a namespace, each one of the possible actions gets such defaults. Each of those defaults is called by definition a policy.

There’s a name clash here which is not good. It is inherited from the API. I’ve departed in some places from the API, but I believe we need to stick to it in this case: A policy consists of a policy and an exception list, to be associated with certain category and action on behalf of a certain user.

The policy attribute may be open or closed, and the exception list is a set of usernames. (Note: FluidDB in general lacks ordered collections, read “set” when you see “list”.)

Users

Users have a name, a username, and an object, explained in the following section.

Where are the IDs?

If you are familiar with the API you may be wondering where did the IDs of tags, namespaces, and users go, and what are those objects I’ve mentioned.

Tags, namespaces, and users are not FluidDB objects themselves. They have no ID, they have no about, you can delete a tag.

The proper identifier of a tag or a namespace in the system are their paths, and the one of a user its username.

FluidDB, however, creates an object for each tag, namespace, and user. They can be found in their object attribute. So, for example, if you wanted to tag the user whose username is “fxn” there’s a canonical object in the system for it. You can tag that object, but you cannot tag the user itself.

If a namespace is deleted, the corresponding object is not. Remember, objects are immortal. In particular if the namespace was tagged the tags are still there, with the object that represented it in FluidDB. This parallels the object for any other thing in life that once existed.

Update: Reworded the last section to have examples with tags or namespaces instead of users because as of this writing users can’t be deleted. Thanks Esteve for pointing this out.

2 Responses to “FluidDB Terminology”

  1. Esteve Says:

    Thanks for the article, it’s really useful. Here are some remarks:

    - about is just a tag, not an attribute of an object. Although it’s special (immutable, can only be created when a new object is created, etc.) it behaves just like any other tag: it’s searchable, indexed, subject to the same constraints, etc.

    - the API uses name for users’ real names (e.g. Xavier Noria), whereas username is your login name (e.g. fxn)

    - users are not deletable. We’ll probably make this a feature once we get out of the private alpha. The reason is fairly simple, nobody wants to inherit someone else’s reputation. It also makes FluidDB much simpler from the technical point of view.

    - I found the last section slightly confusing. Users don’t have a direct representation inside FluidDB (I’m talking about the system, not the API), that is, a user is just an object with a bunch of tags. For example, the way I’m represented inside FluidDB is by a random object tagged with fluiddb/users/username (= “esteve”), fluiddb/users/password (= my hashed password), fluiddb/users/name (=”Esteve Fernandez”), there’s nothing else. It’s useful to think of everything as a combination of object + tag, because that way you realize that everything is searchable, mashable, etc. and that all objects (whether they represent a user, a namespace, an already created tag or just a user-created tag, are taggable). So, in practice I can say that I’m going to tag you with esteve/friend, although we know that I’m tagging the object tagged with fluiddb/users/username = “fxn”, with an instance of the esteve/friend tag.

  2. Xavier Noria Says:

    Hi Esteve thanks for the comment.

    I corrected the misinterpretation of the API regarding user names in the post.

    Regarding representations, the public interface for users does not talk about objects. A GET on /users/username retrieves a user resource, and that includes its name (which is not an attribute of objects).

    The fact that users are handled by FluidDB internally as objects is an implementation detail in my opinion. In my view it is coherent to say that tags, namespaces, and users are FluidDB resources that have a canonical object for them.

    That’s useful to know because if you want to tag a user, or to tag a tag, you know which object you should tag. The one the resource points to in the id field.

Leave a Reply