All good questions and thanks for taking the time to put this together. I'm not prepared to comment on any of them now as I'm, brain-dead from working on taxes all day, but I will chime in over the coming week.
It occured to me in reading through this that I have been struggling with "definitions of terms" and not really recognized the point til now. Perhaps one of the first things we need to do is put together a glossary of terms so we will all know we're talking about the same things. My background is not is library science and although I've done extensive research and work comfortably in 3 languages, and a half-dozen Computer languages, I'm not sure I can give you an "elevator definition" of what a "work" is vs. an "edition" and how these record "merges" are important or implemented, etc. John Rigdon > Hi! I'm not sure how to reply to a thread made before I joined the list, > so > I'll have to start a new one. A bit of a wall-of-text, sorry! > > When reading the "Data consistency > policy<http://www.mail-archive.com/ol-discuss%40archive.org/msg00814.html>" > thread in the archives, I realised OL doesn't seem to have any guidelines > at all, and some people were suggesting that should change. Strict rules > are obviously a problem: both music and books have the tendency to find > the holes in every single rule you can think of (we in MusicBrainz are > quite proud our community of walking edge-case generators). But without > having some idea of what's the desired state of data, it's hard to make > any > improvements on it. > > I'm the new guy here, but I also happen to be the "style leader" (that is, > the guy in charge of the guideline processes) in MusicBrainz, so of course > I felt the urge to try to reach a set of basic OL guidelines and > documents. > We have a fairly insane amount of them ( http://musicbrainz.org/doc/Style > ) > but something much more simple should do, at least in the beginning :) > > I've added > http://openlibrary.org/community/guidelines<http://openlibrary.org/community/guidelines?m=edit> > and > listed some of the issues I can, from my MB experience, see as useful to > settle. I'm fairly new here, so I expect some of these are settled issues > - > that's much better then, but they should still be put in writing so that > future editors can see them. I'm also sure other people can think of more, > so we should add them there. > > If people think the whole thing is stupid, feel free to shout at me - if > you think it's useful, let's try to advance on this. At MusicBrainz we > work > based on consensus - hopefully that will also be possible here but if > people would prefer voting, that's also a possibility. > > Some of the notes are proper guideline stuff (where there is a style > decision to take). Some are more of a design question, but they should > still be documented (and in some cases, maybe rethinked). Of course, a > good > few will require coding changes and thus might be wishful thinking as of > now, but it seems more reasonable to decide what we'd *want*, even if it's > not yet possible with the existing code, and then find ways to accommodate > until that changes. It would also help give some pointers on things to > work > towards for the developer(s). > > Cheers, > Nicolás > _______________________________________________ > Ol-discuss mailing list > Ol-discuss@archive.org > http://mail.archive.org/cgi-bin/mailman/listinfo/ol-discuss > To unsubscribe from this mailing list, send email to > ol-discuss-unsubscr...@archive.org > _______________________________________________ Ol-discuss mailing list Ol-discuss@archive.org http://mail.archive.org/cgi-bin/mailman/listinfo/ol-discuss To unsubscribe from this mailing list, send email to ol-discuss-unsubscr...@archive.org
