FluidDB Terminology
<h2>Introduction</h2>
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.
<h2>Objects</h2>
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.
<h2>Tags</h2>
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.
<h2>Values</h2>
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.
<h2>Namespaces</h2>
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.
<h2>Permissions</h2>
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”.)
<h2>Policies</h2>
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”.)
<h2>Users</h2>
Users have a name, a username,
and an object, explained in the following section.
<h2>Where are the IDs?</h2>
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 them.
The proper identifier of a tag or a namespace in the system is
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 the user is deleted, the corresponding object is not. Remember,
objects are immortal. In particular if the user 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.
Syndicated 2009-09-08 02:39:54 from FluidThinking