Re: [mb-style] RFC-264: Add premiere-relationship between work and place
Den 30-10-2013 23:18, ListMyCDs.com skrev: On 30.10.2013 23:19, Frederik Freso S. Olesen wrote: A date for the première, but no information about where it happened. That sounds like an [unknown] place to me. Place might not be unknown just because artist doesn't mention it on her website. Note that my example was an entirely fictive one, meant to demonstrate a situation where no further information about that gig exists (or can be easily found). [unknown] should be last solution if information isn't available via regular channels. I don't think anyone disagrees with that or has argued otherwise... ? For artists there's [unknown] and [anonymous] clearly separating if artist is unknown to editor or unknown to everyone. The MB Artist [unknown] has also been used for storing mastering and other engineering dates (e.g., Recording Bazbar was mixed by [unknown] on 2005-05). If we only were to use [unknown] for stuff which is unknown to *everyone*, we could not ever use it, as *someone* out there might know. On the contrary, we use [unknown] when we cannot find a reliable source for who/what to use, but *someone* did do it. This could be the engineer of some Release or Recording, or it could be the Place of said engineering or recording. Or the première data of the Recording. (Since we can store the time of engineering with Artist-Recording relationships, if those are known, I think it would be a rare case (though it's probably out there...) where it would be better to AR the [unknown] Place to a Recording for engineering data rather than an [unknown] engineer.) -- Namasté, Frederik Freso S. Olesen http://freso.dk/ 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
Re: [mb-style] RFV: STYLE-248
Hi, What's the current status? @Frederik: I didn't see Rob in CC (unless it was in BCC). Kind regards Walter www.muzikum.eu 2013/10/19 Frederik Freso S. Olesen freso...@gmail.com Den 14-10-2013 15:24, muzikum mail skrev: Ticket link: http://tickets.musicbrainz.org/browse/STYLE-248 Expected expiration date: / Description: Dear, this is the RFV for the proposol to addhttp://muzikum.eu http://muzikum.eu/ to the lyrics sites whitelist for relations. No changes have been made since the RFC a month ago. Muzikum specialises in (but is not limited to) band info, discographies and lyrics from *Belgium*and *The Netherlands*. Our site is localized in English, Dutch, French, German, Italian and Spanish. We ask the bands, authors and labels for permission to publish their lyrics. Lyrics for those who object are blocked. All requests and the responses (ok or not ok) are shown on the various band-profile page. Examples: Publishing status ok: http://muzikum.eu/en/120-280/daan/biography.html Publishing status not ok: http://muzikum.eu/en/120-93/hooverphonic/biography.html Example of a blocked lyric: http://muzikum.eu/en/123-93-1030/hooverphonic/jackie-cane-lyrics.html http://muzikum.eu/en/123-93-1030/hooverphonic/jackie-cane-lyrics.html This has received no veto in 4 days since it was posted. CC'ing Rob for a final approval to pass or reject this proposal. -- Namasté, Frederik Freso S. Olesen http://freso.dk/ 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] RFC: STYLE-262, Place-URL has OSM at
2013/10/31 Sheamus Patt musicbrainz.r...@ncf.ca On 10/21/2013 10:54 AM, Alastair Porter wrote: http://tickets.musicbrainz.org/browse/STYLE-262 RFC expires October 28 Proposing a new URL relationship to link a Place to its details on openstreetmap. Hopefully pretty straightforward. If you can locate it on OpenStreetMap, then you know it's GPS co-ordinates which can be put into MB, And, if you have the GPS co-ordinates, you can easily construct the URL. E.g. http://www.openstreetmap.org?mlat=43.630704mlon= -79.415448http://www.openstreetmap.org?mlat=43.630704mlon=%20-79.415448 (locates Ontario Place, just an arbitrary place). So, why go through the trouble of adding URLs to all of the various places with specific locations, when we could just put a (locate this place) button into the UI which will take you there using the GPS co-ordinates? ... and storing directly the coordinates should allow to easily create another button to another similar website if ever we decide to. -- 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] [unknown] for places
On 31.10.2013 8:58, Frederik Freso S. Olesen wrote: If we only were to use [unknown] for stuff which is unknown to *everyone*, we could not ever use it, as *someone* out there might know. Nothing is certain. Still if printed 10-part music encyclopedia mentions unknown location its usually based on extensive research. wikipedia would also request me to add citations when adding information like that. In MusicBrainz it could be fine to enter the same information based on beliefs. [unknown] just tells that someone though it's unknown, maybe did some research or not, nothing more. Most of the people wouldn't vote on edits related to this because it would also reguire them to do extensive research. Problem is that extensive research without a definition has different meaning for everyone. Is didn't find it with google or artist doesn't mention it on his website enough? I'm not fully against of having [unknown] for places but without good guidelines it could be complete useless. Visitors and bots share this information as a fact and wrong information is spreading widely. I think we are also responsible of providing valid and factual data. ListMyCDs / Timo Martikainen ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] [unknown] for places
Just want to add my 2 cents on this topic. I also have no problem with having [unknown]. I also have no problem if someone doesn't do the research and puts it as [unknown] because: a.) Someone can go over later, do the research and change it. b.) I'd rather someone put unknown rather then guessing or finding an untrustworthy source. c.) Sometimes editors (I am guilty sometimes) are concerned with other information and don't have the time to research specific relationships, again someone else can fill in the blanks at a later date. Sebastien On Thu, Oct 31, 2013 at 10:57 AM, ListMyCDs.com musicbra...@listmycds.comwrote: On 31.10.2013 8:58, Frederik Freso S. Olesen wrote: If we only were to use [unknown] for stuff which is unknown to *everyone*, we could not ever use it, as *someone* out there might know. Nothing is certain. Still if printed 10-part music encyclopedia mentions unknown location its usually based on extensive research. wikipedia would also request me to add citations when adding information like that. In MusicBrainz it could be fine to enter the same information based on beliefs. [unknown] just tells that someone though it's unknown, maybe did some research or not, nothing more. Most of the people wouldn't vote on edits related to this because it would also reguire them to do extensive research. Problem is that extensive research without a definition has different meaning for everyone. Is didn't find it with google or artist doesn't mention it on his website enough? I'm not fully against of having [unknown] for places but without good guidelines it could be complete useless. Visitors and bots share this information as a fact and wrong information is spreading widely. I think we are also responsible of providing valid and factual data. ListMyCDs / Timo Martikainen ___ 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] [unknown] for places
On Thu, Oct 31, 2013 at 7:57 AM, ListMyCDs.com musicbra...@listmycds.comwrote: I'm not fully against of having [unknown] for places but without good guidelines it could be complete useless. Visitors and bots share this information as a fact and wrong information is spreading widely. I think we are also responsible of providing valid and factual data. If an editor has a source for a date, we shouldn't discourage entering the date. We could come up with another special purpose place like [undetermined], but I'd rather not go there. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: STYLE-262, Place-URL has OSM at
Sheamus Patt wrote: On 10/21/2013 10:54 AM, Alastair Porter wrote: http://tickets.musicbrainz.org/browse/STYLE-262 RFC expires October 28 Proposing a new URL relationship to link a Place to its details on openstreetmap. Hopefully pretty straightforward. If you can locate it on OpenStreetMap, then you know it's GPS co-ordinates which can be put into MB, And, if you have the GPS co-ordinates, you can easily construct the URL. E.g. http://www.openstreetmap.org?mlat=43.630704mlon= -79.415448 http://www.openstreetmap.org?mlat=43.630704mlon=%20-79.415448 (locates Ontario Place, just an arbitrary place). So, why go through the trouble of adding URLs to all of the various places with specific locations, when we could just put a (locate this place) button into the UI which will take you there using the GPS co-ordinates? As Ian pointed out early on this should probably not be used for plain coordinate links but for links to entities in OSM, like ways and relationships. Which I would avoid too since they're not stable enough - OSM entities are mostly graphical entities with no proper semantics and it can happen easily enough that you edit a way in OSM and it ends up representing something entirely different. Or you delete it and replace it with another way. Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Inheritance or appending of information through relationships
I think pulling more data through as appropriate would be great. So we already do this in a way with release credits at the bottom. Master work name as a prefix to sub work name makes sense to me. If we had masters separate from recordings then inherited performance attributes would make sense - same is already true for compilation and could maybe be an option for a DJ mix? But if we think there might be important exceptions I don't think we should do it by default because we end up asserting things that are wrong unless corrected. Here we could consider optionally pulling the data or having better tools for duplicating data and editing multiple entities at once. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
