{"action":"created","issue":{"url":"https://api.github.com/repos/pulibrary/lcsort/issues/1","labels_url":"https://api.github.com/repos/pulibrary/lcsort/issues/1/labels{/name}","comments_url":"https://api.github.com/repos/pulibrary/lcsort/issues/1/comments","events_url":"https://api.github.com/repos/pulibrary/lcsort/issues/1/events","html_url":"https://github.com/pulibrary/lcsort/issues/1","id":82112258,"number":1,"title":"too strict?","user":{"login":"jrochkind","id":149304,"avatar_url":"https://avatars.githubusercontent.com/u/149304?v=3","gravatar_id":"","url":"https://api.github.com/users/jrochkind","html_url":"https://github.com/jrochkind","followers_url":"https://api.github.com/users/jrochkind/followers","following_url":"https://api.github.com/users/jrochkind/following{/other_user}","gists_url":"https://api.github.com/users/jrochkind/gists{/gist_id}","starred_url":"https://api.github.com/users/jrochkind/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jrochkind/subscriptions","organizations_url":"https://api.github.com/users/jrochkind/orgs","repos_url":"https://api.github.com/users/jrochkind/repos","events_url":"https://api.github.com/users/jrochkind/events{/privacy}","received_events_url":"https://api.github.com/users/jrochkind/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":9,"created_at":"2015-05-28T20:32:15Z","updated_at":"2015-06-01T19:25:58Z","closed_at":null,"body":"I'm finding this code is refusing certain LC call numbers as invalid, that I'm pretty sure are valid. \r\n\r\nI think one class where it does this is where the initial class number has a decimal part. LC call numbers usually start like \"TL 780\".  But sometimes the number has a decimal, like \"TL 780.5\".  If I understand it right. This second example, where the number has a \".5\" on the end, is rejected by this normalizer. \r\n\r\nI'm still trying to wrap my head around exactly what is and isn't valid, and what the numbers mean as far as sort order.  And I'm still evaluating different code to begin with for LC sort normalization, including this one -- I might port something ndushay has from Java instead, not sure. \r\n\r\nBut if I decide this one is my best bet, are you interested in pull requests to make it stop rejecting things that are or should be valid, to make it a bit more flexible? \r\n\r\nThere are some other things in this gem that work a bit differently then I'd like -- I don't see the `:wellform` option as being useful. If `:wellform => true` were just the only way it worked, you could still get the behavior you want with simply `Lcsort.normalize(call_str) || call_str.upcase`.  If what you want is an upcased version of call number for calls that can't be normalized, you can do that yourself, it doesn't need to be baked into Lcsort.normalize, which can just return nil. Unless I'm missing something? "},"comment":{"url":"https://api.github.com/repos/pulibrary/lcsort/issues/comments/107677801","html_url":"https://github.com/pulibrary/lcsort/issues/1#issuecomment-107677801","issue_url":"https://api.github.com/repos/pulibrary/lcsort/issues/1","id":107677801,"user":{"login":"jrochkind","id":149304,"avatar_url":"https://avatars.githubusercontent.com/u/149304?v=3","gravatar_id":"","url":"https://api.github.com/users/jrochkind","html_url":"https://github.com/jrochkind","followers_url":"https://api.github.com/users/jrochkind/followers","following_url":"https://api.github.com/users/jrochkind/following{/other_user}","gists_url":"https://api.github.com/users/jrochkind/gists{/gist_id}","starred_url":"https://api.github.com/users/jrochkind/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jrochkind/subscriptions","organizations_url":"https://api.github.com/users/jrochkind/orgs","repos_url":"https://api.github.com/users/jrochkind/repos","events_url":"https://api.github.com/users/jrochkind/events{/privacy}","received_events_url":"https://api.github.com/users/jrochkind/received_events","type":"User","site_admin":false},"created_at":"2015-06-01T19:25:58Z","updated_at":"2015-06-01T19:25:58Z","body":"Here are a few call numbers that aren't parseable with this library, that I believe are legal LC call numbers. In general, I think most of these can be parsed by Bill Dueber's lc_callnumber parsing library. \r\n   \r\n\r\n    QA76.5915 .D68 2011\r\n    DT546.175.N63 2011\r\n    HD30.213 .T87 2011\r\n\r\nI think maybe only two numbers after the decimal point in the class number are allowed?  QA 76.5915 => bad, but QA 76.59 would be okay. But I don't think there is in fact a two-number restriction in lc call numbers like this. \r\n\r\nHere's an example straight from LC's own catalog, LCCN 2010028310 , catalog.loc.gov doesn't have persistent URL's so I can't give you a link, but just enter that number at catalog.loc.gov. \r\n\r\nCall number directly in the record for that LCCN is: QA76.884 .L36 2011\r\n\r\nThat is not parseable by this library. \r\n\r\nIf it is just an issue of number of digits past the decimal in the class number -- fixing it would also require making more space in the generated sort key, which would make sort keys incompatible with previous sort keys. "}}