[mb-style] RFC3: Add a few more release formats

[Brian Schweitzer]

Ok, trying this one again.  :)

I think we all agree that some sort of advanced release-type tree (with
attribute support, so that things like the size of the vinyl and the color
of the wax can be represented) is something we want in the post-NGS future.
However, that's a separate, UI, issue from our supporting/not supporting
valid media types which have known releases, and which are unique (ie, not
subtypes of existing formats).

Hence, I'm re-proposing this, and combining in the UMD proposal (RFC-108).
Hopefully, with the issue of UI separated as outside of what we can request
in a near-future proposal, there'll be no objections this time.  :)

This would add the following as media types:


> * VHS (RFC-75) - http://bugs.musicbrainz.org/ticket/5605
 * VCD (RFC-76) - http://bugs.musicbrainz.org/ticket/4615
 * SVCD (RFC-77) - http://bugs.musicbrainz.org/ticket/4615
 * Betamax - (raised in the thread below)
 * HDCD (RFC-81) - http://bugs.musicbrainz.org/ticket/3942
 * USB flash drive (raised on Release_Formats as potentially "other"
 baring the format's addition)
 * slotMusic (raised on Release_Formats as potentially "other" baring the
 format's addition)

>>> * UMD (Universal Media Disc)

Without objection (this time around), this proposal will go to RFV status on
2010-03-22.

Thanks,
Brian
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[mb-style] Facebook & microblog/Twitter ARs

[Brian Schweitzer]

Andrew,

Since it's been 3 months or so now, can you give us any update on the
current status of RFC-88: Add microblog/Twitter AR and RFC-89: Add Facebook
AR?  Any idea when a proposal for either might be coming?  :)

Brian

On Thu, Dec 10, 2009 at 9:32 AM, Andrew John Hughes <
gnu_and...@member.fsf.org> wrote:

> 2009/12/10 Brian Schweitzer :
> > For those who don't follow the style list, the following RFCs are in need
> of
> > a champion to take them on, clean them up, and get something done with
> the
> > proposal.  Anyone here willing?  :)
> >
> > Capitalization Standard Turkish
> > Hello! Project style
> > Medley Style
> > Release Event Style and Release Country Style
> > Audiobook styleguide
> > Facebook (and Twitter) URL ARs
> >
> > Brian
> >
> > ___
> > MusicBrainz-users mailing list
> > musicbrainz-us...@lists.musicbrainz.org
> > http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
> >
>
> I'm happy to do the FB/Twitter one.  I've certainly run into cases
> where I've been missing the existence of such a relationship.
>
> Do we actually want these specific versions or shall we go for
> something more general like 'has social networking profile' and 'has
> microblog' (as we discussed a little before)?
> --
> Andrew :-)
>
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
>
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
>
> ___
> MusicBrainz-users mailing list
> musicbrainz-us...@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Release Title

[Brian Schweitzer]

On Sun, Mar 7, 2010 at 2:00 PM, caller#6 <
meatbyproduct-musicbra...@yahoo.com> wrote:

> Brian Schweitzer wrote:
> > Page: http://wiki.musicbrainz.org/Release_Title
> > RFC: RFC-47
> >
> > This RFC is an attempt to clear out a proposal that's essentially
> > official in all but name, and has been for a long while.
> >
> > ReleaseTitle was start by zout in 2005.  In October of 2007, zout
> > first attempted an RFC on it (
> >
> http://lists.musicbrainz.org/pipermail/musicbrainz-style/2007-October/005255.html
> > ), but, like so many proposals of that time, there was some
> > discussion, then the RFC just kind of went nowhere.
> >
> > Without objection, this RFC will move to RFV status on 2010-03-13.
> >
>
> The first thing that jumps out at me is: it seems like there should be
> some mention of the ETI page (
> http://wiki.musicbrainz.org/Extra_Title_Information_Style ).
>
>
> best,
> Alex / caller#6
>
>
I've added ETI to the page.  Does anyone see any other blockers that would
prevent making this page official?

Quick Style Leader note: I'm only championing this particular proposal
because someone had to; if you see anything that should be fixed before this
is made official, please feel free to go ahead and make the fix.  Don't feel
as though you need to get me to do it, simply because I'm the Idea Champion
of record for this particular proposal.  :)

Brian
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[mb-style] A proposal has passed! (was RFV: Add attribute 'translated' to Librettist Relationship Type)

[Brian Schweitzer]

No veto having been heard, and the RFV period having expired, this proposal
has now passed.

Thanks everyone,

Brian

On Sat, Mar 13, 2010 at 6:57 PM, Brian Schweitzer <
brian.brianschweit...@gmail.com> wrote:

> No objections having been heard, and the RFC period having expired, this
> proposal is now in RFV.  Without veto, it will pass on 2010-03-15.
>
> Thanks,
> Brian
>
> On Sat, Mar 6, 2010 at 2:58 AM, Brian Schweitzer <
> brian.brianschweit...@gmail.com> wrote:
>
>> This is essentially a clone of RFC-70, to maintain the same options
>> between the two similar ARs.  RFC-70 adds the translated attribute to the
>> Lyricist Relationship Type; this would also add the same attribute to the
>> Librettist Relationship Type.
>>
>> The proposal page is:
>> http://wiki.musicbrainz.org/User:BrianSchweitzer/Librettist_Relationship_Type
>>
>> The attribute page for the translated attribute is at:
>> http://wiki.musicbrainz.org/Translated_Relationship_Attribute
>> This is the same description/page as that for the Lyricist Relationship
>> Type attribute proposal.
>>
>> This is RFC-102; without objection, it will move to RFV on 2010-03-13.
>>
>> Thanks,
>>
>> Brian
>>
>
>
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[mb-style] RFC2: Add "Has News Coverage At" AR

[Brian Schweitzer]

Ok, I've refined the proposed AR's page, so lets give this another shot.
The AR is now much more restrictive, both in what can be linked to, and in
how many links the same story can have.

The new URL for the proposed AR is
http://wiki.musicbrainz.org/News_Coverage_Relationship_Type

(Note that the URL has slightly changed since the original RFC.)



In addition, though this should not be considered a blocker for implementing
the AR, should this proposal pass, it is requested that dev time eventually
(near-future post-NGS, if not possible for the NGS release) be aimed towards
the following:

* Rather than using the link text "{{entity}} has news coverage at
http://www.foo.com/somestory.html";, the description field should be used for
the link text.

* The description field is a mandatory attribute for this AR, and thus, no
edit to add an AR of this type should be allowed by the server if the
description field does not match a "-00-00: (text)" pattern.

* When presenting this AR on pages displaying ARs, the description fields
should be sorted, so that date order is maintained, and each AR of this type
should appear on a new line, such that the resulting display is:

News coverage for Foo: 2000-10-03: A new band emerges!
   2005-02-11: Foo's latest release is a hit

   2007-09-05: Foo's 'All the Best Songs' goes platinum
   2010-02-24: It's official, Foo is breaking up!

(which would, of course, when such a view is implemented, mean ignoring the
link text for the {{non-URL entity}}-{{URL}} display).



Are all these changes enough to make the AR both seem useful and
non-problematic?  :)

This remains RFC-68.  Without continued objection/debate, this new RFC will
move to RFV status on 2010-03-22.

Thanks!
Brian

On Mon, Mar 15, 2010 at 5:24 PM, Brian Schweitzer <
brian.brianschweit...@gmail.com> wrote:

> *Style Leader hat on*
>
> An update on the Champion for this proposal:  I've talked to ruaok.  He's
> rather limited in what time he can devote to the lists (hence why he'd asked
> me to propose this for him).  This is an AR he'd like to see happen, but
> he's busy enough that actively working the proposal isn't likely to happen.
> So he's asked me to champion it for him.
>
> *Style Leader hat off*
>
> This isn't a huge change, but it skips the delay of my passing any changes
> to the AR or proposal through ruoak, so long as the core of AR remains.  So,
> let me reiterate my comments and suggestions from earlier today, in my new
> position as champion for this proposal.  I've also spent part of today
> looking at what Wikipedia had to say about this type of link, given that
> they have frequently have news links as references.
>
> The only further changes or additions I'd make at the moment would be these
> (I'll wait on some comments, if there are any, before I revise the wiki
> proposal):
> * to specify that not 'any site on the net that can be considered a "news"
> site' should be linkable, but rather, that 'any site on the net that can be
> considered a "news" site which is considered reputable'
> * somehow, specify that we want "real" news articles, not tiny blurbs -
> perhaps a requirement that the article have a headline, and that the artist
> be a primary focus of the article, would suffice?
> * specify that the original source, or as close as possible, should be
> linked for any article.  So an article from a Washington Post reporter would
> be fine to link to at the Washington Post, but an AP report should link to
> it at the AP, not at some tiny paper which reprinted the AP story.
>
> Brian
>
>
> On Mon, Mar 15, 2010 at 12:42 PM, Brian Schweitzer <
> brian.brianschweit...@gmail.com> wrote:
>
>> Trying to get this proposal back on track... :)
>>
>> On Sun, Mar 7, 2010 at 7:34 AM, Chad Wilson  wrote:
>>
>>>  On 7/03/2010 2:56 p.m., Brian Schweitzer wrote:
>>>
>>>  I think the fear is there'd be tons of URLs linked, but without any
 context, those URLs don't give much, other than that you know there's some
 news article about the artist on the other end.

 However, if the AR description field could be displayed next to each URL
 AR for that type, that field would seem to work perfectly to address some 
 of
 this concern and describe just what news article was on the other end of
 each such URL AR.

 Dev impact: It wouldn't really make sense to implement this type of
 description display on the current server code, but this would seem to
 entail only some minor additional template handling (specific to this AR
 type?) for the AR display page template on the NGS server.  Plus, if it 
 were
 added, esp universally, that so-far useless AR description field would
 actually now have some useful purpose.  :)

 Brian

>>>
>>> Chad, would this address your concerns?  As I understand the propos

Re: [mb-style] RFC: Add "Has News Coverage At" AR

[Brian Schweitzer]

*Style Leader hat on*

An update on the Champion for this proposal:  I've talked to ruaok.  He's
rather limited in what time he can devote to the lists (hence why he'd asked
me to propose this for him).  This is an AR he'd like to see happen, but
he's busy enough that actively working the proposal isn't likely to happen.
So he's asked me to champion it for him.

*Style Leader hat off*

This isn't a huge change, but it skips the delay of my passing any changes
to the AR or proposal through ruoak, so long as the core of AR remains.  So,
let me reiterate my comments and suggestions from earlier today, in my new
position as champion for this proposal.  I've also spent part of today
looking at what Wikipedia had to say about this type of link, given that
they have frequently have news links as references.

The only further changes or additions I'd make at the moment would be these
(I'll wait on some comments, if there are any, before I revise the wiki
proposal):
* to specify that not 'any site on the net that can be considered a "news"
site' should be linkable, but rather, that 'any site on the net that can be
considered a "news" site which is considered reputable'
* somehow, specify that we want "real" news articles, not tiny blurbs -
perhaps a requirement that the article have a headline, and that the artist
be a primary focus of the article, would suffice?
* specify that the original source, or as close as possible, should be
linked for any article.  So an article from a Washington Post reporter would
be fine to link to at the Washington Post, but an AP report should link to
it at the AP, not at some tiny paper which reprinted the AP story.

Brian

On Mon, Mar 15, 2010 at 12:42 PM, Brian Schweitzer <
brian.brianschweit...@gmail.com> wrote:

> Trying to get this proposal back on track... :)
>
> On Sun, Mar 7, 2010 at 7:34 AM, Chad Wilson  wrote:
>
>>  On 7/03/2010 2:56 p.m., Brian Schweitzer wrote:
>>
>>  I think the fear is there'd be tons of URLs linked, but without any
>>> context, those URLs don't give much, other than that you know there's some
>>> news article about the artist on the other end.
>>>
>>> However, if the AR description field could be displayed next to each URL
>>> AR for that type, that field would seem to work perfectly to address some of
>>> this concern and describe just what news article was on the other end of
>>> each such URL AR.
>>>
>>> Dev impact: It wouldn't really make sense to implement this type of
>>> description display on the current server code, but this would seem to
>>> entail only some minor additional template handling (specific to this AR
>>> type?) for the AR display page template on the NGS server.  Plus, if it were
>>> added, esp universally, that so-far useless AR description field would
>>> actually now have some useful purpose.  :)
>>>
>>> Brian
>>>
>>
>> Chad, would this address your concerns?  As I understand the proposal, "If
>> it's the former, I think the proposal/guidelines should specifically say "Do
>> not link to individual articles about an artist/release", or something
>> similar." would specifically be counter to the proposal; the intent is that
>> individual articles *should* be linked using this proposed AR.
>>
>>
>> Not really, no. :( Even if we mandated use of the description field, I'm
>> not convinced it would be actively used despite guidelines, and we have far
>> too many AR edits currently for there to be special attention to these ones.
>> It's also not really "structured" - I'll come back to that later.
>>
>
> While this is true, I think we could mandate a structure, and a report
> (akin to the ASIN one) could detect those ARs which have either a missing,
> or incorrectly formatted, description.  It'd be almost as easy for someone
> to edit in a description after the fact as it would be for the original
> editor to include it.
>
>
>> I mainly think manual adding and maintenance of the kinds of volumes of
>> links that are available for news on any given artist - for it to give a
>> useful or complete picture - is far too great to manage, and better served
>> by a search engine, or tagging+mashup style approach, rather than hard AR
>> links. Add to that how quickly news article links come and go in their
>> validity on many websites, and I'm just not convinced that the data would
>> have much value in the years to come?
>>
>> Most of our links currently are for general concepts, or landing pages for
>> an artist where there many only be say 1, 5, 10 or maybe even 50 such links
>> for an artist added. When you're talking news articles, there are thousands
>> that /could/ be linked. With non-standard or potentially unreliable URLs.
>> Many might be recycled/syndicated content with some extra guff added. The
>> ARs wouldn't have any structured metadata, so automatic processing of
>> content would be difficult.
>>
>
> While you're right, most ARs are of this sort, we do have not one, but four
> existing ARs which all can easily suffer the same 

[mb-style] Discography Relationship Type - clarification on a guideline that seems out of date

[Brian Schweitzer]

Discography Relationship Type includes this style detail:

"This is intended for "free form" web pages, not for big online databases
like MusicBrainz . There is a
separate 
OtherDatabasesRelationshipClassof
relationship types used for linking
MusicBrainz  artists to their
corresponding entries in other online databases. Some online databases, such
as AllMusic.com, discourage systematic linking; please don't add links to
this type of page. Also, links to Amazon are handled by a separate system (
AmazonRelationshipType),
so links to that website are inappropriate here."

With the current move to attempt to generalize relationships away from
adding a new AR for each and every website, is this still true?
OtherDatabasesRelationshipClasswould
now map to External Website Information Class, which is the class for
specific websites' ARs.  While yes, we want the specific AR used for any
site that has one (BBC Music, Discogs, MusicMoz, MySpace, Wikipedia,
YouTube), is there a reason why this AR cannot/should not be used for "big
online databases" like the relevant ones listed in
http://wiki.musicbrainz.org/Category_talk:External_Website_Relationship_Classif
there is not a website-specific AR already in place for a site?

Brian
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Part of series relationship

[Brian Schweitzer]

On Mon, Mar 15, 2010 at 1:32 PM, Leiv Hellebo wrote:

> Brian Schweitzer wrote:
> > Perhaps also modify it, to handle the concerns that have been raised, so
> > it's something like this:
> >
> > 
> > Release Group is part of a series {{with / , the next volume in the
> > series is}} Release Group
> >
> > Attribute: [] Next
> > 
>
> I don't quite see how valuable the AR-beetwen-Releases-or-RGs approach
> is as long as it cannot represent the name of the series. You would have
> to use the release annotation to note that some release is part of the
> "Columbia Jazz Masterpieces" as opposed to the "Columbia String Swing
> Masterpieces". And what if a release was part of two series, both the
> Summer Hits series and the DJ ÜberKool Remix series?
>

> And surely one motivating factor for working on a series would be to
> have a page that would gradually become more complete and goodlooking as
> releases were added and where one could add interesting and geeky
> annotations? For releases-in-sets we already have that: ReleaseGroups
> (at least I hope they can get annotations when NGS comes). For series,
> there is no good way to say that
>
> The series 'Opening Doors', is intended by Dausgaard and the Swedish
> Chamber Orchestra to explore "the limits of what a chamber orchestra is
> traditionally expected to perform"
> (http://www.bis.se/album_info.php?aID=BIS-SACD-1566).
>
>
I agree that eventually a "Series" or "Box" entity would be most desirable,
but until then, there's no other way that would allow linking together
Series.  For a multi-volume classical set of a single composer, that's an
annoyance, but not a real problem.  But for a VA series, there's no way,
other than *maybe* a targeted search, or really redundant annotations in
each release/RG, to move between volumes in a series easily.  And hopefully,
if there's enough people using such an AR to indicate demand for it,
Box/Series becomes a post-NGS dev priority, rather than just a theoretical
possibility...  and then you get annotations and all the other good stuff.
:D

Brian
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Part of series relationship

[Leiv Hellebo]

Brian Schweitzer wrote:
> Perhaps also modify it, to handle the concerns that have been raised, so 
> it's something like this:
> 
> 
> Release Group is part of a series {{with / , the next volume in the 
> series is}} Release Group
> 
> Attribute: [] Next
> 

I don't quite see how valuable the AR-beetwen-Releases-or-RGs approach 
is as long as it cannot represent the name of the series. You would have 
to use the release annotation to note that some release is part of the 
"Columbia Jazz Masterpieces" as opposed to the "Columbia String Swing 
Masterpieces". And what if a release was part of two series, both the 
Summer Hits series and the DJ ÜberKool Remix series?

And surely one motivating factor for working on a series would be to 
have a page that would gradually become more complete and goodlooking as 
releases were added and where one could add interesting and geeky 
annotations? For releases-in-sets we already have that: ReleaseGroups 
(at least I hope they can get annotations when NGS comes). For series, 
there is no good way to say that

The series 'Opening Doors', is intended by Dausgaard and the Swedish 
Chamber Orchestra to explore "the limits of what a chamber orchestra is 
traditionally expected to perform" 
(http://www.bis.se/album_info.php?aID=BIS-SACD-1566).


___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Add "Has News Coverage At" AR

[Brian Schweitzer]

Trying to get this proposal back on track... :)

On Sun, Mar 7, 2010 at 7:34 AM, Chad Wilson  wrote:

>  On 7/03/2010 2:56 p.m., Brian Schweitzer wrote:
>
>  I think the fear is there'd be tons of URLs linked, but without any
>> context, those URLs don't give much, other than that you know there's some
>> news article about the artist on the other end.
>>
>> However, if the AR description field could be displayed next to each URL
>> AR for that type, that field would seem to work perfectly to address some of
>> this concern and describe just what news article was on the other end of
>> each such URL AR.
>>
>> Dev impact: It wouldn't really make sense to implement this type of
>> description display on the current server code, but this would seem to
>> entail only some minor additional template handling (specific to this AR
>> type?) for the AR display page template on the NGS server.  Plus, if it were
>> added, esp universally, that so-far useless AR description field would
>> actually now have some useful purpose.  :)
>>
>> Brian
>>
>
> Chad, would this address your concerns?  As I understand the proposal, "If
> it's the former, I think the proposal/guidelines should specifically say "Do
> not link to individual articles about an artist/release", or something
> similar." would specifically be counter to the proposal; the intent is that
> individual articles *should* be linked using this proposed AR.
>
>
> Not really, no. :( Even if we mandated use of the description field, I'm
> not convinced it would be actively used despite guidelines, and we have far
> too many AR edits currently for there to be special attention to these ones.
> It's also not really "structured" - I'll come back to that later.
>

While this is true, I think we could mandate a structure, and a report (akin
to the ASIN one) could detect those ARs which have either a missing, or
incorrectly formatted, description.  It'd be almost as easy for someone to
edit in a description after the fact as it would be for the original editor
to include it.


> I mainly think manual adding and maintenance of the kinds of volumes of
> links that are available for news on any given artist - for it to give a
> useful or complete picture - is far too great to manage, and better served
> by a search engine, or tagging+mashup style approach, rather than hard AR
> links. Add to that how quickly news article links come and go in their
> validity on many websites, and I'm just not convinced that the data would
> have much value in the years to come?
>
> Most of our links currently are for general concepts, or landing pages for
> an artist where there many only be say 1, 5, 10 or maybe even 50 such links
> for an artist added. When you're talking news articles, there are thousands
> that /could/ be linked. With non-standard or potentially unreliable URLs.
> Many might be recycled/syndicated content with some extra guff added. The
> ARs wouldn't have any structured metadata, so automatic processing of
> content would be difficult.
>

While you're right, most ARs are of this sort, we do have not one, but four
existing ARs which all can easily suffer the same problem...  yet haven't.
Biography, Fanpage, History, and Review Relationship Types all are so
generic in what they allow linking to that any of the 4 could link to tens,
hundreds, even thousands of sites.  Yet I'm not aware of any artist which
has more than perhaps a few of any of these.



> I'm still really not seeing the use case for individual articles here. Who
> would find this useful where a search or aggregator site mashup would not be
> better for their purpose?
>

Imagine some future UI, giving this among the ARs for an artist:

News coverage for Foo: 2000-10-03: A new band emerges!
   2005-02-11: Foo's latest release is a hit
   2007-09-05: Foo's 'All the Best Songs' goes platinum
   2010-02-24: It's official, Foo is breaking up!

Would that not perhaps be both useful and interesting?


>
> Personally, so long as the display were able to show me the headline's
> title, it'd be a lot more useful and interesting to see articles about
> specific events in U2's history, rather than simply a link to some category
> of articles about U2.  If the latter were intended, the AR would seem rather
> redundant; an auto-generated link to
> http://news.google.com/news/search?q=U2 would suffice.
>
>
> As above, I can't really see why individual article links at MB would be
> better/more up to date/more correct than the news.google.com search
> either. There is nothing in the AR that says "only link to articles about
> important stuff"; and policing this would lead to subjective edit arguments.
>

I don't think it needs it, to be honest.  I think editors are relatively
self-selecting.  There's nothing to stop even some news agency from paying
someone to link each and every article about an artist to that artist's
page, but that'd perhaps be beneficial, if a

[mb-style] Parent Relationship Type and Sibling Relationship Type issues

[Brian Schweitzer]

I've run into another 2 ARs with open issues and suggestions dating back
anywhere from 1 to 4 years, without any resolution, so the AR's use in
various cases still is open to debate.  I'll try to just summarize the
issues I've run into in the discussion/etc pages, rather than copy them in
entirely, in hopes of this being a shorter email.  :)

1) The link phrase for Parent Relationship Type is "is the parent of".
However, nearly everyone has at least *2* parents.  So the suggestion is
that the phrase be changed to "is a parent of".

Suggestion: Change the link phrase

2) Adoptive family, step-family, in-laws, and half-family:  Parent
Relationship Type  makes no provision for indicating whether a parent is a
biological parent, adoptive parent, parent-in-law, or step-parent.  Sibling
Relationship Type makes no provision for indicating whether a sibling is a
birth sibling, step-sibling, sibling-in-law, or half-sibling.  This allows
less precision, and more clustering (esp with in-laws) than we may desire.

Suggestions:
* Add attribute "biological" to Parent Relationship Type
* Add attribute "adoptive" to Parent Relationship Type
* Add attribute "step" to Parent Relationship Type and Sibling
Relationship Type
* Add attribute "half" to Sibling Relationship Type
* Add language to each AR to the effect of "in-laws should be linked to
the artist (2) to whom the artist (1) was married, not directly to the
artist (1)"

3) Open question: This overlaps a lot with the various "changed name to"
artist-artist AR proposals, but can a group artist be considered to be the
"parent" or "child" of another group artist?  Examples are Smile as the
parent of Queen, and Marillion as the parent of Los Trios Marillos

Suggestion: Personally, while I do want a changed name to artist-artist AR,
I think this one's a stretch; member of band ARs with appropriate dates
should cover 99% of cases where this might get attempted, and even that
remaining 1% would feel only questionably correct.

Brian
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[mb-style] Band With Main Performer Name?

[Brian Schweitzer]

I've run across this page, Band With Main Performer Name (
http://wiki.musicbrainz.org/Band_With_Main_Performer_Name ), and am trying
to figure out just what to do with it while we clean up documentation.

It's essentially been left unmodified since 2006, when it was apparently
created - perhaps as part of the "project as artist type" proposal?

It, and http://wiki.musicbrainz.org/Identically_Named_Artists , both seem
really redundant.

The first seems to be setting a complex definition for what is really a
named collab that happens to have as its name the name of one of the members
of the collab.  The second is essentially a single FAQ question about how to
split an artist.  Each seem like they should just be part of the Artist, or
Artist Name, page; esp given
http://musicbrainz.org/doc/Artist_Name#Artists_with_identical_names .

Does anyone know anything about Band With Main Performer Name?  Band With
Main Performer Name also is odd, in that it seems to define a case where we
would actually invent an artist.  Supporting Musician Relationship Type
formerly had this text as part of the page, "Note that in some cases it
might be better to construct a
BandWithMainPerformerName.".
While reworking the page, I've removed that text for now, as it can only be
read (to my mind) as an outright suggestion that users can choose to invent
artists, using Band With Main Performer Name as justification, rather than
using ARs correctly to indicate a performer/supporting performer
relationship.

Brian
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[mb-style] What does the Merchandising Provider Relationship Type represent?

[Brian Schweitzer]

I've run into this one while continuing to clean up the ARs.  The
description on this one is singularly unuseful:

"Unfortunately I don't know what this role is for - it could mean a variety
of things, such as: the company that manufactures the merchandise; the
individual who organises that merchandising operation, by selling rights to
use logos and so on; or it could by a synonym for marketing."

Brian
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Part of series relationship

[Frederic Da Vitoria]

2010/3/15 Brian Schweitzer 

> The only question would be what is meant when you have some RGs in the same
> series linked with the unordered AR, and some linked with the ordered AR;
> perhaps the AR's definition language should specify that a mixed series like
> that would be meaningless (ie, counter to a guideline within the AR''s
> documentation)?
>

Not necessarily: I subscribe to a classical music magazine. Each issue comes
with a CD. All those CDs form an ordered series. But each year (usually)
there is a special issue also with a CD. You could consider that the special
issue should be inserted between the normal ones, but this would give things
like 78, 79, 80, hs12, 81, 82... Or you could also consider that the special
issues form a separate numbering sequence (which is obviously what the
magazine's authors meant). My particular example uses 2 numberings, one for
the regular issues and one for the special issues, but I am confident that
there exists somewhere unnumbered extra issues so that mixing ordered and
unordered should be allowed (but not encouraged).

-- 
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Make Don't Make Relationship Clusters history, and no longer an official guideline

[Frederic Da Vitoria]

2010/3/15 Brian Schweitzer 

> This is RFC-204.  Because I know this one's a lot of text to read, both
> here and on the DMRC page, I'm voluntarily extending the initial RFV period
> to 2 weeks, rather than the standard 1 week.  Therefore, the scheduled RFV
> date is pushed back to 2010-03-29.
>
> Brian
>
> -
>
> The idea behind Don't Make Relationship Clusters (
> http://wiki.musicbrainz.org/Don%27t_Make_Relationship_Clusters) was that
> ARs can multiply quickly.
>
> For those that don't remember that guideline offhand a quick summary of the
> problem it attempted to avoid:
>
> Michael Jackson has siblings: Rebbie, Jackie, Tito, Jermaine, La Toya,
> Marlon, Randy, and Janet.  But by definition, Janet Jackson also has all
> those same siblings, as do Rebbie, Jackie, etc.  So we don't have 8 "Michael
> Jackson has sibling " ARs.  Rather, we have 36 ARs, with each sibling
> being linked to the other siblings.  Thus, the guideline defines a
> "Relationship Cluster" as a situation where there are a group of entities in
> the database, where every entity is linked to every other entity.
>
> But is this really a problem?
>
> The page cites two reasons it is, or at least was considered to be, a
> problem.
> 1) This is a lot of unnecessary moderation work.
> 2) The difficulty of updating the database consistently.
>
> For number 1, if an editor is willing and interested in entering those ARs,
> then should we really stop them?  Also, for some ARs, such as sibling or
> parent, it's conceivable that a bot could even be written to do most of the
> work, as Don't Make Relationship Clusters suggests (the paragraph just above
> the images).  (Michael Jackson has parent Joseph Walter Jackson and sibling
> Janet Jackson | Janet Jackson has sibling Michael Jackson and La Toya
> Jackson | the bot auto-creates the link from La Toya to Joseph, and from La
> Toya to Michael).
>
> For number 2, the principle difficulty presented rests on a faulty
> premise.  It argues that:
>
> "[If] someone adds Hugh Jackman to the database, and mistakenly creates a
> sibling link to Michael Jackson and Janet Jackson. If someone then comes in
> to correct this fact, they might delete one sibling relationship without
> deleting the other. Or they might submit both deletions, but one could get
> voted down while the other gets voted through. This is, depending on how you
> look at it, either inconsistent or merely confusing."
>
> This assumes that the moderation system broke down in the first place, such
> that the link to Hugh Jackman was even created.  It also assumes that if a
> link from Michael to Hugh is incorrect, a link from Janet to Hugh is also
> guaranteed to be incorrect.
>

Many edits pass without a vote, so the creation of such a link isn't hard to
imagine to me.


It's that last which is where I see this as a broken concept.
>
> The guideline says that when a relationship cluster could potentially
> exist...
>
> "...linking various recordings of the same song together; linking artist
> performance names together; linking re-released releases together; linking
> individual releases in a box set together; and many more."
>
> then we should specify one entity to hold all the links, then only link to
> that entity, even though all the other links would technically be correct.
>
> As I see it, many of the clusters it's worried about are things we now
> actually find might be useful, or are things which point towards future
> development possibilities.
>
> * "linking various recordings of the same song together" --> NGS Recording,
> NGS Work (depending on which AR you're using)
>
> * "linking artist performance names together" --> sort of NGS Artist
> Credits, though as the performance name AR is 1:n, I don't quite follow this
> one.
>
> * "linking re-released releases together" --> Release Groups
>
> * "linking individual releases in a box set together" --> Part of Set, or
> the proposed Part of Series, either one deals with this.  In addition, this
> (and the Part of Series) points to a need in the post-NGS dev planning to
> look at some sort of "Set" entity.
>
> As for siblings/parents/etc, there's a huge assumption being made.  The
> assumption is that every sibling is related to every other sibling, and that
> every sibling shares the same parents.  In this particular case, we have 9
> children who all happen to share the same 2 parents.  But that's almost
> unusual in today's world.  Once you throw in 2nd or 3rd marriages,
> half-siblings and step-siblings, -in-laws, etc, you get a situation where
> there's not one clean cluster, but rather, several smaller clusters which
> only overlap for certain people within each cluster.
>
> Don't Make Relationship Clusters assumes, then, that when you look at any
> one entity in the cluster, you can assume that every other entity that
> *could* be linked together *should* be linked together.  If that assumption
> often isn't true, then I'd argue that we can't make

[mb-style] Part of series relationship

[Brian Schweitzer]

Oliver confirmed that in NGS, Release Groups will be valid entity types for
ARs:
http://lists.musicbrainz.org/pipermail/musicbrainz-devel/2010-March/003790.html

Perhaps the best thing to do would be to redefine this proposed AR as one
which is between Release Groups, rather than Releases?  It would have to
wait for the NGS release to be implemented, but that would allow, I think, a
better way of linking.

Perhaps also modify it, to handle the concerns that have been raised, so
it's something like this:


Release Group is part of a series {{with / , the next volume in the series
is}} Release Group

Attribute: [] Next


If the 'next' attribute is present, the AR represents an ordered Series,
such that "Foo, Volume 1" is part of a series, the next volume in the series
is "Foo, Volume 2".

If it is not present, then the AR represents an unordered Series, "Masters
of Bar: Foo!" is part of a series with "Masters of Bar: Bap!" and "Masters
of Bar: Plop!".

The latter does permit (even suggest) a relationship cluster, as by
definition every release in an unordered series is part of that series with
every other release, but I don't see that as a problem; it's factually true
(and I'm sure someone would end up writing a bot to link together any RGs
with the unordered AR that are only partially linked).

The only question would be what is meant when you have some RGs in the same
series linked with the unordered AR, and some linked with the ordered AR;
perhaps the AR's definition language should specify that a mixed series like
that would be meaningless (ie, counter to a guideline within the AR''s
documentation)?

Brian

On Thu, Mar 11, 2010 at 10:47 PM, Leiv Hellebo wrote:

> caller#6 wrote:
> > Chad Wilson wrote:
> >> On 25/02/2010 11:04 p.m., Nikki wrote:
> >>
> >>> I'd much rather see all entries in a release group linked to the same
> >>> entry (typically earliest).
> >>>
> >>
> >> Unfortunately doing this defeats one of the original benefits of the
> >> relationship as defined, which is to define a proper sequential order
> >> between the entries without relying on release events to infer order
> >> (and make possibly wrong assumptions about the "next" entry in a series
> >> where REs on the two releases are perhaps from different countries, or
> >> where there are missing entries).
> >>
> >
> > I can think of a few series off the top of my head with no explicit
> > sequential order other than cat#, namely:
> >
> > Castle Collectors Series (Castle Communications CCSxxx)
> > Columbia Jazz Materpieces (and similar Columbia/CBS reissue series for
> > fusion and classical)
>
> Yes, we want both the ordered and non-ordered series represented.
>
> This means that "release A is part of a series, the next release in the
> series is release B"
> (http://wiki.musicbrainz.org/Part_Of_Series_Relationship_Type) is not
> what we want. I guess this is even admitted on
> http://wiki.musicbrainz.org/Series: "Important: Not all series may be
> suitable for use with this relationship".
>
> I guess in stead we want some light version of the entity label, say
> "series". This would allow us to
>
> 1) give the series a name (how would you otherwise catch "Columbia Jazz
> Masterpieces" or "Opening Doors" (see annotation on
> http://musicbrainz.org/release/29628fe1-2616-481a-ad33-944ae68de31c.html)
> 2) have ARs between the series and the release groups in it. (Assuming
> it is the release groups that are in a series: Perhaps it is conceivable
> to have a SACD series where we would lump together the regular-CD and
> the SACD release in the same release group, but only the SACD one was in
> the series?)
> 3) have series pages under http://musicbrainz.org/series/, showing
> the entire series in all its glory
> 4) (possibly, hopefully) a series number or identificator which for
> sequential series allows you to get
> "FabricLive 35: Marcus Intalex is the 35th release in the FabricLive
> compilation series". (See more examples on
> http://wiki.musicbrainz.org/Series), and some smart ordering of the
> release groups on the series page.
> 5) get series with only one release in it. Today the wiki.mb.org/Series
> page says "A series can vary between two and hundreds of releases.", and
> that sounds wrong to me: Perhaps only the first volume has been
> released, perhaps the artist dies before getting to record the second.
>
> Personally I think perhaps the track series idea should be dropped: This
> sounds just weird to me: "Metallica's The Unforgiven, The Unforgiven II
> and The Unforgiven III are a track series".
>
> It will sometimes be difficult to say whether something is an imprint
> (label) or a series. Take "Columbia Jazz Masterpieces" again, my guess
> is that if that was on passionato.com it would be a sublabel. See
> examples for Decca or Deutsche Grammophon sublabels here:
> http://www.passionato.com/labels/ .
>
> Does this make any sense? Perhaps the ideas have already been dismissed?
>
> Lei

[mb-style] RFC: Make Don't Make Relationship Clusters history, and no longer an official guideline

[Brian Schweitzer]

This is RFC-204.  Because I know this one's a lot of text to read, both here
and on the DMRC page, I'm voluntarily extending the initial RFV period to 2
weeks, rather than the standard 1 week.  Therefore, the scheduled RFV date
is pushed back to 2010-03-29.

Brian

-

The idea behind Don't Make Relationship Clusters (
http://wiki.musicbrainz.org/Don%27t_Make_Relationship_Clusters) was that ARs
can multiply quickly.

For those that don't remember that guideline offhand a quick summary of the
problem it attempted to avoid:

Michael Jackson has siblings: Rebbie, Jackie, Tito, Jermaine, La Toya,
Marlon, Randy, and Janet.  But by definition, Janet Jackson also has all
those same siblings, as do Rebbie, Jackie, etc.  So we don't have 8 "Michael
Jackson has sibling " ARs.  Rather, we have 36 ARs, with each sibling
being linked to the other siblings.  Thus, the guideline defines a
"Relationship Cluster" as a situation where there are a group of entities in
the database, where every entity is linked to every other entity.

But is this really a problem?

The page cites two reasons it is, or at least was considered to be, a
problem.
1) This is a lot of unnecessary moderation work.
2) The difficulty of updating the database consistently.

For number 1, if an editor is willing and interested in entering those ARs,
then should we really stop them?  Also, for some ARs, such as sibling or
parent, it's conceivable that a bot could even be written to do most of the
work, as Don't Make Relationship Clusters suggests (the paragraph just above
the images).  (Michael Jackson has parent Joseph Walter Jackson and sibling
Janet Jackson | Janet Jackson has sibling Michael Jackson and La Toya
Jackson | the bot auto-creates the link from La Toya to Joseph, and from La
Toya to Michael).

For number 2, the principle difficulty presented rests on a faulty premise.
It argues that:

"[If] someone adds Hugh Jackman to the database, and mistakenly creates a
sibling link to Michael Jackson and Janet Jackson. If someone then comes in
to correct this fact, they might delete one sibling relationship without
deleting the other. Or they might submit both deletions, but one could get
voted down while the other gets voted through. This is, depending on how you
look at it, either inconsistent or merely confusing."

This assumes that the moderation system broke down in the first place, such
that the link to Hugh Jackman was even created.  It also assumes that if a
link from Michael to Hugh is incorrect, a link from Janet to Hugh is also
guaranteed to be incorrect.

It's that last which is where I see this as a broken concept.

The guideline says that when a relationship cluster could potentially
exist...

"...linking various recordings of the same song together; linking artist
performance names together; linking re-released releases together; linking
individual releases in a box set together; and many more."

then we should specify one entity to hold all the links, then only link to
that entity, even though all the other links would technically be correct.

As I see it, many of the clusters it's worried about are things we now
actually find might be useful, or are things which point towards future
development possibilities.

* "linking various recordings of the same song together" --> NGS Recording,
NGS Work (depending on which AR you're using)

* "linking artist performance names together" --> sort of NGS Artist
Credits, though as the performance name AR is 1:n, I don't quite follow this
one.

* "linking re-released releases together" --> Release Groups

* "linking individual releases in a box set together" --> Part of Set, or
the proposed Part of Series, either one deals with this.  In addition, this
(and the Part of Series) points to a need in the post-NGS dev planning to
look at some sort of "Set" entity.

As for siblings/parents/etc, there's a huge assumption being made.  The
assumption is that every sibling is related to every other sibling, and that
every sibling shares the same parents.  In this particular case, we have 9
children who all happen to share the same 2 parents.  But that's almost
unusual in today's world.  Once you throw in 2nd or 3rd marriages,
half-siblings and step-siblings, -in-laws, etc, you get a situation where
there's not one clean cluster, but rather, several smaller clusters which
only overlap for certain people within each cluster.

Don't Make Relationship Clusters assumes, then, that when you look at any
one entity in the cluster, you can assume that every other entity that
*could* be linked together *should* be linked together.  If that assumption
often isn't true, then I'd argue that we can't make that assumption ever -
that even though "Relationship Clusters" are an interesting phenomenon,
"Don't Make Relationship Clusters" is a bad conclusion to draw from them.

Brian
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
h