On Sat, Oct 29, 2011 at 11:29 AM, Jim DeLaHunt <from.nab...@jdlh.com> wrote: > Hi, Nikki. Thanks for taking a look at this RFC. > > > Nikki-3 wrote: >> >> I don't think your proposed Style/Work/Partial Works Relationship >> Inheritance page belongs under Style as it's currently written. The >> Style pages are intended to simply be guidelines saying how editors >> should enter data and nothing more. >> > > Fair enough. So where do you think the proposed "Partial Works Relationship > Inheritance" page should reside? And what pages should like to it? > > > Nikki-3 wrote: >> >> From what I understood of the >> proposal, that could written as one sentence along the lines of "When a >> work has parts, any relationships that apply to all sub-works should >> only be added to the parent work". >> > > I propose adding text like this to "Parts Relationship Type" as part of > RFC-339. Another comment in this thread suggests adding it to the > description of every Relationship Type involving Work entities. I think > that's a good idea, but I'll leave it out of RFC-339. It can be a followup > proposal. > > > Nikki-3 wrote: >> >> I also agree with Calvin and think we need server support before >> inheriting relationships before adding a guideline like this. >> > > Tell me more. (repeating my reply to Calvin:) I had intended this proposal > to guide addition of new data into MusicBrainz, not to initiate a campaign > to get rid of ARs on partial Work entities which inheritance renders > redundant. But I get the impression that you and others are concerned about > delaying the purge on such ARs until the software is up to snuff. i'm OK > with that. I'm even OK with an interim policy which says, put ARs > everywhere for now, while we get the software able to handle inheritance, > and then do a much bigger purge of redundant ARs. Would that answer your > objection? > > > Nikki-3 wrote: >> >> Instead of attempting to get the server, the search server and anything >> else using MusicBrainz data to implement the same version of >> inheritance, perhaps what we really need is a better way of >> adding/editing relationships. Would this still be a problem if we >> improved relationship editing so that, for example, we were able to >> add/edit relationships for a work and all its sub-works at the same time? >> > > I think that, regardless of RFC-339, relationship editing for works is > hugely inadequate for handling works and subworks for opera compositions, > and to a lesser extent for Classical. With 30-50 subworks for an opera, and > 16 UI actions (clicks, buttons, text fields) per sub-work relationship, > entering subworks for a single opera takes hours and is very tedious. I have > a number of ideas for improving this, but they are beyond the scope of > RFC-339. > > (repeating my reply to Calvin) I'm hearing a couple of people in this thread > allude to a preference for having Relationships describing compositions be > applied to every parent and child Work entity in the Parts Relationship tree > of Work entities. This is a legitimate choice for the data model. It makes > application development easier, at the cost of making data entry harder, > accidental inconsistency of data more likely, etc. But we could decide we > prefer that trade-off.
(meh, I kinda wrote a long mail...) It doesn't have to make data entry harder (or just marginally) if a good way of batch adding relationships is developed. At some point you said you didn't know if people were adding relationships for subparts: I certainly am, and I would be more worried about whether other people do add parent works at all, as it's not straightforward and obvious with the current structure. A revamp of the "work" entity would also be important in my opinion, that allows us to, for example, indicate if it is a full work, a container of other works or just a work part (in a way that lets us do things like filter the work list to show only full works and ignore things like movements or like "3 piano sonatas" if we want to). With that we could make a nice report "parts without a parent work" to fix those issues. Once *that* is done, I would consider going through with this. Classical, I think we all agree, needs a huge revamp. Even ruaok and the devs know, which is why they talked about making a 2012 mini-summit about it to try to deal with it better. And trying to fix small parts of it first *is* a good idea: I think CSG v2 guidelines should start being RFC-d soon in small chunks so we can at least have *something*, even if parts of it have to wait to be implemented until we all agree on them. But we don't even know how CSG2 will be. Also, at some point (hopefully soon) the option to add works *and* relationships to works from the release page will be added (same as we do now for recordings), which will probably make people enter more info for partial works than now while still not making them enter parent works (which is a second level of abstraction a lot of them won't care about). So I would want their efforts to be useful and not against the guidelines, because writing guidelines that go against what most people will do is just frustrating both for them and for people trying to enforce them. > > -- > View this message in context: > http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Partial-Works-Relationship-Inheritance-tp6939661p6942817.html > Sent from the Style discussions mailing list archive at Nabble.com. > > _______________________________________________ > MusicBrainz-style mailing list > MusicBrainz-style@lists.musicbrainz.org > http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style > -- Nicolás Tamargo de Eguren _______________________________________________ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
