Re: [mb-style] RFC STYLE-276: Remove attributes from the performing orchestra relationship

[Ben Ockmore]

+1 from me!
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Pre-RFC: Make instruments entities

[Rachel Dwight]

Would specific instrument makes and models have to be implemented as aliases?

Sent from my iPhone

> On Jan 2, 2014, at 1:03 PM, "Frederik \"Freso\" S. Olesen" 
>  wrote:
> 
> Den 02-01-2014 15:02, Frederic Da Vitoria skrev:
>> I don't know where what is the current situation about languages in the
>> DB. If it is far from handling languages correctly, and if instrument
>> entities are implemented before languages, we could temporarily restrict
>> the instrument language to English. English is the language currently
>> used for the instrument tree, and it is probably the language which has
>> the most instruments translated into it.
> 
> "Languages" are already implemented and several site translations are
> well underway. We agreed at the summit to open up for the German
> translation on the main site. I don't know why that's not happened yet.
> 
> If(/when) instrument-as-entities are added, we'll be able to fully
> utilise the power of the alias and disambiguation systems. Two
> instruments called the same can have disambiguation notes. One
> instrument called different things in different languages can have
> localised aliases. One instrument called multiple things in one language
> can have multiple (localised) aliases. E.g., "viola" could have the
> French primary alias "alto", the Danish primary alias "bratsch", and an
> additional Danish alias "viola". The search system also takes aliases
> into account, so searching for either viola, alto, or bratsch would make
> this instrument show up in the results.
> 
> Whether we're currently "handling languages correctly" is probably
> rather debatable though. I'd say no, but I think we need some more
> wide-spread testing (e.g., get some non-English languages enabled on
> mb.o) allowing users to get a feel for what needs to be handled differently.
> 
> -- 
> Namasté,
> Frederik "Freso" S. Olesen 
> MB:   https://musicbrainz.org/user/Freso
> Wiki: https://wiki.musicbrainz.org/User:Freso
> 
> ___
> 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] Pre-RFC: Make instruments entities

[Frederik "Freso" S. Olesen]

Den 02-01-2014 15:02, Frederic Da Vitoria skrev:
> I don't know where what is the current situation about languages in the
> DB. If it is far from handling languages correctly, and if instrument
> entities are implemented before languages, we could temporarily restrict
> the instrument language to English. English is the language currently
> used for the instrument tree, and it is probably the language which has
> the most instruments translated into it.

"Languages" are already implemented and several site translations are
well underway. We agreed at the summit to open up for the German
translation on the main site. I don't know why that's not happened yet.

If(/when) instrument-as-entities are added, we'll be able to fully
utilise the power of the alias and disambiguation systems. Two
instruments called the same can have disambiguation notes. One
instrument called different things in different languages can have
localised aliases. One instrument called multiple things in one language
can have multiple (localised) aliases. E.g., "viola" could have the
French primary alias "alto", the Danish primary alias "bratsch", and an
additional Danish alias "viola". The search system also takes aliases
into account, so searching for either viola, alto, or bratsch would make
this instrument show up in the results.

Whether we're currently "handling languages correctly" is probably
rather debatable though. I'd say no, but I think we need some more
wide-spread testing (e.g., get some non-English languages enabled on
mb.o) allowing users to get a feel for what needs to be handled differently.

-- 
Namasté,
Frederik "Freso" S. Olesen 
MB:   https://musicbrainz.org/user/Freso
Wiki: https://wiki.musicbrainz.org/User:Freso



signature.asc
Description: OpenPGP digital signature
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Pre-RFC: Make instruments entities

[Frederik "Freso" S. Olesen]

Den 02-01-2014 13:44, Ben Ockmore skrev:
> For instruments, the user would enter an instrument name into a free
> text field, and this would be searched for among existing instrument
> entities. If it's not found, then the user can proceed to use their entry.
> 
> If other users enter the same name, then after a certain number of
> submissions, by multiple users, the name would automatically get
> promoted to an entity, and all matching relationships would be updated
> to use this new entity. Users could then merge or add relationships to
> the instrument just like a normal entity.

I voiced this at the summit as well, but I only think this approach is
sound if that "certain number" is 1. If I add an instrument, I'll likely
want to be able to store translations/aliases and link it to external
sites immediately - instead of waiting for any number of other people to
use the instrument. (Working in niche genres often lead you to have
niche instruments.) If there's some way to add aliases/translations and
links to the instrument before it's an entity... then how is it not an
entity already?

Anyway. I'm not sure this is the place for that discussion. +1 to the
"proposal", though I wasn't aware if was something needing RFC'ing. :)

-- 
Namasté,
Frederik "Freso" S. Olesen 
MB:   https://musicbrainz.org/user/Freso
Wiki: https://wiki.musicbrainz.org/User:Freso



signature.asc
Description: OpenPGP digital signature
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC STYLE-227 Add new artist type "Character"

[Frederik "Freso" S. Olesen]

Den 30-12-2013 20:27, Calvin Walton skrev:
> A minor update: hawke spotted a wording issue in the Style/Artist page
> relating to character gender.

Looks well thought out and makes sense to me, but I'm not deeply into
the intricacies of this subject.

+0.5

-- 
Namasté,
Frederik "Freso" S. Olesen 
MB:   https://musicbrainz.org/user/Freso
Wiki: https://wiki.musicbrainz.org/User:Freso



signature.asc
Description: OpenPGP digital signature
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC STYLE-227 Add new artist type "Character"

[Alex Mauer]

On 12/30/2013 01:27 PM, Calvin Walton wrote:
> A minor update: hawke spotted a wording issue in the Style/Artist page
> relating to character gender.
> 

With that change: +1

I also prefer the proposed 'fictional' attribute, but this is a good
start, and will allow an automated transition if/when we get that.

I’m also not a big fan of the 'created' start date (I’d prefer the
fictional birth date), but I can live with it.


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

Re: [mb-style] RFC STYLE-227 Add new artist type "Character"

[Frederik "Freso" S. Olesen]

Den 02-01-2014 15:07, jesus2099 skrev:
> IMO we will loose time with temporary devs.
> We have plenty of pedning bug fix or feeature request that could be not
> temporary instead… :)

How do we lose time exactly? Adding a new a artist type *require* no
developer time (ie., Rob/Ian/bitmap do not have to get involved) and as
such does not take any time away from the development of the schema
change required for a new attribute such as "fictional".

Also, such schema changes can only happen twice a year: May and October.
If it isn't done by May this year, it cannot happen before October. If
it also misses the October 2014 (almost wrote 13 there - I hate new
years :p) mark, then it's not going happen in 2014 at all. kepstin's
proposal can be implemented *right now* (or, well, in around a week if
the RFC goes through).
As a few have already pointed out, this would also mean that there's
already information in the database to make an automated transition to
whatever system, "fictional" attribute or other, is implemented. This
will save editor time as characters are entered into the database from
now and until the schema change has gone through since they won't have
to set the attribute then but could be set as "Character" right off the
bat. Would also enable editors *now* to fix up "Characters" making them
ready for a transition.

TL;DR: I cannot see how this RFC causes time to be lost (except for
people -1'ing it on vague accounts) - au contraire, as far as I can
tell, it will *save* editor time.

-- 
Namasté,
Frederik "Freso" S. Olesen 
MB:   https://musicbrainz.org/user/Freso
Wiki: https://wiki.musicbrainz.org/User:Freso



signature.asc
Description: OpenPGP digital signature
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC STYLE-279: Add "Place of Worship" as place type

[Frederik "Freso" S. Olesen]

Den 02-01-2014 12:30, Frederic Da Vitoria skrev:
> I may be wrong, but I don't think a
> user will one day need an easy way to select together the cathedrals and
> the Buddhist temples.

If you can think of it, chances are someone will want to be able to do
just that some time in the future. We should not hinder this.

However, interlinking with other sources (Wikidata, OSM, etc.) so that
it is possible to cross-reference against those will likely be the way
to achieve such a goal, making a further division unneeded.

That said, I give this RFC a -0. (The minus is mostly due to the
wording, as Ben mentioned, religious places might not necessarily be for
"worship" - but I guess there's not much difference between -0 and +0
anyway. :))

-- 
Namasté,
Frederik "Freso" S. Olesen 
MB:   https://musicbrainz.org/user/Freso
Wiki: https://wiki.musicbrainz.org/User:Freso



signature.asc
Description: OpenPGP digital signature
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC STYLE-279: Add "Place of Worship" as place type

[Frederic Da Vitoria]

2014/1/2 caller#6 

>  On 01/02/2014 07:58 AM, Frederic Da Vitoria wrote:
>
>  2014/1/2 caller#6 
>
>>
>>  I'm not sure what makes a church (or stadium) "other". Maybe it's a
>> translation thing? To me, a church is as much a venue as anything.
>>
>
>  From https://musicbrainz.org/doc/Place :
>
>> A place that has live artistic performances as one of its primary
>> functions, such as a concert hall or multi-purpose arena.
>
>
> Aha! Thanks :-)
>
> That definition is much more narrow than the casual English word.
>

I don't know English well enough to have an opinion about this :-/

-- 
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 STYLE-279: Add "Place of Worship" as place type

[Frederic Da Vitoria]

2014/1/2 Alex Mauer 

> On 01/02/2014 09:58 AM, Frederic Da Vitoria wrote:
> > A place that has live artistic performances as one of its primary
> > functions, such as a concert hall or multi-purpose arena.
>
> Is that not the case for churches?
>
> They may not be musical (though music is often included!) but I would
> count services and/or sermons as “live artistic performances”.
>
> I bet we even have some in the database…
>
> I don’t see a need for a separate place type for these, but I don’t mind
> it either


I hadn't thought of that :-D

Yes you are right, one could consider those as art. But I am not convinced
the Vatican would agree with you, art has often been viewed as something
quite questionable, at least in past times. So if the Artist's Intent is
that his work is not considered as art, can we consider it as art?

Just for the sake of argument, because obviously in the definition above
"artistic performance" meant anything recorded in MB.

-- 
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 STYLE-279: Add "Place of Worship" as place type

[Alex Mauer]

On 01/02/2014 09:58 AM, Frederic Da Vitoria wrote:
> A place that has live artistic performances as one of its primary
> functions, such as a concert hall or multi-purpose arena. 

Is that not the case for churches?

They may not be musical (though music is often included!) but I would
count services and/or sermons as “live artistic performances”.

I bet we even have some in the database…

I don’t see a need for a separate place type for these, but I don’t mind
it either.



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

Re: [mb-style] RFC STYLE-279: Add "Place of Worship" as place type

[caller#6]

On 01/02/2014 07:58 AM, Frederic Da Vitoria wrote:
2014/1/2 caller#6 >



I'm not sure what makes a church (or stadium) "other". Maybe it's
a translation thing? To me, a church is as much a venue as anything.


From https://musicbrainz.org/doc/Place :

A place that has live artistic performances as one of its primary
functions, such as a concert hall or multi-purpose arena. 



Aha! Thanks :-)

That definition is much more narrow than the casual English word.
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC STYLE-279: Add "Place of Worship" as place type

[Frederic Da Vitoria]

2014/1/2 caller#6 

>  On 01/02/2014 03:30 AM, Frederic Da Vitoria wrote:
>
>  2014/1/2 Ben Ockmore 
>
>>  Concert Hall
>> Community Building/Religious Building
>> Stadium
>> Club
>>  Arena
>> Outdoor Space
>> Theatre
>> Bandstand
>>
>>  Are all types that could be useful to have. I don't think we should
>> split categories based on acoustic properties here, since it's an attribute
>> of a place, and should go towards describing the type place, not its
>> acoustic properties. Acoustic properties can be modified, and vary
>> considerably between places of the same type (eg. sound baffles in concert
>> halls).
>>
>
>  I agree the acoustical properties of a place can be modified (although
> making a stadium sound like a real church would be tricky). But if you
> don't split them on acoustical properties, what useful types are left apart
> from those already existing? "Other" seems enough as it correctly describes
> churches. Splitting on the fact that a place is used or not for religion
> seems OT in MB IMO. I may be wrong, but I don't think a user will one day
> need an easy way to select together the cathedrals and the Buddhist
> temples. If not for acoustical reasons, why would we need to split Other?
>
>
> I'm not sure what makes a church (or stadium) "other". Maybe it's a
> translation thing? To me, a church is as much a venue as anything.
>
> It seems to me like finer granularity is better handled in wikidata or by
> some other authority (although I guess that only works for "notable"
> places, which could be a problem)
>

>From https://musicbrainz.org/doc/Place :

> A place that has live artistic performances as one of its primary
> functions, such as a concert hall or multi-purpose arena.


-- 
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 STYLE-279: Add "Place of Worship" as place type

[Nicolás Tamargo de Eguren]

On Thu, Jan 2, 2014 at 4:49 PM, caller#6 <
meatbyproduct-musicbra...@yahoo.com> wrote:

>  On 01/02/2014 03:30 AM, Frederic Da Vitoria wrote:
>
>  2014/1/2 Ben Ockmore 
>
>>  Concert Hall
>> Community Building/Religious Building
>> Stadium
>> Club
>>  Arena
>> Outdoor Space
>> Theatre
>> Bandstand
>>
>>  Are all types that could be useful to have. I don't think we should
>> split categories based on acoustic properties here, since it's an attribute
>> of a place, and should go towards describing the type place, not its
>> acoustic properties. Acoustic properties can be modified, and vary
>> considerably between places of the same type (eg. sound baffles in concert
>> halls).
>>
>
>  I agree the acoustical properties of a place can be modified (although
> making a stadium sound like a real church would be tricky). But if you
> don't split them on acoustical properties, what useful types are left apart
> from those already existing? "Other" seems enough as it correctly describes
> churches. Splitting on the fact that a place is used or not for religion
> seems OT in MB IMO. I may be wrong, but I don't think a user will one day
> need an easy way to select together the cathedrals and the Buddhist
> temples. If not for acoustical reasons, why would we need to split Other?
>
>
> I'm not sure what makes a church (or stadium) "other". Maybe it's a
> translation thing? To me, a church is as much a venue as anything.
>
> It seems to me like finer granularity is better handled in wikidata or by
> some other authority (although I guess that only works for "notable"
> places, which could be a problem).
>

For me something being a "venue" certainly implies its main purpose is
music - a church does feel very much not like a venue to me.
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC STYLE-279: Add "Place of Worship" as place type

[caller#6]

On 01/02/2014 03:30 AM, Frederic Da Vitoria wrote:

2014/1/2 Ben Ockmore mailto:ben.s...@gmail.com>>

Concert Hall
Community Building/Religious Building
Stadium
Club
Arena
Outdoor Space
Theatre
Bandstand

Are all types that could be useful to have. I don't think we
should split categories based on acoustic properties here, since
it's an attribute of a place, and should go towards describing the
type place, not its acoustic properties. Acoustic properties can
be modified, and vary considerably between places of the same type
(eg. sound baffles in concert halls).


I agree the acoustical properties of a place can be modified (although 
making a stadium sound like a real church would be tricky). But if you 
don't split them on acoustical properties, what useful types are left 
apart from those already existing? "Other" seems enough as it 
correctly describes churches. Splitting on the fact that a place is 
used or not for religion seems OT in MB IMO. I may be wrong, but I 
don't think a user will one day need an easy way to select together 
the cathedrals and the Buddhist temples. If not for acoustical 
reasons, why would we need to split Other?




I'm not sure what makes a church (or stadium) "other". Maybe it's a 
translation thing? To me, a church is as much a venue as anything.


It seems to me like finer granularity is better handled in wikidata or 
by some other authority (although I guess that only works for "notable" 
places, which could be a problem).


Alex / caller#6
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC STYLE-227 Add new artist type "Character"

[Frederic Da Vitoria]

2014/1/2 jesus2099 

> IMO we will loose time with temporary devs.
> We have plenty of pedning bug fix or feeature request that could be not
> temporary instead… :)
>

Then how do you suggest characters should be entered in the meanwhile?

-- 
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 STYLE-279: Add "Place of Worship" as place type

[jesus2099]

Having lots of non musical place types will deserve no useful purpose imo,
off topic in MB.
I put all non-studios in VENUES but now that I know there is OTHER, I think
all non primmary music places should simply be OTHER indeed.
Having lots of types I would not know which one to pick. :)



-
 PATATE12  
 jesus2099  
 GOLD MASTER KING 
 FAKE E-MAIL ADDRESS 
--
View this message in context: 
http://musicbrainz.1054305.n4.nabble.com/RFC-STYLE-279-Add-Place-of-Worship-as-place-type-tp4660918p4660979.html
Sent from the MusicBrainz - Style mailing list archive at Nabble.com.

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

Re: [mb-style] Pre-RFC: Make instruments entities

[Frederic Da Vitoria]

2014/1/2 Ben Ockmore 

> I think it would be helpful if we allow Instruments to have images, and
> use these in search results to show graphically what each of the
> suggestions looks like.
>
> All of your ideas for language selection/detection are good. Perhaps we
> could also use the site language that the user is using (once that moves
> from beta to the main site).
>

Yes, images would definitely be useful !

I don't know where what is the current situation about languages in the DB.
If it is far from handling languages correctly, and if instrument entities
are implemented before languages, we could temporarily restrict the
instrument language to English. English is the language currently used for
the instrument tree, and it is probably the language which has the most
instruments translated into it.

-- 
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 STYLE-227 Add new artist type "Character"

[jesus2099]

IMO we will loose time with temporary devs.
We have plenty of pedning bug fix or feeature request that could be not
temporary instead… :)



-
 PATATE12  
 jesus2099  
 GOLD MASTER KING 
 FAKE E-MAIL ADDRESS 
--
View this message in context: 
http://musicbrainz.1054305.n4.nabble.com/RFC-STYLE-227-Add-new-artist-type-Character-tp4660856p4660978.html
Sent from the MusicBrainz - Style mailing list archive at Nabble.com.

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

Re: [mb-style] Pre-RFC: Make instruments entities

[Ben Ockmore]

I think it would be helpful if we allow Instruments to have images, and use
these in search results to show graphically what each of the suggestions
looks like.

All of your ideas for language selection/detection are good. Perhaps we
could also use the site language that the user is using (once that moves
from beta to the main site).
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Pre-RFC: Make instruments entities

[Frederic Da Vitoria]

2014/1/2 Ben Ockmore 

> Of course, there wouldn't be an instrument -> ID3 genre mapping! That part
> applies to genres only. :P
>
> For instruments, the user would enter an instrument name into a free text
> field, and this would be searched for among existing instrument entities.
> If it's not found, then the user can proceed to use their entry.
>
> If other users enter the same name, then after a certain number of
> submissions, by multiple users, the name would automatically get promoted
> to an entity, and all matching relationships would be updated to use this
> new entity. Users could then merge or add relationships to the instrument
> just like a normal entity.
>
> So basically, +1 for making instruments entities, but I'd like to see a
> more fluid and controlled way of creating them (rather than any old person
> coming along and adding an instrument with an edit, which may or may not be
> voted on by other editors). I don't want to limit editing instruments to a
> group of "Instrument Editors" though, because IMO that sort of system is
> elitist and discourages contribution.
>

Then we need the language to be handled in some way. Else this will become
a nightmare, with the instruments written in a language/script that few
users know/are able to check, and the false friends (I guess most users who
know French know that the English "viola" is the same as the French
"alto"). It also should be able to handle homonyms (in French the same word
designates the alto (viola) and the alto (voice)). If we go this way, it is
going to be tricky. But interesting :-)

When I stated first that "we need the language to be handled in some way",
I meant that
- if a user enters for example "alto" and the word is NOT already known,
the MB UI should ask the user which language.
- if a user enters for example "alto" and the word is already known in
several languages, the MB UI should detect that in different languages it
has different meanings and should tell the user so, offer him to pick the
meaning really intended or create one if needed.
- if a user enters for example "alto" and the word is already known in only
one language, the MB UI should tell the user so, offer him to pick this
meaning if it the one really intended or create one new language/meaning if
needed.

We could of course state that the language should for example be the
Release's language, but this would still possibly generate bad edits for
multi-language releases. Also, a user could for example buy a French
release, but find the specific instruments on a German site. So that I
believe that the instrument input language should remain user-modifiable.

-- 
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] Pre-RFC: Make instruments entities

[Ben Ockmore]

Of course, there wouldn't be an instrument -> ID3 genre mapping! That part
applies to genres only. :P

For instruments, the user would enter an instrument name into a free text
field, and this would be searched for among existing instrument entities.
If it's not found, then the user can proceed to use their entry.

If other users enter the same name, then after a certain number of
submissions, by multiple users, the name would automatically get promoted
to an entity, and all matching relationships would be updated to use this
new entity. Users could then merge or add relationships to the instrument
just like a normal entity.

So basically, +1 for making instruments entities, but I'd like to see a
more fluid and controlled way of creating them (rather than any old person
coming along and adding an instrument with an edit, which may or may not be
voted on by other editors). I don't want to limit editing instruments to a
group of "Instrument Editors" though, because IMO that sort of system is
elitist and discourages contribution.
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC STYLE-279: Add "Place of Worship" as place type

[Frederic Da Vitoria]

2014/1/2 Ben Ockmore 

> Concert Hall
> Community Building/Religious Building
> Stadium
> Club
> Arena
> Outdoor Space
> Theatre
> Bandstand
>
> Are all types that could be useful to have. I don't think we should split
> categories based on acoustic properties here, since it's an attribute of a
> place, and should go towards describing the type place, not its acoustic
> properties. Acoustic properties can be modified, and vary considerably
> between places of the same type (eg. sound baffles in concert halls).
>

I agree the acoustical properties of a place can be modified (although
making a stadium sound like a real church would be tricky). But if you
don't split them on acoustical properties, what useful types are left apart
from those already existing? "Other" seems enough as it correctly describes
churches. Splitting on the fact that a place is used or not for religion
seems OT in MB IMO. I may be wrong, but I don't think a user will one day
need an easy way to select together the cathedrals and the Buddhist
temples. If not for acoustical reasons, why would we need to split Other?

-- 
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 STYLE-279: Add "Place of Worship" as place type

[Ben Ockmore]

Concert Hall
Community Building/Religious Building
Stadium
Club
Arena
Outdoor Space
Theatre
Bandstand

Are all types that could be useful to have. I don't think we should split
categories based on acoustic properties here, since it's an attribute of a
place, and should go towards describing the type place, not its acoustic
properties. Acoustic properties can be modified, and vary considerably
between places of the same type (eg. sound baffles in concert halls).
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Pre-RFC: Make instruments entities

[Frederic Da Vitoria]

2014/1/1 Ben Ockmore 

> I still think that similar systems should be used for Genres and
> Instruments (seeing as they're both tree-based systems), so I'd like to
> wait until the developer decide on how they'll tackle Genres before
> anything happens with instruments.
>
> What I'd like to see if both Instruments and Genres as entities, which
> aren't created by a formal "add" process, but are formed from tags/words
> entered by users - a "bottom-up" approach, where user input decides what
> instruments and genres should be in the system. I've written this down
> here, and we talked about it a little at the last summit, but didn't agree
> on anything:
> https://docs.google.com/document/d/1fRfpALAX5D0RAjF7upbPcaAR70OIsQk1jNOW5uuf5wQ/edit?usp=sharing
>

I think I understand your suggestion about genres, but I fail to see the
relation with instruments. Or rather, I feel instruments are sufficiently
different if not structurally, at least semantically, that they would need
to be studied separately. For example, I don't see when entering a tag
would trigger creating an instrument entity. Reference instruments should
be created manually too, because it is important to enter reference names.
And I don't think a simple number of occurrences should be enough for
creating an entity. If you set the limit at for example 50 occurrences
(which is much higher than our current limit for instruments), I can
perfectly imagine a user entering more than 50 times an instrument with the
same typo, thus creating a false instrument. At least for instruments, all
entity creations should be voted IMO.

I don't know much about id3 or itunes genres, but would the mapping between
an instrument and a genre work?

Also, I think it would be interesting to think how user language might
influence your idea. For example, in genres, sometimes exact translations
don't exist, and words which seem to be a translation actually mean
something different. So that it could be a good idea to create a set of
genres for each language, with a way to link (approximately) matching
genres between languages when possible. For example, I believe we Frenchies
use the words Pop and Rock differently from Americans (and probably from
English people too). OTOH, I don't think much translation issues would
appear for instruments.

-- 
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 STYLE-279: Add "Place of Worship" as place type

[Frederic Da Vitoria]

2014/1/2 Nicolás Tamargo de Eguren 

> On Thu, Jan 2, 2014 at 10:55 AM, jesus2099 wrote:
>
>> -1
>> I would prefer keeping simple VENUE for churches (rather than STUDIO).
>> I don’t think what important is the primary type of place.
>> IMO the important is the used type of place, whether VENUE or STUDIO.
>> where a VENUE place will contain more LIVE music recordings and STUDIO
>> places will include more recording sessions.
>
>
> That makes no sense - churches are used for lots of non-live classical
> recordings as well as for lives. If you only care about whether the
> recording is live, you have the attribute on the recording-work rel anyway.
>

Hm, obviously I missed a (perfectly valid) part of your point :-P

-- 
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 STYLE-279: Add "Place of Worship" as place type

[Nicolás Tamargo de Eguren]

On Thu, Jan 2, 2014 at 10:55 AM, jesus2099 wrote:

> -1
> I would prefer keeping simple VENUE for churches (rather than STUDIO).
> I don’t think what important is the primary type of place.
> IMO the important is the used type of place, whether VENUE or STUDIO.
> where a VENUE place will contain more LIVE music recordings and STUDIO
> places will include more recording sessions.


That makes no sense - churches are used for lots of non-live classical
recordings as well as for lives. If you only care about whether the
recording is live, you have the attribute on the recording-work rel anyway.

-- 
Nicolás Tamargo de Eguren
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC STYLE-227 Add new artist type "Character"

[Frederic Da Vitoria]

+1 as a temporary measure. I agree that Rachel's attribute would be better,
but waiting for the schema change means that in the meanwhile the data
can't be entered correctly, while a new type would probably be much quicker
to achieve and as Calvin wrote, the new type can be migrated when the
attribute is created.

I believe we should think in terms of improvement, not of perfection. Is
this an improvement? I think so. Is this the perfect solution? Probably
not, but it would be a step in the right direction.

-- 
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 STYLE-279: Add "Place of Worship" as place type

[Frederic Da Vitoria]

2014/1/2 jesus2099 

> -1
> I would prefer keeping simple VENUE for churches (rather than STUDIO).
> I don’t think what important is the primary type of place.
> IMO the important is the used type of place, whether VENUE or STUDIO.
> where a VENUE place will contain more LIVE music recordings and STUDIO
> places will include more recording sessions.
>

IIUC, Nicolás' point is that currently users for some reason don't use
Venue in this situation but Other, so that creating an explicit "Place of
Worship" would allow at least to collect them.

Maybe simply adding a hint the interface would be enough?

-- 
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 STYLE-227 Add new artist type "Character"

[jesus2099]

-1
*fictionnal* seems easier indeed.



-
 PATATE12  
 jesus2099  
 GOLD MASTER KING 
 FAKE E-MAIL ADDRESS 
--
View this message in context: 
http://musicbrainz.1054305.n4.nabble.com/RFC-STYLE-227-Add-new-artist-type-Character-tp4660856p4660961.html
Sent from the MusicBrainz - Style mailing list archive at Nabble.com.

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

Re: [mb-style] RFC STYLE-278: Add "Stadium/Arena" as place type

[jesus2099]

-1
I would prefer keeping simple VENUE for stadiums (rather than STUDIO).
I don’t think what important is the primary type of place.
IMO the important is the used type of place, whether VENUE or STUDIO.
where a VENUE place will contain more LIVE music recordings and STUDIO
places will include more recording sessions.

If we don’t stcik to this music oriented dichotomy, the list will be endless
with no real added value…



-
 PATATE12  
 jesus2099  
 GOLD MASTER KING 
 FAKE E-MAIL ADDRESS 
--
View this message in context: 
http://musicbrainz.1054305.n4.nabble.com/RFC-STYLE-278-Add-Stadium-Arena-as-place-type-tp4660920p4660960.html
Sent from the MusicBrainz - Style mailing list archive at Nabble.com.

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

Re: [mb-style] RFC STYLE-279: Add "Place of Worship" as place type

[jesus2099]

-1
I would prefer keeping simple VENUE for churches (rather than STUDIO).
I don’t think what important is the primary type of place.
IMO the important is the used type of place, whether VENUE or STUDIO.
where a VENUE place will contain more LIVE music recordings and STUDIO
places will include more recording sessions.



-
 PATATE12  
 jesus2099  
 GOLD MASTER KING 
 FAKE E-MAIL ADDRESS 
--
View this message in context: 
http://musicbrainz.1054305.n4.nabble.com/RFC-STYLE-279-Add-Place-of-Worship-as-place-type-tp4660918p4660959.html
Sent from the MusicBrainz - Style mailing list archive at Nabble.com.

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

Re: [mb-style] RFC STYLE-279: Add "Place of Worship" as place type

[Frederic Da Vitoria]

2014/1/2 caller#6 

>  On 01/01/2014 04:16 AM, Nicolás Tamargo de Eguren wrote:
>
> We have over 50 churches already, and with so much classical music being
> recorded in them it's only going to go up. Using "Other" for it when it's
> so obviously a type seems silly, so I'd like us to add it.
>
>  Ticket: http://tickets.musicbrainz.org/browse/STYLE-279
> Expected RFV date: Jan 8
>
>
> To me, "venue" is a generic term that covers pretty much anywhere music
> might be played for an audience (unless there's an audience in the studio
> during recording, I guess). It sounds like you're thinking of "venue" as
> being specifically clubs and theatres and those sorts of purpose-built
> places.
>
> I'm not sure finer granularity would improve what we already have.
>

"generic term that covers pretty much anywhere music might be played":
Isn't this precisely where we could do better? The acoustics of a church
(which weren't primarily built for music) are completely different from
those of a concert hall, as well as those of an open space such as a
stadium. I believe there is here something which MusicBrainz could take
into account. But I must confess (no pun intended) that I hadn't thought of
what "Place of Worship" could mean. Acoustically, an old Romanesque or
Gothic church does not sound like a small hall which could be used as a
"place of worship'.

Now if this RFC is to be taken literally, from a usage point of view
instead of an acoustical point of view, then I remove my +1. I wouldn't -1
either, I just wouldn't care.

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