#musicbrainz

like the lyrics project

Heh

Well lyrics are fucking mess

I can't bare to add relations to recording by embedding links in wiki markup..

(in general)

We'd love to do lyrics ourselves for example, but licensing is ridiculous

:)

So I suspect most lyrics stuff has enough problems remaining alive to care much about best practices and design

LordSputnik1: well, bookbrainz to cocktailbrainz is still a big one! :p

urgh.. licensing.. copyright.. the enemies of data preservation

There's no decently done chocolate DB out there that I've seen :p

but is it a series of chocolates?

Well they're probably released

reosarevok: Well, that depends on your entities... you'd probably want a Glass, GlassType, Drink, Vendor, and then it's just a case of updating the schema

:)

it did come in a nice plastic box after all..

Well, arguably the same is true of MusicBrainz, LordSputnik1 ;) But designing separate schemas for stuff is hard :)

reosarevok: that depends on your entities, and how you go about storing data - if you move more of it into relationships, and focus on storing only an entity's properties on the entity itself, then changing from one Brainz to another is much easier

Oh, sure, that much is true - wikidata is much more flexible than MB

(by basically storing only a name on the entity and everything else as properties)

It still requires a lot of schema definition to make sense of the stuff, but not so much coding to make the schema work :)

Also, you could argue that by generalizing MB entities and storing them in a sharedBrainz, then you'd have a lot less entities to redefine between Brainzes

I mean, going full wikidata style is interesting in itself

They have just one entity "type", which can then be defined as a property, so basically is:artist

Our stuff has its benefits, but I'd be curious to see MB running on the WD model and see how it fit

Only without the deletionists :p

The code to only allow certain relationships for certain types would become more difficult, certainly

Well, to a degree, yes

You gain flexibility in some parts by making others more complex

We have that with BB already, due to our slightly different model of entities

I'm not saying we *should* work like that, just that it would be interesting :)

Ideally, entities would only store "adjectives", according to http://en.wikipedia.org/wiki/Entity%E2%80%93rel...

Of course, even with how we work now, that's still true

("orchestra married choir" is nonsensical, yet perfectly enterable in MB right now)

Yeah, that's where it might help to eventually have "Person" and "Group" general types, rather than "Artist"

we've talked about this in bookbrainz-devel a little (although sticking with Artist/Creator for now)

I mean, in BB "group" or "collective" is probably less likely to appear

(or well, less *common*, it will certainly appear)

(but if it's rare enough, trusting your users' common sense is less of a problem :p)

I protest. The bible says 'Adam and Eve', not 'Adam Mansell Orchestra and the Stevens Street Worship Choir'

:D

it's pretty confusing add relationships that don't give any sense of direction.. like "sibling"

Well, in that case the direction just doesn't matter :)

It's just there because there must be one, with the way MB works right now

well it does if you want to avoid relationship webs

or whatever the term was

Oh

I think for siblings, most people decided that "shrug"

I thought the standard was to relate all siblings to oldest sibling

Well, yes, that's the official guideline

But I think barely nobody has been following it much

ah, there's the guidelines.. and then there's reality :)

In any case, even if you do it that way, it doesn't matter whether the oldest is entity0 or entity1 in the DB

That just says "do not add a sibling rel between the other ones"

oh really?

that's good to know

I mean, dunno if it might to some purist, but given the lack of following for the loosest interpretation :p

right, the releationship entity doesn't contain any sense of direction so it doesn't matter who's 0 and who's 1

Yup

I do have a ticket to kinda give up on sibling and make do-not-cluster be for other things (like remasters)

LordSputnik1: the goal is to be able to define rels better in MB too, using roles

What are roles?

(in this context)

(so "sibling" is "n siblings", "member" is "1 group, n members", "recording" is "1 recording, 1 place, n performers, 1 recording engineer, etc"))

(instead of all being A x B)

But it's a lot of work :)

So for now...

Well, dunno if it's an official goal, anyway, but it's been talked about in the past a few times and the main objection was amount of effort but not actual opposition to the idea. At least in the core team

But yeah, pie in the sky at the moment I'd expect :) Who knows in the future though

Yeah that seems like a lot of work

reosarevok: BB relationship editor is sort of working here, have a play if you like/have time - http://bookbrainz.org/creator/09688598-bca7-44c... :)

(although if you try to submit, it'll silently fail because you aren't logged in...)

Heh

can't right now, I really should be in bed so I'll just finish work

Remind me tomorrow or one of these days though :)

ahh, BBC stuff?

Yup

Almost done for the day, but my gf has been looking at me like "bed time? please?" for a while so I should stop doing random stuff :p

does anyone recognize this error http://pastebin.com/caEYM3gM ?

i just got it when I tried to save updates to an album

"johtso | tools that consume musicbrainz data don't understand the concept of a series" - doesn't mean they can't be made to, so not really an excuse. MusicBrainz should not worry about how it's data can or cannot be used in other applications, as long as it is making its data available for use.

( Also, https://github.com/sampsyo/beets/issues/1273 )

Freso: I mostly agree, and I'm a data purist, but I do sometimes feel that if we're restricting it so much that it makes it completely useless and very hard to make usable, it might be too much :) )

I mean, in that we need people to have some kind of reason to add stuff, or it won't get added at all

So I'm fine with not being too strict on grey areas (although still strict on things that are just wrong)

johtso: I deliberately make sibling relationship clusters. Since, 1) I don't always know the age of all siblings, 2) If I go to the non-oldest sibling, I can still get information on all siblings, without relying on fetching an "entire" different artist+relationships.

Freso: yeah.. the current implementation is definitely flawed in that respect

is the optimum solution to have some kind of siblingship entity that the various artists are related to?

Isn't that basically what reosarevok talked about wrt "roles"?

ah, skipped over that *reads back through the discussion*

Yeah, that's the optimal choice :) Just not trivial, so for now we do what we can :)

wow, that sounds pretty snazzy

I think pretty much everyone links siblings to all the other siblings, it's not the most ideal way to enter the data, but it's not like any of the currently possible options are great

As long as the data's there it can always be migrated :)

it's just that every time we tried to fix that damn guideline, someone complained :P

so people were like fine, whatever, we'll just continue not following it like we have been since forever *grumble*, or something

The “siblingship entity” to which all the siblings should be related to is generally known as “parent”.

-to

people don't really like adding placeholder artists though, it feels like a hack

(and even if you disagree, that won't make people do it)

And introducing a new siblingship entity is better?

Not a new entity, no :)

The idea would be to allow relationships to have roles, so the sibling relationship wouldn't be A sibling B but "siblings: A and B and C and ..."

The “relationship that can have N participants” idea is broken, too.

Why? :)

For several reasons (and I have a tab with MBS-1159 open since a while back to comment on it).

In any case, that only would suggest even more that what people do (link everyone) is the most reasonable choice

But I'd be curious to know about the issues, really, because relationship roles seem pretty sensible to me