[mb-users] Guess I'll boycott adding release events

[Frederic Da Vitoria]

On Wed, Jul 30, 2008 at 8:04 PM, Frederik 'Freso' S. Olesen
<freso.dk at gmail.com> wrote:
> Frederic Da Vitoria skrev:
>>
>> On Wed, Jul 30, 2008 at 6:04 PM, Frederik 'Freso' S. Olesen
>> <freso.dk at gmail.com> wrote:
>>>
>>> Frederic Da Vitoria skrev:
>>>>
>>>> [...], or we need ways to assess the reliability of each piece of
>>>> information.
>>>
>>> Isn't this done by reviewing the edits related to that piece of
>>> information.
>>
>> What is there to review about a release date? AFAIK, the comments
>> entered by the editor when he entered the new release event are lost.
>
> Where/when are are the comments lost? AFAICT, the comments I entered during
> my last release event addition are still to be found:
> http://musicbrainz.org/mod/search/results.html?object_type=album&orderby=desc&object_id=665858

Almost unusable. start as a normal user would do from the Release
http://musicbrainz.org/show/release/?releaseid=665858 and try to find
your annotation. Or let's try with this one: are there sources for
http://musicbrainz.org/show/release/?releaseid=77593 ?


>>>> If we want to really be reliable, we'll have to include a way of citing
>>>> sources, something more reliable :-) than annotations.
>>>
>>> It is generally recommended to cite your sources when entering the edits.
>>> This goes (or should go) for annotations as well.
>>
>> Annotations are only a fallback solution. Correct DB implementation
>> implies that each identified piece of information has it's own place.
>> General purpose annotations don't do it.
>
> Eh. You're criticising the lack of ability to cite your source(s) when
> entering data into annotations. I tell you where to do just this; citing
> source(s) when entering data into annotation. And then you tell me that
>  entering data into annotations is a fall-back? That wasn't what we were
> talking about. Or I wasn't anyway, and apparently misread your initial
> comment... ?

Sorry, there's annotation and annotation. So I believe using the
Release annotations is a fallback solution. And the edit annotations
are very difficult to find. Furthermore, if I want to add another
source to an existing release event, how can I?


>>>> If I added all the information I found when I happened to do some
>>>> research
>>>> for release dates (for example), the annotations would become
>>>> unreadable.
>>>
>>> Then add the data to the annotation edit as an edit note. And while
>>> you're
>>> at it, please fill in the "description of your changes" so that people
>>> looking at a long list of annotation edits can get an overview of what
>>> has
>>> happened at a glance, instead of going to review the diff of each
>>> individual
>>> change.
>>
>> Imagine what the annotation would like for a Release complete with a
>> few release events and various performers? This is not a database, it
>> is a wiki disguised as a database. I am not saying the MB database is
>> all wrong, I know it's current status comes partially from it's
>> history and partially from lack of developers, I am only saying that
>> the idea of putting this kind of info in a general-purpose field can
>> only be a temporary way to get around a problem and should absolutely
>> not be considered as a solution.
>
> "putting this kind of info in a general-purpose field" - what kind of info?
> I'm talking about citing sources when you're falling back on the "last
> resort" of entering data into annotations. I'm not talking about the info
> actually going into the annotation. This is meta meta information we're
> discussing, not the meta information itself.

I suppose you now understand what I meant :-)


>>>> Each piece of information should be accompanied with it's sources so
>>>> that
>>>> any user could check how reliable the information is. This is more or
>>>> less
>>>> what happens for track listings: by looking at Disc IDs, one can check
>>>> the
>>>> timings, if there are 2 or 3 Disc IDs, one can even detect homebrews...
>>>
>>> [...] DiscIDs aren't a source in themselves, but a piece of
>>> information from the source of the originating CD. This CD is the source
>>> for
>>> the track times, and the DiscID addition edit should preferably have a
>>> note
>>> saying where the CD is from, to verify that it's not a homebrew. This is
>>> not
>>> feasible though, but a DiscID in itself isn't a proper source, [...]
>>
>> Oh come on, we both know this was only an analogy and should only be
>> used as an illustration of my meaning.
>
> I didn't catch the analogy, so I'm not sure who your "we" are. But seeing
> the analogy now, I can only repeat that all pieces of information added to
> the MB db have a corresponding edit to which one is free to add edit notes
> which could easily be citing sources.

How (after the release event has been added)?


>> What I was trying to illustrate is that consistent informations can
>> often be an indication of reliability. If you have 4 DiscIDs with same
>> durations and one with shifted durations, the last one is a suspsect.
>> In the same way, adding more than one source for a piece of info
>> increases the chances that that info is correct.
>
> But a DiscID is not "one source for a piece of info". A DiscID is "a piece
> of info". You're saying that "Each piece of information should be
> accompanied with it's sources" – I'm (or was) pointing out that DiscIDs
> themselves are one of those "[pieces] of information".
>
>>>> But the current database design doesn't allow for this for subjects such
>>>> as release dates or labels.
>>>
>>> Sure does: edit notes.
>>
>> As long as someone can see them.
>
> They're saved perpetually, for all users to (re)view as they please.

As I see it, "they're saved perpetually, for all users smart and
perseverent to (re)view" The info is there, granted, but it is not
easily available and AFAIK not editable. This is not a source handling
mechanism, it is a edit history management system.

-- 
Frederic Da Vitoria