I can't bare to add relations to recording by embedding links in wiki markup..
reosarevok
(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
johtso
urgh.. licensing.. copyright.. the enemies of data preservation
reosarevok wants a chocolatebrainz
reosarevok
There's no decently done chocolate DB out there that I've seen :p
johtso
but is it a series of chocolates?
reosarevok
Well they're probably released
LordSputnik1
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
reosarevok
:)
johtso
it did come in a nice plastic box after all..
reosarevok
Well, arguably the same is true of MusicBrainz, LordSputnik1 ;) But designing separate schemas for stuff is hard :)
LordSputnik1
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
reosarevok
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 :)
LordSputnik1
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
reosarevok
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
LordSputnik1
The code to only allow certain relationships for certain types would become more difficult, certainly
reosarevok
Well, to a degree, yes
You gain flexibility in some parts by making others more complex
LordSputnik1
We have that with BB already, due to our slightly different model of entities
reosarevok
I'm not saying we *should* work like that, just that it would be interesting :)
Of course, even with how we work now, that's still true
("orchestra married choir" is nonsensical, yet perfectly enterable in MB right now)
LordSputnik1
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)
reosarevok
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)
CallerNo6
I protest. The bible says 'Adam and Eve', not 'Adam Mansell Orchestra and the Stevens Street Worship Choir'
LordSputnik1
:D
johtso
it's pretty confusing add relationships that don't give any sense of direction.. like "sibling"
reosarevok
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
johtso
well it does if you want to avoid relationship webs
or whatever the term was
reosarevok
Oh
I think for siblings, most people decided that "shrug"
johtso
I thought the standard was to relate all siblings to oldest sibling
reosarevok
Well, yes, that's the official guideline
But I think barely nobody has been following it much
johtso
ah, there's the guidelines.. and then there's reality :)
reosarevok
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"
johtso
oh really?
that's good to know
reosarevok
I mean, dunno if it might to some purist, but given the lack of following for the loosest interpretation :p
johtso
right, the releationship entity doesn't contain any sense of direction so it doesn't matter who's 0 and who's 1
reosarevok
Yup
LordSputnik1
:P I think it'd be possible to store all siblings in a single relationship in BookBrainz with a few small tweaks
reosarevok
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
LordSputnik1
What are roles?
(in this context)
reosarevok
(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...
gnu_andrew joined the channel
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
i just got it when I tried to save updates to an album
Junior_ joined the channel
simukis_ joined the channel
simukis_ joined the channel
nikki joined the channel
chungy joined the channel
zas joined the channel
ruaok joined the channel
reosarevok joined the channel
reosarevok joined the channel
simukis_ joined the channel
hibiscuskazeneko joined the channel
shredpub joined the channel
DarkerAudit joined the channel
DarkestAudit joined the channel
DarkerAudit joined the channel
DarkestAudit joined the channel
sertansenturk joined the channel
ruaok joined the channel
achadwick joined the channel
KRS-Cuan joined the channel
Freso
"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.
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)
Freso
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.
johtso
Freso: yeah.. the current implementation is definitely flawed in that respect
Freso done with backlog o/
is the optimum solution to have some kind of siblingship entity that the various artists are related to?
Freso
Isn't that basically what reosarevok talked about wrt "roles"?
johtso
ah, skipped over that *reads back through the discussion*
reosarevok
Yeah, that's the optimal choice :) Just not trivial, so for now we do what we can :)
johtso
wow, that sounds pretty snazzy
nikki
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
johtso
As long as the data's there it can always be migrated :)
nikki
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
chirlu` joined the channel
chirlu`
The “siblingship entity” to which all the siblings should be related to is generally known as “parent”.
-to
nikki
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)
chirlu`
And introducing a new siblingship entity is better?
reosarevok
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 ..."
chirlu`
The “relationship that can have N participants” idea is broken, too.
reosarevok
Why? :)
chirlu`
For several reasons (and I have a tab with MBS-1159 open since a while back to comment on it).
reosarevok
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