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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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:
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
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
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
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
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
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
Ya well, I sure prefer Plan B but obviously it will somewhat alter the
track/release ARs view of the artists...
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
29 matches
Mail list logo
