Openlibrary: LCC를 LCC 클래스 이름으로 변환하는 방법

@cdrini LCCO와 일정 개요의 두 가지 개요가 있습니다. @cclauss 는 일정 개요를 사용하고 있었습니다: https://www.loc.gov/aba/cataloging/classification/. @cclauss 의 작업이 일정을 기반으로 하는 경우

비록 불완전하지만 LCCO는 작업하기가 훨씬 더 쉽습니다. 일정에는 들여쓰기가 앞뒤로 모두 있는 하위 클래스가 있고 뷰어와 코더가 볼 수 있도록 시각화하거나 프로그래밍하는 방법이 있기 때문입니다. LCCO는 앞으로만 들여쓰기하므로 클래스는 항상 서로 뒤에 옵니다(서로 앞뒤가 아님).

예를 들어 일정에 다음과 같이 표시될 때입니다.
------하위 클래스 1
하위 클래스 2
------하위 클래스 3

어떻게 쉽게 표현할 수 있습니까? 그것은 할 수 없습니다. 그러나 LCCO는 다음과 같이 보이기 때문에 가능합니다.
하위 클래스 1
----하위 클래스 2
-------하위 클래스 3

표현하기 쉽습니다. LCCO의 유일한 문제는 클래스 및 하위 클래스의 전체 목록이 아니라 불완전하다는 것입니다. 일정은 완전한 것입니다.

그것이 1) 완전성, 2) 표현의 정확성과 같은 무언가를 희생해야 하는 나의 현재 딜레마입니다.

선택하는 것은 귀하와 @cclauss의 몫 입니다. 완전하고 공식적이기 때문에 일정이 최선의 선택이라고 생각합니다. 항상 정보를 표현할 방법을 찾을 수 있지만 누락된 것을 쉽게 얻을 수는 없기 때문입니다.

@cclauss 가 https://github.com/thisismattmiller/lcc-pdf-to-json 의 덤프를 사용하고 있다고 생각합니다. 나는 그것들을 사용하는 것이 가장 좋은 것 같다고 생각합니다. 왜냐하면 우리는 그것이 "느낌"이 어떨지 보기 위해 작동하고 실험할 수 있기 때문입니다.+1: 우리가 선택한 것은 무엇이든 고정되어 있지 않습니다. 우리가 필요하다고 생각되면 더 많은 복잡성을 처리하도록 항상 조정할 수 있습니다. :)

작동하는 복잡한 시스템은 항상 작동하는 간단한 시스템에서 진화한 것으로 밝혀졌습니다. 반대의 명제도 사실인 것 같습니다. 처음부터 설계된 복잡한 시스템은 작동하지 않으며 작동하도록 만들 수도 없습니다. 작동하는 간단한 시스템부터 다시 시작해야 합니다. - 존 갈

@cdrini가 동의했습니다. 더 진행하기 전에 이미 사용 중인 것으로 가 보겠습니다. :) 그렇다면 다음은 무엇입니까?

다음 단계는 @cclauss 가 준비가 되었다고 생각하는 메서드가 있으면 UI에 추가하고 테스트를 위해 dev.openlibrary.org에 넣을 수 있습니다. :) 그게 맞는 것 같 나요?