If I recall correctly, at one point I had created a short definition for each term on the edit page. I can't find it, but could re-create it. The idea was that someone editing could have a mouse-over explanation of the meaning of the term. I think this would be helpful, and obviously anyone not wanting to know could simply not mouse-over. (The OL director at that time was strongly against any "rules" for editing. I think there is a difference between a definition and rules, but I lost that battle.)
Should I go ahead with this? It would have to be a wiki document for now, since we don't have a way to add it to the edit page, but at least it would be preparation for such a facility. There are, however, things I don't know, such as what the software does with, say, hyphens in ISBNs, but I could call out those questions and we could work on them. kc On 4/7/13 6:18 PM, John Rigdon wrote: > 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 > -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet _______________________________________________ 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
