[mb-style] RFC: Add "founder" as attribute to the Member of Band AR

[Brian Schweitzer]

This clears out another old proposal.  Actually, this one is the oldest
style proposal still sitting in Trac without some resolution - the trac
ticket is 4 years old, the discussion page began before we even had
moinmoin, etc. :P

Looking at the potential solutions which would allow this data to be
captured, the only one that really cleanly solves it seems to me to be 'Add
a new MBWiki:AdvancedRelationshipAttribute  "founding member"'.

While it is true that we can set the start date for the "member of" AR as
the same start date for the group, this only allows the user to infer that
the person artist likely was a founding member.  However, I've seen some
cases where this wasn't actually true.
2 possible cases:

1) We don't know a precise start date.  So the best we can say is
"FoundingArtist was a member of group Foo starting in 1992",
"SomeOtherArtist was a member of group Foo starting in 1992", "Foo began in
1992".  However, FoundingMember may have begun the band in February, with
SomeOtherArtist joining in November.  We may not actually have the months
and/or exact dates, but we do sometimes have info that FoundingMember(s)
started the group, whereas SomeOtherArtist joined later.  That info
currently gets hidden by our missing info regarding exact dates.

2) 1 group fades away, another comes together under a new name, then they go
find a drummer.  The band may not actually start rehearsing until they have
a drummer, such that the various artists all have the same start date, but
it seems be hard to argue that someone can both found a group and be
recruited to join that same already existing (if only as an idea) group.

The proposed new AR page is at
http://wiki.musicbrainz.org/User:BrianFreud/Member_Of_Band_Relationship_Type_Proposal#.22founder.22

There is various old discussion at
http://wiki.musicbrainz.org/FoundingMemberDatesQuestion

The related trac ticket is http://bugs.musicbrainz.org/ticket/1009

This is RFC-82.  Without objection, it will move to RFV on 2010-03-08.

Thanks,

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

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

[Brian Schweitzer]

Since there's a few very related proposals which are without a champion,
this is an attempt to kill a few birds with one stone.  :)

I'm resurrecting one of the last threads where at least some of this was
touched on.

Right now, we have 1 video format in the current server's release formats
list: "DVD".

We already have HD-DVD, DVD-Video, DVD-Audio, and Blu-ray being added to DVD
as formats in NGS.

This would add a few more, to clear off other common video formats:

* 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)

and more essoteric audio formats:

* 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)

This RFC is an attempt to clear a few otherwise abandoned proposals; as a
whole, this is RFC-93, and, barring objection, will move to RFV on
2010-03-08.

Brian

On Wed, Jun 3, 2009 at 1:55 AM, Philip Jägenstedt  wrote:

> On Wed, Jun 3, 2009 at 01:15, Age Bosma  wrote:
> > Philip Jägenstedt wrote:
> >>> Main required formats:
> >>> * DVD-Video
> >>> * DVD-Audio
> >>> * VHS
> >>>
> >>> A choice between the first and the second format should be based on the
> >>> actual label ([1] or [2]) present on the DVD.
> >>
> >> The lack of a technically clear distinction between the two formats is
> >> apparent if we need to base the format on what the packaging says. I
> >> guess that a DVD with both AUDIO_TS and VIDEO_TS would be both and
> >> even if the standards don't allow it (do they?) such discs probably
> >> exist.
> >>
> >
> > In case of DVD there is an actual different in the the allowed format of
> > audio between DVD-Video and DVD-Audio. Yes, the physical disc is the
> > same, the file structure probably as well. There is, however, difference
> > in bit-rate/sampling rate/channel combinations [5].
> >
> >>> We currently have 'DVD' as a format. Keeping it as a separate format is
> >>> probably not desirable. As of 2009-06-01 we have 611 releases in our db
> >>> marked as 'DVD' [3]. An additional 152 'Other' releases could use some
> >>> investigation to see if they fall into one of the category format
> >>> mentioned above.
> >>> Imho we have two options to deal with this:
> >>>
> >>> 1. Change all present 'DVD' releases to 'DVD-Video' automatically. At
> >>> least most of them fall under this format since 'DVD-Audio' isn't
> widely
> >>> available.
> >>> 2. Keep 'DVD' as a format for a while and create a report listing all
> >>> releases filed as such. Change every release manually and remove the
> >>> 'DVD' format as soon as there are none left.
> >>
> >> 3. Keep DVD and only add DVD-Audio. Change to DVD-Audio as needed.
> >> Most people don't even know that there can be non-video DVD's, so in
> >> terms of presentation I think just "DVD" is better.
> >>
> >
> > This will probably have the effect that people are going to think 'I've
> > never heard about DVD-Audio, it must be DVD then'. All would be valid
> > under 'DVD'.
>
> Sounds to me like a good thing, as it's highly unlikely that someone
> has a DVD-Audio disc without knowing it. At least I have never seen a
> DVD-Audio disc, so making even hiding it by default and having a "Show
> all formats" option would be cool (or having the most common at the
> top of the select widget followed by "" and then all of them).
>
> >>> My preference goes to the first option in terms of work but I know that
> >>> the second one will result on more correct data. 611 releases aren't
> >>> that many anyway (any volunteers? ;-)).
> >>>
> >>> Then there's 'Blu-ray' and 'HD DVD' nowadays. Since we have some exotic
> >>> formats already (Wax Cylinder, etc) it only seems proper to include
> >>> those two as well. Along with 'Betamax' if we are going to include 'HD
> >>
> >> Unless there are any releases in the database which actually would be
> >> set to betamax (creating one after reading this doesn't count) I don't
> >> think it should be added.
> >>
> >
> > Agreed. There are at least releases present in 'DVD' and 'VHS' (at lest
> > 28 [6]), older ones can be added when needed, when they appear. The same
> > can be said for 'HD DVD'. I do think it would be good to already include
> > 'Blu-ray' as they will start to appear more and more.
> >
> > UMD is another format we might want to consider. At least two releases
> > are already present [7].
> >
> > Age
> >
> >
> > [5] http://en.wikipedia.org/wiki/DVD-Audio
> > [6] http://musicbrainz.org/show/tag/?tag=vhs
> > [7] http://musicbrainz.org/show/tag/?tag=umd
> >
> > ___
> > Musicbrainz-style mailing list
> > Musicbrainz-style@lists.musicbrainz.org
> > http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
> >
>
>
>
>

[mb-style] RFV: proposed relationship release/track to url: has score at

[Brian Schweitzer]

Having seen no objections, and a week (actually, 9 days) having passed since
the RFC, this proposal has entered RFV.  Without objection, it will pass on
2010-03-03.

This proposal is RFC-2.

Brian

On Sat, Feb 20, 2010 at 1:40 PM, mbuser838171846981 <
mbuser838171846...@fastmail.fm> wrote:

> hello style list,
>
> having a relationship describing where to find the score for the music
> of a release or track is useful in analogy to having links to lyrics;
> especially users playing instruments themselves will appreciate this.
>
> by suggestion by nikki on irc, i created a proposal wiki page at [1] in
> the style (aka, copy/pasted) of the lyrics relationship [2] for a new
> "Has Score At" relationship type.
>
> i'd like to propose the relationship for discussion, and, finally, for
> inclusion in musicbrainz.
>
> concerning the legal status of sheet music, the relationship might have
> to be limited to domains where copyright is handled in a responsible
> way. the IMSLP project at [3] seems to be one of those sites, as
> detailed in the wiki page at [1].
>
> regards
> mbuser838171846981
>
> [1] http://wiki.musicbrainz.org/Has_Score_At_Relationship_Type
> [2] http://wiki.musicbrainz.org/Has_Lyrics_At_Relationship_Type
> [3] http://imslp.org/wiki/
>
> ___
> 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

[mb-style] RFC: NGS: Groups and Gender (Q1)

[Brian Schweitzer]

No further discussion has taken place in the past ten days, and the original
discussion seems to be pretty clear on a concensus here.

So, RFC-72: NGS: Groups and Gender

This does not change anything, but resolves an open decision by the NGS devs
which required a decision by RFC.  This RFC would answer the question
"Should group artists have genders?" with a "No".

Without objection, this RFC will go to RFV on 2010-03-08.

Brian

On Fri, Feb 19, 2010 at 11:01 AM, Andrew John Hughes <
gnu_and...@member.fsf.org> wrote:

> On 18 February 2010 15:50, Brian Schweitzer
>  wrote:
> > The first question is one currently raised in
> > http://jira.musicbrainz.org/browse/MBS-344 .  It's been discussed a few
> > times, including
> >
> http://chatlogs.musicbrainz.org/musicbrainz/2010/2010-01/2010-01-20.html#T18-26-42-754738
> > .
> >
> > Question: *Person* artists have genders.  Should *group* artists also be
> > allowed to have a gender?  If so, what would a "male group", a "female
> > group", or other group genders, pending decision of the other question,
> > actually mean?  What would *not* be a "male group"?
> >
> >
> > Personally, I don't think groups should have genders.  Would simply a
> group,
> > like New Kids on the Block, being known as a "boy band" then make it a
> "male
> > group", rather than simply a "group" - and if so, wouldn't whatever
> special
> > meaning is being assumed by those who support constructions like "male
> > group" immediately be watered down to meaninglessness?  Even if we
> narrowly
> > defined the permissible situations for group artists to have a gender
> entry,
> > due to artists being auto-edits, the 90% who never read the FAQs would
> > simply "fill in the blank" and pick a gender anyhow, thus making it a
> large
> > task to maintain correct data for the (I assume) .01% of groups
> for
> > whom gender might actually have some special meaning.
> >
> > Brian
> >
> > On Thu, Feb 18, 2010 at 10:49 AM, Brian Schweitzer
> >  wrote:
> >>
> >> There currently are two related issues from the NGS developers which
> need
> >> debate and decision by the style list.  Before I move either to RFC, I'd
> >> like to see if we can figure out just what guidance the RFC should
> actually
> >> give.
> >>
> >> As you may know, one of the new things under NGS is that artists now
> will
> >> have (among others) an additional field to store the gender of that
> artist.
> >> (See http://musicbrainz.org/doc/NextGenerationSchema#Artist )
> >>
> >> Besides being generally useful to know, for the curious, for
> >> disambigulatory reasons, for the data client, or for any other reasons,
> it's
> >> also something that i18n (site translation) support will need, as sme
> >> languages (unlike English) construct different sentences depending upon
> the
> >> gender of the subject.  (Thus something like "was a member of the band
> Foo"
> >> would be differently constructed depending on if that band member were a
> >> she, a he, or something else.)
> >>
> >> As I can see both questions being debated to some length, to help keep
> >> things easy to follow, I'm going to introduce each in a separate reply
> to
> >> this email.  If you could, please try to keep the discussion on each to
> the
> >> appropriate thread?
> >>
> >> Thanks!
> >>
> >> Brian
> >
> >
> > ___
> > Musicbrainz-style mailing list
> > Musicbrainz-style@lists.musicbrainz.org
> > http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
> >
>
> I don't see the reason to represent a group as having a gender.
> Besides, if you really wanted to show that Take That or Boyzone, etc.
> are boy bands, surely it can be automatically derived from the genders
> of the artists that are members of the group?  It certainly doesn't
> need to be user-editable.
> --
> 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-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

[mb-style] RFV?: Two decisions on gender needed for the NGS devs: Q2: Alternate Genders

[Brian Schweitzer]

There's been no further discussion on this, and the RFC is scheduled to go
to RFV today.  Luks, before this goes to RFV, did you still have concerns?

2010/2/22 Brian Schweitzer 

> Well, offhand, one that would definitely fit your bill would be Jade Starr
> (not the porn actress), and another that comes pretty close, but more
> debatably, is Jayne Country.
>
> Jade Starr: http://www.dreadcircus.com/
> **"In a world controlled by  FEAR of acceptance and LIES Labels are a
> quick reference to explainour individuality. Society have chosen the word
> "Transsexual" to define my misunderstood so called "condition" called
> existence. The only word I choose to be defined by is "ME". I'm a singer,
> guitarist, actor, songwriter and artist."
>
> Jayne Country: http://www.jaynecounty.com/
>
> 2010/2/22 Lukáš Lalinský 
>
> On Mon, Feb 22, 2010 at 1:05 PM, Brian Schweitzer
>>  wrote:
>> > There's some groups in there, and some (Wendy Carlos) might be best set
>> to
>> > male or female, if they have a clear and public gender decision stating
>> > themselves to be male or female, not "Other" - but that part is probably
>> > best left to whatever guideline we end up drafting on artist genders.
>>
>> Which is why I asked about a list where somebody is sure that Other is
>> the right choice. Wendy Carlos, for example, identifies herself as
>> female, so I see no reason for using the Other option.
>>
>> --
>> Lukas Lalinsky
>> lalin...@gmail.com
>>
>> ___
>> 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

[mb-style] RFV: Live Bootleg Style, Live Track Style

[Brian Schweitzer]

This proposal has now entered the RFV stage.  Without veto, it will pass on
2010-03-03.

On Mon, Feb 22, 2010 at 8:34 AM, Brian Schweitzer <
brian.brianschweit...@gmail.com> wrote:

> Noone had had any negative comments when I'd asked about this last, back in
> the beginning of December, so let's give it a shot at RFC.
>
> These two proposals have been around for just about forever (2006-01-23 and
> 2006-04-03, respectively).  They've both ended up in active use for several
> years now, even if they're unofficial and perhaps still have a few warts.
> Untitled Bootleg Style, on the other hand, which those would replace, has
> been essentially abandoned in favor of LBS, even if it is the official
> guideline (LBS entirely encompasses everything in UBS, plus adds the detail
> for more complex cases).
>
> Since this is the de facto reality anyhow, this RFC would make the de facto
> reality also the official reality; ie, eliminate UBS and make LBS and LTS
> official.
>
> Given the large amount of variation in bootlegs, kind of by definition, LBS
> and LTS both still likely can not be considered perfect, but at moving them
> from proposals to official, and getting rid of the unused Untitled Bootleg
> Style would make the documentation a little cleaner and more closely
> resemble reality.
>
> Without objection, this will go to RFV on Monday March 1, 2010.
>
> Brian
>
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[mb-style] RFC: Create three new AR Classes, remove 3 existing AR Classes, move Affiliate RC, merge 2 existing AR Types

[Brian Schweitzer]

Summary:
* Create three new AR Classes, "External Resource Relationship Class",
"External Information Relationship Class", and "External Website
Relationship Class".
* Decommission and remove "Discography Relationship Class", "Online Data
Relationship Class", and "Other Databases Relationship Class".
* Merge "Official Site Relationship Type" into "Official Homepage
Relationship Type", decomissioning "Official Site Relationship Type".



The primary Class, "External Resource Relationship Class", would be created
by merging together Discography Relationship Class, Other Databases
Relationship Class, and Online Data Relationship Class.

* Discography Relationship Class is problematic at the moment. It is
supposed to be "links to discographic resources", but it's a very tenuous
argument to claim that some of these ARs could be considered "discographic".

* Online Data Relationship Class is problematic in two ways. Unlike all the
other AR Classes, save one, this one is defined by what it links to, not
what it holds. By definition, "This is a class of relationships that record
relations between Labels and urls. They are all Label-URL Relationships."
Except... not all label ARs are in this Class, and not all ARs in this class
are exclusively label-URL ARs. In other words, this Class doesn't actually
mean anything, let alone what it claims to mean.  The other problem here is
that the other Class which groups RT's by entity, not subject, is "Label
Relationship Class" (a meta-Class), which is entirely redundant to this one,
in that it too "is a "meta" class of relationships that records relations
involving Labels."

* Other Databases Relationship Class isn't problematic, per say. However,
the one thing all the ARs in these three classes *do* have in common is that
they link to a page outside of MusicBrainz. "Online databases" becomes
difficult to define, vs the ARs not already in this class - Discogs is
clearly a database, but is Youtube, at least to some degree, not also a
database of videos?

The only real type of difference between the ARs in this new class is that
some point to any page at a specific website, whereas the others are
generalized such that they point to one type of page at any website.  So two
classes, "External Information Relationship Class" and "External Website
Relationship Class", would be created to hold each group.  These two Classes
would themselves be members of the new "External Resource Relationship
Class".

Affiliate Relationship Class contains, like Other Databases RC, ARs which
link elsewhere (Amazon only, atm).  There is a worthwhile distinction for
this class's meaning, however; the only change here would be to make that
class a subclass of the new "External Website Relationship Class".

So, the new structure I propose would look like this:

+ External Resource Relationship Class
+ External Information Relationship Class
* Biography Relationship Type
* Catalog Site Relationship Type
* Discography Relationship Type
* Fanpage Relationship Type
* HasNewsCoverage Relationship Type
* History Site Relationship Type
* Image Relationship Type
* Logo Relationship Type
* Official Homepage Relationship Type
* Review Relationship Type
+ External Website Relationship Class
+ Affiliate Relationship Class
* Amazon Relationship Type
* BBCMusic Relationship Type
* Discogs Relationship Type
* MusicMoz Relationship Type
* MySpace Relationship Type
* MySpace Relationship Type
* Wikipedia Relationship Type
* YouTube Relationship Type

Note, I left Official Site Relationship Type out of the above list; I'll get
to that one in a moment.

The new Classes would be defined in this way:

This class defines relationships that allow MusicBrainz  to interact with
affiliate sites on the internet.

* External Resource Relationship Class
  This class defines relationships that allow MusicBrainz to interact
with other sources of data outside of MusicBrainz.

* External Information Relationship Class
  This class defines relationships that allow MusicBrainz to interact
with specific types of information found outside of MusicBrainz.

* External Website Relationship Class
  This class defines relationships that allow MusicBrainz to interact
with specific websites.

* Affiliate Relationship Class
  This class defines relationships that allow MusicBrainz  to interact
with affiliate sites on the internet.
  NOTE: This is unchanged; ^^ is the definition that already is in place
for this Relationship Class.

Last, to merge Official Homepage Relationship Type and Official Site
Relationship Type into Official Homepage Relationship Type.  The
implementations of each can be left alone; there is no overlap between the
label-URL AR and the artist-URL AR.  However, the data each links to is of
the same type, to such as degree that each uses the 

Re: [mb-style] RFC: Fix Production Relationship Class

[Brian Schweitzer]

My apologies, I'd intended to take the really long aka out of the title
before I hit send.  :P
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC (4th try): add attribute 'translated' to LyricistRelationshipType

[Brian Schweitzer]

On Sun, Feb 28, 2010 at 8:33 AM, Jan van Thiel  wrote:

> On 27 February 2010 17:02, Brian Schweitzer
>  wrote:
> > On Sat, Feb 27, 2010 at 8:39 AM, Jan van Thiel 
> wrote:
> >> This is a fourth RFC, rephrased compared to the third RFC. On the JIRA
> >> bug tracker this RFC is located at [4].
> >>
> >> --
> >>
> >> I'd like to see attribute 'translated' added to the Lyricist
> >> Relationship Type[1].
> >>
> >> The phrase for this attribute could read "This attribute describes if
> >> the lyrics are a translation of the same work in another language."
> >>
> >> This should only be used for lyrics that somehow follow the original
> >> lyrics (e.g. carry the overall meaning of the work into the other
> >> language). The 'translated' attribute does not apply on cases where
> >> the meaning of the lyrics is unrelated (i.e. only the music is
> >> related/covered).
> >
> > I know this is where this got bogged down the last time, and this is
> > definitely better, but "follow the original
> > lyrics (e.g. carry the overall meaning of the work into the other
> > language)." still seems like it's stretching; it specifies something, but
> > the something it's defining is so vague that I can see lots of potential
> > misreadings and loopholes.  Would something like this (to replace the
> entire
> > above paragraph) maybe work better?
> >
> > "While a literal translation is not required for this attribute, the
> > translated lyrics should still be distinctly and detectably derived from
> the
> > original lyrics." and leave any further value judgments for the voters to
> > decide?
>
> I guess this is better. Finally a native English speaker gives it a go ;)
>
> >> Parody translations should be linked with Parody Relationship
> >> Attribute[2] of the Cover Relationship Type[3], not with this
> >> attribute.
> >>
> >
> > What if the original song were a serious song with lyrics in German, and
> the
> > new song were an English parody of the German song?  To give this some
> > purely hypothetical context, consider a parody version of the German
> > football team's (hypothetical) fight song, released by the fan of a team
> > from South Africa, taunting the German team during the World Cup.  Would
> > that use both parody and translated, or would the last bit above exclude
> > *any* parodies, translated or not?
>
> It should exclude *all* parodies, whether they are translated or not.
> Parodies in general have new lyrics, right?
>
> I guess that's where I'd see the judgment of the voters coming into play.
It's not a translation from any other language, but wouldn't you consider
"We will, we will, mock you!" (just one at random;
http://www.com-www.com/weirdal/submissions/parody-049.html ) to be
essentially the same lyrics, but satirized?  I just get the sense that
there's cases where both attributes could be true, so making the two
attributes explicitly mutually exclusive seems like its being
over-restrictive. Is your aim to block these perhaps rare "almost the same,
even in translation, parody lyrics" cases, or to avoid something like
http://www.com-www.com/weirdal/submissions/parody-049.html having an
English-English satirization of the lyrics misinterpreted as "translation"?

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

[mb-style] RFC: Fix Production Relationship Class (aka: convert the current Miscellaneous Production and Engineer Relationship Types to Relationship Classes, fix/implement the unimplemented but alread

[Brian Schweitzer]

This proposal is nit-picky, but it cleans up a rather BigMess in the ARs,
where a bunch of stuff just ended up dumped together without the same degree
of organization that most of the rest of the ARs received.  A better, but
way too long, title for this RFC would be: "Convert the current
Miscellaneous Production and Engineer Relationship Types to Relationship
Classes, fix/implement the unimplemented but already-passed specific
Engineer Relationship types, and fix Programming Relationship Type."

http://wiki.musicbrainz.org/Miscellaneous_Production_Relationship_Type
This so-called "relationship type" actually contains 11 of the ~23 or so
relationship types that fall within ProductionRelationshipClass.

http://wiki.musicbrainz.org/Engineer_Relationship_Type
This is the other "relationship type", which actually contains approximately
8 of the ~23 different ProductionRelationshipClass relationship types.

This proposal would clarify the distinction between a Relationship Class and
a Relationship Type.  A Relationship Type is supposed to be one specific AR:

"Each relationship entered by a user belongs to one
AdvancedRelationshipType. These types define:

* Which entities will be related (artists, releases, labels, tracks,
etc)
* What AdvancedRelationshipAttributes go along with the relationship
* The LinkPhrases of the relationships, which describe how to write the
relationship information in English sentences."

whereas a Relationship Class is supposed to be a 'thematic grouping [of ARs]
for the purpose of having related relationship types close to each other'.

Thus, it's pretty easy to see that the contents of
Miscellaneous_Production_Relationship_Type and Engineer_Relationship_Type
each actually are describing Relationship Classes, even though they're named
as Relationship Types.  The only difference here is that they're not
top-level classes, but rather are sub-classes of Production Relationship
Class.

So the main part of this proposal would convert these, and their contained
ARs, to the correct terminology.  (The terminology distinction makes no
difference at the AR implementation level, so this would have no impact
outside of the documentation.)

Now -> After Proposal

These are really long names; to cut down on length for readability, a few
abbreviations:
MPRT = Miscellaneous Production Relationship Type
MPRC = Miscellaneous Production Relationship Class
ERT = Engineer Relationship Type
ERC = Engineer Relationship Class
RC = Relationship Class
RT = Relationship Type

* MPRT (the class) -> MPRC (Subclass of Production Relationship Class)
* MPRT (the AR) -> Miscellaneous Production RT (member of MPRC)
* Legally Represented (part of MPRT) -> Legal Representation RT (member of
MPRC)
* Booked (part of MPRT) -> Booker  RT (member of MPRC)
* Artist and Repertoire Support (A&R) (part of MPRT) -> Artist and
Repertoire Support RT (member of MPRC)
* Creative Direction (part of MPRT) -> Creative Direction RT (member of
MPRC)
* Art Direction (part of MPRT) -> Art Direction RT (member of MPRC)
* Design / Illustration (part of MPRT) -> Design and Illustration RT (member
of MPRC)
* Graphic Design (part of MPRT) -> Graphic Design RT (member of MPRC)
* Photography (part of MPRT) -> Photography RT (member of MPRC)
* Travel Arrangements (part of MPRT) -> Travel Agent RT (member of MPRC)
* Merchandising by (part of MPRT) -> Merchandising Provider RT (member of
MPRC)
* Liner Notes by (part of MPRT) -> Liner Notes Author RT (member of MPRC)

* ERT (the class) -> ERC (Subclass of Production Relationship Class)
* engineered (the AR, part of ERT) -> Engineer RT (member of ERC)
* audio engineered (part of ERT) -> Audio Engineer RT (member of ERC)
* sound engineered (part of ERT) -> Sound Engineer RT (member of ERC)
* live sound engineered (part of ERT) -> Live Sound Engineer RT (member of
ERC, sub-RT to Sound Engineer RT)
* mixed (part of ERT) -> Mix Engineer RT (member of ERC)
* recorded (part of ERT) -> Recording Engineer RT (member of ERC)
* mastered (part of ERT) -> Mastering Engineer RT (member of ERC)
* edited (part of ERT) -> Editor RT (member of ERC)

The last two for engineering are a little complex; the documentation
actually doesn't provide info enough to determine just what these are.
"This more specific version designates artists who engineered an
instrument." and "This more specific version designates artists who
engineered the vocal."  However, it doesn't say just which type of engineer
AR these are intended to be a more specific form *of*.
Note that the docs are way out of date there - the two more specific
engineer roles are not actually proposals anymore, they just never got
implemented (or the wikipage updated) after they passed (the server,
apparently, could not handle implementing them properly at the time).  They
both passed their RFVs, however, 2 years ago, on 2008-03-02.

Rather than implement them entirely as in the proposal, as new RTs

Re: [mb-style] RFC: Extend the Has Lyrics At AR to artists

[Brian Schweitzer]

On Sun, Feb 28, 2010 at 8:51 AM, Atedos  wrote:

> I just personally had to deal with http://lyrics.wikia.com/Autumn
> Those of Russian band are under "Other
> songs".
>

So it's a problem of their not supporting artist disambiguation?
Personally, I could live with that.  If you're looking for lyrics to a song
by some artist, you likely already know the title of the song, so a link to
lyrics by that artist, even if it also contains lyrics by one or two other
artists of the same name, isn't going to be misleading (since I already know
what I'm looking for when I get to that list of song titles).


> 2010/2/28 Brian Schweitzer 
>
>> On Sun, Feb 28, 2010 at 3:45 AM, Atedos  wrote:
>>
>>> Single artist page on LyricWiki may belong to several artists, I don't
>>> think it's a good idea.
>>>
>>
>> That sounds somewhat contradictory to me, and though I've not spent huge
>> amounts of time there, each listing I've looked at would resolve correctly
>> to a single artist listing at MB.  Could you give some examples where
>> there's more than one artist on a page such that this wouldn't be true?
>>
>>
>>> 2010/2/28 Brian Schweitzer 
>>>
 Sorry, that should read Sunday, 2010-03-07.

  On Sun, Feb 28, 2010 at 2:12 AM, Brian Schweitzer <
 brian.brianschweit...@gmail.com> wrote:

> Currently, the Has Lyrics At AR allows only release-URL and track-URL
> links to lyrics.wikia.com.  This RFC would extend the AR to also allow
> artist-URL links, such as linking http://lyrics.wikia.com/Tori_Amos to
> the Tori Amos listing.
>
> This RFC is RFC-90, and has a proposal page at
> http://wiki.musicbrainz.org/User:BrianSchweitzer/HasLyricsAtExtentionProposal.
>   Without objection, this RFC will move to RFV on Sunday, 2010-03-10.
>
> Thanks,
> Brian
>


 ___
 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
>>>
>>
>>
>> ___
>> 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
>
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Extend the Has Lyrics At AR to artists

[Atedos]

I just personally had to deal with http://lyrics.wikia.com/Autumn
Those of Russian band are under "Other
songs".

2010/2/28 Brian Schweitzer 

> On Sun, Feb 28, 2010 at 3:45 AM, Atedos  wrote:
>
>> Single artist page on LyricWiki may belong to several artists, I don't
>> think it's a good idea.
>>
>
> That sounds somewhat contradictory to me, and though I've not spent huge
> amounts of time there, each listing I've looked at would resolve correctly
> to a single artist listing at MB.  Could you give some examples where
> there's more than one artist on a page such that this wouldn't be true?
>
>
>> 2010/2/28 Brian Schweitzer 
>>
>>> Sorry, that should read Sunday, 2010-03-07.
>>>
>>>  On Sun, Feb 28, 2010 at 2:12 AM, Brian Schweitzer <
>>> brian.brianschweit...@gmail.com> wrote:
>>>
 Currently, the Has Lyrics At AR allows only release-URL and track-URL
 links to lyrics.wikia.com.  This RFC would extend the AR to also allow
 artist-URL links, such as linking http://lyrics.wikia.com/Tori_Amos to
 the Tori Amos listing.

 This RFC is RFC-90, and has a proposal page at
 http://wiki.musicbrainz.org/User:BrianSchweitzer/HasLyricsAtExtentionProposal.
   Without objection, this RFC will move to RFV on Sunday, 2010-03-10.

 Thanks,
 Brian

>>>
>>>
>>> ___
>>> 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
>>
>
>
> ___
> 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] RFC (4th try): add attribute 'translated' to LyricistRelationshipType

[Jan van Thiel]

On 27 February 2010 17:02, Brian Schweitzer
 wrote:
> On Sat, Feb 27, 2010 at 8:39 AM, Jan van Thiel  wrote:
>> This is a fourth RFC, rephrased compared to the third RFC. On the JIRA
>> bug tracker this RFC is located at [4].
>>
>> --
>>
>> I'd like to see attribute 'translated' added to the Lyricist
>> Relationship Type[1].
>>
>> The phrase for this attribute could read "This attribute describes if
>> the lyrics are a translation of the same work in another language."
>>
>> This should only be used for lyrics that somehow follow the original
>> lyrics (e.g. carry the overall meaning of the work into the other
>> language). The 'translated' attribute does not apply on cases where
>> the meaning of the lyrics is unrelated (i.e. only the music is
>> related/covered).
>
> I know this is where this got bogged down the last time, and this is
> definitely better, but "follow the original
> lyrics (e.g. carry the overall meaning of the work into the other
> language)." still seems like it's stretching; it specifies something, but
> the something it's defining is so vague that I can see lots of potential
> misreadings and loopholes.  Would something like this (to replace the entire
> above paragraph) maybe work better?
>
> "While a literal translation is not required for this attribute, the
> translated lyrics should still be distinctly and detectably derived from the
> original lyrics." and leave any further value judgments for the voters to
> decide?

I guess this is better. Finally a native English speaker gives it a go ;)

>> Parody translations should be linked with Parody Relationship
>> Attribute[2] of the Cover Relationship Type[3], not with this
>> attribute.
>>
>
> What if the original song were a serious song with lyrics in German, and the
> new song were an English parody of the German song?  To give this some
> purely hypothetical context, consider a parody version of the German
> football team's (hypothetical) fight song, released by the fan of a team
> from South Africa, taunting the German team during the World Cup.  Would
> that use both parody and translated, or would the last bit above exclude
> *any* parodies, translated or not?

It should exclude *all* parodies, whether they are translated or not.
Parodies in general have new lyrics, right?

Jan (zout)

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

Re: [mb-style] RFC: Extend the Has Lyrics At AR to artists

[Brian Schweitzer]

On Sun, Feb 28, 2010 at 3:45 AM, Atedos  wrote:

> Single artist page on LyricWiki may belong to several artists, I don't
> think it's a good idea.
>

That sounds somewhat contradictory to me, and though I've not spent huge
amounts of time there, each listing I've looked at would resolve correctly
to a single artist listing at MB.  Could you give some examples where
there's more than one artist on a page such that this wouldn't be true?


> 2010/2/28 Brian Schweitzer 
>
>> Sorry, that should read Sunday, 2010-03-07.
>>
>> On Sun, Feb 28, 2010 at 2:12 AM, Brian Schweitzer <
>> brian.brianschweit...@gmail.com> wrote:
>>
>>> Currently, the Has Lyrics At AR allows only release-URL and track-URL
>>> links to lyrics.wikia.com.  This RFC would extend the AR to also allow
>>> artist-URL links, such as linking http://lyrics.wikia.com/Tori_Amos to
>>> the Tori Amos listing.
>>>
>>> This RFC is RFC-90, and has a proposal page at
>>> http://wiki.musicbrainz.org/User:BrianSchweitzer/HasLyricsAtExtentionProposal.
>>>   Without objection, this RFC will move to RFV on Sunday, 2010-03-10.
>>>
>>> Thanks,
>>> Brian
>>>
>>
>>
>> ___
>> 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
>
___
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

[Chad Wilson]

I'm reading two different concepts here. The original idea for Guardian 
in IRC talks about linking to tag/index pages on an artist, which might 
be sensible. The proposal as it reads, and the basic text of the 
relationship sounds like a free-for-all to link to individual articles, 
which I don't think would be a good idea. Which is it?


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.


Chad

On 28/02/2010 3:45 p.m., Brian Schweitzer wrote:
The same had occurred to me, though I'm not 100% decided if such a 
potentally large list of URLs would be a good or bad thing; I could 
see it almost becoming some sort of fodder for a future "news about 
artists I'm subscribed to" rss feed.  The origin of this AR was in 
last week's dev meeting, where Rob was asking about adding an AR for 
links to The Guardian.  I've cut out the more un-related bits; here's 
the relevant part of the discussion which led to this RFC:


20:48:50  ruaok   the Guardian would like to have MB link to its 
"tag" pages:

20:49:02  ruaok http://www.guardian.co.uk/music/thebeatles
20:49:16  ruaok   what are your thoughts for adding a new AR type 
for this?

20:49:29  aCiD2   what would be the type?
20:50:00  ruaok   I hadn't explored that yet.
20:50:09  ruaok   "has guardian acticles at" ?
20:50:13  ruaok   *articles
20:51:25  nikki   I would probably just say has a guardian.co.uk 
 page at

20:51:45  ruaok   nikki: +1
20:52:08  ijabz   +1
20:52:10  ruaok   any objections to the general concept of linking 
to the guardian, tho?
20:52:22  navap   Is guardian.co.uk  a 
physical newspaper as well?

20:52:25  nikki   yes
20:52:27  ruaok   yes
20:52:35  ruaok   a respected one at that.
20:52:37  navap   And they call themselves "guardian.co.uk 
"?

20:52:38  ruaok   not a tabloid
20:52:41  brianfreud  Only in so far as who *don't* we link to
20:52:47  warpruaok: what value does it provide for our users?
20:52:49  ijabz   no, they are quite similar to the bbc in some ways
20:52:54  ruaok   no, "The Guardian"
20:53:02  ruaok   warp: more links to find info about bands.
20:53:15  ruaok   if someone wanted to search for new articles 
relating to our artists.
20:53:18  navap   ruaok: I'm surprised they don't call themselves 
The Guardian on their site as well.
20:53:23  warpruaok: sure, but what is the data at the end of 
the link?

20:53:42  ruaok   links to articles relating to that band.
20:53:46  ruaok   not structured data.
20:54:00  navap   Are they linking back to us from that /music/ page?
20:54:06  navap   (Or any other page)
20:54:10  warpruaok: articles written by the guardian?
20:54:13  ruaok   the plan to.
20:54:15  brianfreud  ruaok: Could that be generalized to "has press 
coverage", or some such? Thinking Rolling Stone, Washington Post, San 
Fran Chron, New York Times, Paris Match, etc

20:54:23  ruaok   warp: only articles written by the guardian.
20:54:32  ruaok   brianfreud: thats good. I like.
20:54:41  ijabz   They are way ahead of other uk newspapers wrt 
their internet presence
20:55:03  ruaok   and their information architect contacted us 
directly.

20:55:05  warpbrianfreud: +1 :)
20:55:23  ruaok   I'm keen to make this happen. I have the same 
respect for the guardian as I do the for the BBC.
20:55:24  navap   Where do we draw the line? (Do we draw a line?) 
Between which newspapers we link to and which we don't?
20:56:01  ruaok   with the general new coverage link our users and 
reviewers make the decision.
20:56:04  brianfreud  that's going to be the crux of debate about 
adding the AR on the style list /me reads the future

20:56:09  ruaok   which works well for me. more power to the users!
20:57:01  ruaok   I'll make the proposal page for it. I think this 
idea has merit.
20:57:14  nikki   I quite like the idea of linking to stuff, 
'cause then we have lots of structured links to places and people will 
be like "oooh" and want to use our data, instead of, say, wikipedia's 
where you have to magically figure out what each link actually is

20:57:30  ruaok   +10 nikki
20:57:48  ruaok   I think adding more links to known good 
resources is a good idea.
20:58:01  ruaok   esp if the trusted new sources are willing to do 
this for us.
20:58:41  navap   So perhaps our current system of entity-url 
links needs modernizing? Maybe something that can scale better if/when 
we start linking to more and more sites?

(at this point the discussion moved away from this AR)

On Sun, Feb 28, 2010 at 2:33 AM, Chad Wilson > wrote:


I think this needs to be properly clarified as to its intention.
People will start adding links to individua

Re: [mb-style] RFC: Extend the Has Lyrics At AR to artists

[Atedos]

Single artist page on LyricWiki may belong to several artists, I don't think
it's a good idea.

2010/2/28 Brian Schweitzer 

> Sorry, that should read Sunday, 2010-03-07.
>
> On Sun, Feb 28, 2010 at 2:12 AM, Brian Schweitzer <
> brian.brianschweit...@gmail.com> wrote:
>
>> Currently, the Has Lyrics At AR allows only release-URL and track-URL
>> links to lyrics.wikia.com.  This RFC would extend the AR to also allow
>> artist-URL links, such as linking http://lyrics.wikia.com/Tori_Amos to
>> the Tori Amos listing.
>>
>> This RFC is RFC-90, and has a proposal page at
>> http://wiki.musicbrainz.org/User:BrianSchweitzer/HasLyricsAtExtentionProposal.
>>   Without objection, this RFC will move to RFV on Sunday, 2010-03-10.
>>
>> Thanks,
>> Brian
>>
>
>
> ___
> 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