[fluiddb-discuss] Music info in Fluid?

[Jeremy Dunck]

Are there any objects for artists, songs, etc? If so, what tags
should I look for?

[Terry Jones]

Hi Jeremy

> Are there any objects for artists, songs, etc?

Not that I know of. I've looked at some music databases occasionally, but
never come to any strong conclusion about how best to store it.

I did write some Python a couple of years ago to read my iTunes XML file
and to pull out various tags and put them onto FluidDB objects. That
allowed searches like "show me songs that XXX has listened to more than N
times and which I've not heard" etc. A little tool like that that was used
by even a small number of people would be pretty interesting. I sometimes
give the example of Fred Wilson (the NY VC) who releases his "best of" list
each year - in HTML. If he were simply adding a fred/bestOf/2010 tag to
FluidDB objects, people could do searches to see what he'd been listening
to this year but not last. Other people could add their bestOf tags,
allowing more. That sort of listening data is very social, of course. So I
think there's a ton of potential there.

Terry

[Jeremy Dunck]

On Fri, May 7, 2010 at 12:01 AM, Terry Jones <te...@fluidinfo.com> wrote:
> Hi Jeremy
>
>> Are there any objects for artists, songs, etc?
>
> Not that I know of.  I've looked at some music databases occasionally, but
> never come to any strong conclusion about how best to store it.

I was wondering, on tunkrank, if you worked a deal with them to use
the tunkrank namespace?

Do you think it's worth trying to work a deal with music brainz,
lastfm, etc. for tags of their systems?

How did that argument go? "We have this shared DB, would like to
store your data in it, and this would be more trusted if it used a
namespace of your domain"?

...

> That sort of listening data is very social, of course. So I
> think there's a ton of potential there.

Yep. When I explain Fluid to people, the question the arrive at is
"how can my relational data be fit into tags". Some tags define
relationships, and some tags are "columns" to the object's row.
That's one way to think of it. Have you had success with other
explanations?

[njr]

On May 7, 3:58 pm, Jeremy Dunck <jdu...@gmail.com> wrote:
> On Fri, May 7, 2010 at 12:01 AM, Terry Jones <te...@fluidinfo.com> wrote:
> > Hi Jeremy
>
> >> Are there any objects for artists, songs, etc?

I don't know of any, either, but I am collecting conventions for the
about tag, and music is an obvious area. I've done some stuff with
books (mostly novels) already. See:

http://abouttag.blogspot.com/2010/03/how-to-tag-books-in-fluiddb.html


> [...]

>
> Yep.  When I explain Fluid to people, the question the arrive at is
> "how can my relational data be fit into tags".  Some tags define
> relationships, and some tags are "columns" to the object's row.
> That's one way to think of it.  Have you had success with other
> explanations?

I also gave some thought to relational data in FluidDB, and again
there's a blog post:

http://abouttag.blogspot.com/2010/03/order-from-chaos-tagging-and-tabulating.html

Hope at least one of these helps.

Obviously, if you do start using some convention, let me know and I'll
add it to the list at

http://abouttag.blogspot.com/2010/03/about-tag-conventions-in-fluiddb.html

or if you want to discuss conventions, I'll be interested in that too.

Regards

Nick

[Nicholas Tollervey]

Hi,

As a classical buff I've been thinking about putting musical
information into FluidDB for quite a while.

For example, my first thought was to represent each musical "work"
with an object - but what about works that contain more than one
piece..? (Like a symphony that has several movements.) There would
need to be a way to indicate the relationship between "works" and
"pieces" (upon reflection this would need to be many-to-many: a work
can include many pieces and a piece can be re-used in many works - for
instance, J.S.Bach was into re-cycling).

What should be tagged to an object that represents a piece? I think I
need to attach the obvious tag-values indicating composer[s], title
and so on. But what about performances..? I'd want to be able to
represent information like this:

"There is a piece that is called "Yesterday", that was composed by
McCartney, that has a performance given by a group called The Beatles,
that was recorded as part of the the work with the title "Help!"
(which is also an album) etc..."

The number of objects required would appear to be growing to represent
all sorts of entities...

I might even store an mp3 of a recording as a tag-value associated
with a performance - or in the case of classical music, a Lilypond
source file for generating the score of a piece.

Then there is always the generic "ntoll/rating" tag that attaches to
performances, pieces, performers, groups, composers, beer, books,
films, whatever... ;-)

My *current* attitude is to create objects and tag them using what *I
think* are conventions that are just about good enough for my
purposes. If others agree with my decisions and practices they're
going to copy them but if they don't they can still tag the resulting
objects in a way that suits them (which is why about tags are so
useful).

I suppose I'm erring on being messy, spontaneous, and just "good
enough" in the hope that conventions emerge over time. (Obviously I'd
encourage care and attention when deciding how to tag things.)

Also, I love the way FluidDB lets *me* decide how to represent
information rather than adapting to a pre-planned and imposed schema.
If you don't like how *I've* organised the musical information you can
always annotate the resulting objects in a way that suits you. This is
why FluidDB's writeability is (yet another) killer feature. The user
controls the data rather than the database forcing users to adapt to
its schema.

So, apologies for not answering the initial question (what tags to
look for..?). I suppose I'm encouraging you to not worry too much
about it and just get stuck in. If it works we'll all play along...

:-)

Nicholas.

[Terry Jones]

Hi Jeremy

Sorry for another slow reply - I was thinking about this issue today and
remembered your question (hey - at least you ask memorable questions! :-))

>>>>> "Jeremy" == Jeremy Dunck <jdu...@gmail.com> writes:
> I was wondering, on tunkrank, if you worked a deal with them to use the
> tunkrank namespace?

I wrote to Jason and told him about FluidDB (he already knew something) and
suggested putting tunkrank.com/score onto objects. There wasn't a deal of
any kind, I think he just saw it as an obviously good thing to do. Having
the tunkrank.com domain stamped on the data, and having control over the
tag (including even being able to stop Tickery from reading it) were, I'm
pretty sure, things that were convincing.

Another factor which I think will be useful (though I have no idea if Jason
cared about it) is the argument that by placing your data into FluidDB in
this way, you're increasing its usefulness and therefore its value. If your
data is on objects that other apps also put tags onto, there's a much
better chance your data will be used in interesting ways you couldn't have
anticipated and which would be much harder to build if your data was on its
own server behind yet another custom API.

I bet you've already thought of all that too, though :-)

> Do you think it's worth trying to work a deal with music brainz, lastfm,
> etc. for tags of their systems?

Yes, in time. We still need to do fundamental work on making FluidDB faster
before trying to encourage massive amounts of data. Plus there are some
pending API additions to make life easier for apps.

We've had a ton going on recently, and it's now coming to a close (stay
tuned for news - on Monday). I hope that will mean we'll get back to making
more progress on the product :-) Startup life is really weird sometimes.

> Yep. When I explain Fluid to people, the question the arrive at is "how
> can my relational data be fit into tags". Some tags define
> relationships, and some tags are "columns" to the object's row. That's
> one way to think of it. Have you had success with other explanations?

I've tried many :-) I wrote this, which is pitched at a level that I think
is a bit above what you're looking for:

http://blogs.fluidinfo.com/fluidDB/2009/08/25/kaleidoscope-10-takes-on-fluiddb/

Late last year I went to lunch with two Fluidinfo investors, and a guest at
the lunch was asking what FluidDB is. I did my best to explain. One of the
investors gave a summary like yours above. He said (paraphrasing): Imagine
you had an infinitely large shared online spreadsheet. Anyone can add a row
or a column. The columns have a permissions system, so you can stop people
looking at the values of the cells if you like and if you have write
permission for a column, you can put any value in cells in that column, etc.

I thought that was pretty neat, and very simple (though it leaves out
various things, like the query language, typed data). So did the other guy,
who also asked if he could invest :-)

I realize you were asking for other explanations. Maybe see the Paul
Graham one at the end of that posting.

Terry