동양구조 온톨로지 dyo

Competency questions

쓰임새별 역량 질문

온톨로지가 답해야 할 질문입니다. 질문 아래 칩은 그 답에 필요한 클래스이고, 누르면 모듈별 계층에서 해당 클래스를 표시합니다.

Module map

8개 모듈과 연결 관계

화살표는 모듈을 잇는 대표 관계입니다. 가운데 구조체를 문서의 기록, 해석 요소, 검토 결과, 기준 조항이 함께 가리키는 구조가 정합성 검토와 자동 모델링이 공유하는 뼈대입니다.

Core patterns

설계의 두 가지 핵심 패턴

D1 · 부재 유형과 배치된 부재

일람표의 C1은 단면·배근을 정의하는 부재 유형이고, 각 층에 놓인 기둥은 그 유형을 참조하는 개별 부재입니다. 부호 문자열 '1~5C1'은 층 범위와 유형으로 분해합니다.

D2 · 대상과 기록, 그리고 3면 대조

도면·계산서·해석모델은 같은 대상에 대해 각자 기록(Record)을 남깁니다. 정합성 검토는 같은 대상을 가리키는 기록들의 값을 비교해 검토 결과(Finding)를 만드는 일입니다.

v0.2 · Structure & Records

④ 구조체 · ⑧ 문서·기록 세부 설계

정합성 검토와 도면 분석이 함께 쓰는 핵심 두 모듈입니다. 부재는 기능 유형(클래스)과 재료 방식·벽 위치(값 목록) 두 축으로 나누고, 문서 쪽은 기록 → 값 진술 두 단계로 쪼갭니다.

부재 분류: 두 축

클래스 축은 부재명 구분자와 SDE 인식 종류에서 왔습니다. 'RC 기둥'·'철골 보'처럼 곱한 클래스는 만들지 않습니다.

기록 → 값 진술 → 검토 결과

기록 하나는 한 출처가 한 대상에 대해 적은 묶음이고, 값 진술은 그중 필드 하나(구간 × 속성)입니다. 검토 결과는 값 진술끼리 비교합니다.

기록(Record) describes 대상 · recordedIn 쪽 / fromEntity DXF / fromModelItem MIDAS 행 · generatedBy 추출 실행 · 숫자 일치율·단위 불일치

값 진술(ValueStatement) statesProperty(상부근·fck…) · forSegment(양단부·단부 I…) · rawValue 원문 · normalizedValue 구조화 값 · atRegion 원문 위치

기록 대응(RecordCorrespondence) relates 기록 2개 이상 · 규칙(원문 일치·층 접두 제거·괄호 단면 제거·사람 지정) · 상태(확정·후보·거부) · 내·외단부 단부 대응

추출 실행(ExtractionRun) 도구·버전·AI 모델·입력 해시 — 같은 기록이 언제 무엇으로 만들어졌는지

도구 간 충돌을 이렇게 정리했습니다

개념	지금 흩어진 표기	dyo에서

v0.3 · Mark code dictionary

부호 사전: 종류 코드의 뜻

부재 부호는 층 접두 + 종류 코드 + 번호 + 변형입니다(예: -1~1C31, RG41). 종류 코드의 뜻은 이 사전의 규칙으로 정합니다. 회사 기본 사전이 있고, 용역마다 재정의 사전을 둘 수 있습니다(예: 어떤 용역에서는 TG를 지중보로). 미정 코드로 분류된 부재 유형은 검토자가 확정해야 검증을 통과합니다.

코드	기능 유형	재료 방식	벽 위치	상태	비고

층 접두

Worked example · real data

실사례로 확인: 부대시설 보 G32

SXE가 원문 대조로 부적합을 확인한 사례(SXE_Proejct/docs/PHASE2_MEMBER.md §5)를 dyo 인스턴스로 옮기고, 역량 질문 CQ1.1을 SPARQL로 실행했습니다. 원문에 없는 파일명·추출 방법은 넣지 않았습니다.

CQ1.1 질의 결과 · 불일치 목록과 근거 쪽

동	부호	항목	도면	계산서	판정	심각도
부대시설	G32	양단부 상부근	10-D16 · p.8	단부 I·J 12-D16 · p.39	부적합	구조불안전
부대시설	G32	양단부 하부근	3-D16 · p.8	단부 I·J 4-D16 · p.39	부적합	구조불안전

SHACL로 옮긴 SXE 규칙

묶음 구간 도면 '양단부' 값을 적합으로 판정하려면 계산서 단부 I·J 진술을 모두 대조해야 함

내·외단부 적합 판정에는 사람이 확정한 단부 대응(endAssignment)이 필요

부적합 심각도 부적합이면 구조불안전·도서오류·기타오류 중 하나가 있어야 함

원문 값 값 진술에는 원문 값이 있어야 함(값을 지어내지 않음)

기록 원천 쪽·DXF 요소·모델 행 중 하나와 추출 실행이 있어야 함

검증: 실사례 데이터는 통과. 일부러 '적합 + 단부 I만 대조 + 심각도 삭제'로 바꾼 데이터에서는 묶음 구간 위반과 심각도 누락을 모두 잡아냈습니다.

v0.4 · Engagement & People

② 프로젝트·용역 · ① 조직·사람 세부 설계

Task_DY의 실제 모델(마스터 프로젝트·용역·영업·견적·계약·수금·업무·직원·계정)을 그대로 옮겼습니다. 새로 더한 것은 투입 기록과 그 추정 규칙, 그리고 견적 예측에서 각 속성이 맡는 역할입니다.

투입 인·일 추정 규칙 (D7 · D13)

1. 근무일 월~금, 공휴일 제외

2. 하루 가능량 1 − 연차(1.0)·반차(0.5). 외근·출장·교육은 업무로 셈

3. 진행 중 업무 담당자에 포함 · 기간 안(실제 완료일 우선) · 보류·휴가 분류 제외

4. 배분 가능량을 진행 중 업무에 나눔. 균등 또는 난이도 가중(1~5)

5. 합산 사람 × 업무 × 주 → 투입 기록. 업무의 용역으로 연결

견적 산식의 인·일은 계획값, 이 규칙의 결과는 추정 실투입입니다. 업무 기간 전체를 일한 것으로 보므로 실제보다 크게 나올 수 있어, 주간업무일지 기반 추정과 비교해 보정할 여지를 남겼습니다.

견적 예측에서 속성의 역할

시연 결과 — 가상 데이터(직원 2명, 과거 사업 3건, 새 견적 1건)

estimate_effort.py가 업무 6건·개인일정 2건에서 투입 기록 18건을 만들었고, 아래는 SPARQL 역량 질문 결과입니다. 직원 명단에 없는 담당자 이름('외주 김씨')은 해석 실패로 보고했습니다(D12).

질문	결과
CQ2.1 진행중 용역 · 마감 임박	M3 구조검토 · 실시설계 · 직원A · 검토서 작성 · 10-02 마감 임박 M2 구조설계 · 기본설계 · 직원A · 해석모델 작성, 구조도면 검토 · 10-16
CQ2.2 주간 부하	9/14 주 — 직원A(고급) 5.0 · 직원B(중급) 5.0 9/21 주 — 직원A 4.0(연차 1일) · 직원B 4.5(반차, 용역 외 업무 포함)
CQ2.3 비슷한 과거 사업	새 견적(구조설계 · RC 라멘 · 4,800 m²) → M1 구조설계(5,000 m², 차이 4.2%) · 계획 40 인·일 · 견적 3,000만 · 계약 2,800만 · 추정 실투입 60 인·일. M3은 용역 유형이 달라, M2는 연면적 범위 밖이라 제외
CQ2.5 견적 정확도	M1 구조설계: 계획 40 → 추정 60 인·일 (150%). 추정 방식의 과대 가능성을 감안해 해석

v0.5 · Pricing adjustments & real data

견적 보정 체인과 실데이터 검증

견적가는 산식만으로 정해지지 않습니다. dyo는 견적을 산정 단계(PricingStep)로 풀어 산식 단계와 보정 단계를 따로 기록합니다(D14). 아래 수치는 Task_DY 운영 데이터(읽기 전용 내보내기, 2026-09-29)를 Task_DY 원본 산출 코드로 다시 계산한 결과이며, 개인·거래처 정보 없이 집계만 보여 줍니다.

산식 단계보정 단계(사람의 결정)

용역 유형별 보정 실태 — 견적 234건

용역 유형	견적	당사 조정률	최종가 ÷ 산식 소계	인·일 수동지정	최종가 수기	수주	추정 투입 ÷ 계획 인·일

업무내용 38종 → 용역 유형 13종 (D16)

Notion 업무내용을 견적 용역 유형 아래 값으로 연결합니다. 가정은 확인이 필요한 대응입니다.

작업단계 47종 → 두 축 (D15)

Notion 작업단계에는 건축 단계와 용역 진행 상태가 섞여 있어 둘로 나눴습니다.

실데이터에서 드러난 데이터 품질 과제

항목	규모	영향

v0.6 · Link suggestions

마스터 없는 용역의 연결 제안

용역 1,671건 중 823건은 어느 마스터(사업·건물)에도 속하지 않아 유사 사업 검색과 견적 예측에서 빠집니다. 코드와 이름으로 후보를 자동으로 찾되, 기계의 제안은 연결 제안(LinkSuggestion)으로만 기록하고 사람이 확정한 것만 실제 연결로 옮깁니다(D17). 집계만 표시합니다.

등급별 제안 — 2026-09-29: 181건 반영 후 이름 대조로 63건 되돌림 → 118건 Notion 반영

등급	용역	검증 정확도	근거 · 처리

검증 정확도: 이미 연결된 848건의 마스터를 하나씩 가리고, 1순위 후보가 원래 마스터와 같은 비율. 실제 적용에서는 C 등급이 크게 빗나갔습니다 — 같은 발주처의 다른 현장(대전↔평택 공장, 김천↔문막), 같은 시설 유형(청년주택·초등학교·국민체육센터)이 이름 유사도를 끌어올렸기 때문입니다. 다음 판에서는 지명·지번이 다르면 후보에서 빼는 규칙을 넣습니다.

제안에서 연결까지

코드 뿌리(날짜 6자리, 점검 J 접두 구분)와 이름(연도·차수·용역 종류 단어 제거 후 2-gram 유사도)으로 후보 최대 3개
dyo:LinkSuggestion — 대상 용역 · 제안 마스터 · 등급 · 점수 · 근거 · 검토 상태 후보
검토 파일에서 승인 / 거부 / 다른 마스터 결정
확정분만 Notion·Task_DY에 반영 → dyo:partOfMaster 생성
SHACL: 확정했는데 반영이 안 된 제안은 경고

함께 드러난 마스터 자체의 문제

문제	규모	조치

v0.7 · Standards & knowledge

기준·지식: 세 가지 조항 표기를 하나로

SRO 체크리스트, 위키 Formula DB, dy_kds가 같은 조항을 서로 다르게 적고 있습니다. dyo는 KCSC 부호를 조항의 이름으로 삼고, 판(개정일)은 따로 둡니다(D18). 위키가 정본이고 dyo는 식별자·출처·검증 단계·변수만 색인합니다(D20).

같은 조항, 세 가지 표기

원천	표기 예	담긴 것	dyo

가져온 규모 — 2026-09-29 위키 export · SRO · dy_kds 기준

개념	개수	내역

가져오며 드러난 점

항목	규모	의미

v0.8 · Actions & analysis

작용·해석: 해석 준비 문서가 정본

하중·조합·풍·지진 파라미터·경계조건은 Task_MIDAS의 해석 준비 문서(.dys)가 정본이고, MIDAS 모델은 그 내용을 반영받는 대상입니다(D27). 하중 역할은 값, 케이스는 개체로 두고(D23), 조합은 기준 규칙과 모델에 실린 결과를 함께 기록합니다(D24).

흐름

단계	dyo 개념	원천

회사 표준·기준 정본에서 가져온 참조 데이터

개념	개수	출처

시연 모델이 잡아낸 검토 신호 — 가상 업무시설 M1, 지상 65 m

규칙	잡힌 내용	근거

v0.9 · Review & findings

검토·판정: 의견 3축과 두 층위 판정

사람이 쓴 검토의견은 monitoring의 3축 체계(대상 27 × 세부항목 11 × 문제유형 7)로 라벨을 달고(D29), 항목 판정과 검토 회차 결론은 따로 둡니다(D30). 검토 결과가 인용한 조항은 SRO 체크리스트와 같은 부호라 체크리스트 항목이 자동으로 따라옵니다(D32).

의견 3축

축	값

문제유형별 실적 — 검토의견 25,053건 (monitoring 중간보고)

문제유형	건수	고심각률

판정의 두 층위 (D30)

층위	값	붙는 곳

심각도는 L0~L4 하나입니다. SXE 옛 3등급은 구조불안전→L4·도서오류→L2·기타오류→L1로 옮깁니다(D31).

검토 결과 → SRO 체크리스트 (시연)

검토 결과	인용 조항	SRO 검토요소

Class hierarchy

모듈별 계층 (1~2단계)

회색 영문은 클래스 IRI 이름, 오른쪽은 원천 시스템입니다. 확장 표시는 아직 어떤 역량 질문에도 쓰이지 않는 클래스입니다.

Design decisions

설계 결정

확정은 합의한 결정, 권장은 초안에 반영했지만 아직 따로 확인하지 않은 결정입니다.

Data gaps

쓰임새를 막는 데이터 공백

Roadmap

다음 단계: 모듈별 세부 계층 순서

네 쓰임새가 공유하는 부분부터 채웁니다.

④ 구조체 + ⑧ 문서·기록 v0.2 완료
정합성 검토와 도면 분석이 함께 쓰는 핵심. 부재 분류 충돌(FG, 벽 분류, 재료 kind) 정리, 부호 분해 규칙, 구간 명칭 대응표, Record 필드 확정. SXE·SDE 스키마를 dyo에 매핑.
② 프로젝트·용역 + ① 조직·사람 v0.4 완료
Task_DY 모델을 그대로 옮기고, 투입 기록(EffortRecord) 방식을 정해 견적 예측 특징을 확정.
② 보강: 마스터 연결 제안 v0.6 완료
마스터 없는 용역 823건에 후보를 붙이고 118건을 Notion에 반영(63건은 검토 후 거부). 제안→검토→반영 흐름(D17) 정의.
⑥ 기준·지식 v0.7 완료
SRO 조항 체계와 dy_kds 조항 ID·Formula DB를 한 식별자로 통일하고, Obsidian MOC를 개념 체계로 가져옴.
⑤ 작용·해석 v0.8 완료
Task_MIDAS .dys 섹션과 dy_load 파라미터를 매핑. 실 용도 → 바닥하중 규칙.
⑦ 검토·판정 정리 v0.9 초안
판정 어휘 매핑표, 검토의견 3축 분류(27·11·7종) 확정, SRO 체크리스트 연결.

Files

파일

dyo-core.ttl

OWL 초안 v0.2. spec.py에서 생성.

dyo-shapes.ttl

SHACL 규칙: 기록·값 진술·검토 결과·부호·SXE 구간 규칙.

dyo-markcodes.ttl

회사 기본 부호 사전 29개 규칙.

dyo-queries.rq

검증한 SPARQL: CQ1.1, 부호 규칙, CQ1.7~1.9, CQ2.1~2.7, CQ3.6~3.7, CQ4.6~4.9.

taskdy_to_dyo.py

Task_DY 내보내기 → dyo 인스턴스(견적 산정 체인 포함).

estimate_effort.py

투입 인·일 추정기(Task_DY 형식 JSON → 투입 기록 TTL).

dyo-example-ops.ttl

운영 시연 인스턴스(가상).

dyo-example-g32.ttl

실사례 인스턴스(G32 부적합 2건, 부호 -1~1C31 분해).

match_masters.py

마스터 후보 찾기와 되찾기 검증(--eval).

suggestions_to_dyo.py

후보 JSON → 연결 제안 TTL.

std/std_to_dyo.py

Formula DB·위키 머리말·SRO·dy_kds → 기준·지식 인스턴스.

act/act_to_dyo.py

케이스 템플릿·표 3.2-1·식 1.7·표 6.2-1 → 참조 데이터.

dyo-example-act.ttl

작용·해석 시연 인스턴스(가상).

dyo-example-rev.ttl

검토·판정 시연(가상): 의견 라벨·회차 결론·체크리스트 연결.

spec.py

설계 명세 원본. 클래스·속성·질문·결정을 여기서 고치고 다시 생성.

build_dyo.py

명세 → TTL·페이지 데이터 생성기.