I think guidelines are important and I'm disappointed to hear someone at OL was actively against them.
My take on some of the topics raised: Translations are not separate works, but it's useful to have a "translation" record which records information about a specific translation (translator, date, target language) and collects together all the editions of that language. Work title - it doesn't need to have just one if the I18N is done right. Everyone can have the title in their own language selected by their UI preferences. Strings get stored as a text/language tuple and each language can have one, even for single valued fields/properties. Author name - as above for I18N, but "credited as" or equivalent can go on the edition record for completeness. Pseudonyms - related to above, but not mentioned. Freebase breaks with what I understand to be library practice and collects all personal pseudonyms together as aliases for the main author record. Collective pseudonyms and house names are still cataloged separately. I think it's worth discussing whether pseudonyms should be cataloged separately or together with the main author. ISBNs - accept both 10 & 13, normalize to 13 with no punctuation for storage/search. Check & warn on check digit, but don't reject (because sometimes they're printed with bad check digits). Print runs - don't catalog. External identifiers/URLs - Freebase uses a similar scheme to the one described for MusicBrainz. The identifier gets inserted into a template URL for external links to OpenLibrary, MusicBrainz, Wikipedia etc. Tom On Sun, Apr 7, 2013 at 9:28 PM, Karen Coyle <kco...@kcoyle.net> wrote: > 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 >
_______________________________________________ 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
