Facebook Joinc 그룹
Joinc QA 사이트
Tweet
joinc는 Firefox와 chrome에서 테스트 했습니다. IE에서는 테이블이 깨지거나 이미지가 보이지 않을 수 있습니다. 특히 구글 Docs이미지의 경우 엑박처리될 수 있습니다.
Tweet
joinc는 Firefox와 chrome에서 테스트 했습니다. IE에서는 테이블이 깨지거나 이미지가 보이지 않을 수 있습니다. 특히 구글 Docs이미지의 경우 엑박처리될 수 있습니다.
joinc wiki를 운용해오면서, 각 문서들간의 관계를 그래프와 카테고리 형식으로 구성할 수 있을 것이라는 생각을 했습니다. 꽤 오래전 일이죠. 몇개의 아이디어들이 있었는데, 그중 TAG를 이용한 관계맵구성쪽 아이디어를 정리합니다.
아이디어와 가정
컨텐츠간의 관계를 맺어주기 위해서 생각하던 아이디어로, TAG를 기반으로 한 관계맵만들기에 대한 겁니다.
대량의 TAG셋을 분석할 수 있는 시스템이 갖추어져 있다면, 이를 분석해서 그래프, 카태고리를 만들 수 있을 겁니다.. 이를 위해서는 다음과 조건이 만족돼야 합니다.
- 사람은 연상되는 순서대로 태깅을 할 것이다.
![[http]](/modules/moniwiki/imgs/http.png)
자료구조
쉽게 다음과 같은 전형적인 태그셋이 존재하고 있다고 가정해 보겠습니다.
<리눅스,프로그래밍,C,Perl> <리눅스,시스템,Perl> <리눅스,시스템,보안,해킹,DDOS> <보안,DDOS> <운영체제,리눅스,KDE> <해킹,리눅스>이 태그셋은 아래에 설명하는 방법으로 category와 그래프 형식으로 표현가능 할 겁니다.
category like
이 태그셋을 다음과 같은 방식으로 처리를 하기로 했습니다.
- 태그를 하나 선택한다.
- 선택된 태그의 상위태그와 하위태그의 발생빈도 (이하 TF)를 계산한다. 위의 태그셋을 예로 든다면, 리눅스를 선택했을때, 프로그램밍은 1, 시스템은 2가 될 것이다. 이것은 또한 선택된 리눅스라는 태그와의 연관도를 위한 weight로 사용한다.
- category는 상/하위로 확장될 수 있어야 한다. 이것은 -,+로 결정할 수 있다. 상위 카테고리는 -, 하위 카테고리는 + 하는 식이다.
위의 색인테이블은 +,- 값을 이용해서 다음과 같이 재현할 수 있을 겁니다.
더불어 각각의 상하위 카테고리 TAG는 가중치를 가지고 있으므로, 가중치를 기준으로한 정렬도 가능하고요. 가중치가 있으니 "태그 추천"도 가능합니다.
위의 자료구조는 색인테이블과 RDBMS 어느 것을 사용해도 구현하는데 문제 없을 겁니다. 색인테이블을 이용한다면, 상/하위 카테고리를 위한 별도의 필드를 구현할 것이다. RDBMS라면 별도의 칼럼을 두는 식으로 구분할 수 있을 것이다. 요즘 말이 많은 NoSQL에 적합한 자료겠네요.
upper field : 리눅스 {시스템,프로그래밍,KDE}
lower field : 리눅스 {운영체제,해킹}
graph
관계맵에 더 가까운 형태는 그래프 형태의 자료구조일 겁니다. 그래프로의 재현은 위의 category 재현을 위해서 사용된 색인테이블을 그대로 이용할 수 있습니다. 색인 테이블 자체가 Adjacency List의 구조를 가지므로, 그래프로 재현하는데 무리가 없기 때문이죠.
아래의 Adjacency List 형태로 저장된 데이터는
다음과 같이 그래프로 재현할 수 있습니다.
그래프를 표현하는 방법으로 선택할 만한 또 다른 방법으로 Adjacency Matrix가 있을 건데, 이경우 위의 그래프정보는 아래처럼 저장을 하면 될겁니다. 컬럼기반 데이터 베이스를 이용한다면, 빠른 연산이 가능하겠죠.
| A | B | C | |
| A | 0 | 1 | 1 |
| B | 0 | 0 | 0 |
| C | 0 | 1 | 0 |
tag 연관성 알고리즘
태그를 선택하게 되면, 관련 tag들이 검색 될겁니다. 검색이라기 보다는 선택이라고 해야 할가요? 이때, 태그들간의 연관성을 계산할수 있는데요. 이 연관성은 각 노드를 연결하는 선의 굵기로 표현합니다. 이것은 태그들간의 거리가 되겠죠.
저는 다음의 두가지 요소의 곱으로 태그의 거리를 결정하기로 했습니다.
- TD
Tag Distence 로 선택된 태그셋에서, 태그와 태그의 거리다. 예컨데, {리눅스, <리눅스,시스템,Perl>} 에서 리눅스와 시스템과의 거리는 1/2, 리눅스와 Perl과의 거리는 1/3이 된다. 실제 공식에 적용할 때에는 log를 이용해서 스케일을 조정할 필요가 있다.
- TF
Tag Frequency 로 해당 태그를 포함한 태그셋의 수치에 관한 것이다.
다음은 이 알고리즘의 프로시져코드입니다.
TagName = GetAllTagName(); TagList = GetAllTagList(); i = 0; j = 0; map<TAGNAME,SCORE> TAGSCORE; TAGSCORE.TAGNAME = TagName; while(i < TagName.size()) { while(j < TagList.size()) { if (TagList.find(Tagname[i])) TAGSCORE[Tagname[i]].SCORE += (1/distance); j++; } i++; } i = 0; while(i < TAGSCORE.size()) { makeIndexTable(TAGSCORE[i]); i++; }
생각해볼 문제들
사실과 가치
아이디어를 구현하는 것은 큰 문제가 되지 않을 겁니다. 그러나 구현할 수 있다고 하는 것과 구현한게 가치가 있는 것이냐 하는 건 별개의 문제가 될 것 같네요. 블로거들에게 가치가 있는 구현물이 될 것인가 ? 검색과의 차이는 무엇인가. 검색이 가져다 줄 수 없는 가치를 줄 수 있는가 ?
- 태그의 특징과 가치에 대한 생각들 : 정리좀 해야할 듯.