"2022:Manual"의 두 판 사이의 차이
(→infoUrl) |
(→Node의 개요) |
||
28번째 줄: | 28번째 줄: | ||
** 유의미 란: 조선 태조 - 이성계 등 확실하게 이름이 바뀌는 경우에만 기재 | ** 유의미 란: 조선 태조 - 이성계 등 확실하게 이름이 바뀌는 경우에만 기재 | ||
** Relation: A와 B(이칭)을 isSameAs로 연결 | ** Relation: A와 B(이칭)을 isSameAs로 연결 | ||
− | ** '''이칭 노드를 따로 만들지 않을 경우''': Label에 A | + | ** '''이칭 노드를 따로 만들지 않을 경우''': Label에 A, B(이칭) 을 기재하여 DB에서 중복 체크 시 검색되도록 할 것. |
*ID는 본명, 정식 명칭을 기준으로 정의 | *ID는 본명, 정식 명칭을 기준으로 정의 |
2022년 9월 8일 (목) 10:31 판
목차
- 1 개요
- 2 Node Description 관련(위키/시맨틱데이터 네트워크)
- 3 Class별 규칙
- 4 2021
- 5 Node 관련 지침
개요
매우 강조 사항
- 2022DB에서 동일한 항목이 있는지 반드시 확인★
- 정확히 동일한 ID 뿐 아니라 유사한 ID, 이칭도 검색하여 중복노드가 발생되지 않도록 할 것
- 기존 ID가 정식명칭이 아니거나 온톨로지에 어긋날 경우에는 수정할 것
- 이전 위키/시맨틱데이터에서 본인 데이터는 모두 현재의 양식 및 규칙에 맞게 고치기 (관련 사항 아래 참고)
- 모든 위키 페이지는 표가 깨져있지 않아야 하며, 고스트 노드는 네트워크 그래프, 스토리 네트워크 그래프 모두 절대 없어야 함.
- 모든 행이 공백인 표는 맨 윗줄의 라벨만 남기고 삭제. (라벨: id 등이 적힌 곳으로 표에서 색깔 다른 맨 윗줄)
2020, 2021 위키를 수정할 경우
- 2020 위키를 가져올 떄: 2020 위키는 삭제하지 않고, 이번 위키에 올해 양식 및 규칙으로 수정할 것
- 대폭 수정하는 경우에만 문서 맨 아래에 [[분류:2022:본인이름]] 기재
- 표 틀어진 것, 오타 수정, 올해 양식으로 바꾸는 것은 대폭 수정이 아님!
- 대폭 수정하지 않는 경우에는 [[분류:2020:본인이름]] 로 기재
- 본인이 작성한 과년도 위키를 대폭 수정하는 경우에는 [[분류:2020:본인이름]], [[분류:2021:본인이름]] 은 안써도 됨
- 2020 위키 중 다른 사람 것을 가지고 와서 대폭 수정하는 경우: 기존 작성자를 [[분류:2020:예전 작업자 이름]] 라고 쓰고 아랫줄에 [[분류:2022:본인 이름]] 를 기재.
Node의 개요
- 노드로 만드는 것: 모든 것을 노드화하면 안됨. 네트워크 그래프 가독성을 고려하여 대상에 대한 해설은 해설문으로 설명하고, 굵직한 관계 혹은 유형화하여 관련 시맨틱네트워크를 만들 것만 노드로 만들 것
- 내가 이것을 시맨틱네트워크그래프로 만들 것인가를 고려하여 노드화.
- ex. 덕수궁_중화전(Architecture) - type 정전(Concept) - 경복궁_근정전(Architecture)
- 위처럼 정전을 유형화하여 각 궁궐의 정전을 연결할 예정: 노드화 가능
- 위처럼 정전을 유형화하였으나 각 궁궐의 정전을 연결할 예정이 없으면: 노드화하지 말 것.
- 이칭은 유의미하고 본인이 시맨틱네트워크 그래프를 만들 것만 생성
- 유의미 란: 조선 태조 - 이성계 등 확실하게 이름이 바뀌는 경우에만 기재
- Relation: A와 B(이칭)을 isSameAs로 연결
- 이칭 노드를 따로 만들지 않을 경우: Label에 A, B(이칭) 을 기재하여 DB에서 중복 체크 시 검색되도록 할 것.
- ID는 본명, 정식 명칭을 기준으로 정의
- 도산 안창호(X) -> 안창호 / 언더우드(X) -> 호러스_그랜트_언더우드
Link의 개요
- Ontology:EKC_2022:Relation 을 참고하여 Relation을 정의
- Domain이 본인이 만들려는 링크의 source의 class, Range가 만들려는 링크의 target의 class 와 일치하는 지 확인할 것
- 불일치 시 회의시간에 해당 Relation을 사용해도 되는지, 혹은 다른 Relation을 사용할 지 확인할 것
- Domain이 본인이 만들려는 링크의 source의 class, Range가 만들려는 링크의 target의 class 와 일치하는 지 확인할 것
시맨틱 데이터 생성의 개요
- Event 클래스 노드 생성이 기초 단계임을 명심. 문헌은 이벤트를 기록한 것! 데이터에서는 문헌이 출발점이 아닌, 이벤트가 출발점.
- 네트워크 생성의 기본요소: 이벤트, 문헌(이벤트를 기록), 그림(이벤트를 그림), 인물(이벤트에 참가 + 누구를 위한 이벤트), 장소(이벤트가 열린 곳)
- 아래 시맨틱 네트워크 예시:궁중연향을 참고.
시맨틱 네트워크 예시:궁중연향
- 예시:궁중연향 : 교수님께서 만드신 시맨틱데이터로, 궁중연향 예시는 우리 데이터의 가장 기본적인 패턴이므로 명심할 것!
- ex.“1848 헌종 무신년 진찬”을 보면 Event에 대한 의궤(Record) : documents (1848년(헌종 14)) / Event가 일어난 장소(Place): isHeldAt / Event가 누구를 위해 열린 것인지(Actor) : isHeldFor(60세) 로 연결되어 있음.
- 사업 권역에 위치한 "장소"를 연결하는 작업이 필요함 (현재 해당 그래프는 왕실족보 네트워크 + 의궤 기록 기반 이벤트 노드임)
인물 - 장소의 연결
- 인물과 장소를 연결하는 것은 너무나 많은 데이터가 생기므로 연결하지 않음. 이에 연결법은 하기를 참고.
- ex. 정자(Place) - 정자를 노래한 시(Work) 혹은 작품(Record), 그림(Object) 등 - 관련된 인물(Actor) 로 연결
- 장소(Place) - 장소를 노래한 시, 작품, 그림 : 단순히 언급된 것은 mention, 주로 묘사한 것은 시각적/비시각적 상관없이 depicts
- 시, 작품, 그림 - 관련된 인물(Actor): 저작자는 creator로 연결
참조도구 - 한국민족문화대백과사전 Network
- EncyKorea : 민백의 데이터를 정제 및 활용하여 한양도성 데이터와 상호 검증 및 보완해야 함
- 민백 내 잘못된 데이터 확인되면 교수님께 이야기 드리기.
SQL 관련
- 기본적으로 인문정보학은 DBA로 작업하나 SQL 이용도 가능.
- 단, Delete, Update SQL문은 절대 단독으로 쓰지 말 것!!
- 반드시 작업 시작 전 기존 데이터 백업 후 작업할 것!!
- 문제 발생 시 곧바로 조교에게 연락 (혼자 해결하려고 하지 말 것)
Node Description 관련(위키/시맨틱데이터 네트워크)
id
- 2022DB에서 동일한 항목이 있는지 반드시 확인
- 정확히 동일한 ID 뿐 아니라 유사한 ID, 이칭도 검색하여 중복노드가 발생되지 않도록 할 것
- 기존 ID가 변경되어야 할 경우, 수정
- id=label이 아님을 명심할 것!!
- 정확한 이름은 label로 보여주므로 ID는 식별되는 정도로 축약할 것 (20자 이상 불가)
- 하이픈(-), 콜론(:), 언더바(_) 외의 기호, 특수문자 사용 금지
- 콜론(:)은 앞은 붙이고 뒤만 뜀. (A:_abc)
- .은 3.1이나 8.15와 같은 고유명사만 가능함.
- .와 ()와 ,와 ·(가운데점)과 & 도 불가능합니다!!!
- single quotation은 ㄴ+한자를 눌러서 ’(9번째 있는 것) 쓸 것
- 라틴문자: 움나우트 제외하고 씀 -> ä는 a로 기재
- 한글자 짜리 id: 반드시 한자 병기
- Class별 ID 규칙은 아~~래쪽의 Class별 규칙을 확인
class
- Ontology:EKC_2022:Class 페이지 참고하여 분류
- 클래스별 규칙은 아~~래쪽의 Class별 규칙 항목 참조
groupName
- Ontology:EKC_2022:Class 에 기재된 groupName 만 이용
partName
- Architecture(class) 건축(groupName) 궁궐건축, 왕실건축 이외에는 필수가 아니며 규칙은 정해지지 않음
- 자신의 시맨틱데이터 내에서만이라도 일관될 수 있도록 기재
- 너무 세분화하지는 말고 partName별로 하였을 때 유의미할 정도로 기술
Label
- label은 256자 이상 불가
- Label의 Single quotation, Double quotation은 ㄴ+한자를 눌러서 나오는 것으로 이용
- Class별 Label 규칙을 확인하여 기재할 것
hangeul / hanja / english
- 해당하는 명칭을 기재
infoUrl
- InfoUrl은 다양한 노드를 묶은 집합node가 아닌 이상 빈칸일 수 없음!
- hanyang2 위키는 만들만한 가치가 있는 것 중 자신이 만들 위키페이지인 경우에만 기재
- 이외에는 온라인 상의 Resource(민백, 장서각, 실록위키 등) URL을 기재
- URL은 깨지는 글자 없이 깔끔하게 가져올 것 (특히 URL에 한글이 있으면 반드시 깨지므로 전체 Url 복붙 후 깨진 부분 삭제하고 한글만 따로 또 복붙할 것)
note
- 올해 작업물이거나 2020, 2021 위키를 대폭 수정한 경우에는 2022:본인이름 기재
Class별 규칙
헷갈리는 class 분류 정리
Object / Record
- 그림은 Object. 다만, 권, 축, 병은 그림(Object) / 첩은 문헌 (Record)
- 사진 Record, 유리원판도 Record
Architecture / Place
- Architecture는 3D모델, 3D지도의 대상이 되는 것이며 이외에는 Place
Record / Work
- 문헌은 Record, 문헌에 실린 시 등은 Work
Actor
Event
Place
Architecture
Clothing
Food
Object
Work
- ID: “작가:제목” 등 고유로 구분될 수 있도록 id 규칙 부여 예정 (우선 작가:제목 형식으로 만들 것)
Record
Concept
- 개념어는 최소한으로 함. 개념어는 서로 다른 관계의 노드를 연결하는 일종의 허브노드로만 활용.
- 반복적 개념의 연회는 Concept 클래스 / 개별 연회는 Event 클래스
- ex. 유상곡수연 : concept / 계축년 유상곡수연 : Event
- 장소와 관련된 개념어의 연결: 개념어(Concept)-장소(Place): hasPart 로 연결
- 개념어(Concept) - 중국 고사 등 관련근거: isRelatedTo 로 연결
Heritage
Multimedia
WebResource
Text
Story
Index
Bibliography
- Bibliography의 ID 규칙 및 찾는 법의 자세한 사항은 반드시 인용전거 참고
- ID, label(서지사항) 반드시 각 분류별 유형에 맞도록 기술!!!!!!
단행본
- ID: ISBN 번호(13자리 숫자) / ISBN을 찾을 수 없는 경우에는 저자:연도:제목
- Label: 시카고 형식으로 기술
- 개정판/초판의 ISBN이 다른 경우는 작업자의 판단 하에 둘다 하거나 1개만 선정하여 함.
- 잘 이해가 가지 않을 때: 문헌:참고문헌의 단행본 항목 참조
논문
- 무조건 KCI를 우선으로 찾고 우선시 할 것
- KCI에 있는 경우 ID: URL의 뒷쪽에 있는 ART를 포함한 숫자를 KCI:ART블라블라 형식으로 기재
- ex. KCI:ART001786204
- KCI에 없는 경우 ID -> RISS 에서 검색: 해당 논문 페이지의 화면 중상단에 있는 http://www.riss.kr/link?id= 이후 부분을 RISS:블라블라 형식으로 기재
- ex. RISS:T16083809
- Label: 시카고 형식으로 기술. 한자는 모두 한글로 바꿔서 쓸 것
- 권-호의 표기: 『학술지명』 권-호, 형식으로 기재 (숫자만! 제, 권, 호 같은 한글은 기재X)
- ex. 박미선, 「조선 숙종 대 장희빈의 왕비 책례 거행과 그 함의」, 『한국학』 44-2, 한국학중앙연구원, 2021.
- 권, 호 둘 중 하나만 있을 경우는 1개 숫자만 기재 (한글 기재X)
- ex. 윤진영, 「이유간(1550~1634)의 『연지회시종사실(蓮池會始終事實)』과 남지기로회도(南池耆老會圖)의 전승내력」, 『장서각』 8, 한국학중앙연구원, 2002.
- 학위 논문인 경우: 「논문이름」, ㅇㅇ학위논문, 소속, 연도.
- ex. 이정일, 「헌종대 무신진찬의 정재 연구」, 국내석사학위논문, 한국체육대학교 사회체육대학원, 2019.
- 권-호의 표기: 『학술지명』 권-호, 형식으로 기재 (숫자만! 제, 권, 호 같은 한글은 기재X)
- 잘 이해가 가지 않을 때: 문헌:참고문헌의 논문 항목 참조(단, ID 기재된 것만 작업완료된 것이니 ID 기재된 것만 참고)
고문헌
- 조선왕조실록의 ID: 국사편찬위원회 조선왕조실록 온라인 서비스에서 해당 기사 검색 후 URL 뒷부분에 있는 id/ 뒷부분 sillok:블라블라 형식으로 기술
- ex. sillok:kva_11012028_001
- 조선왕조실록의 label: 『ㅇㅇ실록』, 왕력: 실록 기사명
- ex. 『정조실록』, 정조 10년 12월 28일: 연령군 이훤의 집 제사를 받들도록 해당 궁에 분부하다
- 그밖의 고문헌의 ID: 제목:연도 형식으로 기재
- 그밖의 고문헌의 label: 제목:연도(왕력) 형식으로 기재
- ex. ID: 종묘의궤:1697 / label: 종묘의궤(宗廟儀軌), 1697(숙종23)
2021
사진 등 참고자료의 출처
- 도서 스캔 등 옛 사진의 출처: Label에 원 도서명 기재
- 온라인으로 퍼블리싱한 곳은 쓰지 않음
- 신문사의 보도사진: 위키에도 WebResource 로, Data에도 WebResource 로 들어감!
- label(표제,출처,날짜)과 Remark(기타 내용)에다 나누어서 넣음
이미지 관련
- 사진은 방향 반드시 확인하고, 맞는 방향으로 업로드할 것
- 이미지는 Data 제출 후 모두 업로드하여 Data Review가 가능하도록 할 것
Web Resource
- WebResource: C Text, 장서각, 네이버 지식사전, 위키 등
- 대표 Node와 연결하고, Relation은 isShownAt 텍스트, isShownBy 사진 및 영상 등 멀티미디어
- 사진 및 영상 등이 많다면, 요즘 찍은 사진 및 동영상은 WebResource, 옛날 것은 시멘틱 데이터로 보여줌
groupName
- Web Resource의 groupName: (text) 해설, 참고, 원문, / (multimedia) 사진, 동영상, 도면, 그림, 지도, 3D_지도, 3D_모델
- 해설: 사전적 성격의 웹자원 (민백, 두산백과, 실록사전과 위키피디아 등 위키, 한국민속대백과, 바이두 등)
- Naver로 검색된 결과가 아닌 실제 URL로 기재(민백, 두산백과, 위키 등)
- 참고: 네이버 지식백과, 문화재청 등 원문, 해설이 아닌 모든 것
- 위키의 resource 칸에 3가지 Category 기재: 네이버 지식백과 > 문화원형백과, 네이버캐스트 등 > 하위 Category
- Data의 Label: 3가지 Category ☞ 항목
- 네이버 지식백과 > 네이버캐스트 > 인물한국사 ☞ 명성황후
Link 관련 지침
- 순접과 역접은 본인의 DATA에 따라 진행하면 됨. 둘다 맞다면 모두 유지할 예정
- 그림A-사건B: 본인의 data에 그림A와 연결된 노드가 많으면 A depices B, 사건B와 연결된 노드가 많으면 B isDepictedIn A
- 추상적으로 설명하면 isRelratedTo / 구체적으로 설명하게 되면 depicts과 같은 다른 relation이 되는 것
- ex. A라는 문헌은 B라는 인물과 isRelratedTo / A라는 문헌에 C라는 사건을 depicts, C라는 사건은 B라는 인물이 participatesIn
- 주의할 것: depicts: 문헌 등에 시각적으로 묘사한 것! (글은 mentions)
이칭의 노드화
- 조선_태조 - 이성계(고려의 장군)처럼 이칭이 반드시 필요한 경우만 별도 노드로 생성
- 사투리,약간의 표기차이 등 노드화할 가치가 없는 것은 좀더 비중이 있는 항목만 노드화하고, Label을 A/B로 할 것
집합node 신설
- 집합node란: 다양한 노드를 유형화하여 묶어준 node로 공node라고도 불림
- ex. 정해년진찬 물품 등
- 사진이 많은 경우 집합node 생성할 것
- 주 node와 집합 node를 연결하고, 집합node 내 개별자료는 집합 node랑만 연결 (중요node와 연결 X)
- ex. 건물(환구단) -isRelatedTo- 집합노드(label: 환구단 정비 기본계획 2007) - hasPart - 개별사진 노드
- ex. 건물(환구단) isRelatedTo 집합노드(label: 환구단 정비 기본계획 2007) hasPart 집합노드(도면) includes 개별도면
- Class: 하위노드의 Class를 동일하게 기재
- InfoUrl: 빈칸 가능하나, 해당 위키페이지에서 다양한 시각자료를 한번에 보여줄 수 있으면 더 좋음.
- 도면일 경우, 위키페이지에 모든 도면을 언제, 무슨 프로젝트에서 쓰인 도면인지 설명 등을 기재
- 도면 등 공node의 아이콘은 listing.png 이용 (http://digerati.aks.ac.kr/DhLab/2021/hanyang/icon/listing.png)
인물의 관직, 관청 관련 사항
관직 id
- 관직과 관청을 묶어서 id생성(의정부영의정 O, 영의정 X -> 관직명만 쓰는거 X)
- 2020 db에 둘다 있는 경우가 있는데, 관청 안붙은 id에 연결된 데이터가 있는 경우 따로 체크하여 이야기 주세요 (2021에는 관청명 붙은 id로 생성)
- 2020 db의 id 관직 앞에 증, 겸, 행, 수 붙어있는 것은 떼고 생각하시면 됩니다 (증: 죽고나서 붙는것, 겸: 겸직하는것, 행: 품계보다 낮은 관직 받는 것, 수: 품계보다 높은 관직 받는 것 / 2020: 증 영의정 -> 2021: 의정부영의정)
관청관직
- 인물의 관직은 민백에 있는 관직만 데이터화하면 되며, 관직과 관청정보는 네이버지식백과에서 찾으면 믿을만한 정보가 바로 나옵니다 (https://terms.naver.com/search.naver?query=%EB%8C%80%EC%A0%9C%ED%95%99&searchType=&dicType=&subject=) / ex. 대제학: 홍문관대제학, 예문관대제학 2가지가 있음!
- 관직에 대한 관청이 여러가지라 찾기 어려울 경우, 조선왕조실록사이트(http://sillok.history.go.kr/main/main.do)에서 인물 관직으로 치면 관련자료가 나옵니다(ex. 정사룡 대제학)
관직관청 관련 relation
- 인물 servedAs 관직 (ex. 인물 servedAs 의정부좌의정)
- 관직 isOfficialPositionOf 관청 (ex. 의정부좌의정 isOfficialPositionOf 의정부)
Node 관련 지침
개요
- 노드: 모든 개념을 노드화하는 것이 아님. 그래프 가독성을 고려하여 대상에 대한 해설은 해설문으로 설명하고, 굵직한 관계 혹은 유형화하여 다른 네트워크를 만들 것만 노드화할 것.
- 내가 이것을 유형화하여 그래프를 만들 것인가를 고려하여 노드화.
- 덕수궁_중화전(Architecture) - type 정전(Concept) - type 경복궁_근정전(Architecture)
- 위처럼 정전을 유형화하여 각 궁궐의 정전을 연결할 예정: 노드화 가능
- 덕수궁_중화전(Architecture) - type 정전(Concept)
- 위처럼 정전을 유형화하였으나 각 궁궐의 정절을 연결할 예정이 없으면: 노드화 불가능
- 덕수궁_중화전(Architecture) - type 정전(Concept) - type 경복궁_근정전(Architecture)
이름, 용도, 사용자가 바뀐 경우
- 별도 노드화 가능한 경우: 당시의 사진 및 자료가 있는 경우 노드화 가능
- ID는 현재의 권역_전각의 예전이름
- 덕수궁_태극전 (O)
- 경운궁_태극전 (X): 태극전은 덕수궁 이전의 경운궁 시절 중화전의 이름이나 ID 관리를 위하여 경운궁으로 명명하지 않음
- 덕수궁_태극전 (O)
Actor
- 인물 ID는 본명, 정식 명칭을 기준으로 정의
- 도산 안창호 -> 안창호
- 언더우드 -> 호러스_그랜트_언더우드
- 인물의 Label은 반드시 다음과 같이 기재
- 한글명(한자, 생~몰년)
- 영문이름 풀네임 (한글발음)
- remark 에는 Definition 기재
- 【생(시작)~몰년(끝)】. 이후 설명. (끝에 . 붙일 것)
- 날짜표기법: 2021-07-22 (연도 4자리-월 2자리-일2자리) / 음력: 2021-02-10(음) / 연도 혹은 년월만 제시되었을 경우: 1876년(고종 10)~1876-02월(음)
- 이칭은 모든 이칭(호 등)을 다 쓰지 말고 유의미한 것만을 적으며, isSameAs로 연결할 수 있는 것.
- 즉, 조선 태조-이성계, 왕비-대비가 되어 이름이 바뀌는 경우에만 기재
- 여러 개의 경우: ,_ 로 표현)
Event
- Label은 _제외한 id + 일자(기간)를 기재
- 13도 창의군 1907~1910, 가쓰라-태프트 비밀협약 1905, 경성고등연예관 설립 1910
- remark에는 시작연도와 종료연도 기재
- 날짜 표현은 Actor와 동일 -> 【생(시작)~몰년(끝)】. 이후 설명이 있으면 설명 기재. (끝에 . 붙일 것)
- 이칭은 많이 쓰이는 이칭을 기재 (ex.강화도조약-조일수호조규)
Place
- ID: 궁궐의 경우 큰건물 및 권역_부속건물
- 경복궁_근정전, 경복궁_광화문, 사직단_제기고, 사직단_삼문
- groupName: 객관, 교회, 궁궐, 극장, 능묘, 병원, 사당, 사찰, 서원, 서울시문화재표석, 시장, 외국공관, 장소, 제단, 주택, 진전, 호텔 등
- partName은 서울시문화재표석인 경우 기재
- 표석-고지명, 표석-관아, 표석-근대유산, 표석-서원/향교, 표석-왕실유적, 표석-인물유적
- 주소는 현대적 주소가 있는 경우 기재
- 경도와 위도는 확인하여 기재하고, 고도와 이칭은 필요한 경우 기재
- 지역구 이름은 해당 시 이름_Place 로 함 (Label은 시 이름 빼고)
- 서울_정동 (label은 정동), 서울_남산 (label은 남산)
Architecture
- Architecture는 3D모델, 3D지도의 대상이 되는 것이며 이외에는 Place 임
- groupName: 건축, 조형
- partName은 건축중 궁궐과 왕실인 경우 기재 : 건축-궁궐건축, 건축-왕실건축
Object
- 기록화: 라벨에는 작품명 《한자》(작품명 뒤에 공백 한칸)로 기재, 한자 부분에는 《한자》
- 강희언-인왕산도 《仁王山圖》
- remark에는 【제작일자】. 재료, 크기, 소장처 기재. (마침표 유의)
- 크기와 재료는 박물관 도록에 목록화되는 크기와 재료
- 【1600년】. 지본담채, 32.3×49.5㎝, 한국학중앙연구원 장서각.
- 【1583년경】. 견본수묵, 93.0×60.0㎝, 개인소장.
Record
- groupName: 그림, 금석문, 기록, 기사, 문헌, 뮤지컬, 사진, 사진첩, 신문, 엽서, 외국도서, 외국신문, 음악, 의궤, 의장, 일기, 천문도, 도면
- 저작년과 간행년(확인될 경우 기재)
- 외국서인 경우 간행국과 언어를 기재
- 이칭은 번역서가 따로 만들어져 있지 않으며 이름이 다를 경우 기재
- 옛사진 스캔한 자료 - remark에는 FTP 업로드한 url, 출처는 label에 표시 (예: 조선고적도보)
- 현재 사진(예: 일간지 보도에 실린 사진) - 실제 url 그대로 infoUrl 에 사용 / 출처는 label, 추가적인 캡션 내용은 remarks
- 도면도 모두 Record로 취급
Record vs Object
- 사진 Record , 유리원판도 Record
- 기념사진 isDerivativeOf (~의 파생물이다) 유리원판 및 기념일
Concept
- 모든 역사적 사실을 노드화할 필요는 없으며, 개념어의 뜻 풀이 시 필요
Multimedia
- 3D지도, 3D모델인 경우만!! (이외에는 Record)
- 노드의 접두어: 표석은 vmap-, 이외에는 3d-
- 3d-앨버트_테일러_가옥, vmap-관상감_터
Story
- Story 구성의 기준: 반드시 다른 Fact 노드들과 적어도 3개, 보통 5~6개는 Relation이 있어야 함
- groupName: 보통의 경우에는 Episode, Storyline은 다수개의 Episode를 포함
- Story의 주제별 번호(2021)
- E1: 덕수궁
- E2: 정동
- E3: 환구단
- E4: 남대문
- E5: 독립문
- E6: 서울역
- 권역 이외 Story: E0-000
- Story 중복 여부 재검토 필요. note에 담당자 이름 표시.
- 예) E1-012 Story Episode 고종황제 즉위 40주년 기념행사와 기념비각
- E1-026 Story Episode 고종황제 즉위 40주년과 망육 축하 진연
- E1-027 Story Episode 고종황제의 오순 축하 진연