Re: [mb-style] RFC: Dealing with translations and transliterations

2006-06-16 Thread Nikki
On Fri, Jun 16, 2006 at 01:23:00AM +0200, derGraph wrote:
 So could anyone please summarize this? Is there more than a request for a
 transliteration AR (which by the proposed guidelines doesn't create
 clusters) and a comment on a roadmap?

Basically, yes. The overall thread so far has been that:

* We should create a transliteration/translation relationship so that we
  have the ability to link 'virtual' releases together.
* We should have an 'official' and 'unofficial' attribute because some
  transliterations/translations are officially released, and therefore
  deserve separate entries.
* We can avoid the majority of relationship clusters by linking to the
  official release in the artist's native language (presumably in their
  usual country of release).

Expanding on the last point, there will still be some cases where clusters
would be possible, but focusing on those is silly. We currently have
thousands of transliterations which are lacking a relationship because a
handful of examples (which, in some cases, are just theoretical) are tricky
to handle.

--Nikki

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


Re: [mb-style] RFC: Dealing with translations and transliterations

2006-06-16 Thread Simon Reinhardt

Nikki wrote:

Basically, yes. The overall thread so far has been that:


Some points to add:
Dustin exhaustively tried to state why we *should* allow virtual duplicates - 
which I think was unnecessary because everyone who still wants to argue against 
that is a bit out of reality. ;)
Also it was said that we might want to make use of this relationship for 
displaying duplicate releases together with the official ones (?) and let all 
changes to one of the releases (except the titles) reflect on the other ones 
automatically. I'd like to see more concrete plans for that.


* We can avoid the majority of relationship clusters by linking to the
  official release in the artist's native language (presumably in their
  usual country of release).


This point is a bit hazy to me. What about cases where the official release of a Japanese band is 
in English/Latin and someone creates a virtual Japanese/Kana duplicate? Artist's native 
language is problematic in my eyes. Of course you could say the English/Latin one is the 
official release and therefore everything links there. But what if there are several official ones 
of which none can be seen as most native?
This might sound theoretically but I think identifying the main release can 
be problematic.


Expanding on the last point, there will still be some cases where clusters
would be possible, but focusing on those is silly. We currently have
thousands of transliterations which are lacking a relationship because a
handful of examples (which, in some cases, are just theoretical) are tricky
to handle.


I would like to hear more about those tricky examples. :)
I guess they have been discussed to death before... sorry, didn't read the 
other threads.

Simon (Shepard)

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


Re: [mb-style] RFV: Adding some AR attributes

2006-06-16 Thread Schika

On 6/14/06, Chris Bransden [EMAIL PROTECTED] wrote:


 Note that the following discussion arose from this: Schika had examples of 
liner notes which differentiate between a mixer and a mix engineer. Do we need 
that separated?

well i think you have to be careful as the example (system 7) might
mean DJMix when they say Mixed By and Mixed By where they say Mix
Engineer. if anyone can find an example where that's definitely not
the case then it's probably worth adding seperately.


It's definetly not a DJ-Mix here. The mentioned track On the Seventh
Night with that credits appears on the album 777 (Label: Big Life
Records / Weird and Unconventional Records - Catalog #: BFLLP1)
http://www.discogs.com/release/19794 (is the entry matching the Catalog #)

Also not DJMixed ...

Same group another album Point 3 - Fire Album (Label: Big Life
Records / Butterfly Records - Catalog #: BFLLA11):
B1 - Mysterious Traveller:  Produced by Derrick May  Steve Hillage.
Engineered  Additional Production by Greg Hunter. Keyboards 
Programming by Derrick May. Guitars by Steve Hillage. Additional
Keyboards by Miquette Giraudy. Mixed by Steve Hillage  Miquette
Giraudy. Mix Engineered by Matt Rowland.

A2 has also credits for Mixed by and Mix Engineered by

http://www.discogs.com/release/89959  (is the entry matching the Catalog #)

Maybe someone has the CD versions which probably have more detailed
credits, as the vinyls I currently holding in my hands.

Sorry that I currently bring up examples from only one band - cause
I've tried to enter the credits for their records some time ago and
figured out that ARs are missing.
I'm sure that I will come accross more of such credits - if I have the
time to enter a whole set again.



Of course since we don't have freetext crediting like Discogs we can only render liner notes to a 
certain extent and I'd normally say try to find those types which are nearest to what they really 
did - but since in most of the cases we can't know what they really did, we can only go with the 
liner notes for those smaller roles and therefore I also prefer to see it as close to the liner 
notes as possible. That does not apply for all AR types though - in some cases you *can* know what 
the credited persons really did. For example liner notes for rock albums mostly say guitars 
by ..., bass by ... where they mean electric guitar and electric bass guitar. Of course it's 
not wrong to let it as guitars as those are generalisations.


i agree. i'd still like to have free-text qualifiers (pipe dream...),
for the occasions when a new AR isn't appropriate, but it's still nice
to show the written credit as well as the actual role - eg
http://www.discogs.com/release/535757 (look at some of those
convoluted track credits!)


The mentioned free-text field would be awesome for such rare credits
- instead of adding more to the current list.

BTW great example. :)

--
.: NOP AND NIL :.
.: Schika :.

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


Re: [mb-style] RFC: Dealing with translations and transliterations

2006-06-16 Thread Nikki
On Fri, Jun 16, 2006 at 02:01:29PM +0200, Simon Reinhardt wrote:
 This point is a bit hazy to me.

Feel free to rephrase it.

 What about cases where the official release of a Japanese band is in
 English/Latin and someone creates a virtual Japanese/Kana duplicate?

Then the Japanese/Kana version isn't an official track listing and thus
doesn't count in the versions we can choose from!

 But what if there are several official ones of which none can be seen as
 most native?

Example? Last time the discussion died because people brought up
theoretical problems which, as I said, doesn't do anything for the *real*
cases we have. Anyway, these are only guidelines. We can't possibly cater
for every single case. If someone comes along and finds it hard to apply
the guideline to the data, they're free to work out what *does* work (and
that applies to all of the guidelines). I'm merely giving something which
works for nearly all the cases we have already.

 I would like to hear more about those tricky examples. :)

The only one I'm really at all familiar with is China Dolls [1]. They're a
duo from Thailand, one is half Chinese, one is half Taiwanese. They have
official releases in Thai, Chinese and Japanese. If two of these happen to
share the same songs in the same order, there would be two official
versions which the transliterations and translations could link to. It's
all theoretical because I don't even know if two releases share the exact
same songs in the same order. We only have 4 distinct albums (plus 1
transliteration) for them anyway, so all the possible transliterations and
translations are just some sort of straw man or something.

--Nikki

1 http://musicbrainz.org/artist/db695488-b587-4349-8aa1-da3ab8a5f0ff.html


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


Re: [mb-style] RFC: new renamed to AR type

2006-06-16 Thread derGraph

derGraph wrote:

Simon Reinhardt wrote:
I must admit it was a bit hot when I wrote that and after it I 
thought: hmmm.. that's all bullshit. I think you're right, one 
general type probably won't work. I have a real life example for you:


I just thought about other real-life examples when I had another idea: 
we might have a renamed AR with a split option like

 [artist] {split:split and thereafter} renamed to [artist]
Yet, I wouldn't know a reverse phrase right now,


Maybe something like
[artist] renamed {split:after a split} to [artist]?
Sorry, grammar, but what else could I do? ;-)



What do you think?

It's definitly not a renaming. Could one say Shaaman is a successor 
of Angra?


Since there is only one band member in both bands, I wouldn't say so. 


I would suggest to use this AR only if larger parts of the older band 
were also band members after the name change and vice versa. If only one 
or two band members founded or joined a new band, i.e. there were larger 
lineup changes, MemberOfBandRelationshipType should be enough to 
(indirectly) link the bands.


--

derGraph


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


Re: [mb-style] RFC: Dealing with translations and transliterations

2006-06-16 Thread derGraph

Nikki wrote:

Expanding on the last point, there will still be some cases where clusters
would be possible, but focusing on those is silly. We currently have
thousands of transliterations which are lacking a relationship because a
handful of examples (which, in some cases, are just theoretical) are tricky
to handle.


If it works for the majority of cases, or maybe even for all but very 
few, I'd say we should go ahead!


--

derGraph

PS: Thanks for the summary!


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


[mb-style] Net Releases

2006-06-16 Thread joan WHITTAKER
First of all let me make it clear that I am not talking about music released 
through iTunes, Napster or similar, which invariably are commercial 
releases, available in most retail stores, being released on the net.




What I would like to get a consensus of opinion on is those releases which 
are intended for release on the net and will only ever be released in this 
format.




There is a school of thought which says that by virtue of the fact that it 
is released on the web, then it is a worldwide release and, therefore, 
available to everyone who has access to the internet.




Another school of thought is that it is released in the country in which the 
record label or host server is situated.  Using this argument, if the host 
label is in the USA, then that release is USA.  If elsewhere, then that 
country takes precedence.




Now, I am not trying to appear facetious, but using this argument, we could 
have a long string of release dates, such as:




Release Date: USA 1.1.2006

UK 1.1.2006

Germany 1.1.2006

France 1.1.2006

Japan 1.1.2006

And all would be correct under present guidelines.



However, my argument is that if a piece of music is released on the 
internet, then the intention is that it is equally available to all users of 
the internet, and that to me means worldwide, notwithstanding the fact 
that the originator may be USA or UK based.  That is irrelevant.  Indeed, 
the fact that the label is based in a specific country can be referred to in 
an annotation.




With the advent of more and more music being released only on the internet, 
we need to formulate a policy to deal with them and not leave it to chance. 
May I have your thoughts on this please?




Joan
BEGIN:VCARD
VERSION:2.1
N:Whittaker;Joan
FN:Joan Whittaker
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:20060617T001658Z
END:VCARD
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Net Releases

2006-06-16 Thread Schika

Whatever the artist/label/distributor of the release says should be
used. If they state it should be Germany, Europe or Worldwide
then we have to respect that. They are the owners of the rights and
they decide how their data has to be.
--
.: NOP AND NIL :.
.: Schika :.

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


Re: [mb-style] Net Releases

2006-06-16 Thread Nikki
On Sat, Jun 17, 2006 at 02:46:30AM +0200, Schika wrote:
 Whatever the artist/label/distributor of the release says should be used.
 If they state it should be Germany, Europe or Worldwide then we
 have to respect that. They are the owners of the rights and they decide
 how their data has to be.

What about all the ones which don't say?

--Nikki

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


Re: [mb-style] Net Releases

2006-06-16 Thread Schika

On 6/17/06, Nikki [EMAIL PROTECTED] wrote:

On Sat, Jun 17, 2006 at 02:46:30AM +0200, Schika wrote:
 Whatever the artist/label/distributor of the release says should be used.
 If they state it should be Germany, Europe or Worldwide then we
 have to respect that. They are the owners of the rights and they decide
 how their data has to be.

What about all the ones which don't say?

--Nikki


If a label is known, then the country where it's based (if it's known).
If a label is known but not where it's based - or nothing at all is
currently known - Unknown Country.


--
.: NOP AND NIL :.
.: Schika :.

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


RE: [mb-style] Net Releases

2006-06-16 Thread Beth
So virtually it appears as if you feel [worldwide] should be deleted
altogether? Or only used when the band says Everywhere else? (which I've
seen one band that says that.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Schika
Sent: Friday, June 16, 2006 7:30 PM
To: MusicBrainz style discussion
Subject: Re: [mb-style] Net Releases

On 6/17/06, Nikki [EMAIL PROTECTED] wrote:
 On Sat, Jun 17, 2006 at 02:46:30AM +0200, Schika wrote:
  Whatever the artist/label/distributor of the release says should be
used.
  If they state it should be Germany, Europe or Worldwide then we
  have to respect that. They are the owners of the rights and they decide
  how their data has to be.

 What about all the ones which don't say?

 --Nikki

If a label is known, then the country where it's based (if it's known).
If a label is known but not where it's based - or nothing at all is
currently known - Unknown Country.


-- 
.: NOP AND NIL :.
.: Schika :.

___
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] Net Releases

2006-06-16 Thread Schika

On 6/17/06, Beth [EMAIL PROTECTED] wrote:

So virtually it appears as if you feel [worldwide] should be deleted
altogether? Or only used when the band says Everywhere else? (which I've
seen one band that says that.


No, I'm against a deletion of [Worldwide].
I say that [Worldwide] should be used when it is mentioned that it is
a worldwide release. I've seen that also from
artists/bands/labels/distributors.

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