Re: [mb-style] Re: AR implicit/explicit propagation: to
2007/12/5, Olivier [EMAIL PROTECTED]: That's not a philosophical point, but rather a logical point (begging the question, to be exact) Am referring to petitio principii, not to other (modern) usages of begging the question. Arrr, what about continuing this thread in French instead? :p ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
Propagating not as in copying, but as in displaying on later releases of the same track/release. Editing can only be done at the original point. I'm frankly failing to see the problem. Yes, we have inconsistency in some respects, but I don't see the urgency to fix it using some scheme that would mean be creating or removing redundant data (neither action is very useful). In other words, I support only adding AR:s at the earliest release, not removing data just for the sake of it and living with the inconsistency until we have a proper technical solution. Philip On 12/5/07, Olivier [EMAIL PROTECTED] wrote: 2007/12/5, Philip Jägenstedt [EMAIL PROTECTED]: Is there a great urgency? Why not wait until there is a way to propagate AR:s to later releases of the same release/track instead of rushing ahead? Apart from the nice feeling of having complete tags with composer and all, does anyone actually have a solid use case for these that would justify violating the don't create relationship clusters policy and creating AR:s which will inevitably have to be cleaned up in the future? Philip I'm not sure I understood you point correctly. I don't think anyone supported the idea of propagating things. It was mentioned as a possibility, but not a realistic one. Regards, - Olivier ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
2007/12/5, Philip Jägenstedt [EMAIL PROTECTED]: Is there a great urgency? Why not wait until there is a way to propagate AR:s to later releases of the same release/track instead of rushing ahead? Apart from the nice feeling of having complete tags with composer and all, does anyone actually have a solid use case for these that would justify violating the don't create relationship clusters policy and creating AR:s which will inevitably have to be cleaned up in the future? Philip I'm not sure I understood you point correctly. I don't think anyone supported the idea of propagating things. It was mentioned as a possibility, but not a realistic one. Regards, - Olivier ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
2007/12/5, Brian Schweitzer [EMAIL PROTECTED]: Having consistent data accross a subset of the database (see the examples above). While I understand your reasoning here, until we do have a way to carry forward ARs in practice, and not in theory, so long as the ARs are not incorrect, I don't see them as harmful here. Yes, one track has a more complete set of sum total AR data than the other, but per specific AR that is redundant, I think we do have consistency. Where we don't, see previous point about if the ARs are correct - if they don't match, obviously something is either wrong or missing. BF :-) Does stating we have consistency and denying we have not makes you feel better? :D Whatever you want to call it to diminish the problem, you cannot deny there is something wrong. * Don't touch existing (correct) ARs Mmmm, what if I added the AR myself, and now regret I did (in regard of your previous point)? Does it give me the right to remove it? :-) Perhaps it's a philosophical point, but to my eyes, while I will definitely take ownership for the add data edit in a note that fixes erronious data I have entered, if the data is good, upon my having entered it, my sense is that I no longer have any greater ownership over that data - it has become common property. So no, I would say, so long as the data is good (redundant or not), whether you, I, or an editor who stopped editing 4 years ago added the data, noone has any greater right to remove the AR. In other words, if the AR is correct data, and you're trying to remove it because it is redundant, I would vote no without regard to who originally added the AR. That's not a philosophical point, but rather a logical point (begging the question, to be exact): first supporting a no-resolution that let us in a state where editors are (theoretically) free to choose the way they prefer the data to be represented (AR forwarded or not), then state that you'll not support the editor's choice if it doesn't go with your own preference... - Olivier ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
On Dec 5, 2007 12:11 PM, Olivier [EMAIL PROTECTED] wrote: If you think the right way to handle this is demise, then well, what can I say? :-) Demise is one thing, denying there is a problem (even if I'm the only poor soul fighting with it) is another. Nobody in this thread said there is no problem. But your solution is no solutions at all, it's just a temporary workaround with a flaw: It results in broken later releases, as there is no way anymore to have ARs on later releases. If I own, for example, a re-release of an album and I want to have the ARs available on my version of the album, how would I achieve that with your solution? As I said earlier: It's a technical problem and we need a technical solution for it, not some temporary guideline that avoids some problems and introduces some new. -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
On 12/5/07, Olivier [EMAIL PROTECTED] wrote: 1- currently, both ways of documenting ARs are tolerated: editors who want to document exhaustive AR (even when entities are linked to an earlier one with already all the data) are allowed to do so, and editors who prefer to document only the earliest one obviously can't be forced to propagate I'd vote no adding redundant AR:s as the SSSP at hand is http://wiki.musicbrainz.org/DontMakeRelationshipClusters (although some disagree that duplicating AR:s is in fact such a cluster) 2- THOUGH, the later kind of editors are not allowed to remove (partial) ARs from later releases (even if they added it themselves in the first place), based on the argument that, errr, why would they? and, errr, well, e it's bad! and errr, well, data will be in good shape anyway at some point in the future so why would we want data to be in good shape now, hey? If something is particularly messy and confusing, then I certainly wouldn't oppose removing or adding a bit to put it in order, but doing it in general does seem like a bit of a waste of time. edits that will clutter the open queue 6- all this anyhow concerns only 0.0001% of the tracks, so given the so little quantity of ARs affected, why would we even bother/need to discuss all this? (same author as 5-! who deserves an Award for supporting the two statements :D) My guess is that 99% of the edits are for 1% of the data, so the above doesn't exactly imply show that the number of edits relating to this would be 0.0001% of the open edits. Personally, I'm not very concerned with the volume either, so I wouldn't vote no on useless edits just to spite you. Promise! 9- REMOVING IS BAD!!! NEVER EVER REMOVE ANYTHING!!! :D Haha, not quite. In the sincere hope everyone can take a good laugh about all this ;) (and not throw stones at me). OK, I'm putting the rocks away... Philip ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
2007/12/5, Bram van Dijk [EMAIL PROTECTED]: Well, as I see it: both your solutions (remove AR's from later releases; add AR's to later releases) require lots of editing effort, No. Only the later requires such efforts. The former *lights-up* editing efforts, as it makes maintenance and adding *much easier*. and since there will (some day) be a technical solution to these issues, Ya, some day (see previous post :D) the concensus seems to be that this effort can be used in more productive ways. Agreed. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
2007/12/5, Philipp Wolfer [EMAIL PROTECTED]: On Dec 5, 2007 12:11 PM, Olivier [EMAIL PROTECTED] wrote: If you think the right way to handle this is demise, then well, what can I say? :-) Demise is one thing, denying there is a problem (even if I'm the only poor soul fighting with it) is another. Nobody in this thread said there is no problem. But your solution is no solutions at all, it's just a temporary workaround with a flaw: It results in broken later releases, as there is no way anymore to have ARs on later releases. The don't do anything solution is no better (from a broken point of vue): it result in the situation where there is no way to have a consistent AR style across releases on an artist. If I own, for example, a re-release of an album and I want to have the ARs available on my version of the album, how would I achieve that with your solution? As I said earlier: It's a technical problem and we need a technical solution for it, not some temporary guideline that avoids some problems and introduces some new. So, are you saying: doing nothing and ignoring the data chaos and contradiction in the db is better than any proposition at all? (until we have the proper technical solution) But if I misunderstood and you do actually have a suggestion (other than: let's ignore - the future will be all good), we desperately need one... ;) Again, I never asked for a guideline, nor an editing crusade. I barely pointed out there is a problem that (as far as I can tell) was not mentioned before and that (maybe?) deserve some thinking. - Olivier ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
2007/12/5, Philip Jägenstedt [EMAIL PROTECTED]: I do quite a bit of AR editing, Certainly. and simply link to the first release of the track if it is a re-release. This takes a lot less time than adding new AR:s. Definitely the right thing to do. I don't think this is maintenance hell but rather what requires the least editing of all the options that have been presented. Obviously yes. The problems come when *later* tracks that are linked to this earliest *already* have *some* ARs set. Granted, I sometimes resort to adding earlier releases so that I actually HAVE the first version to link to, but this is good for the database. Again, I definitely agree. Adding early releases constitutes most of my own adds. I wouldn't really object to someone using the earliest version in the database if they can't be bothered though... I probably would, but that's another topic. I don't know what parts of the database you're editing That depends heavily on the season, the food I've been eating, the state of my love affairs, etc. Though, I'm supposed to be jailed in the jazz part of it (which almost nobody ever enters), for being too much of a disturbance if I go in zones where there are actually other people :] or what kind of AR:s you're adding, but I haven't experienced the big demise of the current situation in my editing. Given the kind of stuff I'm editing these days (prior 1940), mostly performers, composers, and whenever the info exists, producers and engineers (not speaking about ARs Labels which are an entirely different beast). I'm not saying there isn't a problem, I'm just questioning if it is really urgent enough to warrant any of the suggested solutions. Well... haven't we gone around the whole topic two or three times? ;) Your opinion is certainly fair, just like the opinion of all the other fine people who took part in this. Now, to be quite frank, I don't see this discussion going nowhere and it's getting somewhat boring/tiring/not worth the effort.So, I guess I'll be managing the problem as I can, until the famous Track Masters save the day. Now, for the record, and to end-up this thread, may I provide a quick summary for future reference? (and also to have some fun about all this :D) Obviously, it's slightly biased, and the slightly disrespectful :-) quotes are not necessarily word by word, though the authors will definitely identify themselves. I hope everybody can taste the fun in it - it's not meant to be harsh, definitely 1- currently, both ways of documenting ARs are tolerated: editors who want to document exhaustive AR (even when entities are linked to an earlier one with already all the data) are allowed to do so, and editors who prefer to document only the earliest one obviously can't be forced to propagate 2- THOUGH, the later kind of editors are not allowed to remove (partial) ARs from later releases (even if they added it themselves in the first place), based on the argument that, errr, why would they? and, errr, well, e it's bad! and errr, well, data will be in good shape anyway at some point in the future so why would we want data to be in good shape now, hey? 3- either way are strictly equivalent from a future point of vue, and the introduction of masters will result in the same dataset 4- there is absolutely no problem in having bad-shaped data right now (that's MB, right? We suck, but we are discussing right now how we will be rocking in 200 years!) 5- doing otherwise (eg: removing the later ARs) will generate tons of edits that will clutter the open queue 6- all this anyhow concerns only 0.0001% of the tracks, so given the so little quantity of ARs affected, why would we even bother/need to discuss all this? (same author as 5-! who deserves an Award for supporting the two statements :D) 7- the additional work/pain in editing generated by this situation is clearly out-weighted by the SSSP (that's the MB Super Sacro Saint Principle - here manifested in a variant of this information is not essentially wrong), principle which has to be obeyed at all costs including extra work for editors, increased maintenance difficulties and bad-shaped information 8- solving practical problems is not really interesting, because it's too complicated and there is no simple answer. On the other hand, it's much better and easier to just speak about the SSSP, as the only question asked is Do you believe in the SSSP? and the only answer is Yes (if it's No, then you're a bad MB person! and you get stoned by the others good MB persons) 9- REMOVING IS BAD!!! NEVER EVER REMOVE ANYTHING!!! :D In the sincere hope everyone can take a good laugh about all this ;) (and not throw stones at me). Regards - Olivier ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
Here's still something I don't get: the most repeated argument I get is Track Masters will come soon, so your problems will go away, meanwhile you have to wait But when I suggest something that actually ease the situation quite a bit (though it obviously has the drawback you mentioned), I'm getting strict opposition, and suddenly the previous Track Masters will come soon argument seem to not apply to that drawback any longer. Meaning: this is temporary, meant to address a very specific problem, with *very little impact* on the database. What makes it so bad that it's considered worth than the chaos/inconsistent style we currently have? Regards, - Olivier ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
2007/12/5, Philip Jägenstedt [EMAIL PROTECTED]: Propagating not as in copying, but as in displaying on later releases of the same track/release. Editing can only be done at the original point. I'm frankly failing to see the problem. Yes, we have inconsistency in some respects, but I don't see the urgency to fix it using some scheme that would mean be creating or removing redundant data (neither action is very useful). See previous posts in this thread, or below, again. In other words, I support only adding AR:s at the earliest release, not removing data just for the sake of it and living with the inconsistency until we have a proper technical solution. That's fair, and that's what I think is the consensus - though it doesn't solve (editing) problems - as it's not a solution but rather a wait for a later release. Specifically, repeating once again what I stated already in the thread: - for each track that I previously linked to its later releases and that I *then* start documenting ARs for, I have to systematically check all downstream tracks to see what ARs are already here or not, instead of being confident there are no such ARs. - same thing every time I have to change an AR, I'll have to perform that exhaustive checking all over again for all linked tracks This has clearly all the problems (maintenance hell) that I earlier described under Plan A (without any of its - so-called - advantages). Obviously, if people fail to see the problem in this, it's because they hardly ever used these links. This is not a problem! Everybody do edit what he/she wants! And that clearly confirms what I stated previously that the impact on the db is absolutely minimal. So, if you don't do that kind of editing, you'll simply have to take my word for it: this situation is a pain to deal/edit with. If you think the right way to handle this is demise, then well, what can I say? :-) Demise is one thing, denying there is a problem (even if I'm the only poor soul fighting with it) is another. Regards, - Olivier ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
Well, as I see it: both your solutions (remove AR's from later releases; add AR's to later releases) require lots of editing effort, and since there will (some day) be a technical solution to these issues, the concensus seems to be that this effort can be used in more productive ways. Bram Olivier schreef: Here's still something I don't get: the most repeated argument I get is Track Masters will come soon, so your problems will go away, meanwhile you have to wait But when I suggest something that actually ease the situation quite a bit (though it obviously has the drawback you mentioned), I'm getting strict opposition, and suddenly the previous Track Masters will come soon argument seem to not apply to that drawback any longer. Meaning: this is temporary, meant to address a very specific problem, with *very little impact* on the database. What makes it so bad that it's considered worth than the chaos/inconsistent style we currently have? Regards, - Olivier ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
2007/12/2, Philipp Wolfer [EMAIL PROTECTED]: On Dec 2, 2007 10:21 PM, Olivier [EMAIL PROTECTED] wrote: So, if I understand well, everybody votes yes on *me* removing ARs that *I* added earlier before adding (earliest) links, on an artist no one cares about but me? :-) Actually I would vote no. I don't think removing otherwise valid ARs will bring us any further and is a step back. Does that means you support Plan A. If so, can you detail how to address its issues? Regards, - Olivier ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
Personally, I would prefer not to codify any of this. I would prefer to instead spend some time discussing quite which release level ARs do or don't inherit, as well as working to fill in the holes in our current AR system (missing libretto AR for track-artist, missing is the same track as track-track AR, etc). I'd also prefer to spend some time discussing quite what we define as being the same track. To me, the same track being reissued (identical) in another release. What's blury there? The blurry part is just what constitutes an identical reissue. I know I've had several discussions in various places on this, and each person's definition seems to differ. If a track is on a Victrola records, then on an LP, later reissued on a remastered audiophile LP, reissued on 8-track, then reissued on regular cassette and CD, then reissued on a CD remaster and a Cr02 AAD audiophile metal cassette (remember those?), then reissued again on a CD re-remaster, or a SACD release... which are the same, which are different? If a track is released on CD with a master by Foo, and released separately on a different CD with a different master by Bar, are they different? Etc. Some of the lines may be easy, some difficult. My point is, though, I have run into several situations where there is blurryness, and I think it would be good for us to come up with some solid definition of same/not the same before we actually have to need one (ie, before track masters). Otherwise, once we do have track masters, I can see lots of long drawn out debates spread across edit notes as to whether or not two tracks really are the same or not. I'd prefer this, because hopefully soon, we will have track masters in the system. At that point, both A and B become irrelevant, as they as essentially what is solved by track masters. However, at that same point, we will have to have the AR inheritance worked out, so we know what ARs should or should not inherit from releases to tracks to track masters, as well as from tracks to track masters. We also will have to have a definition of just what is the same track so we can know what tracks to merge together to create track masters (where the master has more than just a single instance). Again, I don't see what you find blury in the same track definition: it's straightforward IMHO. Anything that is not the same track (edited, remixed, etc), is not the same track :-) Edited and remixed, yes, those are the easy ones which we differentiate between now anyways. Now remasters, rereleases, LP/tape vs CD/SACD/DVD, etc? :) So, if I understand well, everybody votes yes on *me* removing ARs that *I* added earlier before adding (earliest) links, on an artist no one cares about but me? :-) Actually I would vote no. I don't think removing otherwise valid ARs will bring us any further and is a step back. Does that means you support Plan A. If so, can you detail how to address its issues? No, I don't think it's quite everybody chooses what please him most on the artists he is working on., so I would still vote against removing the ARs. I would instead suggest valid ARs, even if redundant, don't get needlessly removed. So if people want to add at the release level still, and I want to add at the track level, so long as the release level ARs are actually valid for all tracks, I see no reason to remove the release level ARs - they'll go away eventually anyhow. If you want to add ARs at the earliest track, and I am adding them at a later release of that track, again, as long as they are each valid, even if redundant, I see no reason to remove either set - eventually they'll be merged, but for the moment, each pair is still serving a purpose which the database currently doesn't otherwise fulfill. (As ARs don't actually propogate, even if theoretically they do.) There's also a funky reasoning why we would still want the ARs on that later release, until the tracks are capable of getting the ARs from the track master. Given a 10 track release, where, say, 6 tracks were released previously, your option A would set up a situation in which 6 tracks have, for the moment, no ARs, while 4 tracks have all ARs. You then set this release to high DQ because everything is done. Someone else looks at the release and wonders why it is set to high, when over half the tracks have no ARs. Again, this bizarreness goes away once track masters are here and ARs do propogate. But until then, things just have the appearance of being broken. Also, we still have the problem of too many votes expiring through. If we are removing redundant ARs, those remove edits add to the open queue. I would rather work on clearing through edits which add new data, rather than fill the queue with edits removing valid but redundant data - especially given that if we simply ignore such redundancies, in the forseeable future, they'll be able to be cleaned away much more easily through merging those
Re: [mb-style] Re: AR implicit/explicit propagation: to
On Dec 3, 2007 10:50 AM, Olivier [EMAIL PROTECTED] wrote: Does that means you support Plan A. If so, can you detail how to address its issues? I would curently prefer to treat every release separately and keep the ARs redundant. For the future I see two possible solutions for the redundancy problems: 1. Track masters: As soon as the same track is really the same entity on different releases there is no need anymore to worry about the redundancy as all ARs have to be added only once.* 2. Some automatic AR propagation as described on http://bugs.musicbrainz.org/ticket/3029 Both solutions will keep the ARs available for every release and not only for the earliest release as it would be the case with Plan B. As long as we don't have the technical solutions I see no problem in keeping the ARs redundant. And I especially see no use in removing valid ARs! * If this get's implemented same ARs on previously different tracks will be merged. I think that's what Brian Schweitzer meant with go away eventually -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
2007/12/3, Philipp Wolfer [EMAIL PROTECTED]: On Dec 3, 2007 10:50 AM, Olivier [EMAIL PROTECTED] wrote: Does that means you support Plan A. If so, can you detail how to address its issues? I would curently prefer to treat every release separately and keep the ARs redundant. For the future I see two possible solutions for the redundancy problems: 1. Track masters: As soon as the same track is really the same entity on different releases there is no need anymore to worry about the redundancy as all ARs have to be added only once.* 2. Some automatic AR propagation as described on http://bugs.musicbrainz.org/ticket/3029 Both solutions will keep the ARs available for every release and not only for the earliest release as it would be the case with Plan B. As long as we don't have the technical solutions I see no problem in keeping the ARs redundant. And I especially see no use in removing valid ARs! * If this get's implemented same ARs on previously different tracks will be merged. I think that's what Brian Schweitzer meant with go away eventually -- Philipp Wolfer I think this discussion to some extent drifted from its original topic, or that I haven't formulated my question as I should have. Say I'm onto working on a specific artist *exhaustively* (as much as I can), planning to move everything I can to HighQuality, and setting every needed data, MB-style. What am I supposed to do? Am I supposed to: - (old plan A) manually propagate all ARs I set on the earliest to their children I think no one in the thread suggested that - and as I pointed out, this IMHO is absolutely impracticable - (old plan B) remove (eventually incomplete) in-children ARs when I link to an earlier that has all the proper credits - the third way: if I understood well it means essentially I can't set HQ and I have to leave what's in place - some children with complete ARs, some others with partial/incomplete ARs, and some without So that third way means I'm left with a half-done job, half-backed releases, no data consistency - which will probably disastisfy everybody (specially me :-)). Arguments about the future and how track masters will get in definitely are interesting, but we still have *present* issues to sort out, including the fact both practices (A B) are currently done in the database - which I really think is bad, and which means: you have one chance out of two of being voted yes/no depending on who votes on your edits. So... What should I do in the case I described? And why would the third way be better when it seems to combine the defects of both A B without having any merit (or did I missed them?) Regards - Olivier ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
On Dec 3, 2007 4:20 PM, Chris B [EMAIL PROTECTED] wrote: with http://bugs.musicbrainz.org/ticket/3029 my intent was to *display* the ARs along the 'chain' of 'same track/release' type items, not propagate. the reason for this is that if you change an AR at one level, it should impact all instances of itself, and in my eyes the simplest way to to do this would be to only store the AR at the 'parent' object, and then just display it at all 'daughter' objects, depending on the AR 'same track' type used (eg, 'remaster' AR does not display the masterer AR for the parent object, as that is no longer relevent). I didn't mean they need to be copied along the chain. It's enough to have them available for all child objects. -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
On Dec 3, 2007 4:19 PM, Olivier [EMAIL PROTECTED] wrote: So that third way means I'm left with a half-done job, half-backed releases, no data consistency - which will probably disastisfy everybody (specially me :-)). Why no data consistency? I don't understand how identical ARs on two identical tracks can be inconsistent. I understand that plan A is really impractical. We should instead aim for getting the ARs for the original releases correct. It's surely Ok to just remove wrong ARs from later releases. But I still don't see the reason for removing correct ARs. If I spent some time adding all ARs to a later release I surely don't want them removed. My suggestions are: * Normally we can just ese plan B when adding ARs * Don't touch existing (correct) ARs * Don't dissallow adding ARs to later releases as that's currently the only way to make them available to those releases Regards, Philipp ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
2007/12/3, Philipp Wolfer [EMAIL PROTECTED]: On Dec 3, 2007 4:19 PM, Olivier [EMAIL PROTECTED] wrote: So that third way means I'm left with a half-done job, half-backed releases, no data consistency - which will probably disastisfy everybody (specially me :-)). Why no data consistency? I don't understand how identical ARs on two identical tracks can be inconsistent. I'll try to formulate clearer: - track A is performed by Doe (set) - track A is composed by Doe (set) Case 1: - track A is the earliest release of track B1 - no AR set on track B1 = no data on B1 Case 2: - track A is the earliest release of track B2 - track B2 is performed by Doe = partial data on B2 Case 3: - track A is the earliest release of track B3 - track B3 is performed by Doe - track B3 is composed by Doe (set) = all data on B3 We have three later releases of track A, but inconsistent data. What to do? I understand that plan A is really impractical. We should instead aim for getting the ARs for the original releases correct. It's surely Ok to just remove wrong ARs from later releases. Sure. But I still don't see the reason for removing correct ARs. Having consistent data accross a subset of the database (see the examples above). If I spent some time adding all ARs to a later release I surely don't want them removed. Well... I can understand that certainly, work has to be respected, but really the fact some work has been done in one way on something doesn't mean we can't have our practice/dataset evolve. And again, I'm obviously speaking about a border case, concerning a handful of editors, for a very small subset of the database. My suggestions are: * Normally we can just ese plan B when adding ARs Agreed. * Don't touch existing (correct) ARs Mmmm, what if I added the AR myself, and now regret I did (in regard of your previous point)? Does it give me the right to remove it? :-) - Olivier ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
On Dec 3, 2007 9:26 PM, Olivier [EMAIL PROTECTED] wrote: We have three later releases of track A, but inconsistent data. What to do? Ok, I see what you mean. The individual ARs are consistent, but not the whole set of ARs. But I still don't see the reason for removing correct ARs. Having consistent data accross a subset of the database (see the examples above). My main objection against your plan B is the fact that it makes the information only available to the first release. This is surely a limitation of the current system and will be solved in the future. But at the moment their is no practical way to use the ARs for later releases (e.g. in file tags). If this gets solved I'm all in favor of plan B. Until then I consider MB to be more usefull with redundant ARs (which might be incomplete for some releases, but they are incomplete for other releases as well). If I spent some time adding all ARs to a later release I surely don't want them removed. Well... I can understand that certainly, work has to be respected, but really the fact some work has been done in one way on something doesn't mean we can't have our practice/dataset evolve. And again, I'm obviously speaking about a border case, concerning a handful of editors, for a very small subset of the database. This surely is not a border case. There are many releases that are affected by this problem. And there are surely enough editors who want to have the ARs as complete as possible. * Don't touch existing (correct) ARs Mmmm, what if I added the AR myself, and now regret I did (in regard of your previous point)? Does it give me the right to remove it? :-) I think at least nobody would be offended :) And I guess it would depend on the people interested in that particular artist. -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
2007/12/3, Philipp Wolfer [EMAIL PROTECTED]: On Dec 3, 2007 9:26 PM, Olivier [EMAIL PROTECTED] wrote: We have three later releases of track A, but inconsistent data. What to do? Ok, I see what you mean. The individual ARs are consistent, but not the whole set of ARs. But I still don't see the reason for removing correct ARs. Having consistent data accross a subset of the database (see the examples above). My main objection against your plan B is the fact that it makes the information only available to the first release. This is surely a limitation of the current system and will be solved in the future. But at the moment their is no practical way to use the ARs for later releases (e.g. in file tags). Maybe luks may provide some light whether it's possible or not to script-funk-PicardQT so it does that. BF told me it was not easy, but well, who knows? If this gets solved I'm all in favor of plan B. Until then I consider MB to be more usefull with redundant ARs (which might be incomplete for some releases, but they are incomplete for other releases as well). If I spent some time adding all ARs to a later release I surely don't want them removed. Well... I can understand that certainly, work has to be respected, but really the fact some work has been done in one way on something doesn't mean we can't have our practice/dataset evolve. And again, I'm obviously speaking about a border case, concerning a handful of editors, for a very small subset of the database. This surely is not a border case. There are many releases that are affected by this problem. And there are surely enough editors who want to have the ARs as complete as possible. Ya, but how many editors go through the *very boring* task of tracking down first release/first version? I mean, not on a seasoned basis, for a very specific release once in a while, but on a daily basis? I've seen such edits *very very rarely* in my subscriptions (which I confess do not cover the whole db, neither the most active part of it, but still) - I think I seen it once from Jugdish on a Parker release, and once or maybe twice from drsaunde. * Don't touch existing (correct) ARs Mmmm, what if I added the AR myself, and now regret I did (in regard of your previous point)? Does it give me the right to remove it? :-) I think at least nobody would be offended :) And I guess it would depend on the people interested in that particular artist. Here! There! Read! BF mate, your abusive voting won't pass! :D I'm gonna redo these edits ASAP :D /was just teasing Thanks for the opinions on this, guys and gals - I guess we have beaten the subject to death, and I had to cancel the edits anyway. I'm not really satisfied by the outcome of this (as I feel my concerns about what I called consistency are not addressed), but hé, that's how things are... Regards to you all, - Olivier ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
On Dec 3, 2007 10:16 PM, Olivier [EMAIL PROTECTED] wrote: Here! There! Read! BF mate, your abusive voting won't pass! :D I'm gonna redo these edits ASAP :D /was just teasing For those who were not aware of the parallel discussion in the edit notes (like me) here the pointer to the edit: http://musicbrainz.org/show/edit/?editid=7852635 Regards Phil ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
2007/12/1, Brian Schweitzer [EMAIL PROTECTED]: While recognizing the points in A and in B, I think both miss a few points... In either A or B, you also assume someone is setting all the possible ARs. While some of us are really this obsessive (and I admit to being one such), most ARs I see only have a few done. So the same track on six releases might have 3 with no ARs, one with a producer AR, one with some performer ARs, and one with some more (and partially overlapping) performer and mixer ARs. I'm obviously speaking about the obsessive-d artists, on which a given editor works out all ARs and tidy everything. B also assumes that any given track has the earliest release of AR created to point it back to the earlier track. We also know this isn't really the case for 99.% (perhaps higher) of the database. Again, I'm clearly speaking about the 0.0001% (your estimate) where every track of the artist is tracked down to its earliest point/version. A has the negative of error-creep. It also has the advantage of multiple eyes on multiple places. Fair enough. Either way, I'm not going to ask casual editors to actually spend five months studying an artist discography before adding what they think fits The earliest release's liner may give very few credits, while later releases include more info Yes, definitely. And such info gets attached to the earliest release of the track. - this I find to often be the case with, for example, classical and soundtracks (the latter especially), where the initial release gives no performer info, while later releases, positively identified as being the exact same release, give at least some credits as to performers, rather than just basic composer info. So, even if the info isn't fully present, between different releases of the exact same track, we may gain better info on that track. E... I'm definitely *not* saying use only the info from the earliest physical release, but use every info you got, and add it to the earliest entry in the db B has negatives too. First, it does assume that the earliest track AR is pointed to. Again, I'm speaking only about these cases. Second, as hinted at in Frederic's note, it assumes we really do have the earliest release that all the ARs are being applied to. If a new earliest release is later found, a strict interpretation of B would mean our then removing a bunch of perfectly good ARs, only to reapply them to the (now) earliest track instance. Yes, in this case, a number of ARs need to be changed. Which is outweighted by the number of ARs that needs to be changed in plan A for *any credit change*. Personally, I would prefer not to codify any of this. I would prefer to instead spend some time discussing quite which release level ARs do or don't inherit, as well as working to fill in the holes in our current AR system (missing libretto AR for track-artist, missing is the same track as track-track AR, etc). I'd also prefer to spend some time discussing quite what we define as being the same track. To me, the same track being reissued (identical) in another release. What's blury there? I'd prefer this, because hopefully soon, we will have track masters in the system. At that point, both A and B become irrelevant, as they as essentially what is solved by track masters. However, at that same point, we will have to have the AR inheritance worked out, so we know what ARs should or should not inherit from releases to tracks to track masters, as well as from tracks to track masters. We also will have to have a definition of just what is the same track so we can know what tracks to merge together to create track masters (where the master has more than just a single instance). Again, I don't see what you find blury in the same track definition: it's straightforward IMHO. Anything that is not the same track (edited, remixed, etc), is not the same track :-) At this later track master point, the only part of A or B I see which will really have potential to cause headaches is where track 1 has an AR for one person, and track 2 has the same AR for a different person. But this too we can handle - it may be that both are correct, and each track only was half attributed, or it may be that one track had an incorrect AR. But I see this as a positive benefit of approach A - redundant info later being cross-checked to later find potential errors in the redundancy. So, if you're suggesting no rule/resolution, and wait for track masters, you're suggesting that (in the interim) everybody chooses what please him most on the artists he is working on. I guess that means now you are gonna change that no vote on my edits, right? :D Cheers. - Olivier ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
On Dec 1, 2007 11:57 PM, Brian Schweitzer [EMAIL PROTECTED] wrote: Personally, I would prefer not to codify any of this. I would prefer to instead spend some time discussing quite which release level ARs do or don't inherit, as well as working to fill in the holes in our current AR system (missing libretto AR for track-artist, missing is the same track as track-track AR, etc). I'd also prefer to spend some time discussing quite what we define as being the same track. That's what I would prefer as well. I'm strictly against removing existing AR from a later release just because they are redundant, as the ARs on the earliest release are not yet easily available to the later releases. And I like to have the ARs in my file tags and the only option currently is to add redundant ARs. As soon as we get track masters this problem will be solved and the ARs of different tracks can be easily merged. If somebody decides not to add ARs because they are already present in the eraliest release that's ok for me. But I would neither disallow nor remove ARs from later releases. -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
2007/12/2, Philipp Wolfer [EMAIL PROTECTED]: On Dec 1, 2007 11:57 PM, Brian Schweitzer [EMAIL PROTECTED] wrote: Personally, I would prefer not to codify any of this. I would prefer to instead spend some time discussing quite which release level ARs do or don't inherit, as well as working to fill in the holes in our current AR system (missing libretto AR for track-artist, missing is the same track as track-track AR, etc). I'd also prefer to spend some time discussing quite what we define as being the same track. That's what I would prefer as well. I'm strictly against removing existing AR from a later release just because they are redundant, as the ARs on the earliest release are not yet easily available to the later releases. And I like to have the ARs in my file tags and the only option currently is to add redundant ARs. As soon as we get track masters this problem will be solved and the ARs of different tracks can be easily merged. If somebody decides not to add ARs because they are already present in the eraliest release that's ok for me. But I would neither disallow nor remove ARs from later releases. So, if I understand well, everybody votes yes on *me* removing ARs that *I* added earlier before adding (earliest) links, on an artist no one cares about but me? :-) - Olivier ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
On Dec 2, 2007 10:21 PM, Olivier [EMAIL PROTECTED] wrote: So, if I understand well, everybody votes yes on *me* removing ARs that *I* added earlier before adding (earliest) links, on an artist no one cares about but me? :-) Actually I would vote no. I don't think removing otherwise valid ARs will bring us any further and is a step back. -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to
While recognizing the points in A and in B, I think both miss a few points... In either A or B, you also assume someone is setting all the possible ARs. While some of us are really this obsessive (and I admit to being one such), most ARs I see only have a few done. So the same track on six releases might have 3 with no ARs, one with a producer AR, one with some performer ARs, and one with some more (and partially overlapping) performer and mixer ARs. B also assumes that any given track has the earliest release of AR created to point it back to the earlier track. We also know this isn't really the case for 99.% (perhaps higher) of the database. A has the negative of error-creep. It also has the advantage of multiple eyes on multiple places. The earliest release's liner may give very few credits, while later releases include more info - this I find to often be the case with, for example, classical and soundtracks (the latter especially), where the initial release gives no performer info, while later releases, positively identified as being the exact same release, give at least some credits as to performers, rather than just basic composer info. So, even if the info isn't fully present, between different releases of the exact same track, we may gain better info on that track. B has negatives too. First, it does assume that the earliest track AR is pointed to. Second, as hinted at in Frederic's note, it assumes we really do have the earliest release that all the ARs are being applied to. If a new earliest release is later found, a strict interpretation of B would mean our then removing a bunch of perfectly good ARs, only to reapply them to the (now) earliest track instance. Personally, I would prefer not to codify any of this. I would prefer to instead spend some time discussing quite which release level ARs do or don't inherit, as well as working to fill in the holes in our current AR system (missing libretto AR for track-artist, missing is the same track as track-track AR, etc). I'd also prefer to spend some time discussing quite what we define as being the same track. I'd prefer this, because hopefully soon, we will have track masters in the system. At that point, both A and B become irrelevant, as they as essentially what is solved by track masters. However, at that same point, we will have to have the AR inheritance worked out, so we know what ARs should or should not inherit from releases to tracks to track masters, as well as from tracks to track masters. We also will have to have a definition of just what is the same track so we can know what tracks to merge together to create track masters (where the master has more than just a single instance). At this later track master point, the only part of A or B I see which will really have potential to cause headaches is where track 1 has an AR for one person, and track 2 has the same AR for a different person. But this too we can handle - it may be that both are correct, and each track only was half attributed, or it may be that one track had an incorrect AR. But I see this as a positive benefit of approach A - redundant info later being cross-checked to later find potential errors in the redundancy. Brian ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: AR implicit/explicit propagation: to remove or to add along same lines
2007/11/30, Olivier [EMAIL PROTECTED]: Ya well, I sure prefer Plan B but obviously it will somewhat alter the track/release ARs view of the artists... Plan B goes in the right direction for the next step. If this is implemented, we must think of what to do - if a new earliest something AR is added (seems pretty obvious, just move the ARs from the previous earliest to the new one) - or if such an AR is removed (this is more tricky, should the composer/performer ARs be copied to each release? If there is one ancestor in the earliest hierarchy, no problem, but if the structure is not so simple, we may end up adding ARs to releases which should not have them). -- Frederic Da Vitoria ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
