"0302 회의"의 두 판 사이의 차이
Encyves Wiki
(→위키기사 집필안: 교수님 지침) |
|||
| (사용자 4명의 중간 판 15개는 보이지 않습니다) | |||
| 8번째 줄: | 8번째 줄: | ||
}} | }} | ||
{{clickable button|[[0223 회의]]}} | {{clickable button|[[0223 회의]]}} | ||
| − | {{clickable button|[[ | + | {{clickable button|[[0308 회의]]}} |
<br/> | <br/> | ||
*자유롭게 수정해 주세요~ | *자유롭게 수정해 주세요~ | ||
| 57번째 줄: | 57번째 줄: | ||
=='''회의내용 정리'''== | =='''회의내용 정리'''== | ||
| + | ===다음주 회의 주제=== | ||
| + | * 각 팀별 새로운 기사 모델 제시 | ||
| + | * 오늘 논의된 내용 중 표준화된 결과물을 보일 수 있는 모델 제시 | ||
| + | |||
===위키기사 집필안: 교수님 지침=== | ===위키기사 집필안: 교수님 지침=== | ||
* 온톨로지 RDF 트리플의 naming guideline(명명 지침) 결정해야 | * 온톨로지 RDF 트리플의 naming guideline(명명 지침) 결정해야 | ||
** '관련항목'의 최종형태는 graph이다. 문장으로 사람들에게 이해시키지 않을 것이므로, RDF 트리플의 naming guideline(명명 지침)을 어떻게 표현하는 것이 좋을지 각 팀에서 결정해야 한다. | ** '관련항목'의 최종형태는 graph이다. 문장으로 사람들에게 이해시키지 않을 것이므로, RDF 트리플의 naming guideline(명명 지침)을 어떻게 표현하는 것이 좋을지 각 팀에서 결정해야 한다. | ||
| − | |||
| − | |||
* 관련항목 | * 관련항목 | ||
** 메타데이터(data type property)에 기술되지 않은 새로운 관계성 정보에 대하여 추가적으로 기술할 필요가 있을 것(ex: 한글고문헌팀_A가 B를 기증하였다.) | ** 메타데이터(data type property)에 기술되지 않은 새로운 관계성 정보에 대하여 추가적으로 기술할 필요가 있을 것(ex: 한글고문헌팀_A가 B를 기증하였다.) | ||
| 67번째 줄: | 69번째 줄: | ||
*** primitive value는 시간값, 공간값 등과 같은 value나, 경우에 따라 공유될 수 있는 객관적 노드가 아닌, 해당 DB에만 해당되는 데이터. | *** primitive value는 시간값, 공간값 등과 같은 value나, 경우에 따라 공유될 수 있는 객관적 노드가 아닌, 해당 DB에만 해당되는 데이터. | ||
*** 대상이 오브젝트인지, 값인지.. 이런 부분들을 고려하여 관계의 틀을.. 전체 네 개의 DB 잡아줄 수 있는 걸 정해야. | *** 대상이 오브젝트인지, 값인지.. 이런 부분들을 고려하여 관계의 틀을.. 전체 네 개의 DB 잡아줄 수 있는 걸 정해야. | ||
| − | *** primitive value와 별도의 | + | *** primitive value와 별도의 노드는 나누기 보다, 일관적으로 다 넣는것이 좋을듯 |
| − | |||
** 주어에 대한 공통된 약속 필요 | ** 주어에 대한 공통된 약속 필요 | ||
| − | *** p.v 와 object property를 모두 보여주기 위해선 | + | *** p.v 와 object property를 모두 보여주기 위해선 주어와 목적어 앞에 class를 달아야. 전체적인 틀을 어떻게 할 것인지는 나온 케이스들을 가지고 잡아가면 됨. |
| − | + | ** 관련항목 포맷을 정해야! | |
| − | ** 포맷을 정해야 | + | *** 해당 노드에서 확장될 의미가 없는 3차 노드도 기술하기도 좋을듯. 이를 위하여 포맷을 어떻게 정할지 많이 늦기 전에 정해야 함. 아직까지는 데이터를 모아놓고 경우의 수를 보는 단계. |
| − | *** | + | * graph에 대한 논의 |
| − | + | ** 1, 2차적 관계만 뽑아서 별도의 최종적으로 보여줄 그래프를 만들지, 아니면 전체적인 그래프와 그것에 대한 응용은 기획기사 레벨이나 다른 레벨에서 활용하고 개별항목에서 보여지는 것은 1, 2차적 관계만 시각화할지는 나중에 시각화 과정에서 결정할 것. | |
| − | * | + | ***그 방법을 정하기 위해 교수님께 기초데이터 제공해 줄 필요가 있으나, 해당 기사에서 작성된 관련항목만을 그래프를 표시해주는 것이 괜찮은 방법이라 생각된다면 그렇게 할 수 있고... 데이터 입력시 graph와 표가 스위칭할 수 있는 프로그램 만들수도 있음.어떤 전략을 취할지는 데이터가 있어야. 관련항목과 필요한 그래프 만들면서 그 차이를 체크할 것 |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | ** | ||
| − | 그 방법을 정하기 위해 | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | [[분류:프로젝트관리]] | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
2017년 6월 14일 (수) 19:50 기준 최신판
| 0302 회의 | |
|---|---|
| 주간회의 | |
| 일시 | 2017/03/02(목) 오후 3시 ~ |
| 장소 | 대학원 103호 |
| 참석자 | 강혜원, 김누리, 김미정, 김바로, 김사현, 김선미, 김지선, 김현규, 김현승, 류인태, 서동신, 서소리, 이혜영, 장동룡, 장원석, 정주영, 차서연, 최한샘, 허호 (19명) |
| 비고 | 김현 교수님 참석 |
- 자유롭게 수정해 주세요~
목차
회의 안건
신규 연구보조원
- 김선미, 김현규, 이혜영, 최한샘 (석사과정)
- 정주영
중심기사 검토
팀별 기사 작성 진행 상황
한글고문서
승탑비문
궁중기록화
민족기록화
답사계획
| 날짜 | 답사지역 | 참석자 | 비고 |
|---|---|---|---|
| 3/3(금) - 4(토) | 문경 | 강혜원, 김사현, 김바로 | 원래 예정했던 "예천 명봉사"가 수리중이어서 촬영 불가. 충주 억정사지와 충주 정토사지로 대체. |
| 3/10 (금) | 회암사지, 태고사 | 강혜원, 김사현, 서소리 | 3/3(금) 여비신청서 제출 예정 |
| 3/12 (일) | 매소성, 행주산성 | 장동룡, 김누리 | 3/6(월) 여비신청서 제출 예정 |
| 3/17 (금) - 18(토) | 충주 | 강혜원, 김사현, 서소리 | 3/8(수) 여비신청서 제출 예정 |
- 업무의 효율성을 위해서 앞으로는 답사팀에서 직접 일정을 계획하고 여비신청서를 작성해주셨으면 합니다.
- 여비신청서 작성과 관련하여 간단하게 몇가지 지침을 알려드릴 예정입니다.
- 늦어도 답사 출발일 7일 전에는 제출해야 하니, 답사를 계획하고 있는 팀에서는 참고해주세요.
- 각 팀에서 작성해서 강혜원에게 메일로 주시면, 검토 후 연구행정실에 제출하겠습니다.
회의내용 정리
다음주 회의 주제
- 각 팀별 새로운 기사 모델 제시
- 오늘 논의된 내용 중 표준화된 결과물을 보일 수 있는 모델 제시
위키기사 집필안: 교수님 지침
- 온톨로지 RDF 트리플의 naming guideline(명명 지침) 결정해야
- '관련항목'의 최종형태는 graph이다. 문장으로 사람들에게 이해시키지 않을 것이므로, RDF 트리플의 naming guideline(명명 지침)을 어떻게 표현하는 것이 좋을지 각 팀에서 결정해야 한다.
- 관련항목
- 메타데이터(data type property)에 기술되지 않은 새로운 관계성 정보에 대하여 추가적으로 기술할 필요가 있을 것(ex: 한글고문헌팀_A가 B를 기증하였다.)
- primitive value 관련
- primitive value는 시간값, 공간값 등과 같은 value나, 경우에 따라 공유될 수 있는 객관적 노드가 아닌, 해당 DB에만 해당되는 데이터.
- 대상이 오브젝트인지, 값인지.. 이런 부분들을 고려하여 관계의 틀을.. 전체 네 개의 DB 잡아줄 수 있는 걸 정해야.
- primitive value와 별도의 노드는 나누기 보다, 일관적으로 다 넣는것이 좋을듯
- 주어에 대한 공통된 약속 필요
- p.v 와 object property를 모두 보여주기 위해선 주어와 목적어 앞에 class를 달아야. 전체적인 틀을 어떻게 할 것인지는 나온 케이스들을 가지고 잡아가면 됨.
- 관련항목 포맷을 정해야!
- 해당 노드에서 확장될 의미가 없는 3차 노드도 기술하기도 좋을듯. 이를 위하여 포맷을 어떻게 정할지 많이 늦기 전에 정해야 함. 아직까지는 데이터를 모아놓고 경우의 수를 보는 단계.
- graph에 대한 논의
- 1, 2차적 관계만 뽑아서 별도의 최종적으로 보여줄 그래프를 만들지, 아니면 전체적인 그래프와 그것에 대한 응용은 기획기사 레벨이나 다른 레벨에서 활용하고 개별항목에서 보여지는 것은 1, 2차적 관계만 시각화할지는 나중에 시각화 과정에서 결정할 것.
- 그 방법을 정하기 위해 교수님께 기초데이터 제공해 줄 필요가 있으나, 해당 기사에서 작성된 관련항목만을 그래프를 표시해주는 것이 괜찮은 방법이라 생각된다면 그렇게 할 수 있고... 데이터 입력시 graph와 표가 스위칭할 수 있는 프로그램 만들수도 있음.어떤 전략을 취할지는 데이터가 있어야. 관련항목과 필요한 그래프 만들면서 그 차이를 체크할 것
- 1, 2차적 관계만 뽑아서 별도의 최종적으로 보여줄 그래프를 만들지, 아니면 전체적인 그래프와 그것에 대한 응용은 기획기사 레벨이나 다른 레벨에서 활용하고 개별항목에서 보여지는 것은 1, 2차적 관계만 시각화할지는 나중에 시각화 과정에서 결정할 것.
