Ok, I've refined the proposed AR's page, so lets give this another shot. The AR is now much more restrictive, both in what can be linked to, and in how many links the same story can have.
The new URL for the proposed AR is http://wiki.musicbrainz.org/News_Coverage_Relationship_Type (Note that the URL has slightly changed since the original RFC.) ---------------------------------------- In addition, though this should not be considered a blocker for implementing the AR, should this proposal pass, it is requested that dev time eventually (near-future post-NGS, if not possible for the NGS release) be aimed towards the following: * Rather than using the link text "{{entity}} has news coverage at http://www.foo.com/somestory.html";, the description field should be used for the link text. * The description field is a mandatory attribute for this AR, and thus, no edit to add an AR of this type should be allowed by the server if the description field does not match a "0000-00-00: (text)" pattern. * When presenting this AR on pages displaying ARs, the description fields should be sorted, so that date order is maintained, and each AR of this type should appear on a new line, such that the resulting display is: News coverage for Foo: 2000-10-03: A new band emerges! 2005-02-11: Foo's latest release is a hit 2007-09-05: Foo's 'All the Best Songs' goes platinum 2010-02-24: It's official, Foo is breaking up! (which would, of course, when such a view is implemented, mean ignoring the link text for the {{non-URL entity}}-{{URL}} display). ---------------------------------------- Are all these changes enough to make the AR both seem useful and non-problematic? :) This remains RFC-68. Without continued objection/debate, this new RFC will move to RFV status on 2010-03-22. Thanks! Brian On Mon, Mar 15, 2010 at 5:24 PM, Brian Schweitzer < brian.brianschweit...@gmail.com> wrote: > *Style Leader hat on* > > An update on the Champion for this proposal: I've talked to ruaok. He's > rather limited in what time he can devote to the lists (hence why he'd asked > me to propose this for him). This is an AR he'd like to see happen, but > he's busy enough that actively working the proposal isn't likely to happen. > So he's asked me to champion it for him. > > *Style Leader hat off* > > This isn't a huge change, but it skips the delay of my passing any changes > to the AR or proposal through ruoak, so long as the core of AR remains. So, > let me reiterate my comments and suggestions from earlier today, in my new > position as champion for this proposal. I've also spent part of today > looking at what Wikipedia had to say about this type of link, given that > they have frequently have news links as references. > > The only further changes or additions I'd make at the moment would be these > (I'll wait on some comments, if there are any, before I revise the wiki > proposal): > * to specify that not 'any site on the net that can be considered a "news" > site' should be linkable, but rather, that 'any site on the net that can be > considered a "news" site which is considered reputable' > * somehow, specify that we want "real" news articles, not tiny blurbs - > perhaps a requirement that the article have a headline, and that the artist > be a primary focus of the article, would suffice? > * specify that the original source, or as close as possible, should be > linked for any article. So an article from a Washington Post reporter would > be fine to link to at the Washington Post, but an AP report should link to > it at the AP, not at some tiny paper which reprinted the AP story. > > Brian > > > On Mon, Mar 15, 2010 at 12:42 PM, Brian Schweitzer < > brian.brianschweit...@gmail.com> wrote: > >> Trying to get this proposal back on track... :) >> >> On Sun, Mar 7, 2010 at 7:34 AM, Chad Wilson <chad.wil...@gmx.net> wrote: >> >>> On 7/03/2010 2:56 p.m., Brian Schweitzer wrote: >>> >>> I think the fear is there'd be tons of URLs linked, but without any >>>> context, those URLs don't give much, other than that you know there's some >>>> news article about the artist on the other end. >>>> >>>> However, if the AR description field could be displayed next to each URL >>>> AR for that type, that field would seem to work perfectly to address some >>>> of >>>> this concern and describe just what news article was on the other end of >>>> each such URL AR. >>>> >>>> Dev impact: It wouldn't really make sense to implement this type of >>>> description display on the current server code, but this would seem to >>>> entail only some minor additional template handling (specific to this AR >>>> type?) for the AR display page template on the NGS server. Plus, if it >>>> were >>>> added, esp universally, that so-far useless AR description field would >>>> actually now have some useful purpose. :) >>>> >>>> Brian >>>> >>> >>> Chad, would this address your concerns? As I understand the proposal, >>> "If it's the former, I think the proposal/guidelines should specifically say >>> "Do not link to individual articles about an artist/release", or something >>> similar." would specifically be counter to the proposal; the intent is that >>> individual articles *should* be linked using this proposed AR. >>> >>> >>> Not really, no. :( Even if we mandated use of the description field, I'm >>> not convinced it would be actively used despite guidelines, and we have far >>> too many AR edits currently for there to be special attention to these ones. >>> It's also not really "structured" - I'll come back to that later. >>> >> >> While this is true, I think we could mandate a structure, and a report >> (akin to the ASIN one) could detect those ARs which have either a missing, >> or incorrectly formatted, description. It'd be almost as easy for someone >> to edit in a description after the fact as it would be for the original >> editor to include it. >> >> >>> I mainly think manual adding and maintenance of the kinds of volumes of >>> links that are available for news on any given artist - for it to give a >>> useful or complete picture - is far too great to manage, and better served >>> by a search engine, or tagging+mashup style approach, rather than hard AR >>> links. Add to that how quickly news article links come and go in their >>> validity on many websites, and I'm just not convinced that the data would >>> have much value in the years to come? >>> >>> Most of our links currently are for general concepts, or landing pages >>> for an artist where there many only be say 1, 5, 10 or maybe even 50 such >>> links for an artist added. When you're talking news articles, there are >>> thousands that /could/ be linked. With non-standard or potentially >>> unreliable URLs. Many might be recycled/syndicated content with some extra >>> guff added. The ARs wouldn't have any structured metadata, so automatic >>> processing of content would be difficult. >>> >> >> While you're right, most ARs are of this sort, we do have not one, but >> four existing ARs which all can easily suffer the same problem... yet >> haven't. Biography, Fanpage, History, and Review Relationship Types all are >> so generic in what they allow linking to that any of the 4 could link to >> tens, hundreds, even thousands of sites. Yet I'm not aware of any artist >> which has more than perhaps a few of any of these. >> >> >> >>> I'm still really not seeing the use case for individual articles here. >>> Who would find this useful where a search or aggregator site mashup would >>> not be better for their purpose? >>> >> >> Imagine some future UI, giving this among the ARs for an artist: >> >> News coverage for Foo: 2000-10-03: A new band emerges! >> 2005-02-11: Foo's latest release is a hit >> >> >> 2007-09-05: Foo's 'All the Best Songs' goes platinum >> 2010-02-24: It's official, Foo is breaking up! >> >> Would that not perhaps be both useful and interesting? >> >> >>> >>> Personally, so long as the display were able to show me the headline's >>> title, it'd be a lot more useful and interesting to see articles about >>> specific events in U2's history, rather than simply a link to some category >>> of articles about U2. If the latter were intended, the AR would seem rather >>> redundant; an auto-generated link to >>> http://news.google.com/news/search?q=U2 would suffice. >>> >>> >>> As above, I can't really see why individual article links at MB would be >>> better/more up to date/more correct than the news.google.com search >>> either. There is nothing in the AR that says "only link to articles about >>> important stuff"; and policing this would lead to subjective edit arguments. >>> >> >> I don't think it needs it, to be honest. I think editors are relatively >> self-selecting. There's nothing to stop even some news agency from paying >> someone to link each and every article about an artist to that artist's >> page, but that'd perhaps be beneficial, if at least definitely not harmful. >> It might even garner MusicBrainz additional press, leading to additional >> licensees for data. :) In any case, is there really the editor who's going >> to bother to link a 10 word story, or will editors be more sane about it, >> linking only to "bigger" stories. Again, I understand the fear, but we've >> not had that kind of problem with the existing ARs - not even with the >> fanpage AR, which perhaps is even more "exploitable", were any fanbase to >> attempt to seriously load up an artist with links to various fanpages. >> >> >>> Sorry, I still really don't understand this. From my perspective, MB is a >>> structured information database that derives its value from providing >>> structured and computer-parseable "hard" links between its own entities and >>> external entities of merit. I'm still not sure how extending that linking to >>> an _unstructured_ bundle of news articles would be useful without structured >>> metadata about those links (at the very least their date) - and even so, >>> handling those kinds of volumes would seem to me to require a different >>> management system, as Pavan alluded to on the IRC discussion. >>> >>> Chad >>> >>> >> As for style, the one change I'd suggest to the proposal would be to make >> the Description field manditory, with a "YYYY-MM-DD: Headline" structure, to >> store the publication date and headline for the linked news report. That >> structure could even be subjected to validation (in the NGS server version), >> blocking entry of the AR if it didn't include that data and structure. >> >> We may not be actually displaying the description now, but we could even >> make it a part of the proposal that, even if it's not in the initial NGS >> release, providing a display - like the one I suggested above - should be >> something looked at for the near future, post-NGS. >> >> Brian >> > >
_______________________________________________ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
