Database Lab

사용자 도구

사이트 도구

추적:
2018_07

차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

차이 보기로 링크

양쪽 이전 판 이전 판
다음 판 		이전 판
2018_07 [2018/07/24 06:59]
ehmoon 		2018_07 [2021/04/13 06:54] (현재)
줄 1: 줄 1:
-===== 6일 금요일 =====+===== 06일 금요일 =====
  
 [Develop] [Develop]
줄 19: 줄 19:
 \\ \\
  
-===== 9일 월요일 =====+===== 09일 월요일 =====
  
 [Develop] [Develop]
줄 464: 줄 464:
  
 서베이 진행해야 함. 서베이 진행해야 함.
 +
 +\\
 +\\
 +\\
 +
 +===== 25일 수요일 =====
 +
 +[Research]
 +
 +Web Content Extraction 에서의 Scoring 방법론 관련 논문을 찾아보니 생각보다 많이 나오지는 않음.
 +
 +google scholar 에서 2개 정도 논문 찾음
 +
 +(1) Evaluating Web Content Extraction Algorithm
 +
 +(2) Evaluation Content Extraction on HTML Documents
 +
 +첫 번째 논문은 스로베니아의 류블랴나 대학교에서 쓴 학위논문이고, 처음 abstrict에서는 web content
 +
 +extraction algorithm을 평가하는 방법에 대해 서베이한다는 것처럼 말하고 있어서 기대했는데
 +
 +막상 읽어보니 서베이라기보단 자신들의 한 가지 방법론을 제시하고 있고 다양한 알고리즘들에 대해서
 +
 +실험해보는 내용임. 여기서 제안하고있는 평가 방법은 Longest Common Subsequence (LCS)
 +
 +즉 HTML code 끼리 text 일치성을 비교하겠다는 의미. python으로 구현했고, 평가는 잘 된다고 나와있음.
 +
 +몇가지 아쉬웠던 점은 아이디어가 그닥 신선하지는 않았고, 정답 Set 만드는 과정이 명확하게 제시돼있지
 +
 +않음. 그리고 여기서 제시하는 것처럼 단순히 text로만 비교를 한다면 생기는 논리적 모순이 발생할 것 같음.
 +
 +예를들어 비슷한 구조를 갖고있는 생뚱맞은 2개의 영역이 있다고한다면 그 2개는 코드가 비슷할테고
 +
 +일치성이 높게 판단될 것. 단순한 LCS 비교로는 이러한 문제를 잡지 못할것임.
 +
 +영역과 면적을 비교한다던지 DOM Tree 를 비교하는 등 구조적인 특징을 잡아야 함.
 +
 +\\
 +\\
 +\\
 +
 +===== 26일 목요일 =====
 +
 +[Research]
 +
 +content extraction evaluating 논문 중 두번째 논문 읽음.
 +
 +이 논문은 독일의 마인츠 대학교에서 쓴 논문이고 content extraction 분야에서 유명한 논문들이
 +
 +reference 했음. 이전 논문에 비해서 좋았던 점은 정답 Set을 정한 기준과 방법에 대해 명확히 제시하고
 +
 +있고, 자신들이 개발한 프레임워크를 설명하는 부분도 있음.
 +
 +아직 다 읽어보지는 못했지만 여기서는 어떤 아이디어를 냈나 대충 읽어보니 여기도 역시
 +
 +text 비교를 하는것 같음. 이전 논문처럼 LCS를 사용했는지는 아직 모르겠지만 비교 단위를 characters, 
 +
 +sequence of words, bag of words, set of words 등으로 분류하는것을 보아 LCS는 아닌것 같음.
 +
 +text를 비교한다는 내용 보고 솔직히 기대는 안되지만 뒤에 실험부분이나 output format 같은 부분은
 +
 +도움이 될 것 같음.
 +
 +\\
 +\\
 +\\
 +
 +===== 27일 금요일 =====
 +
 +[Research]
 +
 +Evaluation Content Extraction on HTML Documents 논문 읽음.
 +
 +어제 대충 읽어봤던대로 이 논문은 content extraction 알고리즘을 평가하는 방법론에 대해 제시하고 있음.
 +
 +인상깊었던 점은 date set을 저장하는 방식이 html 방식이였고, 구체적인 내용을 정의하고있는 meta data를
 +
 +따로 만들었음. 그리고 정답 set을 정의하는 포맷은 text 형식이었음. recall과 precision을 계산하는
 +
 +metric이 text이기 때문에 정답 set 역시 text로 저장해도 무방함.
 +
 +나같은 경우에는 xpath로 저장했었는데 나도 만약 text 비교로 성능을 측정한다면 이와 같이 해도
 +
 +좋겠다는 생각을 함.
 +
 +프레임워크의 아키텍쳐같은 경우는 내가 만들고 있는 방식이랑 거의 유사했음. 다만 이 논문에서는
 +
 +알고리즘별로 연산시간도 뽑아내고 있으므로 단순한 server가 아닌 proxy server를 사용하고 있음.
 +
 +baseline으로 제시한 알고리즘은 Plain, BTE, Crunch, DSC, LQF 로 총 5가지.
 +
 +plain같은 경우는 저자가 proxy 서버에 남아있는 정보를 이용한다는 간단한 아이디어로 구현한것이고
 +
 +나머지 4가지는 기존에 제시된 CE 알고리즘들임.
 +
 +성능은 데이터셋의 종류에 따라 제각각이지만 대부분의 경우에서 DSC가 높게 측정됨.
 +
 +related work로 제시된 논문들은 몇가지 있었으나 딱히 흥미로운 것은 없었음.
 +
 +이 분야에서 성능을 측정하는 방법론에 대해 제시된게 거의 없는 것 같음.
 +
 +사실 이 논문의 저자도 CE 에서의 성능 측정을 IR 에서의 정보 검색률로 생각한 것임.
 +
 +
 +\\
 +\\
 +\\
 +
 +===== 30일 월요일 =====
 +
 +휴가
 +
 +\\
 +\\
 +\\
 +
 +===== 31일 화요일 =====
 +
 +휴가
 +
 +\\
 +\\
 +\\
 +
  
2018_07.1532415597.txt.gz · 마지막으로 수정됨: 2021/04/13 06:54 (바깥 편집)

문서 도구

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki