KR20060004909A - 시맨틱 지식의 검색, 관리, 포착, 공유, 발견, 전달 및프리젠테이션 시스템 및 방법 - Google Patents

Abstract

본 발명은 지식 검색, 관리, 포착, 공유, 발견, 전달 및 프리젠테이션을 위한 통합 구현 프레임워크 및 그 결과로 얻어지는 매체에 관한 것이다. 본 시스템은 시맨틱 정보를 유지하는 일을 한다.

지식검색, 시맨틱, 정보, 공유, 관리, 통신

Description

시맨틱 지식의 검색, 관리, 포착, 공유, 발견, 전달 및 프리젠테이션 시스템 및 방법{SYSTEM AND METHOD FOR SEMANTIC KNOWLEDGE RETRIEVAL, MANAGEMENT, CAPTURE, SHARING, DISCOVERY, DELIVERY AND PRESENTATION}

우선권 주장

본 출원은 2002년 2월 28일자로 출원된 미국 가특허출원 제60/360,610호 및 2001년 6월 22일자로 출원된 미국 가특허출원 제60/300,385호에 대한 우선권을 주장하여 2002년 6월 24일자로 출원된 미국 특허 출원 제10/179,651호의 일부 계속 출원이다. 본 출원은 또한 2002년 6월 24일자로 출원된 PCT/US02/20249호에 대한 우선권을 주장한다. 상기 출원들 모두는 본 명세서에 완전히 기재된 것처럼 전체적인 인용에 의해 본 명세서에 포함된다.

저작권 고지

본 개시 내용은 미국 및 국제 저작권법 하에 보호된다, ⓒ 2002 - 2004 Nosa Omoigui. 모든 권리 유보되어 있음. 본 특허 문서의 개시 내용의 일부분은 저작권의 보호를 받는 자료를 포함하고 있다. 저작권자는 특허 문서 또는 특허 개시 내용이 미국 특허상표청의 특허 파일 또는 기록에 있을 때는 이를 누구라도 팩시밀리 복제하는 것에 대해서 이의를 제기하지 않지만, 그렇지 않다면 어떤 경우에도 모든 저작권을 유보한다.

본 발명은 일반적으로 컴퓨터에 관한 것이며, 보다 구체적으로는 정보 관리 및 조사 시스템에 관한 것이다.

본 발명의 일반적인 배경 기술은 동시 계류 중인 특허 출원(2002년 6월 24일자로 출원된 미국 출원 제10/179,651호)에 기술되어 있으며, 이는 여기에 인용함으로써 그 전체 내용이 본 명세서에 포함되고, 본 출원은 위 출원의 일부 계속 출원이다.

본 발명은 부분적으로는 본 출원인의 동시 계류 중인 특허 출원(2002년 6월 24일자로 출원된 미국 출원 제10/179,651호)에 보다 충분히 기술되어 있는 시맨틱적으로 통합된 지식(semantically integrated knowledge)의 검색, 관리, 전달, 및 프리젠테이션 시스템에 관한 것이다. 본 발명 및 시스템은 이하의 상세한 설명에 보다 충분히 기술되어 있는 바와 같이, 엔티티(entity), 프로파일(profile) 및 시맨틱 쓰레드(semantic thread)(이에 한정되는 것은 아님)를 비롯하여 몇 가지 부가적인 개선된 특징, 향상 및/또는 특성을 포함한다.

이하에서, 첨부도면을 참조하여 본 발명의 바람직한 대체가능한 실시예들이 상세하게 설명된다.

도 1은 부분적인 스크린 사진 개요, 또한 도 2는 특허 심사관이 종래 기술 검색에서 바람직한 실시예를 사용하는 시나리오에 대한 도 1의 대화 상자를 확대한 것으로서 "자기 공명 영상(Magnetic Resonance Imaging)"이 의약 분류에 있는 경우의 스크린 사진을 나타낸 도면.

도 3은 스마트 요청으로 SQML 버퍼를 캡슐화하는 바이너리 문서 포맷인 공유가능 스마트 요청 시스템(Sharable Smart Request System) 상호 작용을 나타내고 또한 확장자 핸들러가 어떻게 문서 열기를 행하는지를 나타낸 도면.

도 4A는 문서 파일의 부분적인 스크린 사진 개요를 나타낸 도면.

도 4B는 Windows 쉘에서 등록된 연결(registered association)을 갖는 도 4A로부터의 2개의 .REQ 문서(맨 오른쪽에 타이틀이 'Headlines on Reuters Related to My Research Report(Live)' 및 'Headlines on Reuters (as of January 21 2003, 08 17 AM)'으로 되어 있음)의 예시를 나타낸 도면.

도 5는 텍스트-음성 변환(Text-to-Speech) 객체 스킨을 예시한 다이어그램으로서 텍스트-음성 변환 객체 스킨을 통해 렌더링되는 이메일 메시지의 예시를 나타낸 도면.

도 6은 텍스트-음성 변환 요청 스킨을 예시한 다이어그램.

도 7은 제약 회사 예에 대한 지식 모델링을 예시한 다이어그램.

도 8은 클라이언트 컴포넌트 통합 및 상호 작용 작업 흐름을 예시한 다이어그램.

도 9 내지 도 11은 카테고리 탐색(Explore Categories) 대화 상자의 3가지 서로 다른 뷰를 나타낸 도면.

도 12 및 도 13은 동작 중에 있는 일건서류(Dossier) 스마트 렌즈의 샘플 스 크린 사진을 나타낸 도면.

도 14는 서버측 시맨틱 쿼리 프로세서가 들어오는 시맨틱 쿼리(SQML로서 표현됨)를 어떻게 처리하는지를 나타낸 도면.

도 15는 2가지 프로파일("My Profile(내 프로파일)"이라는 이름의 디폴트 프로파일 및 "Patents(특허)"라는 이름의 프로파일)을 보여주는 시맨틱 브라우저로서 사용자가 방해를 받지 않고 2가지 프로파일 둘다를 통해 그의 지식 세계를 어떻게 네비게이션 할 수 있는지를 보여주는 도면.

도 16A 내지 도 16C는 사용자가 프로파일을 어떻게 구성하는지(프로파일을 생성하기 위해, 사용자는 "프로파일 생성 마법사(Create Profile Wizard)"를 사용하고 이어서 이 프로파일은 다른 도면들에 도시한 바와 같이 프로퍼티 시트(property sheet)를 통해 수정될 수 있음)를 예시한 도면.

도 17은 "요청 생성 마법사(Create Request Wizard)"로 요청을 생성할 때 사용자가 프로파일을 어떻게 선택하는지를 나타낸 도면.

도 18은 상기한 동작들 및 특징들 중 일부를 나타낸 "스마트 스타일(Smart Styles)" 대화 상자를 갖는 스크린 사진을 나타낸 도면.

도 19는 "스마트 요청 감시(Smart Request Watch)" 대화 상자를 나타낸 도면.

도 20은 필터링된 스마트 요청들(Filtered Smart Requests)(예를 들어, Headlines on Wireless)을 디스플레이하는 감시 윈도우(Watch Window)를 나타낸 것으로서 현재 스마트 요청 타이틀(Current Smart Request Title)을 갖는 감시 윈도 우를 예시한 도면.

도 21은 시맨틱 브라우저에 디스플레이된 엔티티 뷰를 나타낸 도면.

도 22A 및 도 22B는 지식 커뮤니티 가입을 위한 UI를 나타낸 도면.

도 23은 시맨틱 쓰레드 객체 및 그의 시맨틱 링크를 나타낸 도면.

도 24 내지 도 46B는 상세한 설명에 기술되는 기능들, 옵션들 및 동작들에 대해 추가적으로 보여주는 부가적인 스크린 사진을 나타낸 도면.

도 47은 제약/바이오기술 업계에 대한 샘플 시맨틱 이미지(DNA 나선 구조)를 나타낸 도면.

도 48은 속보(Breaking News) 컨텍스트 템플릿에 대한 시맨틱적으로 적절한 이미지 시각화의 예시를 나타낸 도면.

도 49는 시각화 - 스마트 모래시계, 삽입 페이지(interstitial page), 화면 전환 효과(transition effect), 배경 크롬 도금(background chrome), 등에 대한 샘플 이미지(헤드라인)를 나타낸 도면.

도 50은 시각화를 나타낸 것으로서 스마트 모래시계, 삽입 페이지, 화면 전환 효과, 배경 크롬 도금, 등에 대한 샘플 이미지(책상에서 공부하고 있는 두 사람)를 나타낸 도면.

도 51은 시맨틱 "뉴스 메이커(Newsmaker)" 시각화, 또는 스마트 모래시계, 삽입 페이지, 화면 전환 효과, 배경 크롬 도금, 등에 대한 샘플 이미지를 나타낸 도면.

도 52는 시맨틱 "다가오는 행사들(Upcoming Events)" 시각화 - 스마트 모래 시계, 삽입 페이지, 화면 전환 효과, 배경 크롬 도금, 등에 대한 샘플 이미지를 나타낸 도면.

도 53은 시각화 - 스마트 모래시계, 삽입 페이지, 화면 전환 효과, 배경 크롬 도금, 등에 대한 샘플 이미지(페트리 접시(Petri dish))를 나타낸 도면.

도 54는 시맨틱 "역사(History)" 시각화 - 스마트 모래시계, 삽입 페이지, 화면 전환 효과, 배경 크롬 도금, 등에 대한 샘플 이미지를 나타낸 도면.

도 55는 시맨틱 시각화 - 스마트 모래시계, 삽입 페이지, 화면 전환 효과, 배경 크롬 도금, 등에 대한 샘플 이미지(우주선)를 나타낸 도면.

도 56은 시맨틱 "최고 제품(Best Buys)" 시각화 - 스마트 모래시계, 삽입 페이지, 화면 전환 효과, 배경 크롬 도금, 등에 대한 샘플 이미지를 나타낸 도면.

도 57은 시맨틱 시각화 - 스마트 모래시계, 삽입 페이지, 화면 전환 효과, 배경 크롬 도금, 등에 대한 샘플 이미지(커피)를 나타낸 도면.

도 58은 스마트 모래시계, 삽입 페이지, 화면 전환 효과, 배경 크롬 도금, 등에 대한 "클래식(Classics)"에 대한 시맨틱적으로 적절한 샘플 이미지(자동차)를 나타낸 도면.

도 59는 시맨틱적으로 적절한 "추천" 시각화 - 스마트 모래시계, 삽입 페이지, 화면 전환 효과, 배경 크롬 도금, 등의 컨텍스트/응용 요소에 대한 샘플 이미지(엄지손가락을 들어보임)를 나타낸 도면.

도 60은 시맨틱 "오늘" 시각화 - 스마트 모래시계, 삽입 페이지, 화면 전환 효과, 배경 크롬 도금, 등의 컨텍스트/응용 요소에 대한 샘플 이미지를 나타낸 도 면.

도 61은 시맨틱 "주석 첨부된 아이템" 시각화 - 스마트 모래시계, 삽입 페이지, 화면 전환 효과, 배경 크롬 도금, 등에 대한 샘플 이미지를 나타낸 도면.

도 62는 시맨틱 "주석" 시각화 - 스마트 모래시계, 삽입 페이지, 화면 전환 효과, 배경 크롬 도금, 등에 대한 샘플 이미지를 나타낸 도면.

도 63은 시맨틱 "전문가" 시각화 - 스마트 모래시계, 삽입 페이지, 화면 전환 효과, 배경 크롬 도금, 등에 대한 샘플 이미지를 나타낸 도면.

도 64는 시맨틱 "장소" 시각화 - 스마트 모래시계, 삽입 페이지, 화면 전환 효과, 배경 크롬 도금, 등에 대한 샘플 이미지를 나타낸 도면.

도 65는 시맨틱 "믹서" 시각화 - 스마트 모래시계, 삽입 페이지, 화면 전환 효과, 배경 크롬 도금, 등에 대한 샘플 이미지를 나타낸 도면.

도 66 내지 도 84는 각각 이하의 정보 객체 타입, 즉 문서, 책, 잡지, 프리젠테이션, 이력서, 스프레드쉬트, 텍스트, 웹 페이지, 백서, 이메일, 이메일 주석, 이메일 배포 리스트, 행사, 회의, 멀티미디어, 온라인 과정, 사람, 고객 및 사용자에 대한 시맨틱 시각화를 나타낸 도면.

도 85는 시맨틱 "타임라인(Timeline)" 시각화 - 스마트 모래시계, 삽입 페이지, 화면 전환 효과, 배경 크롬 도금, 등에 대한 샘플 이미지를 나타낸 도면.

목 차

A. 부가적인 예시적 시나리오

1. 특허 심사관 종래 기술 검색 도구

2. 바이오기술 회사 연구 시나리오

B. 정보 신경 시스템의 바람직한 실시예의 주제

1. 스마트 선택 렌즈 개요

2. 사람(Person) 객체 개요 붙여넣기

3. 스마트 요청 개요의 저장 및 공유

4. 스마트 스냅샷 개요의 저장 및 공유

5. 가상 지식 커뮤니티

6. 시간에 민감한 시맨틱 쿼리의 구현

7. 텍스트-음성 변환 스킨 개요

8. 언어 번역 스킨

9. 사용자 경험에서의 제1 클래스 객체로서의 카테고리

10. 카테고리화된 주석

11. 부가적인 컨텍스트 템플릿

12. 사용자 상태의 가져오기 및 내보내기

13. 로컬 스마트 요청

14. 통합된 네비게이션

15. 방문 결과에 대한 힌트

16. 지식 연합(Knowledge Federation)

17. 익명의 주석 및 게시

18. 시맨틱 브라우저에서의 오프라인 지원

19. 시맨틱 브라우저에서의 보장된 교차 플랫폼 지원

20. 지식 모델링

21. KIS 하우스키핑 규칙

22. 클라이언트 컴포넌트 통합 및 상호작용 작업 흐름

23. 카테고리 대화 상자 사용자 인터페이스 규격

24. 클라이언트 지원 서버 데이터 일관성 검사

25. 클라이언트측 중복물 검출

26. 클라이언트측 가상 결과 커서

27. 가상 싱글 사인온(Virtual Single Sign-On)

28. 네임스페이스 객체 동작 매트릭스

29. 동적 엔드-투-엔드 온톨로지/분류 업데이트 및 동기화

30. 일건서류(Dossier)(가이드) 쿼리의 호출

31. 지식 커뮤니티(에이전시) 시맨틱스

32. 동적 온톨로지 및 분류 매핑

33. 시맨틱 경고 최적화

34. 시맨틱 "뉴스" 이미지

35. 시맨틱 이미지를 동적으로 선택

36. 동적 지식 커뮤니티(에이전시) 콘택트 멤버쉽

37. 통합된 완전-텍스트 키워드 및 어구 인덱싱

38. 시맨틱 "객체를 읽음으로 마크함"(Semantic "Mark Object as Read")

39. 다중 선택 객체 렌즈

40. 온톨로지 기반 필터링 및 스팸 관리

41. 결과 세분화

42. 정보 스토어의 시맨틱 관리

43. 계산자 필터 사용자 인터페이스

C. 서버측 시맨틱 쿼리 프로세서 규격

1. 개요

2. 시맨틱 관련성 점수

3. 시맨틱 관련성 필터

4. 시간 민감성 필터

5. 지식 타입 시맨틱 쿼리 구현

D. 정보 신경 시스템에 대한 확장가능한 클라이언트측 사용자 프로파일 규격

E. 정보 신경 시스템에 대한 스마트 스타일 규격

1. 스마트 스타일 개요

2. 암시적인 동적 스마트 스타일 프로퍼티

F. 정보 신경 시스템에 대한 스마트 요청 감시 규격

1. 개요

2. 요청 감시 리스트(RWL) 및 그룹(RWG)

3. 통지 관리자(NM)

4. 감시 그룹 모니터

5. 감시창

6. 감시 윈도우

7, 감시 리스트 부록

G. 정보 신경 시스템에 대한 엔티티 규격

1. 소개

2. 포트폴리오(또는 엔티티 컬렉션)

3. 샘플 시나리오

H. 정보 신경 시스템에 대한 지식 커뮤니티 브라우징 및 가입 규격

I. 정보 신경 시스템에 대한 클라이언트측 시맨틱 쿼리 문서 규격

1. 시맨틱 쿼리 마크업 언어(SQML) 개요

2. SQML 생성

3. SQML 파싱

J. 정보 신경 시스템에 대한 시맨틱 클라이언트측 런타임 콘트롤 API 규격

1. Nervana 시맨틱 런타임 콘트롤 소개 - 개요

2. Nervana 시맨틱 런타임 콘트롤 API

3. 이메일 콘트롤 API

4. 사람 콘트롤 API

5. 시스템 콘트롤 이벤트

K. 정보 신경 시스템에 대한 보안 규격

1. 허가

2. 사람 그룹

3. 식별자 메타데이터 연합

4. 액세스 제어

L. 정보 신경 시스템에 대한 깊이있는 정보 규격

M. 정보 신경 시스템에 대한 요청 생성 마법사 규격

N. 정보 신경 시스템에 대한 프로파일 생성 마법사 규격

O. 정보 신경 시스템에 대한 북마크 생성 마법사 규격

1. 북마크 생성 마법사 소개

2. 시나리오

3. 지능적 게시 - 툴 메타데이터 제안 및 유지

P. 정보 신경 시스템™에 대한 시맨틱 쓰레드 규격

1. 시맨틱 쓰레드

2. 시맨틱 쓰레드 대화

3. 시맨틱 쓰레드 관리

Q. 샘플 스크린 사진

R. 정보 신경 시스템에 대한 시맨틱 쿼리 정의 및 시각화에 대한 규격

1. 시맨틱 이미지 및 움직임

2. 스마트 모래시계

3. 시각화 - 컨텍스트 템플릿

현재 바람직한 실시예에서, 본 시스템은 상기 특허출원 및 이 CIP에 기술된 특징 및 기능을 포함한다.

A. 부가적인 예시 시나리오

이하의 시나리오는 본 시스템의 효용성 및 동작을 설명하는 데 도움을 주며, 그에 따라 상세한 설명의 나머지를 파악하고 이해하는 것을 보다 쉽게 해준다.

1. 특허 심사관 종래 기술 검색 도구

대체로 미국 특허상표청 수수료의 전용 때문에, 아주 적은 시간에 확고한 종래 기술 검색을 수행하도록 하는 미국 특허 심사관에 대한 엄청난 압력이 있다. 심사관이 이용가능한 조사 도구가 지난 수년 동안에 극적으로 향상되었지만, 그 도구들은 여전히 많은 단점을 가지고 있다. 단점들 중에는 조사 도구의 대부분이 의미 기반이라기보다는 텍스트 기반이라는 것도 있다. 따라서, 예를 들어 특허상표청 웹 사이트 상에서의 검색 도구는 문서 내의 특정 필드에 있는 특정 단어를 검색한다. 이와 유사하게, 구글 상에서의 최신 검색 도구는 심사관이 특정 단어, 단어들의 특정 문자열을 갖는 문서, 또는 특정 단어 또는 단어들을 갖지 않는 문서를 찾아낼 수 있게 해준다. 그렇지만, 각각의 경우에, 검색 엔진은 심사관이 의미에 기초하여 문서를 찾을 수 있게 해주지는 않는다. 따라서, 예를 들어, 본질적으로 동일한 사상을 알려주지만 쿼리에 있는 것과는 완전히 다른 단어(예를 들어, 동의어 또는 더 좋지 않은 동의 어구)를 사용하는 관련 참고 문헌이 있는 경우, 아마도 예상하고 있지만 그 참고 문헌은 당연히 발견되지 않는다. 심사관이 시간을 할애하여 모든 가능한 동의어, 심지어 발명에 중요한 키워드에 대한 유사 어구를 상상하여 검색할 수 있을지라도, 이는 여전히 참고 문헌을 지나쳐버릴 수 있는데 왜냐하면 때로는 동일한 사상이 동일한 단어들을 전혀 사용하지 않고 표현될 수 있고 때로는 동의적 사상이 어구로 깔끔하게 압축되지 않고 몇 개의 문장 또는 단락에 걸쳐 분포되어 있기 때문이다. 이러한 이유는 예를 들어 숫자가 일대일로 의미를 내포하거나 외연을 나타내는 것처럼 단어들은 그렇지 않기 때문이다. 달리 말하면, 어떤 의미들이 몇 가지 다른 단어 또는 본질적으로 무한한 단어 조합에 의해 내포되거나 외연이 나타내어질 수 있고, 역으로 어떤 단어들 또는 단어 조합이 몇 가지 다른 의미를 내포하거나 외연을 나타낼 수 있다. 가능성들의 이러한 무한한 다대다 네트워크에도 불구하고, 사람은 (문맥, 경험, 추론, 연역, 귀납, 판단, 학습 및 기타로 인해) 대부분의 경우 있을 법한 의미들을 적어도 웬만큼 효과적으로 분리할 수 있다. 현재 종래 기술의 컴퓨터로 자동화된 검색 도구(예를 들어, 특허상표청 웹 사이트, 또는 구글 또는 렉시스(Lexis))는 그러지 못한다. 본 발명의 현재 바람직한 실시예는 이 간극을 상당히 메우고 있는데, 그 이유는 그것이 의미에 기초하여 검색을 할 수 있기 때문이다.

예를 들어, 본 발명의 바람직한 실시예의 검색 기능들 중 일부를 사용하여, 심사관은 검색을 수행할 수 있고, 현재 투자되는 것처럼 어떤 부가적인 노력 또는 시간도 들이지 않고 특허성에 관련한 검색 결과가 심사관에 의해 선택된 키워드와 공통으로 하나의 단어도 포함하고 있지 않더라도 그 검색 결과를 획득할 수 있다. 따라서, 본 시스템은 통상적으로는 종래 시스템들에 의해 찾아내지 못하는 심사관의 업무와 관련한 결과를 획득하게 되는데 그 이유는 본 시스템이 의미에 기초하여 참고 문헌을 찾아낼 수 있기 때문이다.

또한, 의미에 기초하여, 본 시스템은 관련성없는 참고 문헌이 검색 요청과 공통으로 키워드 또는 단어를 공유하고 있을지라도 그 참고 문헌을 배제시킬 수 있다. 환언하면, 종래 기술 조사에서의 한 문제는 거짓 양성 판정(false positive)의 문제이다. 즉, 단지 결과들이 공통으로 키워드를 가지고 있다는 이유만으로 검색 엔진이 관련성 있는 것으로 "생각"하였지만 문맥상 더 정밀한 검사를 해볼 때 그 키워드가 실제로 관련성 없는 사상을 내포하거나 외연을 나타내기 때문에 사실상 전혀 관련성이 없는 결과의 문제이다. 따라서, 심사관은 건초 더미에서 바늘을 찾아야만 하며, 이는 시간 낭비이다.

이와 대조적으로, 본 발명의 바람직한 실시예의 검색 기능들 중 일부를 사용하면, 관련성있는 검색 결과의 밀도가 극적으로 증가하는데 그 이유는 본 시스템이 공통의 키워드에도 불구하고 관련성없는 검색 결과를 누락시킬 정도로 충분히 "지능적"이기 때문이다. 물론, 본 시스템은 이 점에서 사람이 완벽한 것보다는 이 점에서 더 완벽하지는 않다. 그렇지만, 본 시스템은 종래 시스템들보다 관련성없는 결과를 걸러내는 데 훨씬 더 효과적이며, 이 점에서 기능에 있어서 또는 실무적으로 단순한 키보드 기반 검색 엔진보다는 지능적인 조사 보조원을 닮았다. 따라서, 본 시스템을 사용하여, 심사관은 훨씬 더 적은 시간으로 훨씬 더 바람직한 검색을 완수할 수 있다. 한 예에서, 이와 같이 본 시스템을 사용하는 특정의 구조는 다음 과 같이 동작한다.

심사관이 자기 공명 데이터를 해석하고 그에 따라 보다 정확한 진단 영상을 생성하는 보다 정확한 방법에 대한 컴퓨터 소프트웨어에 관한 출원의 심사를 배당받은 것으로 생각해보자. 본 발명의 바람직한 실시예의 검색 기능을 사용하여 관련성있는 종래 기술을 검색하기 위해, 심사관은,

a. 엔티티 생성 마법사(Creat Entity wizard)를 사용하여, "자기 공명 영상"이 등장하는 여러 가지 컨텍스트에서 관련성있는 카테고리를 갖는 "토픽(Topics)" 엔티티를 생성한다. 예시한 것과 같이, 도 1 및 도 2는 의약 분류에서 "자기 공명 영상(Magnetic Resonance Imaging)"이 어디에 있는지를 나타내고 있다. 유의할 점은 그 카테고리가 나타나는 컨텍스트가 몇 개 있다는 것이다. 관련성있는 카테고리들을 엔티티에 부가하고 "OR" 연산을 적용한다. 본질적으로, 심사되고 있는 특허 출원에 기초하여, 이것은 엔티티 "자기 공명 영상"을 올바른 컨텍스트에 있는 모든 자기 공명 영상과 동등한 것으로 정의하는 것(이것이 여러분의 특정 작업과 관계되어 있을 때)과 같다.

b. 새로운 엔티티 "자기 공명 영상" 및 아마도 "영상(imaging)" 및 "진단(diagnostic)" 또는 이들의 어떤 변형 및 조합의 이름을 준다.

c. "자기 공명 영상" 토픽 엔티티를 원하는 프로파일 내의 일건서류(Dossier)(특별 에이전트 또는 디폴트 지식 요청) 아이콘으로 드래그 드롭한다(이 프로파일은 양호하게는 "특허 데이터베이스(Patent Database)" 지식 커뮤니티를 포함하도록 구성되어 있다). 이것은 각각의 특별 에이전트(컨텍스트 템플릿)를 디스 플레이하는 새로운 일건서류(Dossier) 요청/에이전트를 기동시킨다. 다음과 같은 올바른 디폴트 서술어를 갖는 각각의 특별 에이전트가 디스플레이된다.

● 자기 공명 영상에 관한 모든 배팅

● 자기 공명 영상에 관한 최선의 배팅

● 자기 공명 영상에 관한 속보

● 자기 공명 영상에 관한 헤드라인

● 자기 공명 영상에 관한 임의적인 배팅

● 자기 공명 영상에서의 전문가

● 자기 공명 영상에서의 뉴스 메이커

● 자기 공명 영상의 관심 집단

● 자기 공명 영상에 관한 대화

● 자기 공명 영상에 관한 주석

● 자기 공명 영상에 관한 주석 첨부된 아이템

● 자기 공명 영상에 관한 다가오는 행사

● 자기 공명 영상에 관한 인기있는 아이템

● 자기 공명 영상에 관한 클래식

d. 다른 대안에서, 요청이 요청 생성 마법사를 사용하여 생성될 수 있다. 이것을 하기 위해, 일건서류(Dossier) 컨텍스트 템플릿을 선택하고 요청에 대한 지식 소스로서 "특허 데이터베이스" 지식 커뮤니티를 선택한다. 다른 대안에서, 여러분은 "특허 데이터베이스" 지식 커뮤니티를 포함하도록 프로파일을 구성하고 단 지 새로운 요청에 대해 선택된 프로파일을 사용할 수 있다. 다음(Next)을 누른다 - 마법사는 지능적으로 요청에 대한 시맨틱스에 기초하여 요청에 대한 이름을 제안한다. 마법사는 또한 "자기 공명 영상" "토픽" 엔티티의 시맨틱스에 기초하여 올바른 디폴트 서술어를 선택한다. 마법사는 이 엔티티가 "토픽"이라는 것을 알고 있기 때문에, 올바른 컨텍스트에서 의미를 갖는 올바른 엔티티를 선택한다. 마침(Finish)을 누른다. 마법사는 쿼리를 컴파일하고, SQML을 선택된 프로파일 내의 KIS로 전송한 다음에 결과를 디스플레이한다.

상기의 예에서, 결과는 궁극적으로 임의의 소스로부터 도출될 수 있다. 양호하게는, 결과들 중 어떤 것은 웹 상에서 가져온 것이고, 어떤 것은 특허상표청 인트라넷에서 가져온 것이며, 어떤 것은 다른 아마도 독점적인 엑스트라넷에서 가져온 것이다. 원본 문서의 범위 또는 출처에 상관없이, 본 시스템을 사용하여 그 문서는 자동적으로 처리되고, 본 시스템에 의해 자동적으로 "판독" 및 "이해"되며, 따라서 심사관의 쿼리가 개시되고 또한 시맨틱적으로 또 컨텍스트에 의해 "판독" 및 "이해"될 때, 본 시스템은 모든 관련성있는 결과 및 관련성있는 결과만을 찾아낸다. 다시 말하면, 완벽하지는 않지만 임의의 종래 시스템들에서보다 훨씬 더 정확하다. 또한 유의할 점은 본 시스템이 미리 문서에 수동으로 태깅을 하거나 문서를 카테고리화하는 것에 의존하지 않는다는 것이다. 그렇게 하는 것도 역시 정확도에 있어서 도움이 되지만, 이는 우선적으로 온라인 조사의 이점을 완전히 퇴색시킬 정도로 많은 노동을 요하는 일이며 새로운 문서의 증가 속도를 고려할 때 완전히 비실용적이다.

이 시나리오에서, 심사관은 또한 본 발명의 바람직한 실시예의 부가적인 특징을 사용하기를 원할 수 있다. 예를 들어, 심사관은 다음과 같이 특허상표청 내의 전문가에 조언을 구하거나 특허상표청 외부의 전문가의 문헌을 조회하고자 할 수 있다(유의할 점은 자기 공명 영상에서의 전문가가 자기 공명 영상에 관한 일건서류(Dossier)에 포함되어 있지만, 심사관은 그를 별도로 추적하고 그를 "요청 문서"로서 저장하며 그를 동료들에게 이메일로 보내는 등을 위해 별도의 요청을 생성하고자 할 수 있다는 것이다). 자기 공명 영상의 모든 전문가를 찾아낸다.

a. 상기 단계 1 - 4를 따른다.

b. "자기 공명 영상" 엔티티를 원하는 프로파일 내의 전문가(Experts)(특별 에이전트 또는 디폴트 지식 요청) 아이콘으로 드래그 드롭한다. 이것은 적절히 "자기 공명 영상에서의 전문가"라는 타이틀을 갖는 새로운 요청/에이전트를 자동적으로 기동시킨다. 시맨틱 브라우저는 올바른 디폴트 서술어 "in"을 선택하는 데 그 이유는 브라우저는 그 엔티티가 "토픽" 엔티티임을 "알고" 있고 또 컨텍스트 템플릿이 "사람" 템플릿(전문가)이기 때문이다. 그 자체로서, 디폴트 서술어는 이들 2개의 인수의 교집합("in")에 기초하여 선택되는데 왜냐하면 이것이 의미를 갖기 때문이다.

2. 바이오기술 회사 연구 시나리오

바이오기술 회사는 실험실 연구에서 뿐만 아니라 그 자신의 회사 내부 및 외부의 다른 사람들에 의한 연구 결과의 연구에서도 연구 위주이다. 불행히도, 이러한 회사가 이용가능한 연구 도구는 단점이 있다. 독점적 서비스는 컨텍스트에 민 감한(context-sensitive) 유용한 결과를 제공하지만, 그 서비스 자체는 좋지 않은 도구를 가지고 있으며 따라서 인덱싱 및 사람의 노력, 및 값비싼 전문 잡지의 구독에 크게 의존하고, 그 결과 비용이 많이 들고 본 시스템만큼 정확하지 않다. 반면에, 바이오기술 연구자들은 구글을 사용하여 저렴하게 검색할 수 있지만, 구글은 전술한 바와 같이 모든 키워드 기반 제한을 공유하고 있다.

이와 반대로, 본 발명의 바람직한 실시예의 검색 특징을 사용하면, 바이오기술 연구자는 보다 관련성있는 결과를 보다 효율적으로 찾아낼 수 있다. 구체적으로 말하면, 연구자는 다음과 같이 본 시스템을 사용할 수 있다. 예를 들어, 어떤 연구자들은 마케팅 또는 연구에 종사하는 누구라도 작성한 게놈학 및 해부학에 관한 헤드라인을 찾고자 하는 경우, 그 연구자는 그 일을 다음과 같이 할 것이다.

a. 마법사를 사용하여 키워드 "마케팅 연구"를 갖는 배포 리스트에 대해 정보 타입 요청/에이전트를 기동시킨다.

b. 마케팅 배포 리스트 결과를 선택하고 "엔티티로 저장(Save as Entity)"을 클릭한다. 이것은 객체를 "팀(Team)" 엔티티로 저장한다(그 이유는 시맨틱 브라우저가 원본 객체가 배포 리스트임을 알고 있고 그 자체로서 "팀" 엔티티는 이 컨텍스트에서 의미를 갖기 때문이다).

c. 연구 배포 리스트 결과를 선택하고 "엔티티로 저장"을 클릭한다. 이것은 객체를 "팀" 엔티티로 저장한다(그 이유는 시맨틱 브라우저가 원본 객체가 배포 리스트임을 알고 있기 때문이다).

d. 엔티티 생성 마법사를 사용하여, 새로운 "팀" 엔티티를 생성하고 "마케 팅" 및 "연구" 팀 엔티티를 멤버로서 선택한다. 새로운 엔티티 "마케팅 또는 연구"의 이름을 준다.

e. 요청 생성 마법사를 사용하여, 헤드라인 컨텍스트 템플릿을 선택한 다음에 "마케팅 또는 연구" 엔티티를 필터로서 선택한다. 또한, 게놈학 카테고리 및 해부학 카테고리를 선택한다. 그 다음에, "AND" 연산자를 선택한다. 다음(Next)을 누른다. - 마법사는 지능적으로 요청의 시맨틱스에 기초하여 요청에 대한 이름을 제안한다. 마법사는 또한 "마케팅 또는 연구" 팀 엔티티의 시맨틱스에 기초하여 올바른 디폴트 서술어를 선택한다("내부의 누구나"(by anyone in)). 마법사는 엔티티가 "팀"임을 알고 있기 때문에, 디폴트로 "내부의 누구나"를 선택하는데 그 이유는 이것이 의미를 갖기 때문이다. 마침(Finish)을 누른다. 마법사는 쿼리를 컴파일하고, SQML을 선택된 프로파일 내의 KIS로 전송한 다음에 결과를 디스플레이 한다.

게다가, 연구자는 마케팅 또는 연구에 종사하는 모든 전문가를 찾아내기를 원할 수 있다.

a. 상기 단계 1 - 4를 따른다.

b. "마케팅 또는 연구" 엔티티를 원하는 프로파일 내의 전문가(Experts)(특별 에이전트 또는 디폴트 지식 요청) 아이콘으로 드래그 드롭한다. 이것은 적절히 "마케팅 또는 연구에 종사하는 전문가"라는 타이틀을 갖는 새로운 요청/에이전트를 기동시킨다. 시맨틱 브라우저는 올바른 디폴트 서술어 "in"을 선택하는 데 그 이유는 브라우저는 그 엔티티가 "팀" 엔티티임을 "알고" 있고 또 컨텍스트 템플릿이 "사람" 템플릿(전문가)이기 때문이다. 그 자체로서, 디폴트 서술어는 이들 2개의 인수의 교집합("in")에 기초하여 선택되는데 왜냐하면 이것이 의미를 갖기 때문이다.

연구자가 이 연구로 되돌아가거나 그를 보완하거나 또는 그 결과를 나중에 분석할 필요가 있는 것으로 예상할 때, 연구자는 다음과 같이 마케팅 또는 연구에 대한 일건서류(Dossier)를 열려고 할 수 있다.

a. 상기 단계 1 - 4를 따른다.

b. "마케팅 또는 연구" 엔티티를 원하는 프로파일 내의 일건서류(Dossier)(특별 에이전트 또는 디폴트 지식 요청) 아이콘으로 드래그 드롭한다. 이것은 각각의 특별 에이전트(컨텍스트 템플릿)를 디스플레이하는 새로운 일건서류(Dossier) 요청/에이전트를 기동시킨다. 다음과 같은 올바른 디폴트 서술어를 갖는 각각의 특별 에이전트가 디스플레이된다.

● 마케팅 또는 연구에 종사하는 누구나에 의한 모든 배팅

● 마케팅 또는 연구에 종사하는 누구나에 의한 최선의 배팅

● 마케팅 또는 연구에 종사하는 누구나에 의한 속보

● 마케팅 또는 연구에 종사하는 누구나에 의한 헤드라인

● 마케팅 또는 연구에 종사하는 누구나에 의한 임의적인 배팅

● 마케팅 또는 연구에 종사하는 전문가

● 마케팅 또는 연구에 종사하는 뉴스 메이커

● 마케팅 또는 연구에의 관심 집단

● 마케팅 또는 연구에 종사하는 누구나 참여하는 대화

○ 마케팅 또는 연구에 종사하는 누구나에 의한 주석

○ 마케팅 또는 연구에 종사하는 누구나에 의한 주석 첨부된 아이템

● 마케팅 또는 연구에 종사하는 누구나에 의한 다가오는 행사

● 마케팅 또는 연구에 종사하는 누구나에 의한 인기있는 아이템

● 마케팅 또는 연구에 종사하는 누구나에 의한 클래식

연구자는 "나의 경쟁자에 관한 속보"를 찾는데 관심이 있을 수 있으며, 다음과 같이 함으로써 그렇게 한다.

a. 각각의 경쟁자에 대해, 엔티티 생성 마법사를 사용하여 새로운 "경쟁자(competitor)" 엔티티를 ("회사" 아래에) 생성한다. 필요에 따라 올바른 필터를 선택한다. 예를 들어, "Groove"와 같은 잘 알려진 영어 이름을 갖는 경쟁자는 회사가 영업을 하고 있는 카테고리 및 키워드를 포함하는 엔티티를 가져야만 한다.

b. 엔티티 생성 마법사를 사용하여, 포트폴리오(엔티티 컬렉션)를 생성하고 단계 a에서 생성한 모든 경쟁자 엔티티를 부가한다. 엔티티 컬렉션 "내 경쟁자(My Competitors)"의 이름을 준다.

c. 요청 생성 마법사를 사용하여, 속보 컨텍스트 템플릿을 선택하고 단계 b에서 생성한 포트폴리오(엔티티 컬렉션)를 필터로서 부가한다. 디폴트 서술어 선택을 유지한다. "다음"을 누른다. - 마법사는 지능적으로 디폴트 서술어("내 경쟁자에 관한 속보(Breaking News on My Competitors)")를 사용하여 요청에 대한 이름을 제안한다. 마침을 누른다. 마법사는 "내 경쟁자에 관한 속보"라는 이름의 새로운 요청/에이전트를 기동시킨다.

게다가, 연구자는 계속 통지를 받고자 원할 수 있다. 연구자들은 다음과 같이 "우리 경쟁자에 관한 속보"에 관해 자기에게 경고해주도록 시스템에 지시할 수 있다.

a. 전술한 바와 같이 "내 경쟁자에 관한 속보" 요청을 생성한다.

b. 이 요청을 요청 감시 리스트에 부가한다. 시맨틱 브라우저는 이제 "내 경쟁자에 관한 속보"를 보여주는 감시창(watch pane)(예를 들어, 티커(ticker))를 디스플레이한다. 통지 관리자(Notification Manager, NM)를 사용하여, 여러분은 요청/에이전트로부터 새로운 결과가 있을 때 시맨틱 브라우저가 이메일, 인스턴트 메시징, 텍스트 메시징 등을 통해 경고를 보내도록 표시할 수 있다.

게다가, 연구자는 장래의 참조를 위해 경쟁자들의 기록을 유지하고 또 이를 항상 업데이트하고자 원할 수 있다. 본 시스템은 연구자가 다음과 같이 본 시스템에 대해 우리 경쟁자들 각각에 관한 일건서류(Dossier) 컬렉션을 보여주도록 지시함으로써 이러한 기록을 생성 및 업데이트한다.

a. 상기 4a에 기술한 바와 같이 여러분의 경쟁자들 각각에 대한 엔티티를 생성한다.

b. 각각의 경쟁자 엔티티에 대해, 그 엔티티를 원하는 프로파일에 대한 일건서류(Dossier) 아이콘으로 드래그함으로써 그 경쟁자에 관한 새로운 일건서류(Dossier)를 생성한다 - 이것은 경쟁자에 관한 일건서류(Dossier)를 생성한다.

c. 요청 생성 마법사를 사용하여, 새로운 요청 컬렉션(블렌더(blender))를 생성하고 상기 단계 b에서 생성된 일건서류(Dossier) 요청들 각각을 이 컬렉션에 부가한다(여러분은 또한 컬렉션을 추가로 채우기 위해 요청이 생성된 후에 요청을 컬렉션으로 드래그 드롭할 수 있다). 다음을 누른다. - 마법사는 지능적으로 요청 컬렉션에 대한 이름을 제안한다. 마침을 누른다. 마법사는 개별적인 일건서류(Dossier)를 포함하는 요청 컬렉션을 기동시킨다. 이어서, 여러분은 요청 컬렉션을 즐겨찾기로서 부가하고 풍부한 컨텍스트적인 경쟁력있는 정보를 얻기 위해 매일 그 컬렉션을 열 수 있다.

연구자는 특정의 일건서류(Dossier)를 검토하고자 원할 수 있고 본 시스템에 대해 (예를 들어, John Smith라는 이름의) CEO에 관한 일건서류(Dossier)를 보여주도록 지시함으로써 그렇게 할 수 있다.

a. 마법사를 사용하여, 키워드 "John Smith"를 갖는 사람들에 대해 정보 타입 요청/에이전트를 기동시킨다.

b. 결과를 선택하고 "엔티티로 저장"을 클릭한다. - 이것은 객체를 "사람(Person)" 엔티티로 저장한다(왜냐하면 시맨틱 브라우저는 원본 객체가 사람임을 "알고" 있으며 그 자체로서 "사람" 객체는 이 컨텍스트에서 의미를 갖기 때문이다).

c. 요청 생성 마법사를 사용하여, 일건서류(Dossier) 컨텍스트 템플릿을 선택한 다음에 필터로서 "John Smith" 엔티티를 선택한다. 다음을 누른다. - 마법사는 지능적으로 요청의 시맨틱스에 기초하여 요청에 대한 이름을 제안한다. 마법사는 또한 "John Smith" 사람 엔티티의 시맨틱스에 기초하여 올바른 디폴트 서술어를 선택한다. 마침을 누른다. 마법사는 쿼리를 컴파일하고 SQML을 선택된 프로파 일 내의 KIS로 전송한 다음에 다음과 같이 결과를 (서브쿼리/에이전트로서) 디스플레이한다.

● John Smith에 의한 모든 배팅

● John Smith에 의한 최선의 배팅

● John Smith에 의한 속보

● John Smith에 의한 헤드라인

● John Smith에 의한 임의적인 배팅

○ John Smith같은 전문가(이것은 John Smith가 전문 기술을 가지고 있는 카테고리와 동일한 카테고리에 관한 전문 지식을 갖는 전문가를 반환한다)

● John Smith같은 뉴스 메이커(이것은 John Smith가 최근에 "뉴스가 되었던" 카테고리와 동일한 카테고리에서 "뉴스가 되었던" 뉴스 메이커를 반환한다)

● John Smith같은 관심 집단(이것은 시간-윈도우(time-window)(바람직한 실시예에서 2-3개월) 내에서 John Smith가 관심을 표명한 카테고리와 동일한 카테고리에 관심을 표명한 사람들을 반환한다)

○ John Smith가 참여하는 대화

● John Smith에 의한 주석

● John Smith에 의한 주석 첨부된 아이템

● John Smith에 의한 다가오는 행사

● John Smith에 의한 인기있는 아이템

● John Smith에 의한 클래식

상기 시나리오들은 본 시스템의 동작을 예시한 것이다. 본 시스템 자체에 대해 이하에 더욱 상세히 기술한다.

B. 정보 신경 시스템의 현재 바람직한 실시예에 대한 주제

상기 인용한 동시 계류 중인 특허 출원 및 종래의 가특허출원의 출원 이후에 몇가지 개선, 향상 및 변형이 이루어졌다. 이들 중 어떤 것은 모출원에 이미 포함된 특징에 대한 개선이거나 단지 명료하게 한 것에 불과하며, 어떤 것은 전적으로 본 시스템의 새로운 특징이다. 이들은 이하에 열거되고 기술되어 있다. 이들은 중요성의 순서나 임의의 특정의 순서로 정렬되어 있지 않다. 본 발명의 바람직한 실시예가 사용자로 하여금 이하에 기술된 이들 특징 및 개선 중 임의의 것 또는 그 모두를 단독으로 또는 조합하여 사용할 수 있게 해주지만, 어느 단 하나의 특징이 본 발명의 실시에 꼭 필요한 것은 아니며 특징들의 임의의 특정의 조합도 역시 그렇다.

또한, 본 출원에서, 특허 출원 제10/179,651호에 정의된 동일한 용어를 참조하고 있고 또 본 출원 전체에 걸친 설명은 본 출원의 문맥상 명백하게 정반대를 나타내는 경우를 제외하고는 이 특허 출원의 정의, 전문 용어, 학술 용어 및 도면들과 관련하여 이해되어야 한다.

1. 스마트 선택 렌즈 개요

스마트 선택 렌즈(Smart Selection Lens)는 정보 신경 시스템 정보 매체의 스마트 렌즈 특징과 유사하다. 이 경우, 사용자는 객체 내의 텍스트를 선택할 수 있고, 선택된 텍스트를 객체로서 사용하여 렌즈가 적용될 수 있다(선택이 변경될 때 새로운 "이미지"를 동적으로 생성한다). 이와 같이, 사용자는 전체 객체에 대해 "렌즈"를 실행하거나 어느 것에도 "렌즈"를 실행하는 않는 것으로 제한되는 것과는 달리 객체 메타데이터의 구성가능 서브셋에 대해 "렌즈"를 실행할 수 있다. 이 특징은 컨텍스트로 오버로드된 선택 커서/버브(selection cursor/verb)와 유사하다. 예를 들어, 사용자는 프리젠터(Presenter)에서 한 텍스트를 선택하여 텍스트가 나타나는 객체 상에서 "렌즈로 붙여넣기(Paste as Lens)"를 누를 수 있다. 그러면, 프리젠터는 다음과 같은 메소드 호출로 그 텍스트를 클라이언트 런타임 컴포넌트(예를 들어, 액티브 X(ActiveX) 객체)로 전달하게 된다.

bstrSRML = GetSRMLForText( bstrText );

그러면, 이 호출은 인수 텍스트(argument text)를 캡슐화하는 임시적인 SRML 버퍼를 반환한다. 그러면, 프리젠터는 다음과 같은 메소드를 호출하게 된다.

bstrSQML = GetQueryForSmartLensOnObject( bstrSRMLObject );

이 메소드는 클립보드로부터 SQML을 가져오고, 객체에 대한 인수 SRML을 받아서 SQML 내의 링크(디폴트 서술어 "관련성있음(relevant to)"을 가짐)와 같이 SRML에 리소스를 포함하는 새로운 SQML을 동적으로 생성한다. 이어서, 이 메소드는 새로운 SQML을 반환한다. 이어서, 프리젠터는 이하의 메소드를 호출한다.

ProcessSemanticQuery( bstrSQML );

이 메소드는 생성된 렌즈 SQML을 전달한 다음에 결과 내의 아이템의 수 및 SRML 결과를 양호하게는 비동기적으로 검색한다. 이 호출에 대한 상세에 대해서는, 규격 "정보 신경 시스템 시맨틱 런타임 OCX(Information Nervous System Semantic Runtime OCX)"를 참조하기 바란다. 이어서, 프리젠터는 다음과 같은 것을 갖는 미리보기 윈도우(또는 현재의 스킨에 기초한 그 등가물)를 디스플레이한다.

[렌즈 에이전트 타이틀]

23개 아이템 발견됨

[미리보기 객체]

[미리보기 윈도우 콘트롤]

여기서, "렌즈 에이전트 타이틀"은 클립보드 상의 에이전트의 타이틀이다. 미리보기 윈도우(및 미리보기 윈도우 콘트롤)의 상세에 대해서는, 모출원 제10/179,651호를 참조하기 바란다.

바람직한 실시예에서, 미리보기 윈도우는,

● 타이머가 만료된(아마도 500ms) 후에 사라진다. 마우스 이동 시에, 타이머는 양호하게는 리셋된다(이것은 사용자가 동일한 영역 주변에서 마우스를 이동시킬 때 윈도우를 플래싱하는 것을 없애준다).

○ (종국적으로) 서서히 페이드 아웃된다.

바람직한 실시예는 또한 이하의 특징을 갖는다.

1. 객체마다 하나의 선택 범위 그렇지만 결과-셋트마다 다수의 선택이 최선의 옵션이다. 그렇지 않은 경우, 시스템은 (객체마다와는 반대로)객체마다 선택마다 렌즈 아이콘을 보여주기 위해 사용자를 혼란케하는 경험 및 복잡한 UI을 제공한다.

2. 프리젠터가 (SQML이 에이전트 렌즈에 부합하게 동적으로 생성되지만, 정규 SQML 쿼리인) 보류 중인 렌즈 쿼리 요청을 더 이상 필요로 하지 않을 때(예를 들어, 프리젠터가 새로운 페이지로 이동해가는 경우 또는 우리가 객체에 대한 새로운 렌즈 정보를 요청하는 경우) 그 요청이 취소되어야만 한다. 어느 경우든지, 이러한 취소는 성능(또는 대역폭) 관점에서 볼 때 중요한 것이 아닌데, 그 이유는 렌즈 쿼리가 한번에 몇 개의 객체만을 요청할 가능성이 있기 때문이다. 쿼리가 취소되지 않은 경우, 프리젠터는 결과를 무시할 수 있다. 그럼에도 불구하고, 프리젠터도 역시 쓸모없는 결과(stale result)를 처리하여 이들을 바닥에 버려야만 하기 때문에, 프리젠터는 어쨌든(렌즈 쿼리도 역시 취소되는지 그렇지 않든간에) 이렇게 해야만 한다. 프리젠터가 취소 요청을 발행할 때와 취소가 실제로 완료되었을 때 사이의 지연의 윈도우가 있다. 이 시간 동안에 어떤 결과가 나올 수 있기 때문에, 이들은 폐기되어야 한다. 따라서, 바람직한 실시예는 비동기적인 취소 구현을 갖는다. - 소프트웨어 컴포넌트는 잘못되거나 쓸모없는 결과를 무시할 준비가 항상 되어 있도록 설계되어 있다.

3. 프리젠터는 양호하게는 아이콘(현재의 렌즈 요청 상태를 나타냄) 및 툴팁(tool-tip) 둘다를 갖는다. 사용자가 객체 상을 허버링(hover)(마우스 커서가 그 위에 있는 것을 말함)하거나 그를 클릭할 때, 프리젠터는 단어들 "렌즈 정보 요청"(또는 그러한 취지의 단어들)을 갖는 툴팁을 제시할 수 있다. 정보가 되돌아올 때, 허버링은 "23개 객체가 발견됨" 팁을 보여주고 클릭하면 그 결과를 보여준다. 이러한 삽입 툴팁이 결과가 도착할 때도 여전히 위에 있는 경우 그 툴팁은 이어서 미리보기 윈도우로 전환될 수 있다.

게다가, 유의할 점은 스마트 렌즈와 같은 스마트 선택 렌즈가 텍스트 메타데이터 이외의 객체들에 적용될 수 있다는 것이다. 예를 들어, 스마트 선택 렌즈는 이미지, 비디오, 오디오 스트림의 섹션, 또는 다른 메타데이터에 적용될 수 있다. 이들 경우에, 프리젠터는 데이터 타입과 부합하는 적절한 SRML 및 "선택 영역(selection region)"을 반환하게 된다. 이 영역은 이미지, 또는 비디오의 영역, 오디오 스트림 내의 기간 설정값(time span), 기타 등등일 수 있다. 나머지 스마트 렌즈 기능은 전술한 바와 같이 적용되며, 적절한 SQML이 SRML(이는 차례로 렌즈 아래의 데이터 타입에 대한 스키마에 기초함)에 기초하여 생성된다.

2. 사람(Person) 객체 개요 붙여넣기

정보 신경 시스템(이는 다시 말하면 현재 바람직한 실시예의 어떤 측면에 대한 현재의 약식 이름 중 하나임)은 또한 "사람" 객체(사람들, 사용자들, 고객들 기타 등등)의 드래그/드롭 또는 복사/붙여넣기를 지원한다. 이 경우에 바람직한 실시예의 동작을 설명하는 적어도 2개의 시나리오가 있다.

1. 사람(Person) 객체의 출처인 지식 커뮤니티(또는 에이전시)를 나타내는 스마트 요청 상에 사람(Person) 객체를 붙여넣기함. 이 경우, 서버의 시맨틱 쿼리 프로세서는 단지 사람(Person)을 인수로 사용하여 클라이언트로부터의 SQML을 분석한다. 예를 들어, 사용자가 사람 "Joe"를 스마트 요청 "Headlines on Reuters"의 상단에 붙여넣기하는 경우, 클라이언트는 부가적인 인수를 사용하여 새로운 스마트 요청을 생성하게 된다. Reuters 정보 신경 시스템 웹 서비스는 이어서 'Joe'에 의 해 게시되거나 주석 첨부된 모든 헤드라인을 반환함으로써 이 요청을 해결한다. 이 경우, 서버는 본질적으로 적절한 디폴트 서술어(게시자 또는 주석 첨부자 'published or annotated by')를 적용하게 된다.

2. 사람 객체의 출처가 아닌 지식 커뮤니티(또는 에이전시)를 나타내는 스마트 요청 상에 사람 객체를 붙여넣기함. 이 경우, 사람 객체가 (그의 SMS 상의) 목적지 지식 커뮤니티의 시맨틱 네트워크에 있지 않기 때문에, 서버의 시맨틱 쿼리 프로세서는 사람 인수를 이해할 수 없게 된다. 그 자체로서, 서버는 예를 들어 사람이 전문자(바람직한 실시예에서) 또는 뉴스 메이커인 카테고리를 사용하는 등의 다른 방식으로 사람 인수를 분석해야만 한다. 예를 들어, 상기 예를 보면, 사용자가 사람 'Joe'를 스마트 요청 "Headlines on Reuters"의 상단에 붙여넣기(또는 드래그/드롭)하고 Joe가 Reuters 지식 커뮤니티 상의 사람이 아닌 경우, Reuters 웹 서비스(바람직한 실시예에서)는 "Joe의 전문 지식과 관련성있는" 헤드라인을 반환해야만 한다. 이 실시예에서는 이어서 클라이언트가 목적지 웹 서비스로 SQML을 전송하기 전에 2-패스(two-pass) 방식을 취해야만 한다. 먼저, 클라이언트는 그 사람의 전문 지식을 나타내는 "대표적인 데이터(SRML)"를 얻기 위해 그 사람이 속하는 지식 커뮤니티에 질문을 해야만 한다. 웹 서비스는 이하와 같이 함으로써 이 요청을 해결한다.

a. 지식 커뮤니티의 종분류(specifictaxonomy) 및 온톨로지(ontology)를 포함 및/또는 표현하는 그 지식 커뮤니티의 시맨틱 도메인 정보를 얻기 위해 사람 객체가 붙여넣기 또는 드롭되어 있는 지식 커뮤니티(예를 들어, Reuters)에 쿼리를 한다. 유의할 점은 몇 개의 시맨틱 도메인이 있을 수 있다는 것이다.

b. 사람 객체의 시맨틱 도메인 정보를 얻기 위해 그 사람 객체의 출처인 지식 커뮤니티에 쿼리를 한다.

c. 시맨틱 도메인이 동일한 경우 또는 적어도 하나의 공통의 시맨틱 도메인이 있는 경우, 클라이언트는 사람의 전문 지식 카테고리를 얻기 위해 사람 객체의 출처인 지식 커뮤니티에 쿼리를 한다. 이어서, 클라이언트는 이들 카테고리를 인수로서 갖는 SQML을 구축하고 사람 객체가 붙여넣기 또는 드롭되어 있는 지식 커뮤니티에 이 SQML을 전달한다.

시맨틱 도메인이 동일하지 않거나 적어도 하나의 공통의 시맨틱 도메인이 없는 경우, 클라이언트는 그 사람이 전문가인 카테고리에 속하는 몇 개의 객체를 얻기 위해 사람 객체의 출처인 지식 커뮤니티에 쿼리를 한다. 바람직한 실시예에서, 이 구현은 전문 지식의 카테고리를 정확하게 나타내는 충분히 많은 수의 객체를 선택해야만 한다(이 수는 양호하게는 실험에 기초하여 선택된다). 이 경우에 객체를 선택하는 이유는 목적지 웹 서비스가 사람 객체의 출처인 지식 커뮤니티의 카테고리를 이해하지 못하고 그 자체로서 그 카테고리를 그 자신의 카테고리로 매핑할 수 없기 때문이다. 다른 대안에서, 서로 다른 지식 커뮤니티들 간에 카테고리를 매핑하는 카테고리 매퍼(category mapper)가 (인터넷 상의 중앙집중화된 웹 서비스를 통해) 이용될 수 있다. 이 경우, 목적지 지식 커뮤니티는 그 카테고리를 이해하지 못하더라도 항상 SQML의 일부로서 카테고리를 전달받게 된다. - 지식 커뮤니티는 이어서 카테고리 매퍼 웹 서비스를 사용하여 이들 카테고리를 내부 카테고리로 매 핑하게 된다. 카테고리 매퍼 웹 서비스는 카테고리를 분석하는 메소드는 물론 카테고리 매핑을 게시하는 메소드도 갖는다.

3. 스마트 요청 개요의 저장 및 공유

정보 신경 시스템 시맨틱 브라우저(정보 에이전트 또는 라이브레리언(Librarian))의 사용자는 또한 스마트 요청을 디스크에 저장하거나, 이를 첨부물로서 이메일 전송하거나 인스턴트 메신저(역시 첨부물로서) 또는 다른 수단을 통해 이를 공유할 수 있다. 클라이언트 애플리케이션은 스마트 요청을 공유가능 문서로서 저장하는 메소드들을 노출시킨다. 클라이언트 애플리케이션은 또한 스마트 요청 문서를 이메일 또는 인스턴스 메신저에서의 첨부물로서 공유하는 메소드들을 노출시킨다.

공유가능 스마트 요청 문서는 (보안 스트림을 통해 바이너리 포맷으로) SQML을 캡슐화하는 바이너리 문서이다. 이 문서는 다른 특징들 중에서도 무결성을 보호하고 규격의 지적 재산을 보호하는 데 도움을 줄 수 있는 시맨틱 쿼리의 안전하고 직렬화된 표현을 제공한다. 예를 들어, 쿼리 자체는 노출될 경우 경쟁자가 엔지니어 필수적인 경쟁 정보를 회사의 위해로 바꾸어놓을 수 있게 해주는 연구자의 사용자의 기업 비밀을 구체화할 수 있다. 이 보호는 시맨틱 쿼리의 XML 버전을 강력하게 암호화하는 것에 의해 또는 강력한 단방향 해시(strong one-way hash)를 통하는 것을 비롯하여 몇가지 방식으로 달성될 수 있다. 공유가능 문서는 요청을 나타내는 확장자(.REQ)를 갖는다. 클라이언트 오퍼레이팅 시스템 상의 확장자 핸들러는 이 확장자를 표현하기 위해 설치되어 있다. 이 확장자를 갖는 문서가 열릴 때, 그 문서를 열기 위해 확장자 핸들러가 호출된다. 확장자 핸들러는 보안 스트림으로부터 SQML을 추출한 다음에 이 SQML로 시맨틱 네임스페이스 내에 스마트 요청을 생성함으로써 그 문서를 연다. 이 핸들러는 이어서 시맨틱 네임스페이스 내의 스마트 요청을 연다.

시맨틱 네임스페이스 내의 스마트 요청이 저장될 때, 또는 사용자가 이를 이메일 첨부물로서 전송하고자 하는 경우, 클라이언트는 바이너리 .REQ 포맷으로 스마트 요청을 나타내는 SQML을 직렬화하고 이를 요청된 디렉토리 경로에 저장하거나 첨부물로서 .REQ 문서를 갖는 이메일 클라이언트를 연다.

도 3은 스마트 문서로 SQML 버퍼를 캡슐화하는 바이너리 문서 포맷을 나타낸 것이며, 또한 확장자 핸들러가 문서를 어떻게 여는지를 예시한 것이다. 유사한 모델도 역시 (SRML을 통해) 결과를 공유하기 위해 이용될 수 있다. 이 경우에, 바이너리 문서는 상기 경우에서와 같이 SQML이 아니라 SRML을 캡슐화한다.

도 4A 및 도 4B는 윈도즈 쉘에서 등록된 연결(registered association)을 갖는 2개의 .REQ 문서(맨 오른쪽에 타이틀이 'Headlines on Reuters Related to My Research Report(Live)' 및 'Headlines on Reuters (as of January 21 2003, 08 17 AM)'으로 되어 있음)의 예시를 나타낸 것이다. 첫 번째 요청 문서는 '라이브'이고, 두 번째 문서는 특정 시각의 스냅샷이다(이들은 둘다 시간에 민감한(time-sensitive) 요청이다). 유의할 점은 오퍼레이팅 시스템이 시맨틱 브라우저 애플리케이션(Nervana Librarian)을 그 문서와 연관시킨다는 것이다. 문서가 열릴 때, 이 애플리케이션에서 시맨틱 쿼리가 열리게 된다.

● 엔티티 저장 및 공유 - 엔티티를 나타내는 .ENT 확장자를 갖는 것을 제외하고는 동일한 프로세스가 상기와 같이 적용된다. 엔티티 문서가 호출될 때, Nervana Librarian은 브라우저에 엔티티 SQML을 연다.

● 확장자 프로퍼티 시트 - 이것은 시맨틱 환경에서 (문서의 종류에 따라) 임시적인 스마트 요청 또는 엔티티를 생성하고 스마트 요청 또는 엔티티에 대한 프로퍼티 시트를 디스플레이한다.

● 확장자 툴 팁 - 사용자가 라이브레리언 문서(요청, .REQ 또는 엔티티, .ENT) 상에서 허버링할 때 이것은 도움이 되는 툴 팁을 디스플레이한다.

4. 스마트 스냅샷 개요의 저장 및 공유

정보 신경 시스템은 또한 발명자가 "스마트 스냅샷(Smart Snapshots)"이라고 부르는 것의 공유를 지원한다. 스마트 스냅샷은 시간상 정지된 스마트 요청(smart request frozen in time)을 말한다. 이것은 사용자가 스마트 요청을 공유하고자 하지만 그 요청이 "라이브"일 필요는 없는 경우의 시나리오를 가능하게 해준다. 예를 들어, 기본적으로, 사용자가 스마트 요청 "이 문서와 관계된 Reuters 상의 속보(Breaking News on Reuters related to this document)"를 동료와 공유하는 경우, 그 동료는 ("현재 시각"에 기초하여) 스마트 요청의 라이브 결과를 보게 된다. 그렇지만, 사용자가 "이 문서와 관계된 Reuters 상의 [현재] 속보([Current] Breaking News on Reuters related to this document)"를 보고자 하는 경우, 스마트 스냅샷이 이용된다.

스마트 스냅샷은 SQML 문서의 "애트리뷰트(attribute)" 섹션이 그 요청을 스 냅샷으로 만들어주는 애트리뷰트(플래그 QUERYATTRIBUTES_SNAPSHOT)를 포함하는 것을 제외하고는 스마트 요청과 동일하다. SQML 문서의 생성 날짜/시각도 역시 SQML에 저장된다(이전과 마찬가지로, SQML 스키마는 생성 날짜/시각에 대한 필드를 포함한다). 사용자가 스마트 요청을 공유하고자 함을 표시하는 경우, 사용자 인터페이스(시맨틱 브라우저, 정보 에이전트 또는 라이브레리언)는 사용자가 스마트 요청(라이브)을 공유하기를 원하는지 스마트 스냅샷을 공유하기를 원하는지를 물어본다. 사용자가 스마트 요청을 표시하는 경우, (파트 3에서) 전술한 프로세스가 이용된다. 사용자가 스마트 스냅샷을 표시하는 경우, 바이너리 문서는 편집된 SQML(스냅샷 애트리뷰트를 포함함)로 채워지고 상기한 바와 같이 나머지 프로세스를 따른다.

바이너리 문서의 수취인이 (이메일, 인스턴스 메시징 등에 의해) 그를 수신하여 열 때, 확장자 핸들러는 (전술한 바와 같이) 그 문서를 열고 스마트 요청으로서 시맨틱 네임스페이스 내에 엔트리를 부가한다. 수취인이 스마트 요청을 열 때, (앞서 기술한 바와 같이) 클라이언트의 시맨틱 쿼리 프로세서는 처리된 SQML을 서버의 XML 웹 서비스로 전송한다. 이어서, 서버의 시맨틱 쿼리 프로세서는 SQML을 처리하고 SQML 생성 날짜/시각에 관련한 시맨틱 쿼리를 호출함으로써 스냅샷 애트리뷰트를 존중한다. 그 자체로서, 결과는 최초 날짜/시각에 관한 것이고, 그에 따라 송신자의 의도를 존중하게 된다.

5. 가상 지식 커뮤니티

가상 지식 커뮤니티(에이전시)는 지식 커뮤니티의 게시자가 일군의 서버를 하나의 서버인 것처럼 보이도록 게시할 수 있게 해주는 정보 신경 시스템의 특징을 말한다. 예를 들어, Reuters는 (제약, 석유 및 가스, 제조, 금융 서비스 등에 대해) 산업별 Reuters 지식 커뮤니티를 가질 수 있지만 또한 하나의 'Reuters' 지식 커뮤니티를 노출하도록 선택할 수 있다. 이를 위해, Reuters는 (XML 웹 서비스의 WSDL로의 URL보다는) 가상 지식 커뮤니티에 대한 SQML을 게시하고 발표한다. SQML은 실제 지식 커뮤니티의 WSDL의 블렌더(blender)(또는 컬렉션)를 포함하게 된다. 이어서, 시맨틱 브라우저는 SQML을 택하고 (지식 커뮤니티가 하나의 서버인 것처럼) 지식 커뮤니티에 대한 아이콘을 디스플레이한다. 지식 커뮤니티에 대한 어떤 동작도 SQML로 각 서버에 전파된다. 사용자가 동작에 대한 접근 권한을 갖지 않는 경우, 웹 서비스 호출은 그에 따라 실패하게 되고, 그렇지 않은 경우 동작은 수행된다(사용자가 지식 커뮤니티를 포함하는 블렌더를 수동으로 생성한 경우와 전혀 다르지 않다).

6. 시간에 민감한 시맨티 쿼리의 구현

시간에 민감한(time-sensitive) 시맨틱 쿼리는 양호하게는 문제의 지식 커뮤니티에서의 지식 생성의 속도를 참작하기 위해 지능적 방식으로 구현된다. 예를 들어, 초당 10개의 문서를 수신하는 서버 상에서의 "속보"는 매월 10개의 문서를 수신하는 서버 상에서의 "속보"와 동일하지 않다. 그 자체로서, 서버측 시맨틱 쿼리 프로세서는 양호하게는 서버에 정보가 누적되는 속도에 따라 그의 시간에 민감한 시맨틱 쿼리 처리를 조정하게 된다. 이를 구현하기 위해서, 예를 들어 일반적 경험칙이 사용될 수 있다.

● 가장 최근의 N개의 객체(단, N은 분당 새로운 객체의 수에 기초하여 조정된다).

● 객체의 수에 대한 상한선을 갖는 지난 N분 동안 수신된 모든 객체(즉, min(상한선, 지난 N분 동안 수신된 모든 객체)).

N도 역시 쿼리가 헤드라인인지 속보인지에 기초하여 조정될 수 있다. 바람직한 실시예에서, 뉴스 메이커 쿼리는 양호하게는 헤드라인과 동일한 시간-민감성 파라미터로 구현된다.

7. 텍스트-음성 변환 스킨 개요

텍스트-음성 변환(Text-to-Speech)은 객체 레벨에서 또 요청 레벨에서 구현된다. 객체 레벨에서, 객체 스킨은 객체의 SRML을 받기 위해 스크립트를 실행하고, SRML을 해석하며 이어서 (SRML 필드 내의) 선택된 텍스트를 음성 출력을 생성하는 (예를 들어, 마이크로소프트 윈도즈 음성 SDK를 사용하는) 텍스트-음성 변환 엔진으로 전달한다.

도 5는 텍스트-음성 변환 객체 스킨을 예시하는 다이어그램을 나타낸 것이다. 실행될 때, 도 5에 도시된 파이프라인의 결과 이하의 음성 출력이 얻어진다.

1. 이메일 메시지 읽기

2. 적절한 지연

3. Nosa Omoigui로부터의 메시지

4. 적절한 지연

5. John Smith로 전송되는 메시지

6. 적절한 지연

7. Joe 아무개로 복사된 메시지

8. 적절한 지연

9. 메시지 주제는 웹 서비스가 분산 컴퓨팅에 사용되는 소프트웨어 구성 블록이라는 것이다

10. 적절한 지연

11. 메시지 요약은 웹 서비스이다

12. 적절한 지연

13. [선택적] 메시지 보디는 웹 서비스가 분산 컴퓨팅에 사용되는 소프트웨어 구성 블록이라는 것이다

이 예는 다음과 같이 음성 스킨 템플릿을 가정한다.

1. 이메일 메시지 읽기

2. 적절한 지연

3. ＜메시지 저작자 이름＞으로부터의 메시지

4. 적절한 지연

5. ＜메시지 수취인 이름＞으로 전송되는 메시지

6. 적절한 지연

7. ＜cc 메시지 수취인 이름＞으로 복사되는 메시지

8. 적절한 지연

9. 메시지 주제는 ＜메시지 주제 텍스트＞이다

10. 적절한 지연

11. 메시지 요약은 ＜메시지 보디 요약＞이다

12. 적절한 지연

13. [선택적] 메시지 보디는 ＜메시지 보디＞이다

다른 템플릿도 역시 용이하게 이해가능하고 또 렌더링되는 객체 타입의 시맨틱스를 전달하는 음성을 렌더링하기 위해 사용될 수 있다. 상기 보여준 예(이메일에 대한 것)와 마찬가지로, 구현은 객체 타입의 시맨틱스를 포착하기 위해 모든 정보 객체 타입에 대해 적절한 텍스트-음성 변환 템플릿을 사용해야만 한다.

요청 레벨에서, 시맨틱 브라우저의 프리젠테이션 엔진(프리젠터)은 (사용자가 선택한 커서 위치에 기초하여) 렌더링되고 있는 모든 현재 객체들에 대한 SRML을 받는 스킨을 로드한 다음에 각 객체에 대해 텍스트-음성 변환 객체 스킨을 호출한다. 이것은 본질적으로 렌더링되고 있는 각 XML 객체에 대해 차례대로 텍스트-음성 변환 동작을 반복한다.

이메일 객체(SRML)

객체 해석 엔진(객체 스킨)

텍스트-음성 변환 엔진

보낸이: Nosa Omoigui

받는이: John Smith

Cc: Joe 아무개

주제: 웹 서비스

요약: 웹 서비스는 분산 컴퓨팅에 사용되는 소프트웨어 구성 블록이다.

보디: 웹 서비스는 ...

음성 출력

이메일 메시지 읽기

지연

음성 출력

Nosa Omoigui로부터의 메시지

지연

음성 출력

John Smith로 전송되는 메시지

지연

음성 출력

Joe 아무개로 복사되는 메시지

지연

메시지 주제는 웹 서비스가 분산 컴퓨팅에 사용되는 소프트웨어 구성 블록이라는 것이다

음성 출력

지연

음성 출력

메시지 요약은 웹 서비스이다

지연

음성 출력

메시지 요약은 웹 서비스이다

도 6은 요청 스킨을 통해 시맨틱 브라우저 내에 제공되는 몇가지 이메일 객체의 예시를 나타낸 것이다.

보낸이: Nosa Omoigui

받는이: John Smith

Cc: Joe 아무개

주제: 웹 서비스

요약: 웹 서비스는 분산 컴퓨팅에 사용되는 소프트웨어 구성 블록이다

보디: 웹 서비스는 ...

이메일 객체 1

객체 스킨(객체 1)

이메일 객체 2

이메일 객체 3

이메일 객체 N

8. 언어 번역 스킨

언어 번역 스킨은 변환이 언어축 상에 있다는 것을 제외하고는 텍스트-음성 변환 스킨과 유사하게 구현된다. XSLT 스킨(스마트 스타일)은 언어 번역을 실시간으로 자동적으로 수행하기 위해 소프트웨어 엔진을 호출한 다음에 언어들의 전체 집합을 고려하기 위해 유니코드(문자당 16비트)로 인코딩된 XML을 생성할 수 있다. 최종 프리젠테이션 출력을 생성하는 XSLT 변환은 이어서 번역된 XML의 콘텐츠가 주어지면 적절한 문자 세트를 사용하여 출력을 렌더링한다.

언어 불가지론적 시맨틱 쿼리(language-agnostic semantic query)

시맨틱 쿼리도 역시 언어 불가지론적 방식으로 호출될 수 있다. 이것은 시맨틱 브라우저에 의해 생성된 SQML을 KDS(또는 KBS)에 의한 해석에 적합한 형태로 번역하는 번역 계층(SQML 언어 번역기)을 가짐으로써 구현되며, 이 KDS는 차례로 하나 이상의 언어를 위해 도입된 지식 도메인 온톨로지(knowledge domain ontology)를 갖는다. SQML 언어 번역기는 서술어(예를 들어, 키워드, 텍스트, 개념, 카테고리 등)에 의해 참조되는 객체를 번역한 다음에 해석을 위해 그를 서버측 시맨틱 쿼리 프로세서로 전송한다. 이어서, 그 결과는 다시 언어 번역 스킨에 의해 원래의 언어로 번역된다.

9. 사용자 경험에서의 제1 클래스 객체로서의 카테고리

이것은 지식 커뮤니티의 카테고리들이 최종 사용자에게 노출되는 기준이 되는 특징을 말한다. 최종 사용자는 정보 타입, 예를 들어 '웹 서비스'로서의 카테고리에 대한 쿼리를 발행할 수 있다. 이어서, 임의의 제1 클래스 정보 객체 타입에 대한 경우에서와 같이 메타데이터가 시맨틱 브라우저 내에 디스플레이된다. 시각화, 동적 링크, 컨텍스트 팔레트 등도 역시 카테고리 객체를 피벗(pivot)으로 사용하여 이용가능하다. 이 특징은 카테고리를 파라미터로서 갖는 스마트 요청(스마트 에이전트)으로 시작하는 것과는 반대로 사용자가 카테고리로 시작하고 이어서 그를 동적 네비게이션(dynamic navigation)을 위한 피벗으로 사용하기를 원하는 경우에 유용하다.

10. 카테고리화된 주석

카테고리화된 주석은 제1 클래스 객체인 카테고리로부터 따라온다. 사용자는 카테고리에 직접 주석을 첨부할 수 있으며, 그에 따라 카테고리로 매핑되는 이메일 리스트를 시뮬레이션한다. 그렇지만, 많은 카테고리가 있는 경우(예를 들어, 의약에서), 이것은 추천되지 않는데 그 이유는 정보가 많은 카테고리에 속할 수 있고 사용자는 어느 카테고리에 주석을 첨부할지에 관해 생각할 필요가 없고 주석이 자동적으로 카테고리화되는 경우 사용자는 주석을 직접 지식 커뮤니티(에이전시)에 게시하거나 카테고리보다 더 컨텍스트적인 문서 또는 이메일 메시지와 같은 객체에 주석을 첨부해야 하기 때문이다.

11. 부가적인 컨텍스트 템플릿

1. 전문가(Experts) - 전문가 특징은 앞서 인용한 특허출원 제10/179,651호에서 특별 에이전트로서 표시되어 있다. 상기 출원으로부터 잘 알 수 있는 바와 같이, 전문가 특징도 역시 컨텍스트 템플릿 섹션과 연계하여 동작할 수 있다. 전문가는 컨텍스트 템플릿이고 그 이름이 암시하듯이 하나 이상의 주제 또는 컨텍스트에 전문 지식을 갖는 사람들을 나타낸다(PREDICATETYPEID_EXPERTON 서술어로 나타냄).

2. 관심 집단(Interest Group) - 이것은 그 이름이 암시하듯이 하나 이상의 주제 또는 컨텍스트에 관심을 가지고 있는 (그렇지만 꼭 전문 지식을 가지는 것은 아님) 사람들을 나타내는 컨텍스트 템플릿을 말한다(PREDICATETYPEID_INTERESTIN 서술어로 나타냄). 이 컨텍스트 템플릿은 시맨틱 네트워크 내의 임의의 시맨틱 카테고리에 관심을 보이는 사람들을 반환한다. 실제 세계 시나리오는 대답을 가지고 있는 사람들을 반환하는 Experts 및 질문(또는 대답)을 가지고 있는 사람들의 결과를 반환하는 관심 집단을 갖는다. 바람직한 실시예에서, 이것은 시맨틱 네트워크에서 차례로 카테고리화되는 정보를 저작한 사람들의 결과를 반환함으로써 구현되며 지식 도메인은 KIS를 위해 구성되어 있다. 본질적으로, 이 컨텍스트 템플릿은 사용자에게 관심의 동적, 시맨틱 커뮤니티를 제공한다. 이는 아주 강력한 컨텍스트 템플릿이다. 현재 대부분의 조직들은 관심의 커뮤니티를 나타내기 위해 이메일 배포 리스트(또는 기타 등등)를 사용한다. 그렇지만, 이들 리스트는 유지하기가 어려우며 관리자가 수동으로 조직 내의 어느 사람들이 양호하게는 리스트(들)에 속하는지를 추적해야만 한다. 그렇지만, 관심 그룹 컨텍스트 템플릿으로, "리스트들"은 이제 지능적이고 시맨틱하게 된다("스마트 배포 리스트"와 유사함). 리스트들은 또한 컨텍스트적이다, 즉 수동 이메일 배포 리스트가 없다는 특징을 갖는다.

다른 컨텍스트 템플릿에서와 같이, 이익 집단 컨텍스트 서술어는 차례로 서버측 시맨틱 쿼리 프로세서에 의해 해석된다. 이것에 의해 "Interest Group on XML" 또는 "Interest Group on Bioinformatics"와 같은 강력한 쿼리가 가능하게 된다. 이와 유사하게, 이것에 의해 (드래그/드롭 및/또는 스마트 복사/붙여넣기를 통해) "Interest Group on My Local Document" 및 "Interest Group on My Competitor(엔티티)"와 같은 쿼리가 가능하게 된다. 관심 집단 컨텍스트 템플릿은 또한 일건서류(Dossier)(또는 가이드) 컨텍스트 템플릿(이는 각각의 컨텍스트 템플릿에 대해 모든 특별 에이전트를 디스플레이하고 이들을 메인 에이전트/요청의 서브쿼리로서 로드함)의 일부가 된다.

바람직한 실시예에서, 컨텍스트 템플릿은 "관심 영역"을 검출하는 동안인 시간 제한을 가져야만 한다. 이것의 예로는 3개월이 있다. 여기서의 논리는 사용자가 3개월 동안 시맨틱적으로 SQML 필터(이용가능한 경우)와 관련성있는 어떤 정보(대부분 일반적으로 이메일임)도 저작하지 않은 경우, 사용자는 그 카테고리(또는 카테고리들)에 관심이 없거나 관심이 있었지만 더 이상은 없다는 것이다.

3. 내 아이템들의 주석(Annotations of My Items) - 이것은 주석의 변형인 컨텍스트 템플릿이지만 호출측 사용자에 의해 게시되었던 아이템들로 추가로 필터링된다. 이것에 의해 사용자는 자신이 게시하거나 또는 주석을 첨부했던 아이템들에 관한 피드백을 구체적으로 모니터링할 수 있다.

12. 사용자 상태의 가져오기 및 내보내기

시맨틱 브라우저는 사용자 상태의 가져오기(importation) 및 내보내기(exportation)를 지원한다. 사용자는 그의 개인적 상태를 저장하고 이를 다른 머신으로 내보내기를 할 수 있거나 그 역도 마찬가지이다. 이 상태를 이하의 것들에 대한 정보(및 메타데이터)를 포함한다.

● 디폴트 사용자 상태(예를 들어, 컴퓨터 복잡도, 디폴트 관심 영역, 디폴트 업무 역할, 디폴트 스마트 스타일, 기타 등등)

● 프로파일

● 엔티티(프로파일별)

● 스마트 요청(프로파일별)

● 로컬 요청(프로파일별)

● 가입된 지식 커뮤니티(프로파일별)

시맨틱 브라우저는 사용자가 사용자 상태 타입 중 어느 것을 가져오기 또는 내보내기해야 하는지를 선택할 수 있게 해주는 UI(아마도 마법사임)를 보여준다. 이 UI는 또한 식별자/로그온 정보를 포함할지 여부를 사용자에게 질문한다. UI가 호출될 때, 시맨틱 브라우저는 사용자 상태를, 모든 사용자 상태 타입의 메타데이터에 대응하는 필드를 갖는 XML 문서로 직렬화한다. XML 문서가 가져오기될 때, 시맨틱 브라우저는 XML 문서 노드들을 네비게이션하고 XML 문서 내의 노드들에 대응하는 클라이언트 환경에서 사용자 상태 타입을 부가 또는 설정한다.

13. 로컬 스마트 요청

로컬 스마트 요청은 사용자가 지식 커뮤니티(에이전시)로부터의 카테고리를 사용하여 로컬 정보를 브라우징할 수 있게 해준다. 카테고리화된 로컬 요청의 경우, 시맨틱 클라이언트는 로컬 하드 드라이브, 이메일 스토어, 기타 등등을 크롤링(crawl)하고, 메타데이터(요약을 포함함)를 추출하며 이 메타데이터를 시맨틱 메타데이터 스토어(SMS)의 로컬 버전에 저장한다. 클라이언트는 (그의 XML 웹 서비스를 통한) 카테고리화를 위해 XML 메타데이터(객체별)를 지식 커뮤니티로 전송한다. 지식 커뮤니티는 이어서 카테고리 할당 메타데이터로 응답한다. 이어서, 클라이언트는 (로컬 SMS를 통해) 로컬 시맨틱 네트워크를 업데이트하고 서버가 하는 것처럼 시맨틱 요청에 응답한다. 본질적으로, 이 특징은 로컬 서버를 필요로 하지 않고 로컬 서버와 동등한 기능을 제공할 수 있다.

14. 통합된 네비게이션

통합된 네비게이션은 사용자가 (오른쪽에 있는 메인 결과 창에서) 프리젠터 내부로부터 동적으로 네비게이션하고 이 네비게이션을 좌측에 있는 쉘 확장자 네비게이션과 통합시킬 수 있게 해준다. 본질적으로, 이것은 2개의 스택을 병합한다. 바람직한 실시예에서, 이것은 이벤트 시그널링을 통해 달성된다. 프리젠터가 새로운 요청으로 동적으로 네비게이션하고자 하는 경우, 프리젠터는 현재의 브라우저 뷰를 식별해주는 GUID로부터 어떤 상태를 설정한다. GUID는 역시 "Navigation Event", 'Next Namespace Object ID' 및 'Next Path'라고 하는 필드를 갖는 레지스트리 내의 키에 매핑된다. 'Navigation Event' 필드는 현재 프라우저 뷰가 로드될 때 그에 의해 생성되는 이벤트 핸들을 가리키는 DWORD 값을 보유한다. 프리젠터가 새로운 요청으로 네비게이션하고자 할 때, 프리젠터는 시맨틱 환경에서 그 요청을 생성하고 그 요청의 반환된 ID를 캐싱한다. 프리젠터는 이어서 (요청의 정보/컨텍스트 타입에 따라) 그 요청의 적절한 네임스페이스 경로를 동적으로 가져오고 또한 그를 캐싱한다. 프리젠터는 이어서 2개의 필드(이들 2개의 값을 갖는 'Next Namespace Object ID' 및 'Next Path')를 설정한다. 그 다음에, 프리젠터는 'Navigation Event'를 설정한다(Windows에서, 이것은 'SetEvent'라고 하는 Win32 API를 호출함으로써 행해진다).

네비게이션 이벤트를 포착하기 위해, 브라우저 뷰는 처음으로 기동될 때 적 업 쓰레드(worker thread)를 기동시킨다. 이 쓰레드는 네비게이션 이벤트를 기다린다(또한 동시에 브라우저 뷰가 종료되고 있을 때 신호되는 종료 이벤트를 기다린다 - Windows에서 이것은 'WaitForMultipleObjects'라는 이름의 Win32 API를 통해 행해진다). 네비게이션 이벤트가 신호되면, 'Wait'API는 네비게이션 이벤트가 신호되었다는 표시를 반환한다. 작업 쓰레드는 이어서 네비게이션 상태(객체 id 및 경로)를 검색하기 위해 레지스트리를 탐색한다. 작업 쓰레드는 이어서 이 객체 id 및 경로로 네비게이션하기 위해 쉘 브라우저를 호출한다(Windows에서, 이것은 'PIDL'을 검색한 다음에 IShellView를 구현하는 쉘 뷰 인스턴스로부터 IShellBrowser::BrowserTo를 호출함으로써 행해진다).

15. 방문 결과에 대한 힌트

Nervana 시맨틱 브라우저는 사용자가 생각의 속도로 지식 공간을 동적으로 네비게이션할 수 있게 해준다. 사용자는 컨텍스트를 따라 정보 또는 시간축을 네비게이션한다. 그렇지만, 사용자가 네비게이션할 때, 사용자는 중복되는 정보를 제공받을 수 있다. 예를 들어, 사용자는 로컬 문서로부터 '속보'로 또 이어서 '속보' 결과 객체들 중 하나로부터 '헤드라인'으로 네비게이션할 수 있다. 그렇지만, 시맨틱적으로, 헤드라인들 중 어떤 것은 (특히 충분한 시간이 경과하지 않았을 경우) 속보와 중복될 수 있다. 이것은 웹을 브라우징하고 동일한 페이지를 서로 다른 '각도'에서 반복하여 히팅(hit)하는 것과 동등하다

Nervana 시맨틱 브라우저는 최근에 제공된 결과의 로컬 캐시를 가짐으로써 이러한 중복성 문제를 처리한다. 프리젠터는 이어서 결과를 서로 다른 색상 또는 어떤 다른 UI 메카니즘으로 보여줌으로써 중복되는 결과를 사용자에게 나타낸다. 로컬 캐시는 (양호하게는 몇시간 또는 일반적인 "브라우징 경험"의 측정 시간 이후에) 에이징된다. 오래된 엔트리는 제거되고 캐시는 궁극적으로 충분한 시간이 경과한 후에 리셋된다.

다른 대안에서, 사용자 임의로, 중복되는 결과는 폐기되어 전혀 제공되지 않을 수 있다. 구체적으로 말하면, 예를 들어, 동일한 메타데이터를 갖는 객체가 서로 다른 지식 커뮤니티(에이전시)에 나타나는 경우, 시맨틱 브라우저는 또한 프리젠터에서 똑같은 결과를 렌더링하기 전에 그 결과를 제거함으로써 똑같은 결과를 처리하게 된다. 시맨틱 브라우저는 메타데이터 비교를 수행함으로써 이것을 검출하게 된다. 문서, 이메일 등과 같이 비구조화된 데이터의 경우, 시맨틱 브라우저는 요약을 비교하게 된다 - 요약이 동일한 경우, 문서가 동일할 가능성이 아주 많다(그렇지만 이것이 절대적으로 보증되는 것은 아니며, 아주 긴 문서의 경우는 특히 그렇다).

16. 지식 연합(Knowledge Federation)

클라이언트측 지식 연합

클라이언트측 지식 연합은 사용자가 지식 커뮤니티를 연합시키고 결과들이 한 곳에서 온 것처럼 이들을 대해 동작할 수 있게 해준다(이 연합 특징은 모출원 제10/179,651호에 기술되어 있다). 바람직한 실시예에서, 이러한 클라이언트측 지식 연합은 시맨틱 브라우저가 SRML 결과들이 서로 다른 (연합된) KIS들로부터 도착할 때 그 결과들을 병합함으로써 달성된다.

서버측 지식 연합

서버측 지식 연합은 외부 지식을 지식 커뮤니티의 범위 내에서 연합시킬 수 있게 해주는 기술이다. 예를 들어, 많은 회사들은 자기들에게 정보를 제공해주는 Reuters와 같은 외부 콘텐츠 제공업자에 의존한다. 그렇지만, 정보 신경 시스템에서, 주석, 개인 게시물 등에 관련한 보안 및 프라이버시 문제가 일어난다. 많은 회사 고객들은 민감한 주석이 외부 콘텐츠 제공업자에 의해 호스팅되고 관리되는 원격 서버에 저장되는 것을 원하지 않는다.

이를 해소하기 위해, 외부 콘텐츠 제공업자는 자신들의 콘텐츠를, 그 회사에 의해 호스팅되고 관리되는 KIS 메타데이터 캐시 상으로 제공한다. 예를 들어, Reuters는 자신의 콘텐츠를 인텔과 같은 고객에게 제공하지만 인텔이 KIS를 호스팅하고 관리한다. 인텔 KIS는 Reuters KIS(그에 따라 KIS 서버를 연쇄화함) 또는 Reuters DSA를 크롤링한다. 이와 같이, 민감한 인텔 주석은 Reuters 콘텐츠를 콘텐츠로서 사용하여 "포스트-잇"으로서 게시될 수 있는 반면 인텔은 여전히 그의 민감한 데이터에 대한 통제를 유지하고 있다.

연합된 주석

연합된 주석은 사용자가 하나의 에이전시/서버(KIS)로부터 오는 객체에 주석을 첨부하고 다른 서버 상의 "포스트-잇"과 같은 코멘트(및/또는 첨부물(들))를 갖는 객체에 주석을 첨부할 수 있게 해주는 아주 강력한 특징이다. 예를 들어, 서버(서버 A라고 함)는 주석을 지원하지 않을 수 있다(이것은 관리자에 의해 구성가능하며 신뢰의 도메인 및 검증가능한 식별자를 갖지 않는 인터넷 기반 서버의 경우 통상의 경우일 수 있다). 사용자는 문서(또는 임의의 다른 시맨틱 결과)를 서버 A로부터 가져올 수 있지만 주석을 지원하는 하나 이상의 에이전시(KIS)(보다 일반적으로 말하면, 신뢰의 도메인 및 검증가능한 식별자를 갖는 인트라넷 또는 엑스트라넷 기반 에이전시) 상에서 그 객체에 주석을 첨부하고자 할 수 있다. 이러한 경우, 주석 이메일 메시지는 주석이 첨부될 객체의 URI를 포함하게 된다(이메일 메시지 및 그의 첨부물(들)은 주석 자체를 포함하고 있다). 서버가 그의 시스템 받은 편지함(System Inbox)을 크롤링하고 이메일 주석을 선택할 때, 서버는 주석의 인코딩된 받는이(To) 또는 주제(Subject) 필드를 스캔하고 주석이 첨부될 객체의 URI를 추출한다. URI가 다른 서버를 참조하는 경우, 서버는 객체에 대한 SRML 메타데이터를 가져오기 위해 (접근 권한을 갖는 경우) 그 서버로의 XML 웹 서비스 호출을 호출한다. 이어서, 서버는 SRML 메타데이터를 그의 시맨틱 메타데이터 스토어(SMS)에 부가하고, 이메일 주석으로부터의 적절한 시맨틱 링크를 SRML 객체에 부가한다. 이것이 아주 강력한 이유는 그것은 에이전시의 사용자가 주석을 보게 되고 또한 주석이 첨부된 객체가 다른 서버로부터 온 것일지라도 시맨틱적으로 그 객체로 네비게이션할 수 있음을 의미하기 때문이다.

(주석에 대한) 목적지 서버가 주석이 첨부될 객체가 존재하는 서버로의 접근 권한을 갖지 않는 경우, 목적지 서버는 클라이언트에 이것을 통보하고 이어서 클라이언트는 (그 객체가 존재하는) 서버로부터 SRML을 가져오고 완전한 SRML을 (주석에 대한) 목적지 서버로 다시 전송해야만 한다. 이 구현은 본질적으로 목적지 서버가 URI 자체를 "역참조(de-reference)"하도록 하는 것이 아니라 클라이언트가 먼 저 URI를 "역참조"하고 SRML을 목적지 서버로 전송해야만 한다는 것을 의미한다. 이 방식은 CPU 및 I/O 부하를 그의 클라이언트들에 걸쳐 분산시키기 때문에 성능의 이유로 우수할 수 있다(왜냐하면 클라이언트들이 URI의 다운로드 및 SRML로의 "역참조"를 해야만 하기 때문이다).

연합된 주석에 대한 시맨틱 경고

시맨틱 브라우저가 정규적으로(예를 들어, 매분마다) 각각의 현재 보는 객체와 관련된 "속보"를 얻기 위해 현재 보고 있는 사용자 프로파일 내의 각 KIS에 폴링을 하는 것과 동일한 방식으로, 주석에 대해서도 똑같이 수행된다. 본질적으로, 이것은 현재 디스플레이되는 각 객체가 "이제 막 주석이 첨부되었는지"를 폴링하는 것과 유사하다. 연합되지 않은 주석(즉, 주석을 첨부하는 객체로의 강력한 시맨틱 링크를 갖는 주석)의 경우, 이것은 주석이 첨부된 객체의 출처인 KIS로의 간단한 SQML 콜백이다. 그렇지만, 연합된 주석의 경우, 이 프로세스는 약간 더 복잡한데 그 이유는 객체의 출처인 KIS가 주석을 지원하지 않거나 특정 객체에 대한 주석을 포함하지 않을지라도 다른 KIS 상에서 객체의 복사에 주석 첨부되었을 수 있기 때문이다.

이 경우, 디스플레이되는 각 객체에 대해, 시맨틱 브라우저는 선택된 프로파일 내의 각 KIS에 폴링을 하고 그 객체가 KIS 상에서 주석 첨부되었는지를 KIS에 "질문"하기 위해 객체의 URI를 전달한다. 이와 같이, 시맨틱 경고는 연합된 주석에 대해서도 생성된다.

주석 힌트

이것은 KIS가 객체가 주석 첨부되었음을 나타내는 컨텍스트 애트리뷰트를 반환하는 경우의 특징을 말한다. KIS가 (일반적으로 시스템 받은 편지함으로부터) 주석을 검출하고 시맨틱 네트워크를 업데이트하고 있을 때 이것은 캐싱될 수 있다. 이어서, 이 컨텍스트 애트리뷰트는 성능 최적화기가 되는데, 그 이유는 애트리뷰트 세트를 갖는 그 객체들에 대해 그 객체가 주석 첨부되었는지 검사하기 위해 클라이언트가 다시 KIS에 쿼리를 할 필요가 없기 때문이다. 이것은 KIS로의 추가의 (불필요한) 라운드트립 호출(roundtrip call)을 피하기 위해 객체의 상태를 캐싱하는 것과 같다.

주석에 대한 다른 관점

정보 신경 시스템의 간단한 시맨틱 주석 특징을 보는 다른 방식은 이제 사용자의 지식 세계 내의 모든 객체/아이템/결과가 그 자신의 컨텍스트 받은 편지함을 갖는다는 것이다. 그런 식으로, 사용자가 객체를 보는 경우, 객체의 컨텍스트와 연관된 받은 편지함은 항상 볼 수 있다. 환언하면,

연합된 지식 커뮤니티에 대한 카테고리 명명 및 식별자(URI)

이것은 카테고리가 연합된 지식 커뮤니티 상에서 어떻게 명명되는지를 말한다. 예를 들어, 인텔에 설치된 Reuters 지식 커뮤니티(에이전시)는 'Reuters@Intel/Information Technology/Wireless/80211'과 같이 명명된 카테고리를 갖는 Reuters@Intel로 명명된다. 바람직한 실시예에서, 모든 카테고리는 적어도 이하의 프로퍼티를 갖추게 된다.

● 지식 도메인 ID - 이것은 카테고리의 출처인 지식 도메인을 일의적으로 식별해주는 전역적으로 고유한 식별자이다.

● 이름 - 이것은 카테고리의 이름이다.

● 경로 - 이것은 카테고리의 전체 분류 경로이다.

바람직한 실시예에서, 카테고리 지식 도메인 id(이름이 아님)는 양호하게는 카테고리 URI에서 사용되는데, 그 이유는 지식 도메인이 진화함에 따라 카테고리가 재명명(rename)될 수 있기 때문이다(그렇지만 식별자는 동일하게 유지되어야만 한다). 바람직한 실시예에서 카테고리 URI의 예는 다음과 같다.

nerv://c9554bce-aedf-4564-81f7-48432bf8e5a0?type=category＆path=Information Technology/Wireless/80211

이 예에서, 지식 도메인 id는 c9554bce-aedf-4564-81f7-48432bf8e5a0이고, URI 타입은 'category'이며, 카테고리 경로는 "Information Technology/Wireless/80211"이다.

17. 익명의 주석 및 게시

시맨틱 브라우저는 또한 사용자가 익명으로 주석을 첨부하고 지식 커뮤니티(에이전시)에 게시할 수 있게 해준다. 이 모드에서, 메타데이터는 (사용자 식별자와 함께) 완전히 저장되지만 게시자가 익명으로 남고 싶다는 것을 나타내는 플래그가 붙어 있다. 이와 같이, 추론 엔진(Inference Engine)은 완전한 메타데이터를 사용하여 추론할 수 있지만 게시자에 대한 요청은 그의 식별자를 노출하지 않는다. 다른 대안에서, 관리자는 또한 추론 엔진이 익명의 주석 또는 게시를 사용하여 추론할 수 없도록 지식 커뮤니티(에이전시)를 구성할 수 있다.

18. 시맨틱 브라우저에서의 오프라인 지원

시맨틱 브라우저는 또한 오프라인 지원을 갖는다. 브라우저는 모든 원격 호출에 대한 캐시를 갖는다. 캐시는 XML 데이터로의 엔트리를 포함하게 된다. 이것은 SRML이거나 XML 웹 서비스로의 호출로부터 반환되는 임의의 다른 데이터일 수 있다. 각 호출은 시맨틱 브라우저에 의해 고유의 서명을 부여받으며, 이 서명은 XML 데이터로 해싱하는 데 사용된다. 예를 들어, 시맨틱 쿼리는 그의 SQML에 의해 해싱된다. 다른 원격 호출은 메소드 이름, 인수 이름 및 타입, 그리고 인수 데이터의 조합을 사용하여 해싱된다.

XML 웹 서비스로의 모든 호출에 대해, 시맨틱 런타임 클라이언트는 호출의 서명을 추출하고 이어서 이것을 로컬 캐시 내의 엔트리로 매핑한다. 브라우저(또는 시스템)가 현재 오프라인인 경우, 클라이언트는 캐시 내의 XML 데이터를 반환한다(그것이 존재하는 경우). 그것이 존재하지 않는 경우, 클라이언트는 호출자(아마도 프리젠터임)에게 에러를 반환한다. 브라우저가 온라인인 경우, 클라이언트는 XML 웹 서비스로부터 XML 데이터를 검색하고 파일 엔트리의 이전 내용을 서명 해시에 의해 표시된 파일 경로로 덮어쓰기함으로써 캐시를 업데이트한다. 이것은 원격 호출이 실제로 완료되는 것을 가정한다 - 시스템/브라우저가 온라인인 경우조차도 네트워크 트래픽 및 다른 조건으로 인해 그렇지 않을 수 있다. 이러한 경우, 캐시는 덮어쓰기되지 않는다(캐시는 새로운 데이터가 있을 때만 덮어쓰기 된다. 캐시가 먼저 클리어되지 않는다).

19. 시맨틱 브라우저에서의 보장된 교차 플랫폼 지원

개요

모출원(제10/179,651호)에 기술되어 있는 바와 같이, 정보 신경 시스템은 교차 플랫폼 방식으로 구현될 수 있다. 표준 프로토콜은 양호하게는 가능한 경우에 이용되며, 웹 서비스 계층은 상호 운용 가능한 웹 서비스 표준을 사용하고 독점적인 구현을 피해야만 한다. 본질적으로, 테스트는 시맨틱 브라우저와 대화하는 지식 커뮤니티(또는 에이전시) 웹 서비스가 다른 것 상부의 특정의 플랫폼 상에서 실행되고 있는지 여부를 "알고" 있을 필요가 없다는 것이다. 예를 들어, 시맨틱 브라우저는 그와 대화하는 웹 서비스가 Microsoft의 .NET™ 플랫폼 또는 Sun의 J2EE 플랫폼(독점적인 애플리케이션 서버의 예를 2가지 든다면), 리눅스 또는 임의의 다른 "오픈 소스" 서버 상에서 실행되고 있는지를 알고 있을 필요가 없다. 지식 커뮤니티 웹 서비스 및 클라이언트-서버 프로토콜은 .NET™ 및 J2EE™과 같은 서로 다른 웹 서비스 구현에 의해 공통적으로 지원되는 웹 서비스 표준을 이용해야만 한다.

이상적인 세계에서, 웹 서비스 벤더 구현들에 걸쳐 승인되고 적절히 구현된 공통의 표준 세트가 있다. 그렇지만, 실제 세계에서는 그렇지 않을 수도 있으며, 적어도 아직은 그렇다. 시맨틱 브라우저가 서로 다른 웹 서비스 구현에서 고유의 기능을 처리해야만 하는 경우를 처리하기 위해, 지식 커뮤니티 스키마는 양호하게는 웹 서비스 플랫폼 구현을 나타내는 필드를 포함하도록 확장된다. 예를 들어, 지식 커뮤니티의 .NET™ 구현은 양호하게는 플랫폼이 .NET™임을 나타내는 필드로 게시된다. 똑같은 것이 J2EE™에도 적용된다. 시맨틱 브라우저는 이어서 (지식 커뮤니티로의 WSDL URL을 통해 직접 또는 멀티캐스트, 엔터프라이즈 디렉토리(예를 들어, LDAP), 글로벌 지식 커뮤니티 디렉토리, 기타 등등을 통해 통지를 수신하는 것에 의해) 지식 커뮤니티에 대한 메타데이터를 검색할 때 이 필드에 액세스한다.

이어서, 시맨틱 브라우저는 지식 커뮤니티가 실행되고 있는 플랫폼에 따라 플랫폼 관련 호출을 발행할 수 있다. 이것은 추천되는 방식이 아니지만, 플랫폼 관련 호출을 해야 할 필요가 절대적으로 있을 경우, 양호하게는 이 모델이 바람직한 실시예에서 이용된다.

20. 지식 모델링

지식 모델링은 기업들이 정보 신경 시스템을 설치하는 추천되는 방식을 말한다. 이것은 관련 온톨로지 및 분류를 호스팅하는 몇 개의 KIS 서버(상위 레벨 지식 도메인마다) 및 하나의(또는 최대 몇 개의) KDS(이전에는 KBS라 함) 서버를 설치하는 것을 포함한다. KIS 서버는 양호하게는 네트워크 내에서의 네비게이션과 추론의 지식 공유 가능성이 충분하지 않을 정도로 너무 좁은 것과 확장성(데이터베이스 및/또는 추론 엔진이 필요로 하는 스토리지 및 CPU 마력에 있어서)이 문제가 될 정도로 너무 높은 것 간의 균형을 이루기 위해 도메인마다 설치된다. 물론, 하드웨어 및 소프트웨어 기술이 진화함에 따라 특정의 균형점은 시간에 따라 이동되고, 바람직한 실시예는 특정의 균형이 잡힌 것에 의존하지 않는다. 게다가, 다수의 그룹이 동일한 KIS를 공유하는 경우 그룹 레벨에서 액세스 제어를 강요하는 것과는 반대로, KIS 서버는 양호하게는 액세스 제어가 (더 높은 수준의 보안을 위해) 서버 레벨에서 필요한 경우에 설치된다. 예를 들어, 대규모 제약 회사는 전체 회 사에 대한 온톨로지를 위한 지식 커뮤니티 KIS 및 최첨단 R＆D에 종사하며 전략적 특허를 출원하는 연구원을 위한 또하나의 KIS를 가질 수 있다. 이들 2개의 KIS는 동일한 정보 소스를 크롤링할 수 있지만 후자의 KIS가 더 안전한데 그 이유는 R＆D 그룹의 사용자에게만 액세스를 제공하기 때문이다. 또한, 선택적으로, 이들 연구원들의 게시 및 주석은 회사 KIS 상에서는 볼 수 없다.

도 7은 제약 회사에 대한 가능한 지식 아키텍처의 예를 나타낸 것이다. 도 7에 도시한 바와 같이, KDS는 다음과 같은 몇 개의 보조 KIS에 서비스할 수 있다.

클라이언트

지식 통합 서버 1(종양학)

지식 통합 서버 2(약물학)

지식 통합 서버 3(바이오기술)

지식 통합 서버 4(심장병학)

지식 도메인 서버(의약)

21. KIS 하우스키핑 규칙

지식 통합 서버(KIS)는 관리자가 오래되거나 쓸모없는 메타데이터를 제거하기 위해 '하우스키핑'규칙을 설정할 수 있게 해준다. 이것은 KIS 상의 SMS가 무한정으로 커지는 것을 막아준다. 이들 규칙은 일정 나이(오래된 데이터를 유지하는 회사의 정책에 따라 2년 내지 5년)보다 오래되고 어떤 주석도 갖지 않으며 또 즐겨찾기로 마크(또는 등급 지정)되지 않은 메타데이터를 제거하는 것처럼 간단할 수 있다.

22. 클라이언트 컴포넌트 통합 및 상호작용 작업 흐름

시스템의 클라이언트 컴포넌트는 작업 흐름 상호작용 또는 용법 패턴에서와 같이 몇 개의 서로 다른 단계 또는 시퀀스에서 통합될 수 있다. 현재 바람직한 실시예에서, 작업 흐름 및 컴포넌트 상호작용은 다음과 같다.

1) 쉘: 사용자는 UI 네비게이션 또는 마법사를 통해 SQML 쿼리를 묵시적으로 생성한다.

2) 쉘: 사용자는 (트리 또는 폴더 뷰를 통해) 에이전트를 연다

3) 쿼리 버퍼는 파일로서 저장되고, 생성된 레지스트리 엔트리가 에이전트에 대해 생성된다.

a) 레지스트리 엔트리는 에이전트 이름, 생성 날짜, 에이전트(요청) GUID, SQML 경로, 코멘트, 네임스페이스 객체 타입(에이전시, 에이전트, 블렌더 등) 및 애트리뷰트를 포함한다.

4) 쉘: 요청이 프리젠터로 넘겨진다.

a) (요청을 생성한 네임스페이스 경로 및 SQML 파일 URL을) 포함하는 레지스트리 요청 GUID 엔트리가 생성된다.

b) 커맨드 라인 http://Presenterpage.html#RequestGUID http://presenterpapge.html/ 로 브라우저가 초기화되고 열린다. 프리젠터는 페이지 내에 포함된 디폴트 Chrome을 로드한다.

c) 프리젠터 페이지는 프리젠터 바이너리 거동 및 시맨틱 런타임 OCX를 로드한다.

5) 프리젠터: SQML을 로드하고 쿼리 관리자를 통해 요청을 발행한다.

a) SQML 파일 경로를 가져오기 위해 요청 GUID를 분석한다.

b) SQML 파일을 버퍼로 로드하고, 리소스 핸들러 요청을 생성하며, 이들을 리소스 핸들러로 전달하고, 결과를 기다리고 수집한다. 로컬 리소스의 요약이 여기에서 행해진다. 모든 요약은 2개의 경로, 이 파일 경로로 표시된 문서를 요약하거나 이 텍스트(클립보드, 아웃룩, 익스체인지 등으로부터 추출됨)를 요약하는 것 중 하나를 따라간다. 경로 둘다는 요약을 시맨틱 서버 XML 웹 서비스로의 요청에 포함하기에 적합한 동일한 형태로 생성한다.

c) SQML 파일을 상기로부터의 임의의 리소스 요약을 포함하는 개별적인 서버 요청 버퍼로 컴파일한다.

d) 시맨틱 런타임 클라이언트 쿼리 관리자를 호출함으로써 서버 요청을 개시한다.

6) 쿼리 관리자: 서버 요청을 모니터링하고 데이터에 대한 콜백을 행한다. 이는 또한 요청 완료 또는 타임아웃 시에 이벤트를 신호한다. 이 콜백은 프리젠터에 대한 것이며, 이는 XML을 전달하는 프로세스간 메시징을 의미한다.

7) 프리젠터: 데이터를 수신하고 적절한 스킨을 로드한다.

a) 버퍼 내의 SRML 데이터를 수신한다. 이것은 점증적으로 일어난다.

b) 이 에이전트와 연관된 바람직한 스킨이 있는지를 판정하고, 그렇지 않은 경우 디폴트 스킨을 선택한다.

c) XSLT를 통해 SRML을 바람직한 스킨 포맷으로 변환한다. 이것은 결과가 들어올 때 결과의 트리에 대해 다단계이다(루트가 리스트이고, 그 다음이 객체, 그 다음이 Deep/Lens/BN 정보이다).

d) 페이지 내의 타겟 DIV에 결과를 디스플레이한다. 타겟은 거동 자체에 대한 인수이고 루트 페이지에 의해 정의된다.

8) 프리젠터: 컨텍스트 패널(컨텍스트 템플릿마다)을 채우는 시맨틱 런타임, 깊이 있는(deep) 정보, 스마트 복사 및 붙여넣기, 및 다른 시맨틱 커맨드를 호출한다. 프리젠터는 또한 스마트 스타일을 호출하고, 이는 이어서 요청의 시맨틱스와 부합하는 시맨틱 이미지, 움직임 등을 로드한다.

도 8은 상기한 현재 바람직한 클라이언트 컴포넌트 통합 및 상호작용 작업 흐름을 예시한 것이다.

23. 카테고리 대화 상자 사용자 인터페이스 규격

a. 개요

카테고리 대화 상자는 사용자가 지식 도메인에 속하는 카테고리 폴더(또는 분류)로부터 하나 이상의 카테고리를 선택할 수 있게 해준다. 어떤 상황에서는 더 많이 또는 더 적게 설치될 수 있지만, 바람직한 실시예에서 대화 상자는 이하의 사용자 인터페이스 콘트롤 모두를 갖는다.

1. 프로파일 - 이것은 사용자가 구성된 관심 영역에 기초하여 카테고리 폴더(또는 분류)를 필터링하는 데 사용하는 프로파일을 선택할 수 있게 해준다. 예를 들어, 프로파일이 "건강 및 의료(Health and Medicine)"로 설정된 관심 영역을 갖는 경우, 그 프로파일을 선택하면 "건강 및 의료" 관심 영역(예를 들어, 의약, 건 강관리, 및 유전자)에 속하는 그 카테고리 폴더만을 디스플레이 한다. 이 콘트롤은 사용자가 다른 도메인으로부터의 분류를 볼 필요없이 그의 지식 도메인과 관련된 분류상에 포커싱 할 수 있게 해준다.

2. 관심 영역 - 이것은 사용자가 특정의 관심 영역을 선택할 수 있게 해준다. 기본적으로, 이 콤보 박스는 "내 관심 영역(My Areas of Interest)"으로 설정되어 있으며 프로파일 콤보 박스는 "모든 프로파일(All Profiles)"로 설정되어 있다. 이와 같이, 대화 상자는 모든 프로파일에 대한 모든 관심 영역에 대한 카테고리 폴더를 디스플레이 한다. 그렇지만, "관심 영역(Area of Interest)" 콤보 박스를 사용함으로써, 사용자는 그의 프로파일(들) 내의 관심 영역에 상관없이 카테고리 폴더를 필터링하는 데 사용되는 관심 영역을 직접 지정할 수 있다.

3. 게시자 도메인 존/이름 - 이것은 사용자가 분류 게시자의 도메인 존(domain zone) 및 이름을 선택할 수 있게 해준다. 이것은 이름 충돌을 가질 수 있는 게시자들을 구별하는 데 유익하다. 바람직한 실시예에서, 게시자 도메인 이름은 DNS 명명(naming) 방식을 사용한다(예를 들어, IEEE.org, Reuters.com). 도메인 존은 사용자가 도메인 이름의 범위를 선택할 수 있게 해준다. 바람직한 실시예에서, 옵션은 인터넷, 인트라넷 및 엑스트라넷이다. 존 선택은 또한 게시된 카테고리 폴더(또는 분류)를 구별한다. 꽤 통상적인 경우는 대기업 내의 부서가 그 자신의 내부 분류를 갖는 경우이다. 이 경우에, 그 부서는 인트라넷 도메인 존을 할당받으며 그 자신의 도메인 이름, 예를 들어 인트라넷＼마케팅(Intranet＼Marketing) 또는 인트라넷＼판매(Intranet＼Sales)를 갖는다.

4. 카테고리 폴더 - 이것은 사용자가 카테고리 폴더 또는 분류를 선택할 수 있게 해준다. 이 선택이 행해지면, 선택된 카테고리 폴더에 대한 카테고리들이 카테고리 트리 뷰에 디스플레이 된다.

5. 검색 카테고리 - 이것은 사용자가 현재 디스플레이 된 카테고리를 필터링하는 데 사용되는 하나 이상의 키워드를 입력할 수 있게 해준다. 예를 들어, 의약 연구자는 의약 분류를 선택하지만 이어서 키워드 "해부학"을 포함하는 분류 내의 엔트리만을 디스플레이하기 위해 키워드 "해부학"을 입력할 수 있다.

6. "기억" 체크 박스 - 이것은 대화 상자가 지난번 검색이 있는 경우 사용자가 이를 "기억"해야만 하는지를 지정할 수 있게 해준다. 이것은 사용자가 많은 동일한 카테고리 폴더로부터 동일한 키워드 필터(들)를 사용하여 유사한 카테고리 기반 검색/요청을 수행하기를 원할 수 있는 경우에 아주 도움이 된다.

7. 검색 옵션들 - 이들 콘트롤은 사용자가 대화 상자가 키워드를 어떻게 해석해야하는지를 지정할 수 있게 해준다. 이 옵션들은 사용자가 키워드가 분류 트리 내의 각 엔트리의 전체 계층 구조에 적용되어야 하는지 또는 키워드가 엔트리들의 [끝부분] 이름들에만 적용되어야 하는지를 선택할 수 있게 해준다. 예를 들어, 분류 엔트리 "해부학＼세포＼크롬친화 세포(Anatomy＼Cells＼Chromaffin Cells)"는 계층 구조 필터에 포함되는데 그 이유는 계층 구조가 단어 "해부학(Anatomy)"을 포함하기 때문이다. 그렇지만, 이는 이름 필터로부터 배제되는데 그 이유는 끝부분 이름("크롬친화 세포(Chromaffin Cells)")이 단어 "해부학(Anatomy)"을 포함하지 않기 때문이다.

또한, 검색 옵션들은 사용자가 대화 상자가 모든 키워드, 임의의 키워드 또는 정확한 어구를 검사해야만 하는지를 선택할 수 있게 해준다.

8. 카테고리 트리 뷰 - 트리 뷰는 분류 계층 구조를 디스플레이하고, 사용자가 요청 생성 마법사에 부가하거나 새로운 일건서류(Dossier)(가이드) 요청/에이전트로서 열어야 할 하나 이상의 아이템을 선택할 수 있게 해준다. 사용자 인터페이스는 성능 이유로 카테고리 계층 구조를 "카테고리 페이지들"로 분해한다. UI는 사용자가 버튼 및 슬라이드 콘트롤을 통해 페이지들을 네비게이션할 수 있게 해준다. 또한 현재 선택된 분류 아이템 모두를 선택 해제하는 "모두 선택 해제(Deselect All)"도 있다.

9. 탐색 버튼 - 이것은 대화 상자의 메인 호출 버튼이다. 대화 상자가 요청 생성 마법사로부터 기동될 때, 이 버튼은 이름이 "부가(Add)"로 바뀌고 선택된 아이템들을 마법사 "필터(filters)" 프로퍼티 페이지에 부가한다. 대화 상자가 애플리케이션으로부터 직접 기동될 때, 이 버튼의 타이틀은 "탐색(Explore)"이고, 클릭될 때 선택된 카테고리에 대해 일건서류(Dossier) 요청을 기동한다. 사용자가 다수의 프로파일을 갖는 경우 또는 다수의 분류 카테고리가 선택된 경우, 대화 상자는 또 하나의 대화 상자, 즉 사용자에게 일건서류(Dossier)를 기동시키는 데 사용하는 프로파일 및/또는 카테고리를 필터로서 일건서류(Dossier)에 적용하는 데 사용할 연산자(AND 또는 OR)를 선택하도록 요청하는"카테고리 탐색 옵션들(Expolre Categories Options)" 대화 상자를 기동시킨다.

상기한 특징들은 도 9 내지 도 11에 예시되어 있으며, 이는 카테고리 탐색 (Explore Categories) 대화 상자의 3가지 서로 다른 뷰를 보여준다.

24. 클라이언트 지원 서버 데이터 일관성 검사

서버(KIS)가 지식 소스를 크롤링할 때, 서버의 메타데이터 캐시가 소스 자체와 동기를 벗어날 때가 있다. 예를 들어, 웹을 주기적으로 크롤링하는 KIS 상의 웹 크롤러는 시맨틱 메타데이터 스토어(SMS)에 유효 기간이 지난 엔트리를 부가할 수 있다. 이 경우, 클라이언트는 소스 URI를 호출하려고 시도할 때 404 에러를 가져온다. (예를 들어, 변경이 있는지 모니터링될 수 있는 파일-공유에 대해) 모니터링 기능을 갖는 데이터 소스 어댑터(DSA)의 경우, 이것은 그다지 문제가 되지 않는데 그 이유는 KIS가 지식 소스(들)와 동기하고 있을 수 있기 때문이다. 그렇지만, 모니터링/변경 통지 서비스를 갖지 않는 웹 사이트 등의 소스에 있어서, 이것은 걱정할 만한 문제를 제공할 수 있다.

모출원(제10/179,651호)은 KIS가 쓸모없는 엔트리를 SMS로부터 주기적으로 제거하기 위해 일관성 검사기(consistency checker, CC)를 어떻게 사용할 수 있는지에 대해 기술하고 있다. 그렇지만, 어떤 상황에서, 이 방법은 성능을 손상시킬 수 있는데, 그 이유는 CC가 전체 SMS를 주기적으로 스캔하고 인덱싱된 객체가 여전히 존재하는지 여부를 확인해야한 하기 때문이다. 본 발명의 이 특징의 대체 실시예는 클라이언트(시맨틱 브라우저)가 404 에러를 가져오는 경우 서버에 통지를 하도록 하는 것이다. 이를 하기 위해, 시맨틱 브라우저는 사용자가 "열기"를 한 각 결과에 대해 404 에러를 가져오는 때를 추적해야만 한다. 웹 문서의 경우, 사용자가 결과를 열기 이전에도 클라이언트는 결과를 디스플레이할 때 HTTP 헤더를 위해 폴링을 할 수 있다. 이 경우, 소스 웹 서버가 404 에러(객체가 발견되지 않음, object not found)를 보고하는 경우, 클라이언트는 이를 KIS에 보고해야만 한다.

KIS가 클라이언트로부터 "404 보고"를 가져오는 경우, KIS는 지능적으로 이것이 객체가 더 이상 이용가능하지 않은지를 의미하는지 여부를 결정한다. KIS는 임의적으로 객체를 삭제할 수 없는데 그 이유는 404 에러가 간헐적인 웹 서버 고장으로 인한 것일 수 있기 때문이다(예를 들어, 웹 서버 상의 디렉토리가 일시적으로 디스에이블 될 수 있다). KIS 자체는 이어서 객체(또는 웹 객체의 경우에, 최소한 HTTP 헤더)를 몇 번(예를 들어, 5번) 비동기적으로 다운로드하려고 시도해야만 한다. 각 시도가 실패하는 경우, KIS는 객체가 더 이상 이용가능하지 않은 것으로 결론짓고 이를 SMS로부터 제거할 수 있다. KIS가 다운로드를 처리하고 있는 동안 다른 클라이언트가 동일한 객체에 대해 404 에러를 보고하는 경우, KIS는 그 보고를 무시해야만 한다(왜냐하면 이는 중복되는 것이기 때문이다).

이 대안적인 기술은 대략적으로 게으른 일관성 검사를 그 특징으로 할 수 있다. 어떤 상황에서, 이는 유익하고 선호될 수 있다.

25. 클라이언트측 중복물 검출

서버(KIS)는 새로운 객체를 시맨틱 메타데이터 스토어(SMS)에 부가하기 전에 소스 URI를 검사함으로써 중복물 검출을 수행한다. 그렇지만, 성능 이유로, 때로는 서버가 엄격한 중복물 검출을 수행하지 않는 경우가 유익하다. 이러한 경우, 중복물 검출은 클라이언트측에서 수행되는 것이 최선이다. 게다가, 클라이언트가 몇 개의 KIS로부터의 결과를 연합시키기 때문에, 클라이언트가 서로 다른 KIS로부 터 중복물을 가져올 수가 있다. 그 자체로서, 클라이언트도 역시 중복물 검출을 수행하는 경우가 유익하다.

바람직한 실시예에서, 클라이언트는 명확히 중복물인 객체를 제거하고 그럴법한 중복물인 객체에 플래그를 붙인다. 명확한 중복물은 동일한 URI, 최근 수정된 타임 스탬프, 요약/개념 및 크기를 갖는 객체이다. 그럴법한 중복물은 동일한 요약/개념을 갖지만 서로 다른 URI, 최근 수정된 시각 또는 크기를 갖는 객체이다. 요약 추출이 어려운 객체의 경우, 그럴법한 중복물인지를 검사하는 데 타이틀도 사용되는 것이 추천된다(즉, 동일한 요약을 가지지만 서로 다른 타이틀을 갖는 객체는 그럴법한 중복물로 간주되는데 그 이유는 요약이 객체의 콘텐츠의 신뢰성있는 표시자일 수 없기 때문이다). 또한, (시맨틱 중첩/중복을 검출하기 위해) 요약/개념 추출이 어려운 경우, 시맨틱 브라우저는 파일 크기 검사를 ±N%(예를 들어, 5%)로 제한할 수 있다 - 예를 들어, 동일한 요약/개념 및 서로 다른 URI, 최근 수정된 시간, 및 크기를 갖는 객체는 파일 크기가 중복성 검사를 위해 그와 비교되고 있는 객체의 파일 크기의 5% 이내에 있는 경우 그럴법한 중복물로서 자격이 없을 수 있다.

26. 클라이언트측 가상 결과 커서

클라이언트(시맨틱 브라우저)도 역시 사용자 프로파일에 가입된 다수의 지식 커뮤니티(에이전시)가 존재할 때 사용자에게 매끄러운 사용자 경험을 제공한다. 시맨틱 브라우저는 양호하게는 결과가 하나의 소스로부터 온 것처럼 결과를 제공한다. 이와 유사하게, 브라우저는 양호하게는 사용자에게 하나의 네비게이션 커서를 제공한다 - 사용자가 스크롤할 때, 시맨틱 브라우저는 더 많은 결과를 가져오기 위해 KIS에 재쿼리를 한다. 바람직한 실시예에서, 시맨틱 브라우저는 빈번한 재쿼리를 방지하기에 충분히 큰 결과 캐쉬를 유지한다 - 예를 들어, 캐쉬는 5 내지 10 스크롤(페이지)에 대한 충분한 결과를 처리하도록 초기화될 수 있다. 캐쉬 크기는 양호하게는 메모리 고려 사항에 기초하여 상한이 정해진다. 커서가 전진(또는 후퇴)될 때, 브라우저는 현재 페이지가 캐시 히트 또는 미스를 발생하는지를 검사한다. 현재 페이지가 캐시 히트를 발생하는 경우, 브라우저는 캐시로부터의 결과를 제공하고, 그렇지 않은 경우 브라우저가 캐시에 부가하는 부가적인 결과를 얻기 위해 KIS에 재쿼리를 행한다.

캐쉬는 무한정으로 늘어나도록 또는 슬라이딩 윈도우가 되도록 구현될 수 있다. 전자의 옵션은 구현의 간편성의 이점 및 높은 메모리 소모 가능성의 단점을 갖는다. 바람직한 실시예인 후자의 옵션은 낮은 메모리 소모 및 높은 캐쉬 일관성의 이점을 갖지만 보다 복잡한 구현의 비용이 들어간다. 슬라이딩 윈도우의 경우, 시맨틱 브라우저는 윈도우 내에 들어있지 않는 페이지(다른 실시예에서와 같이 모든 페이지와는 달리 예를 들어, 마지막 N개 - 예를 들어 5 내지 10개 - 페이지)로부터 결과를 제거하게 된다.

27. 가상 싱글 사인온(Virtual Single Sign-On)

클라이언트(시맨틱 브라우저)는 또한 사용자를 그가 가입한 지식 커뮤니티(에이전시)에 대해 인증할 때 사용자에게 매끄러운 사용자 경험을 제공한다. 클라이언트는 본 발명자가 "가상 싱글 사인온"이라고 부르는 것을 통해 이것을 행한다. 이 모델은 사용자가 지식 커뮤니티마다 그의 사용자 이름 및 패스워드를 입력할 필요없이 시맨틱 브라우저가 지식 커뮤니티에 대해 사용자를 인증하는 것을 포함한다. 일반적으로, 사용자는 몇 개의 사용자 이름 및 패스워드를 가지지만, (특히 부서 또는 그룹 액세스 및 인터넷 기반 지식 커뮤니티에 기초하여 회사 내에서) 그가 멤버로 있는 많은 지식 커뮤니티를 가질 수 있다. 그 자체로서, 인증 보증서의 수에 대한 지식 커뮤니티의 수의 비(사용자마다)는 아주 높을 수 있다.

가상 싱글 사인온에 있어서, 사용자는 시맨틱 브라우저에 대한 그의 로그온 보증서를 서버(지식 커뮤니티) 독립적인 방식으로 지정한다. 시맨틱 브라우저는 보증서를 보증서 캐쉬 테이블(Credential Cache Table, CCT)에 저장한다. CCT는 이하에 예시한 컬럼들을 갖는다.

계정 이름 사용자 이름 패스워드 지식 커뮤니티 엔트리 리스트

● 계정 이름 - 이것은 계정에 대한 친숙한 이름이다

● 사용자 이름 - 이것은 로그온 사용자 이름이다(예를 들어, 이메일 주소)

● 패스워드 - 이것은 보안 비밀키로 암호화되어 저장된 패스워드이다

● 지식 커뮤니티 엔트리 리스트(KCEL) - 이것은 이 계정에 대한 보증서를 사용하여 사용자를 인증하는 지식 커뮤니티의 리스트이다.

사용자가 처음으로 지식 커뮤니티에 가입(또는 예를 들어 커뮤니티의 프로퍼티를 가져오기 위해 어떤 다른 방식으로 지식 커뮤니티에 액세스)하려고 시도할 때, 시맨틱 브라우저는 사용자에게 그의 패스워드를 요청하고 이어서 공급된 보증서를 사용하여 서버에 로그온하려고 시도한다. 로그온이 성공적이면, 시맨틱 브라우 저는 공급된 보증서로 새로운 CCT 엔트리(CCTE)를 생성하고 KC를 새로운 CCT 엔트리에 대한 지식 커뮤니티 엔트리 리스트(KCEL)에 부가한다.

각각의 차후의 가입 시도에 대해, 시맨틱 브라우저는 사용자가 가입하게 될 KC가 임의의 CCTE에 대한 KCEL 내에 있는지 알아보기 위해 CCT를 검사한다. 있는 경우, 시맨틱 브라우저는 CCTE에 대한 보증서를 검색하고 그 보증서를 사용하여 사용자를 로그온시킨다. 이와 같이, 사용자는 중복하여 그의 로그온 보증서를 입력할 필요가 없다.

유의할 점은 시맨틱 브라우저도 역시 오퍼레이팅 시스템이 이미 도메인에 로그온되어 있을 때 패스-쓰루 인증(pass-through authentication)을 지원한다는 것이다. 예를 들어, Windows 머신이 이미 NT(또는 액티브 디렉토리) 도메인에 로그온 되어 있는 경우, 클라이언트측 웹 서비스 프록시도 역시 KC에 로그온하려고 시도하기 위한 기본 보증서를 포함하고 있다. 바람직한 실시예에서, 사용자에 의해 공급된 부가적인 보증서는 양호하게는 SOAP 보안 헤더를 통해(웹 서비스 보안(WS-보안) 또는 유사한 방식을 통해) 전달된다. WS-보안 및 SOAP 헤더로 인증 정보를 전달하는 것에 대한 상세에 대해서는,

http://oasis-open.org/committees/download.php/3281/WSS-SOAPMessageSecurity-17-082703-merged.pdf를 참조하기 바란다.

시맨틱 브라우저는 사용자가 CCTE에 대한 보증서가 양호하게는 CCTE에 대한 KCEL이 비어있을 때 제거되는지 또는 보증서가 저장되어야만 하는지를 표시할 수 있도록 프로퍼티를 노출시킨다. 바람직한 실시예에서, 보증서는 양호하게는 사용 자가 달리 표시하지 않는 한 기본적으로 저장된다. 사용자가 보증서가 제거되는 것을 원하는 경우, 시맨틱 브라우저는 KC가 더 이상 브라우저 내의 임의의 프로파일에 가입되어 있지 않을 때 KC가 존재하는 CCTE로부터 그 KC를 제거해야만 한다. KC를 CCTE의 KCEL로부터 제거한 후에 CCTE가 비게 되는 경우, CCTE는 양호하게는 CCT로부터 삭제된다.

가상 싱글 사인온 특징은 본 출원에서의 많은 특징들과 같이 본 발명의 정보 신경 시스템 또는 가상 라이브레리언에서와 다른 애플리케이션들에서 사용될 수 있다. 예를 들어, 이는 둘 이상의 도메인에 로그인해야만 하는 임의의 컴퓨터 사용자가 사용하도록 구성될 수 있다.

28. 네임스페이스 객체 동작 매트릭스

이하의 테이블은 네임스페이스 객체가 복사되고 다른 네임스페이스 객체에 붙여넣기 될 때 시맨틱 브라우저가 호출하는 동작들을 나타낸 것이다.

29. 동적 엔드-투-엔드 온톨로지/분류 업데이트 및 동기화

정보 신경 시스템™은 온톨로지 및 분류의 동적 업데이트를 지원한다. Nervana에 의해 게시된(또는 써드파티 온톨로지 게시자에 의해 Nervana에 제공되는) 지식 도메인 플러그-인은 Nervana 웹 도메인(Nervana.com) 상의 중앙 웹 서비스(온톨로지 저장소) 상에서 호스팅된다. 각각의 KDS는 이어서 (URI에 의해 참조되는 그의 지식 도메인 플러그-인 각각 또는 플러그-인의 글로벌 고유 식별자에 대해) 주기적으로 웹 서비스 호출을 통해 중앙 웹 서비스에 폴링을 하고 플러그-인이 업데이트되었는지를 웹 서비스에 "질문"한다. 웹 서비스는 플러그-인이 업데이트되었는지를 판정하기 위해 온톨로지 파일의 최근 수정된 타임스탬프를 사용한다. 플러그-인이 업데이트된 경우, 웹 서비스는 호출측 KDS에 새로운 온톨로지 파일을 반환한다. KDS는 이어서 그의 온톨로지 파일을 교체한다.

업데이트 동안 KDS가 실행되고 있는 경우, KDS가 파일 변경 통지를 지원하지 않고 온톨로지를 재로드 하지 않는 한, KDS는 통상은 파일을 교체하기 전에 일시적으로 서비스를 중단한다(이는 추천되는 구현이다).

각각의 KIS도 역시 그의 온톨로지가 변경되었는지를 KDS에 "질문"하기 위해 그와 연결되어 있는 각각의 KDS에 폴링을 해야만 한다. 바람직한 실시예에서, KDS가 서로 다른 버전의 온톨로지를 가지고 있는 경우, KIS는 KDS에 폴링을 하고 중앙 웹 서비스에는 폴링을 하지 않는다. KDS는 또한 온톨로지가 변경되었는지를 판정하기 위해 지식 도메인 플러그-인(온톨로지)의 최근 수정된 타임스탬프를 사용한다. KDS는 이어서 이것을 KIS에 알려준다. 온톨로지가 변경된 경우, KIS는 그에 따라 시맨틱 네트워크를 업데이트해야 한다. 바람직한 실시예에서, KIS는 새로운 버전의 온톨로지에 없는 카테고리를 참조하는 시맨틱 링크를 제거하고 새로운 버전의 온톨로지에 기초하여 시맨틱 링크를 부가/수정함으로써 이것을 행한다. 대체 실시예에서, KIS는 시맨틱 네트워크를 제거하고 그를 재인덱싱 한다.

이어서, 클라이언트는 그가 가입되어 있는 분류가 변경되었는지를 (중앙 웹 서비스를 통해 직접 또는 KIS를 통해) 판정하기 위해 그가 가입되어 있는 각 KIS에 폴링을 행한다. KIS는 XML 웹 서비스를 통해 메소드를 노출시키며, 그 서비스를 통해 클라이언트는 분류가 변경되었는지를 (분류/온톨로지 플러그-인 파일의 최근 수정된 타임스탬프를 통해) 판정한다. 분류가 변경된 경우, 클라이언트는 새로운 분류를 보여주기 위해 카테고리 대화상자 사용자 인터페이스(및 다른 UI 기반 분류 디펜던트(taxonomy dependent))를 업데이트해야 한다.

(예를 들어, Nervana를 통해) 중앙 집중적으로 게시된 분류의 경우, 클라이언트는 분류를 업데이트하기 위해 중앙 웹 서비스에 폴링을 해야 한다.

이 모델에서, 클라이언트, KIS, KID 및 중앙 분류/온톨로지 저장소는 동기된 상태로 유지된다.

30. 일건서류(Dossier)(가이드) 쿼리의 호출

일건서류(Dossier) 시맨틱 쿼리 프로세싱

일건서류(Dossier)(가이드) 쿼리는 양호하게는 요청/에이전트의 SQML을 파싱하고 일건서류(Dossier) 컨텍스트 서술어를 각각의 특별 에이전트(컨텍스트 템플릿) 컨텍스트 서술어 - 예를 들어, 모든 배팅, 최상의 배팅, 속보, 헤드라인, 임의 적인 배팅, 뉴스 메이커 등으로 대체함으로써 클라이언트측 시맨틱 쿼리 프로세서에 의해 호출된다. 각 쿼리(컨텍스트 템플릿마다)는 이어서 쿼리 프로세서를 통해 개별적인 쿼리처럼 호출된다. 이와 같이, 사용자는 일건서류(Dossier)의 레벨에서 동작하지만 시맨틱 브라우저는 막후에서 일건서류(Dossier)를 개별적인 쿼리로 매핑한다.

예를 들어, "일건서류(Dossier) on Category C"에 대한 SQML이 파싱되고 새로운 SQML 쿼리가 다음과 같이 발생된다.

● 카테고리 C에 관한 모든 배팅

● 카테고리 C에 관한 최상의 배팅

● 카테고리 C에 관한 속보

● 카테고리 C에 관한 헤드라인

● 카테고리 C에 관한 임의적인 배팅

● 카테고리 C에 관한 뉴스 메이커

● 기타

클라이언트측 시맨틱 쿼리 프로세서는 컨텍스트 서술어를 제외한 모든 다른 서술어를 보유한다. 이와 같이, 필터는 상기 예로 나타낸 바와 같이 일관성을 유지한다.

일건서류(Dossier) 스마트 렌즈

정보 신경 시스템™에서의 다른 요청/에이전트와 같이, 일건서류(Dossier)(가이드)는 (그것이 어떻게 드래그/드롭, 스마트 복사 및 붙여넣기, 기타를 위한 타 겟이 될 수 있는지와 같이) 스마트 렌즈로서 사용될 수 있다. 이 경우, 스마트 렌즈는 각 컨텍스트 템플릿(특별 에이전트)에 대한 섹션/탭/프레임을 갖는 "일건서류(Dossier) 미리보기 윈도우"를 디스플레이한다. 일건서류(Dossier) 스마트 렌즈의 UI를 보여주는 일건서류(Dossier)의 샘플 스크린 사진이 도 12 및 도 13에 포함되어 있다.

일건서류(Dossier) 스크린 사진

31. 지식 커뮤니티(에이전시) 시맨틱스

이하는 시맨틱 브라우저 내의 시맨틱 네임스페이스/환경의 컨텍스트 내에서 지식 커뮤니티(에이전시)의 시맨틱스에 대해 기술한 것이다.

1. 지식 커뮤니티를 선택 - 이것은 그 KC로부터의 일건서류(Dossier) 요청을 연다. 본질적으로, 일건서류(Dossier)는 KC의 "홈 페이지"의 등가물이 된다.

2. KC로 드래그 및 드롭(문서, 텍스트, 엔티티, 키워드 등) - 이것은 KC로부터 (디폴트 서술어를 사용하여) 객체 상에 일건서류(Dossier) 요청/에이전트를 연다.

3. KC를 클립보드로 복사 - 이것은 KC를 스마트 렌즈로서 선택한다. 사용자가 결과 또는 엔티티 상에서 허버링할 때, 시맨틱 브라우저는 KC 이름 및 KC의 프로파일 이름을 커서 아래에 보여줌으로써 스마트 렌즈를 디스플레이한 다음에 KC로부터의 일건서류(Dossier)를 렌즈 미리보기 창에서 렌즈 아래의 객체 상에 연다.

4. KC에 가입 - KC가 처음으로 가입될 때, 시맨틱 브라우저는 (예를 들어, 마이크로소프트 아웃룩 또는 아웃룩 익스프레스에서) KC의 이메일 주소를 로컬 이 메일 콘택트(local email contact)에 부가한다. 이것은 (통합된 콘텍트 리스트를 통해) 지식을 이메일로 전송함으로써 사용자가 지식을 KC로 게시하는 것을 용이하게 만들어준다. 이와 유사하게, KC가 모든 프로파일로부터 가입 취소될 때, 시맨틱 브라우저는 로컬 이메일 콘텍트 리스트로부터 KC를 제거해야만 하는지를 사용자에게 물어본다.

32. 동적 온톨로지 및 분류 매핑

분류 및 온톨로지를 사용하는 것의 과제들 중 하나는 하나의 분류/온톨로지의 시맨틱스를 다른 것으로 어떻게 매핑하느냐이다. 정보 신경 시스템™은 이하의 알고리즘에 의해 이것을 달성한다.

각각의 KDS는 (온톨로지 매퍼(OM)를 통해) 온톨로지 매핑하는 일을 하며 온톨로지 매핑 테이블(OMT)을 사용하여 중앙 웹 서비스(온톨로지 저장소)를 주기적으로 업데이트한다. 업데이트는 양방향성이다. 즉, KDS는 주기적으로 중앙 웹 서비스로부터의 그의 온톨로지 및 분류를 업데이트하고 OMT의 업데이트를 중앙 웹 서비스로 전송한다. 각 OMT는 서로 다르지만 중앙 온톨로지 저장소는 모든 OMT를 마스터 OMT로 통합한다. 온톨로지 매퍼는 일관된 사용자 경험을 생성하는데 그 이유는 사용자가 관련성이 있지만 중첩하는 우산형 분류(umbrella taxonomy) 내의 모든 아이템을 선택할 필요가 없기 때문이다. 시맨틱 브라우저는 자동적으로 이것을 처리하게 된다. KIS는 매퍼에 대한 어떤 개념도 갖고 있지 않지만 시맨틱 네트워크를 업데이트하기 위해 사용하게 될 KDS로부터 매핑된 결과를 가져온다.

그렇지만, KDS 및 KIS 운영자는 여전히 올바른 KDS 온톨로지 플러그-인을 선 택하는 일을 한다, 그렇지만 각각의 온톨로지/분류에 기초하여 선택한다(온톨로지 매핑은 온톨로지를 향상시키지 않으며 단지 그를 매핑할 뿐이다).

33. 시맨틱 경고 최적화

시맨틱 브라우저에서의 시맨틱 경고는 이하의 규칙을 (순서대로) 사용하여 최적화될 수 있다.

주어진 필터(예를 들어, 결과, 문서, 텍스트, 키워드, 엔티티)에 대해,

1. 먼저 헤드라인이 있는지 검사한다.

2. 헤드라인이 있는 경우, 속보 및 뉴스 메이커가 있는지 검사한다.

이렇게 하는 이유는 바람직한 실시예에서 헤드라인은 더 큰 시간 윈도우에서의 경우를 제외하고는 속보와 유사하게 구현되기 때문이다. 그 결과, 헤드라인이 없는 경우(바람직한 실시예에서), 속보가 없다. 또한, 바람직한 실시예에서, 뉴스 메이커는 헤드라인의 저작자를 반환함으로써 구현된다. 그 자체로서, 헤드라인이 없는 경우, 뉴스 메이커가 없다.

34. 시맨틱 "뉴스" 이미지

코비스(http://www.corbis.com) 및 게티 이미지(http://www.gettyimages.com) 둘다는 항상 최신의 것으로 유지되는 "뉴스" 이미지를 가지고 있다. 정보 신경 시스템™은 컨텍스트 의존적일 뿐만 아니라 "최신의 것"인 시맨틱 이미지를 위해 이러한 종류의 이미지를 사용할 수 있다. 이것은 사용자 인터페이스를 흥미롭고 "새롭게"유지한다는 관점에서 유리할 수 있다. 예를 들어, "사스에 관한 속보(Breaking News on SARS)"는 의약 이미지 뿐만 아니라 최 근의 사스 발발 등에 대처하는 의사들을 나타내는 이미지도 보여줄 수 있다.

35. 시맨틱 이미지를 동적으로 선택

시맨틱 이미지는 이하의 규칙들을 사용하여 동적이고 지능적으로 선택될 수 있다.

1. 현재 디스플레이된 네임스페이스 객체가 요청인 경우, 카테고리를 위해 객체의 SQML을 파싱한다. 카테고리가 있는 경우, 카테고리와 관련성있는 이미지를 얻기 위해 카테고리를 (시맨틱 이미지 캐쉬를 호스팅하는) 중앙 웹 서비스로 전송한다. 또한, 요청 타입(예를 들어, 모든 배팅 및 헤드라인과 같은 지식 타입 또는 프리젠테이션과 같은 정보 타입)과 부합하는 이미지를 반환하기 위해 요청 타입을 중앙 웹 서비스로 전송한다.

2. 네임스페이스 객체가 요청이 아닌 경우, 현재 프로파일(이용가능한 경우)에 대한 관심 영역을 중앙 웹 서비스로 전송한다. 웹 서비스는 이어서 프로파일의 관심 영역과 부합하는 시맨틱 이미지를 반환한다. 프로파일이 관심 영역을 구성하지 않은 경우, 애플리케이션(시맨틱 브라우저)를 위해 관심 영역을 전송한다. 애플리케이션이 관심 영역을 구성하지 않은 경우, 빈 문자열을 중앙 웹 서비스로 전송한다 - 이 경우에, 중앙 웹 서비스는 일반 이미지(예를 들어, 브랜드 상품 이미지)를 반환한다.

36. 동적 지식 커뮤니티(에이전시) 콘택트 멤버쉽

지식 커뮤니티(에이전시)는 멤버(커뮤니티에 대한 읽기, 쓰기 또는 읽기-쓰기 접근 권한을 갖는 사용자) 및 콘택트를 갖는다. 콘택트는 커뮤니티에 관련성이 있지만 반드시 멤버인 것은 아닌 사용자이다. 예를 들어, 대기업에서의 부서 지식 커뮤니티(KC)는 부서의 멤버들을 KC의 멤버로서 가질 수 있지만 기업의 모든 직원을 콘택트로서 가질 수 있다. 콘택트가 유리한 이유는 콘택트가 KC의 멤버들이 시맨틱적으로 KC와 관련성 있지만 멤버가 아닐 수 있는 사용자들을 네비게이션 할 수 있게 해주기 때문이다. KC는 시맨틱적으로 콘택트에 의해 전송된 인덱스일 수 있다. - 인덱스는 이 경우에 콘택트가 KC의 멤버가 아닐지라도 콘택트를 포함하게 된다.

이것을 보는 다른 방식은 실제 세계에서의 지식 커뮤니티는 핵심 멤버 및 주변 멤버를 갖는 경향이 있다. 핵심 멤버는 커뮤니티에서 아주 활동적인 사용자인 반면, 주변 멤버는 지식 취미 리스트, 특별 기고자, 잠재적인 신입 사원 및 다른 관련 커뮤니티의 멤버까지 등과 같은 "다른" 사용자를 포함한다.

정보 신경 시스템™에서의 동적 KC 콘택트 멤버쉽의 경우, KIS는 "사용자를 보게 될 때"(환언하면 멤버가 아닌 새로운 사용자를 갖는 이메일 메시지를 인덱싱할 때) 시맨틱 메타데이터 스토어(SMS) 내의 그의 콘택트 테이블 및 시맨틱 네트워크에 사용자를 부가한다. 이것은 커뮤니티가 동적으로 그렇지만 멤버와 단순 콘택트를 구별하는 방식으로 그의 콘택트를 확장할 수 있게 해주며, 시스템을 동작시킬 때(예를 들어, 검색 등을 실행할 때) 구별의 중요성을 시맨틱적으로 "이해"한다.

37. 통합된 완전-텍스트 키워드 및 어구 인덱싱

KIS는 또한 개념(키 어구) 및 키워드를 시맨틱 네트워크의 제1 클래스 멤버로서 인덱싱한다. 이것은 다음과 같이 도메인 독립적인 방식으로 행해질 수 있다.

시맨틱 네트워크에 부가될 각각의 새로운 객체(예를 들어, 문서)에 대해,

1. 객체의 보디로부터 개념(키 어구)을 추출한다.

2. 각 개념에 대해, 그 개념을 객체 타입 id OBJECTTYPEID_CONCEPT를 갖는 시맨틱 네트워크에 부가한다. 서술어 PREDICATETYPEID_CONTAINSCONCEPT를 갖는 시맨틱 링크를, 주제로서 새로운 객체를 가지고 그 주제로서 새로운 개념 객체를 갖는 "시맨틱 링크(Simantic Links)" 테이블에 부가한다.

3. 현재 개념에 대해, 개념 키 어구로부터 키워드를 추출하고 각각의 키워드를 객체 타입 id OBJECTTYPEID_KEYWORD를 갖는 시맨틱 네트워크에 부가한다. 또한, 서술어 PREDICATETYPEID_CONTAINSKEYWORD를 갖는 시맨틱 링크를, 주제로서 새로운 객체를 가지고 그 주제로서 새로운 키워드 객체를 갖는 "시맨틱 링크" 테이블에 부가한다.

객체의 타이틀에 대해 또한 적절한 경우 객체의 스키마에 대한 다른 메타-태그에 대해 상기 단계들을 반복한다.

어떤 실시예들은 통합된 완전-텍스트 인덱싱을 필요로 하지 않지만, 현재 바람직한 실시예에 포함되어 있는 이유는 그것이 몇가지 유용한 이점을 제공하기 때문이다.

1. 이는 시맨틱 필터를 (SQML로) 구현하는 일관된 모델을 가능하게 해준다. 사용자는 카테고리, 문서, 엔티티 및 키워드를 필터로서 부가할 수 있고, 필터는 일관성있게 시맨틱 네트워크에 (서브쿼리로서) 적용된다.

2. 특히, 이는 엔티티의 시맨틱 쿼리 프로세싱을 지원한다. 엔티티는 카테 고리로 정의될 수 있으며 (키워드가 서로 다른 컨텍스트에서 서로 다른 것을 의미하는 경우에 키워드를 명확히 하기 위해) 키워드로 더욱 좁혀질 수 있다. 통합된 완전-텍스트 인덱싱은 카테고리 및 키워드/개념을 갖는 필요한 서브쿼리를 시맨틱 네트워크에 적용함으로써 KIS 시맨틱 쿼리 프로세서(SQP)가 엔티티를 매끄럽게 해석할 수 있게 해준다.

3. 일반적으로, 통합된 완전-텍스트 인덱싱은 매끄럽고 일관된 데이터 및 쿼리 모델이 얻어진다.

38. 시맨틱 "객체를 읽음으로 마크함"(Semantic "Mark Object as Read")

어떤 경우에, KIS는 객체별로 사람들과 객체들 간의 시맨틱 링크를 저장하는 리소스를 갖지 않을 수 있다. 게다가, 시맨틱 기반의 중복성은 이메일에서와 같이 객체별 중복성과 동일하지 않다. 예를 들면, 이메일 클라이언트는 사용자가 이메일 메시지를 읽음 또는 읽지 않음으로서 선택할 수 있게 해준다 - 이것은 일반적으로 이메일 메시지를 갖는 메일 서버 상에 저장된 플래그로서 구현된다. 그렇지만, 이메일이 시맨틱 시스템이 아니기 때문에, 서버 상의 시맨틱적으로 유사하거나 동일한 메시지는 그 자체로서 플래그가 붙어 있지 않다 - 사용자는 시맨틱 중복성에 상관없이 각 메시지에 개별적으로 플래그를 붙여야 한다.

정보 신경 시스템™에서, 사용자는 이메일에서와 다르지 않게 객체를 읽음으로서 플래그를 붙일 수 있다. 그렇지만, 이 경우, 시맨틱 브라우저는 객체로부터 개념을 추출하고 요청 프로파일 내의 모든 KIS에 "개념(concepts)"이 읽혀졌음을 알려준다. 이어서, KIS는 그를 구성하는 데 사용되는 KDS를 통해 개념을 카테고리 에 동적으로 매핑하고 그 카테고리에 속하는 객체들에 플래그를 부가 및/또는 개념에 대응하는 카테고리와 카테고리에 링크되어 있는 모든 객체들 간에 서술어 PREDICATETYPEID_VIEWEDCATEGORY를 갖는 시맨틱 링크를 갖는 시맨틱 네트워크에 플래그를 부가한다. 바람직한 실시예에서, KIS는 (소스 개념에 대한) 링크-세기 임계값(link-strength threshold)을 넘는 그 카테고리에만 플래그를 붙여야 한다. 이것은 그 객체(바람직한 실시예에서) 및/또는 원본 객체에 시맨틱적으로 가까운 카테고리에만 플래그가 붙여지도록 보장해준다.

시맨틱 브라우저가 KIS를 통해 객체에 플래그를 붙일 때, KIS는 네트워크가 업데이트되었는지를 나타내는 플래그를 반환한다(객체가 임의의 "강력한" 카테고리를 갖지 않는 경우 또는 동일한 "강력한" 카테고리를 공유하는 다른 객체가 없는 경우 아무런 변경이 행해지지 않을 수 있다). 요청 프로파일 내의 적어도 하나의 KIS가 네트워크가 업데이트되었음을 나타내는 경우, 시맨틱 브라우저는 요청/에이전트를 리프레쉬 해야 한다. 시맨틱 브라우저는 KIS가 읽지 않은 객체만 또는 (읽거나 읽지 않은) 모든 객체를 반환하기를 사용자가 원하는지를 나타낼 수 있도록 해주기 위해 프로퍼티를 노출시킬 수 있으며, 이 경우 브라우저는 읽지 않은 객체를 다르게 디스플레이해야 한다(이메일 클라이언트가 읽지 않은 메시지를 굵은체로 디스플레이하는 방법과 같음). 시맨틱 브라우저 내의 프리젠테이션 계층은 이어서 명백한 시각적 구분을 제공하기 위해 읽은 객체 및 읽지 않은 객체를 적절한 폰트 및/또는 색상으로 디스플레이해야만 한다.

39. 다중 선택 객체 렌즈

다중 선택 객체 렌즈는 모출원에 기술되어 있는 객체 렌즈의 대체 구현이다. 그 실시예에서, 객체 렌즈는 스마트 복사 및 붙여넣기를 통해 호출되었다 - 객체를 다른 객체 상에 붙여 넣기 하는 것은 적절한 디폴트 서술어로 객체 렌즈를 호출하게 된다. 이것은 사용자가 시맨틱 브라우저의 인스턴스들에 걸쳐, 프로파일들에 걸쳐, 및 다른 환경으로부터 객체를 복사할 수 있게 해준다는 이점을 갖는다(파일 시스템, 워드 프로세서, 이메일 클라이언트 등과 같음).

현재 바람직한 실시예에서, 객체 렌즈는 일건서류(Dossier) 렌즈이다(컨텍스트 서술어는 일건서류(Dossier)이고, 필터는 소스 및 타겟 객체이며, 프로파일은 소스 객체가 디스플레이되어 있는 프로파일이다).

다중 선택은 객체 렌즈를 호출하기 위해 복사 및 붙여넣기 대신에 사용될 수 있다. 시맨틱 브라우저는 사용자가 다수의 객체(결과)를 선택할 수 있게 해준다. 사용자는 이어서 선택된 객체에 대해 객체 렌즈를 호출하기 위해 버튼(또는 대안적인 사용자 인터페이스 객체)을 누를 수 있다. 이 경우, 일건서류(Dossier) 컨텍스트 서술어를 갖는, 선택된 객체로서 필터를 갖는 또한 요청 프로파일로서 현재 프로파일을 갖는 일건서류(Dossier) 렌즈가 (미리보기 창 내에) 디스플레이 된다.

40. 온톨로지 기반 필터링 및 스팸 관리

객체가 (하나 이상의 KDS를 통해) KIS가 구성되는 데 사용된 지식 도메인들 중 적어도 하나로부터 적어도 하나의 카테고리에 속하는 경우, KIS(바람직한 실시예에서)는 그 객체를 시맨틱 메타데이터 스토어(SMS)에 부가하기만 한다. 이것은 본질적으로 KIS가 자신이 "이해하지 못하는" 객체를 인덱싱하지 않는다는 것을 의 미한다. 이에 대한 예외는 KIS가 그의 시스템 인박스로부터의 모든 객체를 인덱싱 한다는 점이다 - 왜냐하면 이것이 관련성이 있지만 항상 시맨틱적으로 관련성있는 것은 아닐 수 있는 가끔씩있는 개인 커뮤니티 관련 게시 및 주석을 포함하기 때문이다.

이 온톨로지 기반 필터링 모델의 부작용은 스팸 관리이다 - 온톨로지 기반 인덱싱은 스팸이 인덱싱되어 저장되는 것을 방지하는 데 효과적이다. 사용자가 이메일에 액세스하기 위해 그의 받은 편지함과는 달리 시맨틱 브라우저를 사용하는 경우, 시맨틱적으로 필터링 된 이메일만 통과한다.

41. 결과 세분화

요청/에이전트의 결과는 부가적인 필터 및 서술어를 통해 추가로 정리될 수 있다. 예를 들어, 생물 정보학에 관한 요청/에이전트 헤드라인은 어떤 생물 정보학의 분야에 고유한 키워드로 추가로 정리될 수 있다. 이와 같이, 최종 사용자는 베이스(base)로서 요청/에이전트를 사용하여 결과 세트를 더욱 좁힐 수 있다. 게다가, 시간에 민감한 요청의 경우, 사용자는 디폴트 시간 윈도우를 오버라이드하도록 시간 윈도우를 지정할 수 있다. 예를 들어, 디폴트 속보 시간 요청은 3시간으로 설정될 수 있다. 사용자는 적절한 UI 메카니즘(예를 들어, 1 시간 내지 24 시간의 범위를 갖는 슬라이더 콘트롤)으로 (프로파일마다 또는 애플리케이션 전반에 걸쳐 디폴트를 변경하는 것 이외에) 특정 요청/에이전트에 대해 이것을 오버라이드할 수 있어야만 한다. 헤드라인 및 뉴스 메이커에 대해서도 마찬가지이다(예를 들어, 하루 내지 일주일의 범위를 갖는 슬라이더 콘트롤).

사용자가 필터-오버라이드를 지정할 때, 시맨틱 브라우저는 요청 프로파일 내의 KIS 각각에 대해 XML 웹 서비스 호출을 호출하고 호출의 일부로서 오버라이드 인수를 전달한다. 오버라이드 인수가 존재하는 경우, 웹 서비스는 디폴트 필터 값 대신에 그 값들을 사용한다. 부가적인 필터(예를 들어, 키워드)에 대해서도 마찬가지이다 - 이들은 부가적인 인수로서 웹 서비스로 전달되고, 웹 서비스는 에이전트/요청 SQML에 지정된 쿼리를 추가로 필터링하기 위해 부가적인 서브쿼리를 적절히 적용한다(환언하면, SQML은 언제나처럼 전달되지만, 그 밖에 필터 오버라이드 및 부가적인 필터도 역시 전달된다).

필터-오버라이드에 바람직한 경우는 최선의 배팅에 대한 것이다. 최선의 배팅에 대한 디폴트 시맨틱 관련성 세기는 90%로 설정될 수 있다(바람직한 실시예에서). 그렇지만, 주어진 요청/에이전트에 대해, 사용자는 시맨틱 관련성 범위에 걸쳐 "배팅"을 보고자 할 수 있다. 관련성 UI 콘트롤(예를 들어, 0% 내지 100% 범위를 갖는 슬라이더 콘트롤)을 노출시키는 것은 이것을 가능하게 해준다. 이것은 본질적으로 사용자가 동작 중인 최선의 배팅을 "모든 배팅"(0%)으로부터 "완벽한 배팅"(100%)으로 변경할 수 있게 해준다.

하이브리드 모델은 또한 다수의 필터링 축을 포함하는 컨텍스트 템플릿(특별 에이전트) 구현의 실시예를 위해 이용되어야만 한다. 예를 들어, 속보는 또한 25%의 관련성 필터를 부과하고 헤드라인 및 뉴스 메이커는 50%의 관련성 필터를 부과한다(속보는 더 낮은 관련성 임계값을 갖는데 그 이유는 속보가 더 높은 시간 민감성 임계값을 갖기 때문이며, 그 자체로서 관련성 임계값이 완화될 수 있다). 이 경우, 시맨틱 브라우저는 사용자가 양축(시간 민감성에 대한 슬라이더 콘트롤 및 관련성에 대한 또하나의 슬라이더 콘트롤)에 걸쳐 특별 에이전트를 정리할 수 있도록 하기 위해 UI 콘트롤을 노출시켜야만 한다.

일건서류(Dossier)에 있어서, 시맨틱 브라우저는 일건서류(Dossier)에 디스플레이된 각각의 특별 에이전트에 대한 UI 콘트롤을 디스플레이할 수 있다 - 메인 일건서류(Dossier) 창은 모든 UI 콘트롤을 보여줄 수 있다(어떤 UI 콘트롤이라도 변경하면 그 특별 에이전트에 대한 일건서류(Dossier) 서브요청을 리프레쉬 한다). 또한, 일건서류(Dossier)가 각 특별 에이전트에 대한 탭을 갖는 경우, 각 탭은 탭에 대한 특별 에이전트에 고유한 UI 콘트롤을 가질 수 있다.

42. 정보 스토어의 시맨틱 관리

정보 신경 시스템™은 또한 개인 이메일 인박스, 개인 콘택트 리스트, 개인 이벤트 캘린더, 데스크톱 파일 시스템(예를 들어, 로컬 및 네트워크 기반 파일에 대한 마이크로소프트 윈도즈 탐색기 파일 관리 시스템) 등의 정보 스토어 및 파일 공유, 콘텐츠 관리 시스템 및 웹 사이트와 같은 다른 스토어를 관리하는 데 사용될 수 있다.

클라이언트 기반 스토어(이메일 인박스 및 파일 시스템 등)에 있어서, 시맨틱 브라우저의 클라이언트 런타임은 중복적인, 쓸모없는 또는 의미없는 것으로 된 아이템들이 있는지 검사하기 위해 프로그램적 인터페이스를 통해 주기적으로 스토어에 폴링을 해야만 한다. 이것은 이메일 받은 편지함이 "그의 의미 및 관련성을 상실"할 수도 있는 쓸모없는 메시지들로 계속 증대되는 경우 현재 문제를 해소해준 다. 그렇지만, 사용자가 대처해야만 하는 절대적인 정보량으로 인해, 많은 컴퓨터 사용자들은 그의 이메일 받은편지함 자체를 관리할 수 있는 능력을 상실하고 있으며, 그 결과 저장 공간을 차지하는 오래된 또한 아마도 관련성없는 메시지의 정크 힙(junk-heap)이 얻어지고 관련성있는 메시지 및 아이템을 찾아내기가 더욱 어렵게 된다.

클라이언트 런타임은 사용자의 정보 스토어 내의 아이템들을 열거하고, 아이템들로부터(예를 들어, 이메일 메시지의 보디로부터 또 로컬 문서로부터) 개념을 추출하며 그 개념들을 사용자의 프로파일들 내의 KIS로 전송한다. 대체 실시예에서, 디폴트 프로파일만이 사용되어야만 한다. 클라이언트는 이어서 본질적으로 아이템들이 사용자가 가입한 KIS에 어떤 의미를 갖는지를 그 KIS에 "질문"을 한다. 바람직한 실시예에서, 클라이언트는 이하의 발견적 학습법을 이용해야 한다.

1. 첫째, 중복성의 검사 - 중복된 이메일 아이템, 개념 및 요약을 공유하는(그렇지만 서로 다른 타이틀 또는 파일 크기를 갖는) 중복된 문서에 플래그를 붙임(또는 삭제함)으로써. 클라이언트는 중복된 아이템(사용자 구성가능함)을 삭제하거나 이들을 이메일 클라이언트 또는 데스크톱 내의 특별 폴더(사용자 구성가능함)로 이동시킴으로써 그 아이템들에 플래그를 붙여야 한다.

2. 그 다음에, 비중복된 아이템에 대해, 클라이언트는 의미없음 또는 무관련성에 대해 검사해야 한다. 먼저, 클라이언트는 이메일 아이템, 문서 또는 다른 객체의 최근 수정된 시각을 검사함으로써 N일(예를 들어, 30일)보다 "더 오래된" 아이템들을 검사해야 한다. 적격인 아이템에 대해, 개념을 추출하고 사용자의 프로 파일들 모두(또는 대체 실시예에서 디폴트 프로파일) 내의 각 KIS에 대해 XML 웹 서비스를 호출한다.

3. 아주 오래된(예를 들어, 180일보다 오래된) 아이템의 경우, 클라이언트는 보존을 위해 XML 웹 서비스에 아주 낮은 의미 임계값(예를 들어, 25%)을 지정해야만 한다. 본질적으로, 이것은 아주 오래되고 의미가 약한 그 아이템들을 삭제하는 것과 유사하다.

4. 꽤 오래된(예를 들어, 90일보다는 더 오래되었지만 180일보다는 덜 오래된) 아이템의 경우, 클라이언트는 보존을 위해 아주 낮은 임계값(예를 들어, 10%)을 지정해야만 한다. 이것은 꽤 오래되고 의미가 아주 약한 그 아이템들을 삭제(또는 플래그 첨부)하는 것과 유사하다.

5. 오래된(그렇지만, 그다지 오래되지는 않은 - 예를 들어, 하루보다는 오래되었지만 30일보다는 오래되지 않은) 아이템의 경우, 클라이언트는 보존을 위해 아주 낮은 임계값(예를 들어, 0%)을 지정해야 한다. 이것은 사용자의 프로파일(들)에 기초하여 오래되었지만(그렇지만 그다지 오래되지는 않은) 의미가 없는 그 아이템들을 삭제(또는 플래그 첨부)하는 것과 유사하다.

본질적으로, 바람직한 실시예의 이 측면 또는 특징에 대한 모델은 덜 오래된 아이템들에 더 높은 시맨틱 임계값을 부과함으로써(그에 따라 전적으로 그렇지는 않지만 아이템들이 그다지 오래되지 않은(fairly young) 경우 대체적으로 의미없는 것일 수 있는 아이템을 보존함으로써) 시맨틱 민감성을 시간 민감성과 균형을 맞추어준다. 예를 들어, 상당히 최근의 이메일 쓰레드는 의미가 약할 수 있다 - 클라 이언트는 어쨌든 이들을 보존해야만 하는데 그 이유는 이들의 "오래되지 않음(youth)"도 역시 관련성의 표시이기 때문이다. 그렇지만, 아이템들이 "오래되어(age)"감에 따라, 클라이언트는 이들을 안전하게 삭제(또는 삭제를 위해 이들에 플래그 첨부)할 수 있다.

이 모델은 또한 로컬 파일 시스템 상에서 문서를 관리하는 데 적용될 수 있다. 이 모델은 (정보 신경 시스템™ XML 웹 서비스로의 호출을 통해) 이들 시스템을 모니터링하도록 정보 스토어 모니터(ISM)를 구성하고 시맨틱적으로 관리될 보관소의 도메인과 부합하는 온톨로지를 갖는 KDS로 구성되어 있는 KIS로 ISM을 구성함으로써 콘텐츠 관리 시스템, 문서 보관소 등으로 확장될 수 있다. 이 특징은 콘텐츠 관리 시스템을 시맨틱적으로 관리하고 시간에 따라 관련성있는 아이템만이 그 시스템 상에 보존되도록 보장함으로서 저장 공간 및 소토리지/유지 비용을 절감해준다.

43. 계산자(Slide-Rule) 필터 사용자 인터페이스

시맨틱 브라우저 내의 세분화 창(refinement pane)은 사용자가 "결과내 검색"을 할 수 있게 해준다. 사용자는 부가적인 키워드를 부가, 데이터 범위를 지정, 기타 등등을 할 수 있다. 데이터-범위 콘트롤은 계산자와 같이 구현될 수 있다. 계산자에서 한쪽 패널을 이동시키면 하위 날짜 경계를 이동시키는 반면 다른쪽 패널은 상위 날짜 경계를 이동시킨다. 이어서, 다른 패널들이 시간 경계를 위해 부가될 수 있다 - 시간 패널 및 날짜 패널 둘다를 이동시키면 날짜 및 시간 제약 둘다를 부과하게 된다. 패널은 또한 다른 필터축을 위해 부가될 수 있다.

C. 서버측 시맨틱 쿼리 프로세서 규격

1. 개요

이 섹션은 서버측 시맨틱 쿼리 프로세서(SQP)가 SQML 쿼리를 어떻게 분석하는지의 현재 바람직한 실시예를 기술한다. 주어진 서버 상에서, 쿼리는 몇 가지 성분으로 분해될 수 있다.

a. 컨텍스트(문서, 키워드, 엔티티, 포트폴리오(또는 엔티티 컬렉션))

b. 컨텍스트/지식 템플릿(또는 특별 에이전트) 또는 정보 템플릿 - 이것은 요청이 지식 타입(예를 들어, 속보, 대화, 뉴스 메이커 또는 인기있는 아이템)에 대한 것인지 특정 정보 타입(예를 들어, 문서, 이메일)에 대한 것인지를 기술한다.

클라이언트 상에서, 시맨틱 쿼리는 컨텍스트, 요청(또는 에이전트) 타입 및 지식 커뮤니티(또는 에이전시)의 삼각망으로 이루어져 있다. 클라이언트는 시맨틱 쿼리를 나타내는 SQML을 요청이 살아 있는 프로파일 내의 모든 지식 커뮤니티로 전송한다. 클라이언트는 한번에 몇 개의 결과를 요청하고 이어서 하나 이상의 서버로부터의 결과들을 통합한다.

서버측 시맨틱 쿼리 프로세서는 시맨틱 쿼리를 몇 개의 서브쿼리로 세분하고, 이어서 (바람직한 실시예에서 SQL 내부 결합 또는 서브쿼리를 통해) 그것을 적용한다. 이들 서브쿼리는 다음과 같다.

1. 요청 타입 서브쿼리 - 이것은 요청 타입에 의존하는 서브쿼리(시맨틱(semantic) 또는 비시맨틱(non-semantic))를 나타낸다. 예로는 컨텍스트(지식) 타입(예를 들어, 모든 배팅, 최선의 배팅, 헤드라인, 전문가 등)과 정보 타입(일반 문서, 프리젠테이션, 웹 페이지, 스프레드쉬트 등)이 있다.

2. 시맨틱 컨텍스트 서브쿼리 - 이것은 클라이언트로부터 전달된 컨텍스트(필터)로부터 도출된 시맨틱 서브쿼리를 나타낸다(이것의 예로는 클라이언트로부터 전송되거나 시맨틱 스테밍(semantic stemming)을 통해 키워드/텍스트로부터 매핑된 카테고리가 있다).

3. 비시맨틱 컨텍스트 서브쿼리 - 이것은 클라이언트로부터 전달된 컨텍스트(필터)로부터 도출된 비시맨틱 서브쿼리를 나타낸다(예로는 시맨틱 스테밍 - 온톨로지 기반 카테고리로의 매핑이 없는 키워드가 있다).

4. 액세스 제어 서브쿼리 - 이것은 호출측 사용자가 접근 권한이 없는 시맨틱 메타데이터 스토어(SMS) 내의 그 아이템들을 필터링 아웃하는 서브쿼리를 나타낸다. 상세한 것은 "보안"규격을 참조하기 바란다.

상기 단계들은 도 14(서버측 시맨틱 쿼리 프로세서 컴포넌트)에 예시되어 있다. 도 14는 서버측 시맨틱 쿼리 프로세서가 들어오는 시맨틱 쿼리(SQML로서 표현됨)를 어떻게 처리하는지를 보여준다.

2. 시맨틱 관련성 점수

시맨틱 관련성 점수는 개념 추출 엔진이 반환하는 정규화된 점수를 정의한다. 이는 텍스트 "블롭(blob)"의 주어진 용어를 주어진 온톨로지에 대한 하나 이상의 카테고리로 매핑한다. 이 점수는 아이템들이 시맨틱 네트워크에 부가될 때 ("SemanticLinks" 테이블의 "LinkStrength" 필드에서) 시맨틱 네트워크에 부가된다.

3. 시맨틱 관련성 필터

관련성 필터는 관련성 점수와는 다르다(실제로, 양자는 일반적으로 결합된다). 관련성 필터는 SQP가 시맨틱적으로 컨텍스트를 어떻게 해석하는지를 나타낸다(주의: 현재 바람직한 실시예에서, 필터링은 이 경우에 항상 시맨틱이다). 2개의 관련성 필터, High 및 Low가 있다. High 관련성 필터에 있어서, SQP는 카테고리와 용어의 교집합인 서브쿼리를 포함하게 된다. 예를 들어, 키워드 "XML"에 대한 컨텍스트는 XML과 동일한 카테고리를 공유하고 또 키워드 "XML"을 포함하는 아이템으로서 해석된다. 이것은 행해질 수 있는 최고 레벨의 온톨로지 기반 시맨틱 필터링이다. 그렇지만, 이는 시맨틱 네트워크(또는 시맨틱 메타데이터 스토어(SMS))에 시맨틱적으로 컨텍스트와 동등하지만 그의 키워드 또는 용어를 공유하지 않는 객체들이 있는 경우 정보 손실을 야기할 수 있다. 예를 들어, 전술한 쿼리는 XML과 동일한 카테고리를 공유하지만 그 대신에 용어 "확장 가능 마크업 언어(Extensible Markup Language)"는 아이템들을 놓치게 된다. Low 관련성 필터는 컨텍스트와 동일한 카테고리를 공유하지만 High 관련성 필터와는 달리 키워드 등가성의 부가적인 제약을 포함하지 않는 객체들만을 포함한다.

이 때문에, 관련성 필터는 양호하게는 나중에 결과를 정렬하는 데 사용되는 서브쿼리 "버킷(buckets)"을 생성하는 데만 사용된다. 예를 들어, SQP는 시맨틱 네트워크를 필터링할 때 High 관련성 필터를 Low 관련성 필터보다 먼저 우선순위를 부여하도록 결정할 수 있지만 최종 시맨틱 필터링 프로세스 동안 동의어가 거부되지 않도록 보장하는 데 도움을 주기 위해 여전히 둘다(중복된 것은 제거됨)를 반환 하게 된다.

4. 시간 민감성 필터

시간 민감성 필터는 시맨틱 서브쿼리가 얼마나 시간 임계적(time-critical)인지를 결정한다. 2가지 레벨, 즉 High 및 Low가 있다. High 필터는 극도로 시간 임계적임을 의미한다. 디폴트는 3시간이다(이것은 점심 시간, 사무실/책상으로부터 벗어난 시간 등을 고려한 것이다). Low 필터는 적당히 시간 임계적임을 의미한다. 디폴트는 12시간이다.

5. 지식 타입 시맨틱 쿼리 구현

본 출원 전체에 걸쳐, 어떤 특정의 지식 타입은 적절한 약식 이름으로 참조되고, 그 중 일부는 출원인이 상표명으로서 사용하거나 사용할 수 있다. 이 섹션은 이들 중 일부의 특성 및 기능을 보다 상세히 설명한다.

a. 모든 배팅

"모든 배팅" 쿼리의 경우, 서버는 단순히 시맨틱 메타데이터 스토어 내의 모든 아이템을 반환한다. SQML이 필터를 갖는 경우, 그 필터는 시맨틱 링크 세기 임계값을 갖지 않는 내부 서브쿼리를 통해 부과된다. 예를 들어, 토픽 A에 관한 모든 배팅은 토픽 A를 처리하는 것과 (강하게 또는 간신히) 관련된 모든 아이템을 반환한다.

b. 임의적인 배팅

바람직한 실시예에서, "임의적인 배팅" 쿼리의 경우, 서버는 단순히 시맨틱 메타데이터 스토어 내의 모든 아이템을 반환하지만("모든 배팅" 쿼리의 경우와 같 음) 결과를 임의적으로 정렬한다. SQML이 필터를 갖는 경우, 그 필터는 시맨틱 링크 세기 임계값을 갖지 않는 내부 서브쿼리를 통해 부과된다. 예를 들어, 토픽 A에 관한 임의적인 배팅은 토픽 A를 처리하는 것과 (강하게 또는 간신히) 관련된 (임의적으로 정렬된) 모든 아이템을 반환한다.

c. 속보

서버가 사용자 상태를 갖는 경우, 속보는 아주 지능적인 방식으로 구현될 수 있다. 이하의 테이블은 사용자가 어느 아이템(및/또는 카테고리)를 읽었는지를 서버가 추적할 때 속보에 대한 현재 바람직한 등급 및 우선순위 결정을 예시한 것이다.

바람직한 실시예에서, 서버는 (속보 컨텍스트 서술어를 통해) 속보에 대한 SQML을 다음과 같이 처리한다.

1. 모든 속보는 반환된 뉴스가 N시간(또는 일, 또는 월, 구성가능함)보다 "오래되지 않아야"한다는 서브쿼리로 필터링된다 - 이것은 중요한 시간 민감성 제약을 부과한다.

2. 속보는 항상 시맨틱이다.

3. 바람직한 실시예에서, 시맨틱 네트워크 관리자(SNM)는 각 사용자에 대한 "최근 읽은 시각"을 각 카테고리에 알려주기 위해 시맨틱 네트워크를 업데이트해야만 한다. 이것은 이어서 서브쿼리에서 (카테고리마다 또는 객체마다 - 카테고리마다가 바람직한 실시예인데 그 이유는 후자가 스케일링되지 않기 때문이다) 뉴스가 "읽혔는지" 여부를 검사하기 위해 사용된다.

4. 우선순위는 사용자가 "읽지"않은 뉴스 아이템들에 부여된다(이것은 SemanticLinks 테이블 내의 최근 읽은 시각을, "사용자"를 "카테고리"에 링크시키는 시맨틱 링크 타입과 비교함으로써 구현된다).

5. 시맨틱 우선순위 결정 방식이 암시하는 바는 뉴스가 더 시맨틱적으로 관련성있기 때문에 사용자가 "더 오래된" 속보를 먼저 가져올 수 있고 뉴스가 덜 시맨틱적으로 관련성있기 때문에 "덜 오래된" 속보를 "나중에" 가져올 수 있다는 것이다. 이 결과 하이브리드 관련성-시간 민감성 우선순위 결정 방식이 얻어진다.

6. 1차 정렬축(생성 시각)은 결과들이 신선함에 의해 필터링되도록 보장한다. 2차 정렬축(관련성 점수)은 타이브레이크(tiebreaker)로서 동작하며 똑같이 신선한 결과가 주로 관련성에 기초하여 구분되도록 보장한다.

7. 속보 내재적 경고(Breaking News Intrinsic Alert)는 클라이언트 상에서 속보 우선순위를 우선순위 2로 제한하고 우선순위 1 및 우선순위 시간 민감성 필터를 High로 변경함으로써 구현된다. 이와 같이, (High 및 Low 시맨틱 관련성 필터 둘다의) 아주 신선한 읽지 않은 시맨틱 속보만이 반환된다. 이것이 유익한 이유는 경고가 속보 요청(또는 에이전트)보다 더 높은 중단 임계값을 가져야만 하기 때문 이다 - 왜냐하면 그것이 명시적이기보다는 암시적이기 때문이다.

8. 읽지 않은 속보는 읽은 속보보다 더 높은 우선순위인 이유는 사용자가 아직 보지 않은 자료에 더 관심을 보일 수 있기 때문이다.

9. 읽지 않은 속보가 읽은 속보보다 더 낮은 시간 민감성 필터를 갖는 이유는 사용자가 자신에게 새로운 더 오래된 뉴스에 대해 새롭지 않은 덜 오래된 뉴스보다 더 관대할 수 있기 때문이다.

어떤 경우에, 서버는 사용자 상태(및 "읽음"정보)를 갖지 않을 수 있다. 이 경우, 속보의 간단한 구현이 이하에 주어져 있다.

1. 기본적으로(필터가 없음), 속보는 N시간(디폴트는 3시간임)보다 오래되지 않은 아이템만을 반환해야 한다.

2. SQML에 적어도 하나의 필터가 있는 경우, 속보는 시간 민감성 필터(3 시간)를 외부 서브쿼리에 적용하고 또 적당히 강한 관련성 필터를 (SemanticLinks 테이블로부터) 내부 서브쿼리에 적용해야 한다. 바람직한 실시예에서, 이것은 50%의 관련성 점수(및 링크 세기)에 대응해야 한다. 예를 들어, 토픽 A에 관한 속보는 적어도 50%의 관련성 점수를 갖는, 지난 3시간 동안 게시되었고 또 토픽 A로 나타내어진 카테고리(또는 카테고리들)에 속하는 그 아이템들을 반환한다. 이것은 토픽 A와 간신히 관련성있는 속보 아이템들과 같이 거짓 양성 판정을 회피하게 된다.

d. 헤드라인

속보에서와 마찬가지이다(시간 민감성 제약이 더 완화된 것을 제외하고 - 예를 들어, High 필터는 3 시간 대신에 12 시간이고 Low 필터는 12 시간 대신에 하루 임). 간단한 구현에서, 시간 민감성 제약은 하루이다. 이것은 또한 주말을 동적으로 처리하기 위해 월요일에는 3일로 될 수 있다(날짜수가 "근무일수"가 됨).

e. 뉴스 메이커

뉴스 메이커는 SQP가 아이템 자체가 아닌 헤드라인 아이템의 저작자를 반환하는 것을 제외하고는 헤드라인과 동일한 방식으로 처리된다.

f. 최선의 배팅

모출원(미국출원번호 제10/179,651)에 기술되어 있는 바와 같이, 최선의 배팅은 "카테고리에 속함(Belongs to Category)"서술어로 시맨틱 링크의 세기에 필터를 부과함으로써 구현된다. 바람직한 디폴트는 90%이지만, 클라이언트는 (사용자 임의로) XML 웹 서비스를 통해 전달된 인수를 통해 동작 중인 이것을 변경할 수 있다. 최선의 배팅은 Objects 테이블과 SemanticLinks 테이블 간의 SQL 내부 결합 및 "카테고리에 속함" 서술어 및 90%(디폴트) 이상의 LinkStrength를 갖는 SemanticLinks 테이블 내의 행들만을 결합하는 것에 의해 구현된다. 처리되고 있는 SQML이 필터(예를 들어, 키워드, 텍스트, 엔티티 등)를 포함하는 경우, 서버측 시맨틱 쿼리 프로세서는 또한 원하는 필터에 매핑되는 SQL 내부 결합인 서브쿼리를 호출해야만 한다. 바람직한 실시예에서, 이 서브쿼리는 또한 "최선의 배팅" 필터를 포함해야만 한다.

바람직한 실시예에서, 대부분의 사용자에 있어서 외부 서브쿼리가 최선의 배팅인 것이 유익하고 아마도 바람직하며, 내부 서브쿼리에 대해서도 마찬가지이다. 이것을 설명하기 위해, "토픽 A에 관한 최선의 배팅"은 시맨틱적으로 "토픽 A 에도 관련성있는 최선의 배팅"과 다르다. 첫 번째 예에서, 토픽 A"에 관한" 최선의 배팅인 최선의 배팅만이 (내부 서브쿼리에 대해 "최선의 배팅"시맨틱 필터를 적용함으로써) 반환된다. 이와 반대로, 두 번째 예는 토픽 A와 관련이 있을 수 있는 모든 것에 관한 최선의 배팅을 반환한다. 그 자체로서, 두 번째 예는 거짓 양성 판정을 반환할 수 있는데 그 이유는 예를 들어 토픽 B에 관해 최선의 배팅이지만 토픽 B에 관해 "약한 배팅(weak bet)"인 문서가 반환되고 그것이 쿼리의 시맨틱스와 부합하지 않거나 아마도 원하는 결과가 아니기 때문이다. "최선의 배팅" 필터를 외부 서브쿼리 뿐만 아니라 모든 내부 서브쿼리에도 확장하는 것은 이것이 일어나는 것을 방지한다. 다른 쿼리 구현도 역시 SQML이 필터를 포함하는 경우 이 규칙을 따를 수 있다(메인 쿼리의 시맨틱스에 기초하여 올바른 서브쿼리가 적용됨).

g. 다른 지식 타입에 대한 쿼리 구현

다른 지식 타입은 상기한 것과 유사한 방식으로 (올바른 서술어를 통해) 구현된다. 몇가지 예가 이하에 기술되어 있다.

정보 타입 시맨틱 쿼리 구현

모든 정보 타입 시맨틱 쿼리 구현은 동일한 패턴을 따를 수 있고 양호하게는 (반드시 그렇지는 않지만) 따른다. 즉, SQP는 요청된 정보 타입에 대응하는 객체 타입 id를 갖는 그 객체들만을 반환한다. 예는 "Information Type＼Presentations(정보 타입＼프리젠테이션)"이다. SQP가 클라이언트로부터 수신된 SQML을 파싱할 때, SQP는 SQML로부터 이 애트리뷰트를 추출하고 이를 객체 타입 id에 매핑한다. SQP는 이어서 객체 타입 id에 대한 부가된 필터로 SQL 쿼리를 호출 한다. 몇가지 개별적인 정보 타입에 걸쳐 있을 수 있는 특별한 정보 타입("Information Type＼All Documents(정보 타입＼모든 문서)"등)의 경우, SQP는 요청을 일련의 객체 타입 id로 매핑하고 이 부가된 필터로 SQL 쿼리를 호출한다.

컨텍스트 시맨틱 쿼리 구현

클라이언트가 개념(클라이언트 상에서 텍스트 또는 문서로부터 추출됨)을 포함하는 SQML을 전송할 때, 서버측 SQP는 그에 대응하는 서브쿼리를 생성하기 전에 먼저 그 개념을 시맨틱적으로 해석해야만 한다. 이를 위해, 서버는 시맨틱 카테고리화를 위해 그를 구성하고 있는 모든 KDS(KBS)로 개념들을 전송한다. 서버가 다시 카테고리를 가져올 때, 서버는 양호하게는 적절한 서브쿼리를 생성하기 전에 그 카테고리들 중 어느 것이 필터로서 사용될 정도로 "강한지"를 판정한다.

이 "필터-세기" 판정이 유익한 이유는 컨텍스트가 예를 들어 꽤 긴 문서인 경우, 그 문서는 수천개의 개념들 및 카테고리를 포함할 수 있기 때문이다. 그 결과, 문서의 "대표적인 시맨틱스"가 문서 내의 모든 개념들/카테고리들의 일부분에만 포함되어 있을 수 있다. 모든 카테고리들을 서브쿼리에 매핑하는 것은 사용자를 혼란케할 수 있는 결과를 반환한다 - 사용자는 문서가 무엇을 포함하는지 "감"을 가질 수 있고 사용자가 문서 내의 어떤 약한 개념과 관련성있는 결과를 보는 경우 사용자는 그 결과를 문서 컨텍스트와 조화시키지 못할 수 있다. 따라서, 바람직한 실시예에서, 서버측 SQP는 양호하게는 서브쿼리에 적용할 "강한 카테고리들"만을 선택한다. 이들이 적어도 50%의 시맨틱 세기를 갖는 카테고리인 것이 추천된다. 그와 같이, 시맨틱 컨텍스트에서 강하게 등록되는 카테고리들만이 서브쿼리에 적용된다. 서브쿼리의 구현은 지식 타입, 정보 타입 등에 기초하여 쿼리가 컨텍스트 서술어를 포함하는지 여부에 따라 전술한 규칙을 따른다.

시맨틱 스테밍 구현

모출원에 기술되어 있는 바와 같이, 서버측 시맨틱 쿼리 프로세서는 하나 이상의 도메인 온톨로지에 기초하여 키워드, 텍스트 및 개념을 카테고리에 매핑하기 위해 시맨틱 스테밍(semantic stemming)을 수행한다. 이것을 행하는 한가지 방식은 카테고리를 획득하기 위해 그를 구성하고 있는 KDS/KBS(또는 KDS들/KBS들)로의 XML 웹 서비스 호출을 호출하는 것에 의한다. 시맨틱 스테밍은 이어서 카테고리를 그의 시맨틱 네트워크로 매핑한다. 이러한 형태의 스테밍은 키워드 변형(단수 변형 및 복수 변형, 시제 변형 등)에 기초하는 통상의 스테밍보다 우수한데, 그 이유는 키워드 형태에만 기초하는 스테밍보다 의미에 기초하여 스테밍하는 도메인 관련 시맨틱 매핑을 포함하기 때문이다.

현재 바람직한 실시예에서, KIS는 추가의 시맨틱 해석을 필요로 하는 SQML을 수신할 때마다 KDS/KBS를 호출한다. 그렇지만, 이 결과 KDS/KBS가 서로 다른 서버 상에 있는 경우, 네트워크 연결이 빠르지 않은 경우, 또는 KDS/KBS가 많은 요청을 처리하느라 바쁜 경우 지연이 있을 수 있다. 이 경우, KIS도 역시 시맨틱 스테밍 캐쉬를 구현할 수 있다. 이 캐쉬는 전체 이름으로 된 URI를 갖는 카테고리(카테고리를 전역적으로 고유하게 만들어줌)에 키워드 및 개념을 매핑한다. 서버측 시맨틱 쿼리 프로세서는 키워드, 텍스트, 또는 개념(말하자면 클라이언트 상에서 클라이언트측 시맨틱 쿼리 프로세서에 의해 문서로부터 추출됨)을 포함하는 SQML을 수 신할 때, 먼저 키워드가 이미 시맨틱적으로 스테밍되었는지를 알아보기 위해 캐쉬를 검사한다. 캐쉬 히트가 있는 경우, SQP는 단지 캐쉬로부터 카테고리를 검색하고 그 카테고리를 SQL 쿼리를 통해 시맨틱 네트워크에 매핑한다. 캐쉬 미스가 있는 경우(즉, 컨텍스트가 캐쉬에 없는 경우), SQP는 시맨틱 카테고리화를 수행하기 위해 KDS들/KBS들을 호출한다. 이는 이어서 그 결과를 취하고, 이 결과를 고유의 카테고리 URI에 매핑하며 엔트리를 캐쉬에 부가한다(컨텍스트를 해쉬 코드로 사용함). 유의할 점은 컨텍스트가 어떤 카테고리에도 매핑되지 않더라도, "카테고리의 결여(lack of a category)"는 양호하게는 캐싱된다. 환언하면, 컨텍스트는 카테고리를 갖지 않는 캐쉬 엔트리로서 부가된다. 이와 같이, 서버는 찾아내기 위해 매번 KDS들/KBS들을 호출할 필요없이 주어진 컨텍스트가 어떤 카테고리도 갖지 않는지를 신속하게 결정할 수 있다.

캐쉬 관리

SQP는 또한 시맨틱 스테밍 캐쉬를 관리할 수 있다. SQP는 2가지 이유로 이것을 해야만 한다. 첫째로, 캐시가 무제한으로 커져 너무 많은 시스템 리소스(특히, 힙 기반 해쉬 테이블을 갖는 메모리)를 소모하는 것을 방지하기 위해, 둘째로 KIS 구성이 변경되는 경우(예를 들어, 지식 도메인이 부가/제거되는 경우), 캐시는 양호하게는 지워지는데 그 이유는 엔트리들이 이제는 쓸모없는 것일 수 있기 때문이다. 첫 번째 시나리오는 최대 수의 엔트리를 캐쉬에 할당함으로써 처리될 수 있다. 바람직한 실시예에서, SQP는 캐시에 의해 소모되는 현재 메모리양을 캐싱하고 캐쉬 한계는 메모리 사용에 의해 좌우된다. 예를 들어, 운영자는 최대 캐쉬 크기 를 64MB로 설정할 수 있다. 구현을 간단화하기 위해, 이것은 (예를 들어, 각각의 캐쉬 엔트리의 크기의 추정치로 최대 메모리 사용을 나눔으로써) 적절한 수의 아이템에 매핑될 수 있다.

각각의 새로운 엔트리에 대해, 캐쉬 한계에 도달되지 않은 경우, SQP는 엔트리를 캐쉬에 부가한다. 그렇지만, 캐쉬 한계에 도달된 경우, SQP는 (바람직한 실시예에서) 적어도 최근에 부가된 아이템을 캐쉬로부터 제거해야 한다. 바람직한 실시예에서, 이것은 (컨텍스트를 키로서 사용하여 신속한 탐색을 위해) 캐쉬 자체를 구현하는 해쉬 테이블과 동기를 유지하는 아이템들의 큐를 유지함으로써 구현될 수 있다. SQP는 공간을 비우기 위해 캐쉬로부터 아이템들을 제거할 필요가 있을 때, 적어도 최근에 부가된 큐로부터 아이템을 디큐잉하고 또한 (컨텍스트를 키로서 사용하여) 대응하는 아이템을 해쉬 테이블로부터 제거한다. 이와 같이, 신선한 아이템은 더 오래된 아이템보다 캐쉬 히트가 될 가능성이 더 많다. 이 결과 클라이언트 상에서 더 빠른 사용자 경험이 있게 되는데 그 이유는 사용자가 에이전트/요청/쿼리를 열 때마다 저장된 에이전트/요청/쿼리에 대한 컨텍스트가 신속한 탐색으로 캐싱되는 것으로 마무리되기 때문이다. 동일한 컨텍스트를 갖는(그렇지만 서로 다른 지식 타입을 갖는) 일건서류(Dossier)(가이드) 쿼리에 대해서도 마찬가지이다 - 클라이언트는 동일한 컨텍스트에 대한 각각의 지식 타입을 요청하고, 컨텍스트가 캐싱되기 때문에 각각의 서브쿼리가 더 빠르게 실행된다.

D. 정보 신경 시스템에 대한 확장가능한 클라이언트측 사용자 프로파일 규격

개요

확장가능한 클라이언트측 사용자 프로파일은 시맨틱 브라우저의 사용자가 서로 다른 업무 역할, 지식 소스, 식별자, 사람, 작업 스타일 등에 대해 서로 다른 상태를 가질 수 있게 해준다. 이것은 본질적으로 사용자가 서로 다른 시나리오에 대해 서로 다른 "지식 세계"를 생성할 수 있게 해준다. 예를 들어, 의약 연구자는 그의 작업과 관련성있는 모든 지식 소스를 포함하는 디폴트 프로파일을 가질 수 있다. 모출원 제10/179,651호에 기술되어 있는 바와 같이, 이들 소스 각각으로부터의 SRML은 클라이언트 상에서 병합되며 그에 따라 사용자가 매끄럽게 결과를 하나의 소스에서 오는 것처럼 달성할 수 있게 해준다. 그렇지만, 연구자는 그 밖의 모든 것과 별개인 특허를 추적하고자 할 수 있다. 이러한 경우, 연구자는 별도의 "특허(Patents)"프로파일을 생성하고 또 특허와 관련이 있는 지식 커뮤니티(에이전시)(예를 들어, 미국 특허청 데이터베이스, EU 특허 데이터베이스 등)를 포함할 수 있다.

또다른 예를 말하면, 예를 들어, 사용자는 "직장"에 대한 프로파일 및 "가정"에 대한 프로파일을 생성할 수 있다. 많은 투자 분석가들은 다양한 업계에 걸쳐 회사를 추적한다. 시맨틱 브라우저를 사용하여, 분석가들은 자신이 추적하는 각 업계에 대한 프로파일을 생성한다. 컨설턴트는 프로젝트마다(또 업계마다) 이동하며 각 프로젝트로 생성된 요청 및 엔티티를 저장하고자 할 수 있다. 프로파일은 이 시나리오를 처리하는 데도 사용될 수 있다.

프로파일은 이하의 사용자 상태를 포함한다.

● 이름/설명 - 프로파일의 설명적 이름

● 요청(에이전트)이 호출되어질 (KIS 상에서 실행 중인) 지식의 소스를 나타내는 하나 이상의 지식 커뮤니티(에이전시).

● 식별자 정보 - 사용자 이름(현재 사용자의 이메일 주소로 태깅되어 있음) 및 패스워드

● 관심 영역 또는 즐겨찾기 카테고리 - 이것은 (동일한 또는 유사한 카테고리를 갖는 정보 컴포넌트에 비교함으로써) 사용자에게 정보 커뮤니티(에이전시)를 제안하고 디폴트로서 그 프로파일로 생성된 요청들에 대한 필터를 쿼리하는 데 사용된다.

● 스마트 스타일 - 프로파일로 생성된 요청 및 엔티티에 대해 디폴트로 사용될 스마트 스타일

● 디폴트 플래그 - 이것은 프로파일이 디폴트 프로파일인지 여부를 나타낸다. 디폴트 프로파일은 사용자가 요청 및 엔티티를 생성, 정보 커뮤니티를 브라우징, 기타 등등을 하고자 할 때 디폴트로 개시된다. 사용자가 다른 프로파일을 명시적으로 선택하지 않는 한, 디폴트 프로파일이 사용된다.

프로파일은 생성, 삭제, 수정 및 이름 변경될 수 있다. 그렇지만, 바람직한 실시예에서, 디폴트 프로파일은 삭제될 수 없는데 그 이유는 시스템에 항상 적어도 하나의 프로파일이 있어야만 하기 때문이다. 대체 실시예에서, 최소 프로파일이 요구되지 않는다.

양호하게는, 시맨틱 브라우저 내의 모든 객체가 프로파일의 컨텍스트 내에서 열린다. 예를 들어, 스마트 요청은 프로파일에서 생성되고, 런타임 시에 클라이언 트 시맨틱 쿼리 프로세서는 그 요청을 호출하기 위해 프로파일의 프로퍼티(구체적으로 말하면 그 프로파일 내의 가입된 지식 커뮤니티(에이전시))를 사용한다. 이것은 사용자가 요청의 지식 특성(보다 일반적으로는 사용자가 요청에 대해 사용하고자 하는 지식의 소스)에 기초하여 요청을 특정의 프로파일에 상관시키거나 스코핑(scope)할 수 있게 해준다.

도 15는 2가지 프로파일("내 프로파일(My Profile)"이라는 이름의 디폴트 프로파일(15A) 및 "특허(Patents)"라는 이름의 프로파일(15B))을 보여주는 시맨틱 브라우저를 나타낸 것이다. 사용자가 양 프로파일을 통해 방해 없이 그의 지식 세계를 어떻게 네비게이션 하는지를 관찰해보라.

도 16A 내지 도 16C는 사용자가 프로파일을 어떻게 구성하는지(프로파일을 생성하기 위해, 사용자는 "프로파일 생성 마법사(Create Profile Wizard)"를 사용하고 이어서 이 프로파일은 도시한 바와 같이 프로퍼티 시트(property sheet)를 통해 수정될 수 있음)를 예시한 것이다.

도 17은 "요청 생성 마법사(Create Request Wizard)"로 요청을 생성할 때 사용자가 프로파일을 어떻게 선택하는지를 나타낸 것이다.

E. 정보 신경 시스템에 대한 스마트 스타일 규격

1. 스마트 스타일 개요

스타일 테마에 적용되는 컬러 테마 및 애니메이션 테마는 "스마트 스타일"을 생성한다. 이 컨텍스트에서 "스마트"란 그 스타일이 그의 요청의 분위기, 컨텍스트 창, 미리보기 모드, 핸드헬드 모드, 라이브 모드, 슬라이드쇼 모드, 스크린세이 버 모드, 블렌더/컬렉션 모드, 접근성, 사용자 설정 인식, 및 아마도 시스템 내의 다른 변수(이하 참조)에 적응적이거나 반응한다는 것을 의미한다. 무한한 수 및 종류 또는 "클래스(Classes)"의 가능한 스타일이 있다. 바람직한 실시예는 적어도 이하의 스타일 클래스를 포함한다.

1. 미묘(Subtle) - 태스크 지향 생산성에 대해

2. 적절(Moderate) - 어떤 프리젠테이션 효과를 갖는 태스크 지향 생산성에 대해

3. 흥분(Exciting) - 흥분시키는 효과 (1차 및 2차 머신 둘다에 대해 또 비활성 Nervana 윈도우에 대해 양호함 - 예를 들어, 배경 내의 또는 태스크바 상에 도킹된 Nervana 클라이언트 윈도우)

4. 과도 흥분(Super-exciting) (사용자가 그의 1차 머신을 사용할 때 생산성을 갖는 스마트 스크린세이버에 좋음 - 예를 들어 2차 머신)

5. Sci-Fi (매트릭스 팬에 대해, 특정의 생산성 필요가 없는 스마트 스크린세이버에 좋음 - 예를 들어 사용자가 그의 책상에서 멀리 떨어져 있을 때)

Nervana 및 아마도 사용자 및/또는 써드파티 스킨 저작자에 의해 생성된 스타일, 컬러 및 애니메이션 테마 - 가변적임, 무제한 -

2. 암시적인 동적 스마트 스타일 프로퍼티

a. 분위기 - 스마트 스타일은 요청의 분위기를 전달해야만 한다(즉, 요청은 스마트 스타일로 전달되는 파라미터이다). 이것은 스마트 요청의 시맨틱적으로 통보되거나 시맨틱적으로 결정되는 프로퍼티(컨텍스트 템플릿 또는 정보 타입, 카테 고리, 필터(예를 들어, 로컬 문서)가 있는지 여부, 그 필터들의 정보 타입 등)를 전달하는 시맨틱 이미지, 시맨틱 움직임, 시각화 등을 포함한다.

b. 컨텍스트 창 - 예를 들어 깊이있는 정보 창(객체마다), 도킹가능한 미리보기 창, 도킹가능한 컨텍스트 PIP 감시 그룹/창 등

c. 미리보기 모드 - 각 스마트 스타일은 미리보기를 위해 (작은 윈도우에) 그의 결과를 디스플레이할 수 있어야만 한다.

d. 핸드헬드 모드 - 각 스마트 스타일은 핸드헬드 장치에 최적화된 그의 결과를 디스플레이할 수 있어야만 한다.

e. 라이브 모드 - 각 스마트 스타일은 실시간 시맨틱 시각화(객체마다)를 디스플레이하는 동안인 "라이브(live)" 모드를 가져야만 한다. 이것은 온 또는 오프 토글될 수 있다(예를 들어, 사용자가 실시간 시맨틱 시각화를 원하지 않는 경우, 또는 객체마다 실시간 웹 서비스 호출로 야기되는 대역폭을 절감하기 위해).

f. 슬라이드쇼 모드 - 양호하게는, 각 스마트 스타일은 요청의 결과를 - 라이브 스트림처럼 - "재생(play)"할 수 있어야만 한다.

g. 스크린세이버 모드 - 양호하게는, 각 스마트 스타일은 요청의 결과를 스크린세이버로서 "재생"할 수 있어야만 한다. 이것은 전체 화면/극장 모드에서를 제외하고는 슬라이드쇼 모드의 변형이다.

h. 블렌더/컬렉션 모드 - 양호하게는, 각 스마트 스타일은 디스플레이하고 있는 중인 요청이 블렌더/컬렉션인 경우에 그의 UI를 적절히 변경해야만 한다.

i. 접근성 - 양호하게는, 각 스마트 스타일은 접근성을 지원해야만 한다.

j. 사용자 설정 인식 - Nervana Librarian은 사용자가 초보자, 보통 사용자, 또는 파워-유저인지와 그의 개별적인 업무 기능(R＆D, 판매, 마케팅, 관리 등)을 나타낼 수 있게 해준다. 양호하게는, 각 스마트 스타일은 적절한 경우 이들 기능을 고려한다(또는 그에 의해 영향을 받는다).

● 양호하게는, 각 스마트 스타일은 요청의 시맨틱스에 부합하게, 인식(또는 분간 또는 인지)한 다음에 시각화(사용자의 주목을 받을만한 것에 부합하게, 또는 제공 또는 묘사 또는 예시)하는 일을 맡는다.

● 현재 요청의 분위기(시맨틱 이미지, 움직임, 크롬 도금 등을 포함함)

● 현재 요청 내의 아이템의 수의 변경

● 각 객체의 분위기(내재적으로)

● 각 객체의 컨텍스트의 분위기(헤드라인, 속보, 전문가 등)

● 정도의 문제 또는 기울기나 연속성에 관한 문제와 다른 이원적/절대적 문제 또는 특성(예를 들어, 속보가 있는가 여부?, 얼마나 많은 전무가가 있는가? 얼마나 많은 헤드라인이 있는가?)

● 특성이 기울기 또는 연속성에 관한 것인 경우, 그를 따라 상대적 배치를 인지(예를 들어, 속보가 얼마나 엄청난 것인가? 헤드라인이 얼마나 중대한 것인가? 전문가의 전문 지식의 수준이 어느 정도인가 등)

● 각 객체의 컨텍스트의 변경(새로운 속보가 있다, 새로운 주석이 있다, 등)

● 각 객체가 디스플레이될 상대적 중요성(RELATIVE criticality)(서로 다른 크기의 뷰 포트, 서로 다른 폰트, 서로 다른 크롬 도금 등)

● 요청 네비게이션 및 "로딩" 상태(로드되는 새로운 요청의 분위기를 소개하는 삽입물)

● 임의의 개별적인 PIP 윈도우의 모든 프로퍼티(애니메이션 콘트롤로 애니메이션화됨)

● (PIP 윈도우 팔레트에) 새로운 PIP 윈도우의 부가

● PIP 윈도우의 임의의 크기 변경/이동/도킹

● 임의의 미리보기 윈도우(컨텍스트 팔레트의 경우, 각 객체 상의 "시각화 UI", 타임 라인 등)

● 분위기 및 통지의 이전의 시각화 모두와 부합하는 사운드(보드 전체에 걸쳐)

도 18은 상기한 동작들 및 특징들 중 일부를 나타낸 "스마트 스타일(Smart Styles)" 대화 상자를 갖는 스크린 사진을 나타낸 것이다. 알 수 있는 바와 같이, 대화 상자는 사용자가 스타일 부류, 스타일 테마, 색상 테마, 및 애니메이션 테마에 걸쳐 피벗함으로써 스마트 스타일을 브라우징할 수 있게 해준다. 미리보기 윈도우는 사용자에게 현재 선택된 스마트 스타일의 미리보기를 보여준다.

F. 정보 신경 시스템에 대한 스마트 요청 감시 규격

1. 개요

스마트 요청 감시는 시맨틱 브라우저(정보 에이저너트 또는 라이브레리언)의 사용자가 스마트 요청을 병렬로 모니터링(또는 "감시")할 수 있게 해주는 정보 신 경 시스템의 특징을 말한다. 이것은 사용자가 동시에 몇 개의 요청을 추적할 수 있게 해줌으로써 생산성을 향상시킨다는 점에서 아주 유익한 특징이다.

이 특징은 구성가능한 스마트 요청 감시 방식을 가능하게 해주는 클라이언트측 시맨틱 런타임, 시맨틱 브라우저 및 스킨에서 (텔레비전 세트의 "PIP(Picture-In-Picture)"기능과 유사한 메카니즘을 통해) 구현된다. 양호하게는, 이하의 소프트웨어 컴포넌트 중 하나 이상이 사용된다.

1. 요청 감시 리스트(RWL)

2. 요청 감시 그룹

3. 통지 관리자(NM)

4. 감시 그룹 모니터(WLM)

5. 감시창(Watch Pane)

6. 감시 윈도우(Watch Window)

2. 요청 감시 리스트(RWL) 및 그룹(RWG)

요청 감시 리스트는 클라이언트 런타임이 관리하는 스마트 요청(또는 스마트 에이전트)의 리스트이다. 이 리스트는 본질적으로 사용자가 모니터링하고자 하는 스마트 요청을 포함한다. 요청 감시 리스트는 엔트리의 리스트, 즉 이하의 데이터 구조체를 갖는 요청 감시 리스트 엔트리(RWLE)를 포함한다.

요청 감시 리스트(RWL)는 RWLE 구조체의 어레이 또는 벡터를 포함한다. 요청 감시 리스트 관리자는 RWL을 관리한다. 시맨틱 브라우저는 사용자가 스마트 요청을 RWL에 부가할 수 있게 해주는 사용자 인터페이스를 제공한다 - UI는 RWL로/로부터 RWLE를 부가 및 제거하도록 RWLM에 지시한다. RWL은 클라이언트측 시맨틱 런타임에 의해 (XML 파일 기반 표현으로서 또는 Windows 레지스트리처럼 스토어에) 중앙집중적으로 저장(및 존속)된다.

RWL은 또한 요청 감시 그룹(RWG)에 의해 채워질 수 있다. 요청 감시 그룹은 사용자가 스마트 요청의 컬렉션을 모니터링하는 수단을 제공한다. 이는 또한 사용자가 시맨틱 브라우저로 하여금 구성가능한 조건에 기초하여 RWL을 자동적으로 채우도록 하는 간단한 방법도 제공한다. 적어도 2가지 타입의 RWG, 즉 자동 요청 감시 그룹 및 수동 요청 감시 그룹이 있다. 자동 요청 감시 그룹은 선택된 프로파 일, 즉 현재 디스플레이된 요청의 프로파일 등에 따라 시맨틱 브라우저에 의해 동적으로 채워지는 그룹이다. 수동 요청 감시 그룹은 사용자가 컬렉션으로 모니터링하기 위해 수동으로 일군의 스마트 요청(정규 스마트 요청 또는 블렌더)을 채울 수 있게 해준다. 수동 요청 감시 그룹은 또한 사용자가 컨텍스트 타입(예를 들어, 문서, 카테고리, 텍스트, 키워드, 엔티티 등)을 부가/지원할 수 있게 해준다 - 이 경우, 시스템은 필터(들)로부터 동적으로 시맨틱 쿼리(SQML)를 생성하고 그 결과 얻어지는 쿼리를 수동 요청 감시 그룹에 부가한다. 이것은 필터를 감시 그룹에 부가하기 전에 하나 이상의 필터에 기초하여 사용자가 먼저 시간에 민감한 요청을 생성할 필요가 없게 해준다 - 사용자는 단지 필터 상에 포커싱하기만 하고 시스템이 나머지를 행한다.

(도 19의 스마트 요청 감시 대화 상자에 도시한 "모든 프로파일"을 비롯하여 하나 이상의 구성가능 프로파일에 대해) 사용자는 이하의 타입의 자동-RWG을 부가할 수 있다.

1. 속보 - 이것은 시맨틱 브라우저에 속보 스마트 요청을 (선택된 프로파일(들)에 대한) RWL에 자동적으로 부가하도록 지시한다.

2. 헤드라인 - 이것은 시맨틱 브라우저에 헤드라인 스마트 요청을 (선택된 프로파일(들)에 대한) RWL에 자동적으로 부가하도록 지시한다.

3. 뉴스 메이커 - 이것은 시맨틱 브라우저에 뉴스 메이커 스마트 요청을 (선택된 프로파일(들)에 대한) RWL에 자동적으로 부가하도록 지시한다.

4. 카테고리화된 속보 - 이것은 시맨틱 브라우저에 카테고리화된 속보 스마 트 요청을 (컨텍스트 프로파일에 대한) RWL에 자동적으로 부가하도록 지시한다. 시맨틱 브라우저는 현재 디스플레이된 스마트 요청의 각 서브카테고리에 대응하는 카테고리 필터를 갖는(및 컨텍스트 또는 현재 프로파일에 대한) 스마트 요청을 동적으로 부가한다 - 현재 디스플레이된 스마트 요청이 카테고리를 갖는 경우. 예를 들어, 스마트 요청 "기술에 관한 "속보""가 현재 시맨틱 브라우저 인스턴스에 디스플레이되고 있는 중인 경우, 및 카테고리 "기술(Technology)"이 5개의 서브카테고리(예를 들어, 무선, 반도체, 나노기술, 소프트웨어, 및 전자)를 갖는 경우, 이하의 스마트 요청은 현재 스마트 요청이 로드될 때 RWL에 동적으로 부가된다.

● 기술.무선에 관한 속보＜컨텍스트적 프로파일 이름＞

● 기술.반도체에 관한 속보＜컨텍스트적 프로파일 이름＞

● 기술.나노기술에 관한 속보＜컨텍스트적 프로파일 이름＞

● 기술.소프트웨어에 관한 속보＜컨텍스트적 프로파일 이름＞

● 기술.전자에 관한 속보＜컨텍스트적 프로파일 이름＞

또한, 이들 엔트리에 대한 RWLE는 현재 시맨틱 브라우저 인스턴스의 RequestViewInstanceID로 초기화된다. 사용자가 새로운 스마트 요청으로 네비게이션하면, 이전에 로드된 스마트 요청에 대한 카테고리화된 속보는 RWL로부터 제거되고, 카테고리화된 속보의 새로운 리스트가 새로운 스마트 요청에 대해 (이 요청이 카테고리를 갖는 경우) 부가되고 - 새로운 스마트 요청 뷰에 대응하는 새로운 RequestViewInstanceID로 초기화된다. 이것은 스마트 사용자 경험을 생성하며, 이 때 (서브카테고리에 대한) 관련성 있는 카테고리화 된 속보는 현재 디스플레이된 요청에 기초하여 동적으로 디스플레이된다. 사용자는 이어서 카테고리화된 속보 스마트 요청을 감시 그룹 또는 컬렉션으로서 모니터링할 수 있다.

5. 카테고리화된 헤드라인 - 이것은 시맨틱 브라우저에 카테고리화 된 헤드라인 스마트 요청을 (컨텍스트적 프로파일에 대한) RWL에 자동적으로 부가하도록 지시한다. 이것은 이 경우에 헤드라인이 사용되는 것을 제외하고는 카테고리화된 속보와 유사하다. 사용자는 이어서 카테고리화된 헤드라인 스마트 요청을 감시 그룹 또는 컬렉션으로서 모니터링할 수 있다.

6. 카테고리화된 뉴스 메이커 - 이것은 시맨틱 브라우저에 카테고리화된 뉴스 메이커 스마트 요청을 (컨텍스트적 프로파일에 대한) RWL에 자동적으로 부가하도록 지시한다. 이것은 이 경우에 뉴스 메이커가 사용되는 것을 제외하고는 카테고리화된 속보와 유사하다. 사용자는 이어서 카테고리화된 뉴스 메이커 스마트 요청을 감시 그룹 또는 컬렉션으로서 모니터링할 수 있다.

7. 내 즐겨찾기 요청 - 이것은 시맨틱 브라우저에 모든 즐겨찾기 스마트 요청을 (선택된 프로파일(들)에 대한) RWL에 자동적으로 부가하도록 지시한다. 이것은 사용자가 모든 그의 즐겨찾기 스마트 요청을 그룹으로서 감시 또는 모니터링할 수 있게 해준다.

8. 내 즐겨찾기 속보 - 이것은 시맨틱 브라우저에 모든 즐겨찾기 속보 스마트 요청을 (선택된 프로파일(들)에 대한) RWL에 자동적으로 부가하도록 지시한다. 이것은 사용자가 모든 그의 즐겨찾기 속보 스마트 요청을 그룹으로서 감시 또는 모니터링 할 수 있게 해준다.

9. 내 즐겨찾기 헤드라인 - 이것은 시맨틱 브라우저에 모든 즐겨찾기 헤드라인 스마트 요청을 (선택된 프로파일(들)에 대한) RWL에 자동적으로 부가하도록 지시한다. 이것은 사용자가 모든 그의 즐겨찾기 헤드라인 스마트 요청을 그룹으로서 감시 또는 모니터링할 수 있게 해준다.

10. 내 즐겨찾기 뉴스 메이커 - 이것은 시맨틱 브라우저에 모든 즐겨찾기 뉴스 메이커 스마트 요청을 (선택된 프로파일(들)에 대한) RWL에 자동적으로 부가하도록 지시한다. 이것은 사용자가 모든 그의 즐겨찾기 뉴스 메이커 스마트 요청을 그룹으로서 감시 또는 모니터링 할 수 있게 해준다.

요청 감시 그룹 관리자 사용자 인터페이스

도 19는 바람직한 실시예의 시맨틱 브라우저 내의 "스마트 요청 감시(Smart Request Watch)" 대화 상자를 나타낸 것이다. 대화 상자의 상반부는 자동 감시 그룹을 부가하는 데 사용된다. 사용자는 자동 감시 그룹 타입 및 프로파일 타입("모든 프로파일", "컨텍스트적 프로파일" 및 실제 프로파일 이름)을 선택하고 이들을 자동 감시 그룹 리스트에 부가할 수 있다. 사용자는 또한 자동 감시 그룹을 제거할 수 있다. 대화 상자의 하반부는 수동 감시 그룹으로/으로부터 스마트 요청을 부가/제거하는 데 사용된다.

3. 통지 관리자(NM)

바람직한 실시예에서, 통지 관리자(NM)는 RWL 내의 스마트 요청을 모니터링하는 시맨틱 런타임 클라이언트의 컴포넌트이다. NM은 RWL 내의 각 스마트 요청을 (클라이언트 시맨틱 쿼리 프로세서를 통해) 주기적으로 호출하고 RWLE를 "결과 카 운트" 및 "최근 업데이트 시각"으로 업데이트하는 쓰레드를 갖는다. 바람직한 실시예에서, NM은 양호하게는 매 5-30초마다 스마트 요청을 호출한다. (대역폭 사용 및 웹 서비스에 대한 확장성 영향을 최소화하기 위해) NM은 RWL의 크기에 따라 요청 검사의 주기성 또는 빈도를 지능적으로 조정할 수 있다.

시간에 민감한 스마트 요청(속보, 헤드라인 및 뉴스 메이커 등)의 경우, NM은 양호하게는 어떤 부가적인 시간 필터도 없이 스마트 요청을 호출한다. 그렇지만, 시간에 민감하지 않은 요청의 경우(컨텍스트 타입과 반대인 정보의 경우 또는 즐겨찾기 및 추천 같은 시간에 민감하지 않은 컨텍스트 템플릿의 경우), NM은 양호하게는 시간 필터로(예를 들어, 지난 10분) 스마트 요청에 대한 쿼리를 호출한다.

4. 감시 그룹 모니터

바람직한 실시예에서, 시맨틱 런타임 클라이언트는 본 발명자가 감시 그룹 모니터(WGM)라고 부르는 것을 관리한다. 사용자가 감시 그룹 리스트에 부가한 각 감시 그룹에 대해, 클라이언트는 감시 그룹 모니터를 생성한다. 감시 그룹 모니터는 그의 감시 그룹 내의 각 요청에서의 새로운 결과의 수를 추적한다. 감시 그룹 모니터는 새로운 결과를 갖는 감시 그룹 내의 RWLE에 대한 큐를 생성한다. WGM은 결과의 신선도를 최대화하기 위해 큐를 관리한다. WGM은 그의 감시 그룹 내의 각 요청에 대한 새로운 결과가 있는지 여부를 알아보기 위해 NM에 주기적으로 폴링을 행한다. 있는 경우, WGM은 요청의 "최근 결과 시각"에 따라 큐에 요청을 부가한다. WGM은 가장 신선한 결과를 갖는 요청을 먼저 우선순위 부여하기 위해 이것을 한다. 프리젠터에서 실행 중인 현재 디스플레이된 시각 스타일(스킨)은 이어서 WGM 큐 내의 요청을 디큐잉하기 위해 시맨틱 런타임 OCX를 호출한다. 이와 같이, 요청 감시 사용자 인터페이스는 새로운 결과의 존재 및 결과의 신선도와 부합된다. 현재 디스플레이된 요청에 더 이상 새로운 결과가 없는 경우, 스마트 스타일은 WGM 큐로부터 그 다음 요청을 디큐잉한다.

5. 감시창

감시창(Watch Pane: WP)은 (주 결과창과 함께) 프리젠터(presenter)에게 디스플레이되고 사용자의 감시 그룹의 시각적인 표현들을 유지하는 패널(panel)을 지칭한다. WP는 사용자가 요청 내에 새로운 결과가 있는지 여부를 알기 위해 각각의 감시 그룹을 흘긋 보는 것을 허용한다. 또한 WP는 사용자가 각각의 감시 그룹의 실시간 상태가 디스플레이되는 현재 보기를 바꾸는 것을 허용한다. 다음 보기들이 현재 정의되어 있다.

타일형 보기 - 이 보기는 모든 스마트 요청 내에 새로운 결과의 총 개수와 함께 감시 그룹의 제목을 디스플레이한다.

티커(ticker) 보기 - 이 보기는 모든 감시 그룹의 스마트 요청 내에 새로운 결과의 총 개수를 디스플레이하며 (티커처럼) 각각의 스마트 요청 내에 새로운 결과의 개수를 순차적으로 디스플레이하는 애니메이션을 보여준다.

미리 보기 - 이 보기는 티커 내에 새로운 결과의 개수와 함께 단위 스마트 요청당 최신 결과도 디스플레이되는 점을 제외하고는 티커 보기와 비슷하다.

심층 보기 - 이 보기에서, WP는 스마트 요청당 모든 새로운 결과의 슬라이드 쇼와 각각의 스마트 요청 내에 새로운 결과의 총 개수를 디스플레이하는 티커 와 함께 감시 그룹의 모든 스마트 요청 내에 새로운 결과의 총 개수를 디스플레이한다.

6. 감시 윈도우

WP는 사용자가 감시 그룹을 감시하는 것을 허용한다. 사용자는 WP 내의 감시 그룹 중 하나를 선택하고 그것을 주 결과창 내로 드래그(drag)함으로써 (또는 유사한 기법을 사용함으로써) 이를 수행할 것이다. 이는 감시 윈도우(Watch Window: WW)를 형성한다. 이러한 WW는 겉보기나 레이아웃에서 TV의 화면내 화면(picture-in-picture) 기능과 유사하거나 유추될 수 있지만, 몇 가지 측면에서 다르며, 이 경우에 디스플레이된 콘텐츠는 "감시"되고 있는 텔레비젼 채널과는 전혀 다르게 시맨틱(semantic) 요청와 결과를 포함하고 있다는 점에서 가장 현저하게 다르다. 물론, 콘텐츠를 생성하는 근본적인 기법도 상당히 다르다. WW는 전술한 모든 보기 내에서 디스플레이될 수 있다. 그러나, WW가 심층 보기에 있으면, WW의 보기 콘트롤이 디스플레이된다. 다음 콘트롤들이 현재 정의되어 있다.

피닝(pinning) 요청 - 이는 사용자가 감시 그룹 내에 특정 요청을 피닝(pin)하는 것을 허용한다. WW는 오직 피닝된 요청에 대한 새로운 결과를 (주기적으로) 계속하여 디스플레이할 것이며, 현재 요청이 계속하여 피닝된다면 감시 그룹 내에 다른 요청로 나아가지 않을 것이다.

스와핑(swapping) 요청 - 이는 사용자가 현재 디스플레이된 요청을 시맨틱 브라우저 내에 도시되고 있는 주 요청와 스와핑하는 것을 허용한다. 스마트 스타일은 OCX에 대한 방법이 (그 SQML 버퍼에 의해 해쉬(hash)된) 스와핑된 요청을 갖는 임시 요청을 생성하게 한 다음에, 그 요청로 네비게이션(navigation)하면서 또한 (WW 내에) 대신하여 주 요청을 지금 디스플레이하고 있다는 것을 프리젠터에게 통보할 것이다.

정지, 재생, 찾기, 빨리감기, 되감기, 가속 - 이들은 사용자가 "감시 그룹 요청 흐름"을 정지하거나, 재생하거나, 찾거나, 빨리감거나, 되감거나 또는 가속하는 것을 허용한다. 예를 들어, 빨리감기는 현재 디스플레이되고 있는 요청에 선행하는 몇 가지 요청로 진행할 것이다.

결과 콘트롤 - 이는 사용자가 감시 그룹 내의 각각의 요청 내의 결과들을 콘트롤하는 것을 허용한다. 필연적으로 결과들은 흐름(stream) 내의 흐름이며, 이는 사용자가 현재 감시 그룹 내의 현재 요청 내의 결과를 콘트롤하는 것을 허용한다.

자동 디스플레이 모드 - 이는 디스플레이할 결과가 없을 때 자동적으로 WW를 숨기고 새로운 결과가 있을 때 WW를 차차 뚜렷하게 보여줄 것이다. 이런 식으로, 사용자는 새로운 결과가 있을 때 감시 윈도우가 차차 뚜렷하게 보여지는 것을 알면서 스크린 상에서 그/그녀의 부동산의 효용을 극대화할 수 있다. 이러한 특징은 또한 사용자가 개인적이고 시맨틱한 방식으로 정보 상호작용 중에 그/그녀의 관심을 관리하는 것을 허용한다.

도킹(docking), 닫기, 최소화, 최대화 - 이들 특성은 그 명칭이 의미하는 바와 같이 사용자가 감시 윈도우를 도킹하거나, 닫거나, 최소화하거나 또는 최대화하는 것을 허용한다. 도20은 (예를 들어 무선 상의 헤드라인과 같은) 필터링된 스 마트 요청을 디스플레이하는 감시 윈도우를 도시한다. 도20은 (예를 들어 "속보"와 같은) 현재 스마트 요청 제목을 갖는 감시 윈도우의 하나의 예시이다.

7. 감시 리스트 부록

사용자 인터페이스에서, 감시 리스트는 "뉴스 감시(News Watch)"로 명명될 수 있다. 사용자에게 요청, 객체, 키워드, 텍스트, 엔티티 등을 "뉴스 감시"에 추가하거나 "뉴스 감시"로부터 제거할 것이 요청된다. "뉴스 감시"는 신문가판대 감시창으로 보여질 수도 있다. 이는 어떤 사람이 도서관 또는 서점으로 걸어들어갈 때 뉴스-잡지대의 보기와 다르지 않으면서 (감시 리스트에 추가된 객체를 통해, 그리고 이들 객체를 필터로 사용하면서 런타임(runtime)에 의해 동적으로 생성된) 사용자의 요청와 동적으로 생성된 요청들의 공간적으로 배향된 보기를 제공할 것이다.

G. 정보 신경 시스템에 대한 엔티티 규격

1. 서론

엔티티는 정보 신경 시스템의 바람직한 실시예의 매우 강력한 특성이다. 엔티티는 엔티티가 통상적으로 작용하는 방법을 매핑(mapping)하는 컨텍스트상 정의를 사용자가 생성할 것을 허용한다. 엔티티의 예는 다음을 포함한다.

산업-특유의 엔티티도 있다. 예를 들어, 의약품에서 엔티티는 약, 약 상호 작용 논쟁, 특허, FDA 임상 실험 등을 포함할 수 있다. 필연적으로, 엔티티는 스마트 컨텍스트상 객체인 시맨틱 엔벌로프(semantic envelope)이다. 엔티티는 다른 스마트 객체과 마찬가지로 드래그 앤드 드롭(drag and drop)될 수 있다. 그러나, 엔티티는 SQML에 의해 묘사되며 SRML에 의해 묘사되지 않는다. (즉 엔티티는 훨씬 귀중한 시맨틱을 가지므로 쿼리 객체이다.) 엔티티는 스마트 요청에 변수로서 포함될 수도 있다.

사용자는 그/그녀의 임무에 따라 엔티티를 생성한다. 바람직한 실시예에서 엔티티는 다음 정보를 적어도 포함한다. (또 다른 실시예에서 엔티티는 더 많은 또는 더 적은 정보를 포함할 수 있다.)

1. 명칭/설명 - 엔티티에 대해 적합하게 설명된 명칭

2. 엔티티의 카테고리 - 표준 교차-산업 분류(standard cross-industry taxomonies) 또는 수직적/회사-특유의 분류(vertical/company-specific taxonomies)에 따름

3. 컨텍스트상 리소스 - 이들은 키워드, 국지적인 문서, 인터넷 문서 또는 (사람과 같은) 스마트 객체를 포함할 수 있다.

엔티티는 시맨틱 브라우저 내에 개방될 수 있고, (예를 들어 내 프로젝트(my project)에 대한 헤드라인과 같이) 스마트 요청을 위한 변수로서 네비게이션을 위한 피벗(pivot)으로 사용될 수도 있고, 복사되고 붙여질 수 있으며, 스마트 렌즈를 사용하여 사용될 수 있고, 스마트 스타일을 사용하여 시각화될 수 있고, 내재적인 경보를 위한 기준으로 사용될 수 있고, .ENT 문서로서 저장될 수 있고, 이메일링되고 공유될 수 있다. 즉, 엔티티는 1등급 스마트 객체이다.

시맨틱 런타임 클라이언트는 엔티티를 지칭하는 새로운 귀중한 SQML을 생성하기 위해 엔티티의 귀중한 메타데이타를 상관적인 요청의 주제에 첨부함으로써 SQML을 동적으로 생성한다.

엔티티는 바람직하게는 다른 중요한 특성도 갖는다.

1. 토픽에 관하여, 엔티티는 (엄밀하게 정의되고 그러한 맥락에서 요청에 대한 사용자의 독특한 컨텍스트에 정확하게 매핑될 수 없는 공공연한 분류에 좌우되거나 배타적으로 제한되지 않으면서) 사용자가 그/그녀의 개인 분류를 생성하는 것을 허용한다. 분류가 갖는 문제는 심지어 같은 조직 내에서조차 모든 사람의 필요성에 적합할 수 있는 분류가 있을 수 없다는 것이다. 컨텍스트는 매우 개인적이며, 엔티티는 사용자가 개인적 분류를 생성하는 것을 허용한다. 예를 들어, 개 소유자 스티브에 의해 소유된 캐쉬미어로 명명된 (박서 종의) 개를 예를 들어 보자. (스피브를 제외한) 다른 모든 사람들에게, 캐쉬미어는 (분류에 따라) 다음과 같이 표현될 수 있다.

생물

동물

포유류

개

복서

캐쉬미어

그러나, 스티브에게 캐쉬미어는 다음과 같다.

내의 사랑하는 것들

내 애완동물

캐쉬미어

그러나, 스티브의 수의사에게 캐쉬미어는 다음과 같다.

내 클라이언트

내 개

건강한 내 개

캐쉬미어

캐쉬미어를 "정의"하기 위해 분류가 (독자적으로) 사용되면, 세 개의 분류 중 어느 것도 일반인, 스티브 및 스티브의 수의사를 만족시키지 못할 것이다. 한편 엔티티와 관련하여 스티브는 "캐쉬미어가 그에게 의미하는 것"에 기반하여 "캐쉬미어" 엔티티를 생성할 수 있다. 그런 다음, 모든 다른 사람들이 동일한 것을 수행할 수 있다. 스티브의 수의사도 그렇게 할 수 있다. 그러므로, 엔티티는 넓은 분류의 연장일 수 있는 개인 토픽을 생성할 능력을 사용자에게 부여할 것이다.

다른 예로서, 큰 제약 회사에 근무하는 의약물 연구원이 ("유전자 프로젝트(gene project)"라고 명명된) 유전체에 대한 새로운 일급 비밀 프로젝트에 대해 일하고 있을 수 있다. "유전자 프로젝트"는 내부 프로젝트이므로, 이러한 시맨틱 브라우저를 사용하여 사용될 수 있는 공공 분류에 내 발명의 바람직한 실시예가 존재하지 않을 것 같다. 그러나, 연구원은 "유전자 프로젝트"로 명명되고 프로젝트로 타이핑된 엔티티를 생성할 수 있고, 그런 다음 (넓은 분류에 존재하는) 유전체에 엔티티를 범위 설정한 다음에 (앤드(AND) 연산자를 사용하여) 키워드 숙어 "유전자 프로젝트"를 사용하여 엔티티도 한정함으로써 엔티티를 초기화할 수 있다. 필연적으로, 이는 숙어"유전자 프로젝트"를 갖는 유전체에 대한 모든 것으로서 "유전자 프로젝트"를 한정하는 것과 유사하다. 이는 (단어 "프로젝트"를 함유하지만 유전체와 전혀 상관없는 결과를 돌려줄 수 있는) 키워드 "유전자 프로젝트"를 단순히 사용하는 것 이상으로 훨씬 까다로운 컨텍스트를 부과할 것이다. 유전체에 범위 설정되지만 "유전자 프로젝트"도 확장하는 개인적인 토픽 "유전자 프로젝트"를 특정 한정사(qualifier)를 사용하여 한정함으로써, 연구원은 지금 훨씬 더 정확하고 개인적인 컨텍스트를 갖는다. 그런 다음, (예를 들어 "유전자 프로젝트에 대한 전문가"와 같은) 요청을 생성하기 위해 엔티티가 드래그 앤드 드롭되고, 복사되며, 붙여질 수 있다. 런타임 내에, 서버측 시맨틱 쿼리 프로세서는 (SQML을 시맨틱 네트워크에 매핑함으로써) 이를 "카테고리 유전체에 속하면서 숙어 "유전자 프로젝 트"도 포함하는 임의의 정보에 대한 전문가"로 해석할 것이다.

2. 공공 분류는 매우 정적이지만 정기적으로 갱신되지 않지만, 엔티티는 또한 사용자가 동적 분류를 생성하는 것도 허용한다. 엔티티를 사용하여, 사용자는 그/그녀의 개인 분류를 동적으로 그리고 생각의 속도로 "확장"할 수 있다. 지식은 생각의 속도로 전달된다. 엔티티는 사용자가 그/그녀의 심리 또는 생각 흐름과 동일한 속도 및 활력으로 컨텍스트를 생성하는 것을 허용한다. 이는 매우 중요하다. 예를 들어, 사용자는 새롭게 스케줄링된 미팅, 방금 알게된 회의, 새로운 고객, 새롭게 알게된 경쟁자 등에 대한 엔티티 모두를 생각의 속도로 생성할 수 있다. 분류는 이를 허용하지 않는다.

3. 분류는 토픽이 컨텍스트의 유일한 리소스라고 가정한다. 엔티티를 사용하여, 사용자는 토픽을 포함하지만 토픽에만 제한되지 않는 추상적인 컨텍스트 정의를 생성할 수 있다. 예는 사람, 팀, 사건, 회사등을 포함한다. 엔티티는 (시간에 걸쳐 그리고 이들 엔티티들이 "명성" 또는 "악명"을 얻음에 따라) 분류 내의 토픽으로 결과적으로 "진화"할 수 있지만, "단기간" 내에서 엔티티는 사용자가 무르익은 분류 항목으로 아직 진화되지 않은 (또는 결코 진화될 수 없는) 컨텍스트를 생성하는 것을 허용한다. 예를 들어, Nervana(우리 회사:출원인)는 초기에는 (단지 그 자신과 몇몇 고용인에게만 알려진) 엔티티였지만, 우리가 성장하여 공공의 관심을 받게 됨에 따라 엔티티로서의 우리는 공공 분류 내에서 토픽으로 진화하고 있다. 엔티티를 사용하여, 사용자는 "결과적으로" 토픽이 되는 (Nervana와 같은) 컨텍스트를 기다릴 필요가 없다.

4. 엔티티는 발명자가 "복합 컨텍스트"으로 호칭하는 것을 사용자가 생성하는 것을 허용한다. 이러한 예는 미팅이다. 미팅은 대개 토론의 토픽과 관련된 문서, 프레젠테이션 슬라이드 및/또는 인쇄물과 함께 몇몇 참석자를 포함한다. 정보 신경 시스템 내에서 엔티티를 사용하여, 사용자는 미팅의 시맨틱을 포착하는 "미팅" 컨텍스트를 생성할 수 있다. 생성 엔티티 마법사를 사용하여, 사용자는 엔티티가 미팅인 것을 규정한 다음 시맨틱 필터를 규정할 수 있다. 5명의 참석자와 2 개의 인쇄된 문서와 하나의 프레젠테이션 슬라이드를 갖는 프로젝트 미팅의 예를 고려하자. 미팅의 프리젠터는 미팅에 특별하게 관련되는 지식을 가져오기 위해 엔티티를 생성하는 것을 원할 수 있다. 예를 들어, 그/그녀는 다음 미팅을 스케줄링할 때 또는 미팅에 관련된 특정 활성 아이템을 가져올 때를 결정하기 위해 이를 수행할 것을 원할 수 있다. 엔티티를 생성하기 위해, 사용자는 엔티티 필터 정의에 참석자의 이메일 주소, 인쇄된 문서와 프레젠테이션을 추가할 것이다. 그런 다음, 사용자는 시맨틱 네임스페이스(namespace)/환경 내에 다음에 생성되는 엔티티를 저장할 것이다. 그런 다음, 사용자는 훗날에/나중에 예를 들어 그/그녀가 미팅에 관련되는 새로운 문서를 디스커버리했다면 새로운 또는 제거된 필터(및/또는 새로운 명칭/설명)를 사용하여 엔티티를 편집할 수 있다. 사용자가 엔티티를 드래그 앤드 드롭하고 요청/인자(agent) 내에 엔티티를 포함시킬 때, 시맨틱 브라우저는 그 다음에 개폐를 컴파일하고, 해석을 위해 XML 웹 서비스에도 통과된 서브 쿼리(sub-query)를 사용하여 마스터 SQML 내에 엔티티를 포함한다. 그런 다음 서버측 시맨틱 쿼리 프로세서는 일련의 SQL 서브 쿼리 (또는 동등물)을 구성하고 SQL 서브 쿼 리를 사용하여 순서대로 생성되는 엔티티 서브 쿼리를 사용함으로써 복합 SQML을 처리한다.

사용자는 AND 또는 OR (또는 다른) 연산자를 사용하여 엔티티 필터가 적용되어야 하는 방법을 표시할 수 있다. 예를 들어, 사용자는 미팅이 (시맨틱적으로) 미팅의 참석자와 미팅 중에 인쇄된 문서/슬라이드 논리곱(AND)이라는 것을 나타낼 수 있다. 엔티티가 클라이언트 또는 서버에서 컴파일될 때, SQML 동등물가 사용되어 (원하는 연산자를 갖는) 엔티티를 해석할 수 있다. 이는 매우 강력하다. 이는 사용자가 "프로젝트 미팅"이라 명명된 엔티티를 정의하고 "속보"라 명명된 특정 인자로서 그 엔티티를 드래그 앤드 드롭할 수 있다. 그런 다음, 이는 (엔티티의 식별자로 지칭되는 적절한 SQML과 함께) "프로젝트 미팅에 대한 속보"라 명명된 요청을 생성하며, 그런 다음 해석을 위해 이 요청이 서버로 통과되기 전에 서브 SQML로 컴파일될 것이다. 그런 다음 서버는 (객체를 위해 "이해되는" 것에 기반하여) 엔티티내의 항목에 디폴트 서서술어를 적용한다. 그런 다음, 이러한 특정 예에서, 엔티티의 정의 때문에 서버는 아래로 복귀할 것이다.

모든 참가가에 의해 AND 또는 모든 문서/슬라이드에 시맨틱적으로 또한 관련된 속보(Breaking News BY ALL the participants AND which is ALSO semantically relevant TO ALL the documents/slides)

예를 들어, 이는 오직 미팅의 모든 참석자에 관련되고 미팅 중에 공표될 모든 인쇄물에 시맨틱적으로 관련되는 대화/인수(argument)를 반환할 것이다. 이는 사용자가 (이 경우에) 바로 원했던 것이며, 시맨틱 브라우저는 다소 복잡한 쿼리를 필연적으로 구성할 권한을 사용자에게 부여할 것이다.

훨씬 더 복잡한 쿼리도 가능하다. 엔티티는 복잡한 엔티티를 허용하기 위해 다른 엔티티를 포함할 수 있다. 예를 들어, 사람들의 전체 팀이 미팅에 관련되면, 프리젠터는 이들 사람들의 이메일 배포 리스트를 포함하는 엔티티를 생성하길 원할 수도 있다. 이 경우에, 사용자는 배포 리스트를 위한 정보 신경 시스템을 조사할 수 있고 그런 다음에 결과를 엔티티로서 저장한다. 브라우저는 사용자가 엔티티로서 결과를 저장하는 것을 허용하고, 그 결과 타입에 따라 "의미 있는" 디폴트 엔티티 타입을 사용하여 엔티티를 자동적으로 생성할 것이다. 예를 들어, 사용자가 엔티티로서 문서 결과를 저장하면, 시맨틱 브라우저는 "토픽" 엔티티를 생성할 것이다. 사용자가 사람 결과를 엔티티로서 저장하면, 시맨틱 브라우저는 "사람" 엔티티를 생성할 것이다. 사용자가 엔티티로서 이메일 배포 리스트를 저장하면, 시맨틱 브라우저는 "팀" 엔티티를 생성할 것이다.

이 예에서, 사용자는 사람 엔티티로서 사람 결과를 저장할 수 있으며, 그런 다음 프로젝트 미팅 엔티티 내로 그 엔티티를 드래그 앤드 드롭할 수 있다. 미팅 참가자의 이메일 배포 리스트에 매핑된 팀 엔티티는 프로젝트 미팅 엔티티로 드래그 앤드 드롭될 수 있다. 그런 다음 사용자는 엔티티를 포함하는 "프로젝트 미팅에 대한 헤드라인"이라 호칭된 요청을 생성할 수 있다. 그런 다음 시맨틱 쿼리 프로세서는 (올바른 디폴트 서서술어를 사용하여) 이메일 배포 리스트 내의 모든 사람에 의해 미팅중에 공표될 모든 인쇄물에 시맨틱적으로 관련되는 헤드라인을 반환할 것이다. 이와 유사하게 프로젝트 미팅에 관한 일건 서류(가이드)는 미팅에 관 한 모든 의견(bet), 미팅에 관한 최선 의견, 미팅에 관한 전문가 등을 반환할 것이다.

다른 엔티티를 포함하는 이러한 복잡한 엔티티는 참조 무결성을 위한 클라이언트측 시맨틱 일관성 검사자에 의해 검사된다. 즉, 엔티티 A가 엔티티 B를 언급하고 사용자가 엔티티 B를 지우려고 시도하면, 시맨틱 브라우저가 이를 감지하고 엔티티 B가 미해결 참조를 갖고 있다는 것을 사용자에게 신호한다. 그럼에도 불구하고 사용자가 엔티티 B를 삭제하면, 엔티티 A 내의 참조는 (엔티티 B에 대한 임의의 다른 참조와 함께) 제거될 것이다. 이와 달리 다른 실시예에서 사용자가 엔티티와 연관된 조직 내에서 다른 사람들의 허락에 기초하여 동일한 상황에서 엔티티 B를 삭제하는 것을 (통지되는 지 여부를) 금지할 수 있다.

예를 들어, 고용주는 몇몇 회사 내에서 이메일을 사용하여 수행되는 것과 같이 훨씬 더 강력하게 오직 훨씬 잠재적으로 리스크 관리 목적을 위해 고용인의 활동을 모니터할 수 있다. (물론 적절한 정책과 프라이버시 고려가 처리되어야 할 것이다.) 동일한 프로세스가 요청 컬렉션(블렌더), 포트폴리오(엔티티 컬렉션 - 이하 참조)와, 시맨틱 네임스페이스/환경 내의 다른 복잡한 아이템에 (네임스페이스/환경 내에 다른 아이템으로 참조될 수 있는 아이템에) 적용된다.

5. 공공 엔티티는 지식 커뮤니티의 구성원들 사이에 공유될 수도 있다. (요청 또는 지식 커뮤니티 (인자)와 같이) 시맨틱 브라우저 내의 다른 아이템과 같이, 엔티티는 파일로 저장될 수 있다. (그래서 사용자는 나중에 파일을 개방하거나 동료에게 파일을 이메일로 보내거나 중앙 파일 공유 등에 파일을 저장할 수 있다.) 공통 시나리오는 영업에서 법인의 사서가 내부 프로젝트, 미팅, 세미나, 임무 및 다른 중요한 흥미있는 법인 지식 아이템에 매핑되는 엔티티를 생성할 것일 수 있다. 그런 다음, 이들 엔티티들은 파일 공유 또는 (포탈 또는 웹사이트와 같은) 다른 공유 기법으로 또는 지식 커뮤니티(에이전시)로 저장될 것이다. 그런 다음 조직 내의 지식 노동자가 엔티티를 사용할 수 있을 것이다. 엔티티가 갱신될 때마다, 바람직한 실시예에서 사서가 그 컨텍스트를 자동적으로 편집할 수 있고 할 것이며, 사용자는 재충전하거나 새로운 엔티티에 동기화될 수 있다. 엔티티는 또한 그리고 교대로 개인 사용자에 의해 일대일(peer-to-peer) 방식으로 공유될 수 있다. 이는 음악을 위한 법률적인 일대일 파일 공유와 유사하며, 음악 대신에 공유되는 것이 의미 또는 보다 의미 있는 커뮤니케이션을 촉진하기 위한 컨텍스트이다.

2. 포트폴리오 (또는 엔티티 컬렉션)

포트폴리오는 엔티티의 컬렉션을 포함하는 특정 타입의 엔티티이다. 바람직한 실시예에서는, 엔티티가 임의의 크기 또는 구성을 가질 수 있고 포트폴리오가 임의의 종류 또는 개수의 엔티티를 포함할 수 있는 반면 (적어도 학명 또는 전문 용어와의) 혼동과 복잡도를 최소로 하기 위해, 포트폴리오는 다른 포트폴리오를 포함할 것이다. 포트폴리오는 일급 엔티티이고, 이러한 맥락에서 하나의 엔티티의 모든 전술한 특징을 모두 갖는다. 포트폴리오가 스마트 요청 내의 변수로 사용될 때, OR 한정사가 그 포함 엔티티에 (디폴트에 의해) 적용될 것이다. 즉, 포트폴리오(P)가 엔티티 E1 및 E2를 포함하고, "P에 대한 헤드라인"이라 명칭부여된 스마트 요청이 'E1 또는 E2에 대한 헤드라인'으로 처리될 것이다. 사용자는 개인 스마트 요청에 대한 이러한 설정을 (AND 한정사로) 변경할 수 있다.

3. 샘플 시나리오

다시, 아래에 시나리오를 리뷰하면서, 개념적으로 시스템은 보다 관련된 정보를 부분적으로 모을 수 있다는 것을 기억하는 것이 도움될 것이다. 왜냐하면, 시스템은 시스템을 요청하는 사람을 "알고 있고" 사람 또는 그룹이 누구인지와 그들이 아마도 관심을 갖고있는 정보의 종류를 "이해하고 있기" 때문이다. 물론, 엄밀하게 말해서, 시스템은 완전한 인간 감각에서 인지력이 있거나 스스로 자각하지는 않으며, 선행 문장에서 연산 동사는 개념적인 은유 또는 직유이다. 아직도, 연산 또는 결과에서, 시스템은 그 근본적인 시맨틱적으로 통지된 구조 및 실행 때문에 선례가 없는 정도로 이해와 지식을 부분적으로 모방한다.

이러한 점은 극단적으로 단순화된 대비에 의해 설명될 수 있다. 즉 두 명의 매우 다른 사람이 구글과 같은 검색 엔진으로 정확하게 동일한 시간에 정확하게 동일한 검색을 입력했다면, 그들은 정확하게 동일한 결과를 얻을 것이다. 이와 달리, 본 발명의 바람직한 실시예에 따라, 이들 동일한 두 사람이 엔티티를 통해 동일한 요청을 입력했다면, 각각은 각각에 관련되어 맞추어진 다른 결과를 얻을 것이다.

이들 특성의 잠재력의 약간을 이해하기 위해, 시스템 또는 엔티티가 쿼리를 제기하는 사람을 "알고 있는" 반면, (비록 사용자 정보가 항상 공급되고 고려될 수 있다하더라도) 이러한 지식에 대해 엔티티는 그들을 통지하며 그들을 계속하여 일정하게 갱신하고 통지하는 사용자에 따라 다르다는 것을 주목하는 것이 유용하다. 만약 그렇다면, 시스템은 너무 노동 집약적이어서 많은 상황에서 효율적이고 유용하지 않을 수 있을 것이며, 이는 너무 많은 작업을 초래한다. 대신에, 본 출원과 그 모출원을 통해 설명된 바와 같이, 엔티티는 참조에 의해 그리고 때때로 다른 사람에 의해 공급되고, 때때로 파생되고 추론되며, 때때로 다른 요청로부터 컬렉션되는 특성으로부터 시맨틱으로부터 요청자가 누구인지를 "안다."

동작되는 엔티티의 몇 가지 예시적인 시나리오는:

1. 의약품 '특허' 엔티티는 특허의 카테고리, 관련 키워드 및 관련 문서를 포함할 수 있다.

2. CIA 에이전트는 테러리스트를 추적하기 위해 '테러리스트' 엔티티를 생성할 수 있다. 이는 테러리즘에 대한 카테고리, 혐의가 있는 전신환, 혐의가 있는 무기 판매, 비밀 분류된 문서, 키워드 및 정보 커뮤니티 내에 테러리즘 전문가를 포함할 수 있다.

3. 어제 미팅에 대한 모든 속보를 찾는다.

4. 내 경쟁자 모두에 대한 헤드라인을 찾는다. (이는 경쟁자 엔티티를 생성한 다음 OR 한정사를 각각의 설명과 함께 사용하여 변수로서 엔티티를 사용하여 스마트 요청을 찾음으로써 수행된다.)

5. 내 투자 포트폴리오 회사에 대한 전문가를 찾는다. (개개의 엔티티를 생성하고, 이들 엔티티를 포함하는 포트폴리오를 생성한 다음, '전문가' 컨텍스트 템플릿(template)을 가지며 포트폴리오를 논쟁으로 사용하는 스마트 요청을 생성한다.

6. 나의 경쟁자에 대한 일건 서류(가이드)을 연다. (개개의 경쟁자 엔티티를 생성하고, 이들 엔티티를 포함하는 포트폴리오를 생성한 다음, '일건 서류' (또는 '가이드' 컨텍스트 템플릿을 가지면서 포트폴리오를 논쟁으로 사용하는 스마트 요청을 생성한다. 도21은 (왼쪽 상에) 시맨틱 브라우저 내에 디스플레이된 엔티티 보기를 도시한다.

H. 정보 신경 시스템에 대한 지식 커뮤니티 브라우징과 가입 규격

개 요

Nervana 시맨틱 브라우저는 사용자가 주어진 프로파일에 대해 지식 커뮤니티(에이전트)에 가입하거나 지식 커뮤니티로부터 탈퇴하는 것이 허용될 것이다. 이들 지식 커뮤니티는 시맨틱 환경에서 프로파일 항목의 하부의 사용자에게 즉시 이용가능하다. 추가적으로, 이들 지식 커뮤니티는 결과들이 동일 프로파일을 사용하여 생성된 임의의 요청에 대해 디스플레이될 때마다 내재적인 경보, 컨텍스트 패널 등을 위한 디폴트에 의해 쿼리될 것이다.

시맨틱 환경은 각각의 프로파일에 대한 가입된 지식 커뮤니티를 나타내는 상태를 포함한다. 클라이언트측 시맨틱 쿼리 프로세서(semantic query processor: SQP)는 주어진 프로파일의 요청에 대한 결과로부터 시작하는 동적 요청을 위한 이러한 정보를 사용한다. (SQP는 프로파일용 지식 커뮤니티를 위한 시맨틱 런타임 클라이언트를 요청할 것이다.)

도22a 및 도22b는 지식 커뮤니티 가입과 탈퇴를 위한 사용자 인터페이스를 도시한다. 대화 상자는 사용자가 모든, 새로운, 가입된, 제안된, 탈퇴된 커뮤니티 를 보기 위해 프로파일에 의해, 산업 및 관심 영역에 의해, 키워드에 의해, 공표 관점(모든 공표 관점, 국부 영역 네트웍, 기업 디렉토리 및 광역 지식 커뮤니티 디렉토리)에 의해, 그리고 런타임(모두, 오늘, 어제, 이번 주 및 다음 주)에 의해 필터링하는 것을 허용하는 콤보 상자를 갖는다. 시맨틱 런타임 클라이언트는 필터를 사용하여 (각각의 공표 관점에 대한) 공표 관점 단말 청취자를 쿼리한다. 그런 다음 클라이언트는 결과를 모으고 결과를 결과창 내에 디스플레이한다. 사용자는 또한 콤보 상자를 통해 결과창 내에 각각의 지식 커뮤니티의 카테고리를 볼 수 있다. 도20b는 지식 커뮤니티 대화 상자의 저부를 도시한다.

I. 지식 신경 시스템에 대한 클라이언트측 시맨틱 쿼리 문서 규격

1. 시맨틱 쿼리 마크업 언어(Semantic Query Markup Language: SQML) 개요

현재 바람직한 실시예에서, Nervana 시맨틱 DHTML 거동은 클라이언트의 관점으로부터 모든 것을 쿼리 문서로서 이해하는 인터넷 익스플로러 DHTML 거동이다. 클라이언트는 워드 프로세서가 '텍스츄얼 및 복잡한 문서(textual and compound doctunents'를 여는 방법과 유사한 방식으로 '쿼리 문서'를 연다. Nervana 클라이언트는 주로 Nervana 시맨틱 쿼리 문서를 처리하고 결과를 제공할 책임이 있다. Nervana 시맨틱 쿼리 문서는 Nervana 시맨틱 쿼리 마크업 언어(Semantic Query Markup Language: SQML)의 형태로 표현되고 저장된다. 이는 "시맨틱 파일 포맷"과 유사하다.

바람직한 실시예에서, SQML 시맨틱 파일 포맷은 다음을 포함한다.

헤드 - HTML 경우와 같이 '헤드' 태그는 문서를 설명하는 태그를 포함한 다.

명칭 - 문서 명칭

코멘트 - 문서의 코멘트

사용자명 - 문서 생성자의 사용자명

시스템 명칭 - 문서가 생성된 장치의 시스템 명칭

주제 - 문서의 주제

생성자 - 문서의 생성자

회사 - 문서가 생성된 회사

요청 타입 - 이는 문서 타입을 나타낸다. 그것은 (하나 이상의 정보 커뮤니티 웹 서비스에 대한 요청을 나타내는) "스마트 요청" 또는 (하나 이상의 국부 또는 네트워크 리소스에 대한 요청을 나타내는) "덤(dumb) 요청"일 수 있다.

객체 타입 - 이는 쿼리에 의해 반환된 객체의 타입을 완전하게 한정한다.

URI - 문서의 위치

생성 시간 - 문서의 생성 시간

마지막 수정 시간 - 문서의 마지막 수정 시간

마지막 접근 시간 - 문서의 마지막 접근 시간

속성 - 문서의 속성, 있는 경우에

교정 횟수 - 문서의 교정 횟수

언어 - 문서의 언어

버전 - 이는 쿼리의 버전을 나타낸다. 이는 웹 서비스의 시맨틱 쿼리 프 로세서가 버전된(versioned) 결과를 반환하는 것을 허용한다. 예를 들어, 브라우저의 한 버전은 쿼리의 V1을 사용할 수 있고 또 다른 버전은 V2를 사용할 수 있다. 이는 웹 서비스가 (예를 들어 에어전트를 위한) 리소스 수준에서 그리고 링크 수준에서 후방으로의 호환성을 제공하는 것을 허용한다.

표적 - 이는 쿼리 문서가 표적으로 하는 정보 커뮤니티 웹 서비스의 명칭과 URL을 나타낸다.

타입 - 이는 표적의 타입을 나타낸다. 이는 태그가 실제 웹 서비스 표적을 나타내는 보조 태그(sub-tag) 포함하는 "표적 항목(targetentries)"이거나 또는 쿼리 프로세서가 모든 가입된 정보 커뮤니티를 사용하는 "모든 가입된 표적(allsuballsubscribedtargets)"일 수 있다.

카테고리 - 이는 쿼리 문서가 참조하는 카테고리 URL의 리스트를 나타낸다. 각각의 "카테고리" 항목은 카테고리가 출현하게 되는 지식 도메인 서버(Knowledge Domain Server: KDS)의 URL을 나타낸다.

타입 - 이는 카테고리의 타입을 나타낸다. 이는 보조 태그가 카테고리 항목의 리스트를 참조하는 "카테고리 항목(categoryentries)", 모든 카테고리가 정보 커뮤니티 웹 서비스로부터 요청되는 "모든 카테고리(allcategories)", 또는 쿼리 프로세서가 사용자의 즐겨찾는 카테고리를 모은 다음 이들 카테고리를 포함하는 컴파일된 SQML을 생성하는 (그런 다음 이렇게 컴파일된 SQML은 서버로 보내짐) "나의 즐겨찾기 카테고리(myfavoritecategories)"일 수 있다.

쿼리 - 이는 쿼리 문서의 모든 주 쿼리 항목에 대한 모 태그이다.

리소스 - '덤' 리소스에 대한 참조가 쿼리된다. 예시는 파일 경로, URL, 캐쉬 항목 식별자 등을 포함한다. 이들은 해석자(interpreter)에 의해 실제 리소스 관리자 구성요소로 매핑될 것이다.

타입 - 네임스페이스를 사용하여 한정된 리소스 참조의 타입. 정의된 리소스 참조 타입의 예시는, nervana:url (이는 리소스 참조가 잘 형성된 표준 인터넷 URL이거나 'agent://...'와 같은 커스텀 Nervana URL인 것을 나타낸다), nervana:filepath (이는 리소스 참조가 파일 시스템 상의 파일 또는 디렉토리에 대한 경로임을 나타낸다) 및 nervana:namespaceref (이는 리소스가 클라이언트 시맨틱 네임스페이스(namespace)으로부터 출현하는 것을 나타낸다)이다.

Uri - 이는 리소스의 유니버셜 리소스 식별자(universal resource identifier)를 나타낸다. 경로 및 인터넷 URL의 경우에는, 이는 URL 자신을 나타낸다. 네임스페이스 쿼리의 경우에는, 이는 항목의 GUID 식별자를 나타낸다.

Mid - 이는 문서의 메타데이타 부분에 리소스를 매핑하는 SQML 해석자에 의해 사용되는 메타데이타 식별자를 나타낸다. 메타데이타는 메타데이타 부분 내에 동일 식별자에 매핑된다.

Args - 이는 리소스 식별자의 인수(argument)를 나타낸다.

링크 - 이는 (오직 "표적"을 위한) 시맨틱 링크에 대한 참조를 나타낸다.

타입 - 이는 링크의 타입을 나타낸다. 이는 링크가 명시적인 항목임을 나타내는 "링크 항목(linkentries)"일 수 있다.

링크 항목(LinkEntries) - 이는 링크 항목의 상세 내역을 나타낸다.

서서술어(Predicate) - 이는 링크의 서서술어의 타입을 나타낸다. 예를 들어, 서서술어 "nervana:relevantto"는 쿼리가 "객체 O에 관련된 리소스 R로부터 모든 객체는 반환"임을 나타낸다. R과 O는 각각 특정된 리소스와 객체이다. 서서술어의 다른 예시는 nervana:reportsto, nervana:teammateof, nervana:from, nervana:to, nervana:cc, nervana:bcc, nervana:attachedto, nervana:sentby, nervana:sentto, nervana:postedon, nervana:containstext 등을 나타낸다.

타입 - 이는 '링크' 태그 내의 객체 참조 표시의 타입을 나타낸다. 예시는 xml:string, xml:integer와 같은 표준 XML 데이타 타입, 동일한 Nervana 동등물, ('오늘' 및 '내일'과 같이 객체 참조로 참조될 수 있는) nervana:datetimeref와 같은 커스텀 Nervana 타입 및 Nervana가 시맨틱 XML 객체로서 처리할 수 있는 객체를 참조하는 Nervana URL (object:// 등) 또는 모든 표준 인터넷 URL (HTTP, FTP 등)을 포함한다.

메타데이타 - 이는 메타데이타 항목에 대한 참조를 포함한다.

메타데이타 항목(MetadataEntry) - 이는 메타데이타 항목의 상세 내역을 나타낸다.

Mid - 이는 메타데이타 식별자(GUID)를 나타낸다.

값 - 이는 메타데이타 자체를 나타낸다.

예시: (정보 또는 컨텍스트 기반의) 문서

＜?xml version="1.0" encoding="utf-8"?＞

＜sqml＞

＜head

requesttype="smart request"

objecttype="context＼headlines"

uri="c:＼foo's＼bar.pdf"

creationtime="foo"

lastmodifiedtime="foo"

lastaccessedtime="foo"

attributes="0"

revisionnumber="0"

language="foo"

version="foo"/＞

＜title＞foo＜/title＞

＜comments＞foo＜/comments＞

＜usename＞foo＜/usename＞

＜systemname＞foo＜/systemname＞

＜subject＞foo＜/subject＞

＜creator＞foo＜/creator＞

＜company＞foo＜/company＞

＜targets＞

＜target

name="Marketing"

reftype="uri"

ref="kisp://marketing/default.wsdl"

/＞

＜target

name="Research"

reftype="uri"

ref="kisp://research/default.wsdl"

/＞

＜/targets＞

＜categories＞

＜category

name="reuters＼pharmaceuticals＼biotechnology"

reftype="uri"

ref="kdsp://reuters.com/categories.wsdl?id=45"

/＞

＜category

name="reuters＼pharmaceuticals＼life~sciences"

reftype="uri"

ref="kdsp://reuters.com/categories.wsdl?id=57"

/＞

＜/categories＞

/＞

＜resources＞

＜resource

name="foo"

type="information＼documents＼general document"

reftype="nervana:filepath"

ref="file://c:＼bar.doc"

mid="7886e4aO-55d9-45ac-aO84-97adc6fffdOf"

args=""

/＞

＜resource

name="foo"

type="information＼all information"

reftype="nervana:url"

ref="file://c:＼bar.doc"

mid="Olfc64a3-cO68-4339-bc97-17e5ff37e93f"

args=""

/＞

＜resource

name="foo"

type="information＼all information"

reftype="nervana:folderpath"

ref="file://c:＼"

mid="f8cc39c3-e4fO-4a29-be2a-d2faf36eb3aO"

args="includesubfolders=true"

/＞

＜resource

name="foo"

type="information＼documents＼general document"

reftype="nervana:url"

ref="http://www.bar.com/doc.htm"

mid="f8cc39c3-e4fO-4a29-be2a-d2faf36eb3aO"

args=""

/＞

＜resource

name="foo"

type="information＼documents＼general document"

reftype="nervana:url"

ref="ftp://gate.com/doc.txt"

mid="f8cc39c3-e4fO-4a29-be2a-d2faf36eb3aO"

args=""

/＞

＜resource

name="foo"

type="information＼documents＼general document"

reftype="nervana:filepath" r

ref="file://＼＼servers＼server＼file.pdf"

mid="lb870a25-4e98-45d8-a444-fO283a495357"

args=""

/＞

＜resource

name="foo"

type="information＼documents＼text document"

reftype="nervana:text"

ref=""

mid="7886e4aO-55d9-45ac-aO84-97adc6fffdOf"

args=""

/＞

＜resource

name="foo"

type="information＼documents＼general document"

reftype="nervana:cacheentry"

ref="ef9c90ea-282d-46d6-b355-ac8a4fc2f3e5"

mid=""

args=""

/＞

＜resource

name="foo"

type="information＼email＼email message"

reftype="nervana:url"

ref="request://email.all@ibm.com"

mid=""

args=""

/＞

＜resource

name="foo"

type="information＼email＼email annotation"

reftype="nervana:url"

ref="objects://rad.com/agency.asp"

mid=""

args=""

/＞

＜resource

name="foo"

type="information＼documents＼general document"

reftype="nervana:url"

ref="objects://rad.com/agency.asp"

mid=""

args=""

/＞

＜resource

name="foo"

type="information＼documents＼general document"

reftype="nervana:url"

ref="objects://rad.com/agency.asp"

mid=""

args=""

/＞

＜resource

name="foo"

type="information＼documents＼general document"

reftype="nervana:url"

ref="request://documents.all@intel.com"

mid=""

args=""

/＞

＜/resources＞

＜links＞

＜link

operator="and"

predicate="nervana:relatedto"

name="foo"

type="information＼documents＼general document"

reftype="nervana:filepath"

ref="file://c:＼foo.doc"

mid="7886e4a0-55d9-45ac-a084-97adc6fffd0"

args=""

/＞

＜link

operator="and"

predicate="nervana:contains"

name="foo"

type="information＼documents＼general document"

reftype="nervana:text"

ref=""

mid="46ea76cb-1383-4885-af6f-OeOfc6a66896"

args=""

/＞

＜link

operator="and"

predicate="nervana:postedon"

name="foo"

type="types＼datetime"

reftype="nervana:datetimeref"

ref=""

mid="3fa64c3c-4754-4380-91b5-521299036c62"

args=""

/＞

＜link

operator="and"

predicate="nervana:relatedto"

name="foo"

type="information＼documents＼general document"

reftype="nervana:url"

ref="kisp://98@in.com/m.asp"

mid="c2649c39-alc3-4ca8-ae8d-c85cO4372e9a"

args=""

/＞

＜link

operator="and"

predicate="nervana:isofpriority"

name="foo"

type="types＼priority"

reftype="nervana:priority"

ref=""

mid="69bbc048-98c8-4f76-8edf-5a00ce91cl83"

args=""

/＞

＜/links ＞

＜metadata＞

＜metadataentry

mid="7886e4aO-55d9-45ac-aO84-97adc6fffdOf"

reftype="uri"

ref="file://c:＼foo＼bar.pdf"/＞

＜value＞

＜document＞

＜title＞scenario modelling＜/title＞

＜type＞text＜/type＞

＜format＞application/pdf＜/format＞

＜filepath＞c:＼foo＼bar.pdf＜/filepath＞

＜shortfilename＞bar.pdf＜/shortfilename＞

＜creationtime＞foo＜/creationtime＞

＜lastmodifiedtime＞foo＜/lastmodifiedtime＞

＜lastaccessedtime＞foo＜/lastaccessedtime＞

＜attributes＞O＜/attributes＞

＜size＞O＜/size＞

＜subject＞foo＜/subject＞

＜creator＞foo＜/creator＞

＜manager＞foo＜/manager＞

＜company＞foo＜/company＞

＜category＞foo＜/category＞

＜keywords＞foo＜/keywords＞

＜comments＞foo＜/comments＞

＜hlinkbase＞foo＜/hlinkbase＞

＜template＞foo＜/template＞

＜lastsavedby＞foo＜/lastsavedby＞

＜revisionnumber＞O＜/revisionnumber＞

＜totaleditingtime＞foo＜/totaleditingtime＞

＜numpages＞O＜/numpages＞

＜numparagraphs＞O＜/numparagraphs＞

＜numlines＞O＜/numlines＞

＜numwords＞O＜/numwords＞

＜numcharacters＞0＜/numcharacters＞

＜numcharacterswithspaces＞0＜/numcharacterswithspaces＞

＜numbytes＞O＜/numbytes＞

＜language＞foo＜/language＞

＜version＞foo＜/version＞

＜abstract＞foo＜/abstract＞

＜/document＞

＜/value＞

/＞

＜metadataentry

mid="bfcbl2b4-70bb-473a-847c-ebffel87828f"

reftype="uri"

ref="file://c:＼foo＼bar.pdf"/＞

＜value＞

＜email＞

＜title＞scenario modelling＜/title＞

＜type＞text＜/type＞

＜format＞application/pdf＜/format＞

＜filepath＞c:＼foo＼bar.pdf＜/filepath＞

＜shortfilename＞bar.pdf＜/shortfilename＞

＜creationtime＞foo＜/creationtime＞

＜lastmodifiedtime＞foo＜/lastmodifiedtime＞

＜lastaccessedtime＞foo＜/lastaccessedtime＞

＜attributes＞O＜/attributes＞

＜size＞O＜/size＞

＜subject＞foo＜/subject＞

＜creator＞foo＜/creator＞

＜manager＞foo＜/manager＞

＜company＞foo＜/company＞

＜category＞foo＜/category＞

＜keywords＞foo＜/keywords＞

＜comments＞foo＜/comments＞

＜hlinkbase＞foo＜/hlinkbase＞

＜template＞foo＜/template＞

＜lastsavedby＞foo＜/lastsavedby＞

＜revisionnumber＞0＜/revisionnumber＞

＜totaleditingtime＞foo＜/totaleditingtime＞

＜numpages＞O＜/numpages＞

＜numparagraphs＞O＜/numparagraphs＞

＜numlines＞O＜/numlines＞

＜numwords＞0＜/numwords＞

＜numcharacters＞O＜/numcharacters＞

＜numcharacterswithspaces＞0＜/numcharacterswithspaces＞

＜numbytes＞O＜/numbytes＞

＜language＞foo＜/language＞

＜version＞foo＜/version＞

＜abstract＞foo＜/abstract＞

＜/email＞

＜/value＞

/＞

＜/metadata＞

＜/sqml＞

2. SQML 생성

바람직하게는, SQML은 아래의 가능한 몇 가지 방식 중 임의의 하나에 의해 생성된다. 몇 가지 방식은,

스마트 요청을 생성하는 것,

국부적 요청을 생성하는 것,

엔티티를 생성하는 것,

시맨틱 브라우저 내에 하나 이상의 국부적 문서를 여는 것,

드래그 앤드 드롭, 스마트 복사 및 붙여넣기, 내재적인 경보, 컨텍스트 패널/링크 이노베이션(link innovation) 등에 대응하여 (동적으로) 클라이언트에 의한 것이다.

3. SQML 파싱(parsing)

몇 가지 실시예에서 몇 가지 상황에서, 클라이언트 상에 생성되는 SQML은 서버의 XML 웹 서비스에 의해 또는 또 다른 머신 사이트(machine site)에서 실시간으로 원격 소비(remote consumption)를 준비할 수 없다. 이는 SQML이 문서, 엔티티 또는 (시맨틱 환경에서 유일한 식별자에 의해 식별되는) 스마트 요청와 같은 국부적인 컨텍스트를 참조할 때 특히 사실일 것이다. (블렌더(blender)(또는 컬렉션(collection))은 스마트 요청에 대한 참조를 포함한다) 바람직한 실시예에서, 클라이언트는 대개 원격 소비를 준비할 SQML을 생성한다. 바람직하게는, 클라이언트는 문서의 메타데이타 부분 내에 모든 참조를 위한 메타데이타를 캐쉬함으로써 이를 수행한다. 이는 몇 가지 경우에 쿼리가 호출될 때 참조가 지칭하는 리소스 또는 객체가 더 이상 존재할 수 없기 때문에 양호할 수 있다. 예를 들어, 사용자는 새로운 상관적인 요청을 생성하기 위해 인터넷으로부터의 문서를 스마트 요청로 드래그 앤드 드롭할 수 있다. 클라이언트는 링크로부터 (요약을 포함하는) 메타데이타를 추출하고 메타데이타를 SQML 내로 삽입한다. 쿼리의 레졸루션(resolution)이 오직 메타데이타를 사용하기 때문에, 일단 메타데이타가 SQML 문서 내로 삽입되면 쿼리가 소비될 준비가 되어 있다. 그러나, 객체가 참조하는 링크는 사용자가 그 것을 디스커버리한 후에 하루를 존재할 수 없다. 이러한 경우에, 비록 링크가 존재하지 않게 된 후에 사용자가 상관적인 요청을 호출하더라도, 메타데이타는 SQML 내에 이미 캐쉬되었기 때문에 요청은 아직도 작용할 것이다.

클라이언트 SQML 파서(parser)는 SQML 내에 메타데이타의 "느린" 갱신을 수행한다. 요청이 불러내어질(invoke) 때, 그것은 SQML 내의 모든 변수(리소스 등)의 메타데이타를 갱신함으로써, 상관적인 요청을 생성하기 위해 그들이 사용되었으므로 객체가 변화할 수 있는 경우를 다룰 수 있다. 객체가 존재하지 않으면, 클라이언트는 클라이언트가 이미 갖고 있는 메타데이타를 사용한다. 그렇지 않다면, 클라이언트는 메타데이타를 갱신하고 갱신된 메타데이타를 사용한다. 따라서 비록 객체가 삭제된 경우에도, 메타데이타가 출현하는 객체를 여는 것을 사용자가 실제로 시도할 때까지 사용자 경험은 해석되지 않는다.

J. 정보 신경 시스템에 대한 시맨틱 클라이언트측 런타임 콘트롤 API 규격

1. Nervana 시맨틱 런타임 콘트롤 소개 - 개요

바람직한 실시예에서, Nervana 시맨틱 런타임 콘트롤은 Nervana 시맨틱 사용자 경험을 사용하여 시맨틱 데이타를 디스플레이하는 데 사용하기 위한 특성과 방법을 공개하는 액티브엑스(ActiveX) 콘트롤이다. 콘트롤은, (SRML 스키마(schema)를 사용하여) XML 데이타를 가져오고 Nervana 시맨틱 사용자 경험의 요건과 일치하는 DHTML+TIME 또는 SVG 출력을 생성하는 XSLT 스킨(skin)으로부터 주로 호출될 것이다. 필연적으로, 이러한 실시예에서, Nervana 콘트롤은 시맨틱 콘텐츠 구동 방식 사용자 경험을 생성하기 위해 XSLT 스킨이 위치한 상부에 "SDK"을 인캡슐레이 팅(encapsulating)한다. 아래에 리스트된 API는 바람직한 실시예 내의 최종 API 설정에 의해 공개되고 이용될 기능성을 설명한다.

2. Nervana 시맨틱 런타임 콘트롤 API

a. EnumObjectsInNamespacePath

서 론

EnumObjectslnNamespacePath 방법은 네임스페이스(namespace) 경로 내에 객체를 반환한다.

사용 시나리오

(예를 들어 시맨틱 브라우저와 같은) Nervana 클라이언트 애플리케이션 또는 Nervana 스킨은 시맨틱 브라우저 내로부터 네임스페이스를 사용자가 네비게이션하도록 네임스페이스 경로를 여는 이러한 방법을 호출할 것이다.

PROTOTYPE

SCODE

EnumObjectsInNamespacePath(

[in] BSTR Path,

[in] LONG QueryMask,

[out] BSTR *pQueryRequestGuid );

b. CompileSemanticQueryFromBuffer

서 론

CompileSemanticQueryFromBuffer 방법은 SQML 버퍼를 열고 하나 이상의 실행 준비된(execution-ready) SQML 버퍼 내로 그것을 컴파일한다. 예를 들어, 블렌더를 포함하는 SQML 파일은 각각의 블렌더 항목을 대표하는 SQML 버퍼 내로 컴파일될 것이다. 블렌더가 블렌더들을 포함하면, 블렌더들이 풀려질 것이고 SQML 버퍼는 각각 포함된 블렌더에 대해 반환될 것이다. 컴파일된 또는 "실행 준비된" SQML 버퍼는 에이전시에 의해 시맨틱적으로 처리될 수 있는 것이다. 내포(implication)는 다중 에이전시로부터 에이전트를 갖는 블렌더가 각각의 에이전시로부터 적절한 SQML을 사용하여 그 SQML가 버퍼로 컴파일될 것이라는 것이다.

주: 버퍼가 이미 컴파일되었으면, 방법은 S_FALSE를 반환하고 반환 인수가 무시된다.

사용 시나리오

(예를 들어 시맨틱 브라우저와 같은) Nervana 클라이언트 애플리케이션 또는 Nervana 스킨은 SQML 버퍼를 컴파일하고 실행 준비된 생성된 "컴파일된 코드"를 검색하는 이러한 방법을 호출할 것이다. 전형적인 시나리오에서, 애플리케이션 또는 스킨은 SQML 버퍼를 컴파일한 다음에 각각의 개별적인 SQML 쿼리가 앉기를 원하는 프레임 윈도우를 준비한다. 그런 다음, 그것은 OpenSemanticQueryFromBuffer를 호출함으로써 개별적인 SQML 시맨틱 호출을 발부한 다음에 결과가 개별 프레임 내에 디스플레이될 수 있다.

PROTOTYPE

SCODE

CompileSemanticQueryFromBuffer(

[in] BSTR SQMLBuffer,

[in] DWORD Flags,

[out] DWORD *pdwNumCompiledBuffers,

[out] BSTR *pbstrCompiledBuffers );

c. OpenSemanticQueryFromBuffer

서 론

OpenSemanticQueryFromBuffer 방법은 SQML 버퍼를 열고 DOM 상으로 (SRML로 된) XML 결과를 비동기식으로 발포하며, DOM으로부터 Nervana 스킨이 이벤트를 싱크(sink)할 수 있다. 이 실시예에서, SQML은 "컴파일"되어야 하고 실행 준비되어야 한다. SQML이 실행 준비되지 않았다면, 호출이 실패할 것이다. SQML 버퍼를 컴파일하기 위해, CompileSemanticQueryFromBuffer를 호출한다.

사용 시나리오

(예를 들어 시맨틱 브라우저와 같은) Nervana 클라이언트 애플리케이션 또는 Nervana 스킨은 컴파일된 SQML 버퍼를 열기 위해 이러한 방법을 호출할 것이다.

PROTOTYPE

SCODE

OpenSemanticQueryFromBuffer(

[in] BSTR SQMLBuffer,

[in] DWORD Flags,

[out] GUID *pQueryID );

d. GetSemanticQueryBufferFromFile

서 론

GetSemanticQueryBufferFromFile 방법은 SQML 파일을 열고 버퍼 콘텐츠를 반환한다. 그런 다음, 버퍼는 컴파일되고 그리고/또는 열려질 수 있다.

사용 시나리오

(예를 들어 시맨틱 브라우저와 같은) Nervana 클라이언트 애플리케이션 또는 Nervana 스킨은 이 방법을 호출하여 SQML 파일을 버퍼 내로 변환한 후에 처리할 것이다.

PROTOTYPE

SCODE

GetSemanticQueryBufferFromFile(

[in] BSTRSQMLFilePath,

[in] DWORD FileOpenFlags,

[out] BSTR *pbstrSQMLBuffer );

e. GetSemanticQueryBufferFromNamespace

서 론

GetSemanticQueryBufferFromNamespace 방법은 네임스페이스 객체를 열고, 그 SQML 버퍼를 검색한다.

사용 시나리오

(예를 들어 시맨틱 브라우저와 같은) Nervana 클라이언트 애플리케이션 또는 Nervana 스킨은 그것이 네임스페이스 객체의 ID와 경로에 이미 액세스할 때 이 방법을 호출하여 SQML 파일을 열 것이다.

PROTOTYPE

SCODE

GetSemanticQueryBufferFromNamespace(

[in] GUID ObjectID,

[in] BSTR Path,

[out] BSTR *pbstrSQMLBuffer );

f. GetSemanticQueryBufferFromUlIL

서 론

GetSemanticQueryBufferFromURL 방법은 URL을 SQML 버퍼 내에 둘러싸고 버퍼를 반환한다.

사용 시나리오

(예를 들어 시맨틱 브라우저와 같은) Nervana 클라이언트 애플리케이션 또는 Nervana 스킨은 이 방법을 호출하여 임의의 타입의 URL을 SQML로 변환할 것이다. 이는 파일 경로, HTTP URL, FTP URL, ("wsobject://"에 의해 접두된) Nervana 에이전시 객체 URL 또는 ("wsagency://"에 의해 접두된) Nervana 에이전시 URL을 포함할 수 있다.

PROTOTYPE

SCODE

GetSemanticQueryBufferFromURL(

[in] BSTR URL,

[out] BSTR *pBuffer );

g. GetSemanticQueryBufferFromClipboard

서 론

GetSemanticQueryBufferFromClipboard 방법은 클립보드 콘텐츠를 SQML으로 변환하고 버퍼를 반환한다.

사용 시나리오

(예를 들어 시맨틱 브라우저와 같은) Nervana 클라이언트 애플리케이션 또는 Nervana 스킨은 이 방법을 호출하여 클립보드로부터 시맨틱 쿼리를 가져올 것이다. 그런 다음, 애플리케이션은 쿼리 버퍼를 로딩할 수 있다.

PROTOTYPE

SCODE GetSemanticQueryBufferFromClipboard ([out] BSTR *pBuffer );

h. 정지

서 론

정지 방법은 현재 개방 요청을 중지한다.

사용 시나리오

(예를 들어 시맨틱 브라우저와 같은) Nervana 클라이언트 애플리케이션 또는 Nervana 스킨은 이 방법을 호출하여 로딩 요청이 방금 발부된 것을 중지할 것이다.

PROTOTYPE

SCODE Stop ([in] GUID Query );

i. 회복

서 론

회복 방법은 현재 개방 요청을 회복시킨다

사용 시나리오

(예를 들어 시맨틱 브라우저와 같은) Nervana 클라이언트 애플리케이션 또는 Nervana 스킨은 이 방법을 호출하여 현재 로딩된 요청을 회복시킬 것이다.

PROTOTYPE

SCODE Refresh( [in] GUID Query );

j. CreateNamespaceObject

서 론

CreateNamespaceObject 방법은 네임스페이스 객체를 생성하고 그 GUID를 반환한다.

사용 시나리오

(예를 들어 시맨틱 브라우저와 같은) Nervana 클라이언트 애플리케이션 또는 Nervana 스킨은 대개 이 방법을 호출하여 새로운 쿼리 문서가 개방될 때 임시 네임스페이스 객체를 생성할 것이다.

PROTOTYPE

SCODE

CreateNamespaceObject(

[in] BSTR Name,

[in] BSTR Description,

[in] BSTR QueryBuffer,

[in] LONG AgentObjectType,

[in] LONG Attributes,

[in] LONG NamespaceObjectType,

[out] GUID *pObjectID );

k.DeleteNamespaceObject

서 론

DeleteNamespaceObject 방법은 네임스페이스 객체를 삭제한다.

사용 시나리오

(예를 들어 시맨틱 브라우저와 같은) Nervana 클라이언트 애플리케이션 또는 Nervana 스킨은 대개 이 방법을 호출하여 임시 네임스페이스 객체를 삭제할 것이다.

PROTOTYPE

SCODE DeleteNamespaceObject([in] GUID ObjectID );

l. CopyObject

서 론

CopyObject 방법은 사유(proprietary) SQML 클립보드 포맷을 사용하여 SQML 버퍼로서 클립보드에 시맨틱 객체를 복사한다. 그런 다음, 객체가 상관적 시맨틱 쿼리용 에이전트 상에 붙여질 수 있거나 또는 다른 객체 또는 에이전트 상에 렌즈로서 사용될 수 있다.

사용 시나리오

사용자가 객체에 대한 팝업 메뉴를 오프하면서 "복사" 메뉴 옵션을 클릭할 때, Nervana 스킨은 대개 Copyobject 방법을 호출할 것이다.

PROTOTYPE

SCODE CopyObject([in] BSTR ObjectSRML );

m. CanObjectBeAnnotated

서 론

CanObjectBeAnnotated 방법은 주어진 객체가 주석될 수 있는지 여부를 조사한다.

사용 시나리오

Nervana 스킨은 "주석(annotate)" 명령을 나타내는 UI를 도시하는 지를 결정하기 위해 CanObjectBeAnnotated 방법을 전형적으로 호출할 것이다.

PROTOTYPE

SCODE CanObjectBeAnnotated([in] BSTR bstrObjectSRML );

n. AnnotateObject

서 론

AnnotateObject 방법은 현재 설정된 이메일 클라이언트를 불러내고, 이를 초기화하여 객체가 출현하게 되는 에이전시의 이메일 에이전트에 객체의 이메일 주석 을 보낸다.

사용 시나리오

사용자가 객체에 대한 팝업 메뉴를 오프하면서 "주석" 메뉴 옵션을 클릭할 때, Nervana 스킨은 대개 AnnotateObject 방법을 호출할 것이다.

PROTOTYPE

SCODE AnnotateObject([in] BSTR bstrObjectSRML );

o. CanObjectBePublished

서 론

CanObjectBePublished 방법은 주어진 객체가 공표될 수 있는지 여부를 조사한다.

사용 시나리오

Nervana 스킨은 "공표" 명령을 나타내는 UI를 도시하는 지를 결정하기 위해 CanObjectBePublished 방법을 대개 호출한다.

PROTOTYPE

SCODE CanObjectBePublished([in] BSTR bstrObjectSRML );

p. PublishObject

서 론

PublishObject 방법은 현재 설정된 이메일 클라이언트를 불러내고 이를 초기화하여 객체가 출현하게 되는 에이전시의 이메일 에이전트로 객체의 이메일 공표를 보낸다.

사용 시나리오

사용자가 객체에 대한 팝업 메뉴를 오프하면서 "공표" 메뉴 옵션을 클릭할 때, Nervana 스킨은 PublishObject 방법을 전형적으로 호출할 것이다.

PROTOTYPE : SCODE AnnotateObject([in] BSTR bstrObjectSRML );

q. OpenObjectContents

서 론

OpenObjectContents 방법은 적절한 뷰어를 사용하여 객체를 연다. 예를 들어, 이메일 객체가 이메일 클라이언트 내에 열려지고, 브라우저 내에 문서가 열려질 것이다.

사용 시나리오

사용자가 객체에 대한 팝업 메뉴를 오프하면서 "열기" 메뉴 옵션을 클릭할 때 Nervana 스킨은 OpenObjectContents 방법을 전형적으로 호출할 것이다.

PROTOTYPE : SCODE OpenObjectContents([in] BSTR ObjectSRML );

r. SendEmailToPersonObject

서 론

사람 또는 고객 객체로 이메일을 보내기 위해 SendEmailToObject 방법이 호출된다. 이 방법은 이메일 클라이언트를 열고 사람 또는 고객 객체의 이메일 주소를 사용하여 그것을 초기화한다.

사용 시나리오

사용자가 사람 또는 고객 객체에 대한 팝업 메뉴를 오프하면서 "이메일 송 부" 메뉴 옵션을 클릭할 때, Nervana 스킨은 SendEmailToObject 방법은 전형적으로 호출할 것이다.

PROTOTYPE

SCODE SendEmailToObject([in] BSTR ObjectSRML );

s. GetObjectAnnotations

서 론

GetObjectAnnotations 방법이 호출되어 객체가 출현하게 되는 에이전시 상에 객체가 갖는 주석을 가져온다.

사용 시나리오

Nervana 스킨이 객체가 갖는 주석의 제목을 예를 들어 팝업 메뉴 내에 디스플레이하기를 원할 때 또는 윈도우 내에 주석 메타데이타를 디스플레이하기를 원할 때 Nervana 스킨은 GetObjectAnnotations 방법을 전형적으로 호출할 것이다.

PROTOTYPE

SCODE

GetObjectAnnotations(

[in] BSTR ObjectSRML,

[in] LONG QueryMask,

[out] BSTR *pQueryRequestGuid );

t. IsObjectMarkedAsFavorite

서 론

IsObjectMarkedAsFavorite 방법은 객체가 출현하게 되는 에이전시 상에 즐겨찾기로서 객체가 표시되는 지를 조사하기 위해 호출된다.

사용 시나리오

Nervana 스킨은 "즐겨찾기로서 표시(Mark as Favorite)" 또는 "즐겨찾기로서 표시하지 않음(Unmark as Favorite)" 명령을 어떤 UI가 도시하는 지를 결정하기 위해 IsObjectMarkedAsFavorite 방법을 전형적으로 호출할 것이다. 객체가 즐겨찾기로서 표시되지 않을 수 있다면, (예를 들어 객체가 에이전시 상에서 시작되지 않았다면,) 에러 코드 E_INVALIDARG가 반환된다.

PROTOTYPE

SCODE

IsObjectMarkedAsFavorite([in] BSTR ObjectSRML );

u. MarkObjectAsFavorite

서 론

MarkObjectAsFavorite 방법이 호출되어 객체가 출현하게 되는 에이전시 상에 즐겨찾기로서 객체를 표시한다.

사용 시나리오

Nervana 스킨은 사용자가 "즐겨찾기로서 표시" 명령을 클릭할 때 MarkObjectAsFavorite 방법을 전형적으로 호출할 것이다.

PROTOTYPE

SCODE

MarkAsFavorite([in] BSTR ObjectSRML );

v. UnmarkObjectAFavorite

서 론

UnmarkObjectAsFavorite 방법이 호출되어 객체가 출현하게 되는 에이전시 상에 즐겨찾기로서 객체를 표시하지 않는다.

사용 시나리오

Nervana 스킨은 사용자가 "즐겨찾기로서 표시하지 않음" 명령을 클릭할 때 UnmarkObjectAsFavorite 방법을 전형적으로 호출할 것이다.

PROTOTYPE

SCODE

UnmarkAsFavorite([in] BSTR ObjectSRML );

w. IsSmartAgentOnClipboard

서 론

IsSmartAgentOnClipboard 방법이 호출되어 스마트 에이전트가 클립보드로 복사되어 있는 지를 조사한다.

사용 시나리오

Nervana 스킨이 사용자 인터페이스가 "붙여넣기" 아이콘을 디스플레이하도록 토클링할 것을 원할 때 또는 "붙여넣기" 명령이 호출될 때, Nervana 스킨은 IsSmartAgentOnClipboard 방법을 전형적으로 호출할 것이다.

PROTOTYPE

SCODE

IsSmartAgentOnClipboard();

x. GetSmartLensQueryBuffer

서 론

GetSmartLensQueryBuffer 방법이 호출되어 스마트 렌즈의 쿼리 버퍼를 가져온다. 이는 클립보드 상에 존재하는 스마트 에이전트 상에 있고 주어진 객체과 시맨틱적으로 관련되는 객체를 대표하는 쿼리의 SQML을 반환한다.

사용 시나리오

클립보드 상에 존재하는 스마트 에이전트에서 떨어져 스마트 렌즈를 불러내기 위해 사용자가 "스마트 렌즈로서 붙여넣기"를 타격할 때 Nervana 스킨은 GetSmartLensQueryBuffer 방법을 전형적으로 호출할 것이다.

PROTOTYPE

SCODE

GetSmartLensQueryBuffer(

[in] BSTR ObjectSRML,

[in] LONG QueryMask,

[out] BSTR *pQueryRequestGuid );

y. OpenObjectContents

서 론

OpenObjectContents 방법은 적절한 뷰어를 사용하여 객체를 연다.

사용 시나리오

사용자가 객체에 대한 팝업 메뉴를 오프로 하면서 "열기" 메뉴 옵션을 클릭할 때, Nervana 스킨은 OpenObjectContents 방법을 전형적으로 호출할 것이다.

PROTOTYPE

SCODE OpenObjectContents([in] BSTR ObjectSRML );

Part

3. 이메일 콘트롤 API

a. Email_GetFromLinkObjeets

서 론

EmailGetFromLinkObjects 방법이 호출되어 이메일 객체가 출현하게 되는 에이전시로부터 이메일 객체에 대한 "From" 링크용 메타데이타를 가져온다.

사용 시나리오

Nervana 스킨이 이메일 객체로부터 "From" 리스트로 네비게이션하길 원할 때 또는 "From" 리스트 내에 사람의 명칭을 사용하여 팝업 메뉴를 디스플레이하길 원할 때, Nervana 스킨은 Email_GetFromLinkObjects 방법을 전형적으로 호출할 것이다.

PROTOTYPE

SCODE

Email_GetFromLinkObjects(

[in] BSTR EmailObjectSRML,

[in] LONG QueryMask,

[out] BSTR *pQueryRequestGuid );

b.Email_GetToLinkObjects

서 론

Email_GetFromLinkObjects 방법이 호출되어 이메일 객체가 출현하게 되는 에이전시로부터 이메일 객체에 대한 "To" 링크용 메타데이타를 가져온다.

사용 시나리오

Nervana 스킨이 이메일 객체로부터 "To" 리스트로 네비게이션하길 원하거나 또는 "To" 리스트 내에 사람의 명칭을 사용하여 팝업 메뉴를 디스플레이할 것을 원할 때, Nervana 스킨은 Email_GetToLinkObjects 방법을 전형적으로 호출할 것이다.

PROTOTYPE

SCODE

Email_GetToLinkObjects(

[in] BSTR EmailObjectSRML,

[in] LONG QueryMask,

[out] BSTR *pQueryRequestGuid );

c. Email_GetCcLinkObjects

서 론

Email_GetCcLinkObjects 방법이 호출되어 이메일 객체가 출현하게 되는 이메일 에이전시로부터 이메일 객체에 대한 "CC" 링크용 메타데이타를 가져온다.

사용 시나리오

Nervana 스킨이 이메일 객체로부터 "CC" 리스트로 네비게이션하길 원하거나 또는 "CC" 리스트 내에 사람의 명칭을 사용하여 팝업 메뉴를 디스플레이하길 원할 때, Nervana 스킨은 Email_GetCcLinkObjects 방법을 전형적으로 호출할 것이다.

PROTOTYPE

SCODE

Email_GetCcLinkObjects(

[in] BSTR EmailObjectSRML,

[in] LONG QueryMask,

[out] BSTR *pQueryRequestGuid );

d. Email_GetBccLinkObjects

서 론

Email_GetBccLinkObjects 방법이 호출되어 이메일 객체가 출현하게 되는 에이전시로부터 이메일 객체에 대한 "BCC" 링크용 메타데이타를 가져온다.

사용 시나리오

Nervana 스킨이 이메일 객체로부터 "BCC" 리스트로 네비게이션하길 원할 때 또는 "BCC" 리스트 내에 사람의 명칭을 사용하여 팝업 메뉴를 디스플레이하길 원할 때, Nervana 스킨은 Email_GetBccLinkObjects 방법을 전형적으로 호출할 것이다.

PROTOTYPE

SCODE

Email_GetBccLinkObjects(

[in] BSTR EmailObjectSRML,

[in] LONG QueryMask,

[out] BSTR *pQueryRequestGuid );

e. Email_GetAttachmentLinkobjects

서 론

Email_GetAttachmentLinkObjects 방법이 호출되어 이메일 객체가 출현하게 되는 에이전시로부터 이메일 객체에 대한 "첨부(Attachment)" 링크용 메타데이타를 가져온다.

사용 시나리오

Nervana 스킨이 이메일 객체로부터 "첨부" 링크로 네비게이션하길 원할 때 또는 "첨부" 리스트 내에 첨부의 제목을 사용하여 팝업 메뉴를 디스플레이하길 원할 때, Nervana 스킨은 Email_GetAttachmentLinkObjects 방법을 전형적으로 호출할 것이다.

PROTOTYPE

SCODE

Email_GetAttachmentLinkObjects(

[in] BSTR EmailObjectSRML,

[in] LONG QueryMask,

[out] BSTR *pQueryRequestGuid );

4. 사람 콘트롤 API

a. Person_GetDirectReports

서 론

Person_GetDirectReports 방법이 호출되어 사람 객체가 출현하게 되는 에지전시로부터 사람 객체에 대한 "Direct Reports" 링크용 메타데이타를 가져온다.

사용 시나리오

Nervana 스킨이 사람 객체로부터 "Direct Reports"로 네비게이션하길 원할 때 또는 "Direct Reports" 리스트 내에 직접 보고의 이름을 사용하여 팝업 메뉴를 디스플레이하길 원할 때, Nervana 스킨은 Person_GetDirectReports 방법을 전형적으로 호출할 것이다.

PROTOTYPE

SCODE

Person_GetDirectReports(

[in] BSTR EmailObjectSRML,

[in] LONG QueryMask,

[out] BSTR *pQueryRequestGuid );

b. Person_GetDistributionLists

서 론

Person_GetDistributionLists 방법이 호출되어 사람 객체가 출현하게 되는 에이전시로부터 사람 객체에 대한 "배포 리스트의 구성원(Member of Distribution Lists)" 링크용 메타데이타를 가져온다.

사용 시나리오

Nervana 스킨이 사람 객체로부터 "배포 리스트의 구성원" 링크로 네비게이션할 것을 원할 때 또는 사람이 구성원인 배포 리스트의 명칭을 사용하여 팝업 메뉴를 디스플레이하길 원할 때, Nervana 스킨은 Person_GetDistributionLists 방법을 전형적으로 호출할 것이다.

PROTOTYPE

SCODE

Person_GetDistributionLists(

[in] BSTR PersonObjectSRML,

[in] LONG QueryMask,

[out] BSTR *pQueryRequestGuid );

c. Person_GetInfoAuthored

서 론

Person_GetInfoAuthored 방법이 호출되어 사람 객체가 출현하게 되는 에이전시로부터 사람 객체에 대한 "사람에 의해 저술된 정보(Info Authored by Person)" 링크용 메타데이타를 가져온다.

사용 시나리오

Nervana 스킨이 사람 객체로부터 "사람에 의해 저술된 정보" 링크로 네비게이션하길 원할 때 또는 그 사람이 저술한 빠르게 알려져야할(time-critical) 또는 최근 정보를 사용하여 미리보기 윈도우를 디스플레이하길 원할 때, Nervana 스킨은 Person_GetInfoAuthored 방법을 대개 호출한다.

PROTOTYPE

SCODE

Person_GetInfoAuthored(

[in] BSTR PersonObjectSRML,

[in] BOOL SemanticQuery,

[in] LONG QueryMask,

[out] BSTR *pQueryRequestGuid );

d.Person_GetInfoAnnotated

서 론

Person_GetlnfoAnnotated 방법이 호출되어 사람 객체가 출현하게 되는 에이전시로부터 사람 객체에 대한 "사람에 의해 주석된 정보(Info Annotated byPerson)" 링크용 메타데이타를 가져온다.

사용 시나리오

Nervana 스킨이 사람 객체로부터 "사람에 의해 주석된 정보" 링트로 네비게이션하길 원할 때 또는 사람이 주석한 주요 시간 또는 최근 정보를 사용하여 미리보기 윈도우을 디스플레이하길 원할 때, Nervana 스킨은 Person_GetInfoAnnotated 방법을 전형적으로 호출할 것이다.

PROTOTYPE

SCODE

Person_GetInfoAnnotated(

[in] BSTR PersonObjectSRML,

[in] LONG QueryMask,

[out] BSTR *pQueryRequestGuid );

e. Person_GetAnnotationsPosted

서 론

Person_GetAnnotationsPosted 방법이 호출되어 사람 객체가 출현하게 되는 에이전시로부터 사람 객체에 대한 "사람에 의해 발송된 주석(Annotations Posted by Person)" 링크용 메타데이타를 가져온다.

사용 시나리오

Nervana 스킨이 사람 객체로부터 "사람에 의해 발송된 주석" 링크로 네비게이션할 것을 원할 때 또는 사람이 발송한 주요 시간 또는 최근 주석을 사용하여 미리보기 윈도우를 디스플레이할 것을 원할 때, Nervana 스킨은 Person_GetAnnotationsPosted 방법을 대개 호출한다.

PROTOTYPE

SCODE

Person_GetAnnotationsPosted(

[in] BSTR PersonObjectSRML,

[in] LONG QueryMask,

[out] BSTR *pQueryRequestGuid );

f. Person_SendEmailTo

서 론

Person_SendEmailTo 방법이 호출되어 사람 또는 고객 객체로 이메일을 보낸다. 이 방법은 이메일 클라이언트를 열고 사람 또는 고객 객체의 이메일 주소를 사용하여 이메일 클라이언트를 초기화한다.

사용 시나리오

사용자가 사람 또는 고객 객체에 대한 팝업 메뉴를 오프하면서 "이메일 송부(Send Email)" 메뉴 옵션을 클릭할 때, Nervana 스킨은 Person_SendEmailTo 방법을 대개 호출한다.

PROTOTYPE

SCODE Person_SendEmailTo(

[in] BSTR ObjectSRML) ;

5. 시스템 콘트롤 이벤트

a. 이벤트: OnBeforeQuery

서 론

콘트롤이 현재 시맨틱 요청와 상호 관련되는 리소스에 쿼리를 발부하기 전에, OnBeforeQuery 이벤트가 개시된다.

사용 시나리오

(예를 들어 시맨틱 브라우저와 같은) Nervana 클라이언트 애플리케이션 또는 Nervana 스킨이 쿼리가 발부되기 전에 쿼리 또는 캐쉬 상태를 취소할 것을 원하면, 이 이벤트가 생략될 것이다.

PROTOTYPE

VOID

OnBeforeQuery(

[in] GUID QueryID,

[in] BSTR QueryBuffer,

[in] DWORD QueryMask,

[in] DWORD Flags,

[out] BOOL *Cancel );

b. 이벤트: OnQueryBegin

서 론

콘트롤이 현재 시맨틱 요청와 상호 관련된 리소스에 제1 쿼리를 발부할 때, OnQueryBegin 이벤트가 개시된다.

사용 시나리오

(예를 들어 시맨틱 브라우저와 같은) Nervana 클라이언트 애플리케이션 또는 Nervana 스킨이 쿼리가 진행되고 있을 때 상태를 저장하거나 상태 정보를 디스플레이하길 원하면 이 이벤트가 생략될 것이다.

PROTOTYPE

VOID

OnQueryBegin([in] GUID ObjectID);

c. 이벤트: OnQueryComplete

서 론

콘트롤이 현재 시맨틱 요청와 상호 관련되는 리소스에 쿼리를 발부하기 전에, OnQueryComplete 이벤트가 개시된다.

사용 시나리오

(예를 들어 시맨틱 브라우저와 같은) Nervana 클라이언트 애플리케이션 또는 Nervana 스킨이 쿼리가 발부되기 전에 쿼리 또는 캐쉬 상태를 취소할 것을 원하면, 이 이벤트가 생략될 것이다.

PROTOTYPE

VOID

OnQueryComplete([in] GUID Query );

d. 이벤트: OnQueryResultsAvailable

서 론

비동기 방법 호출의 이용 가능한 결과가 있을 때, OnQueryResultsAvailable 이벤트가 개시된다. 이 이벤트는 요청 GUID를 나타내며, 이를 통해 발신자는 응답을 생성한 특정 방법 호출을 고유하게 식별할 수 있다.

사용 시나리오

(예를 들어 시맨틱 브라우저와 같은) Nervana 클라이언트 애플리케이션 또는 Nervana 스킨은 콘트롤에 대한 방법 호출의 응답을 받기 위해 이 이벤트를 생략할 것이다.

PROTOTYPE

VOID

OnQueryResultsAvailable(

[in] GUID QueryID,

[in] SCODE QueryResult,

[in] BSTR Results,

[in] DWORD NumResults,

[in] DWORD QueryMask,

[in] VARIANT ResultsParam );

e. 부록 A

쿼리 마스크 값

#define QM_RESULTS 0x01

#define QM_RESULTCOUNT 0x02

#define QM_NEWRESULTS 0x04

#define QM_NEWRESULTCOUNT 0x08

#define QM_DEFAULT (QM_RESULTS)

Example:

Person_GetInfoAuthored(

PersonObjectSRML,

QM_RESULTS｜QM_RESULTCOUNT,

＆QueryRequestGuid );

K. 정보 신경 시스템용 보안 규격

1. 허가

서 론

'사람' DSA는 LDAP 디렉토리 URL 및 그룹 명칭을 사용하여 초기화될 것이다. '사용자' DSA도 LDAP 디렉토리 URL 및 그룹 명칭을 사용하여 초기화될 것이다. 대개, '사용자'는 '사람'의 부분집합일 것이다. 예를 들어, 의약품 법인은 (예를 들어, 바이오 공학, 생명 과학, 약리학 등과 같은) 다른 많은 의약품 카테고리에 대한 KIS를 설정할 수 있다. 이들 각각은 그 카테고리에 흥미있고 지식을 갖고 있는 사용자 그룹을 가질 것이다. 그러나, KIS는 또한 법인의 모든 고용인으로 모여있는 '사람' 그룹도 가질 것이다. 이로 인해 전체 고용인 모그룹의 구성원이 KIS의 사용자가 아닌 경우에도 KIS의 사용자라면 전체 고용인 모그룹의 구성원으로 네비게이션할 수 있다. 또한, KIS의 사용자가 반드시 아닐지라도, 추론 엔진은 법인 내에 있는 사람으로부터 떨어져 시맨틱 링크를 사용하여 전문의견(expertise)을 추론할 수 있다.

이는 또한 KIS 수준에서 접근 콘트롤에 대한 장점도 가지며, 따라서 이는 웹 서비스 레이어에서 애플리케이션 서버에 의해 제공된 접근 콘트롤을 보충하고 보완한다. 사용자 그룹은 KIS 지식에 접근할 수 있는 사람을 포함할 것이다. 그러나, 사람 그룹은 비록 KIS에 접근할 수 없지만 KIS 지식에 관련된 사람을 포함할 것이 다.

사람 및 사용자 DSA는 시맨틱 메타데이타 스토어(Semantic Metadata Store: SMS) 내의 사람 테이블을 모그룹하고 적절하게 객체 타입 ID를 나타낸다. 바람직하게는 패스워드가 SMS 내에 사람 테이블 내에 저장되지 않는 점을 주목하자.

사용자 DSA는 또한 사용자 인증 테이블(User Authentication Table: UAT)도 모그룹한다. 이는 사용자 명칭을 패스워드에 매핑하는 인-메모리(in-memory) 해쉬 테이블이다. 서버의 웹 서비스는 IPasswordProvider 인터페이스 또는 동등물을 이행할 것이다. PasswordProvider 객체의 이행은 특정 사용자 명칭에 매핑되는 패스워드를 반환할 것이다. 아래 C# 예시는 이를 도시한다.

namespace WSDK_Security

{

public class PasswordProvider:Microsoft.WSDK.Security.IpasswordProvider

{

public string GetPassword( string username)

{

return "opensezme";

}

}

다음 C# 코드는 사용자가 인증된 후에 웹 서비스가 사용자 정보를 검색할 수 있는 방법을 보여준다.

using System;

using System.Collections;

using System.ComponentModel;

using System.Data;

using System.Diagnostics;

using System.Web;

using System.Web.Services;

using Microsoft.WSDK.Security;

using Microsoft.WSDK;

namespace WSDK_Security

{

public class Servicel:System.Web.Services.WebService

{

[WebMethod]

public string PersonalHello()

{

string response="";

SoapContext requestContext = HttpSoapContext.RequestContext;

if (requestContext == null)

{

throw new ApplicationException("Non-SOAP request.");

}

foreach(SecurityToken tok in requestContext.Security.Tokens)

{

if(tok is UsernameToken)

{

response += "Hello"+((UsernameToken)tok).Username;

}

}

return response;

}

}

}

그런 다음 Nervana 웹 서비스가 진행될 수 있고 호 설정 사용자 명칭을 사용하여 서버 시맨틱 런타임을 호출한다. 그런 다음 런타임은 이를 SQL에 매핑하고 적절한 필터를 사용하여 시맨틱 쿼리를 발부한다.

Nervana ASP.NET 애플리케이션의 경우에, Web.config 파일 내에 모 구성 요소의 자(child) 구성 요소로서 추가된다.

＜microsoft.wsdk＞

＜security＞

＜passwordProvider

type="WSDK_Security.PasswordProvider,WSDK-Security"/＞

＜/security＞

＜/microsoft.wsdk＞

a. 클라이언트 측 허가 요청

요청에 대한 UsernameToken을 생성하기 위해, Nervana 클라이언트는 SOAP 요청의 일부로서 사용자명칭과 패스워드를 통과해야 한다. Nervana 클라이언트는 요청의 부분으로서 다중 토큰을 통과할 수 있으며, 따라서 이는 사용자 신원이 다중 인증 공급자를 가로질러 연합된 경우에 양호할 수 있다. Nervana 클라이언트는 (사용자 명칭 및 패스워드 정보를 포함하여) 사용자가 공급하는 사용자 계정 정보를 모으고, 이들을 WS-보안 토큰으로 변환하며, 그런 다음 SOAP 요청을 발부할 것이다. 클라이언트 코드는 다음과 같을 것이다. (참조:http://www.msdn.microsoft.com)

localhost.Servicel proxy = new localhost.Servicel();

Username Token clearTextToken

= new UsernameToken("Joe",

"opensezme",

PasswordOption.SendHashed);

proxy.RequestSoapContext.Security.Tokens.Add(clearTextToken);

labell.Text = proxy.PersonalHello();

b. 서버에 대한 UsernameToken 비준

(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwssecur/html/wssecwithwsdk.asp)

비록 WSDK가 보안 헤더 구문을 입증하고 패스워드 공급자로부터 패스워드에 대항하는 패스워드 해쉬(hash)를 조사하지만, 요청에 대해 양호하게 수행되는 몇 가지 추가 입증이 있다. 예를 들어, WSDK는 패스워드 요소를 포함하지 않는 UsernameToken이 수신되면 패스워드 공급자을 호출하지 않을 것이다. 조사할 패스워드가 없으면, 패스워드 공급자를 호출할 이유가 없다. 이는 우리가 UsernameToken의 포맷을 우리 스스로 입증할 필요가 있다는 것을 의미한다.

또 다른 가능성은 요청을 포함하는 하나 이상의 UsernameToken 구성 요소가 있다는 것이다. WS-보안은 상이한 목적을 위해 사용될 수 있는 하나의 요청에 임의의 수의 토큰을 포함하기 위한 지원을 제공한다.

Nervana 웹 방법이 해슁(hashing)된 패스워드를 UsernameToken이 포함한다는 것을 입증하고 단일 UsernameToken을 사용하여 오직 수신 요청만을 수용하도록, 전술한 코드가 수정될 수 있다. 수정된 코드는 아래와 같다.

[WebMethod]

public string ProcessSemanticQuery(string Query)

{

SoapContext requestContex = HttpSoapContext.RequestContext;

if (requestContext==null)

{

throw new ApplicationException("Non-SOAP request.");

}

if(requestContext.Security.Tokens.Count==1)

{

foreach(SecurityToken tok in requestContext.Security.Tokens)

{

if(tok is UsernameToken)

{

UsernameToken UserToken=(UsernameToken)tok;

if(UserToken.PasswordOption==PasswordOption.SendHashed)

{

return ProcessSemanticQueryInternal(Query,UserToken.Username);

}

else

{

throw new SoapException(

"Invalid UsernameToken password type.",

SoapException.ClientFaultCode);

}

}

else

{

throw new SoapException(

"UsernameToken security token required.",

SoapException.ClientFaultCode);

}

}

}

else

{

throw new SoapException(

"Request must have exactly one security token.",

SoapException.ClientFaultCode);

}

return null;

}

2. 사람 그룹

KIS는 사람 그룹에 대한 메타데이타를 포함할 것이다. 이들은 최신 오퍼레 이팅 시스템 내의 사용자 그룹과 다르지 않다. 사람 그룹은 Nervana 일급 객체일 것이다. (즉, 사람 그룹은 객체 클래스로부터 유래될 것이다.) 또한, 사람 그룹 스키마(schema)는 다음과 같다.

대부분의 경우에, 사람 그룹은 (LDAP와 같이) 디렉토리 시스템 내에 사용자 그룹을 매핑할 것이다. 예를 들어, KIS 서버 행정은 KIS가 사용자 그룹의 설정 가능한 세트를 크롤링하게 할 것이다. 사용자 그룹을 크롤링하고 SMS 내에 사용자 테이블과 사람 그룹을 모집할 사람 DSA가 존재할 것이다. 사람 DSA는 다음과 같은 동작을 수행할 것이다.

(SMS 내에 그룹이 존재하지 않으면) 그룹을 생성하거나 또는 (그룹이 존재하면) 그룹의 메타데이타를 갱신 한다.

(소스에, 바람직한 실시예에서 LDAP 디렉토리에) 그룹 내에 모든 사용자를 열거한다.

그룹 내의 모든 사용자에 대해, 사람 프로젝트를 생성한다. (또는 객체가 SMS 내에 이미 존재하면 메타 데이타를 갱신 한다.)

(BELONGS_TO_GROUP 시맨틱 링크 타입을 사용하여) 그룹 객체에 사람 객체를 매핑함으써 (SMS 내에 'SemanticLinks' 테이블을 통해) 시맨틱 네트워크를 갱신한다. 이로 인해 SMS가 (그룹과 사용자 자신들에 추가하여) 그룹 멤버쉽 정보를 포착하는 시맨틱 링크를 갖는 것을 보장한다.

3. 식별자 메타데이타 연합

식별자 메타데이타 연합(Identity Metadata Federation: IMF)은 정보 커뮤니티(에이전시)(Information Community)가 인터넷을 통해 발전되지만 법인 또는 개인 고객을 서비스하기 위해 사용되는 특징을 참조한다. 예를 들어, 로이터는 독점 콘텐츠에 따라 모든 그 법인 고객들에 대한 정보 커뮤니티를 설정할 수 있다. 복수의 고객이 (동일한 산업과 같이) 정보 커뮤니티를 공유하는 이러한 경우에, 로이터는 각각의 고객을 위해 SMS에 대한 그룹을 가질 것이다. 그러나, 이들 각각의 고객들은 사람 메타데이타가 이용 가능하게 되기 위해 로이터에 대해 그 법인 디렉토리가 반영되어야 할 것이다. 이는, 특히 보안 및 프라이버시 관점에서 문제를 야기할 것이다. 법인은 법인의 고용인의 메타데이타에 대한 접근권을 얻는 외부 콘텐츠 공급자를 갖는다는 점에서 아마도 불편할 것이다. IMF는 사용자의 인증을 위해 단지 충분한 메타데이타만을 인터넷 호스팅된(internet-hosted) 정보 커뮤니티(에이전시)에게 갖게 함으로써 이러한 문제를 해결한다. 예를 들어, 로이터는 그 SMS 내에 그 법인 고객의 사용자에 대한 로그온 정보만을 저장할 것이다. 시맨틱 브라우저가 이러한 불충분한 메타데이타를 포함하는 SRML을 수용할 때, 클라이언트는 사용자의 완전한 메타데이타를 가져오기 위해 (기업 디렉토리 메타데이카가 웹 서비스 디렉토리를 통해 이용가능하게 되면 LDAP 접근 또는 UDDI를 통해) 기업 디렉토리에 또 다른 쿼리를 발부할 것이다. 이는 외부적으로 저장된 메타데이터는 남아있는 메타데이타를 가져올 수 있는 식별 정보를 가질 것이기 때문에 가능하다. 클라이언트가 기업의 방화벽 내에 남아있는 메타데이타를 가져갈 수 있으므로, 민감한 법인 메타데이터르 외부와 공유되지 않는다.

4. 접근 콘트롤

a. 접근 콘트롤 정책

바람직한 실시예에서, KIS는 접근 콘트롤 시맨틱을 포함하고 적용할 것이다. KIS는 "디폴트 접근"의 정책을 사용한다. 여기에서 디폴트 접근은 접근이 부인된 경우를 제외하고 KIS가 SMS 내의 임의의 메타데이타에 대한 발신 사용자의 접근을 허용할 것이라는 것을 의미한다. 이러한 맥락에서, 시스템은, 접근의 새로운 형상과는 대조적으로 부인의 새로운 형상을 제공하기 위해 확장될 수 있다. 또한, 이러한 것은 부인을 위한 근거가 없다면 사용자가 접근 허용된다는 것을 의미한다.(이는 보다 단순하고 공정한 접근 콘트롤 모델을 제공한다.)

KIS는 접근 콘트롤 관리자(Access Control Manager: ACM)를 가질 것이다. ACM은 클라이언트로부터 주어진 시맨틱 요청에 대해 SQP에 의해 쿼리에 부가될 부인 시맨틱 쿼리(Denial Semantic Query: DSQ)를 생성하는데 주로 책임이 있다. ACM은 다음 방법을 공개할 것이다 (C#; 샘플)

String GetDenialSemanticQuery(String CallingUserName)

바람직하게는, 이 방법은 발신 사용자 명칭을 수용하고 예외 객체를 엔캡슐 레이션하는 SQL 쿼리(또는 동등물)를 반환한다. 이들은 SQP에 의해 발신 사용자로 반환 금지된 객체(즉, 사용자가 접근할 수 없는 객체)이다.

그런 다음 SQP는 다음과 같이 부인 쿼리를 포함하는 최종 미처리(raw) 쿼리를 형성한다.

Aggregate Raw Query AND NOT IN (Denial Query)

예를 들어, 컬렉션 미처리 쿼리가

SELECT OBJECTID FROM OBJECTS WHERE OBJECTTYPEID = 5 이고

부인 쿼리가

SELECT OBJECTID FROM OBJECTS WHERE OWNERUSERNAME ＜＞ 'JOHNDOE' 이면,

(SQP가 SRML에 최종적으로 수행하고 차례로 나열하여 발신 사용자에게 반환할 것인) 최종 미처리 쿼리는 다음과 같다.

SELECT OBJECTID FROM OBJECTS WHERE OBJECTTYPEID = 5 AND NOT IN

(SELECT OBJECTID FROM OBJECTS WHERE OWNERUSERNAME ＜＞ 'JOHNDOE')

시맨틱적으로, 이것은 아마도 "5의 객체 타입 ID을 갖지만 존 도에에 의해 소유되지 않은 객체 리스트 내에 있지 않은 모든 객체를 선택하라"와 동등하다.

이것은 다시 아마도 시맨틱적으로 "존 도에"에 의해 소유된 5의 객체 타입 ID를 갖는 모든 객체를 선택하라"와 동등하다.

b. 일반 접근 콘트롤 규칙

시맨틱 쿼리 프로세서(semantic query processor: SQP)에 의해 처리된 각각의 시맨틱 쿼리는 접근 콘트롤 조사를 포함한다. 이는 발신 사용자가 그/그녀가 접근할 수 있는 메타데이타만을 수용하는 것을 보장한다. SQP은 시맨틱 쿼리를 수행할 때 다음의 접근 콘트롤 규칙을 사용할 것이다.

1. 바람직하게는, 쿼리가 (사람, 사용자, 고객, 전문가, 신문편집인 등인) '사람' 객체를 위한 것이면, 반환되는 '사람' 객체는,

발신 사용자를 포함하거나,

발신 사용자와 함께 적어도 하나의 사람 그룹을 공유하고 발신 사용자 또는 시스템에 의해 소유되는 사람을 포함하여야 한다.

바람직하게는, 대응하는 부인 쿼리는 다음과 같은 규칙에 매핑된다. 즉, 반환되는 객체는,

발신 사용자가 아닌가, 그리고

발신 사용자 또는 시스템에 의해 소유되지 않았는가, 그리고

발신 사용자와 임의의 사람 그룹을 공유하지 않는 사람이 있는가를 만족해야 한다.

샘플 부인 쿼리 SQL

아래 SQL은 접근 콘트롤 정책을 강화시키도록 ACM에 의해 생성되고 SQP에 의해 첨부될 접근 콘트롤 부인 쿼리를 도시한다. 이러한 예시에서, 발신 사용자의 명칭은 '존 도에'이다.

SELECT OBJECTID FROM OBJECTS WHERE

OWNERUSERNAME ＜＞ 'JOHNDOE' OR

OWNERUSERNAME ＜＞ 'SYSTEM' OR

WHERE OBJECTID NOT IN (SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE') OR

WHERE OBJECTID NOT IN

(SELECT OBJECTID FROM SEMANTICLINKS WHERE

OBJECTTYPEID ="PERSON AND PREDICATETYPEID='BELONGS_TO_GROUP' AND SUBJECTID IN (SELECT SUBJECTID FROM SEMANTICLINKS WHERE OBJECTID IN (SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE'))

2. 바람직하게는, 쿼리가 (문서, 이메일, 이벤트 등과 같은) 사람이 아닌 객체를 위한 것이면, 반환되는 객체는,

발신 사용자 또는 시스템 사용자에 의해 소유되어야 하고, 그리고

객체로서 발신 사용자를 갖는 시맨틱 링크의 주제이거나,

객체로서 발신 사용자를 갖는 시맨택 링크의 객체가거나,

발신 사용자와 적어도 하나의 사람 그룹을 공유하는 사람인 객체를 갖는 시맨틱 링크의 주제이거나,

발신 사용자의 적어도 하나의 사람 그룹을 공유하는 사람인 객체를 갖는 시맨틱 링크의 객체가어야 한다.

바람직하게는, 대응하는 부인 쿼리는 다음 규칙으로 매핑된다. 즉, 반환되는 객체는,

발신 사용자에 의해 소유되지 않는가, 그리고

시스템 사용자에 의해 소유되지 않는가, 그리고

객체로서 발신 사용자를 갖는 시맨틱 링크의 주제가 아닌가, 그리고

주제로서 발신 사용자를 갖는 시맨틱 링크의 객체가 아닌가, 그리고

발신 사용자의 적어도 하나의 사람 그룹을 공유하는 사람인 객체를 갖는 시맨틱 링크의 주제가 아닌가, 그리고

발신 사용자의 적어도 하나의 사람 그룹을 공유하는 사람인 주제를 갖는 시맨틱 링크의 객체가 아닌가이다.

샘플 부인 쿼리 SQL

아래 SQL는 접근 콘트롤 정책을 강화하기 위해 ACM에 의해 생성되고 SQP에 의해 첨부될 접근 콘트롤 부인 쿼리를 도시한다. 이러한 예시에서 발신 사용자의 명칭은 '존 도에'이다.

SELECT OBJECTID FROM OBJECTS WHERE OWNERUSERNAME ＜＞'JOHNDOE'OR

OWNERUSERNAME ＜＞'SYSTEM'OR

OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE

OBJECTTYPEID='PERSON' AND OBJECTID IN (SELECT OBJECTID FROM PEOPLE WHERENAME='JOHNDOE') OR

WHERE OBJECTED NOT IN (SELECT OBJECTID FROM SEMANTICLINKS INNER JOIN PEOPLE WHERE SEMANTICLINKS.SUBJECTTYPEID = 'PERSON'AND SEMANTICLINKS.SUBJECTID=PEOPLE.OBJECTID) OR

OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE OBJECTTYPEID='PERSON'AND PREDICATETYPEID='BELONGS_TO_GROUP' AND SUBJECTID IN (SELECT SUBJECTID FROM SEMANTICLINKS WHERE OBJECTID IN (SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE')) OR

OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE OBJECTTYPEID='PERSON' AND PREDICATETYPEID='BELONGS_TO_GROUP' AND OBJECTID IN (SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE'))

샘플 병합된 부인 쿼리 SQL

이들 두 규칙을 병합함으로써, ACM은 접근 부인을 위한 SQP에 다음과 같은 합병된 쿼리를 반환한다.

SELECT OBJECTID FROM OBJECTS WHERE

OWNERUSERNAME ＜＞ 'JOHNDOE' OR

OWNERUSERNAME ＜＞ 'SYSTEM' OR

OBJECTID NOT IN (SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE') OR

OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE

OBJECTTYPEID ="PERSON AND PREDICATETYPEID='BELONGS_TO_GROUP' AND SUBJECTID IN (SELECT SUBJECTID FROM SEMANTICLINKS WHERE OBJECTID IN (SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE')) OR

OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE OBJECTTYPEID ="PERSON' AND OBJECTID IN (SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE') OR

OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS INNER JOIN PEOPLE ON SEMANTICLINKS.SUBJECTTYPEID='PERSON' AND SEMANTICLINKS.SUBJECTID=PEOPLE.OBJECTID) OR

OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE OBJECTTYPEID='PERSON'AND PREDICATETYPEID='BELONGS_TO_GROUP' AND SUBJECTID IN (SELECT SUBJECTID FROM SEMANTICLINKS WHERE OBJECTID IN (SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE')) OR

OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE OBJECTTYPEID='PERSON' AND PREDICATETYPEID='BELONGS_TO_GROUP' AND OBJECTID IN (SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE'))

예시 시나리오

예를 들어, 로이터 에이전시(KIS)는 로이터가 서비스하는 각각의 기업 고객에 대한 사람 그룹을 가질 수 있다. 에이전시는 (로이터 콘텐츠인) 공통적인 정보 기반을 가지지만 기업 고객마다 사람 그룹을 가질 것이다. 이들 그룹은 경쟁자를 포함할 수 있다. 이러한 맥락에서, 지식 흐름, 생성 및 추론이 경쟁자 경계와 교차하니 않는다는 것을 보장하는 것이 양호하다. 예를 들어, 회사 A의 고용인은 회사 A와 경쟁하는 회사 B의 고용인으로부터 직접적으로 지식을 유도하지 않아야 하지만, 그가 또는 그녀는 (추론을 통해) 간접적으로 지식을 유도해야 한다. 회사 A의 고용인은 회사 B의 고용인에 의해 주석된 아이템에 대한 추천을 받을 수 없어야 한다. 또는 회사 A의 고용인은 회사 B를 위해 작업하는 전문가를 디스커버리할 수 없어야 한다. 물론, 이러한 것은 회사 A와 회사 B가 어떤 점에서 파트너가 아니라 는 것이 가정된다. (이 경우에, 그들은 지식을 공유하길 원할 수 있다.) 지식 파트너의 경우에, 로이터는 회사 A 와 회사 B의 사람 그룹을 포함하는 (LDAP를 통하는 것과 같이) 사람 그룹을 생성할 것이다. 그런 다음 로이터 KIS는 다음 회사 그룹, 즉 회사 A, 회사 B, 회사 A 및 B을 가질 것이다. SMS는 또한 회사 A와 회사 B에 있는 사람들이 ("그룹에 속하는(belongs to group)" 시맨틱 링크 타입을 통해) 이들 그룹에 속하는 것을 나타내는 메타데이타를 포함할 것이다. 이들 공정이 제자리에 있는 상태에서, 전술한 규칙들은 회사 A와 회사 B 사이에 지식이 공유되는 것을 보장할 것이다.

c. 주석을 위한 접근 콘트롤 규칙

주석의 경우에, 발신 사용자는 시맨틱 네트워크를 쿼리하는 것과는 대조적으로 시맨틱 네트워크를 편집할 것이다. 이 경우에, 다음 규칙들이 적용될 것이다.

1. 바람직하게는, 주석되는 객체가 사람 객체가면, 객체는,

발신 사용자, 또는

발신 사용자와 적어도 사람 그룹을 공유하고 발신 사용자 또는 시스템에 의해 소유된 사람일 것이다.

2. 바람직하게는, 주석되는 객체가 (예를 들어, 문서, 이메일, 이벤트 등과 같이) 사람 객체가 아니면, 객체는,

발신 사용자에 의해 소유되거나,

시스템에 의해 소유되어야 한다.

샘플 부인 쿼리 SQL

아래 SQL는 접근 콘트롤 정책을 강화하기 위해 (주석을 위한 접근 콘트롤을 조사하기 위한) ACM에 의해 생성되고 SQP에 의해 주석될 접근 콘트롤 부인 쿼리를 도시한다. 이 예시에서, 발신 사용자의 명칭은 '존 도에'이다.

SELECT OBJECTID FROM OBJECTS WHERE

OWNERUSERNAME ＜＞ 'JOHNDOE' OR

OWNERUSERNAME ＜＞ 'SYSTEM' OR

OBJECTID NOT IN (SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE') OR

OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE OBJECTTYPEID='PERSON' AND PREDICATETYPEID='BELONGS_TO_GROUP' AND OBJECTID IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE OBJECTID IN (SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE'))

접근 콘트롤 강화

ACM은 KIS 상에 주석 및 다른 기록 동작을 위한 접근 콘트롤을 강화시킨다. KIS XML 웹 서비스는 다음(C# 샘플)과 같이 주석 방법을 공개한다. (C# 샘플)

AnnotateObject (String CallingUserName, String ObjectID);

이러한 방법은 부인 쿼리를 가져오기 위해 ACM을 호출한다. 그런 다음 다음과 같은 최종 쿼리를 생성시킨다.

Annotation Object Query AND NOT IN (Denial Query)

바람직한 실시예에서, 주석 객체 쿼리는 항상,

SELECT OBJECTID FROM OBJECTS WHEREOBJECTID=ObjectlED의 형태이며, ObjectID는 AnnotateObject 방법에 대한 인수이다.

그런 다음 ACM은 최종 접근 콘트롤 쿼리 SQL를 구성하고 이 SQL을 사용하여 접근 콘트롤을 조사한다. ACM은 SQL을 반환할 필요가 없으므로, 접근 콘트롤을 조사하기 위해서, ACM은 SQL을 직접 호출할 수 있다. 또한, 그것이 2진 조사(접근 또는 비접근)이기 때문에, ACM은 부인 쿼리가 적어도 하나의 열을 반환할 지 여부를 조사한다. 예를 들어, 최종 쿼리는 비슷하게 보일 수 있다.

SELECT OBJECTID FROM OBJECTS WHERE OBJECTID=ObjectID AND NOT IN (SELECT OBJECTID FROM OBJECTS WHERE OWNERUSERNAME ＜＞ 'JOHNDOE')

그런 다음, ACM은 (SQL 쿼리 프로세서를 통해) 이러한 쿼리를 실행시키고 결과 세트 내에 열의 수를 카운트를 필요로 한다. 하나의 열이 있다면, 접근이 허여되고 그밖의 다른 접근은 부정된다. 이러한 모델은 부인 쿼리 모델와 상호 관련성을 갖기 위해 이런 방식으로 이행된다. (ACM은 항상 부인 쿼리를 사용하고 모든 접근 콘트롤 조사를 위한 기반으로서 이를 사용한다.)

L. 정보 신경 시스템용 심층 정보 규격

심층 정보 개요

서 론

바람직한 실시예에서, Nervana '심층 정보' 도구는 Nervana 정보 객체를 위한 컨텍스트-민감성 층형(story-like) 정보를 목표로 하고 있다. 심층 정보는 필연적으로 특정 컨텍스트가 주어지게 되면 그렇지 않을 경우에 상실되었을 정보를 Nervana 사용자에게 제공한다. 대략적으로, 심층 정보는 (현재 아티스트, 현재 음 악 및 어떤 경우에는 그 음악에 대한 현재 음악 악기에 대한 정보를 보여주는) MTV 상의 음악 비디오 상에 디스플레이되는 컨텍스트 정보와 유사하다.

'심층 정보'에서 '심층'은 객체가 출현하게 되는 에이전시 상의 시맨틱 네트워크 내에 복수의 "도약(hop)"을 컨텍스트 정보가 종종 생성하는 사실을 참조한다. '심층 정보'는 평탄한 컨텍스트 메타데이타 또는 (SQML을 통한) 시맨틱 쿼리 링크를 갖는 메타데이타일 수 있는 '심층 정보 너깃(nugget)'를 포함한다.

바람직한 실시예에서, 적어도 다섯 종류의 심층 정보 너깃이 있다.

1. 기본적인 시맨틱 링크 너깃

2. 컨텍스트 템플릿 너깃

3. 평범한(trivia) 너깃

4. 중매인(matchmaker) 너깃

5. 재귀 너깃

a. 기본 시맨틱 링크 너깃

기본 시맨틱 링트 진리를 사용하여, 심층 정보 너깃은 현재 객체의 시맨틱 링크를 단지 전달한다. 이들 너깃은 1이란 시맨틱 링크 길이와 관련된다. 이 경우, '링크' 컨텍스트/임무 창 내에 디스플레이될 것과 중첩이 있다. 예시는 아래와 같다.

패트릭 쉬미즈가 노사 오모이구이에게 보고한다.

패트릭 쉬미즈가 5개의 직접 보고서를 갖고 있다.

패트릭 쉬미즈가 47개의 객체를 주석했다.

패트릭 쉬미지가 13개의 객체를 저술했다.

패트릭 쉬미즈가 56개의 이메일 객체 상에 복사되었다.

b. 컨텍스트 템플릿 너깃

ㆍ컨텍스트 템플릿 너깃은 가까이에 정보에 기반하여 각각의 관련 컨텍스트 템플릿에 대한 컨텍스트 정보를 디스플레이한다. 이들 너깃은 각각의 타입의 컨텍스트 템플릿에 대한 컨텍스트 바 또는 컨텍스트 패널 내에 디스플레이될 것들과 동일하다. 예시는 아래와 같다.

패트릭 쉬미즈가 3개의 속보 아이템을 발송했다.

패트릭 쉬미즈가 14개의 클래식을 발송했다.

패트릭 쉬미즈가 7개의 헤드라인을 저술했다.

패트릭 쉬미즈가 13개의 토론과 관련된다.

패트릭 쉬미즈가 356개의 객체에 대한 뉴스메이커이다.

c. 평범한 너깃

에이전시 상의 모든 이메일 객체에 대해,

스티브 저킨스는 모든 이메일 객체의 "To" 리스트에 나타나있고,

스티브 저킨스는 그들의 23%에 응답했으며,

패트릭 쉬미즈는 그들의 50%를 주석했고,

이들 중 단지 3개만 2보다 큰 쓰레드 깊이(thread depth)를 갖는다.

에이전시 상의 모든 사람 객체에 대해,

패크릭 쉬미즈는 그들 중 47%에 이메일을 보냈고,

그들 중 14%는 노사 오모이구이에게 보고하고,

샐리 스미스는 그들 중 85%가 토론했고,

그들 중 12%는 적어도 하나의 토픽에 대한 뉴스메이커이고,

그들 모두는 이번 주에 적어도 하나의 토론과 관련되며,

그들 중 33%는 적어도 하나의 토픽에 대한 전문가이고,

그들 중 8%는 3개 이상의 토픽에 대한 전문가이다.

에이전시 상의 주어진 배포 리스트에 대해,

스티브 저킨스는 이 리스트로 가장 많은 이메일을 발송했고,

사라 트렌트는 이 리스트 상의 가장 많은 이메일에 응답했으며,

노사 오모이구이는 이 리스트로 전혀 발송하지 않았고,

패트릭 쉬미즈는 이번 달에 이 리스트로 87개의 메시지를 발송했고,

리차드 노보트니는 올해 이 리스트로 345개의 메시를 발송했다.

에이전시 상의 모든 배포 리스트에 대해,

스티븐 저킨스는 모든 리스트로 가장 많은 이메일을 발송했고,

리사 헤이브론은 리스트의 오직 2%에 대한 이메일에 응답했고,

노사 오모이구이는 모든 리스트로 발송하지 않았고,

패트릭 쉬미지는 모든 리스트로 매주 적어도 한 번 발송했고,

리차드 노보트니는 3개의 리스트에 대한 메시지를 발송했다.

에이전시 상의 모든 정보 객체에 대해,

스피븐 저킨스는 가장 다작의 발표자였고, (그는 그들의 5%를 발표했다)

샐리 스미스는 가장 다작의 주석가였고, (그녀는 그들의 2%를 주석했다)

노사 오모이구이는 가장 활력있는 뉴스메이커가었고,

패트릭 쉬미즈는 가장 많은 개수의 전문가 의견을 갖고 있으며,

스티브 저킨스는 올해 발표된 정보에 대한 최고 전문가 의견을 갖고 있고,

가빈 쉬미즈는 최고 토론과 (그들중 12%임) 관련되어 있으며,

리차드 노보트니는 이번 달에 최고 토론과 (그들중 18%임) 관련되어 있다.

d. 중매인 너깃

사람 대 사람

시맨틱 링크 기반

패트릭 쉬미즈는 13명의 사람에게 메일을 보냈고,

47명의 사람이 패트릭 쉬미즈와 동일한 To 리스트 상에 나타나있고,

47명의 사람이 패트릭 쉬미즈와 동일한 CC 리스트 상에 나타나있고,

전부 89명의 사람이 패트릭 쉬미즈에 의해 보내진 이메일 상에 참조되었고,

24명의 사람이 패트릭 쉬미즈와 동일한 정보를 주석했고,

3명의 사람이 패트릭 쉬미즈와 동일한 모든 배포 리스트 상에 있으며,

29명의 사람이 패트릭 쉬미즈의 배포 리스트 중 적어도 하나 상에 있다.

컨텍스트 템블릿 기반

12명의 사람이 패트릭 쉬미즈와 동일한 정보 카테고리 상에 전문가 의견을 갖고 있으며,

14명의 사람과 패트릭 쉬미즈가 동일한 정보 아이템에 대한 뉴스메이커이고,

27명의 사람이 패트릭 쉬미즈와 토론 중에 있다.

정보 대 사람

시맨틱 링크 기반

패트릭 쉬미즈는 이 정보 아이템을 발송했고,

스티브 저킨스는 이 정보 아이템을 저술했으며,

이 정보 아이템은 2명의 사람에게 복사되었고,

3명의 사람이 이 정보 아이템을 주석했다.

컨텍스트 템플릿 기반 (컨텍스트 템플릿 너깃과 유사함)

이 정보 아이템에 대한 4명의 전문가가 있고,

이 정보 아이템에 대한 27명의 뉴스메이커가 있다.

정보 대 정보

컨텍스트 템플릿 기반 (컨텍스트 템플릿 너깃과 유사함)

578개의 관련된 '모든 의견'이 있고,

235개의 관련된 '최상 의견'이 있고,

4개의 관련된 속보 아이템이 있고,

46개의 관련된 헤드라인이 있다.

(사람을 통한) 시맨틱 링크 기반

이것을 갖는 동일한 전문가를 갖는 21개의 정보 아이템이 있고,

이것을 갖는 동일한 뉴스메이커를 갖는 23개의 정보 아이템이 있으며,

이것을 발송한 동일한 사람에 의해 발송된 34개의 정보 아이템이 있고,

이것을 저술한 동일한 사람에 의해 저술된 34개의 정보 아이템이 있으며,

이것을 주석한 사람에 의해 주석된 44개의 정보 아이템이 있다.

e. 재귀 너깃

재귀 너깃을 사용하여, 현재 정보 너깃의 주제에 대한 심층 정보를 디스플레이하는 것은 컨텍스트 계층을 형성한다. 그런 다음 시스템은 주제의 객체 타입에 기반하여 너깃을 재귀적으로 디스플레이한다. 재귀 너깃을 사용하여, 시스템은 소스 객체로부터 시작하는 시맨틱 네트워크를 필연적으로 조사하고 네트워크의 경로를 따라 너깃을 계속 디스플레이한다. 조사하는 것은 바람직하게는 사용자 피드백에 기반하여 리소스 제한과 상호 관련되는 깊이에서 정지될 것이다.

재귀 너깃을 생각하는 또 다른 방법은 비지니스 조직 차트의 컨텍스트 버전과 같다. 그러나, 정보 신경 시스템 내의 심층 정보를 사용하여, 사용자는 정보 트리와는 대조적으로 지식 트리를 브라우징할 수 있을 것이다. 예시를 위해, 사용자가 객체를 선택하면 트리 보기는 아래 디스플레이된 것과 같은 것을 도시할 것이다.

컨텍스트으로서 문서를 사용한 예:

[+] Newsmakers on'Title of document'

[+] Gavin Schmitz

[+] Reports To -＞

[+] Steve Judkins

[+] Experts Like Steve Judkins -＞

[+] Nosa Omoigui

[+} Patrick Schmitz

[+] Interest Group Like Steve Judkins -＞

[+] Patrick Schmitz

...

[+] Chuck Johnson

...

[+] Direct Reports -＞

[+] Joe Williams

[+] Direct Reports □

[+] Interest Group Like Joe Williams -＞

[+] Richard Novotny

...

[+] Nosa Omoigui

...

[+] Interest Group

[+] Experts

컨텍스트으로서 이메일을 사용한 예:

[+] Email is From:

[+] Nosa Omoigui

[+] Experts like Nosa Omoigui

...

[+] Email is To:

[+] Chuck Johnson

[+] Experts like Chuck Johnson

...

[+] Email is Copied To:

[+] Richard Novotny

[+] Experts like Richard Novotny

...

[+] Email Attachments:

foo.doc

[+] Experts on foo.doc

[+] Gavin Schmitz

[+] Newsmakers like Gavin Schmitz

...

[+] Newsmakers on 'Title of Email'

...

컨텍스트으로서 대화 객체를 사용한 예:

[+] Conversation Participants

[+] Steve Judkins

[+] Interest Group Like Steve Judkins...

...

[+] Nosa Omoigui

[+] Interest Group Like Nosa Omoigui

...

[+] Experts on 'Title of Conversation'

[+] Richard Novotny

[+] Interest Group Like Richard Novotny

...

예를 들어 사람 객체에 링크된 사람 주제와 함께 전술한 예시에서 디폴트 서서술어의 사용 및 (예를 들어 리차드 노보트니와 유사한 이해 그룹)인 LIKE 서서술어 사용을 주목하자.

재귀 너깃의 또 다른 예시는 아래와 같다.

[+] Patrick Schmitz authored this email

[+] Patrick Schmitz reports to Nosa Omoigui

[+] Nosa Omoigui has 6 Direct Reports

[+] Steve Judkins...

[+] Steve Judkins posted...

[+] Steve Judkins is an expert on...

[+] Steve Judkins is a newsmaker on...

[+] Steve Judkins has been involved in 6 discussions

[etc.]

[+] Richard Novotny...

[+] [The remaining 6 direct reports]

[+] Nosa Omoigui annotated 13 objects...

[+] [More context template nuggets on the 13 objects]

[+] Nosa Omoigui has authored 278 objects

[+] Nosa Omoigui has annotated 23 items

[...]

[+] Patrick Schmitz has 5 Direct Reports

[+] John Doe...

[+] More Native Nuggets based on the direct reports

[+] Patrick Schmitz annotated 47 objects

바람직한 실시예에서, 재귀 너깃은 시맨틱 브라우저 내이 각각의 결과 객체 옆에 드릴다운(drill-down) 창을 통해 가장 전형적으로 디스플레이될 것이다. 이 는 사용자가 (전술한 바와 같이) 결과 객체를 선택하는 것을 허용하고 그런 다음 객체를 재귀적으로 시맨틱적으로 "익스플로어링(exploring)"할 것을 허용한다.

또한, 심층 정보 드릴 다운 트리 보기 내의 각각의 헤더 아이템은 (예를 들어 스티브 저킨스와 유사한 전문가와 같은) 요청에 대한 링크일 것이며, 각각의 결과는 엔티티에 대한 링크일 것이다. 예를 들어, 사용자가 심층 정보 트리 보기 내에 임의의 위치로부터 "사람" (시맨틱적으로) 패트릭 쉬미즈로 "네비게이션"할 수 있을 것이다. 그런 다음, 패트릭 쉬미지에 의해 속보로 명명된 요청을 열기 위해, 사용자는 패트릭 쉬미즈에 대한 일건 서류을 볼 수 있으며, 패트릭 쉬미즈를 복사할 수 있고, 그것을 속보 위에 붙일 수 있다. 즉, 사람 주제에 기반한 ("BY") 디폴트 서서술어의 사용을 주목하자.

(시맨틱 브라우저 내의 시맨틱 런타임 API로 부터의 지원과 함께) 바람직한 실시예의 프리젠터 심층 정보 트리 보기는 요청이 있는 링크들과 결과 객체가 있는 링크들의 트랙을 유지할 것이다. 즉, 그런 방식으로 사용자가 링크 상에 트리 보기를 클릭할 때 사용자의 의도를 지능적을 해석할 것이다. (그것은 엔티티로 네비게이션하거나 요청로 네비게이션할 것이다.)

M. 정보 신경 시스템용 생성 요청 마법사 규격

생성 요청 마법사 서론

서 론

바람직한 실시예의 생성 요청(Create Request)(또는 스마트 에이전트) 마법사는 사용자가 (지식 집적 서비스를 운용하면서) 하나 이상의 지식 소스에 발부되 는 시맨틱 쿼리를 대표하는 새로운 요청을 쉽고 직관적으로 생성하는 것을 허용한다.

마법사 제1면: 프로파일 및 요청 타입을 선택한다. 이 면은 사용자가 요청이 생성하게될 프로파일을 선택하는 것을 허용한다. 이 면은 또한 사용자가 그/그녀가 생성하기 원하는 요청의 타입을 선택하는 것을 허용한다. 이러한 타입은 (요청에 나타난 필터에 기반하여) 각각의 컨텍스트 템플릿에 대한 보조 요청, (최상 의견, 헤드라인, 전문가, 뉴스메이커 등과 같은 컨텍스트 템플릿에 대응하는) 지식 타입, (프레젠테이션, 일반 문서 등과 같은 타입에 대응하는) 정보 타입 및 블렌더(blender)이면서 사용자가 응집력 있는 단위로서 몇가지 요청을 보는 것을 허용하는 요청 컬렉션(request collection)을 포함하는 요청을 생성할 일건 서류(일건서류(Dossier))(가이드)일 수 있다. 도17a를 참조한다.

마법사 제2면: 지식 커뮤니티(에이전시)를 선택한다. 이 면은 사용자가 (지식 집적 서비스(Knowledge Integration Service: KIS)를 운용하면서) 요청이 그 지식을 어느 지식 커뮤니티로부터 가져와야 하는 지를 선택하는 것을 허용한다. 사용자는 요청이 선택된 프로파일 내에 구성된 것들과 동일한 지식 커뮤니티를 사용해야 한다는 것을 나타낼 수 있다. 이와 달리 사용자는 특정 지식 커뮤니티를 선택할 수 있다. 도17b를 참조한다.

마법사 제3면: 필터를 선택한다. 이 면은 사용자가 어느 필터가 요청 내에 포함되는 지를 선택하는 것을 허용한다. 필터는 키워드, 텍스트, 카테고리, 국부적인 문서, 웹 문서, (사람 필터를 위한) 이메일 주소 및 엔티티 중 하나 이상을 포함할 수 있다. 또 다른 실시예에서, 다른 필터 타입이 지원될 것이다. 특성 면은 또한 사용자가 특정 필터에 적용할 수 있는 서서술어를 선택하는 것을 허용한다. 바람직하게는 공표될 가장 통상적인 서술어는 "에 관련되는"이다. 다른 서술어는 필터 타입에 상호 관련되어 공표될 수 있다. (예를 들어 요청된 타입이 '사람'이 아니라면, 이메일 주소 또는 엔티티를 통해 사람을 참조하는 필터는 - 예를 들어 존 스미스에 의한(BY) 헤드라인과 같이- 디폴트 서술어 "BY"를 사용하게 될 것이며, 요청된 타입이 '사람'이면 - 예를 들어 존 스미스와 유사한(LIKE) 전문가와 같이- 디폴트 서술어 "LIKE"를 사용할 것이다.) 특성 면은 또한 사용자가 필터에 의해 적용되는 연산을 선택하는 것을 허용할 것이다. 두 개의 가장 통상적인 연산자는 (오직 모든 필터들을 만족시키는 결과만이 반환되는) AND와 (임의의 필터를 만족시키는 결과가 반환되는) OR이다. 도17c를 참조한다

마법사 제4면: 이 요청을 명명하고 설명한다. 이 면은 사용자가 요청에 대한 명칭과 설명을 입력하는 것을 허용한다. 마법사는 요청의 시맨틱에 기반하여 요청에 대한 명칭과 설명을 자동적으로 제안한다. 예는 다음과 같다.

1. 보안에 대한 AND 애플리케이션 개발에 대한 AND 웹 서비스에 대한 헤드라인

2. 암호화 기법에 대한 OR 사용자 인터페이스 설계 등에 대한 R＆D로부터의 전문가

3. 인공 지능에 대한 프레젠테이션

4. 데이타 마이닝(mining)에 대한 AND 웹 개발에 대한 일건 서류

도17d를 참조한다.

사용자에게는 제안된 명칭/설명을 무시하는 것이 허용된다. 제안은 최대 명칭 및 설명 길이에 기반하여 필요한 만큼 생략된다.

시맨틱 브라우저는 또한 특성 시트를 통해 기존 요청의 특성을 공표한다. 이는 사용자가 요청을 "편집"하는 것을 허용한다. (요청의 SQML 표현을 디시리얼라이징(deserializing)함으로써) 필드를 제외하고 마법사가 요청의 시맨틱에 기반하여 초기화됨에 따라 특성 시트는 동일한 사용자 인터페이스를 공표한다. 도17e를 참조한다.

N. 정보 신경 시스템용 생성 프로파일 마법사 규격

생성 프로파일 마법사 서론

서 론

생성 프로파일 마법사는 사용자가 새로운 사용자 프로파일을 쉽고 직관적으로 생성하는 것을 허용한다.

마법사 제1면: 당신이 흥미있는 영역을 선택한다. 이 면은 사용자가 그/그녀의 관심 영역을 선택하는 것을 허용한다. 이는 시맨틱 브라우저가 (그/그녀가 일하고 있는 산업과 같은) 사용자의 지적 흥미에 대한 어느 정도 높은 수준의 정보를 모으는 것을 허용한다. 그런 다음 이러한 정보가 사용되어, 카테고리 다이아로그 내에서 카테고리 선택을 좁히고, 사용자의 흥미 영역과 상호 일치하는 지적 도메인으로 구성된 새로운 지식 커뮤니티(에이전시)를 추천한다. 도45a를 참조한다.

마법사 제2면: 당신의 지식 커뮤니티를 선택한다. 이 면은 사용자가 프로파 일용 지식 커뮤니티를 설명하는 것을 허용한다. 이는 요청을 발부하기 위해 어느 지식을 출처로 해야하는 지와 프로파일을 위해 이들 요청이 생성되는 때를 시맨틱 브라우저가 "알아야" 하는 것을 허용한다. 시맨틱 브라우저가 가시화, 시맨틱 경보, (주어진 프로파일에 대해 렌즈가 요청/에이전트일 때) 스마트 렌즈, (표적 객체가 주어지 프로파일로부터의 결과일 때) 객체 렌즈를 호출할 때, 사용자가 주어진 프로파일에 대한 요청/에이전트로 객체를 드래그 앤드 드롭할 때 (또는 복사하고 붙일 때), 시맨틱 브라우저는 프로파일 내에 지식 커뮤니티를 또한 사용한다. 도45b를 참조한다.

마법사 제3면: 이 프로파일을 명명하고 설명한다. 이 면은 사용자가 프로파일에 대한 명칭과 설명을 입력하는 것을 허용한다. 이 면은 또한 사용자가 프로파일이 바람직하게는 디폴트 프로파일로 만들게 될 지 여부를 표시하는 것을 허용한다. 시맨틱 브라우저 내에 임의의 연산 내에서 사용자가 프로파일을 명시적으로 표시하지 않으면 디폴트 프로파일이 사용된다 (예를 들어 파일 시스템으로부터 시맨틱 브라우저를 대표하는 아이콘으로 문서를 드래그 앤드 드롭하는 것은 디폴트 프로파일로부터 그 문서를 갖는 북마크를 여는 반면, 특정 프로파일을 대표하는 아이콘으로 문서를 드래그 앤드 드롭하는 것은 그 프로파일을 갖는 북마크를 연다.) 도45c를 참조한다.

O. 정보 신경 시스템용 생성 북마크 마법사 규격

1. 생성 북마크 마법사 서론

서 론

생성 북마크(또는 국부적인/덤(dumb) 요청 에이전트) 마법사는 (예를 들어 드래그 앤드 드롭, 스마트 복사 및 붙여넣기, 스마트 렌즈, 스마트 경보, 가시화 등과 같은) 시스템의 도구상자에 접근할 수 있는 시맨틱 브라우저 내에서 국부적인/웹 문서, 엔티티등을 보기 위해 사용자가 새로운 북마크(국부적인/덤 요청)를 쉽고 직관적으로 생성하는 것을 허용한다.

마법사 제1면: 프로파일 및 요청 타입을 선택한다. 이 면은 사용자가 북마크가 생성되어야 하는 프로파일을 선택하는 것을 허용한다. 이 면은 사용자가 북마크로부터 아이템을 제거하고 북마크에 아이템을 추가하는 것도 또한 허용한다. 도46a를 참조한다.

마법사 제2면: 이 북마크를 명명하고 설명한다. 이 면은 사용자가 북마크에 대한 명명과 설명을 입력할 것을 허용한다. 마법사는 북마크 내에 있는 아이템에 기반하여 북마크에 대한 명칭과 설명을 자동적으로 제안한다. 예는 아래와 같다.

문서1, 문서2, 문서3

'암호화'를 매칭하는 문서

폴더 '내 문서' 및 서브폴더 내의 문서

Nervana 프레젠테이션 (2003년 7월).ppt AND 폴더 '내 문서' 및 서브폴더 내의 "보안"을 매칭하는 문서

사용자는 제안된 명칭/설명을 무시할 수 있다. 제안은 최대 명칭 및 설명 길이에 기반하여 필요한 만큼 생략된다. 도4b를 참조한다.

2. 시나리오

단백질 공학에 대한 모든 프레젠테이션을 나에게 보여줄 것.

생성 요청 마법사를 사용하여, 프레젠테이션 정보 타입을 (문서/프레젠테이션으로) 선택한 다음, 필터로서 단백질 공학 카테고리를 선택한다. '다음'을 누르면, 마법사는 요청의 시맨틱에 기반하여 (단백질 공학에 대한 프레젠테이션) 요청에 대한 명칭을 지능적으로 제안한다. 마법사는 또한 적절한 디폴트 서술어를 선택한다. '마침'을 누른다. 마법사는 쿼리를 컴파일하고, 선택된 프로파일 내에 KIS로 SQML을 보낸 다음에, 그 결과를 디스플레이한다.

3. 지능적 발표 도구 메타데이타 제안 및 보수

정보 신경 시스템이 (예를 들어 문서의 저자와 같은) 발표 도구에 의해 저장된 메타데이타에 의존하는 않는 반면, 이러한 이용 가능하고 신뢰할 만한 메타데이타를 갖는 것이 유리할 수 있다. 종래 기술이 갖는 하나의 문제점은 (예를 들어 마이크로소프트 워드, 아도베 아크로뱃 등과 같은) 발표 도구는 메타데이타 생성 및 보수 처리르 지능적으로 관리하지 못한다는 것이다. 메타데이타 생성 및 보수 처리를 더 좋게 하기 위해 본 발명에 따른 바람직한 실시예가 사용될 수 있는 몇 가지 방법이 이하 기술된다.

a. 사용자가 새로운 문서를 생성할 때, (단순히 저자의 이름이라기보다는) 문서의 메타데이타 헤더에 저자의 이메일 주소를 추가한다. (이러한 것은 사용자의 이메일 클라이언트로부터 프로그램적으로 검색될 수 있고, 사용자가 몇 가지 주소를 갖는 경우에 발표 도구는 사용자에게 어느 주소를 사용할 것인지를 상기시켜야 한다.) 이는 이메일 주소가 훨씬 더 고유성을 제공하기 때문이다. (예를 들어, 명 칭 '존 스미스'는 수많은 사람들 중 하나로 지칭될 수 있다. 따라서 이러한 맥락에 따라 문서의 메타데이타 내의 이러한 데이타의 존재는 유용하지 않다.) 메타데이타 헤더 내에 사용되는 하나의 가능한 이메일 주소는 (예를 들어 마이크로소프트 패스포트^TM와 같이) 사용자의 단일 서명 계정에 대한 기록(logged)으로부터 검색될 수 있다.

b. (메타 데이타 내에 표시된 바와 같이) 문서가 편집되고 현재 사용자가 문서의 저자와 다르다면, 그에 따라 그/그녀가 메타데이타 헤더를 변화시키기를 원하면 사용자를 자극하라. 이는 지능형 메타데이타 보수의 몇가지 기본 기반을 제공한다.

발표 도구가 필드를 유효하게 할 수 있는 경우에 (즉, 사용자의 명칭 및 이메일 주소에 현재 기록의 경우와 같이) 다른 객체 타입 및 메타데이타 필드를 가로질러 이러한 모델이 적용될 수 있다.

P. 정보 신경 시스템 ^TM 에 대한 시맨틱 쓰레드 규격

1. 시맨틱 쓰레드

개 요

바람직한 실시예에서, 시맨틱 쓰레드는 주석 또는 대화의 쓰레드를 대표하는 KIS 시맨틱 네트워크 내의 객체이다. 그들은 또한 시맨틱이라는 점에서 정상적인 이메일 쓰레드와 다르며, 따라서 그들은 객체 식별자 및 타입 식별자(OBJECTTYPEIDTHREAD 식별자) 쓰레드 특유의 시맨틱 링크를 가지며, 하나 이상의 온톨로지(ontology) 기반 지식 도메인을 통해 의미를 전달하고, 동적 링크를 지원한다. 따라서, 그들이 정보 신경 시스템 내에 일급 객체이므로, 그들은 쿼리되고, 복사되고, 붙여지고, 드래그되고, 드롭되며, 또한 스마트 및 객체 렌즈와 함께 사용될 수 있다. 도 23은 시맨틱 쓰레드 객체 및 그 시맨틱 링크를 설명한다.

시맨틱 쓰레드 객체가 시맨틱 네트워크와 전체 정보 신경 시스템의 일급 구성 요소이므로, 시스템 내에서 다른 객체와 같이 조작, 프레젠테이션, 및 쿼리될 수 있다. 예를 들어, 시맨틱 브라우저는 사용자가 사람 객체로부터 (PREDICATETYPEID_PARTICIPANTOPTHREAD인 서술어 타입 ID를 갖는 "참석자" 서술어를 통해) 사람이 참석하고 있는 모든 쓰레드로 네비게이션하는 것을 허용할 것이다. 그런 다음 사용자는 쓰레드로부터 모든 쓰레드의 참석자(사람)을 네비게이션할 수 있고 그때로부터 계속하여 동적으로 네비게이션할 수 있다. 또 다른 예시를 위해, 쓰레드 객체는 또한 주어진 컨텍스트에서 최상 의견일 수 있다(또는 아무것도 설명되지 않았다면 절무(none)임).

바람직한 실시예에서, 시맨틱 쓰레드 객체는 또한 의미를 전달한다. 이러한 것은 시스템 내에서 시맨틱 쿼리를 통해 쓰레드가 반환될 수 있다는 것을 의미하므로 유리하다. 예를 들어, "토픽 A 및 토픽 B에 대한 모든 쓰레드를 나에게 찾아줘라(Find me all threads on Topic A and Topic B)"가 있다. KIS는 문서와 같은 다른 객체를 사용하여 수행되는 것과 똑같이 시맨틱 쓰레드를 위한 시맨틱 링크를 유지한다. 그러나, 시맨틱 쓰레드가 복수의 객체를 참조할 수 있으므로, 쓰레드의 시맨틱은 쓰레드가 포함하는 객체를 사용하여 진화한다. 예를 들어 쓰레드는 하나 의 토픽으로 시작할 수 있고 다른 토픽을 포함하도록 빠르게 진화할 수 있다. 이메일 쓰레드는 그들이 시작하는 곳으로부터 매우 상이한 "시맨틱 도메인" 내에 종결될 수 있으며, 따라서 참석자는 새로운 견해를 도입하고, 새로운 정보가 쓰레드에 추가되며, 이메일 첨부가 쓰레드에 추가될 수 있으며, 모든 것이 의미의 기반에 있다.

KIS는 시맨틱 쓰레드의 "시맨틱 진화"를 관리한다. 쓰레드의 컨텐츠를 "트랙"하기 위해 쓰레드에 시맨틱 링크를 추가함으로써, KIS는 이러한 것을 행한다. 예를 들어, 쓰레드가 하나의 문서와 하나의 주석으로 시작되면, KIS는 문서 및 주석의 카테고리가 속하는 각각에 대한 쓰레드에 시맨틱 링크를 추가한다. 즉, 당연히 쓰레드는 그것이 포함되는 문서 및 주석과 동일한 시맨틱을 갖는다. 또 다른 주석이 쓰레드에 추가되면(예를 들어, 사용자가 제1 주석을 주석하면), KIS는 쓰레드로부터 이미 떨어져 링크된 새로운 주석의 카테고리에 대한 새로운 링크 세기를 계산한다. 새로운 주석이 특정 견해로부터 전체 쓰레드의 시맨틱을 약화시키거나 강화시킬 수 있으므로 KIS가 이를 행한다면 양호하다. 그러나, 쓰레드로부터 이미 떨어져 존재하는 카테고리에 대한 시맨틱 링크의 세기의 이러한 수정은 단위 카테고리 기반으로 행해지는 것이 양호하며, 따라서 다른 객체를 사용함에 따라 쓰레드는 다른 세기를 갖는 복수의 카테고리에 속할 수 있다. 새로운 링크 세기는 적어도 두 가지 방식으로 계산될 수 있는 데, 단순한 실시예에서는, 쓰레드에 링크된 카테고리에 대한 모든 링크 세기의 평균을 사용한다. 그러나, 이러한 것은 약한 세기의 쓰레드 내의 너무 많은 아이템들이 전체 쓰레드의 (KIS 시맨틱 쿼리 프로세 서가 관련되는 한) "지각된(perceived)" 시맨틱을 진화시킬 수 있는 단점을 갖는다. 또 다른 실시예는 최대 링크 세기를 사용하는 것이다. 그러나, 이것 또한 심지어 쓰레드가 새로운 도메인/카테고리로 "이동되어 있는(has moved on)" 경우에도 쓰레드의 시맨틱이 하나의 도메인/카테고리에 여전히 고정될 수 있는 단점을 갖는다. 가중치 평균 전망으로부터, 쓰레드의 크기가 성장함에 따라, 이러한 것은 혼동된 결과를 반환할 것이다.

바람직한 실시예에서, KIS는 쓰레드에 링크된 카테고리에 대한 모든 링크 세기의 가중치 평균을 계산한다. 이러한 새로운 가중치 평균이 링크 세기가 된다. 바람직하게는 쓰레드 내에 각각의 객체 내의 개념의 수를 사용하여 가중치 평균이 계산된다. 이러한 것은 (짧은 우편물과 같이) "시맨틱적으로 가벼운" 객체들이 (이메일 첨부 및 긴 우편물와 같이) 쓰레드 내의 "시맨틱적으로 조밀한" 객체에 관련된 쓰레드의 시맨틱을 손상시키지 않는 것을 보장하는 장점이 있다. 객체의 크기는 객체의 개념 가중치의 보다 덜 신뢰할만한 표시기이므로, 바람직한 실시예에서 크기가 아닌 개념의 수가 양호하게 사용된다. 예를 들어, 문서는 이미지를 포함할 수 있고 또는 주요한 구문 또는 개념에 잘 매핑되지 않는 많은 정보를 포함할 수 있다.

바람직하게는, 계산된 가중치는 또한 항목이 추가될 때의 시간을 포함할 수 있다. (그에 따라, 새로운 아이템에 대한 오래된 아이템의 시맨틱을 "에이징"한다.) 그런 다음 이러한 가중치는 카테고리 링크 세기에 의해 곱해지고, 곱들이 더해진 다음에 항목의 개수에 의해 나눠진다. 다른 가중치 방법이 적용될 수도 있다.

새로운 아이템이 시맨틱 네트워크에 추가될 때 다음 규칙이 적용되며, 시맨틱 쓰레드에 추가되는 것은,

1. 쓰레드에 추가될 새로운 아이템을 카테고리화한다.

2 시맨틱 쓰레드 상에 이미 존재하는 카테고리의 반환된 리스트 내의 각각의카테고리에 대해,

{

새로운 가중치 평균 링크 세기를 계산하고,

시맨틱 쓰레드 객체에서 떨어져 카테고리 시맨틱 링크를 갱신 한다

}

3. 시맨틱 쓰레드 상에 이미 존재하지 않는 카테고리의 반환된 리스트 내의 각각의 카테고리에 대해,

{

링크 세기를 할당하고,

시맨틱 쓰레드 객체에서 떨어져 카테고리 시맨틱 링크를 추가한다.

}

가중치 평균 링크 세기는 다음과 같이 계산된다.

Ci는 객체 i의 개념의 정규화된 수(0 내지 1)이고, Li는 객체 i의 링크 세기이며, N은 (새로운 객체를 포함하여) 쓰레드 내의 객체의 수이다. 개념의 정규 화된 구는 (지식 도메인 관리자(Knowledge Domain Manager:KDM)에 의해 추출된)각각의 객체 내의 개념의 수를 (새로운 객체를 포함하는) 쓰레드 내의 최대 객체 내의 개념의 수로 나눔으로써 계산될 수 있다.

시맨틱 쓰레드가 표준의 내재적인 (그리고 편집되지 않은) 이메일 쓰레드를 포함하면, KIS는 시맨틱 네트워크를 다르게 수정한다. 이러한 것은 대부분의 이메일 클라이언트가 최근 이메일 메시지 내에 쓰레드를 형성하는 모든 선행하는 이메일 메시지를 포함하기 때문이다. 이러한 맥락에서, 이 경우에는, 바람직하게는 KIS가 전체 쓰레드의 대표로서 최근 이메일 메시지를 단순히 사용한다. 이를 달성하기 위해, KIS는 바람직하게는 최근 이메일 메시지를 카테고리화하고, 쓰레드 객체로부터 (카테고리와 관련된) 선행하는 모든 시맨틱 링크를 새로운 카테고리 및 링크 세기와 대응하는 새로운 시맨틱 링크로 대체한다.

(예를 들어, 시맨틱 네트워크 내의 기존의 객체의 주석에 기반하여 형성된 쓰레드와 같은) 비 이메일 쓰레드에 대해, 전술한 모델이 사용되어야 한다. 이와 달리, KIS는 이후에 카테고리화될 집합 쓰레드 문서(Aggregate Thread Document: ATD)를 유지할 수 있다. 이러한 문서는 쓰레드 내에 객체의 텍스트를 포함해야 하며, 이는 이메일 메시지가 동일한 쓰레드 내에 선행하는 메시지의 텍스트를 포함하는 방법과 대체로 유사하다.

새로운 객체가 쓰레드에 추가될 때, KIS는 바람직하게는 시맨틱 메타데이타 스토어(Semantic Metadata Store :SMS) 내의 쓰레드 객체가 최종 수정 시간을 갱신한다.

2. 시맨틱 쓰레드 대화

정보 신경 시스템 내의 시맨틱 쓰레드 대화는 시맨틱 쓰레드의 독특한 형태이다. 필연적으로 대화는 하나 이상의 참가자를 갖는 시맨틱 쓰레드이다. 시맨틱 쓰레드 대화는 객체 타입 id, OBJECTTYPEID_THREADCONVERSATION을 갖는다.

KIS는 그 쓰레드 내의 참가자의 수에 기반하여 쓰레드를 생성하고, 쓰레드 대화로서 쓰레드를 즉시 생성할 수 있다. 이와 달리, 추가 참가자가 감지되는 경우에, KIS가 대화에 대한 쓰레드를 "갱신"할 수 있다.

3. 시맨틱 쓰레드 관리

이하 의사 코드는 KIS가 바람직한 쓰레드 및 대화를 시맨틱 네트워크에 추가하는 방법을 설명한다.

1. 개별 이메일 메시지가 감지되고 기존의 쓰레드 객체의 구성원이면,

{

ㆍ 쓰레드에 새로운 이메일 객체를 추가하고 시맨틱 네트워크를 갱신한다.

ㆍ쓰레드가 하나 이상의 참가자를 가지면, 쓰레드의 객체 타입 식별자를 OBJECTTYPEID_THREADCONVERSATION으로 변경한다.

}

2. 이메일 쓰레드가 감지되면,

{

ㆍ새로운 쓰레드 객체를 생성하고 시맨틱 네트워크를 갱신한다.

ㆍ쓰레드가 하나 이상의 참가자를 가지면, 쓰레드의 객체 타입 식별자를 OBJECTTYPEID_THREADCONVERSATION으로 변경한다.

}

3. 기존 객체의 이메일 주석이 감지되면,

{

ㆍ시맨틱 네트워크에 주석을 추가한다.

ㆍ주석된 객체가 주석 자체가 아니면,

{

ㆍ새로운 쓰레드 객체를 생성하고 시맨틱 네트워크를 갱신한다.

}

ㆍ그렇지 않으면

{

ㆍ(예를 들어 기존 주석과 같은) 주석된 객체를 포함하는 쓰레드에 새로운 주석을 추가하고 시맨틱 네트워크를 갱신한다.

ㆍ갱신된 쓰레드가 하나 이상의 참가자를 가지면, 쓰레드의 객체 타입 식별자를 OBJECTTYPEID_THREADCONVERSATION으로 변경한다.

}

}

Q. 샘플 스크린 샷

도24-44b는 전술한 기능, 옵션, 연산을 추가로 설명하는 추가적인 스크린 샷 이다.

R. 정보 신경 시스템용 시맨틱 쿼리 정의 및 가시화에 대한 규격

1. 시맨틱 영상 및 움직임

a. 개요

시맨틱 영상 및 움직임은 Nervana 시맨틱 사용자 경험의 견지에서 바람직한 실시예의 유리한 구성요소일 수 있다. 즉, 시스템과 함께 사용자의 경험은 Nervana 에이전시 (정보 커뮤니티) 상에 저장되고 Nervana XML 웹 서비스를 통해 접근되는 시맨틱 영상/움직임 메타데이타를 갖는 실시예에서 향상될 수 있다. 그 실시예에서, Nervana를 통해, 단말 사용자는 그 영상에 컨텍스트 및 시간 민감성 시맨틱 접근할 수 있다. 오직 예시로서, 이메일 메시지 상에 스마트 렌즈와 같은 게티 영상(Getty Images)(또는 코르비스(Corbis)) 에이전트를 사용한다고 생각하며, 따라서, 호출될 때, 이는 메시지에 시맨틱적으로 관련된 영상을 열 것이다. 또는 시맨틱적으로 관련된 영상을 보기 위해 당신의 하드 드라이버로부터 게티 에이전트로 문서를 드래그 앤드 드롭한다고 생각하자. 이는 (영상 스키마와 상호 일치하는) 영상 메타데이타를 갖는 것을 포함할 것이다. Nervana 공구상자는 동일성을 유지하며, 우리는 단지 영상용 새로운 정보 객체 타입을 추가한다. 또한,다른 보기, 섬네일(thumbnails), 슬라이드 쇼, 필터링, 컬렉션 등과 같은 시맨틱 영상용 시맨틱 스킨이 있다. 시맨틱 영상의 예를 위해서는 아래를 방문하자.

http://creative.gettyimages.com/source/search/resultsmain.asp?source=advSearch＆hdnSync=Medicine%7EO%2C12%2C449%2C3%2C15%2C1%2C0%2C0%2C0%2C12287%2C0 %2C7%2C14%2C6%2C3%2C3%2CO%2C12%2C449%2Cen%2Dus＆UQR=tfxfwz

매우 일반적으로, 시맨틱 가시화의 특성은 몇 가지 다른 변수에 따라 달라질 것이다. 이러한 변수 중에서, 시스템의 어떤 특징 또는 특성의 컨텍스트가 호출되는 지는 포함하는 컨텍스트가 종종 있을 것이다. 이하 몇 개의 섹션에서, 시맨틱 결정에 영향을 미치는 컨텍스트 변수 중 몇가지가 리스트 및/또는 설명될 것이다. 많은 경우에, 변수의 중첩 또는 공통성 또는 시맨틱 가시화의 결정요소(determinant)가 있겠지만, 어떤 경우에는 고려 대상 또는 고려 대상의 결합은 특정 상황에 대해 고유할 것이다.

b. 산업-특유의 시맨틱 영상 및 움직임

산업-특유의 시맨틱 영상/움직임은 (산업에 매핑되는) 하나 이상의 카테고리에 대한 시맨틱 결과용 프레젠테이션 분위기의 일부로서 사용될 수 있는 (그리고 바람직한 실시예에서 사용되는) 영상/움직임이다. 예를 들어, http://www.corbis.com 과 http://www.gettyimages.com을 방문하고, (집합 내에서 산업-표준 분류에 기반하여 목표 산업에 매핑된) 이하 리스트된 키워드용 검색을 입력한다. 이러한 영상/움직임은 (컨텍스트 템플릿 및 카테고리에 매핑된) 컨텍스트 및 카테고리 스킨을 위한 배경, 필터 효과, 변환 및 애니메이션으로서 사용될 수도 있다. 또한, 이들 영상/움직임은 상위 스크린세이버를 위한 이들 영상 중 몇 가지로부터 추출된 움직임 경로을 위한 비주얼로 사용될 수 있다. 예를 들어, 다른 주위의 영상 및 애니메이션등을 갖는 크로움을 따라 (예를 들어 "전기" 산업을 위한 전구 내로 회전하는 메타데이타와 같은) 이들 시맨틱 영상 중 하나로부터 추 출된 움직임 경로를 따른 가시화와 메카데이타를 디스플레이하는 스킨을 생각하자. 산업 특유의 영상과 움직임을 갖는 다른 산업들은 아래와 같이 포함할 수 있다.

예를 들어, 사용자가 요청/에이전트, 즉, 생명정보학 또는 단백질 공학에 대한 헤드라인을 새로 시작하면, 시맨틱 브라우저는 SQML로부터의 바이오 공학 관련 카테고리를 바이오 공학 산업 내의 영상 세트에 매핑할 것이다. 그런 다음 요청/에이전트의 결과에 대한 스킨의 부분으로서 하나 이상의 영상을 디스플레이할 것이다. (이에 따라 요청/에이전트의 "경향"을 시각적으로 전달하면서 유쾌한 사용자 경험을 제공한다).

도101은 (코르비스 웹 사이트로부터 라이센스받은, 왼쪽의 인간 얼굴과 오른쪽의 유기 화학 차트에 대해 중첩된 예술적인 DNA 나선형인) 약리학/바이오 공학 산업에 대한 샘플 시맨틱 영상이다.

동일한 것이 정보 타입 및 컨텍스트 템플릿에 적용된다. 스킨은 컨텍스트/정보 타입 및 카테고리/온톨로지에 기반하여 스마트 행위를 수행하고, 지능적으로 이들 특성 사이에 시맨틱 영상/움직임을 혼합시키고 매칭시킨다. 예를 들어, "무선 공학에 관한 헤드라인(Headlines on Wireless Technology)"라고 명명된 에이전트는 "헤드라인" 영상/움직임과 "무선" 영상/움직임 사이를 토글링하면서 영상/움직임 기반 애니메이션을 보여주는 크롬(및/또는 스마트 모래시계 - 이하 참조)를 가질 수 있다. "무선에 관한 헤드라인과 반도체에 관한 속보와 제품 규격에 관련되어 내 그룹의 누군가에 의한 이메일"이라고 명명된 블렌더는 "헤드라인", "뉴스", "무선", "반도체" 및"이메일"을 위한 영상/움직임 사이에 "토글"하는 크롬(및/또는 스마트 모래시계)을 가질 수 있다.

프리젠터의 쿼리 프로세서는 (에이전트/블렌더 SQML로부터) 모든 카테고리와 모든 컨텍스트 템플릿 및 정보 타입을 열거하고 이에 따라 크롬 애니메이션을 설정할 수 있다.

정보 타입에 대해, (예를 들어 코르비스 및 케티 상에) 아래 검색어를 입력한다.

또한, 컨텍스트 템플릿에 대해 아래 검색어를 입력한다.

또한, 시맨틱 영상/움직임은 완전히 랜덤하지 않는 것이 양호하다는 것을 주목하자. 그러나, 그들은 모두 한정된 세트로부터 오는 것이 아니다. 바람직하게는, 그들이 조심스럽게 선택된 다음에 스킨들이 주어진 세트로부터 랜덤하게 선택될 수 있다. 그러나, 바람직하게는 그들은 예를 들어 코르비스 또는 게티 영상에 대한 모든 세트로부터 랜덤하지 않다. 그렇지 않다면, 바보같은 영상, 카툰, 몇 가지 잠재적으로 불쾌하거나 부적절할 수 있는 영상이 있을 수 있다. 또한, 바람직하게는, 이들 안내 중 몇가지는 스킨 주제가 미미한 모드, 온화한 모드, 흥분되는 모드 또는 극도로 흥분되는 모드인지에 따라 다르게 변화한다. 미미한 모드에서, 스킨은 가시화 피벗마다 하나의 영상/움직임을 선택하는 것을 결정할 수 있다. 다른 모드에서, 이러한 것은 지루한 사용자 경험을 일으킬 수 있다.

낮은 섬광(low-flashiness) 모드에서, 스킨은 (예를 들어 알파-혼합된) 파워포인트 슬라이드 데크 배경과 다르지 않는 크롬의 일부로서 시맨틱 영상/움직임을 사용할 수 있다. 시맨틱 영상/움직임은 (컨텍스트 바, 패널 또는 파렛트 상에) 가시화의 일부 내는 물론 스마트 모래시계(이하 참조) 내에 사용될 수도 있다. 컨텍스트 및 정보 타입을 가시화하기 위해, 시맨틱 영상/움직임은 바람직하게는 정보 타입 또는 컨텍스트를 명확하게 나타내기 위해 조심스럽게 선택된다. 또한, 선택 모드가 또한 스킨 특성일 수도 있다.

또한, 스킨마다 사용되는 가능한 시맨틱 영상/움직임의 수는 영상/움직임이 디스플레이되는 위치에 따라 캐핑(capping)될 필요가 있을 것이다. 그러나, 몇 가지 시나리오에서, 이러한 것이 필요하지 않을 수 있다. 예를 들어, 블렌더 스킨은 블렌더로부터 현재 디스플레이되는 것과 상호 일치하도록 (면에서 면으로 또는 에이전트에서 에이전트로) 사용자가 블렌더 결과를 네비게이션함에 따라 크롬 배경 사이에서 순환할 수 있다. 이러한 것은 스킨 특성일 수도 있다.

c. 클라이언트측 시맨틱 영상 및 움직임 캐쉬

프리젠터는 다운로드되어 (설치되는 동안에) 클라이언트에 저장되는 시맨틱 영상 및 움직임을 갖는 스마트 확장가능 클라이언트측 캐쉬를 갖는다. 그런 다음 스킨은 이들 사전 캐쉬된 영상 및 움직임으로부터 선택할 수 있다. 영상/움직임은 표적 산업에 매핑된 사용자의 즐겨찾기 카테고리 및 (그/그녀가 선택한) 흥미 영역에 기반하여 사전 캐쉬될 수 있다. 그런 다음 스킨은 (Nervana 또는 코르비스 또는 게티 영상과 같은 제3자에 의해 호스팅된 서버측 영상/움직임을 공표하는 XML 웹 서비스인) 영상 서버로의 주문형(on-demand) 영상 쿼리를 사용하여 사전 캐쉬된 시맨틱 영상/움직임을 보완할 수 있다.

프리젠터는 또한 최근 다운로드된 영상/움직임이 (타이브레이커(tiebreaker)로서) 오래된 것들 이전에 선택되도록 스마트 행위를 수행하고 바이어스 기능을 가질 것이다. "사용 계수"는 또한 각각의 영상/움직임과 함께 캐쉬되며, 따라서 프리젠터는 이 계수를 사용하여 어느 영상/움직임이 언제 디스플레이되는 지를 필터링한다. 이러한 "부하 분산(load balancing)"은 더 신선하고 되풀이되지 않는 사용자 경험을 얻게 할 것이다.

캐쉬는 바람직하게는 (사용자의 시맨틱 쿼리에 기반하여) 주문형으로 채워지게 되므로, 예를 들어 보잉에 있는 사용자의 머신을 위해 약리학 영상/움직임을 사전 캐싱하는 것은 소용없는 일이다. 바람직하게는, 캐쉬 크기도 또한 캐핑되면, 영상 캐쉬 관리자는 바람직하게는 LRU 알로리즘 또는 동등물을 사용하여 "오래된" 그리고 "미사용" 영상을 제거한다. 이런 식으로, 캐쉬는 사용자의 에이전트 사용 패턴 및 즐겨찾기 에이전트 리스트를 사용하여 "시맨틱 동기(semantic sync)" 내에 있을 수 있다.

2. 스마트 모래시계

Nervana 프리젠터가 "시맨틱 사용자 경험"을 제공하게 될 호출의 대부분은 아마도 XML 웹 서비스로의 리모트 호출일 것이다. 이러한 맥락에서, UI 내에 예측할 수 없고 잠재적으로 무제한인 지연이 있을 것이다. 어떤 사람은 기업 내에서 상당한 양의 대역폭과 서버 마력을 기대할 수 있지만, Nervana 사용자 인터페이스는 방법 호출에서 미지의 지연을 여전히 "계획"해야한다.

운용 시스템은 오늘날 디스크 또는 네트워크에 대한 무제한인 I/O 호출을 갖는 이러한 문제점을 갖는다. 어떤 CPU 밀착형 연산도 실질적인 지연을 갖는다. 윈도우 및 Mac UI에서, 사용자는 대개 "모래시계" 형상인 "대기" 커서를 통해 지연을 인식하게 된다.

바람직한 실시예에서, 프리젠터는 "스마트 또는 시맨틱 모래시계"의 동등물을 디스플레이할 수 있는 시맨틱 힌트를 가질 것이다. 이는 "로딩(loading)" 또는 다른 효과를 디스플레이하는 중간면의 형태일 수 있다. 또한, 프리젠터는 쿼리가 대표하는 카테고리와 정보 타입 또는 컨텍스트 템플릿에 대한 힌트를 얻기 위해 SQML 을 판독함으로써 쿼리의 시맨틱을 전달할 수 있다. 그런 다음 프리젠터는 비록 그 결과를 수신하지 않았더라고 이들 힌트를 사용하여 쿼리와 상호 일치하는 시맨틱 영상 및 텍스트를 디스플레이할 수 있다. 쿼리가 더 많은 힌트를 가질수록, 모래시계는 더 스마트할 수 있다. 그런 다음 심지어 실제 결과가 웹 서비스로부터 도착되고 (필요하다면) 최종 결과를 생성하는 프리젠터에 의해 병합되기 전일지라도, "로딩"면이 "출현하게 될 것"의 분위기를 전달할 수 있다.

이러한 "스마트 모래시계"는 주 결과창 상에 뿐만 아니라 아마도 (필연적으로 웹 서비스의 모든 호출 사이트에 그리고 "초점"이 있는 곳에) 스마트 렌즈 풍선 팝업 윈도우 및 인라인 미리보기 윈도우 상에도 디스플레이될 수 있다. 프리젠터는 "모래시계"를 디스플레이하기 전에 (아마도 수백 밀리초 후에 - 이를 위한 도면에 도착한 유용성 테스트를 구현이 사용해야 함) 쿼리에 대한 중단(timing out)에 의해 스마트 행위를 수행할 수 있다.

3. 가시화 - 컨텍스트 템플릿

서 론

컨텍스트 템플릿은 정보 접근 및 검색에 대한 독특한 시맨틱 모델에 매핑하는 시나리오 구동형 정보 쿼리 템플릿이다. 필연적으로, 컨텍스트 템플릿은 사전 정의된 시맨틱 템플릿을 사용함으로써 사용자에게 정보를 전달하는 개인적인 디지탈 시맨틱 정보 검색 "채널"로 생각될 수 있다. 컨텍스트 템플릿은 바람직하게는 하나 이상의 에이전시를 거쳐서 정보를 컬렉션한다.

이하 설명된 컨텍스트 템플릿은 정의되어 있다. 다양한 타입의 시맨틱 정보의 통합 및 배급을 향해 의도되는 추가적인 컨텍스트 템플릿이 고려된다. (이러한 예는 예를 들어 "화", "슬픔" 등과 같은 감정과 관련된 컨텍스트 템플릿과, 위치, 유동성, 주위 환경, 사용자 임무 등과 같은 컨텍스트 템플릿을 포함한다.)

속보

속보 컨텍스트 템플릿은 시맨틱 정보를 전달하는 방법에서 CNN의 "속보" 프로그램 삽입의 개인적인 디지탈 버전과 유사할 수 있다. 컨텍스트 템플릿은 하나 이상의 에이전시로부터 아주 빠르게 알려져야하고 정보 생성 또는 공표 시간 및 정보 중요성을 정의하는 형성 가능한 시간 양에 관한 정보에 따라 분류된 정보에 사용자가 접근하는 것을 허용한다.

도102는 속보 컨텍스트 템플릿을 위한 시맨틱적으로 적절한 영상 가시화를 도시한다.

속보 - 샘플 객체 및 컨텍스트 바 가시화

이하에 속보 컨텍스트에 적적한 가시화의 샘플 또는 대표 구성 요소의 리스트가 있다. 바람직한 실시예에서 모든 가시화(또는 그 구성 요소)와 마찬가지로, "경향" 또는 시맨틱 감정 또는 코노테이션(connotation)이 특정 컨텍스트에 적절할 것이다. 매우 대체적인 유추로서, "세트"가 영화를 위한 시나리오에서 특정 장면에 적절해야 하는 것과 마찬가지로 가시화는 애플리케이션 내의 컨텍스트에 적절할 것이다. 이는 이러한 특정 객체 및 컨텍스트 바 가시화는 물론 바람직한 실시예에서의 모든 가시화에 대해 사실일 것이다.

1. 임박한 속보 아이템의 총 개수의 배경 위에 최신 또는 진행중인 속보 아이템의 공표 또는 스케줄링된 시간을 보여주는 똑딱거리는 시계

2. 시맨틱 영상 위에 최신 또는 진행중인 속보 아이템의 공표 또는 스케줄링된 시간을 보여주는 똑딱거리는 시계

3. 시맨틱 영상 및 속보 아이템의 총 개수 위에 최신 또는 진행중인 속보 아이템의 공표 또는 스케줄링된 시간을 보여주는 똑딱거리는 시계

4. 평이한 배경 위에 최신 또는 진행중인 속보 아이템의 공표 또는 스케줄링 된 시간을 보여주는 똑딱거리는 시계

5. 여러 가지 배경 위에 모든 속보 아이템의 공표 또는 스케줄링된 시간을 (순차적으로) 보여주는 똑딱거리지 않는 시계

6. 여러 가지 배경 위에 최근 또는 진행중인 속보 아이템의 공표 또는 스케줄링된 시간을 보여주는 달력 보기

7. 여러 가지 배경 위에 모든 속보 아이템의 공표 또는 스케줄링된 시간을 (순차적으로) 보여주는 달력 보기

8. 최근 또는 진행중인 속보 아이템의 공표 또는 스케줄링된 시간에 따라 크기가 달라지는 폰트 크기

9. 속보의 개수에 따라 크기가 달라지는 폰트 크기

10. 최근 또는 진행중인 속보 아이템의 공표 또는 스케줄링된 시간에 따라 애니메이션 속도가 달라지는 (예를 들어 반짝거리는 텍스트, 회전하는 텍스트, 움직임 경로 위의 텍스트 등과 같은) 애니메이션된 폰트

11. 속보 아이템의 개수에 따라 애니메이션 속도가 달라지는 (예를 들어 반짝거리는 텍스트, 회전하는 텍스트, 움직임 경로 위의 텍스트 등과 같은) 애니메이션된 폰트

12. 최근 또는 진행중인 속보 아이템의 공표 또는 스케줄링된 시간에 따라 달라지는 폰트 색깔

13. 속보 아이템의 개수에 따라 달라지는 폰트 색깔

14. 속보 시맨틱 영상 또는 동등물의 애니메이션된 그래픽

15. 속보 아이템의 개수

16. 순차적으로 애니메이션된 속보 아이템의 제목 (리스트 보기)

17. 순차적으로 애니메이션된 속보 아이템의 제목과 상세 내역 (타일형 보기)

18. 객체 주위에 환상 궤도의 움직임 경로 위를 움직이는 시맨틱 영상/움직임

19. 시맨틱 영상/움직임 배경 위에 아이템의 개수를 보여주는 풍선 팝업

20. 평이한 배경이지만 시맨틱 영상/움직임으로 애니메이션된 아이템의 수를 보여주는 풍선 팝업

헤드라인

헤드라인 컨텍스트 템플릿은 시맨틱 정보를 전달하는 방법인 점에서 CNN의 "헤드라인 뉴스" 프로그램의 개인적인 디지털 버전과 유사할 수 있다. 컨텍스트 템플릿은 정보 "신선도"를 정의하는 정보 생성 또는 공표 시간과 시간 또는 아이템 수의 형성 가능한 양에 따라 분류된 사용자가 하나 이상의 에이전시로부터의 정보 헤드라인에 접근하는 것을 허용한다. 예를 들어, CNN의 "헤드라인 뉴스"는 (24시간 계속하여) 매 30분마다 헤드라인을 디스플레이한다. 바람직한 실시예에서, 헤드라인 컨텍스트 템플릿은 순서대로 체인 연결된 다음과 같은 서브 쿼리(오늘 공표된 추천(Recommendations Published Today), 오늘 공표된 즐겨찾기(Favorites Published Today), 오늘 공표된 최적 의견(Best Bets Published Today), 오늘 및 내일 도래할 임박한 이벤트(Upcoming Events Occurring Today and Tomorrow), 오늘 공표된 주석 아이템(Annotated Items Published Today))들을 사용하여 서버 상의 SQL 쿼리로서 구현될 것이다.

바람직하게는, 모든 서브 쿼리들이 공표 일자/시간에 의해 분류된 다음에 서로 체인 연결될 것이다. 추가적인 필터들이 SQML 내에 서서술어 리스트에 기반하여 쿼리에 적용될 것이다. 전술한 원리들은 도103에 도시되어 있는데, 도103은 스마트 모래시계를 위한 샘플 영상, 틈새면, 전이 효과, 배경 크롬 등과 같은 헤드라인 가시화이다.

대화 컨텍스트 템플릿

대화 컨텍스트 템플릿은 시맨틱 정보를 전달하는 방법인 점에서 CNN의 "의견충돌(Crossfire)" 프로그램의 개인적인 디지탈 버전에 유사할 수 있다. 정보 보급을 위한 컨텍스트으로서 대화와 토론을 사용하는 "의견충돌"과 같이, 바람직한 실시예에서, 대화 컨텍스트 템플릿은 이메일 발송, 주석 및 관련 정보에 대한 쓰레드를 추적한다.

대화 컨텍스트 템플릿은 다음과 같은 정보 객체 타입을 포함한다.

1. 적어도 하나의 쓰레드 깊이를 갖는 이메일 (이메일 메시지에 대한 하나의 이메일 답신)

2. 적어도 하나의 쓰레드 깊이를 갖는 주석 (객체의 주석의 주석)

3. 인터넷 뉴스 발송 (뉴스 발송에 대한 뉴스 발송 답신)

쿼리는 쓰레드 깊이에 의해 분류될 것이다. SQML 내에 서술어 리스트에 기반하여 쿼리에 추가 필터들이 적용될 것이다. 또한, 컨텍스트 스킨은 쓰레드에 의 해 정보 아이템을 디스플레이해야 한다.

도104는 (한 책상에서 일하고 있는 두 사람에 대한) 스마트 모래시계에 대한 샘플 영상, 틈새면, 전이 효과, 배경 크롬 등과 같은 가시화이다.

대화 컨텍스트-샘플 객체 및 컨텍스트 바 가시화

이하는 (삽입된) 대응하는 표시된 컨텍스트에 시맨틱적으로 적절한 가시화 구성 요소의 특성 또는 고찰 리스트이다.

1. 시맨틱 영상/움직임의 애니메이션된 그래픽 (아이콘 및 컨텍스트 안내 보기)

2. 평이한 배경 위의 최대 쓰레드 깊이 (아이콘 및 컨텍스트 안내 보기)

3. 시맨틱 영상/움직임의 최대 쓰레드 깊이 (아이콘 및 컨텍스트 안내 보기)

4. 순서대로 애니메이션된 대화의 제목 (리스트 보기)

5. 순서대로 애니메이션된 대화의 제목과 상세 내역 (타일형 보기)

6. 평이한 배경 위희 대화의 개수 (아이콘 및 컨텍스트 안내 보기)

7. 시맨틱 영상/움직임 위의 대화의 개수 (아이콘 및 컨텍스트 안내 보기)

뉴스메이커 컨텍스트 템플릿

뉴스메이커 컨텍스트 템플릿은 시맨틱 정보를 전달하는 방법인 점에서 NBC의 "언론을 만나다(Meet the Press)"의 개인적인 디지탈 버전과 유사할 수 있다. 이 경우에, 뉴스 자체 또는 대화와는 대조적으로 "뉴스 내의 사람"이 강조된다. 사용자는 정보 객체 피벗으로서 반환된 사람을 사용하여 네트워크를 네비게이션한다. 편집인 컨텍스트 템플릿은 바람직하게는 "사람" 또는 "사용자" 객체 타입 필터와 " 에 의해 저술된(authored by)", "에 의해 아마도 저술된(possibly authored by)", "에의해 호스팅된(hosted by)", "에 의해 주석된(annotated by)", "에 관한 전문가(expert on)" 등의 서술어 (사람을 정보와 관련시키는 서술어)를 갖는 헤드라인 컨텍스트 템플릿으로서 생각될 수 있다. "에 관련된(relevant to)" 디폴트 서술어는 바람직하게는 모든 밀접한 관련있는 특수 서술어를 포함하기 위해 사용된다. 뉴스메이커과 같은 관련 정보의 분류 순서는 헤드라인과 같이 "그들이 만든 뉴스(news they make)"의 순서에 기초하여 분류된다.

쿼리는 헤드라인의 수에 의해 분류될 것이다. SQML 내에 서술어 리스트에 기반하여 쿼리에 추가적인 필터가 적용될 것이다.

도105는 (풋볼 챔피언쉽) 스마트 모래시계, 틈새면, 전이 효과, 배경 크롬 등을 위한 시맨틱 "뉴스메이커" 가시화 또는 샘플 영상을 도시한다.

뉴스메이커 - 샘플 객체 및 컨텍스트 바 가시화

1. 대화하는 2명의 말하는 머리의 애니메이션된 그래픽 (아이콘 및 컨텍스트 안내 보기)

2. 시맨틱 영상/움직임의 애니메이션된 그래픽 (아이콘 및 컨텍스트 안내 보기)

3. 뉴스메이커의 총 수 (아이콘 및 컨텍스트 안내 보기)

4. 시맨틱 영상/움직임 위의 뉴스메이커의 총 수 (아이콘 및 컨텍스트 안내 보기)

5. 순서대로 애니메이션된 뉴스메이커의 명칭 (리스트 보기)

6. 순서대로 애니메이션된 뉴스메이커의 명칭 및 상세 내역 (타일형 보기)

임박한 이벤트 컨텍스트 템플릿

임박한 이벤트 컨텍스트 템플릿(그리고 그에 따른 특정 에이전트)는 임박한 이벤트에 대한 정보를 전달하는 특정 프로그램의 개인적인 디지털 버전과 유사할 수 있다. 예시는 "월드 시리즈(The World Series)", "NBA 결승전(The NBA Finals)", "축구 월드컵 결승전(The Soccer World Cup Finals)" 등과 같은 이벤트를 위한 특별 프로를 포함한다. 지식 노동자 시나리오에서 동등물은 하나 이상의 카테고리, 정보 또는 다른 정보 객체 피벗에 관련하는 모든 임박한 산업 이벤트를 모니터링하고자 하는 사용자이다. 바람직하게는 임박한 이벤트 컨텍스트 템플릿은 (바람직하게는 이벤트 및 시간 임계(criticality)를 내포(connotation)하는 시맨틱적으로 고유한 "컨텍스트 스킨"을 사용하여) 오직 임박한 이벤트가 필터링되고 디스플레이되는 것을 제외하고는 헤드라인 컨텍스트 템플릿과 동일하다.

도106은 스마트 모래시계, 틈새면, 전이 효과, 배경 크롬 등을 위한 시맨틱 "임박한 이벤트(Upcoming Events)" 가시화 또는 샘플 영상을 도시한다. (어포인트먼트 바인더(appointment binder)

임박한 이벤트 - 샘플 객체 및 컨텍스트 바 가시화

1. 임박한 이벤트의 총 개수의 배경 위에 다음 이벤트까지의 시간을 보여주는 똑딱거리는 시계 (아이콘 및 컨텍스트 안내 보기)

2. 시맨틱 영상/움직임 위에 다음 이벤트까지의 시간을 보여주는 똑딱거리는 시계 (아이콘 및 컨텍스트 안내 보기)

3. 시맨틱 영상/움직임 및 임박한 이벤트의 총 개수 위에 다음 이벤트까지의 시간 보여주는 똑딱거리는 시계 (아이콘 및 컨텍스트 안내 보기)

4. 평이한 배경 위에 다음 이벤트까지의 시간을 보여주는 똑딱거리는 시계 (아이콘 및 컨텍스트 안내 보기)

5. 여러 가지 배경 위에 모든 임박한 이벤트까지의 시간을 (순차적으로) 보여주는 똑딱거리지 않는 시계 (아이콘 및 컨텍스트 안내 보기)

6. 여러 가지 배경 위에 다음 임박한 이벤트의 스케줄링된 시간을 보여주는 달력 보기 (아이콘 및 컨텍스트 안내 보기)

7. 여러 가지 배경 위에 모든 임박한 이벤트의 스케줄링된 시간을 (순차적으로) 보여주는 달력 보기 (아이콘 및 컨텍스트 안내 보기)

8. 달력 움직임을 보여주는 애미메이션된 그래픽 (아이콘 및 컨텍스트 안내 보기)

9. (예를 들어 스케줄북인) 시맨틱 영상/움직임의 애미메이션된 그래픽 (아이콘 및 컨텍스트 안내 보기)

10. 시맨틱 영상/움직임 위희 임박한 이벤트의 총 개수 (아이콘 및 컨텍스트 안내 보기)

11. 평이한 배경 위의 임박한 이벤트의 총 개수 (아이콘 및 컨텍스트 안내 보기)

12. 순서대로 애니메이션된 임박한 이벤트의 명칭 (리스트 보기)

13. 순서대로 애니메이션된 임박한 이벤트의 명칭 및 상세 내역 (타일형 보 기)

디스커버리

디스커버리 컨텍스트 템플릿은 "디스커버리 채널(Discovery Channel)"의 개인적인 디지털 버전와 유사할 수 있다. 이 경우에는, 특정 토픽에 대한 "다큐멘터리"가 강조된다. 디스커버리 컨텍스트 템플릿은 주어진 카테고리 세트에 관련되고 선택적으로 사전결정된 형성 가능한 시간 주기 내에 발송되는 정보 객체를 무작위로 선택함으로써 정보의 지능적인 컬렉션을 시뮬레이션한다. 시간과는 대조적으로 시맨틱 가중치는 정보가 주문되거나 보여지게될 방법을 결정하기 위한 바람직한 중요성이다. 컨텍스트 템플릿은 카테고리화 서술어를 위한 시맨틱 링크 세기에 의해 모든 정보 타입을 필터링함으써 구현될 수 있다. 이 경우에, 필터는 '최적 의견' 필터보다 덜 민감해야하며, 따라서 컨텍스트 템플릿은 필터링의 견지에서 '최적 의견'과 '모든 아이템' 사이에 어딘 가에 위치된다.

도107은 스마트 모래시계, 틈새면, 전이 효과, 배경 크롬 등을 위한 "디스커버리" 가시화 또는 샘플 영상이다. (페트리 접시(petri dish))

디스커버리 - 샘플 객체 및 컨텍스트 바 가시화

1. 시맨틱 영상/움직임의 애니메이션된 그래픽 (예를 들어 망원경, 보이저, 우주선, 바다 위의 오래된 배) (아이콘 및 컨텍스트 안내 보기)

2. 순차적인 애니메이션으로 N개의 제1 정보 아이템들의 명칭 (리스트 보기)

3. 순차적인 애니메이션으로 N개의 제1 정보 아이템들의 명칭 및 상세 내역 (타일형 보기)

4. 시맨틱 영상/움직임 위의 아이템들의 총 개수 (아이콘 및 컨텍스트 안내 보기)

5. 아이템들의 총 개수 (아이콘 및 컨텍스트 안내 보기)

역사

역사 컨텍스트 템플릿은 "역사 채널"의 개인적인 디지탈 버전과 유사할 수 있다. 이 경우에는 특정 토픽에 관한 것은 물론 역사적인 컨텍스트와 관련된 보급 정보가 강조된다. 이러한 템플릿을 위해, 바람직한 축들은 카테고리와 시간이다. 역사 컨텍스트 템플릿은 디스커버리 컨텍스트 템플릿과 유사하며, "최소 시간 한계(minimum age limit)"과 더 일치해야 한다. 변수와 관련해서는 "최대 시간 한계" 변수가 "최소 시간 한계" 변수(또는 선택적인 "역사 시간 스팬(history time span)" 변수)로 대체되는 점을 제외하고는 바람직하게는 디스커버리 컨텍스트 템플릿의 변수와 동일하다. 또한, 반환된 객체는 바람직하게는 시스템에서 그들의 나이 또는 생성 이후의 그들의 나이에 기반하여 반대로 또는 무작위로 분류된다.

도108은 스마트 모래시계, 틈새면, 전이 효과, 배경 크롬 등을 위한 시맨틱 "역사" 가시화 또는 샘플 영상을 도시한다. (전쟁 기념관)

역사 - 샘플 객체 및 컨텍스트 바 애니메이션 가시화

1. 시맨틱 영상/움직임 또는 동등물의 애니메이션된 그래픽

2. 순차적인 애니메이션으로 가장 오래된 (또는 무작위인) N개의 정보 아이템의 명칭 (리스트 보기)

3. 순차적인 애니메이션으로 가장 오래된 (또는 무작위인) N개의 정보 아이 템의 명칭 및 상세 내역 (타일형 보기)

4. 시맨틱 영상/움직임 위의 아이템의 전체 개수 (아이콘 및 컨텍스트 안내 보기)

5. 평이한 배경 위의 아이템의 총 개수 (아이콘 및 컨텍스트 안내 보기)

모든 아이템

모든 아이템 컨텍스트 템플릿은 시맨틱에 기반하여 또는 키워드 또는 텍스트 기반 검색에 기반하여 관련된 임의의 정보를 반환하는 컨텍스트를 대표한다. 이 경우에는 컨텍스트에 심지어 미미하게 관련될 수 있는 보급 정보가 강조된다. 모든 아이템 컨텍스트 템플릿을 위한 주축은 바람직하게는 얼마 안되는 관련 가능성이다. 바람직한 실시예에서, 모든 아이템 컨텍스트 템플릿은 가능한한 넓은 세트 또는 관련될 수 있는 넓은 결과를 반환하기 위해 시맨틱 기반 쿼리와 텍스트 기반 쿼리를 모두 사용한다.

도109는 스마트 모래시계, 틈새면, 전이 효과, 배경 크롬 등을 위한 시맨틱 가시화 또는 샘플 영상을 도시한다. (외계)

모든 아이템 - 가시화와 샘플 객체 및 컨텍스트 바 애니메이션

1. 시맨틱 영상/움직임 또는 동등물의 애니메이션된 그래픽

2. 순차적인 애니메이션으로 최근 N개의 정보 아이템들의 명칭 (리스트 보기)

3. 순차적인 애니메이션으로 최근 N개의 정보 아이템들의 명칭 및 상세 내역 (타일형 보기)

4. 시맨틱 영상/움직임 위의 아이템의 총 개수 (아이콘 및 컨텍스트 안내 보기)

5. 평이한 배경 위의 아이템이 총 개수 (아이콘 및 컨텍스트 안내 보기)

최적 의견

최적 의견 컨텍스트 템플릿(및 그에 따른 특정 에이전트)는 오직 매우 관련된 정보를 반환하는 컨텍스트를 대표한다. 바람직한 실시예에서, 매우 관련있고 시맨틱적으로 중요하다고 생각되는 보급 정보가 강조된다. 이러한 컨텍스트 템플릿에 대해, 주 축은 관련성이다. 필연적으로, 최적 의견 컨텍스트 템플릿은 텍스트 기반 쿼리 결과의 관련성을 보장할 수 없기 때문에, 시맨틱 쿼리를 사용하며 텍스트 기반 쿼리를 사용하지 않을 것이다. 최적 의견 컨텍스트 템플릿은 바람직하게는 카테고리 필터 도는 키워드를 사용하여 초기화된다. 키워드가 특정되면, 서버는 카테고리화를 동적으로 수행한다. 결과는 바람직하게는 관련성 점수 또는 객체로부터 카테고리 필터로의 "카테고리에 속하는(belongs to category)" 시맨틱 링크의 세기에 기반하여 분류된다.

도110은 스마트 모래시계, 틈새면, 전이 효과, 배경 크롬 등을 위한 "최적 의견" 가시화 또는 샘플 영상을 도시한다. (현미경)

최적 의견 가시화 - 샘플 객체 및 컨텍스트 바 애니메이션

1. 시맨틱 영상/움직임 또는 동등물의 애니메이션된 그래픽

2. 순차적인 애니메이션으로 최근 N개의 정보 아이템들의 명칭 (리스트 보기)

3. 순차적인 애니메이션으로 최근 N개의 정보 아이템들의 명칭 및 상세 내역 (타일형 보기)

4. 시맨틱 영상/움직임 위의 아이템의 총 개수 (아이콘 및 컨텍스트 안내 보기)

5. 평이한 배경 위의 아이템이 총 개수 (아이콘 및 컨텍스트 안내 보기)

즐겨찾기

즐겨찾기 컨텍스트 템플릿(및 그에 따른 특정 에이전트)는 "즐겨찾기" 또는 "인기있는" 정보를 반환하는 컨텍스트를 대표한다. 이 경우에는, 다른 사람에 의해 추천되고 우호적으로 받아들여진 보급된 정보가 강조된다. 바람직한 실시예에서, 즐겨찾기 컨텍스트 템플릿에 대한 축은 리더쉽 관심도의 수준, 객체가 받은 "리뷰", 객체에 대한 주석 쓰레드의 깊이를 포함한다. 실시예에서, 즐겨찾기 컨텍스트 템플릿은 "즐겨찾기" 컨텍스트 링크를 갖는 정보만을 반환하며, (이 시맨틱 링크에 기반하여) 객체에 대한 "투표"의 수를 셈으로써 분류된다.

도111은 스마트 모래시계, 틈새면, 전이 효과, 배경 크롬 등을 위한 가시화 또는 샘플 영상을 도시한다. (커피와 패스트리)

즐겨찾기 가시화 - 샘플 객체 및 컨텍스트 바 애니메이션

1. 시맨틱 영상/움직임 또는 동등물의 애니메이션된 그래픽

2. 순차적인 애니메이션으로 최근 N개의 정보 아이템들의 명칭 (리스트 보기)

3. 순차적인 애니메이션으로 최근 N개의 정보 아이템들의 명칭 및 상세 내역 (타일형 보기)

4. 시맨틱 영상/움직임 위의 아이템의 총 개수 (아이콘 및 컨텍스트 안내 보기)

5. 평이한 배경 위의 아이템이 총 개수 (아이콘 및 컨텍스트 안내 보기)

클래식

클래식 컨텍스트 템플릿(및 그에 따른 특정 에이전트)는 "클래식" 정보 또는 인정받을 가치가 있는 정보를 반환하는 컨텍스트를 대표한다. 즐겨찾기 컨텍스트 템플릿과 같이, 다른 사람에 의해 추천되고 우호적으로 받아들여진 보급된 정보가 강조된다. 이 컨텍스트 템플릿에서, 바람직한 축은 역사적인 컨텍스트, 리더쉽 관심도의 수준, 객체가 받은 "리뷰", 객체에 대한 주석 쓰레드의 깊이를 포함한다. 클래식 컨텍스트 템플릿은 바람직하게는 즐겨찾기 컨텍스트 템플릿에 기반하여 구현되지만, 필연적으로 "오래된 즐겨찾기" 컨텍스트 템플릿으로서 작용하게 되는 부가적인 최소 시간 한계 필터 및 투표 점수를 구현해야 한다.

도112는 스마트 모래시계, 틈새면, 전이 효과, 배경 크롬 등을 위한 "클래식"의 시맨틱적으로 적절한 샘플 영상을 도시한다. (차)

클래식 가시화 - 샘플 객체 및 컨텍스트 바 애니메이션

1. 시맨틱 영상/움직임 또는 동등물의 애니메이션된 그래픽

2. 순차적인 애니메이션으로 최근 N개의 정보 아이템들의 명칭 (리스트 보기)

3. 순차적인 애니메이션으로 최근 N개의 정보 아이템들의 명칭 및 상세 내역 (타일형 보기)

4. 시맨틱 영상/움직임 위의 아이템의 총 개수 (아이콘 및 컨텍스트 안내 보기)

5. 평이한 배경 위의 아이템 총 개수 (아이콘 및 컨텍스트 안내보기)

추천

추천 컨텍스트 템플릿은 "추천된" 정보 또는 사용자에게 흥미있을 것이라고 에이전시가 추론한 정보를 반환하는 컨텍스트를 대표한다. "추천" 시맨틱 링크를 "SemanticLinks" 테이블에 추가하고 사용자들이 표시한 즐겨찾기 시맨틱 링크를 발굴함으로써 추천이 삽입될 것이다. 추천은 바람직하게는 머신 학습과 협동 필터링과 같은 기법을 사용하여 수행된다. 이 컨텍스트 템플릿에서는 사용자에게 흥미있을 것 같지만 사용자가 이미 볼 수는 없었을 보급된 정보가 강조된다. 이 컨텍스트 템플릿에서, 주축은 바람직하게는 흥미의 가능성과 신선함을 포함한다.

도113는 스마트 모래시계, 틈새면, 전이 효과, 배경 크롬 등의 컨텍스트/애플리케이션 구성요소에 대한 시맨틱적으로 적절한 "추천" 가시화 또는 샘플 영상을 도시한다. (치켜올려진 엄지손가락(thumb up))

추천 가시화 - 샘플 객체 및 컨텍스트 바 애니메이션

1. 시맨틱 영상/움직임 또는 동등물의 애니메이션된 그래픽

2. 순차적인 애니메이션으로 최근 N개의 정보 아이템들의 명칭 (리스트 보기)

3. 순차적인 애니메이션으로 최근 N개의 정보 아이템들의 명칭 및 상세 내역 (타일형 보기)

4. 시맨틱 영상/움직임 위의 아이템의 총 개수 (아이콘 및 컨텍스트 안내 보기)

5. 평이한 배경 위의 아이템이 총 개수 (아이콘 및 컨텍스트 안내 보기)

오늘

오늘 컨텍스트 템플릿은 "오늘" 발송되거나 (이벤트의 경우에) "오늘" 보유하는 정보를 반환하는 컨텍스트를 대표한다. 이 컨텍스트 템플릿에서는 신선도를 결정하는 필터가 "오늘"임에 기반하여 현재라고 생각되는 보급된 정보가 강조된다.

도114는 스마트 모래시계, 틈새면, 전이 효과, 배경 크롬 등의 구성요소에 대한 시맨틱적 "오늘" 가시화 또는 샘플 영상을 도시한다.

"오늘 가시화" - 샘플 객체 및 컨텍스트 바 애니메이션

1. 시맨틱 영상/움직임 또는 동등물의 애니메이션된 그래픽

2. 순차적인 애니메이션으로 최근 N개의 정보 아이템들의 명칭 (리스트 보기)

3. 순차적인 애니메이션으로 최근 N개의 정보 아이템들의 명칭 및 상세 내역 (타일형 보기)

4. 시맨틱 영상/움직임 위의 아이템의 총 개수 (아이콘 및 컨텍스트 안내 보기)

5. 평이한 배경 위의 아이템이 총 개수 (아이콘 및 컨텍스트 안내 보기)

주석된 아이템

주석된 아이템 컨텍스트 템플릿은 주석된 정보를 반환하는 컨텍스트를 대표한다. 이 컨텍스트 템플릿에서는 하나 이상의 사용자들이 아이템을 주석한 사실에 기반하여 중요할 것 같은 보급된 정보가 강조된다.

도115는 스마트 모래시계, 틈새면, 전이 효과, 배경 크롬 등의 구성요소에 대한 시맨틱적 "주석된 아이템" 가시화 또는 샘플 영상을 도시한다.

"주석된 아이템" 가시화 - 샘플 객체 및 컨텍스트 바 애니메이션

1. 시맨틱 영상/움직임 또는 동등물의 애니메이션된 그래픽

2. 순차적인 애니메이션으로 최근 N개의 정보 아이템들의 명칭 (리스트 보기)

3. 순차적인 애니메이션으로 최근 N개의 정보 아이템들의 명칭 및 상세 내역 (타일형 보기)

4. 시맨틱 영상/움직임 위의 아이템의 총 개수 (아이콘 및 컨텍스트 안내 보기)

5. 평이한 배경 위의 아이템이 총 개수 (아이콘 및 컨텍스트 안내 보기)

주석

주석 컨텍스트 템플릿은 주석된 정보를 반환하는 컨텍스트를 대표한다. 이 컨텍스트 템플릿에서는 주석이 있는 보급된 정보가 강조된다.

도116는 스마트 모래시계, 틈새면, 전이 효과, 배경 크롬 등에 대한 시맨틱적 가시화 또는 샘플 영상을 도시한다. (게시판에 피닝된 노트)

"주석" 가시화 - 샘플 객체 및 컨텍스트 바 애니메이션

1. 시맨틱 영상/움직임 또는 동등물의 애니메이션된 그래픽

2. 순차적인 애니메이션으로 최근 N개의 정보 아이템들의 명칭 (리스트 보기)

3. 순차적인 애니메이션으로 최근 N개의 정보 아이템들의 명칭 및 상세 내역 (타일형 보기)

4. 시맨틱 영상/움직임 위의 아이템의 총 개수 (아이콘 및 컨텍스트 안내 보기)

5. 평이한 배경 위의 아이템이 총 개수 (아이콘 및 컨텍스트 안내 보기)

전문가

도117은 스마트 모래시계, 틈새면, 전이 효과, 배경 크롬 등의 구성요소에 대한 시맨틱적 "전문가" 가시화 또는 샘플 영상을 도시한다. (교수)

"전문가" 가시화 - 샘플 객체 및 컨텍스트 바 애니메이션

1. 시맨틱 영상/움직임 또는 동등물의 애니메이션된 그래픽

2. 순차적인 애니메이션으로 최근 N개의 정보 아이템들의 명칭 (리스트 보기)

3. 순차적인 애니메이션으로 최근 N개의 정보 아이템들의 명칭 및 상세 내역 (타일형 보기)

4. 시맨틱 영상/움직임 위의 아이템의 총 개수 (아이콘 및 컨텍스트 안내 보기)

5. 평이한 배경 위의 아이템이 총 개수 (아이콘 및 컨텍스트 안내 보기)

장소

도118는 스마트 모래시계, 틈새면, 전이 효과, 배경 크롬 등에 대한 시맨틱적 "장소" 가시화 또는 샘플 영상을 도시한다. (파리)

"장소" 가시화 - 샘플 객체 및 컨텍스트 바 애니메이션

1. 시맨틱 영상/움직임 또는 동등물의 애니메이션된 그래픽

2. 순차적인 애니메이션에서 최근 N개의 장소들의 명칭 (리스트 보기)

3. 순차적인 애니메이션에서 최근 N개의 장소들의 명칭 및 상세 내역 (타일형 보기)

4. 시맨틱 영상/움직임 위의 장소들의 총 개수 (아이콘 및 컨텍스트 안내 보기)

6. 평이한 배경 위의 장소들의 총 개수 (아이콘 및 컨텍스트 안내 보기)

블렌더

도119는 스마트 모래시계, 틈새면, 전이 효과, 배경 크롬 등의 구성요소에 대한 시맨틱적 "블렌더" 가시화 또는 샘플 영상을 도시한다. (블렌더)

"블렌더" 가시화 - 샘플 객체 및 컨텍스트 바 애니메이션

1. 시맨틱 영상/움직임 또는 동등물의 애니메이션된 그래픽

2. 작동중인 블렌더 또는 믹서의 애니메이션된 그래픽

3. 순차적인 애니메이션으로 블렌더 아이템들의 명칭 (리스트 보기)

4. 순차적인 애니메이션으로 블렌더 아이템들의 명칭 및 상세 내역 (타일형 보기)

5. 시맨틱 영상/움직임 위의 아이템의 총 개수 (아이콘 및 컨텍스트 안내 보기)

6. 평이한 배경 위의 아이템이 총 개수 (아이콘 및 컨텍스트 안내 보기)

정보 객체 타입

도120 내지 도138은 문서, 책, 잡지, 프레젠테이션, 이력서, 스프레드시트, 텍스트, 웹 페이지, 백지, 이메일, 이메일 주석, 이메일 배포 리스트, 이벤트, 미팅, 멀티미디어, 온라인 강좌, 사람, 고객, 사용자와 같은 정보 객체 타입에 대한 시맨틱 가시화를 각각 도시한다.

프레젠테이션 스킨 타입

타임라인(timeline)

도139는 스마트 모래시계, 틈새면, 전이 효과, 배경 크롬 등의 구성요소에 대한 시맨틱적 "타임라인" 가시화 또는 샘플 영상을 도시한다.

"타임라인" 가시화 - 샘플 객체 및 컨텍스트 바 애니메이션

1. 여러 가지 배경 위의 정보 아이템의 (공표 시간, 스케줄링된 시간 등의) 유효 시간을 도시하는 달력 보기 (아이콘 및 컨텍스트 가이드 보기)

2. 여러 가지 배경 위의 정보 아이템들의 유효 시간을 (순차적으로) 도시하는 달력 보기 (아이콘 및 컨텍스트 가이드 보기)

3. 달력 움직임을 도시하는 애니메이션된 그래픽 (아이콘 및 컨텍스트 가이드 보기)

4. 시맨틱 영상/움직임의 애니메이션된 그래픽 (예를 들어 시간 뒤틀림 영상 /움직임) (아이콘 및 컨텍스트 가이드 보기)

5. 시맨틱 영상/움직임 위의 정보 아이템의 총 개수 (아이콘 및 컨텍스트 가이드 보기)

6. 평이한 배경 위의 정보 아이템의 총 개수 (아이콘 및 컨텍스트 가이드 보기)

7. 순서대로 애니메이션된 정보 아이템의 명칭 (리스트 보기)

8. 순서대로 애니메이션된 정보 아이템의 명칭 및 상세 내역 (타일형 보기)

9. 유효 날짜/시간에 기반하여 컬렉션된 아이템을 갖는 스크롤링, 리니어 타임라인 콘트롤

10. 유효 날짜/시간에 기반하여 분류된 애니메이션된 타임라인 티커 콘트롤

시맨틱 가시화의 영향력

가시화에 관련된 최종 노트. 바람직한 실시예는 정보를 시맨틱적으로 검색할 뿐 아니라, 정보를 시맨틱적으로 조직화하고 저장하며, 또한 정보를 시맨틱적으로 제공한다. 그리고, 프레젠테이션은 정보의 순서, 조직 및 관련성에서 시맨틱할 뿐 아니라 전술한 가시화들이 부분적으로 전달되도록 의도됨에 따라 시각적이다. 결과적으로, 영화 관람자가 조명 장치, 복장, 음악 및 전체 세트 또는 장면의 주변 컨텍스트에 의해 다이어로그의 의미를 이해하도록 도움을 받는 것과 대략 같은 방식으로, 사용자는 시스템에 의해 주어진 정보를 이해하도록 도움을 받게 된다. 다르게 배치되더라도 나머지 모든 것이 바람직한 실시예의 시스템에 의해 제공되거나 관리되거나 또는 바람직한 실시예의 시스템과 함께 위치된다면, 가시화는 의미 있 는 정보를 전달하는 목적을 수행하거나 아주 똑같이 정보를 의미 있게 전달할 것이다. 의미는 바람직한 실시예의 통합된 테마이며, 따라서 의미는 시스템과 시스템이 포함하고 있는 각각의 구성 요소의 설계 및 작동에 영향을 미친다.

본 발명의 바람직한 몇 가지 대안적인 실시예가 전술한 바와 같이 도시되고 설명되었지만 본 발명의 사상과 범위를 벗어나지 않으면서 많은 변화가 수행될 수 있다. 따라서, 본 발명의 범위는 바람직한 실시예의 상세한 설명에 의해 제한되지 않는다. 그 대신, 본 발명은 전적으로 첨부된 특허청구범위를 참조하여 결정되어야 한다.

[부록 A]

[발명의 명칭]

지식 검색, 관리, 전달 및 프리젠테이션을 위한 시스템 및 방법{SYSTEM AND METHOD FOR KNOWLEDGE RETRIVAL, MANAGEMENT, DELIVERY AND PRESENTATION}

[기술분야]

본 발명은 일반적으로 정보 관리 시스템에 관한 것으로, 보다 상세하게는 지식 검색, 관리, 전달 및 프리젠테이션을 위한 통합되고 일체화된 실행 프레임워크 및 결과 매체에 관한 것이다.

[배경기술]

지식은 현재 세계적으로 조직의 핵심적인 자산이며, 경쟁력있는 이점으로 사용되는 도구로서 폭넓게 인식되고 있다. 오늘날 연결된 정보를 기반으로 하는 세계에서, 지식 노동자들은 생산성을 향상시키고, 고객 관계를 높이며 그들의 비지니스를 보다 경쟁적으로 만들기 위해 보다 낫고, 보다 빠르고, 보다 정보화된 결정을 하는데 필요한 지식 및 도구에 액세스해야만 한다. 또한, 산업 옵서버들은 정보 경제에서 가져야 할 중요한 비지니스 목표로서 "민첩성(agility)" 및 "실시간 기업 전략(real-time enterprise)"을 강조해 왔다.

많은 조직들은 제품 및 고객 서비스를 향상시키기 위하여 그들의 조직 내에서 지식을 전파하는 가치와, 잘 트레이닝된 노동력이 가진 가치를 구현하기 시작했다. 투자 비지니스는 e-학습을 만들고, 조직적인 교육은 이것의 일부 증거를 제공 한다. 회사들은 또한 콘텐츠 관리, 검색, 협동 및 비지니스 지식에 대한 도구들에 투자했다. 또한, 회사들은 그들의 비지니스 프로세스을 디지털화, 특히 고객을 모집하고 보유하는 것에 관한 중요한 리소스에 소비하고 있는 중이다.

그러나, 많은 지식/학습 및 고객 관계 특성은 서로의 언어를 이해하지 못하는 다양한 세트의 저장소들에 여전히 저장되고, 그 결과로서 정보의 독립된 아일랜드(island)로서 관리되고 상호작용된다. 이와 같이, 많은 조직들이 "지식"이라고 부르는 것은 단지 데이터 및 정보일 뿐이다. 대부분의 정보 경제는 여전히 증가하고 있는 데이터 및 정보 본체의 컨텍스트(context), 의미 및 효율적인 액세스를 제공하는 방식을 찾기 위한 노력이다. 즉, 달리 말하자면, 대량의 활용 가능한 데이터 및 정보를 유용한 지식으로 전환시키는 것이다.

정보는 신문, 책, 라디오 및 텔레비전 매체와 같은 다양한 형태, 그리고 전자 형태로 확산의 정도를 변화시키면서 오랫동안 접근해 왔다. 정보 관리 및 액세스는 컴퓨터 및 컴퓨터 네트워크의 이용으로 극적으로 바뀌었다. 네트워크화된 컴퓨터 시스템들은 시스템을 통해 시스템을 따라 임의의 지점에 관리되는 정보로의 액세스를 제공한다. 사용자들이 액세스하기 위해서는 네트워크에의 필수적인 접속의 설정, 적당한 인증의 제공 및 원하는 정보의 식별만을 필요로 한다.

정보 액세스는 방대한 정보 본체에의 액세스를 제공하기 위해, 다양한 지역에 걸쳐 있는 다수의 컴퓨터들을 접속하는 인터넷의 등장으로 더욱 향상되었다. 인터넷을 통해 정보를 제공하는 가장 널리 퍼진 방법은 월드 와이드 웹(WWW)를 통해서이다. 웹(Web)은 통상적으로 HTTP(Hypertext Transfer Protocol), FTP(File Transfer Protocol), GOPHER 또는 다른 서버들을 운영하는 인터넷에 접속된 컴퓨터들 또는 웹 서버들의 서브세트로 이루어져 있다. 웹 서버들은 웹사이트에서 웹 페이지들은 호스트한다. 웹 페이지들은 HTML(Hypertext Markup Language), 보다 최근의 XML(eXtensible Markup Language) 또는 SGML(Standard Generic Markup Language)와 같은 하나 이상의 언어를 이용하여 인코딩된다. 이들 언어에 대한 공개된 명세서는 본 명세서에서 참조로서 결합된다. 이들 포맷된 언어의 웹 페이지들은 마이크로소프트사의 인터넷 익스플로어 또는 네스케이프 네비게이터와 같은 웹 브라우징 소프트웨어를 통해 인터넷 사용자들이 접속할 수도 있다.

웹은 대부분 컨텍스트(context) 및 시맨틱스(semantics)이라기 보다는 구문(syntax) 및 구조에 기초하여 구성되어 왔다. 그 결과, 정보는 통상적으로 검색 엔진 및 웹 디렉토리를 통해 액세스된다. 현재의 검색 엔진은 관련된 컨텍스트(context) 및 시맨틱스 정보없이 본문 또는 기본적인 과제 정보 및 인덱스에 좌우되는 키워드 및 해당 검색 기술을 이용한다. 불행하게도, 그러한 검색 방법은 수천의 큰 반응이 없는 결과; 영향있는 지식에 상반되는 문서들을 생성한다. 향상된 검색 기술은 질의에 촛점을 맞추고, 검색 결과의 컨텍스트(관련성)을 향상시키기 위해 개발되어 왔다. 많은 그러한 기술들은 과거의 사용자 검색 경향에 좌우되어, 원하는 정보에 대한 기본적인 가정을 만들었다. 선택적으로, 다른 검색 기술들은 가장 관련성이 있다고 예측되는 범위에 검색 결과를 추가로 촛점을 맞추기 위한 웹 사이트들의 카테고리에 좌우된다. 검색 기술과는 무관하게, 검색가능한 정보의 잠재적인 조직은 컨텍스트(관련성) 중심이라기 보다는 인덱스 중심이다. 문서에 관 련된 문자 정보의 빈도 또는 타입은 문서의 과제의 속성과는 상반되게 그리고 이들 속성들이 사용자의 컨텍스트에 어떻게 관련되는지에 따라 검색 결과를 결정한다. 그 결과, 실행가능한 지식을 취득하기 위한 도구로서의 웹의 이용을 둘러싼 모호성과 비효율성이 지속된다

오늘날 전세계의 기업들에서, 웹은 지식 노동자들의 정보 플랫폼이다. 그리고 문제점이 존재한다. 우리가 알고 있는 웹은 데이터 및 정보에 대한 플랫폼인 반면, 그 사용자는 "지식"의 레벨에서 작업한다. 이 단절은 매우 근본적인 것이며 이해할 수 없다. 웹은, 큰 정도에서, "당신의 손끝에 있는 정보"의 꿈을 채워주었다. 그러나, 지식 노동자들은 단지 "당신의 손끝에 있는 정보"와는 상반되게 "당신의 손끝에 있는 지식"을 요구한다. 불행하게도, 오늘날의 지식 노동자들은 웹을 이용하여 그들의 질의에 관련된 실제 지식이라기 보다는 문서들-데이터 및 정보의 편집-을 브라우징 및 검색한다. 향상된 지식을 취득하기 위해서는 데이터 및 정보에 대한 적당한 컨텍스트(관련성), 의미 및 효과적인 액세스를 제공할 필요가 있으며, 이들 모두 전통적인 웹에서 놓치고 있다.

"당신의 손끝에 있는 지식"의 목표를 달성하기 위한 노력이 진행되어 왔다. 일례는 시맨틱 웹(Semantic Web)으로서 참조되는 정보 조직 및 분배에 대한 새로운 개념이다. 시맨틱 웹은 정보가 잘 정의된 의미를 제공하는 한 현재의 웹의 확장이며, 이는 컴퓨터 및 사람들이 협동하여 작업할 수 있게 한다. 개념적으로 중요한 단계가 인터넷상의 정보의 향상된 컨텍스트(관련성), 의미 및 액세스를 지원하도록 진행되는 동안, 시맨틱 웹은 아직까지 진술된 잠재력에 따라 행동하는 성공적인 실 행을 찾고 있다.

현재의 웹 및 시맨틱 웹 둘다, 사용자가 실행가능한 지식을 취득할 수 있도록 데이터 및 정보에 대한 적당한 컨텍스트(관련성), 의미 및 효과적인 액세스를 제공하는데 실패했다. 이것은 부분적으로 오늘날의 웹(Today's Web)과 심사숙고된 시맨틱 웹이 구성되는 방식에 관련된 문제, 바꾸어 말하자면, 기술 레이어(layer)에 관련된 문제이다. 도 1에 나타난 바와 같이, 예를 들면, 하이퍼텍스트 매체인 오늘날의 웹은 "덤(dumb)" 링크, 또는 컨텍스트-감도, 시간-감도 등이 없는 링크를 포함하는 3개의 기술 레이어들을 제공한다. 시맨틱 웹 또한 "시맨틱 하이퍼미디어"로서 참조되는 시맨틱 웹의 현재 개념은 도 2에 나타난 바와 같이, 5개의 기술레이어들을 제공한다. 이하에 보다 상세히 설명되는 바와 같이, 각 기술레이어 구조와 관련된 심각한 한계가 있다.

또한, 지식 검색, 관리 및 전달을 위한 통합되고 일정한 실행 프레임워크 및 결과 매체를 제공하는 포괄적인 정보 관리 시스템내에 다양한 특성이 존재해야만 한다. 이들 특성의 비소모적인 리스트는 시맨틱/의미; 컨텍스트-감도; 시간-감도; 자동 및 지성 디스커버러빌러티; 다이나믹 링킹; 사용자 제어의 네비게이션 및 브라우징; 네트워크에서 비-HTML 및 로컬 문서 참여; 표시되는 정보의 시맨틱을 스마트하게 전송하는 다양한 프리젠테이션; 논리, 추론 및 추리; 다양한 사용자 중심의 정보 분석; 다양한 시맨틱 질의; 읽기/기입 지원; 주석; "신뢰의 웹(Web of Trust)"; 정보 패키지("블렌더(blenders)"); 컨텍스트 템플레이트, 및 사용자 지향 정보 집합을 포함한다. 이들 각 특성들은 이하 오늘날의 웹 및 시맨틱 웹 둘다에 대한 어플리케이션의 컨텍스트에서 논의될 것이다.

시맨틱스/의미(SEMANTICS/MEANING)

오늘날의 웹(Today's Web)은 플랫폼의 고유 부분 및 사용자 경험으로서 시맨틱스가 부족하다. 웹 페이지들은 그들이 포함하는 데이터의 시맨틱스라기 보다는 원문 및 그래픽 데이터만을 전송한다. 그 결과, 사용자는 자연어-예를 들면, "라틴 재즈에 관한 것이며 최근 5년내에 공개된, 100 페이지보다 길지 않은 모든 책들을 찾아라"를 가지고 예측한 것과 같은 시맨틱 질의를 제시할 수 없다. 그러한 질의를 처리하기 위하여, 웹 사이트 또는 검색 엔진은 책을 포함하는 것을 "알고" 있어야만 하고, 질의 요구의 시맨틱스에 기초하여 그 콘텐츠를 지능적으로 필터링해야 한다. 그러한 질의는 웹 투데이에서 가능하지 않다. 그 대신에, 사용자들은 문자에 기초한 검색에 의존할 수 밖에 없다. 이들 검색은 사용자가 정보 베이스의 문자와 일치하지 않는 검색 용어들을 걸러내야 하기 때문에 대개 정보 과부하 또는 정보 손실의 결과를 초래한다. 상술한 예에서, 사용자는 검색 용어 "책 라틴 재즈"를 골라낼 수 있고 검색 엔진이 접속할 것을 희망한다. 사용자에게는 대개 검색 결과를 독립적으로 필터링하는 것이 남겨진다. 이러한 종류의 문자에 기초한 검색은 또한 동일한 의미를 전송해야 하는 용어를 의미한다. 상술한 예에서, "남부 및 중앙 아메리카 재즈에 관한 책들" 또는 "라틴 섬으로부터의 재즈에 대한 공개"와 같은 검색 용어로부터의 결과는 검색 질의의 처리 동안 무시될 수 있다.

시맨틱스의 결여는, 또한 오늘날의 웹이 사용자들이 인간적인 생각에 기초하여 네비게이션 할 수 없다는 것을 의미한다. 예를 들면, 조직 구조를 이용하여 사 내 망을 네비게이션하기를 원할 수 있다. 예를 들면, 사람들로부터 이들이 생성한 문서를 분배 리스트에 전문가들의 직접적인 리포트에 대한 문서인 다이렉트 리포트는 이들 멤버들이 생성한 문서들에 대한 분배 리스트의 멤버들이다. 이 "웹"은 시맨틱이며 실제 정보 분류("사물(things)")에 기초하여 오늘날의 웹과 같은 "페이지"는 아니다.

시맨틱스의 결여는 또한 다른 함축적인 의미를 갖는다. 첫번째로, 웹이 프로그램가능하지 않다는 것을 의미한다. 시맨틱스과 함께, 웹은 페이지들 및 링크를 감지하고 나서 추론, 추천 등을 할 수 있는 스마트 에이전트에 의해 소비될 수 있다. 오늘날의 웹과 더불어, 추론을 할 수 있는 유일한 "에이전트(Agent)"는 인간 두뇌이다. 이와 같이, 웹은 컴퓨터가 이해할 수 있는 방식으로 나타낼 수 없기 때문에 컴퓨터가 할 수 있는 수많은 처리 능력을 사용할 수 없다.

시맨틱스의 결여는 또한 정보가 액션가능하지(actionable) 않다는 것을 의미한다. 검색 엔진은 배출한 결과들을 "이해(understand)"하지 못한다. 이와 같이, 일단 사용자가 검색 결과를 수신하면, 그는 "그 자신"이다. 또한, 웹 브라우저는 표시되는 정보를 "이해"하지 못하고 이와 같이 정보를 이용하여 스마트한 일들을 할 수 없다. 적소에 시맨틱스를 이용하여, 예를 들면, 스마트 디스플레이는 정보가 액션 가능하게 됨으로써 이벤트는 이벤트라는 것을 "알 수 있을 것이며(know)", 이벤트가 사용자의 캘린더에 이미 있거나, 프리/비지 정보를 표시하거나, 사용자가 그들의 캘린더에 이벤트가 자동적으로 삽입되기를 원한다면 관심있는 일들을 체크할 것이다. 시맨틱스 없이 제공된 정보는 액션가능하지 않거나, 시맨틱스가 추론 될 필요가 있으며, 이는 불쾌한 사용자 경험을 초래할 수 있다.

시맨틱 웹은 잘 정의된 시맨틱스 방식으로 정보를 인코딩함으로써 오늘날의 웹을 이용하여 시맨틱/의미 한계에 근접하려 시도한다. 시맨틱 웹 상의 웹 페이지는 메타데이터 및 다른 메타데이터에의 시맨틱스 링크를 포함하며, 이로써 검색 엔진이 보다 지능적이며 정확한 검색을 수행할 수 있게 한다. 또한, 시맨틱 웹은 지식 표현에 사용되게 될 온톨로지(ontologies)를 포함하며, 이로써 시맨틱스 검색 엔진이 단지 문자만이 아니라 의미에 기초하여 용어를 해석할 수 있게 한다. 예를 들면, 이전 예에서, 라틴 재즈 온톨로지는 시맨틱 웹 사이트상에서 사용될 수 있으며 사이트상의 검색 엔진이 "남부 및 중앙 아메리카 재즈에 관한 책들" 또는 "라틴 섬으로부터의 재즈에 대한 공개" 용어들이 "라틴 재즈에 관한 책들" 용어와 동일한 의미를 갖는지를 "식별(know)"할 수 있게 한다. 오늘날의 웹을 이용하여 수많은 부족분을 개념적으로 극복하는 동안, 컨텍스트-감도 및 시간-감도와 같은 추가적인 특성을 제공하기 위해 특히 필수적인 시맨틱스 링크, 온톨로지 등을 포함하는 컨텍스트 및 의미를 제공하는 잘 정의된 데이터 모델의 성공적인 실행을 하지 못하고 있다.

현재 우리가 사용하고 있는 웹은 인터넷 상에서 사용자에게 컨텐츠를 제공하는 정보 시스템인 반면에, 시맨틱 웹은 사람뿐만아니라 컴퓨터(기계)가 직/간접적으로 처리할 수 있는 데이터를 위한 웹을 의미한다. 따라서 시맨틱 웹을 위해서는 사람이 직관적 또는 의미적으로 판단하여 처리하는 부분을 컴퓨터가 처리할 수 있도록 사용되는 용어에 대한 공통적인 합의가 필요하게 되며, 이를 웹 온톨로지라 부른다.

컨텍스트-감도(CONTEXT-SENSITIVITY)

오늘날의 웹은 컨텍스트-감도가 부족하다. 컨텍스트(관련성) 결여가 의미하는 것은 오늘날의 웹이 개인적이지 않다는 것이다. 예를 들면, 액세스가능한 스토리지의 문서들은 독립적으로 스태틱(static)하기 때문에 무감각적이다(stupid). 문서의 과제에 관련된 정보는 이미 공개되어 있으며, 새롭게 공개중이거나, 곧 공개될 것이다. 그러나, 스토리지의 문서들이 스태틱하기 때문에, 실시간으로 관련 정보와 그 과제를 다이나믹하게 관련시킬 방법이 없다. 바꾸어 말하자면, 사용자들은 실시간으로 외부 정보와 그들 개인의 컨텍스트를 다이나믹하게 접목시킬 방법이 없다. 형식적인 컨텍스트는 그들 자신의 아일랜드에 자리잡은 정보 소스(예를 들면 문서)는 전체적으로 다른 관련 정보 소스로부터 단절되었다. 이것은 정보 및 생산성 손실을 초래한다.

이에 대한 일차적인 이유는 오늘날의 웹이 덤(dumb) 클라이언트(예를 들면, 원격 컴퓨터)에 정보의 시야를 제공하도록 설계된 프리젠테이션에 근거한 매체이다. 클라이언트는 서버가 말하는 것을 단지 표시하는 것을 제외하고, 가상적으로 사용자의 경험을 플레이하는 역할을 하지 않는다. 클라이언트측 코드(예를 들면, 자바 애플릿 및 ActiveX 컨트롤)가 있는 경우에서도, 제어는 대개 특정한 것을 행하고 클라이언트측 코드가 서버측 코드와 조정중에 있게 되도록 원격 서버와 동등한 액션을 가지지 않는다.

생산성의 관점으로부터, 그 의미는 지식 노동자들과 정보 소비자들이 전체적 으로 정보 저작자의 처분에 좌우된다는 것이다. 오늘날, 지식 노동자들은 보유 및 업데이트되는 포털(portals)을 가지고 기업 정보, 외부 데이터 등의 커스텀(custom) 관점을 제공한다. 그러나, 지식 노동자들은 사용자가 액세스하려고 하는 정보와 그들의 과제의 컨텍스트(관련성)의 관련 정보를 다이나믹이면서 지능적으로 아무것도 접목시킬 수 없다면 완벽하게 무용지물이기 때문에 여전이 매우 제한적이다.

지식 노동자가 그 포털 상에서 정보의 관련 조각에 대한 링크를 볼 수 없다면, 그리고 만일 친구 또는 동료가 그에게 링크를 이메일하지 못하고, 정보가 드롭(drop)된다면; 정보는 사용자 컨텍스트(context) 또는 표시되는 컨텍스트와의 접목 또는 적응되지 못한다. 마찬가지로, 전체 포털에 대한 새로운 데이터가 활용가능하고 이를 그들의 로컬 하드 드라이브에 다운받는 것을 사용자에게 통지하는데 충분치 않다. 컨텍스트-감도 알림 통지를 이용한 커스텀화가능한(customizable) 프리젠테이션이 부족하다.

시맨틱 웹(Semantic Web)은 컨텍스트-감도의 면에서 오늘날의 웹과 같은 제한을 겪는다. 시맨틱 웹상에서, 사용자는 마찬가지로 정보 저작자 마음대로 좌우된다. 시맨틱 웹 자체는 저작될 것이지만, 그 저작은 시맨틱스를 포함할 것이다. 그 결과, 사용자들은 여전히 활용가능한 정보의 컨텍스트를을 배치하고 평가하는 그들 자신에 크게 좌우된다. 독립적인 실체로서의 시맨틱 웹은 다른 정보 소스와의 다이나믹한 접목을 수행할 수 없을 것이다.

시간-감도(TIME-SENSITIVITY)

오늘날의 웹은 시간-감도가 부족하다. 웹 플랫폼(예를 들면, 브라우저)은 정보의 시간-감도에 대한 어떠한 고려도 없이, 단지 정보를 제공하는 소프트웨어의 일 부분이다. 사용자에게는 시간 감도를 추론하거나 시간에 대한 감도없이 남겨진다. 웹 플랫폼이 실시간으로 시간-감도 접목을 행할 수 없기 때문에 생산성의 커다란 손실을 초래한다. 일부 웹 사이트들이 예를 들면, 선정된 일자 이전의 정보를 인덱싱함으로써, 시간-감도 정보를 제공하는데 촛점이 맞추어진 바면에, 웹브라우저 자체는 시간-감도의 개념이 없다. 그 대신에, 그들이 그들 자신의 아일랜드에 표시하는 정보에 시간-감도를 포함하는 것은 개별 웹 사이트에 남겨진다. 바꾸어 말하자면, 웹 링크 상의 시간축이 없다.

오늘날의 웹과 같이, 시맨틱 웹은 시간-감도를 구현하지 않는다. 시맨틱 웹은 시간을 내재하지 않은 시맨틱스 링크를 가질 수 있다. 이것은, 대부분 시맨틱 웹이 컨텍스트-감도 및 시간-감도를 구현하는 소프트웨어 웹 서비스의 개념을 함축적으로 가지고 있지 않기 때문이다.

자동적 및 지능적 발견특성(AUTOMATIC AND INTELLIGENT DISCOVERABILITY)

오늘날의 웹은 새롭게 생성된 정보의 자동적이며 지능적인 발견특성이 부족하다. 현재로서는, 웹 사이트들이 오늘 또는 어제 새롭게 개시했는지를 알 수 있는 방법이 없다. 사용자가 검색할 때 새로운 사이트를 우연히 발견하거나 통보되지 않는다면, 사용자는 어떤 새로운 웹 사이트 또는 페이지가 있는지에 대한 어떠한 단서도 가질 수 없을 것이다. 동일한 문제가 기업에 존재한다. 사내망에서, 지식 노동자들은 일부 외부 수단을 통해 알려지지 않는다면 새로운 웹 사이트가 나 타날 때 알 수 있는 방법이 없다. 웹 플랫폼 자체는 알림 또는 디스커버리의 개념이 없다. 또한, 사용자의 태스크(task)의 컨텍스트 또는 현재 정보 공간내에서 새로운 사이트 또는 페이지를 결정하기 위한 컨텍스트-감도 디스커버리가 없다.

시맨틱 웹은, 오늘날의 웹과 같이, 자동적인 발견특성의 결여를 구현하지 않는다. 시맨틱 웹 사이트들은 동일한 문제점 -사용자들이 외부 소스로부터 새로운 정보 소스의 존재에 관해 찾거나, 검색을 수행할 때 개인적인 디스커버리 할 것임- 을 겪는다.

다이나믹 링킹(DYNAMIC LINKING)

오늘날의 웹은 정보 모델에 대한 그래프 "데이터 구조" 또는 순수 네트워크를 사용한다. 각 웹 페이지는 네트워크에서의 노드를 나타내고 각 페이지는 네트워크에서 다른 노드들에의 링크를 포함할 수 있다. 각 링크는 각 페이지에 수동적으로 저작된다. 이는 몇가지 문제점들을 갖는다. 첫번째로, 네트워크가 연속적인 값을 갖도록 유지될 필요가 있다는 것을 의미한다. 만일 웹 페이지들이 업데이트되지 않거나, 만일 웹 페이지 또는 사이트 저작자가 컨텍스트에 기초하여 그들의 페이지에의 링크를 추가하는 규율을 가지고 있지 않다면, 네트워크는 가치를 잃을 것이다. 오늘날의 웹은 필수적으로 데드 링크, 오래된 링크 등을 갖기 쉽다. 순수 네트워크 또는 그래프 정보 모델이 가진 다른 문제점은 정보 소비자가 웹 페이지 또는 사이트의 프리젠테이션의 제어하에서라기 보다는 그에 따라 좌우된다는 것이다. 바꾸어 말하자면, 웹 페이지 또는 사이트가 임의의 링크를 포함하지 않는다면, 사용자는 관련 정보를 찾으려 하지 않는다. 검색 엔진은 단지 네트워크로의 페이지 또는 노드들로 리턴하기 때문에 거의 도움이 되지 않는다. 네트워크 자체는 임의의 독립적인 또는 다이나믹한 링킹 능력을 가지고 있지 않다. 따라서, 검색 엔진은 그 자체가 링크를 가지고 있지 않거나 죽었거나, 진부하거나 관련없는 링크를 가지고 있는 웹 페이지들에 대한 링크를 쉽게 리턴할 수 있다. 일단 사용자가 검색 결과를 취득하면, 사용자들은 그들 자신에 대한 것이고 리턴된 페이지들의 저작자는 관련된, 시간-감도 링크를 페이지에 삽입했는지에 따라 완벽하게 된다.

시맨틱 웹은, 시맨틱 웹이 단지 오늘날의 웹 플러스 시맨틱스이기 때문에, 오늘날의 웹과 동일한 문제점을 겪는다. 사용자가 네트워크를 시맨틱하게 네비게이션할 수 있다고 할지라도(사용자들이 현재 웹을 작동할 수 없는), 그들은 정보가 어떻게 저작되었는지에 따라 여전히 좌우될 것이다. 바꾸어 말하자면, 시맨틱 웹은 저작자의 원칙에 따라 좌우되기 때문에, 상술한 오늘날의 웹의 동일한 문제점을 겪는다. 만일 시맨틱 웹이 온톨로지 및 메타테이터를 갖는 페이지를 포함하지만, 이들 페이지들은 잘 유지되지 않거나 다른 관련 소스로의 링크를 포함하지 않는다면, 사용자는 여전히 현재 링크 및 다른 정보를 취득할 수 없을 것이다. 시맨틱 웹은, 현재 고민하고 있는 바와 같이, 스마트하고, 다이나믹하며, 자기 저작(self-authoring), 자기 치료의 네트워크가 되지 않을 것이다.

사용자 제어의 네비게이션 및 브라우징(USER-CONTROLLED NAVIGATION AND BROWSING)

오늘날의 웹과 함께, 사용자는 네비게이션 및 브라우징 경험에 대해 제어할 수 없지만, 웹 페이지에 따라 완벽하게 되고 어떻게 링크가 저작되었는지를 알 수 있다. 종래 기술인 도 3을 참조하여 나타난 바와 같이, 오늘날의 웹은 네비게이션 되는 연속적인 유지에 전체적으로 좌우되는 "덤 링크(dumb link)" 또는 스태틱하게 저작된 일반적인 링크로 구성된다.

시맨틱 웹은 사용자 제어의 브라우징이 없다는 점에서 오늘날의 웹과 유사한 문제점을 겪는다. 그 대신에, 종래 기술인 도 4를 참조하여 나타난 바와 같이, 시맨틱 웹은 시맨틱 정보 및 메타데이터를 더 포함하는 "덤 링크"로 이루어져 있다. 그러나, 시맨틱 웹 링크는 네비게이션될 연속적인 유지에 따라 동일하게 좌우된다.

네트워크에서 비-HTML 및 로컬 문서 참여(NON-HTML AND LOCAL DOCUMENT PARTICIPATION IN THE NETWORK)

오늘날의 웹이 가진 다른 문제점은 HTML로서 저작되는 문서만이 웹에 참여할 수 있으며, 이러한 사실에 덧붙여서 이들 문서들은 링크를 포함해야만 하는 필수성이다. 비-HTML 문서와 같은 다른 정보 오브젝트(예를 들면, PDF, 마이크로소프트 워드, 파워포인트 및 액셀 문서 등)- 특히 사용자의 하드 드라이브에 있는 것들-는 네트워크에서 다른 오브젝트에 링크되는 이점으로부터 배제된다는 것을 의미한다. 이것은, HTML이 아니며 링크를 포함하고 있지 않은 정보 오브젝트 간에 시맨틱 컨텍스트는 있을 수 있기 때문에, 특히 매우 제한적이다.

게다가, 검색 엔진은, 웹 상에서 활용가능한 대량의 콘텐츠가 표준 웹 크롤러(crawler)에 접속할 수 없기 때문에, 전세계의 정보에 대한 결과를 리턴하지 못한다. 이것은 예를 들면, 데이터베이스, 인덱스되지 않은 파일 저장소, 가입 사이 트, 로컬 기계 및 디바이스, 독점 파일 포맷(예를 들면, 마이크로소프트 오피스 문서 및 이메일) 및 비-텍스트 멀티미디어 파일내에 저장된 콘텐츠를 포함한다. 인터넷 상에서 접속할 수 없는 문제의 광대한 집합체는 기업내의 "보이지 않는 사내망(invisible intranet)"으로서 언급된다. 오늘날의 웹은 이러한 문제를 구현하는 웹 크롤러 도구를 제공하지 않는다.

시맨틱 웹은 또한 이러한 제한을 겪는다. 이미 그곳에서 벗어난 수백만의 비-HTML 문서들, 특히 사용자의 하드 드라이브에 있는 것들은 구현할 수 없다. 이것은 RDF 메타데이터 등가물 또는 프록시를 가지고 있지 않은 문서들이 네트워크에 다이나믹하게 링크될 수 없다는 것을 의미한다.

디스플레이되는 정보의 시맨틱스를 스마트하게 표현하는 다양한 프리젠테이션(Flexible Presentation that Smartly Conveys the Semantics of the Information being Displayed)

오늘날의 웹은 사용자로 하여금 웹 사이트 또는 웹 페이지를 커스텀화하거나(customize) "스킨(skin)"으로 표현 할 수 없게 되어 있다. 이것은, 오늘날의 웹 서버가 브라우저에 의해 프리젠테이션용으로 이미 포맷되어 있는 정보를 리턴하기 때문이다. 최종 사용자는 상이한 기준(예를 들면, 정보의 타입, 활용가능한 양의 부동산 등)에 기초하여 정보를 표시하는 최적의 수단을 선택할 시 다양성이 없다.

시맨틱 웹은 다양한 프리젠테이션의 문제를 언급하지 않는다. 시맨틱 웹 사이트는 개념적으로 RDF 및 온톨로지를 사용하지만, 브라우저에 HTML을 여전히 전송한다. 필수적으로, 시맨틱 웹은 프리젠테이션에 대해 특정 사용자 권한을 제공하 지 않는다. 이와 같이, 오늘날의 웹 플랫폼에 의해 보여지는 시맨틱 웹 사이트는 사용자에게 다양한 프리젠테이션에 대해 권한을 여전히 부여하지 않을 것이다. 게다가, XML쪽으로의 산업 이동에도 불구하고, 새로운 플랫폼만이 프리젠테이션으로부터 데이터가 분리되게 될 것을 명령하고 데이터를 프로그램가능하게 만들기 위한 가이드라인을 정의할 수 있다. 시맨틱 웹에 대한 콘텐츠를 확립하는 저작자들은 XML을 리턴하고 프리젠테이션을 전체적으로 문제화하는 것을 피하거나, 랜더링하기 위한 단일 프리젠테이션 스타일(수직적인 산업 시나리오)에 그들의 노력을 집중시킨다. 그러한 방법 어느 것도 시맨틱 웹으로 하여금 최적의 지식 분배를 달성할 수 있게 할 수는 없다.

논리, 추론 및 추리(Logic, Inference and Reasoning)

오늘날의 웹이 어떠한 시맨틱스, 메타데이터 또는 지식 프리젠테이션도 가지고 있지 않기 때문에, 컴퓨터들은 논리 및 추론을 이용하여 새로운 링크를 추론하고 통지하는 웹 페이지를 처리할 수 없다. 오늘날의 웹은 컴퓨터가 사용하는 것이 아니라 인간이 사용하는 것으로 설계 및 구성되었다. 이와 같이, 오늘날의 웹은 메타데이터를 추출하고 논리 및 추론을 적용하기 위해 시도되는 스크린 스크랩핑(scraping)과 같은 다루기 힘들고 신뢰할 수 없는 기법에 이용하지 않고는 정보 구성을 조작할 수 없다.

시맨틱 웹이 개념적으로 컴퓨터에 의해 처리될 수 있는 인코딩된 정보를 웹 페이지 및 사이트에 제공하는 메타데이터 및 의미를 사용하는 반면, 컴퓨터 처리를 성공적으로 달성할 수 있으며, 정보 소비자 또는 생산자에게 이득이 되는 새롭거나 향상된 시나리오를 구현하기 위해서 현재 실행되는 것은 없다.

다양한 사용자 중심의 정보 분석(Flexible User-Driven Information Analysis)

오늘날의 웹은 사용자 중심의 정보 분석이 부족하다. 오늘날의 웹은 사용자가 상이한 필터들과 조건을 이용하여 링크의 상이한 "뷰우(views)"를 표시할 수 없게 한다. 예를 들면, 웹 검색 엔진들은 사용자가 상이한 시나리오하에서 검색의 결과들을 테스트할 수 없게 한다. 사용자들은 정보 타입(예를 들면, 문서, 이메일 등), 컨텍스트(예를 들면, "Headlines", "Best Bets" 등), 카테고리(예를 들면, "wirelss", "technology" 등)등과 같은 다른 관점(pivots)을 이용하여 결과를 볼 수 있다.

더 큰 정도의 다양한 정보 분석을 제공하는 반면, 시맨틱 웹은 어떻게 프리젠테이션 레이어가 웹 자체와 상호작용 방식으로 상호작용하여 다양한 분석을 제공할 수 있었는지를 기술하지 않는다.

다양한 시맨틱 질의(Flexible Semantic Queries)

오늘날의 웹은 단지 특정 웹 사이트의 구조에 얽매여 있는 질의 또는 문자에 기초한 질의를 허용한다. 이들 질의는 다양성이 부족하다. 오늘날의 웹은 사용자로 하여금 자연어에 근접하거나 시맨틱스 및 영역의 컨텍스트와 결합되는 질의를 할 수 없게 한다. 예를 들면, "검색시 나의 보스 또는 임의의 사람에 의해 기재되며 나의 하드 디스크상의 상세(specification)에 관련된 모든 이메일 메시지를 찾아라"와 같은 질의는 오늘날의 웹에서는 불가능하다.

메타데이터 및 온톨로지를 사용함으로써, 개념적인 시맨틱 웹은 사용자로 하여금 오늘날의 웹보다 다양한 질의를 제시할 수 있게 한다. 예를 들면, 사용자는 "검색시 나의 보스 또는 임의의 사람에 의해 기재된 모든 이메일 메시지를 찾아라"와 같은 질의를 할 수 있을 것이다. 그러나, 사용자는 영역의 컨텍스트(context)를 결합시킬 수는 없을 것이다. 또한, 시맨틱 웹은 자연어를 이용하지 않고 사용자가 웹에 질의를 하게 되는 쉬운 방식을 정의할 수 없다. 자연어 기술은 옵션이지만 신뢰가능한 기술과는 거리가 있다. 이와 같이, 자연어에 근접한 질의 사용자 인터페이스는 아직 자연어에 좌우되지 않는다. 시맨틱 웹은 이를 구현하지 않는다.

읽기/쓰기 지원(Read/Write Support)

오늘날의 웹은 읽기전용 웹이다. 예를 들면, 사용자가 데드 링크(예를 들면, "404" 에러를 통해)에 접하게 되는 경우, 사용자들은 사용자에게 알려질 수 있었던 업데이트된 타겟에 포인팅함으로써 링크를 "고정(fix)"시킬 수 없다. 이것은 특히, 사용자가 타인과 공유될 중요한 지식을 가지고 있는 경우와 사용자가 어떻게 네트워크가 표시되고 전개되어야 하는지에 대해 입력하기를 원하는 경우에 제한될 수 있다.

시맨틱 웹이 독립적인 참가 어플리케이션에 의해 제공되는 바와 같이, 읽기/쓰기 시나리오를 개념적으로 허용하는 반면, 현재 이러한 능력이 제공되어 실행되는 것은 없다.

주석(Annotations)

오늘날의 웹은 주석에 대한 함축적인 지원은 없다. 그리고 일부 특정 웹 사이트는 주석을 지원하지만, 그들은 매우 제한적이며 스스로를 제한하는 방식으로 한다. 오늘날의 웹 매체 자체는 주석을 기입하지 않는다. 바꾸어 말하자면, 사용자가 액세스하는 임의의 링크에 코멘트나 추가적인 정보의 주석을 다는 것은 불가능하다. 이것은 잠재적인 정보의 손실을 초래한다.

시맨틱 웹이 개념적으로 시스템에 만들어질 주석에 보안적인 제약이 있는 한, 이러한 기능을 제공하여 현재 실행되는 것은 없다.

"신뢰의 웹(WEB OF TRUST)"

오늘날의 웹은 웹에 인증, 액세스, 제어 및 권한 부여의 일체화된 통합, 또는 "신뢰의 웹"으로 일컬어져 왔던 것이 결여되 있다. 예를 들어, 신뢰의 웹을 이용하는 경우, 사용자는 웹에 링크를 주장, 고정 및 업데이트할 수 있으며 그러한 동작에 제공되는 제어 제한을 액세스할 수 있다. 오늘날의 웹상에서, 신뢰의 결여는 웹 서비스가 독점적인 사용자 가입 인증, 액세스 제어 또는 지불 시스템을 실행해야 하는 독립적인 아일랜드을 유지한다는 것을 의미한다. 제3자 서버들에 이 정보를 집중시키기 위한 커다란 구조는 개인적인 관심사 때문에 소비자 및 판매자를 불신하게 된다. 풍부한 콘텐츠에 액세스를 하기 위하여, 사용자는 개인적으로 로그인해야 하며 각 사이트에 식별 정보를 제공해야 한다.

시맨틱 웹이 신뢰의 웹을 개념적으로 허용하는 한, 현재 이러한 기능을 제공하는 것은 없다.

정보 패키지(INFORMATION PACKAGES;블렌더(BLENDERS))

오늘날의 웹 또는 시맨틱 웹 어느 것도, 중첩되는 결과(예를 들면, 커스텀, 사적인 신문 또는 TV 채널을 생성하는 것과 같음)를 생성하도록 근본적으로 발산하는 시맨틱 정보의 특성들을 결합함으로써, 사용자로 하여금 관련된 시맨틱 정보를 하나의 단위로 다룰 수 있게 허용하지 않는다.

컨텍스트 템플레이트(Context Templates)

오늘날의 웹 또는 시맨틱 웹 어느 것도 사용자로 하여금 정보 액세스 및 검색에 대한 특정 및 친숙한 시맨틱 모델을 독립적으로 생성하고 맵핑하는 것을 허용하지 않는다.

사용자 중심의 정보 집합(User-Oriented Information Aggregation)

오늘날의 웹은 사용자 중심의 정보 집합에 대한 지원이 부족하다. 사용자는 하나의 브라우징 세션의 컨텍스트내에서, 한번에 하나의 웹 사이트 또는 하나의 검색 엔진에 액세스할 수 있다. 이와 같이, 만일 사용자가 현재 보고 있는 정보에 관련된 다른 정보 소스 상의 컨텍스트-감도 또는 시간-감도 정보가 있다고 할지라도, 이들 소스는 사용자 태스크의 현재의 컨텍스트 지정 방식으로 제공될 수 없다.

시맨틱 웹은 또한 사용자 중심의 정보 통합의 부족을 겪는다. 매체 자체는 오늘날의 웹의 확장이다. 이와 같이, 사용자는 여전히 한번에 하나의 사이트 또는 하나의 검색 엔진을 액세스할 것이며 정보 저장소에 컨텍스트-감도 또는 시간-감도 방식으로 정보를 집합할 수 없을 것이다.

"당신의 손끝에 있는 지식"에 대한 증가하는 요구는 물론 오늘날의 웹 및 개념적인 시맨틱 웹에서의 결핍에서, 이들 대부분은 상술되어 있으며, 지식 검색, 관 리 및 전달의 새롭고도 통합적인 시스템 및 방법이 필요하다.

[발명의 상세한 설명]

본 발명은 부분적으로 지식 검색, 관리, 전달 및 프리젠테이션에 대한 통합되고 일정한 실행 프레임워크 및 결과 매체에 관한 것이다. 시스템은 통신 매체를 통해 프리젠테이션 플랫폼을 구동하는 클라이언트에 컨텍스트 및 시간 감도 시맨틱 정보 검색 서비스를 함께 작업하여 제공하는 몇 개의 구성요소들로 이루어진 서버를 포함한다. 서버는 도메인-특정 시맨틱 정보 또는 지능을 추가하고 유지할 수 있는 제1 서버를 포함한다. 제1 서버는 바람직하기로는 시맨틱 네트워크, 시맨틱 데이터 수집기(Gatherer), 시맨틱 네트워크 일관성 체커, 추론 엔진, 시맨틱 질의 프로세서, 자연어 분석기(Parser), 이메일 지식 에이전트 및 지식 도메인 매니저를 제공하도록 되어 있는 구조 및 방법론을 포함한다. 서버는 시맨틱 정보를 분류하고 카테고리화하는데 사용되는 도메인-특정 정보를 호스트하는 제2 서버를 포함한다. 제1 및 제2 서버는 함께 작업하고 물리적으로 통합 또는 분리될 수도 있다.

시스템 내에서, 소정 계층의 모든 오브젝트 또는 이벤트는 미리 결정되며 커스텀화 가능한(customizable) 테마 또는 "스킨(Skin)"에 따라 클라이언트에게 프리젠테이션용 데이터 오브젝트를 리턴시키는 질의(내장된 액션 코드로 이루어짐)을 나타내며 서로 시맨틱하게 관련된 액티브 에이전트이다. 이 시스템은 고객에게 에이전트들 및 내장된 관련 질의들을 커스텀화하고 "블렌드(blend)"하는 다양한 수단을 제공하여 최종 정보의 프리젠테이션을 최적화한다.

본 발명의 엔드-투-엔드(end-to-end) 시스템 구조는 커스텀 클라이언트와 프로그램 통합을 행할 수 있는 추가적인 SDK 레이어를 제공하는 본 발명에 의해 변형되는 바와 같이, 독립된 시맨틱 웹 플랫폼을 통해, 또는 전통적인 웹 포털(예를 들면, 오늘날의 웹 액세스 브라우저)를 통해 다양한 지식 정보 소스간에 통신의 다수의 클라이언트 액세스 수단을 제공한다.

본 발명의 방법론은 부분적으로 지식의 검색, 관리, 전달 및 프리젠테이션을 포함하는, 전체 시스템의 동작적인 관점에 관한 것이다. 이는 바람직하기로는 정보 소스로부터 정보를 보안하는 단계, 정보 소스로부터 정보를 시맨틱하게 링킹하는 단계, 시맨틱하게 링킹된 정보의 본문의 시맨틱 속성을 유지하는 단계, 사용자 질의에 기초하여 요구된 시맨틱 정보를 전달하는 단계, 및 커스텀화가능한 사용자 기호에 따라 시맨틱 정보를 제공하는 단계를 포함한다. 본 발명의 방법론의 선택적인 실시예는 서버측에서 사용되는 질의들을 나타내는 에이전트의 동작 및 시맨틱하게 관련있는 정보를 생성하는 효과적인 추론에 기초한 질의를 실행할 수 있는 클라이언트측 어플리케이션에 관한 것이다.

본 발명의 바람직한 실시예 및 선택적인 실시예들은 다음 도면들을 참조하여 이하에 상세히 기술된다.

[도면의 간단한 설명]

도 1은 오늘날의 웹(Today's Web)의 기술 레이어(layer)들을 나타내는 구성체계이다.

도 2는 개념적인 시맨틱 웹(Semantic Web)의 기술 레이어들을 나타내는 구성 체계이다.

도 3은 오늘날의 웹에서 링크에 대한 사용자 네비게이션을 나타내는 그림이다.

도 4는 개념적인 시맨틱 웹에서 링크에 대한 사용자 네비게이션을 나타내는 그림이다.

도 5는 본 발명에 따라 샘플 정보 에이전트 결과 창(pane)을 나타내는 스크린 도면이다.

도 6은 본 발명의 오늘날의 웹 및 정보 신경 시스템의 기술 플랫폼 스택을 나타내는 구성체계이다.

도 7은 본 발명의 시스템의 개요를 나타내는 그림이다.

도 8은 본 발명의 정보 신경 시스템에 대한 엔드-투-엔드(end-to-end) 시스템 구조를 나타내는 그림이다.

도 9는 본 발명의 정보 신경 시스템의 지식 통합 서버(KIS)에 대한 시스템 구조를 나타내는 그림이다.

도 10은 본 발명의 오늘날의 웹의 하이-레벨 설명 플랫폼 레이어와 정보 신경 시스템에서의 등가물(적용 가능한 경우)간의 비교도이다.

도 11은 정보 신경 시스템의 바람직한 실시예를 도시하며, 본 발명에 대한 이종의, 크로스-플랫폼 컨텍스트를 도시한 도면이다.

도 12 내지 도 14는 본 발명의 바람직한 실시예에 따른 블렌더 마법사 사용자 인터페이스의 특성에 대한 대표적인 스크린샷을 나타낸 도면이다.

도 15는 브레이킹 뉴스 에이전트 사용자 인터페이스의 대표적인 창을 나타낸 도면이다.

도 16은 본 발명의 오픈 에이전트 대화를 나타내는 바람직한 실시예의 도면이다.

도 17 내지 도 19는 오픈 에이전트 대화를 포함하는 샘플 시맨틱 환경의 3가지 뷰우(view)를 도시한 도면이다.

도 20은 본 발명의 바람직한 실시예의 에이전트 구성체계를 나타낸 도면이다.

도 21은 본 발명의 바람직한 실시예의 에이전트 타입 IDs를 나타낸 도면이다.

도 22는 본 발명의 바람직한 실시예의 에이전트 퀄리 타입 IDs를 나타낸 도면이다.

도 23은 본 발명의 KIS상에 어떻게 서버측 에이전트가 바람직하게 구성될 수 있는지를 보여주는 에이전트명에 대응하는 샘플 시맨틱 질의를 도시한 도면이다.

도 24는 본 발명의 KIS의 개요를 나타낸 그림이다.

도 25는 본 발명에 따라 기업 상황쪽으로 향한 샘플 시맨틱 네트워크를 도시한 그림이다.

도 26은 본 발명에 따라 오브젝트 타입의 바람직한 구성체계를 나타낸 테이블이다.

도 27은 본 발명의 시맨틱 링크 테이블을 나타낸 도면이다.

도 28은 본 발명의 바람직한 실시예의 술어 타입 IDs를 나타내는 테이블이다.

도 29는 본 발명에 따라 만들어진 바람직한 사용자 오브젝트 구성체계를 나타낸 테이블이다.

도 30은 사용자(사람) 오브젝트 구성체계와 바람직하게 관련된 메일링 어드레스 타입 IDs를 나타낸 테이블이다.

도 31은 본 발명에 따라 만들어진 바람직한 카테고리 오브젝트 구성체계의 테이블이다.

도 32는 본 발명에 따라 만들어진 바람직한 문서 오브젝트 구성체계의 테이블이다.

도 33은 바람직한 실시예의 프린트 미디어 타입 IDs를 나타낸 도면이다.

도 34는 바람직한 포맷타입ID(FORMATTYPEID)를 나타낸 도면이다.

도 35는 본 발명에 따라 만들어진 바람직한 이메일 메시지 리스트 오브젝트 구성체계를 나타낸 도면이다.

도 36 및 도 37은 본 발명의 바람직한 실시예의, 이메일 분배 리스트와 이메일 공개 폴더 오브젝트 구성체계를 각각 나타낸 대표적인 테이블이다.

도 38은 본 발명의 바람직한 공개 폴더 타입 ID(PublicFolderTypeID)를 나타낸 도면이다.

도 39는 본 발명에 따라 만들어진 바람직한 이벤트 오브젝트 구성체계 메시지 리스트 오브젝트 구성체계를 나타낸 도면이다.

도 40은 본 발명의 바람직한 실시예의 이벤트 타입을 나타낸 도면이다.

도 41은 본 발명에 따라 만들어진 바람직한 미디어 오브젝트 구성체계 메시지 리스트 오브젝트 구성체계를 나타낸 도면이다.

도 42는 본 발명의 바람직한 실시예의 미디어 타입을 나타내는 도면이다.

도 43 내지 도 45a 및 45b는 본 발명의 바람직한 실시예에서 어떻게 오브젝트가 카테고리화되고 활용되는지를 나타내는 추가적인 샘플의 도면이다.

도 46은 본 발명에 따른 시맨틱 네트워크에 처리 안한(raw) 이메일 XML 메타데이터의 맵핑을 나타내는 오브젝트 그래프이다.

도 47 내지 도 53은 KIS에 의해 에이전트 관리의 특성을 나타내는 대표적인 스크린 도면들이다.

도 54는 정보 에이전트 결과 창에 표시된 정보 오브젝트를 도시한 샘플 사용자 인터페이스를 나타낸 도면이다.

도 55는 본 발명에 따른 이메일 샘플을 나타낸 고유의 시맨틱 링크와 관련된 벌룬 팝업(balloon popup)의 일례를 나타낸 도면이다.

도 56은 본 발명에 따른 동사 사용자 인터페이스(Verb user interface)와 관련된 벌룬 팝업의 일례를 나타낸 도면이다.

도 57은 본 발명에 따른 딥(Deep) 정보 모드 사용자 인터페이스와 관련된 벌룬 팝업의 일례를 나타낸 도면이다.

도 58 및 도 59는 본 발명에 따른 대표적인 시맨틱 환경을 나타내는 도면들이다.

도 60 내지 도 68은 본 발명의 바람직한 실시예에 따른 정보 에이전트의 대표적인 스크린을 나타낸 도면들이다.

도 69 내지 도 71은 본 발명에 따른 정보 에이전트의 스마트 렌즈 특성과 관련된 대표적인 벌룬 팝업 메뉴를 제공하는 도면들이다.

도 72는 2개의 오브젝트의 컨텍스트 측정을 나타내는 도 71의 벌룬 팝업 메뉴의 변형의 일례를 나타낸 도면이다.

도 73 내지 도 75는 스마트 렌즈를 이용할 때 오브젝트 타입 술어를 포함하는 행동 및 관계를 도시한 샘플 테이블을 나타낸다.

도 76은 본 발명에 따른 시맨틱 결과 플레이어/프리뷰 제어를 도시한 사용자 인터페이스 샘플 도면이다.

도 77은 블렌더의 시맨틱 결과를 나타내는 사용자 인터페이스 샘플 도면이다.

도 78, 도 79a, 79b, 79c 및 79d는 본 발명의 대표적인 기능성 맵핑을 도시한 도면들이다.

도 80은 본 발명에 따른 에이전트 결과 및 대응하는 컨텍스트 팔레트를 나타낸 사용자 인터페이스 도면이다.

도 81은 본 발명에 따른 샘플 스마트 추천 팝업 컨텍스트 결과를 나타낸 도면이다.

도 82는 본 발명의 정보 신경 시스템의 기술 레이어를 나타낸 테이블이다.

도 83은 본 발명의 바람직한 실시예에 따른 다이나믹 링킹과 사용자 제어의 네비게이션 및 브라우징을 도시한 도면이다.

[실시예]

본 명세서에는 본 발명의 바람직한 실시예의 예시로서 대표적인 코드를 포함한다.

본 발명의 상세한 설명의 차례

A. 정의

B. 개요

1. 발명 컨텍스트

2. 가치 제안

3. 오늘날의 "정보(INFORMATION)" 웹 대(對) 본 발명의 정보 신경 시스템

C. 시스템 구조 및 기술 고찰

1. 시스템 개요

2. 시스템 구조

3. 기술 스택

4. 시스템 이질성

5. 보안

6. 효율 고찰

D. 시스템의 구성 요소 및 동작

1. 에이전시 및 에이전트

a. 에이전시

b. 에이전트

2. 지식 통합 서버

a. 시맨틱 네트워크

b. 시맨틱 데이터 수집기

c. 시맨틱 네트워크 일관성 체커

d. 추론 엔진

e. 시맨틱 질의 프로세서

f. 자연어 분석기

g. 이메일 지식 에이전트

h. 지식 도메인 매니저

i. 다른 구성 요소

3. 지식 기반 서버

4. 정보 에이전트(시맨틱 브라우저 플랫폼)

a. 개요

b. 클라이언트 구성 요소

c. 클라이언트 프레임워크 상세

d. 클라이언트 프레임워크

e. 시맨틱 질의 문서

f. 시맨틱 환경

g. 시맨틱 환경 매니저

h. 환경 브라우저(Semantic Browser 또는 Inforamaion Agent^TM)

i. 추가적인 어플리케이션 특징

5. 본 발명에서 제공된 컨텍스트

a. 컨텍스트 템플레이트

b. 컨텍스트 스킨

c. 스킨 템플레이트

d. 디폴트 술어

e. 컨텍스트 술어

f. 컨텍스트 속성

g. 컨텍스트 팔레트

h. 고유 경고

i. 스마트 추천

6. 본 발명의 특성 이점

E. 시나리오

1. 본 발명을 활용하는 시맨틱 질의의 예들

2. 사업상 문제점

3. 상황

A. 정의

액션스크립트(ActionScript). 마크로미디어 플래쉬(macromedia flash)의 언어를 스크립하는 것. 이 양방향 통신은 상호작용 영화에서 사용자들을 돕는다. http://www.macromedia.com/support/flash/action_scripts/actionscript_tutorial/을 참조하라.

에이전시(Agency). 웹 사이트의 시맨틱 등가물인 지식 통합 서버(KIS)의 지명된 예.

에이전시 디렉토리(Agency Directory). 에이전시에 관한 메타데이터 정보를 저장하며 클라이언트로 하여금 저장된 에이전시를 추가, 제거, 검색 및 브라우징할 수 있게 하는 디렉토리. 에이전시들은 LDAP와 같은 디렉토리들 또는 마이크로소프트 액티브 디렉토리에 공개될 수 있다. 에이전시들은 또한 에이전시들에 대해 구체적으로 만들어진 사적인 디렉토리에 공개될 수 있다.

에이전트(Agent). 특정 시맨틱 오브젝트 타입(예를 들면, 문서, 이메일, 사람들(people) 등), 컨텍스트(예를 들면, 헤드라인, 대화 등) 또는 블렌더(Blender)에 대한 XML 정보를 리턴시키는 시맨틱 필터 질의.

·Blender ^TM 또는 Compound Agent ^TM . 에이전트를 포함하며 사용자(클라이언트측 블렌더의 경우에) 또는 에이전시 매니저(서버측 블렌더의 경우에)로 하여금 그들이 가지고 있는 에이전트의 결과의 통합 또는 교점인 결과를 생성하는 질의들을 생성할 수 있게 하는 에이전트의 상표명. 클라이언트측 블렌더의 경우에, 결과는 상이한 뷰(view)(상이한 프레임으로 블렌더의 각 에이전트를 나타내는 것, 보유된 에이전트들에 대해 특정 오브젝트 타입의 모든 오브젝트를 보여주는 것 등)를 이용하여 생성될 수 있다.

·Breaking News Agent ^TM . 사용자가 시간-임계(time-criticality)를 가리키는 것으로서 특별히 태그(tag)시키는 스마트 에이전트에 대한 상표명. 사용자들은 임의의 스마트 에이전트를 브레이킹 뉴스 에이전트로서 태그시킬 수 있다. 이 속성은 사용자의 시맨틱 환경에 저장된다. 바람직하게, 브레이킹 뉴스 에이전트는, 표시되는 정보에 관련된 브레이킹 뉴스가 있는 경우 알림을 나타낸다.

·Default Agent ^TM . 사용자에게 제공된, 표준화되고 비사용자 변경가능한 에이전트에 대한 상표명.

·Domain Agent ^TM . 시맨틱 도메인에 속하는 에이전트에 대한 상표명. "카테고리(categories)" 테이블에 대한 참조를 포함하는 에이전트 질의로 초기화된다.

·Dumb Agent ^TM . 네트워크 공유 또는 웹 링크 또는 URL 상에서, 로컬 정보(로컬 하드 드라이브상에서)를 참조하고 에이전시를 갖고 있지 않은 에이전트에 대한 상표명. 덤 에이전트는 비-스마트 샌드박스(non-smart sandbox)(예를 들면, 파일 시스템 또는 인터넷)로부터 정보 아이템들(예를 들면, 문서들)을 스마트 샌드박 스(정보 에이전트(시맨틱 브라우저)를 통한 정보 신경 시스템)에 필수적으로 로드하는데 사용된다.

·Email Agent ^TM (또는 Email Knowledge Agent ^TM ). 에이전시상에서 정보를 공개 또는 주석을 달고 지식을 공유하는데 사용된 공개 에이전트에 대한 상표명.

·Favorite Agent ^TM . 사용자들이 선호하고 자주 액세스한다는 것을 표시하는 에이전트에 대한 상표명.

·Public Agent ^TM . 시스템 매니저에 의해 생성 및 관리되는 에이전트에 대한 상표명.

·Private 또는 Local Agents ^TM . 사용자들에 의해 생성 및 관리되는 에이전트의 상표명.

·Search Agent ^TM . 스마트 에이전트상에서 추가적인, 문자에 기초한 질의 필터를 불러내기 위하여, 키워드로 시맨틱 환경을 검색하거나 현존하는 스마트 에이전트를 검색함으로써 생성되는 스마트 에이전트의 상표명.

·Simple 또는 Standard Agent ^TM . 구성된, 비-시맨틱 질의(예를 들면, 로컬 파일 시스템 또는 데이터 소스로부터)을 요약하는 독립형 에이전트의 상표명.

·Smart Agent ^TM . XML 웹 서비스를 통해 에이전시에 참조하는 구성된, 시맨틱 질의를 요약하는 독립형 에이전트의 상표명.

·Special Agent ^TM . 컨텍스트 템플레이트에 기초하여 생성되는 스마트 에이전트의 상표명.

에이전트 디스커버리(Agent Discovery). 사용자가 다른 사람(친구 또는 동료)에 의해 생성된 새로운 서버측 에이전트 또는 클라이언트측 에이전트를 용이하면서도 자동적으로 발견할 수 있게 하는 본 발명의 정보 매체의 특성. 또한 "디스커버빌러티(Discoverability)"를 참조하라.

주석(Annotations). 정보 오브젝트에 개인적인 정황을 추가하는데 사용되는 주석, 코멘트 또는 설명. 바람직한 실시예에서, 주석은 그들이 지목한 오브젝트에 링크되며, 첨부물을 가질 수 있는 이메일 메시지이다(통상의 이메일 메시지와 거의 유사). 또한, 주석은 시스템에서 제1 클래스 정보 오브젝트이며 이와 같이 그들 자체가 주석이 될 수 있으며, 이로써 초기 오브젝트를 루트(root)로서 갖는 쓰레드 주석(threaded annotations) 또는 주석의 트리(a tree of annotations)를 초래한다.

어플리케이션 프로그래밍 인터페이스(API). 특정 컴퓨터 특성을 어떻게 소프트 저작자들이 활용할지를 정의한다. API는 윈도우 시스템, 파일 시스템, 데이터베이스 시스템, 네트워크 시스템 및 다른 시스템에 존재한다.

캘린더 액세스 프로토콜(CAP). 사용자가 iCalendar 표준에 기초하여 캘린더 스토어를 디지털식으로 액세스할 수 있게 하는 인터넷 프로토콜.

Compound Agent Manager ^TM . 사용자에게 에이전트를 추가 및 삭제함으로서 그들을 관리하기 위해서 컴파운드 에이전트를 생성 및 삭제할 수 있도록 프로그램적으로 허용하는 에이전트 구성 요소의 상표명.

컨텍스트(Context). 아이템을 해석하는 것은 물론 이 아이템에 관련된 다른 관련 정보를 찾을 시 정보 소비자를 지원하며 의미를 제공하는 특정 아이템에 관한 정보.

컨텍스트 결과 창(Context Result pane). 컨텍스트에 기초한 질의에 대한 결과를 표시하는 결과 창. 이들은 컨텍스트 팔레트, 스마트 렌즈, 딥 정보 등에 대한 결과를 포함한다. "결과 창(Results Pane)"을 참조하라.

컨텍스트-감도(Context-Sensitivity). 제공되는 모든 정보의 컨텍스트를 지능적이면서 다이나믹하게 인식할 수 있으며 컨텍스트는 있는 추가적인, 관련 정보를 제공할 수 있게 하는 정보 매체의 특성. 컨텍스트-감도 시스템 또는 매체는 적당한 컨텍스트(고유하게 그리고 관계적으로)로 정보를 제공하기 위하여 제공되는 정보의 시맨틱을 이해하고 적당한 행동(사용자의 행동에 기초한 사전행동 및 반응)을 제공한다.

Context Template ^TM . 정보 액세스 및 검색에 관한 특정의 친숙한 시맨틱 모델로 맵핑하는 시나리오 중심의 정보 질의 템플레이트의 상표명. 예를 들면, 본 실시예에서의 "헤드라인(Headlines)" 템플레이트는 "헤드라인(Headlines)"(높은 관심의 레벨의 플레시니스(freshness) 및 가능성(likelihood)은 검색의 1차 축(axes)인 경우)의 전달과 일관되는 파라미터를 갖는다. "업커밍 이벤트(Upcoming Events)" 템플레이트는 "업커밍 이벤트(Upcoming Events)"의 전송과 일관되는 파라미터를 갖는다. 기타 등등. 특히, 컨텍스트 템플레이트는 공지의 시맨틱 템플레이트를 사용함으로써 사용자에게 정보를 전송하는 개인적인, 디지털 시맨틱 정보 검색 "채널(channels)"을 유추할 수 있다.

Deep Information ^TM . 정보 에이전트가 정보 오브젝트에 관련된 고유의, 컨텍스트 정보를 표시할 수 있게 하는 본 발명의 특징에 대한 상표명. 오브젝트가 무엇으로부터 에이전트의 시맨틱 네트워크로부터 찾은 정보를 포함하는 컨텍스트 정보.

발견특성(Discoverability). 사용자가 정보를 명확하게 찾지 않고도 사용자에게 정보를 지능적이면서도 사전에 정보를 알리거나 볼 수 있게 하는 본 발명의 정보 매체의 능력.

Domain Agent Wizard ^TM . 에이전시 매니저가 도메인 에이전트를 생성하고 관리할 수 있게 하기 위한 시스템 구성 요소 및 사용자 인터페이스에 대한 상표명.

DOTNET(.NET). Microsoft　.NET은 정보, 사람들, 시스템 및 디바이스를 접속시키기 위한 마이크로소프트 소프트웨어 기술의 세트이다. XML 웹 서비스의 이용을 통한 소프트웨어 통합 즉, 인터넷을 통해 서로 접속되는 작고, 개별적인 빌딩-블럭 어플리케이션은 물론 다른, 큰 어플리케이션을 실행할 수 있다. .NET-접속 소프트웨어는 XML 웹 서비스의 생성 및 통합을 용이하게 한다. http://www.microsoft.com/net/defined/default.asp를 참조하라.

Dynamic Linking ^TM . 정보 아이템들이 자체적으로 링크를 포함하고 있지 않다고 할지라도, 사용자가 정보를 다이나믹하게, 시맨틱하게 그리고 사고의 속도로 링크할 수 있게 하는 본 발명의 정보 신경 시스템의 기능에 대한 상표명. 고유의 행동을 갖는 스마트 오브젝트를 사용하고 정보 에이전시의 XML 웹 서비스에 내장된 순환적인 지능을 이용함으로써, 시맨틱 네트워크의 각 노드는 오늘날의 웹 또는 개념적인 시맨틱 웹상의 통상의 링크 또는 노드보다 더 스마트해진다. 바꾸어 말하자면, 본 발명의 스마트 가상 네트워크 또는 웹의 각 노드는 저작(authoring)과는 독립적인 다른 노드에 링크할 수 있다. 각 노드는 드래그 및 드롭을 통해 에이전시 및 스마트 에이전트에 다이나믹하게 링크하고 시맨틱 환경에서 에이전시에 링크를 스마트 복사, 첨부(paste), 생성할 수 있고, 스마트 에이전트로부터 렌즈 요구에 응답하여 새로운 링크를 생성하며, 에이전시에 관한 컨텍스트-감도 및 시간-감도 정보에 링크를 다이나믹하게 생성하게 될 고유의 알림을 포함하고, 뉴스(노드가 이름공간에 브레이킹 뉴스 에이전트에 자동적으로 링크할 수 있는)를 브레이킹하기 위한 프리젠테이션 힌트를 포함하고,사용자가 새로운 링크를 찾을 수 있게 하는 기본 딥 인포(deep info)를 형성하는 등의 행동을 갖는다. 따라서, 본 발명의 사용자는 메타데이터의 저작자에 따라 좌우되지 않는다. 일단 사용자가 네트워크의 노드에 도달하면, 사용자는 스마트 에이전시 및 에이전트 등에 컨텍스트, 시간, 관계를 이용하여 다이나믹이면서도 자동적으로 네비게이팅하는 수많은 시맨틱 수단을 갖는다.

이메일 XML 오브젝트(Email XML Object). "이메일(Email)" 정보 오브젝트 타입을 갖는 정보 오브젝트. XML 오브젝트는 "이메일(Email)" SRML 구성체계(XML을 사용함)를 갖는다.

환경 브라우저(Environment Browser). 정보 에이전트를 참조하라.

Favorite Agents Manager ^TM . 에이전시 매니저가 서버측 즐겨찾기 에이전트를 관리할 수 있게 하는 시스템 구성 요소 및 사용자 인터페이스 엘리먼트에 대한 상표명.

플래쉬(Flash). 개발자 및 콘텐츠 저작자가 그들의 콘텐츠에 정교화된 그래픽 및 애니메이션을 내장할 수 있게 하는 마이크로미디어 플래쉬 사용자 인터페이스 플랫폼. http://micromedia.com/flash를 참조하라.

플래쉬 MX(Flash MX). 마이크로미디어 플래쉬 MX는 방대한 범위의 인터넷용 고밀도의 콘텐츠 및 풍부한 어플리케이션을 생성하기 위한 문자, 그래픽, 애니메이션 설계 및 개발 환경이다. http://www.macromedia.com/software/flash/productinfo/product_overview/를 참조하라.

Global Agency Directory ^TM . 인터넷(또는 다른 글로벌 네트워크)상에서 운영되는 에이전시 디렉토리의 일례에 대한 상표명. 글로벌 에이전시 디렉토리는 사용자에게 그들의 정보 에이전트를 이용하여 인터넷에 기초한 에이전시를 찾고, 검색하며 브라우징할 수 있게 한다(시맨틱 환경내에서 직접적으로). 또한, "에이전 시 디렉토리(Agency Directory)"를 참조하라.

HTTP. 하이퍼텍스트 트랜스퍼 프로토콜(Hypertext Transfer Protocol)은 분매, 통합, 하이퍼미디어 정보 시스템에 대한 어플리케이션-레벨 프로토콜이다. 요구 방법, 오류 코드 및 헤더의 확장을 통해, 이름 서버 및 분배 오브젝트 관리 시스템과 같은, 하이퍼텍스트의 이용을 벗어나 많은 태스크에 사용될 수 있는 일반적인, 스테이트리스(stateless) 프로토콜이다. HTTP의 특징은 시스템이 전송되는 데이터를 독립적으로 작성할 수 있게 하는 데이터 표현의 타이핑 및 연결 협상(negotiation)이다. http://www.w3.org/Protocols/와 http://www.w3.org/Protocols/Specs.html을 참조하라.

Inference Engine ^TM . 패턴 및 데이터를 관찰하여 추론에 의해 컨텍스트 있으며 논리적으로 유효한 결론에 도달하는 본 발명의 방법론에 대한 상표명. 바람직하기로는 추론 규칙(선정된 세트의 교수법)을 활용하여 본 발명의 시맨틱 네트워크에 시맨틱 링크를 추가하는 것이다.

정보(Information). 지식을 전송하는 콘텐츠 또는 데이터의 컨텍스트 및 지능의 양적이거나 질적인 측정.

Information Agent ^TM . 다중 소스, 정보 타입 및 템플레이트로부터 실행가능한 정보(또는 지식)의 컨텍스트-감도 및 시간-감도 전송 및 표현을 제공하며, 다양한 저장소에 걸쳐서 정보의 다이나믹한 링킹을 허용하는 본 발명의 시맨틱 클라이언트 또는 브라우저에 대한 상표명.

Information Nervous System ^TM . 손으로 태스크에 대한 지식의 취득 및 이용을 최대화하기 위하여, 사용자가 사고의 속도로, 그리고 컨텍스트-감도 및 시간-감도를 가지고 정보를 지능적이면서 다이나믹하게 링크할 수 있게 하는 본 발명의 다이나믹한, 자기-저작의, 컨텍스트-감도 및 시간-감도 정보 시스템의 상표명.

Information Object ^TM (또는 아이템 또는 패킷). 소정의 컨텍스트에 관한 지식을 포함하는 특정 타입의 정보 단위에 대한 상표명.

Information Object Pivot ^TM . 동일 컨텍스트내의 다른 관련 정보를 찾기 위해 사용자가 네이케이션 관점(navigational pivot)으로서 사용하는 정보 오브젝트의 상표명.

정보 오브젝트 타입(Information Object Type). 오브젝트 타입을 참조하라.

지능 에이전트(Intelligent Agent). 사용자를 대신하여 정보를 찾아 필터링하고, 서비스에 대해 협상하고, 복합 태스크를 쉽게 자동화하거나, 다른 소프트웨어 에이전트와 통합하여 복잡한 문제를 해결하는 소프트웨어 에이전트. 정의에 의해, 지능 에이전트는 자율적이어야 하거나, 바꾸어 말하자면 사용자의 개입없이 자유롭게 실행할 수 있어야 한다. 부가적으로, 지능 에이전트는 다른 소프트웨어 또는 휴먼 에이전트와 통신할 수 있어야 하며 그들이 속한 환경을 인식하고 모니터링하는 기능을 가져야만 한다. http://www.findarticles.com/cf_dls/m0FWE/7_4/64694222/p1/article.jhtml을 참조하라.

인터넷 캘린더링 및 스케쥴링(iCalendar). 인터넷용으로 공동 이용가능한 캘린더 및 스케쥴 서비스의 개발을 할 수 있는 프로토콜. 프로토콜은 인터넷을 통해 캘린더 및 스케쥴의 공개적으로 변경하기 위한 공통 포맷의 정의를 제공한다.

인터넷 메시지 액세스 프로토콜(IMAP). 메일 서버와 상호작용하여 클라이언트에게 메일을 보내고, 메일박스를 조정하기 위한 통신 메카니즘. 현재 가장 대중적인 메일 액세스 프로토콜은 아마도 포스트 오피스 프로토콜(Post Office Protocol; POP)이며, 또한 원격 메일 액세스 필요성을 어드레스한다. IMAP는 POP 특징의 슈퍼세트(superset)를 제공하며, 이는 훨씬 많은 복합적인 상호작용을 허용하고 POP 모델보다 훨씬 더 효과적인 액세스를 제공한다. http://www-smi.stanford.edu/projects/imap/ml/imap.html을 참조하라.

Intrinsic Semantic Link ^TM . 특정 정보 오브젝트의 구성체계에 대한 고유의 시맨틱 링크의 상표명. 예를 들어, 이메일 정보 오브젝트는 오브젝트 자체에 고유하며 이메일 정보 오브젝트 타입에 대한 구성체계를 정의한 "from", "to", "cc", "bcc" 및 "attachments"와 같은 고유의 링크를 갖는다.

아일랜드(Island). 관련된, 시맨틱하게 관련있는, 컨텍스트-감도 및 시간-감도 정보를 포함하지만 그러한 정보가 관련성이 있을 수 있는 다른 컨텍스트와는 단절되어 있는 다른 저장소로부터 분리된 정보 저장소.

J2EE. J2EE(JavaTM 2 Platform, Enterprise Edition)은 다층 기업 어플리케이션을 개발하기 위해 사용되었다. J2EE는 서비스의 세트를 표준화되고 모듈화된 구성요소에 제공하고 어플리케이션 행동의 수많은 상세를 자동적으로 다룸으로써, 상기 구성요소에 대한 기업 어플리케이션에 기초를 가지고 있다. http://java.sun.com/j2ee/overview.html를 참조하여라.

지식(Knowledge). 관련 태스크에 대한 결정을 보다 스마트하면서도 적절하게 하기 위하여 정보 소비자가 정보로부터 배우고 정보를 적용할 수 있는 컨텍스트-감도 및 시간-감도 방식으로 제공된 정보.

Knowledge Agent ^TM . 정보 에이전트를 참조하라.

Knowledge base Server ^TM (KBS). 지식 통합 서버(KIS)에 대한 지식을 호스트하는 서버의 상표명.

Knowledde Domain ManagerTM(KDM). 시맨틱 네트워크상에서 도메인-특정 지능을 추가하고 유지하는 것을 담당하는 지식 통합 서버의 구성 요소에 대한 상표명.

Knowledge Integration Server ^TM (KIS). 다수의 이종 소스로부터 시맨틱 네트워크로 데이터를 시맨틱적으로 통합하며, 또한 네트워크에 액세스를 제공하는 서버측 에이전트를 호스트할 수 있고 서버상에서 지식에 대한 컨텍스트-감도 및 시간-감도 액세스를 제공하는 XML 웹 서비스를 호스트할 수 있는 서버의 상표명.

Knowledge Web ^TM . 정보 신경 시스템을 참조하라.

자유 연합(Liberty Alliance). 자유 연합의 비전은 필요한 개인 식별 정보 의 프라이버시 및 보안을 유지하면서 개인 및 비지니스가 보다 쉽게 거래를 수행할 수 있는 네트워크화된 세계를 실현하는 것이다. 이 비전을 달성하기 위하여, 자유 연합은 공개된 기술 스펙을 통하여 연합된 네트워크 식별을 위한 공개된 표준을 설정하도록 한다. http://www.projectliberty.org/index.html를 참조하라.

Lightweight Directory Access Protocol(LDAP). 공통 디렉토리 정보에 액세스하기 위한 기술. LDAP는 대부분의 네트워크 중심의 미들웨어를 포함하고 시행하여 왔다. 공개로서, 판매자-중립 표준, LDAP는 오늘날의 분배 시스템 및 서비스에 활용될 필요가 있는 정보의 중앙집중적인 저장 및 관리에 대한 확장가능한 구조를 제공한다. LDAP는 현재 대부분의 네트워크 구동 시스템, 그룹웨어 및 심지어 쉬링크-랩(shrink-wrapped) 네트워크 어플리케이션에 지원된다. http://public-b.boulder.ibm.com/Redbooks.nsf/RedbooksAbstracts/sg244986.html?Open을 참조하라.

Link Template ^TM . 컨텍스트 템플레이트를 참조하라.

로컬 컨텍스트(Local Context). 로컬 컨텍스트는 클라이언트측 정보 오브젝트 및 사용자에게 액세스할 수 있는 에이전트를 의미한다. 이는 시맨틱 환경내의 에이전트, 로컬 파일, 폴더, 사용자의 이메일 인박스내의 이메일 아이템, 사용자의 즐겨찾기(favorite) 및 최근 웹 페이지, 현재 웹 페이지, 현재 열어본 문서, 및 사용자의 현재 태스크, 위치, 시간 또는 컨디션을 나타내는 다른 정보 오브젝트를 포함한다.

의미(Meaning). 정보의 활용을 극대화하기 위하여, 정보의 소비자가 (텍스트 또는 데이터에 상반되는)관련 정보 콘텐츠에 기초하여 찾거나 네비게이트할 수 있게 하고 컨텍스트-감도 및 시간-감도 방식으로 작용할 수 있게 하는 정보 행동의 속성.

메타데이터(Metadata). "데이터에 관한 데이터". 정보 오브젝트를 완벽하게 기술하는 데이터 필드, 링크 및 속성을 포함한다.

자연어 분석기(Natural Language Parcer). 자연어 질의를 이해하고 이들을 구조화된 시맨틱 정보 질의로 번역할 수 있는 소프트웨어 구성 요소를 분석 및 해석하는 것.

Nervana ^TM . 정보 신경 시스템 정보 매체/플랫폼의 독점적인 엔드-투-엔드 실행의 상표명. 이 명칭은 또한 소스 형태와 정해진 술어 명칭의 적절한 명칭공간을 정의한다.

.NET 패스포트(.NET Passport). 마이크로소프트 .NET 패스포트는 인터넷 및 온라인 구매에 관한 웹에 기초한 서비스의 한 세트이다. .NET 패스포트는 수적으로 성장하는 참여 사이트에서, 사용자에게 SSI(single sign-in)과 빠른 구매 기능을 제공하며, 정보 사용자의 수를 감소시키는 것은 기억(remember) 또는 재타이핑(retype)해야 한다. .NET 패스포트는 큰 사용자 베이스에 대한 고품질의 온라인 체험을 제공하고 데이터의 보호를 위해 강력한 암호화 기술 -예를 들면, SSL(Secure Sokets Layer)와 3DES(Triple Data Encryption Standard) 알로리즘-을 사용한다. 개인 프라이버시는 최 우선이며, 모든 참여 사이트들은 그들이 우편물에 동의하고 기업에서 수용한 가이드라인에 첨부된 개인 프라이버시 정책을 따르는 계약에 사인한다.

네트워크 영향(Network Effects). 이것은 다른 사람들의 수가 특정 사용자에 대한 제품 또는 서비스의 가치에 영향을 미칠 때 존재한다. 전화 서비스는 명확한 예를 제공한다. 사용자에 대한 전화 서비스의 가치는 다른 가입자들의 수의 함수이다. 몇몇은 누군가에게 접속되지 않았던 전화기에 관심을 가질 것이고, 대부분은 로컬 네트워크라기 보다는 전국적인 네트워크에 링크된 전화 서비스에 더 높은 가치를 매길 것이다. 유사하게, 많은 컴퓨터 사용자들은 그들이 다른 사용자들과 즉시 정보를 교환할 수 있는 컴퓨터 시스템을 가치있게 생각한다.

네트워크 영향은 성공적인 제품이 보다 성공적으로 될 수 있는 포지티브 피드백 영향을 생성하는 수요측 외면성이다. 이와 같이, 네트워크 영향은 스케일 및 범위의 공급측 경제에 대한 유사성이 있다. 회사의 출력이 증가함에 따라, 평균 비용이 더 낮아지고, 가격을 낮출수 있으며, 경쟁업체로부터 추가적인 비지니스를 얻어 올 수 있게 된다. 연속적인 확장은 훨씬 더 낮은 평균 비용을 초래하고 또한 가격을 훨씬 더 낮추게 된다. 유사하게, 네트워크 영향으로부터의 포지티브 피드백은 이전에 성공했을 때 만들어진다. 컴퓨터 산업에서, 예를 들면, 사용자들은 더 많은 대중적인 컴퓨터 시스템에 더 많이 지불하며, 그밖의 모든 것은 만일 2개의 컴퓨팅 시스템의 가격 및 다른 특징들이 동일하다면 더 크게 설치된 베이스를 갖는 시스템을 선택한다. http://www.ei.com/publications/1996/fall1.htm를 참조 하라.

NNTP(Network News Transfer Protocol). ARPA-인터넷 공동체중에서 신뢰할만한 스트림에 기초한 뉴스의 전송을 이용하여 뉴스 기사의 분배, 조사, 검색 및 게시하기 위한 프로토콜. NNTP는 가입자들이 읽기를 원하는 아이템만을 선택할 수 있도록 한 중앙 데이터베이스에 뉴스 기사가 저장되도록 설계되어 있다. 인텍싱, 상호 참조 및 오래된 메시지의 만료가 또한 제공된다.

통지(Notifications). 통지는 에이전트(클라이언트측 에이전트 또는 서버측 에이전트 중 어느 하나)에 대한 새로운 정보가 있다는 것을 사용자에게 가리키기 위해 정보 에이전트 또는 에이전시에 의해 송신되는 경고이다. 사용자들은 그들의 시맨틱 환경에서 에이전트로부터 통지를 요구할 수 있다. 사용자들은 그들이 통지를 수신했음을 표시할 수 있다. 통지 소스(클라이언트 또는 서버)는 에이전트에 대한 통지를 사용자가 확인한 최종 시간을 가리키는 사용자 및 에이전트에 대한 정보를 저장한다. 통지 소스는 최종 확인 시간이후로 새로운 정보가 있다면 에이전트가 체크했는지 검사한다. 만일 있다면, 통지 소스는 사용자에게 알린다. 경고(Alerts)는 이메일, 페이저, 음성 또는 마이크로소프트사의 .NET 경고 서비스와 같은 통상의 경고 메카니즘을 통해 전송될 수 있다. 사용자들은 (통지 소스에 표시된 기호를 무시하는) 에이전트 기초에 따라 -통지 소스에 대한 모든 에이전트에게 적용하는- 전체 통지 소스(클라이언트 또는 서버)에 대한 바람직한 통지 메카니즘을 가리키는 옵션을 가진다.

오브젝트(Object). 정보 오브젝트를 참조하라.

오브젝트 타입(Object Type). 소비자가 정보의 특성을 이해하고, 그 콘텐츠를 해석하고, 정보가 어떻게 작용될 수 있는지를 예측하며, 이를 오브젝트 타입이 어떻게 실제 세계에서 관련될 수 있는지에 기초하여 다른 상관 정보 아이템에 링크할 수 있게 하는 정보와 관련된 식별 데이터. 예를들면, 문서, 이벤트, 이메일 메시지, 사람들 등이 있다.

온톨로지(Ontology). 필수적인 품질에 따른 지식의 계층적인 구조. 온톨로지는 개념의 명백한 상세이다. 이 용어는 철학으로부터 차용된 것으로, "Ontology"는 존재의 의미론적(systematic) 이유이다. 인공적인 지능 시스템의 경우, "exists"라는 것은 표현될 수 있는 것이다. 도메인의 지식은 진술 형식주의로 표현되며, 표현될 수 있는 오브젝트의 세트는 논리의 영역이라 칭한다. 이 오브젝트의 세트와, 이들간의 기술가능한 관계는 지식에 기초한 프로그램이 지식을 나타내는 표현적인 단어로 반영된다. 따라서, 인공적인 지능의 컨텍스트에서, 프로그램의 온톨로지는 표현 용어의 세트를 정의함으로써 기술된다. 이러한 온톨로지에서, 정의라는 것은 명칭이 의미하는 것을 기술하는 인간이 읽을 수 있는 문자와, 해석을 해야하는 형식적인 원리와 이들 용어의 잘 형식화된 이용을 통해 논리의 영역에서 실체의 명칭을 관련시키는 것이다. 형식상, 온톨로지는 논리 이론의 명령문이다.

온톨로지의 과제는 일부 도메인에 존재하거나 존재할 수도 있는 물건의 카테고리의 연구이다. 온톨로지라고 불리는, 이러한 연구의 산물은 D에 관해 이야기 하는 의도에 대해 언어 L을 이용하는 사람의 관점으로부터 관심 D의 도메인에 존재 한다고 가정되는 물건의 타입에 대한 카테고리이다. 온톨로지의 타입은 도메인 D에서 토픽을 논의하는데 사용될 때 언어 L의 술어, 워드 센스 또는 개념 및 관계 타입을 나타낸다. 일반적으로 http://www-ksl.stanford.edu/kst/what-is-an-ontology.html과 http://users.bestweb,net/~sowa/ontology/를 참조하라.

술어(predicate). 술어는 결과가 일부 조건의 진실 또는 거짓을 나타내는 속성 또는 링크이다. 예를 들면, 술어 "authored by" 는 정보 오브젝트를 가진 사람을 링크시키고 사람이 오브젝트를 저작했는지를 가리킨다.

Presenter ^TM . 시맨틱 질의 프로세서(바람직하기로는, SQML을 해석하는)로부터 결과의 본 발명의 정보 에이전트(시맨틱 브라우저)의 시스템 구성 요소. 프리젠터(Presenter)는 레이아웃 관리, 집합, 네비케이션, 스킨 관리, 컨텍스트 팔레트의 제공, 상호작용, 애니메이션 등을 다룬다.

RDF. RDF(Resource Description Framework)는 메타데이터를 처리하기 위한 기초이며; 웹상에서 기계가 이해할 수 있는 정보를 교환하는 어플리케이션들 간의 정보처리 상호 운용을 제공한다. RDF는 웹 리소스의 자동화된 처리를 실행하는 설비를 강조한다. RDF는 명명된 특성 및 가치에 관하여 리소스간의 관계를 설명하기 위한 간단한 모델을 정의한다. RDF는 특성은 리소스의 속성의 사고일 수 있으며 감각면에서 전통적인 속성 가치 쌍에 대응한다. RDF 특성은 또한 리소스간의 관계를 나타낸다. 이와 같이, RDF 데이터 모델은 실체 관계 다이어프램과 유사할 수 있다.

RDF는 다양한 어플리케이션 영역에, 예를 들면, 더 나은 검색 엔진을 제공하는 리소스 발견시, 지식 공유 및 교환를 활용하는 지능 소프트웨어 에이전트에 의해 특정 웹 사이트, 페이지 또는 디지털 라이브러리에서 활용가능한 콘텐츠 및 콘텐츠 관계의 기술을 카탈로그화할 시, 웹 페이지의 지적 재산권을 설명하고, 사용자의 개인적인 기호는 물론 웹 사이트의 개인적인 방침을 표현하기 위한 단일 논리 "document"를 나타내는 페이지들의 수집을 기술할 시 사용될 수 있다. 전자 서명을 포함하는 RDF는 바람직하기로는 전자 상거래, 협조 및 다른 어플리케이션에 대한 "Web of Trust"를 이루는 하나의 구성요소이다. 일반적으로 http://www.w3.org/TR/PR-rdf-syntax/와 http://www.w3.org/TR/rdf-schema/를 참조하라.

RDFS. RDF 구성체계에 대한 두문자어(Acronym). 리소스 설명 공동체는 임의의 종류의 리소스에 관한 임의의 사고를 말하는 능력을 필요로 한다. 도서목록 리소스를 기술하는 경우, 예를 들면, "저작자(author)", "제목(title)" 및 "과제(subject)"를 포함하는 설명 속성이 공통된다. 디지털 증명서의 경우, "checksum" 및 "authorization"와 같은 속성들이 종종 필요하게 된다. 이들 특성(속성) 및 이들의 대응하는 시맨틱스의 진술은 RDF의 컨텍스트에서 RDF 구성체계로 정의된다. 구성체계는 리소스의 특성(예를 들면, 제목, 저작자, 과제, 사이즈, 컬러 등)은 물론, 상술된 리소스의 종류(책, 웹 페이지, 사람들, 회사 등)을 정의한다. http://www.w3.org/TR/rdf-schema/를 참조하라.

Results Pane ^TM . SQML 질의의 결과를 표시하는 정보 에이전트(시맨틱 브라우저)내의 그래픽 디스플레이 영역에 대한 상표명. 서버측 에이전트, 추가적인 플레이어 컨트롤/네비게이션/필터 툴바, "서버측 에이전트 대화(Server-Side Agents Dialog"(사용자가 서버측 에이전트를 브라우즈 및 오픈할 수 있게 함) 및 서버측 에이전트로부터의 샘플 결과("문서(Documents)" 정보 오브젝트 타입을 가짐)를 도시한 샘플 정보 에이전트 스크린샷을 나타낸 도 5를 참조하라.

시맨틱스(Semantics). 암시적인 의미.

Semantic Environment ^TM . 이것은 에이전시 서버(예를 들면, 서명된 서버측 에이전시, 서버측 즐겨찾기 에이전트 등)에 대한 사용자 특정 데이터에 부가하여 사용자의 로컬 기계에 저장된 모든 데이터를 의미한다. 클라이언트측 상태는 각 클라이언트측(사용자가 생성한) 에이전트에 대한 SQML 파일 및 버퍼에 부가하여, 즐겨찾기 및 최근 에이전트와 인증 및 인증 정보(예를 들면, 다양한 에이전시에 대한 사용자명 및 패스워드)를 포함한다. 정보 에이전트는 "즐겨찾기(favorites)" 리스트에 부가되었던 것들을 제외하고, 자동적으로 삭제하기 전에 한 세트의 시간량에 대한 에이전트를 저장하도록 구성하는 것이 바람직하다. 예를 들면, 사용자들은 2주 동안 에이전트를 저장하는 정보 에이전트를 구성할 수 있다. 이 경우, 2주보다 더 오래된 에이전트는 자동적으로 시스템으로부터 제거되고 시맨틱 환경은 그에 따라 조정된다. 시맨틱 환경에는 컨텍스트 팔레트(컨텍스트 팔레트는 디폴트 에이전시 사용자들이 컨텍스트 형태를 보기를 원한다는 것을 예보하기 위하여 "최 근(recent)" 및 "즐겨찾기(favorites)" 리스트내에 있는 에이전시를 이용한다)가 사용된다.

Semantic Environment Manager ^TM . 시맨틱 환경(정보 에이전트에서)에 대한 모든 로컬 상태를 관리하는 소프트웨어 구성 요소의 상표명. 이는 모든 클라이언트측 에이전트에 대한 메타데이터(그리고 히스토리 및 즐겨찾기 에이전트 서브-리스트)를 저장하고 관리하는 것, 에이전트 상태(예를 들면, 에이전트 스킨, 에이전트 기호 등), 통지 관리, 에이전시 브라우징(에이전시 디렉토리 상에서), 멀티캐스트 및 피어-투-피어 알림 프로토콜을 통한 에이전시의 리스닝, 사용자로 하여금 시맨틱 브라우저를 통해(트리 뷰(tree view), "Open Agent" 대화 및 결과 창(Results Pane)을 통해) 시맨틱 환경을 브라우징할 수 있는 서비스 등을 포함한다.

Semantic Data Getherer ^TM (SDG). KIS(Knowledge Integration Server)에 의해 사용되며, SMS(Semantic Metadata Store)를 통해 시맨틱 네트워크내의 엔트리를 추가, 제거 및 업데이트할 수 있는 XML 웹 서비스의 상표명.

Semantic Metadata Store ^TM (SMS). 각 1차 오브젝트 타입에 대한 테이블을 갖는 데이터베이스(예를 들면, SQL 서버, 오라클(oracle), DB2)를 사용하여 KIS상에 모든 메타데이터를 저장하는 KIS상의 소프트웨어 구성 요소의 상표명.

Semantic Network. 시맨틱 메타데이터 스토어상의 데이터베이스 테이블을 통해 시맨틱 방식으로 함께 구성체계와 관련된 오브젝트들을 링킹하는 시스템 및 방법.

Semantic Network Consistency Checker ^TM . 시맨틱 네트워크의 보전 및 일관성을 유지하여 태스크되는 본 발명의 에이전시를 운영하는 소프트웨어 구성 요소의 상표명. 체커(checker)는 "SemanticLinks" 테이블내의 엔트리가 고유의 오브젝트 테이블에 존재하는지, "objects" 테이블내의 엔트리가 고유의 오브젝트 테이블내에 존재하는지, 그리고 시맨틱 메타데이터 스토어내의 모든 엔트리가 수집되어 있는 저장소에 여전히 존재하는지를 주기적으로 실행하여 확실하게 한다.

시맨틱 질의(Semantic Queries). 의미, 컨텍스트, 시간-감도, 컨텍스트-템플레이트 및 자연어에 근접하는 풍부함을 결합한 질의. 간단하다기 보다는 훨씬 더 강력한, 키워드에 기초한 질의들은 컨텍스트, 시간-감도이며 이들 질의들에는 의미 또는 시맨틱이 결합된다.

SQML(Semantic Query Markup Language). 클라이언트측 시맨틱 질의를 정의, 저장, 해석 및 실행하기 위한 본 발명에 의해 사용된 독점적인 XML에 기초한 질의 언어. SQML은 파일, 폴더, 어플리케이션 저장소와 같은 상이한 리소스로부터의 데이터(데이터 소스를 나타냄)를 취득하고, 에이전시 XML 웹 서비스(리소스 식별자 및 URL을 통해)를 참조하는 질의를 정의하는 태그(tags)를 포함한다. 또한, SQML은 데이터가 어떻게 리소스로부터 질의 및 필터링되는지를 시맨틱 필터링(커스텀 링크 및 술어를 통해)할 수 있는 태그(tags)와, 어떻게 리소스가 질의되는지 그리고 결과가 어떻게 필터링되는지를 나타내는 인자(argument)를 포함한다. 특히, 인자는 로컬 또는 원격 컨텍스트에 대한 참조를 포함할 수 있다. 이 컨텍스트 아규 먼트는 XML 메타데이터에 실행 시간으로 클라이언트측 SQP에 의해 해결된다. XML 메타데이터는 리소스 및 시맨틱 링크에 대한 참조와, 질의가 어떻게 리소스(예를 들면, 에이전시의 XML 웹 서비스)에 의해 해결되는지를 가리키는 술어과 함께 방법 호출로서 적당한 리소스(예를 들면, 에이전시의 XML 웹 서비스)에 통과된다. SQML은 HTML이 오늘날의 웹인것과 같이 정보 신경 시스템이다. 주요 차이점은 HTML이 하이퍼텍스트 프리젠테이션에 대한 룰을 정의하는 반면에 SQML은 시맨틱 질의에 대한 루울을 정의한다는 것이다. 그러나, SQML은 예를 들어, 드래그 및 드롭 그리고 스마트 복사 및 첨부(paste), 스마트 렌즈, 컨텍스트 템플레이트 및 팔레트 등을 통해, 클라이언트가 현존하는 것으로부터 새로운 시맨틱 질의를 반복적으로 생성할 수 있게 한다는 점(현존하는 SQML 질의로부터 유추된 새로운 링크로 새로운 SQML을 생성함으로써)에서 뛰어나다. 또한, SQML이 프리젠테이션용 루울을 정의하고 있지 않기 때문에, 시맨틱 질의의 결과는 사용자의 기호, 관심, 컨디션 또는 컨텍스트에 기초한 프리젠테이션을 생성한 결과(SRML에서)를 취하는 "skin"를 이용하여 다수의 방식으로 표현될 수 있다. 또한, SQML은 컨텍스트 템플레이트를 참조 또는 사용하는 것과 같은 요약 링크 및 술어를 포함할 수 있다. 리소스(에이전시의 XML 웹 서비스)는 적당한 질의 포맷(예를 들면, SQL 또는 에이전시의 XML 웹 서비스의 경우의 등가물)에 대한 SQML을 분석하며 "actual" 질의를 불러내는데, 이는 결과(사용자의 컨텍스트 또는 컨텍스트 템플레이트를 설명하게 되는)를 생성하기 위한 것이다. 또한, SQML 버퍼 또는 파일은 다수의 리소스(그리고 에이전시)를 참조할 수 있으며, 이로써 클라이언트로 하여금 데이터의 소스에 기초한다기 보다는 통합된 방식으로 결과를 볼 수 있게 한다(이것은 사용자 제어의 브라우징 및 정보 통합(이하의 세션을 참조)을 실행하는 본 발명의 강력한 특징임). 결국, 모든 클라이언트측 에이전트는 모든 웹 페이지가 HTML 파일을 가지고 있는 것과 같이 SQML 정의 및 파일을 갖는다.

Semantic Query Processor ^TM (SQP). SQML을 취하여 이를 SQL(본 바람직한 실시예에서)로 변환하고 나서 그 결과를 XML로 리턴시키는 서버측 시맨틱 질의 프로세서(바람직한 실시예의 XML 웹 서비스)에 대한 상표명. KIS에서, SQP는 KIS의 클라이언트로부터 시맨틱 질의에 대한 응답을 담당하는 본 발명의 시맨틱 네트워크에 대한 메인 엔트리 포인트이다. 서버상에서, 이것은 클라이언트로부터 SQML로서 표현되는 시맨틱 질의를 처리하는 소프트웨어 구성 요소이다. 클라이언트상에서, 클라이언트측 SQP는 SQML 통합을 착수하며 이를 서버(또는 에이전시) XML 웹 서비스에 전송할 수 있는 개인적인 SQML 질의에 응하거나 맵핑한다.

SRML(Semantic Results Markup Language). 시맨틱 결과를 정의, 저장, 해석 및 제공하는 본 발명에 의해 사용된 독점적인 XML에 기초한 데이터 구성체계 및 포맷. 클라이언트측에서, SRML은 시맨틱 데이터 소스에 해석, 포맷 및 질의 요구를 행하는 시맨틱 리소스 핸들러를 통해 SQP로부터 리턴된다. 시맨틱 데이터 소스는 로컬 또는 원격 어플리케이션(예를 들면, 마이크로소프트 아웃룩 이메일 어플리케이션 인박스) 등으로부터 에이전시의 XML 웹 서비스, 로컬 파일, 로컬 폴더, 커스텀 데이터 소스를 포함할 것이다. XML 웹 서비스는 클라이언트의 시맨틱 질의에 응답하여 클라이언트에 SRML을 리턴시킬 것이다. 이 방식, XML 웹 서비스는 결과가 클라이언트에 어떻게 제공되고 있는지를 "care" 하지 않을 것이다. 이는 서버들이 클라이언트에게 이미-포맷된 HTML를 리턴시켜 제공하며, 클라이언트가 프리젠테이션 데이터(시맨틱 데이타와는 상반되게)를 제공만하고 데이터의 제공을 커스텀화할 수 없는 오늘날의 웹 및 시맨틱 웹과 대조를 이룬다. 본 발명에서, 2개의 클라이언트는 어느 한 클라이언트의 사용자에 의해 선택 또는 적용되었던 현 "skin"에 기초하여 동일한 SRML을 완벽하게 다른 방식으로 만들 수 있다. 그리고 나서, "skin"은 SRML을 XHTML, DHTML+TIME, SVG, Flash MX 등과 같은 프리젠테이션-레디(presentation-ready) 포맷으로 변환한다.

SRML은 상이한 정보 오브젝트 타입(예를 들면, 문서, 이메일, 사람들, 이벤트 등)에 대한 데이터를 포함할 수 있는 콘테이너 포맷를 의미하는, 메타-구성체계(meta-schema)이다. SRML 파일 또는 버퍼는 이들 각 오브젝트 타입에 대한 서로 얽힌 결과를 포함할 수 있다. 잘 형성된 SRML은 SRML이 나타난 시맨틱 결과에 포함되어 있는 정보 오브젝트 타입의 구성체계와 일치하는 잘 형성된 XML 문서 세션을 포함할 것이다. 부록의 샘플 A를 참조하라.

시맨틱 웹(Semantic Web). 정보가 잘 정의된 의미를 가지며 컴퓨터 및 사람들이 협력하여 작업할 수 있도록 한 오늘날의 웹의 확장. Tim Berners-Lee, James Hendler, Ora Lassila, The Semantic Web, Scientific American, 2000년 5월을 참조하라.

오늘날의 웹상에서 기계가 이해할 수 있는 데이터가 갖는 유용성은 많은 공 동체에 대한 높은 우선도가 되고 있다. 웹은, 데이터가 자동화된 도구는 물론 사람들에 의해 공유 및 처리될 수 있는 장소가 된다면, 완벽한 잠재력에 도달할 수 있다. 스케일이 있는 웹의 경우, 장래(tomorrow)의 프로그램은 이들 프로그램들이 전체적으로 독립적으로 설계되었을 때 조차도 데이터를 공유 및 처리할 수 있어야만 한다. 시맨틱 웹은 개념적인 비젼, 즉 단지 디스플레이 목적이 아니라 다양한 어플리케이션을 통한 데이터의 자동화, 통합 및 재사용을 기계에 의해 사용될 수 있는 방식으로 정의 및 링크된 웹 상에 데이터를 갖는 아이디어이다. 또한, http://www.w3.org/2001/sw/를 참조하라.

SAP(Session Announcement Protocol). 멀티캐스트 멀티미디어 회의 및 다른 멀티캐스트 세션의 광고를 지원하고, 전망 참가자에 관련 세션 셋업 정보를 통신하기 위하여, 분배 세션 디렉토리가 사용될 수도 있다. 이러한 세션 디렉토리의 일례는 세션의 설명을 포함하는 패킷을 주기적으로 멀티캐스트하고 이들 광고는 다른 세션 디렉토리에 의해 수신되어, 잠재적인 원격 참가자는 세션 설명을 이용하여 세션에 참가하는데 필요한 도구를 개시할 수 있다.

가장 간단한 형태에서, 이것은 특정 세션을 기술하는 세션 알림 패킷을 주기적으로 멀티캐스팅하는 것을 포함하고 있다. SAP를 수신하기 위하여, 수신기는 잘알려진 멀티캐시트 어드레스 및 포트를 간단하게 들을 수 있다. 세션들은 세션 설명 프로토콜(ftp://ftp.isi.edu/in-notes/rfc2327.txt)를 이용하여 기술된다. 만일 수신기가 SDP 메시지를 간단하게 디코딩하는 세션 알림 패킷을 수신한다면, 사용자에게 세션 정보를 표시할 수 있다. 동일 세션 설명 메시지의 반복간의 간격은 (특정 범위에 있는 각 송신기가 동일 범위내에 있는 다른 송신기를 들을 수 있다)알려지는 세션의 수에 따라 좌우되어, 특정 범위의 세션 알림에 사용되는 대역폭은 대략 일정하게 유지된다. 만일 수신기가 설정된 시간동안 들을 수 있으며 세션 알림은 들을 수 없다면, 수신기는 세션이 삭제되어 있으며 더 이상 존재하지 않는다고 결론을 내릴 수 있다. 이 세트 주기는, 송신기가 종종 어떻게 송신했었는지에 대한 수신기의 추정치에 기초한다.

일반적으로, http://www.faqs.org/rfcs/rfc2974.html, http://www.video.ja.net/mice/archive/sdr_docs/node1.html, ftp://ftp.isi.edu/in-notes/rfc2327.txt를 참조하라.

SMTP(Simple Mail Transfer Protocol). 메일을 신뢰성 있으면서도 효율적으로 전송하도록 설계된 프로토콜. SMTP는 특정 전송 서브시스템에 독립적이며 신뢰성 있는 명령 데이터 스트림 채널만을 요구한다. SMTP의 중요한 특징은 전송 환경에 따라 메일을 릴레이(relay)하는 성능이다. http://www.ietf.org/rfc/rfc0821.txt를 참조하라.

스킨(Skins). 퍼-에이전트 베이시스(per-Agent basis)에 대한 사용자의 체험을 커스텀하거나 시맨틱 도메인 명칭/경로 또는 온톨로지 및 다른 사고에 대해, 전체 레이아웃(에이전트와는 독립적인), 오브젝트(정보 오브젝트 타입에 기초함), 컨텍스트(컨텍스트 템플레이트에 기초함), 블렌더(블렌더인 에이전트의 경우)의 프리젠테이션을 커스텀화하는데 사용되는 프리젠테이션 템플레이트. 각 에이전트는 현재의 결과의 온톨로지(온톨로지 스킨)을 가리키는 오브젝트 타입(오브젝트 스킨 ), 스타일, 컬러, 그래픽, 필터, 변형, 효과, 애니메이션 등, 현재의 결과(컨텍스트 스킨)의 컨텍스트 템플레이트를 가리키는 스타일 및 블렌더(즉, 블렉터 스킨)으로부터 어떻게 결과를 보고 네비게이트하는지를 가리키는 스타일의 표현을 포함하는, 각 결과가 표시되는 방식으로, 예를 들면, 이들 결과들이 동영상화될 것인지의 정보 오브젝트(레이아웃 스킨)을 나타내는 XML 결과의 레이아웃을 커스텀화하는 파라미터들의 XML 메타데이터 표현을 차례로 가지게 되는 스킨을 포함할 것이다.

Smart Lens ^TM . 사용자들이 스마트 에이전트 또는 오브젝트를 다른 오브젝트 또는 에이전트가 볼 수 있는 컨텍스트로서 선택할 수 있게 하는 본 발명의 독점적인 특징의 상표명. 렌즈는 컨텍스트를 불러왔는지를 예측한 것을 사용자에게 표시하여 주는 메타데이터, 링크 및 결과 프리뷰를 표시한다. 필수적으로, 스마트 렌즈는 "잠재적인 질의(potential query)"의 결과를 표시한다. 스마트 렌즈는 사용자로 하여금 실제적으로 질의를 불러오지 않고도(그들의 생산성을 증가함으로써) 컨텍스트 결과를 스마트하게 프리뷰할 수 있게 한다. 또한, 스마트 렌즈는 관점(pivots), 템플레이트 및 프리뷰 윈도우를 이용하여 컨텍스트와 일치하는 뷰(view)를 표시할 수 있으며, 이로써 사용자가 질의를 불러오기 전에 상이한 방식으로 컨텍스트를 분석할 수 있게 한다.

Smart Virtual Web ^TM . 사용자가 그들이 제어하고 커스텀화할 수 있는, 다이나믹, 버추얼, "on-the-fly", 사용자 제어의 "Web"을 브라우징할 수 있도록 하기 위하여 시맨틱, 컨텍스트-감도, 시간-감도 및 다이너미즘을 통합하는 본 발명의 특 성에 대한 상표명. 이는 오늘날의 웹과 개념적인 시맨틱 웹과 대조적인 것이며, 이들 둘다 수동적으로 저작된 네트워크를 사용하며 사용자들은 네트워크상에서 정보의 저작자에 따라 좌우된다.

SQL(Structuered Query Language). "ess-que-el"로 발음됨. SQL은 데이터베이스와 통신하는데 사용된다. ANSI(American National Standards Institute)에 따르면, 관계적인 데이터베이스 관리 시스템의 표준 언어이다. SQL 명령문은 데이터베이스상에서의 데이터 업데이트 또는 데이터베이스로부터의 데이터 검색과 같은 태스크를 수행하는데 사용된다. SQL을 사용하는 일부 공통적인 관계적인 데이터베이스 관리 시스템은 오라클(Oracle), 씨베이스(Sybase), 마이크로소프트 SQL 서버, 액세스, 잉그르(Ingres) 등이 있다. 대부분의 데이터베이스 시스템은 SQL을 사용한다고 할지라도, 이들 대부분은 또한 시스템에 통상적으로 사용되는 그들 자신의 추가적인 특성 확장을 갖는다. 그러나, "선택(Select)", "삽입(Insert)", "업데이트(Update)", "삭제(Delete)", "생성(Create)" 및 "드롭(Drop)"과 같은 표준 SQL 명령은 사람이 데이터베이스를 가지고 작업할 필요가 있는 거의 모든 것을 수행하는데 사용될 수 있다.

SQL은 관계 데이터베이스를 가지고 작업한다. 관계 데이터베이스는 테이블(관계)에 데이터를 저장한다. 데이터베이스는 테이블의 집합이다. 테이블은 기록의 리스트로 이루어져 있으며, 테이블내의 각 기록은 바람직하기로는 동일 구조를 포함하는 것이며, 각기 고정된 수의 소정 타입의 "필드(fields)"를 갖는다.

일반적으로, http://www.sqlcourse.com/intro.html 및 http://www.dcs.napier.ac.uk/~andrew/sql/0/w.htm를 참조하라.

SVG(Scalable Vector Graphics). 2차원 그래픽을 XML로 기술한 언어. SVG는 3가지 타입의 그래픽 오브젝트 즉, 벡터 그래픽 형상(예를 들면, 직선 및 곡선을 포함하는 경로), 이미지 및 문자를 허용한다. 그래픽 오브젝트는 이전에 만들어진 오브젝트로 그룹화, 스타일화, 변형 및 합성될 수 있다. 문자는 SVG 그래픽의 검색기능 및 액세스 기능을 향상시키는 어플리케이션에 적합한 XML 명칭공간에 있을 수 있다. 이 특징 세트는 네스트된 변형(nested transformations), 클리핑 경로, 알파 마스크, 필터 효과, 템플레이트 오브젝트 및 확장 가능성을 포함한다. SVG는 도면은 다이나믹하면서 상호작용될 수 있다. 전 XML DOM을 포함는, SVG용 DOM(Document Object Model)은 스크립팅을 통해 올바르며 효과적인 벡터 그래픽 애니메이션을 허용한다. 온마우스오버(onmouseover) 및 온클릭과 같은 풍부한 세트의 이벤트 핸들러는 임의의 SVG 그래픽 오브젝트에 할당될 수 있다. 다른 웹 표준의 호환성 및 레버리지(leveraging)로 인해, 스크립팅과 같은 특징은 동일 웹 페이지내에서 동시에 상이한 명칭공간으로부터 SVG 엘리먼트 및 다른 XML 엘리먼트에 대해 수행될 수 있다. http://www.w3.org/Graphics/SVG/Overview.htm8를 참조하라.

텍사노미(Taxonomy). 분할이 그룹 또는 카테고리로 명령되는 조직화된 구조.

시간-감도(Time-Sensitivity). 정보가 때에 맞추어 가장 컨텍스트는 있을 때에 기초하여 정보를 전송하고 제공하는 정보 매체의 특징. 예를 들면, 신선도 (freshness)는 시간-감도를 지칭하는 속성이다. 또한, (정의에 의해 시간-감도가 되는)다가올 이벤트의 전송 및 제공과 이벤트의 시간-임계가 표시되는 방식은 시간-감도 매체의 특성이다.

오늘날의 웹(Today's Web). 이것은, 우리가 현재 알고 있는 월드 와이드 웹을 의미한다. 오늘날의 웹은 하이퍼텍스트 서버(HTTP 서버)의 영역이며, 이는 문자, 그래픽, 사운드 파일 등들이 함께 링크될 수 있게 하는 서버들이다. 하이퍼텍스트는 간단하게 제공된 정보의 비선형 방식이다. 저작자, 또는 편집가 또는 발행자가 제시한 순으로 사물에 관해 읽거나 배운다는 것 보다, 하이퍼텍스트의 독자는 그들 자신의 경로를 따르고, 그들 자신의 명령을 생성하거나 재료의 의미를 파악할 수 있다. 이는 정보간의 "링크(links)"를 생성함으로써 달성된다. 이들 링크는, 사용자가 논의되는 특정 토픽에 관한 추가 정보(링크를 더 가질 수 있으며, 각 독자를 상이한 방향으로 이끌 수 있는)로 "점프(jump)"할 수 있도록 제공된다. 하이퍼텍스트 매체는 제공된 정보에 멀티미디어 방법을 제공하는 그래픽, 사운드, 비디오를 결합시킬 수 있으며, 또한 하이퍼미디어로 불린다. 일반적으로 http://www.w3.org/History.html 및 http://www.umassd.edu/Public/People/KAmaral/Thesis/hypertext.html를 참조하라.

TTL(Multicast Time to Live). 멀티캐스트 루우팅 프로토콜은 전송 호스트로부터 소정 멀티캐스트 패킷이 얼마나 "멀리(far)" 진행될 수 있는지를 결정하는 데이터그램(datagrams)이라는 필드를 사용한다. 멀티캐스트 데이터그램의 디폴트 TTL은 1이고, 이는 멀티캐스트 패킷들이 로컬 네트워크상의 다른 호스트에만 가게 될 것이다. setsockopt(2) 호출은 TTL을 변화시키는데 사용될 수도 있다. TTL의 값이 증가함에 따라, 로우터(router)는 멀티캐스트 패킷을 진행하게 하는 홉(hops)의 수를 확장할 것이다. 의미있는 범위 제어를 제공하기 위하여, 멀티캐스트 로우터는 통상적으로 TTL 분야에 기초한 진행시 다음 "thresholds"를 강화시킨다.

·동일 호스트에 제한된 0

·동일 서브넷에 제한된 1

·동일 사이트에 제한된 32

·동일 영역에 제한된 64

·동일 컨티넌트(continent)에 제한된 128

·비제한된 255

http://www.isl.org/projects/eies/mbone/mbone27.htm를 참조하라.

사용자 상태(User State). 이것은 사용자에 의해 생성되거나, 클라이언트 또는 서버상에서 사용자의 기호, 즐겨찾기 또는 다른 사람의 정보를 캐쉬(cache)하는데 필요한 모드 상태를 의미한다. 클라이언트측 사용자 상태는 인증 자격 정보, 사용자의 에이전트 리스트(그리고 에이전트에 대한 SQML 질의를 포함하는 모든 메타데이터), 홈 에이전트, 구성 옵션, 스킨과 같은 기호 등을 포함한다. 필수적으로, 클라이언트측 사용자 상태는 사용자의 시맨틱 환경의 지속(persisted) 형태이다. 서버측 사용자 상태는 사용자의 즐겨찾기 에이전트, 기입된 에이전트, 디폴트 에이전트, 서버상의 정보 오브젝트에 대한 시맨틱 링크(예를 들면, "즐겨찾기" 링크) 등과 같은 정보를 포함한다. 서버측 사용자 상태는 서버의 경우에 옵션이지만 원하는 경우 지원한다. 서버들은 (서버측 에이전트가 없이도)사용자 로그온 및 "사람들(people)" 오브젝트 타입을 지원하는 것이 바람직한데, 이는 이들이 즐겨찾기, 추천과 같은 특징과 "Newsmarkers", "Experts", "Recommendations", "Favorites" 및 "Classics"와 같은 컨텍스트 템플레이트를 필요로 하기 때문이다.

Vertual Information Object Type ^TM . 별개의 오브젝트 타입으로 맵핑하지 않지만, 아직 사용자에게 시맨틱하게 관심이 있는 오브젝트 타입의 상표명.

Vertual Parameter ^TM . 시맨틱 질의 프로세서에 의해 실행시간에서 다이나믹하게 해석되는 변수, 파라미터, 인자(arguments) 또는 명칭에 대한 상표명. 이는 에이전시 매니저로 하여금 가상 명칭을 참조하여 질의가 불려질 때 실제로 컨텍스트 있는 용어로 변경되는 명칭을 갖는 에이전트를 저장할 수 있게 한다.

Web of Trust. 시맨틱 웹의 사용자들이 단정 및 명령문을 유효하게 하는데 사용될 수 있는 인증의 체인을 참조하는 시맨틱 웹 검색 공동체의 멤버에 의해 만들어진 용어. 수학 및 암호 해독법을 이용한 작업에 기초하여, 디지털 서명은 임의의 사람이 문서 또는 명령문을 기입(또는 동의)한 증거를 제공한다. 사용자들은 그들의 RDF 명령문 모두를 디지털 서명하는 것이 바람직하다. 이 방식을 통해, 사용자들은 이들이 기입했다는 것을 확실히 할 수 있다(또는 그들의 인증을 적어도 입증할 수 있음). 사용자들은 프로그램의 서명이 신뢰성이 있다고 간단하게 말한다. 각각 그들의 신뢰(또는 편집증)의 레벨을 설정할 수 있고, 컴퓨터는 얼마나 많이 신뢰할 수 있는지를 결정할 수 있다.

일례로서, 신뢰의 웹을 이용하여, 사용자는 그가 그의 베스트 프렌드인 로버트(Robert)를 신뢰하는 컴퓨터를 말할 수 있다. 로버트는 네트(Net)상에서 다소 인기있는 사내이며 다수의 사람들이 상당히 신뢰한다. 그가 신뢰하는 모든 사람들은 다른 세트의 사람들을 차례로 신뢰한다. 신뢰의 측정들 각각은 정도가 있다(로버트는 상당 부분 웬디(Wendy)를 신뢰할 수 있지만 셀리(Sally)는 거의 그렇지 않다). 신뢰와 더불어, 불신의 레벨이 하나의 요소로 포함될 수 있다. 만일 사용자들의 컴퓨터가 명백하게 신뢰하는 사람이 없지만, 어느 누구도 그것이 거짓이라고 말하지 않는 문서를 발견하는 경우, 아마도 많은 사람들이 말했던 것 보다 적은 정보가 거짓이라고 믿을 것이다. 컴퓨터는 신뢰할 수 있는 정보의 조각을 결정할 때 이들 모든 팩터(factor)를 고려한다. 바람직하기로는, 컴퓨터는 이들 모든 정보를 간단한 디스플레이(thumbs-up/thumbs-down) 또는 보다 복잡한 설명(포함된 모든 다양한 신뢰 팩터의 설명)에 결합시킨다. http://blogspace.com/rdf/SwartzHendler를 참조하라.

WS-I(Web Services-Interoperability). 플랫폼, 오퍼레이팅 시스템 및 프로그래밍 언어를 거쳐 웹 서비스 상호작용을 촉진하도록 특권화된 오픈 산업 기구. 이 기구는 산업 및 표준 기구를 거쳐 작업하여, 웹 서비스 해결책을 개발하기 위한 가이던스, 최적의 실시예 및 리소스를 제공함으로써 사용자의 필요성에 응답한다. http://www.ws-i.org를 참조하라.

WS-Security(Web Services Security). 메시지 통합, 메시지 기밀성 및 단일 메시지 인증를 통해 보호의 품질을 제공하는 SOAP 메시지에 대한 향상. 이들 메카 니즘은 다량의 보안 모델 및 암호 기술을 수용하는데 사용될 수 있다. WS-보안은 또한 메시지와 보안 표시를 관련시키는 범용 메카니즘을 제공한다. 특정 타입이 없는 보안 표시는 WS-보안에 의해 요구된다. 이것은 확장가능하게 설계된다(예를 들면, 다수의 보안 표시 포맷을 지원한다). 예를 들면, 클라이언트는 식별을 위한 증명과 특정 비지니스 자격의 증명을 제공할 것이다. 부가적으로, WS-보안은 2진수 보안 표시를 어떻게 인코딩할지를 설명한다. 구체적으로, 상세는 X.509 증명 및 커버로스(Kerberos) 티켓을 어떻게 인코딩할지는 물론 불투명한 암호키를 어떻게 포함할지를 설명한다. 이것은 또한, 메시지와 포함되는 신용의 특성을 추가로 기술하는데 사용될 수 있는 확장성 메카니즘을 포함한다. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-security.asp를 참조하라.

XML(Extensible Markup Language). 웹 상에서 구조화된 문서 및 데이터에 대한 전반적인 포맷. 구조화된 데이터는 스프레드시트, 어드레스 북, 구성 파라미터, 금융 거래, 및 기술적 드로윙과 같은 것을 포함한다. XML은 데이터를 구성할 수 있게 하는 문자 포맷을 설계하기 위한 한 세트의 룰(가이드라인 또는 규정으로서 생각할 수도 있다)이다. XML은 프로그래밍 언어가 아니며, 사람들은 이것을 사용하거나 배우는 프로그래머가 될 수 없다. XML은 컴퓨터가 데이터를 생성하고 데이터를 읽고, 데이터 구조를 명확하는 것을 보장하는 것을 용이하게 한다. XML은 언어 설계에 있어서 공통된 위험이 없다, 즉 이것은 확장가능한, 플랫폼-독립성이 있으며, 이는 국제화 및 지방화를 지원한다. XML은 전체적으로 단일코드-컴플라이 언트(Unicode-compliant)이다. http://www.w3.org/XML/1999/XML-in-10-points를 참조하라.

XML 웹 서비스(XML Web Service)(또는 "Web Service"로서 알려져 있음). 사용자에게 다이나믹한 컨텍스트 구동의 정보를 제공할시 포함되는 상이한 소프트웨어 어플리케이션 중에서 통신의 표준 수단을 제공하는 서비스. 보다 구체적인 정의는 다음을 포함한다:

1. 인테페이스 및 바인딩이 XML 인공물에 의해 정의, 기술 및 발견될 수 있는 URI에 의해 식별된 소프트웨어 어플리케이션. 인터넷에 기초한 프로토콜을 통해 XML 기초의 메시지를 이용하여 다른 소프트웨어 어플리케이션과 직접적인 상호작용을 지원한다.

2. 인터넷 표준을 이용하여 다른 웹 서비스와 통합될 수 있는 서비스로서 전송된 어플리케이션. 이는 사용을 원하는 클라이언트에게 정보를 프로그램적으로 리턴시키는 URL-어드레스 리소스이다. 사용된 주요 통신 프로토콜은 SOAP(Simple Object Access Protocol)이며, 이것은 대부분의 경우 HTTP 이상의 XML(XML over HTTP) 이다.

3. 표준 인터넷 프로토콜을 이용하여 액세스 가능한 프로그램가능한 어플리케이션 로직. 웹 서비스는 구성 요소에 기초한 개발의 특징과 웹을 결합시킨다. 구성 요소와 같이, 웹 서비스는 서비스가 어떻게 수행되는지에 관한 걱정없이 재사용될 수 있는 블랙-박스(black-box) 기능을 나타낸다. 현재의 구성 요소 기술과는 달리, 웹 서비스는 DCOM, RMI 또는 IIOP와 같은 오브젝트-모델-특정 프로토콜을 통 해 액세스되지 않는다. 그 대신에, 웹 서비스는 보편적인 웹 프로토콜(ex: HTTP) 및 데이터 포맷(ex: XML)을 통해 액세스된다.

http://www.xmlwebservices.cc/, http://www.perfectxml.com/WebSvc1.asp 및 http://www.w3.org/2002/ws/arch/2/06/wd-wsa-reqs-20020605.html를 참조하라.

XQuery. 모든 종류의 데이터를 통해 지능적으로 질의를 표현하기 위해 XML의 구조를 사용하며, 미들웨어(middleware)를 통해 XML로서 보여지거나 XML로 저장되는 질의 언어. http://www.w3.org/TR/xquery/ 및 http://www-106.ibm.com/developerworks/xml/library/x-xquery.html를 참조하라.

XPath. XSL 변환(http://www.w3.org/TR/XSLT) 및 XPointer(http://www.w3.org/TR/xpath#XPTR)간에 공유된 기능에 대해 공통 문법체계(syntax) 및 시맨틱을 제공하기 위한 노력의 결과. XPath의 1차적인 목적은 XML[XML] 문서의 일부분을 어드레스하는 것이다. 이 1차적인 목적의 지원에서, 또한 스트링, 번호, 불린(booleans)의 조정을 위한 기본적인 편의를 제공한다. XPath는 컴팩트한, 비-XML 문법체계를 이용하여 URI 및 XML 속성값내에 XPath의 이용을 손쉽게 한다. XPath는 표면 문법체계라기 보다는, XML 문서의 요약, 논리적인 구조에 따라 작동한다. XPath는 XML 문서의 계층적인 구조를 통해 네이비게이팅하기 위한 URL로서 경로 표시의 이용으로부터 그 명칭을 얻었다.

어드레싱을 위한 이용에 부가하여, XPath는 또한 매칭(노드가 패턴과 일치하는지의 여부를 테스팅)에 사용될 수 있는 자연적인 서브세트(natural subset)를 갖도록 설계되고, 이 XPath의 이용은 XSLT에 기술되어 있다. XPath는 XML 문서를 노 드들의 트리로 모델링한다. 이들은 엘리먼트 노드, 속성 노드 및 문자 노드를 포함하는 상이한 타입의 노드들이다. XPath는 각 타입의 노드에 대해 스티링값을 계산하는 방식을 정의한다. 일부 타입의 노드들은 또한 명칭을 가지고 있다. XPath는 XML 명칭스페이스(http://www.w3.org/TR/xpath#XMLNAMES)를 완벽하게 지원한다. 따라서, 노드의 명칭은 로컬 부분과 가능성있는 널(null) 명칭스페이스 URI로 이루어진 한 쌍으로서 모델링되고, 이것은 (http://www.w3.org/TR/xpath#dt-expanded-name)라고 명명된다. http://www.w3.org/TR/xpath#XPTR를 참조하라.

XSL. 포맷팅을 특정화하기 위한 XML 단어를 포함하는 XML용 스타일 시트 언어. http://www.w3.org/TR/xslt11/를 참조하라.

XSLT. 문서가 포맷팅된 단어를 사용하는 다른 XML 문서로 어떻게 변환되는지를 설명하는 XSL에 의해 사용됨. http://www.w3.org/TR/xslt11/를 참조하라.

B. 개요

1. 발명의 배경

정보 액세스에 대한 홀리 그레일(Holy Grail)이 자연어 검색 기능의 규정인 것이라는 오해가 있다. 종래의 정보 액세스의 기술은 정보 검색을 최적화하기 위해 정보의 검색 또는 억세싱하기 위한 인터페이스를 개선하는데 주로 촛점이 맞추어졌었다. 정보에 대한 자연어 인터페이스는 사용자의 정보 액세스 문제점들을 완벽하게 해결하고 사용자가 정보를 찾는데 있어서의 장애물을 제거하게 되는 가정이 널리 차지하고 있었다.

그러나, 실제로, 분석의 많은 축(axes)은 사람들이 실세계에서 지식을 어떻 게 취득하는지를 포함하고 있다. 일례는 컨텍스트이다. 단지 임의의 장소 및 시간에 그들이 있는 곳 때문에 사람들이 알고 있는 많은 것들이 있다. 만일 그 시간에 그 장소에 그들이 없다면, 그들은 사실상 안다는 것을 알지 못하거나, 실제로 알 수 없을 것이다. 자연어를 가지고 현재 알고 있는 것을 검색하는 기능을 갖는다면, 특정 시간 및 장소에 관련된 지식을 노출할 때 지원하지 못한다. 원하는 정보를 검색하기 위한 정확한 질의를 형성하는 간단한 자연적인 파라미터가 없다.

사람들이 그가 알려고 하는 것이 사실 이후까지 가치를 가지고 있는지를 질의할 수 없다는 것은 수수께끼이다. 바꾸어 말하자면, 그들이 알지못하는 것을 알지 못하는 것, 또는 그들이 알기를 원하는 것을 알지 못할 수도 있다는 것을 알지 못하는 것을 질의할 수 없다. 본 발명의 컨텍스트-감도(context-sensitivity), 시간-감도(time-sensitivity), 디스커버리(discovery), 다이나믹 링킹, 사용자-제어 브라우징, 사용자의 "Semantic Environment", 다양한 프리젠테이션, 컨텍스트 스킨, 컨텍스트 속성, 컨텍스트 팔레트(컨텍스트 템플레이트에 기초하여 연관된 컨텍스트 및 시간 감도 정보를 불러오게되는) 및 기타 양상들은, 기존 정보 시스템의 이러한 기본적인 결점을 인식하고 정정한다.

예를 들어, 사람들은 특정 파티에 참석하고 특정 사람들과 대화하기 때문에 그들의 서재에 다수의 CD(이로써 음악적 "지식"을 더 풍부하게 함)를 구비할 수 있다. 이러한 파티에서의 사람들은 상기 CD들을 사람들에게 언급함으로써, 사람들의 음악적 지식을 증가시켜 준다. 다른 예를 들어, 어떠한 사람이 비행기 옆 좌석에 우연히 앉게 된 전혀 알지 못하는 낯선 사람으로부터의 추천에 기초하여 책(읽는다 면, 그 책의 특정 주제에 대한 그 사람의 지식을 증가시켜 줌)을 구입할 수 있다. 현실에서, 사람들은 그들이 읽고 찾은 것에 기초하는 것 뿐만 아니라, 그들이 교류하고 그 판단을 신뢰하며 유지하는 친구들에 기초하여 지식을 취득한다. "지식 환경"은 지식 보급 및 취득을 위해 보다 결정적인 것이 아니라면 검색용 모델(디지털 또는 아날로그) 만큼 결정적인 것이다.

본 발명은 모든 현실의 지식-취득 시나리오를 가상적으로 디지털 세계에 반영한다. 그 결과물인 "Information Nervous System^TM"이 대부분의 작업을 행하는 매체이지만, 매우 명확하게 아날로그(현실) 세계에 맵핑되는 것은 시나리오이다. 지식이 보급되고 취득되는 다양한 방식을 인식하기 위한 시맨틱 웹 뿐만 아니라 오늘날의 웹의 자연어 검색 기술 등의 노력이 있었으나 이러한 것은 불가능하여 결국 무효가 되었다. 본 발명은 정보 전달에 사용되는 실제 기술과는 독립적으로 인간이 항상 지식을 취득하는 다양한 방식에 대하여 설명한다.

예를 들어, 컨텍스트 및 시간은 항상 존재하여 왔다. 마찬가지로, 정보를 다이나믹하게 사용자 제어와 함께 링크할 필요와 발견의 개념이 항상 존재하여 왔다. 본 명세서에 개시된 "classics", "history", "timelines", "upcoming events", "headlines"를 포함하는 특정 컨텍스트 템플레이트가 비록 다른 매체에서라도 항상 존재하여 왔다. 이들 템플레이트는 인터넷, 오늘날의 웹, 이메일, e-학습 등의 생성 이전에 존재하였다. 그럼에도 불구하고, 본 발명 이전에는, 실제 정보 타입, 시맨틱 링크, 메타데이터 등에 대비되도록 실제 시나리오(예를 들어, 컨 텍스트 템플레이트, 컨텍스트-감도, 시간-감도, 다이나믹 링킹, 다양한 프리젠테이션, 컨텍스트 스킨, 컨텍스트 속성 등을 통해)를 맵핑하는 지식 전달의 모드, 프로토콜 및 프리젠테이션에 대하여 촛점을 맞추는 기능이 전자 매체에는 없다. 항상 새로운 정보 타입이 존재할 것이다. 그러나, 지식의 보급 및 취득 축은 항상 동일하게 유지되어 왔고 앞으로도 그럴 것이다. 본 발명은 이러한 현실을 포착한 것이다.

또한, 본 발명은 우연성(serendipity)을 통해 지식을 보급하는 기능을 제공한다. 우연성은 실제 지식 취득에 있어 큰 부분을 차지하는 것으로, 지식 전달의 제1-클래스 모드이다. 본 발명은 컨텍스트, 시간, 컨텍스트 템플레이트에 대한 지원에 의해 사용자가 정보를 우연성을 가지고(그럼에도 불구하고 지능적으로) 취득할 수 있게 한다.

"Web"과 같은 엄격하고 스태틱한 구조를 채택하는 정보 모델 또는 매체는 인증된 "network" 또는 "Web"의 존재를 가정하기 때문에 고장이 발생하고 지식 정보의 다양한 축에 대하여 설명하지 못한다. 이러한 정보 모델은 사용자-중심이 아니고, 컨텍스트, 시간, 다이나믹성 및 템플레이트를 수용하지 못하며, 실제 지식 취득 및 보급 시나리오에 맵핑되지 않는다. 본 발명은, "Web" 등이 존재하지 않더라도, 심지어는 정보를 찾기 위해 자연어가 채용되지 않더라도, 정보 손실을 최소화하고 보유된 정보를 최대화한다. 이는, 정보 액세스용 기존 매체와는 달리, 본 발명의 바람직한 실시예가, 컨텍스트, 시간, 다이나믹성 및 템플레이트를 수용하는(최종-사용자 및 콘텐츠 제공자 양자 모두의 이익을 위함) 지식 보급 모델에 대하여 는 촛점을 맞추고, 스태틱 데이터 모델 또는 인간-기반 저작에 기초하는 정보 자원들의 액세스 인터페이스 또는 링킹(시맨틱 또는 논-시맨틱)의 특정에는 촛점을 맞추지 않기 때문이다. 많은 시나리오에서, "Web"(시맨틱 또는 논-시맨틱)이 네비게이션의 수단으로서 필요하지만, 지식 보급 및 취득의 수단으로서는 충분하지 못하다. 본 발명의 정보 신경 시스템은 본 명세서에 개시되는 "지식 축(knowledge axes)"을 수용하고, 이들을 지능적이고도 일관하게 통합하여, 지식의 보급 및 취득을 촉진하고 지식의 전달에 포함되는 모든 부분들에 도움이 되도록 한다.

2. 값 제안(VALUE PROPOSITIONS)

오늘날, 그것이 기업용이든, 고객용이든 또는 일반인용이든, 지식은 수작업에 의해 디지털 체제의 정보구조로 "하드-코드(hard-coded)" 되어야 한다. 지식에 만들어져 적절하게 분배되지 않으면, 아무도 그 존재를 알지 못하거나, 다른 자원에 어떻게 관련되는가를 알지 못하기도 하고, 또는 실시간에 적절한 방법으로 그에 따라 행동하는 방법을 알지 못한다. 이는 주로 오늘날의 웹이 지식을 위한 플랫폼으로 설계되지 않았기 때문이다. 그것은 프리젠테이션을 위한 플랫폼으로 설계되었으며, 벙어리와 다름없고, 정적(static)이며, 반작용적이 되도록 의도적으로 만들어 졌다. 오늘날 지식작업자들 - 문맥과 의미를 부가함으로서 정보를 찾아 사용하는 사람들-은 지식 저작자들의 처분에 달렸다.

지식 상호작용의 중요한 양상으로는 지식-작업자들(knowledge-workers)이 지식 공간을 통해 그들의 경로를, 매우 직관적인 방식으로, 그들이 결정을 내리고 지식에 대처하기 원하는 속도로, 네비게이트 할 수 있게 하는 것이다. 환언하면, 지 식-작업자들은 e-학습 아일랜드(e-learning island)에 대하여, 그들 조직에서의 문서나 고객 피드백을 포함하는 e-메일이나, 매체 파일이나, 앞으로 다가올 화상-회의(video-conference)나, 최근에 행한 회의나, 뉴스그룹에 저장된 정보 또는 관련 책들과는 개별적인 것으로 "생각(think)"할 필요가 없다. 바람직한 상황으로는 정보 "타입(type)" 및 "소스(source)"를 분류하고, 시맨틱 방식에서 모든 아일랜드들을 초월하는 "일체로된 지식 경험(seamless knowledge experience)"을 생성하는 것이다.

지식 경험의 생성에 있어, 콘텐츠-제공자, 파트너, 공급자, 고객 및 인적 경계들을 가로지르는 지식 자산을 통합할 수 있는 것이 또한 바람직하다. 예를 들어, 기업 시나리오에서, 경쟁력을 유지하기 위해 필요한 모든 지식을 구비하는 단일 조직이란 없다. 지식은 산업 보고서, 자문 회사 및 투자 은행으로부터의 연구 문서, 및 Reuters^TM 및 Bloomberg^TM 등의 매체 회사에 저장된다. 이러한 것은 모두 "지식(knowledge)"을 구성한다. e-학습 저장소(repository)를 전개하여 한번이나 또는 정기적으로 사용자를 트래이닝시키는 것은 충분하지 못하다. 사용자들은 다양한 소스로부터, 해당 장소에서, 그들의 현재 업무에 관련된 지능적인 컨텍스트인 지식을 항상 액세스하여야 한다.

이러한 모든 것은 지능레이어(a layer of intelligence) 및 오늘날 사용되지 않는 사전-학습(pro-activity)을 요구한다. 예를 들어, 오늘날 기업들은 그들의 직원들에게 정보를 보급하는 방식으로서 인트라넷 및 인터넷 등의 정보 포탈 (information portals)을 이용한다. 그러나, 이는 프리젠테이션-레벨 통합만을 제공하기 때문에 충분하지 못하다. 이는, 당신을 위해 당신의 정보를 관리하고, 당신이 허공에서 신규 정보를 찾는 것을 도와주며, 동료들과 정보를 포착하여 공유하는 것을 돕는 것 등을 행하는 에이전트를 두는 대신에, 정보가 업데이트된 상태를 유지하기 위해 정기 간행물 등을 구독하는 것과 유사한 것이다.

원하는 레벨의 지식 상호작용을 달성하려면, 배경, 추리, 학습, 추론으로 작업하고, 프로필에 기초하여 사용자들을 매칭하고, 새로운 지식을 포착하고 자동적으로 새로운 지식을 추론하고, 지식 경험의 일체로된 부분이 되도록 외부 소스들로부터 지식을 연합시키는 에이전트를 필요로 한다. 이는 또한 지식 자산들이 모두 프리젠테이션-레벨 통합 및 문서 검색에 대한 기초를 단순히 제공하기 보다는 총체적 유형의 의미를 갖도록 하는 지식 자산의 시맨틱 통합(integration)을 요구한다. 구현된 프레임워크(implementation framework) 및 그 결과인 매체는, 컨텍스트-감도 및 시간-감도 정보가 "적기에 공급되고(honored)" 지식-작업자들이 보다 생산성있게 보다 많은 것을 빠르게 할 수 있도록, 실시간으로 민첩한 발견 및 추천 서비스를 제공하여야 한다. 마지막으로, 시스템은 기존 정보 소스를 가지고 플러그-앤-플레이 방식으로 동작하여야 하고, 알려진 지식 자산을 이음매없이 자동적으로 분류하여 통합하여야 하며, 지식 자체에 지식을 구현하여야 하며, 이에 의해 지식 자산에 또 다른 "차원(dimension)"을부가하여야 한다.

본 발명은 오늘날의 웹(또는 기타 다른 레이어의 프리젠테이션)과 공존하는 지능적이고, 사전학습적이며, 실시간 지식 플랫폼으로 설계된다. 본 발명을 수용 하여 사용하면, 지식작성이 지능적이고, 다이나믹하고, 자동적이며 생각의 속도로 이루어질 것이기 때문에, 지식-작업자들은 그들의 지식 경험을 관리할 수 있게 될 것이다.

3. TODAY'S "INFORMATION" WEB 대 본 발명의 정보 신경 시스템

오늘날의 웹환경에서, 부여된 정보의 시맨틱은 HTML로 구조화된 데이터의 대화시 서버에서 손실되어, 사용자가 상호작용할 기회를 갖기 이전에 오브젝트로부터 "지식"이 사라진다. 또한, 오늘날의 웹은 정보가 네비게이트될 것인지 또는 소비될 것인지를 그 저작자가 어떻게 "신뢰하느냐(believes)"에 기초하여 서버 상에서 저작되고 "하드-코드된다(hard-coded)". 사용자들은 그들에게 부여된 대로만 정보를 소비한다.

본 발명은 Today's HTML-기반 웹 환경이 지원할 수 없는 지능 레이어 및 최적화 레이어를 부가한다. 본 발명은 오브젝트의 시맨틱이 서버와 클라이언트 사이에서 예약되는 덤(dumb) 웹 페이지들 보다는 오히려 스마트 지식 오브젝트의 XML-기반 다이나믹 웹 페이지들을 제공하고, 이에 의해 사용자들에게 그들의 지식 경험에 대하여 훨씬 많은 파워와 제어를 제공한다. 또한, 본 발명의 웹에 의하면, 지식-작업자들은 "다이나믹 링킹" 및 "사용자-제어 브라우징"을 통해 그들 자신의 지식 경험을 인터렉티브하게 저작할 것이기 때문에 그들 자신의 용어에 대한 정보를 소비하고 대처할 수 있다.

본 발명의 정보 에이전트(시맨틱 브라우저)는, 오늘날의 웹과 공존하고, 인터넷 뿐만 아니라 개인 및 공중 인트라넷 모든 면을 통합하고 증가시키도록 설계된 다. 오늘날의 웹과 본 발명의 정보 신경 시스템의 기술 플랫폼 스택(stacks)이 도 6에 요약된다. 도 6을 참조하면, 오늘날의 웹에 대한 스택은 최하 레이어에, 데이터베이스에 저장된 데이터 등의 정보를 포함하는 Structurede Information Sources와, 문서, e-메일 메시지 등의 정보를 포함하는 Unstructured Information Sources를 구비한다. 이들 양 레이어에서의 정보는 명백하게 조작된다. Information Indexing Layer에는 시맨틱이 사용되지 않고; 오히려, 키워드에 기초하는 검색 엔진들이 사용된다. 로직 계층(Logic Layer)은 주로 검색용 프로그램가능성을 허용하는 데이터베이스, 규칙, 보기, 트리거 등을 포함한다. 어플리컨트 계층(Applicant Layer)는 사용자 입력에 기초하여 전자 비지니스(e-Business) 어플리케이션들을 구동하는 서버측 스크립트를 포함한다. 최상위 또는 프리젠테이션 계층(Presentation Layer)에서, 오늘날의 웹은 웹 플랫폼(브라우저 등)에 의해 포털을 통해 노출되는 프리젠테이션 정보(웹 페이지의 형태임)를 갖는다.

처리의 중첩 레이어들은 별도로 하고, 본 발명은 하위 정보 소스의 시맨틱을 예약하는 방식으로 최하위 레벨의 조작으로부터 정보를 고유하게 조작한다. 구조화된 정보 소스 레이어 및 구조화되지 않은 정보 소스 레이어 양쪽 모두에서, 시스템(10)은 그 정보에 관련된 메타데이터 및 시맨틱을 고려하여 정보를 균일하게 조작한다. 정보 인덱싱 레이어에서는, 정보 메타데이터 및 시맨틱들이 구조화되지 않은 것으로부터 추출된다. 시스템(10)은 오늘날의 웹에 존재하지 않는 이하의 3가지 부가적인 플랫폼 레이어를 부가한다: 구조화된 소스 및 구조화되지 않은 소스 양쪽 모두로부터의 정보가 시맨틱하게 인코드되는 지식 인덱식 및 분류화 레이어; 지식 오브젝트의 자체-정정 또는 치유(self-correction or healing) 시맨틱 네트워크의 유지보수를 가능하게 하는 연합(association)이 생성되는 지식 표현 레이어; 및 시맨틱 레이어에서 신규 접속 및 특성들이 추론되는 지식 온톨로지 및 추론 레이어. 논리 레이어에서는 시맨틱 레벨에서 프로그램가능성을 허용하는 지식-기반가 생성된다. 어플리케이션 레이어에서는, 지식-기반와 관련하여 서버측 스크립트가 사용된다. 이들 스크립트는 사용자 입력에 기초하여 지식 오브젝트를 다이나믹하게 생성하고, 검색, 통지 및 논리용 시맨틱 명령어를 포함할 수 있다. 이 레이어는 또한 시맨틱 사용자 입력의 조절을 최적화하는 스마트 에이전트를 포함할 수도 있다. 시스템(10)의 프리젠테이션 레이어는 최하층 레이어로부터 추적되는 시맨틱들을 예약한다. 이 레이어에서의 프리젠테이션은 클라이언트 컴퓨터 시스템 상에서 다이나믹하게 생성되고 완전히 최적화될 수 있다.

모든 기술 레이어에서 시맨틱의 유지보수, 통합 및 사용에 의해, 본 발명은 인간이 물리적으로나 가상적으로 또는, 달리 말하면 친숙한 "Context Templates"와 같이 상호작용하는 "것들(things)"에 직접 대응하는 대처가능한 "오브젝트"의 가상 웹을 생성한다. 문서의 덤 웹인 오늘날의 웹과는 달리, 본 발명은 특성 및 관계들을 갖는 대처가능한 오브젝트들의, 이벤트가 가상 웹의 다른 부분들에서의 변경을 다이나믹하게 초래할 수 있는 스마트한 가상 웹을 제공한다.

본 발명은 프로그램가능한 웹을 제공한다. 문서의 덤 웹인 오늘날의 웹과는 달리, 본 발명의 웹은 데이터베이스- 논리 및 규칙을 처리할 수 있고, 이벤트를 초기화할 수 있음 -와 유사하게 프로그램가능하다.

오늘날의 웹이 인간을 위해 인코드된 것이고, 따라서 주로 스태틱 정보의 프리젠테이션에 촛점을 둔 것인 한편, 본 발명의 가상 웹은 지식 전달 고리의 종단에서와 같이 궁극적으로 인간에게 부여됨에도 불구하고 주로 기계용으로 인코드된다. 본 발명은 지능적이고 학습적인 웹을 제공한다. 이는 본 발명의 가상 웹이 신규 접속들을 학습할 수 있고 시간이 지남에 따라 보다 스마트해진다는 것을 의미한다. 웹은 다이나믹하고, 가상이며 자체-저작하는 것이고, 이에 의해 오늘날의 웹이 제공할 수 없는 지능적이고 선행학습적인 시맨틱 접속을 이루는 것에 의해 지식-작업자에게 보다 큰 파워를 제공하며, 이에 의해 정보 손실을 감소시키고 궁극적으로는 제거한다.

본 발명의 웹은 자체-치유 웹이다. 문서 저작자(author)에 의해 수동으로 유지보수되어야 하는 오늘날의 웹과는 달리, 본 발명은 기계에 의해 자체-유지되는 웹을 제공한다. 이러한 특징은 웹이 네트워크에서의 단절을 자동적으로 고칠 것이기 때문에 파선을 교정한다.

마지막으로, 이하 보다 상세히 설명되듯이, 본 발명의 다양한 실시예들은 상술된 지식 취득의 축의 일부 또는 전부를 수용하므로, 오늘날의 웹 또는 개념상의 Semantic Web 등의 기존 시스템에 대하여 잠재적인 이점들을 제공한다.

C. 시스템 아키텍쳐 및 기술 고려사항(SYSTEM ARCHITECTURE AND TECHNOLOGY CONSIDERATION)

1. SYSTEM OVERVIEW

본 발명은 지식 검색, 관리 및 전달용 시스템 및 방법에 관한 것이다. 이러 한 시스템 및 방법은 이하 상표등록된 용어인 Information Nervous System^TM으로 불려진다. 도 7을 참조하면, 그 최상위 레벨에서 시스템(10)은, 인터넷 또는 인트라넷 등 통신 매체(40)를 통해 프리젠테이션 플랫폼(브라우저 등)을 조작하는 클라이언트(30)에게 컨텍스트-감도 및 시간-감도 시맨틱 정보 검색 서비스를 제공하도록 연동하는 여러 구성 요소들로 구성되는 서버(20)를 포함한다. 서버 구성 요소가 바람직하게는 KIS(Knowlege Integration Server; 50) 및 KBS(Knowledge Base Server; 80)를 포함하는데, 이는 물리적으로 통합되거나 분리될 수 있다. 시스템 내에서, 주어진 계층구조의 모든 오브젝트 또는 이벤트들은 상호 시맨틱하게 관련되는 액티브 에이전트(90)이고, 소정의 최적화된 테마 또는 "Skin"에 따라 클라이언트에게 프리젠테이션용 데이터 오브젝트를 리턴하는 질의(query)(하부 액션 코드로 구성됨)를 나타낸다. 이 시스템은, 클라이언트가 에이전트를 최적화하고 "블렌드(blend)"하기 위한 여러 수단 및 궁극적인 정보의 프리젠테이션을 최적화하기 위한 하부 관련 질의들 뿐만 아니라 매우 다양한 어플리케이션을 고려한다. 본 발명의 시스템(10)의 바람직한 구성 요소들 각각이 구성 요소들간 상호작용과 더불어 이하 보다 상세히 설명된다.

2. SYSTEM ARCHITECTURE

본 발명의 Information Nervous System용 엔드-투-엔트 시스템 아키텍쳐가 도 8을 참조하여 개시된다. 도 8은 본 발명이 Information Nervous System KIS(XML Web Service)와 스마트 에이전트 사이에서 다수의 클라이언트 액세스 통신 수단을 제공하는 방법을 나타낸다. 바람직한 실시예에서, 이는 정보 에이전트를 통해 생성된다. 선택적인 실시예에서, 통신은 기업 지식 포털(오늘날의 웹 액세스 브라우저 등)를 통해 또는 커스텀 클라이언트에 의해 프로그램에 따른 통합을 가능하게 하는 SDK 레이어를 통해 프로그램에 따라 생성될 수도 있다.

구성 요소들을 포함하는 Information Nervous System의 KIS에 대한 시스템 아키텍쳐가 도 9를 참조하여 개시된다. 이들 구성 요소는 이하 보다 상세히 설명된다.

3. 테크놀로지 스택(TECHNOLOGY STACKS)

오늘날의 웹과 개념상의 시맨틱 웹 사이의 중요한 차이점은 도 10을 참조하여 각각 개시되는 테크놀로지 스택을 참조하여 보다 강조된다. 도 10은 오늘날의 웹의 하이-레벨 상세 플랫폼과 본 발명의 Information Nervous System에서의 하이-레벨 상세 플랫폼의 사이드-바이-사이드 비교이다. 도 10은 오늘날의 웹에서의 시나리오가 특정 인스턴스에서 Information Nervous System에서의 시나리오에 매핑하여, 사용자에게 논리적인 마이그레이션 경로를 제공하는 방법 뿐만 아니라, 오늘날의 웹에 존재하지 않는 Information Nervous System의 특징적인 양상들을 나타낸다.

4. 시스템 복합성(SYSTEM HETERGENITY)

복합성은 본 발명의 이점이다. 바람직한 실시예에서, KIS 에이전시 XML 웹 서비스는 이동가능하다. 이는 호환가능한 XML, XML 웹 서비스 등의 오픈형 규격들(호환성을 위해 WS-I 규격을 채용하는 등), 데이터 스토리지 및 액세스용 규격들 (SQL 및 ODBC/JDBC 등) 및 DSA가 데이터를 모으는 정보 저장소에 대한 규격 프로토콜들(LDAP, SMTP, HTTP 등) 등을 지원한다는 것을 의미한다.

예를 들어, 바람직한 실시예에서, KIS(Agency가 동작중인)는 이하의 것을 할 수 있다:

. LDAP 스토어(store)로부터 "people" 메타데이터 취합(LDAP DSA를 이용함). 이는 마이로소프트사의 윈도우 2000 액티브 디렉토리, 썬사의 디렉토리 서버, 및 LDAP를 지원하는 기타 디렉토리 제품들의 지원을 허용한다. 플랫폼-특정 API를 사용하여 "people" 메타데이터를 취합하는 플랫폼-특정 액티브 디렉토리 DSA를 구비하는 것이 바람직하다.

. SMTP 스토어로부터 e-메일 메타데이터 취합(임의 소스로부터의 e-메일에 대하여 또는 시스템 인박스에 대하여). 이는 마이크로소프트사의 익스체인지, 로터스사의 노트 및 기타 e-메일 서버(SMTP를 지원하는 것임) 지원을 허용한다. 플랫폼-특정 마이크로소프트 익스체인지 e-메일 DSA 또는 로터스 노트 e-메일 DSA를 구비하는 것이 바람직하다.

. iCalendar 등 오픈형 규격을 지원하는 캘린더 스토어로부터의 "event" 메타데이터 취합 및 CAP(Calendar Access Protocol) 등의 프로토콜 사용. 이는 iCalendar 또는 CAL 프로토콜 규격을 지원하는 이벤트 저장소 지원을 허용한다. 플랫폼-특정 마이크로소프트 익스체인지 캘린더(또는 이벤트) DSA, 로터스 노트 캘린더 DSA 등을 구비하는 것이 바람직하다.

선택적인 실시예에서, KIS 에이전시는 소유자 저장소에 저장된 메타데이터를 (적절한 DSA를 통해)추출하도록 구성되어도 좋다.

시스템 복합성을 달성하기 위해, 바람직한 실시예에서는, 클라이언트-서버 통신에 대하여, 시스템(10)은 (플랫폼을 거쳐) 연동가능한 방식으로 동작하는 XML 웹 서비스 규격을 사용한다. 이들은 SOAP, XML, Web Services Security(WS-Security), Web Services Caching(WS-Caching) 등에 대하여 적절한 오픈형이고 연동가능한 규격을 포함한다.

본 발명의 바람직한 실시예에서, 시맨틱 브라우저(또한 Information Agent^TM으로 언급된다)는 플랫폼 전반에 대하여 Windows, .NET, J2EE, Unix 등의 서로 다른 환경에서 동작할 수 있다. 이러한 기능은 브라우저가 어떠한 "platform" 상에서 동작하는지 또는 에이전시(서버)가 어떠한 플랫폼 상에서 동작하는지를 사용자가 주의하지 않고 주의할 필요도 없다는 점에서 시맨틱 사용자 경험의 관념과 일관된 것이다. 본 발명의 시맨틱 브라우저는 사용자에게 그들이 Windows(또는 .NET) 서버 또는 J2EE 서버로 "talking"하는지 여부에 관계없이 일관된 경험을 제공한다. 사용자들은 그들이 상호작용하는 에이전시 중 임의의 것이 동작하는 플랫폼에 기초하여 클라이언트를 인스톨하거나 사용하는 동안 어떠한 여분의 단계를 행할 필요도 없다.

정보 에이전트가 바람직하게는 그 스킨에 대한 오픈형 규격 및 기타 프리젠테이션 효과를 사용한다. 이들은 플랫폼을 걸쳐 동작하는 XSLT, SVG 및 소유자 프리젠테이션 포맷 등의 규격을 포함한다(적절한 버젼의 Flash MX/ActionScript 등).

본 발명의 Information Nervous System의 바람직한 실시예의 샘플, 이질성, 엔드-투-엔드 구현이 도 11을 참조하여 개시된다. 도 11은 Information Nervous System의 바람직한 실시예를 도시하고, 본 발명에 대한 이질성, 크로스-플랫폼 컨텍스트를 도시한다. 도 11에 도시된 구성 요소들은 이하 보다 상세히 설명된다.

5. 보안(SECURITY)

Information Nervous System의 바람직한 실시예는 이하와 같은 보안의 모든 측면에 대한 지원을 제공한다: 인증, 허가, 감사, 데이터 프라이버시, 데이터 집적도, 가용성 및 비-거부(non-repudiation). 이는 보안을 위한 플랫폼에 XML 웹 서비스 어플리케이션을 제공하는 WS-Security 등의 규격을 채택함으로써 달성된다. 보안이 바람직하게는 XML 웹 서비스 프로토콜 스택에서의 보안 규격을 통해 프로토콜 레이어에서 조작된다. 이는 클라이언트(시맨틱 브라우저)로부터 서버(에이전시)로의 암호화 방법 호출, 디지털 서명 지원, 에이전시의 시맨틱 네트워크로의 액세스를 허용하기 이전 사용자 호출의 인증 및 XML 웹 서비스 방법 등을 포함한다.

본 발명이 로컬(클라이언트측) 신임 관리(credential management)를 지원하는 바람직한 실시예. 이는 바람직하게는 사용자에게 그들이 다수의 에이전시 상에서(인트라넷 내에서) 또는 인터넷을 통해 사용하는 사용자명과 패스워드의 리스트를 입력하라고 요구함으로써 구현된다. 시맨틱 브라우저는 사용자에 대하여 서로 다른 인증 신임을 갖는 다수의 에이전시로부터 정보를 모은다. 지원되는 인증 신임이 바람직하게는 사용자명 및 패스워드를 사용하는 기본 인증, SSL상의 기본 인증, 마이크로소프트사의 .NET 패스포트 인증 서비스, 신규 Liberty 인증 서비스, SSL상의 클라이언트 인증, 다이제스트 인증, 및 통합 윈도우 인증(윈도우 환경에서의 사용을 위함) 등과 같은 통사의 스킴을 포함한다.

바람직한 실시예에서는, 클라이언트에서 캐쉬된 사용자의 신임에 의해, 지원되는 인증 레벨 및 에이전시에 대한 스킴(에이전시의 스킴의 일부임)을 체크함으로써 시맨틱 브라우저는 주어진 에이전시에 대하여 적절한 신임을 사용한다. 예를 들어, 에이전시가 통합 윈도우 인증을 지원하면, 시맨틱 브라우저는 사용자에 대한 로그온 조작 또는 기타 식별자에 의해 XML 웹 서비스 방법을 불러낸다. 에이전시가 SSL 상의 기본 인증만을 지원하면, 시맨틱 브라우저는 로그온하기 위한 사용자명 및 패스워드 또는 로그온 조작의 캐쉬된 사본(클라이언트가 이미 로그온 되었고 로그온 조작이 소멸되지 않은 경우)을 전달한다. 바람직한 실시예는, 인증 프로세스 속도(및 로그온 조작 룩업)를 증가시키기 위해, 또한 해킹된 로그온 조작에 대응하여 보호함으로써 보다 나은 보안성을 제공하기 위해, KIS에 대한 로그온 조작 캐슁, 에이징 및 소멸 등의 기술을 채택한다.

에이전시 XML 웹 서비스가 바람직하게는 XML 웹 서비스 구현 자체에 의해 맹목적으로(이러한 특징이 서버 운영 시스템 또는 어플리케이션 서버에 의해 본래 지원되는 경우) 또는 어플리케이션-레벨로 서로 다른 인증 스킴을 지원한다. KIS 에이전시의 XML 웹 서비스의 선택적인 실시예가 바람직하게는, 기본 인증, SSL 상의 기본 인증, 다이제스트 인증, 통합 윈도우 인증, SSL상의 인증, 클라이언트는 인증, 통합 .NET 패스포트 인증 등과 같은 다양한 인증 스킴들을 채택한다.

6. 효율성 고려(EFFICIENCY CONSIDERATIONS)

클라이언트측 및 서버측 질의 및 오브젝트 캐쉬. 본 발명은 빠른 액세스를 위해 질의 캐쉬를 담당하는 질의 캐쉬에 대하여 제공한다. 클라이언트에 대하여, 클라이언트측 질의 캐쉬는 특정화된 인자(specified arguments)를 갖는 SQML 질의의 결과를 캐쉬한다. 캐쉬가 바람직하게는 소정의 시간(몇 분 등) 이후에 그 콘텐츠를 내보내도록 구성된다. 시간이 바람직하게는 시스템 활용도를 모델링하여 캐쉬 시간 제한에 대한 최적값에 도달하도록 함으로써 설정된다. 에이전시 상의 데이터 도달 속도(다른 구현 옵션인 에이전시 캐쉬 마다의 경우), 사용자의 활용도 모델(네비레이션 비율 등) 등의 기타 파라미터가 고려되어도 좋다.

사용자가 시맨틱 환경을 네비게이트할 때 클라이언트가 최근에 사용된 서버들을 액세스할 필요가 없기 때문에 캐슁은 성능을 향상시킨다. 바람직한 실시예에서, 클라이언트는 규격 XML 웹 서비스 캐슁 기술(WS-Caching 등)을 채택한다. 또한, 클라이언트에 대하여, 바람직하게는 오브젝트 캐쉬가 존재한다. 이러한 캐쉬는 각각의 SQML 리소스의 결과를 캐쉬하고 리소스 참조(파일 경로, URL 등)가 태그된다. 이는 클라이언트가 리소스 자체를 액세스할 필요없이 오브젝트 캐쉬로부터 직접 SQML 리소스에 대한 XML 메타데이터를 얻을 수 있기 때문에 SQML 처리를 최적화한다. 상기 리소스는 로컬 파일 시스템이나, 로컬 어플리케이션(예를들면, 마이크로 소프트아웃룩)이나, 또는 에이젼시의 XML웹 서비스일 수도 있다. 상기 질의 캐쉬와 마찬가지로, 상기 오브젝트 캐쉬는 일정시간(예를들면, 몇 분 정도) 후에 그 컨텐츠들을 제거하도록 형성될 수도 있다.

선택적인 실시예에서는, 서버에 대하여, 서버측 질의 캐쉬가 XML 인자에 대한 카테고리 결과를 캐쉬한다. 이는 각각의 질의 요청에 대하여 서버가 KDM이 XML 인자(argument)를 카테고리화할 것을 요청할 필요가 없기 때문에(KIS가 그 도메인 지식을 얻도록 구성되는 하나 이상의 KBS 인스턴스를 통함) 질의 응답 시간 속도를 향상시킨다. 게다가, 상기 서버는 클라이언트들로 부터 SQML 인자(argument)들의 SQL 등가물들을 캐쉬할 수 있다. 이는 서버가 클라이언트로부터 요청을 수신할 때마다 SQML 인자(argument)들을 SQL로 변환할 필요가 없기 때문에 질의 응답 시간 속도를 향상시킨다. 바람직한 실시예에서, 공격적인 클라이언트측 캐슁이 채택되고 서버측 캐싱은 명백하게 성능을 향상시키지 않으면 회피된다. 이는 클라이언트 캐쉬가 그 로컬 컨텍스트에 기초하여 요청하기 때문에 클라이언트측 캐슁이 서버측 캐슁보다 스케일이 우수하기 때문이다.

가상, 분산 질의(Virtual, Distributed Queries). 본 발명은 가상, 분산 질의를 채택한다. 이는 "dynamic linking" 및 "user-controlled browsing" 기능성과 일관된다. 상기 시스템은 그 시스템에 대한 모든 메타데이터를 유지하는 개별 대량의 데이터베이스를 링크하는 스태틱 네트워크를 필요로 하지 않는다. 이는 로컬 또는 글로벌 범위에서 수동 저작 및 유지보수에 대한 필요성을 제거한다. 또한, 이는 통합(또는 유니버셜) 스토리지에 대한 피룡성을 제거하면 거기서 모든 메타데이터는 단일 메타데이터 스토어 상에 저장되도록 요구되고, 하나의 데이터베이스 질의 인터페이스(SQL 등)를 통해 액세스 가능하다. 오히려, 본 발명의 XML 웹 서비스를 사용하여 다양한 에이전시에 걸쳐 질의를 다이나믹하게 분배하고(컨텍스트-감 도 및 시간-감도 방식으로), 일관되고 사용자에게 친숙한 방식으로 이들 질의의 결과를 클라이언트에 모으는 "Dynamic Access" 원리를 채택한다.

D. 시스템 구성 요소 및 동작(SYSTEM COMPONENTS AND OPERATION)

1. 에이전시 및 에이전트(AGENCIES AND AGENTS)

본 발명은 에이전시 및 에이전트를 이용하여 지식을 검색, 관리 및 전달하는 고유한 어프로치를 도입한다.

a. 에이전시들(Agencies)

본 발명의 바람직한 실시예에서, 에이전시는 KIS(Knowledge Integration Server; 50)의 인스턴스이고, 웹 사이트에 대한 본 발명의 등가물이다. 에이전시가 바람직하게는 웹 어플리케이션(웹 서버 상에서)으로 인스톨되어, XML 웹 서비스를 드러낸다. 에이전시가 바람직하게는 에이전시 매니저를 포함할 것이다. 본 발명의 바람직한 실시예에서, 에이전시는 이하의 주요 구성 요소를 구비한다:

. 에이전시가 인증을 지원하는지 또는 요구하는지(또는 양자 모두)를 나타내는 플래그. 에이전시가 인증을 요구하면, 에이전시는 기본 사용자 정보 및 패스워드를 요구할 것이고, 그가 지원하는 인증의 타입으로 정보를 저장할 것이다. 사용자 정보를 저장하는 에이전시에 대하여, 에이전시는 또한 사용자 가입 정보를 요구할 것이다(특정 에이전시에 대하여 에이전트로의 가입을 위함).

. 시맨틱 오브젝트(문서, e-메일 메시지 등)의 구조화된 스토어-각각의 클래스에 대한 스킴에 대응함.

. 시맨틱 질의에 응답하는 런타임 구성요소-구성요소는 호출 어플리케이션에 XML을 리턴할 것이고, 시맨틱 프라우저의 모든 정보 검색 특징에 대한 시스템 서비를 제공한다.

서버측 사용자 상태(Server-Side User State). 본 발명의 바람직한 실시예에서, 에이전시는 "people" 메타데이터 및 사용자 인증을 포함하는 관련 개념을 연관시키는 서버측 사용자 상태를 지원한다. 서버측 사용자 상태는, 사용자 즐겨찾기(user favorites)의 저장(사람들 오브젝트와 정보 오브젝트 사이의 시맨틱 링크에 의함), 새로운 링크를 생성하기 위한 기호의 추론(추천 등), 주석(사용자의 코멘트를 정보 오브젝트에 매핑시킴), 및 사용자를 정보에 매핑시키는 시맨틱 링크에 기초하여 "experts"의 추론(배달된 e-메일, 주석 등)을 포함하는 본 발명의 많은 상세한 구성을 구동시킨다. 서버측 사용자 상태는 바람직하게는 "Experts", "Favorites", "Recommendations" 및 "Newsmakers" 등 몇몇 컨텍스트 템플레이트과 함께 사용된다.

클라이언트측 사용자 상태. 정보 에이전트(시맨틱 브라우저)가 바람직하게는 로컬 클라이언트측 사용자 상태의 로밍을 지원한다. 이는 사용자의 시맨틱 환경 및 사용자의 신임(보안 전송됨)을 포함한다. 바람직한 실시예에서, 사용자는 그들의 시맨틱 환경을 다른 기계에 복제하기 위하여 클라이언트측 사용자 상태를 다른 기계에 용이하게 드러낼 수 있다. 이는 사용자의 에이전트 리스트(최근 기호), 에이전트에 대한 메타데이터(SQML 버퍼를 포함), 사용자의 로컬 보안성 신임 등을 이들 모든 상태를 시리얼화하고 용이하게 전달될 수 있게 하는 XML 포맷으로 전송함으로써 바람직하게 달성된다. 선택적으로는, XML 스킴이 모든 로컬 클라이언트측 사용자 상태에 대하여 개발될 수 있다. 사용자 상태를 서버에 캐슁하고 공통 동기화 기술을 이용하여 사용자 상태를 동기화하는 것은 또한 로밍을 촉진시킬 수 있다. 시맨틱 브라우저가 바람직하게는, 상태를 로컬하게(XML 파일 또는 윈도우 레지스트리 등과 같은 소유자 스토어) 저장하기 보다는 오히려 모든 클라이언트측 사용자 상태를 서버에 다운로드 및 업로드한다.

b. 에이전트(Agents)

에이전트는 본 발명의 시맨틱 네트워크로의 메인 엔트리 포인트이다. 에이전트가 바람직하게는, 특정 시맨틱 오브젝트 타입(문서, e-메일, 사람들 등)에 대한 XML 정보를 리턴하는 시맨틱 필터 질의를 포함한다. 환언하면, 에이전트가 바람직하게는 특정 오브젝트 타입(이하 설명됨)으로 구성된다. 에이전트는 또한 컨텍스트 템플레이트(이하 설명됨)로 구성된다. 이 경우, 질의는 오브젝트 타입을 리턴 할 것이나, 컨텍스트 템플레이트의 시맨틱을 결합할 것이다. 예를 들어, "Headlines" 컨텍스트 템플레이트으로 구성된 에이전트는 시간 및 컨텍스트 등에 의해 분류되어 저장될 것이다. 에이전트는 또한 통지, 경고 및 알림 등을 필터링하기 위해 사용된다. 에이전트는 임의의 명칭으로 주어질 수 있다. 그러나, 본 발명의 바람직한 실시예에서, 대부분의 에이전트에 대한 지칭 포맷은 이하와 같다:

＜Agentobjecttype＞.＜semanticqualifier＞.＜semanticqualifier＞

에이전트는 임의로 지칭될 수 있다. 그러나, 에이전트 명칭의 예로는 이하의 것을 포함한다:

All.All

Email.All

Documents.Technology.Wireless.80211b.All

Events.Upcoming.NextThirtyDays.All

또한 상이한 이름으로 명명된 콘벤션(convention)(이하 참조)을 따르는 도메인 에이전트(이하 참조)가 존재할 것이다. 본 발명의 시맨틱 브라우저에서, 완벽한 형태의 도메인 에이전트 명칭은 이하의 포맷을 가질 것이다:

＜Agentobjecttype＞.＜semanticdomainname＞.＜categoryname＞

[Agency=＜Agency url＞, kb=＜kb ur1＞]

예를 들어, 시맨틱 도메인 명칭이 industries.informationtechnology이고 지식-베이스 ABC.com/kb.asp로부터 카테고리가 wireless.all로 구성되는 에이전시 http://research.Agency.asp에 대한 e-메일 도메인 에이전트는 이하와 같이 완전한명칭으로 지칭된다:

Email.Industries.InformationTechnology.Wireless.All

[Agency=http://research/Agency.asp,kb="http://abccorp.com/kb.asp"]

본 발명의 시맨틱 브라우저가 바람직하게는 에이전트 명칭만을 사용하도록 또는 "Agency" 및 "kb" 수식자(qualifiers)를 포함하도록 구성된다.

에이전트 타입(Agent Types). 서버(20) 상에 생성되는 에이전트의 주요한 3가지 타입이 이하와 같이 존재한다: 표준 에이전트(Standard Agents), 복합 에이전트(Compound Agents) 및 도메인 에이전트(Domain Agents). 표준 에이전트는 도 메인 지식(또는 온톨로지(ontology)/텍사노지(taxonomy) 매핑)이 없이, 구조화된, 논-시맨틱 질의들을 캡슐화하는 독자적인 에이전트이다. 예를 들어, 서버 상에서, All.postedToday.All이라는 에이전트는, CreationTime 특성에 기초하여 모든 오브젝트를 필터링함으로서 해석되는 간단한 에이전트이다. 표준 에이전트가 보다 복잡할 수도 있다. 예를 들어, All.PostedByAnyMemberOfMyTeam.All이라는 에이전트는 오브젝트 테이블 및 사용자 테이블(이하 참조)로부터의 협력 및 서브-질의를 포함하는 복잡한 질의로 해석될 수 있다.

복합 에이전트는 기타 에이전트를 포함하며, 그들의 포함된 에이전트(구성에 의존함)의 결과의 UNION 또는 INTERSECTION인 결과를 생성하는 질의를 에이전시 매니저가 생성할 수 있게 한다. 복합 에이전트는 또한 기타 복합 에이전트를 포함할 수 있다. 바람직한 실시예에서, 복합 에이전트는 동일한 에이전시로부터의 에이전트를 포함한다. 그러나, 본 발명은 상이한 에이전시로부터의 에이전트의 통합을 원한다. 예를 들어, All.Technology.Wireless.All이라는 복합 에이전트는 이하의 에이전트를 복합함으로써 생성될 것이다:

. Documents.Technology.Wireless.All

. Email.Technology.Wireless.All

. People.Experts.Technology.Wireless.All

상술된 바와 같이, 도메인 에이전트는 시맨틱 도메인에 속하는 에이전트이다. 도메인 에이전트는 임의의 다른 에이전트와 마찬가지로 에이전트 질의로 초기화한다. 그러나, 이러한 질의는 지식 도메인 매니저(이하 참조)에 의해 대중화된 CATEGORIES 테이블을 포함한다. 본 발명의 바람직한 실시예가 비공개 시맨틱 환경에 대응하는 소유자 온톨로지를 구비하는 KBS(80)를 사용하는 한편, 본 발명은, 예를 들어 에이전시가 그 조직에 대하여 소유자 온톨로지으로 이전에 초기화되었던 조직 내에서, 에이전시가 하나 이상의 커스텀 비공개 KBS에 접속할 수 있게 할 온톨로지 상호교환 규격의 통합 지원을 예상한다.

도메인 에이전트의 일 예로는 Email.Technology.Wireless.All이 있다. 이 에이전트가 바람직하게는 이하와 같은 지식 소스 URL에 의해 생성된다:

category://technology.wireless.all@ABC.com/marketingknowledge.asp

이러한 지식 소스 URL은ABC.com/marketingknowledge.asp 웹 서비스 상에 인스톨된 지식 베이스 상의 디폴트 도메인에 대한 Technology.Wireless.All 카테고리에 대응한다. 이는 이하의 HTTP URL으로 해석된다. http://ABC.com/marketingknowledge.asp?category="technology.wireless.all". 본 예에서, 완전히 수식된(qualified) 버전의 카테고리 URL은 이하와 같다:

category://technology.wireless.all@abccorp.com/marketingknowledge.asp?semanticdomainname="InformationTechnology"

본 경우, 카테고리 URL은 도메인 이름에 의해 수신된다.

도메인 에이전트가 바람직하게는 도메인 에이전트 마법사를 통해 생성되고, 에이전시 매니저는 KBS(80)로부터의 도메인 에이전트를 본 발명의 시맨틱 네트워크에 부가할 수 있다. 도메인 에이전트 마법사는 사용자가 특정 카테고리에 대하여(카테고리 URL을 이용함) 또는 전체 시맨틱 도메인 이름에 대하여 도메인 에이전트 를 생성할 수 있게 한다. 후자의 경우, 에이전시가 바람직하게는 KBS 상의 시맨틱 도메인에 신규 카테고리가 부가됨에 따라 자동적으로 도메인 에이전트를 생성하도록 구성된다. 이러한 특징은 도메인 및 카테고리가 다이나믹하게 유지될 수 있도록 하고, 이에 의해 시간에 대한 사용자의 요구에 용이하게 적응할 수 있게 된다. 도메인 에이전트가 이러한 유형으로 관리될 때, 에이전시는 더 이상 시맨틱 도메인에 존재하지 않는 에이전트를 제거하도록 구성될 수 있다. 본질적으로, 이러한 모드에서, 도메인 에이전트는 CATEGORIES 테이블과 동기화 된다(이는 다시 이하 설명되는 지식 도메인 매니저에 의해 관련 KBS에서 CATEGORIES 리스트와 동기됨).

도메인 에이전트는 카테고리 명칭 또는 URL에 기초하여 에이전트가 관리하는 데이터를 필터링하는 구조화된 질의로 초기화된다. 이러한 상황에서, 구조화된 질의는 표준 에이전트에 대한 질의와 동일하다. 카테고리 에이전트에 대한 궁극적인 질의의 일 예는 다음과 같다:

SELECT OBJECT FROM OBJECTS WHERE OBJECTID IN (SELECT

OBJECTID FROM SEMANTICLINKS WHERE PREDICATETYPEID=50

AND SUBJECTID=1000 AND OBJECTID IN (SELECT OBJECTID FROM

CATEGORIES WHERE URL LIKE

category://technology.wireless.all@ABC.com/kb.asp?domain="marketing"))

본 예에서, "belongs to the category" 술어부 타입 ID는 값 50을 갖는 것으로 가정되고, 카테고리 objectid는 값 1000을 갖는 것으로 가정된다. 이러한 질의는 영어로 표현하면 이하와 같다:

Select all the objects in the Agency that belong to the category whose object has an objectid value of 1000 and whose URL is category://technology.wireless.all@abccorp.com/kb.asp?domain="marketing"

이는 또한 이하와 같이 해석된다:

Select all the objects in the Agency of the category category://technology.wireless.all@abccorp.com/kb.asp?domain="marketing"

도메인 에이전트 마법사는 사용자에게 간단한 카테고리 명칭 또는 친숙한 버전인 완전히 수식화된 카테고리 명칭 중 어느 것에 기초하여 에이전트를 지칭하기를 원하는지 물을 것이다. 후자의 예로는 : Marketing.Technology.Wireless.All [@ABC]이 있다. 완전히 수식화된 도메인 에이전트 지칭 콘벤션은 다음과 같다:

＜objecttypename＞.＜semanticdomainname＞.＜categoryname＞.all [@KB Name].

본 예에서, 도메인 에이전트 명칭은 이하와 같다:

Email.Marketing.Technology.Wireless.All [@ABC].

블렌더(Blenders). 블렌더는 사용자 개인적의 슈퍼-에이전트이다. 사용자는 블렌더를 생성하여, 블렌더에 에이전트(에이전시를 거쳐)를 추가 및 삭제할 수 있다. 이는 자신의 "Personal Agency"를 갖는 사용자들과 유사하다. 블렌더가 바람직하게는 이들이 다수의 에이전시로부터의 에이전트를 포함하기 때문에 시스템 클라이언트 상에만 불러들여 진다. 본 발명의 클라이언트는 블렌더의 에이전트로부터 모든 오브젝트를 모아서, 이들을 적절하게 부여한다. 블렌더가 바람직하게는 드래그 및 드롭, 스마트 렌즈(이하 설명됨) 등 기타 타입의 에이전트들의 모든 조작 특성을 포함한다. 블렌더는 임의 타입의 에이전트(기타 블렌더들 뿐만 아니라 표준 에이전트, 검색 에이전트, 스페셜 에이전트 등)를 포함할 수 있다.

본 발명은 사용자가 블렌더를 생성하는 것을 촉진하도록 설계된 사용자 인터페이스인 블렌더 마법사를 제공한다. 도 12 내지 14는 본 발명의 바람직한 실시예에 따른 블렌더 마법사 사용자 인터페이스의 예시적인 스크린샷을 도시한다. 도 12는 샘플 시맨틱 환경의 트리 뷰, 및 사용자가 신규 블렌더를 생성하고 관리하도록 하는 "Add Blender" 마법사의 샘플을 나타내는 샘플 정보 에이전트 스크린 샷이다. 도 13은 사용자가 블렌더의 이름과 설명을 입력하고 정보 오브젝트 타입 필터를 최적으로 선택하는 블렌더 부가 마법사의 제2 페이지를 나타낸다. 도 14는 본 발명의 바람직한 실시예에 따른 샘플 블렌더 부가 마법사의 제3 페이지를 나타낸다. 본 예에서, 사용자는 시맨틱 환경으로부터의 에이전트를 블렌더에 부가 및 삭제한다. "Add Agents" 옵션이 선택되면, "Open Agents" 대화가 표시되어 사용자는 신규 에이전트, 블렌더 또는 에이전시를 신규 블렌더에 부가할 수 있다.

브레이킹 뉴스 에이전트(Breaking News Agents). 브레이킹 뉴스 에이전트은 특별히 태그된 스마트 에이전트이다. 에이전시 매니저에 의해 규정되는 시간-임계성(time-criticality)를 갖는 옵션에 부가하여, 사용자는 어느 에이전트가 경고되기를 원하는 정보를 참조하는지를 나타내는 옵션을 갖는다. 브레이킹 뉴스 에이전트에 대하여 관련되는 브레이킹 뉴스가 존재하면 표시되는 모든 정보가 경고를 나타낼 것이다. 예를 들어, 사용자는 이하와 같은 에이전트를 생성할 수 있을 것이 다: 브레이킹 뉴스 에이전트로서의 "All Documents posted on Reuters today" or "All Events relating to computer technology and holding in Seattle in the next 24 hours". 이러한 특징은 각각의 브레이킹 뉴스 에이전트가 개인적인 것이기 때문에("breaking"은 주관적인 것으로 사용자에 의존함) 개인적인 방식에 따라 작용한다. 예를 들어, 시애틀에서의 사용자는 아마 시애틀에서의 사건들을 24시간 내에, 서부 해안에서의 사건들을 다음 주 내에(이 시간 동안 값싼 항공편을 알아볼 수 있음), 미국에서의 사건을 다음 14일 내에(가장 적당하게 가격이 책정된 대륙간 비행기편을 얻기 위해 대부분의 미국 항공선에 대한 사전 통지), 유럽에서의 사건들을 다음 달 내에(호텔 예약을 하기 위한 시간을 필요하기 때문일 것임), 전 세계에서의 사건들을 다음 6개월 내에 통지받기를 원할 것이다.

바람직한 실시예에서, 본 발명은 각각의 브레이킹 뉴스 에이전트를 질의하거나 또는 "Breaking News" 컨텍스트 템플레이트를 질의함으로써 브레이킹 뉴스에 대한 시맨틱 환경을 자동적으로 체크할 것이다. 브레이킹 뉴스 에이전트가 브레이킹 뉴스가 있다는 것을 나타내면, 정보 에이전트 오브젝트 스킨은 윈도우를 깜빡거리거나 또는 오브젝트에 관련하는 경고가 있다는 것을 명백하게 나타내는 사용자 인터페이스를 나타내는 것에 의해 표시할 것이다. 사용자가 브레이킹 뉴스 아이콘을 클릭하면, 브레이킹 뉴스 창(pane) 또는 "Breaking News" 컨텍스트 템플레이트용 컨텍스트 팔레트가 표시되어 사용자가 브레이킹 뉴스를 보고, 브레이킹 뉴스 에이전트(브레이킹 뉴스가 다수 있는 경우)를 선택하고, 술어부를 선택하며, 다른 옵션을 선택할 수 있게 한다. 브레이킹 뉴스 에이전트 사용자 인터페이스의 예시적인 창이 도 15에 도시된다. 이 샘플 사용자 인터페이스는 컨텍스트 결과 창에서의 팝업 메뉴를 나타낸다. 샘플은 에이전트가 브레이킹 뉴스 에이전트라는 점을 제외하고는 스마트 렌즈(에이전트-오브젝트) 팝업 컨텍스트 결과 창(이하 논의됨)과 유사한 컨텍스트 창을 나타낸다.

디폴트 에이전트(Default Agents). 선택적인 실시예에서, 각각의 에이전시는 디폴트 에이전트의 리스트를 드러낸다. 디폴트 에이전트는 웹 사이트 상의 디폴트 페이지와 유사하다: 에이전시의 저작자들(authors)은 어떤 에이전트를 사용자들이 항상 보기를 원하는지를 결정한다. 선택적으로는, 클라이언트상에서, 디폴트 에이전트는 사용자들이 정보 에이전트의 환경의 루트(바람직하게는, 예를 들어 Today's 웹 브라우저 상의 "Home Page"와 동등한 "Home Agent"에 대응함)를 클릭할 때 불려질 것이다. 또한, 복합 디폴트 에이전트들이 사용자들에 의해 형성될 수도 있다.

디폴트 스페셜(또는 컨텍스트) 에이전트. 바람직한 실시예에서, 클라이언트 또는 에이전시는 각각의 컨텍스트 템플레이트에 매핑하는 디폴트 스페셜 또는 컨텍스트 에이전트를 지원한다(이하 논의됨). 이들 에이전트가 바람직하게는 어떠한 필터도 없이 적절한 컨텍스트 템플레이트를 사용한다. 예를 들어, "Today"라 불리우는 디폴트 스페셜 에이전트는 모든 아이템을 오늘 배달되었던 모든 "recent" 및 "favorites" 리스트의 모든 에이전시로(또는 에이전시의 구성 리스트로) 리턴한다. 다른 예에서, "Variety"라 불리우는 디폴트 스페셜 에이전트는 "variety" 컨텍스트 템플레이트에 대응하는 시맨틱 환경에서의 모든 에이전시에 대한 결과의 랜덤 세트 를 나타낸다.

디폴트 스페셜 에이전트가 바람직하게는 대부분의 사용자들이 본 발명의 Information Nervous System과 친숙하게 되는 시작 지점으로서 기능한다. 또한, 디폴트 스페셜 에이전트는, 드래그 및 드롭, 복사와 첨부, 스마트 렌즈, 상세 정보(Deep Information) 등 스마트 에이전트와 동일한 기능성을 유지한다.

수평 결정 에이전트(Horizontal Decision Agents). 바람직한 실시예에서, 사용자 인터렉션을 지원하기 위해 사용자가 이용하는 에이전트는 이하의 것을 포함한다:

. 스케쥴 에이전트(Schedule Agent): 스케쥴 에이전트는 특정 사용자들이 이벤트에 참가하기를 원하는 가능성에 기초하여 이벤트에 지능적으로 순위를 매긴다.

. 미팅 팔로우-업 에이전트(Meeting Follow-up Agent): 미팅 팔로우-업 에이전트는 과거에 생성한 것과 팔로우-업 미팅을 해야할 시간이 다가오면 사용자들에게 지능적으로 알려준다. 추론 엔진(Inference Engine; 이하 참조)은 관련 시맨틱 액티비티를 모니터하여 팔로우-업 미팅을 보장하기에 충분한 변화가 생성하였는지 여부를 판정한다. 사용자가 바람직하게는 정보 오브젝트 관점으로서 이전 미팅 오브젝트를 사용하여 관련 지식 변화(신규 문서, 참석하기를 원하는 새로운 사람 등)를 찾는다.

. 태스크 팔로우-업 에이전트(Task Follow-up Agent): 태스크 팔로우-업 에이전트는 태스크에 응답하여 사용자들에게 사용자가 수행할(문서의 읽기, 그들의 캘린더에 이벤트를 부가하는 것 등) 추천을 보낸다. 에이전트는 사용자가 꾸준히 팔로우-업하는 것을 보장한다. 추천은 사용자의 프로파일에 기초하는 것이고, 에이전트가 바람직하게는 추천을 결정하기에 협조적인 필터링을 사용한다.

. 고객 팔로우-업 에이전트(Customer Follow-up Agent). 고객 팔로우-업 에이전트는 고객의 활동에 기초하여 사용자들에게 통지를 보낸다. 에이전트는 사용자가 언제 참석을 원하는 가를 지능적으로 결정한다(사용자로부터 수신된 e-메일, 사용자 서비를 돕는 신규 문서 등에 기초함).

공개 대 로컬 에이전트(Public versus Local Agents). 에이전시 매니저에 의해 생성되는 에이전트는 "Public Agents"이다. 사용자에 의해 생성되어 관리되는 에이전트는 "Local Agents"이다. 로컬 에이전트는 에이전시 XML 웹 서비스 URL에 대함 참조를 포함하는 SQML을 통해 원격 에이전시를 참조하거나, 또는 로컬 메타데이터 스토어로 KIS의 로컬 인스턴스를 동작시키는 로컬 에이전시를 참조할 수 있다.

저장된 에이전트-사용자의 내 에이전트 리스트(Saved Agents-Uers' My Agent List). 바람직한 실시예에서, 사용자는 불러낸 에이전트의 사본 또는 질의 결과를 로컬 에이전트로서 저장할 수 있다. 예를 들어, 사용자는 그들의 하드 드라이브 상의 문서를 에이전트 폴더로 드래그 및 드롭하여 시맨틱 관계 질의를 생성한다. 사용자는 그 결과를 "Documents.Technology.Wireless.RelatedToMyDocument"라는 이름의 에이전트로서 저장한다. 그리고 이것은 사용자가 그 에이전트를 네비게이트하여 개인화된(personalized) 시맨틱 질의를 볼 수 있게 한다. 사용자들은 그래서 그 에이전트를 사용해서 새로운 개인 에이전트 등을 생성시킬 수 있을 것이다. 개 인적 에이전트 또한 에이전시에 "공개(published)"될 수 있다. 기타 사용자들이 바람직하게는 에이전트를 발견하여 이에 가입할 수 있다.

바람직한 실시예에서, 로컬 에이전트는 시맨틱 관계 질의 결과가 표시될 때마다 클라이언트에 나타나는 "Save as Agent" 버튼에 의해 생성된다. 이는 사용자가 신규 문서를 저장하는 것과 유사하다. 에이전트가 일단 저장되면, 이는 사용자의 마이 에이전트 리스트에 부가된다. 에이전트는 호스트된 에이전시의 시맨틱 도메인에 기초하여 시맨틱 질의에 응답한다. 본질적으로, 에이전트에 대한 시맨틱 질의는 에이전트가 "질의를 이해하였는지(understands the query)" 여부를 묻는 것과 유사하다. 에이전트는 질의에 응답하여 최고의 "이해(understanding)"를 돕는다. 또 다른 예시로서, "People"을 관리하는 에이전트는 시맨틱 도메인의 사람들을 그 도메인의 카테고리에 매핑시키는 자신의 내부 매핑에 기초하여 문서에 대한 전문가를 요구하는 시맨틱 질의에 응답한다.

선택적으로, 시스템 클라이언트는 논-시맨틱 질의를 사용하도록 구성되어도 좋다. 이 경우, 에이전시는 질의에 대하여 추출된 키워드를 사용할 것이다. 모든 에이전트가 논-시맨틱 질의를 지원한다. 바람직하게는 시맨틱 도메인에 속하는 에이전시에 대한 에이전트만이 시맨틱 질의를 지원할 것이다. 환언하면, 시맨틱 검색은 검색을 저하시킨다.

각각의 에이전트는 "smart"인지 아닌지를 나타내는 속성을 갖는다. 스마트 에이전트가 바람직하게는 그 에이전시가 시맨틱 도메인에 속한다면 에이전시에 생성된다. 또한, 스마트 에이전트만이 그가 완전히 "이해한(understands)" 오브젝트 를 리턴한다. 바람직한 실시예에서, 에이전시가 인스톨될 때는, 에이전시 매니저가 인스톨하기를 옵션으로 선택할 수 있는 몇몇 디폴트 스마트 에이전트가 있으며, 이하의 것을 포함한다:

. All.Understood.All

. Documents.Undestood.All

. Email.Understood.All

예를 들어, Email.Understool.All만이 에이전시가 그 시맨틱 도메인(또는 온톨로지)에 기초하여 시맨틱하게 이해할 수 있는 e-메일 오브젝트를 리턴한다.

본 발명이 바람직하게는 사용자가 모든 오브젝트를 표시할 수 있는 기능을 포함하고, 이들 에이전시만이 이해한다.

검색 에이전트(Search Agents). 검색 에이전트는 검색 스트링으로 초기화되는 에이전트이다. 바람직한 실시예에서, 불러들일 때, 클라이언트는 검색 요청을 발행한다. 검색 에이전트는 이하의 것을 포함하는 시맨틱 환경의 임의의 부분을 선택할 수 있도록 구성된다:

. Frequently Used Agents

. Recently Used Agents

. Recently Created Agents

. Favorite

. All[Saved] Agents

. Deleted Agents

. Agents on the local area network

. Agents on the Global Agency Directory

. Agents on any user-customized Agency directories

. All Agents in the entire Semantic Environment

클라이언트는 검색 에이전트의 범위에 기초하여 검색 요청을 생성한다. 사용자가 전체 시맨틱 환경을 커버하는 검색을 원한다는 것을 나타내면, 클라이언트는 시맨틱 환경 매니저(이하 참조)의 모든 에이전트 및 로컬 영역 네트워크, 글로벌 에이전시 디렉토리 및 사용자-커스텀화된 에이전시 디렉토리 상의 모든 에이전트에 대한 요청을 생성한다.

서버측 즐겨찾기 에이전트(Server-Side Favorite Agents). 다른 선택적인 실시예에서, 에이전시는 사용자 상태 지원 즐겨찾기 에이전트를 지원한다. 오늘날의 웹의 유사한 컨텍스트에서, 웹 사이트는 사용자가 그들의 즐겨찾기 링크, 스톡(stock) 등을 커스텀화할 수 있게 한다. 초기에 질의될 때, 에이전시는 호출한 사용자의 디폴트 에이전트 및 즐겨찾기 에이전트 모두를 표시한다(사용자 상태가 존재하는 경우임).

스마트 에이전트(Smart Agents). 스마트 에이전트는 XML 웹 서비스를 통해 에이전시를 참조하는 구조화된 시맨틱 질의를 캡슐화하는 독자적인 에이전트이다. 바람직한 실시예에서, 클라이언트 상의 사용자는 오픈 에이전트 대화를 통해 시맨틱 환경을 브라우즈할 수 있게 하는 "Creat Smart Agent" 마법사를 통해 스마트 에이전트를 생성하고 편집할 수 있다. 본질적으로, 이는 사용자 인터페이스로부터 SQML 질의를 생성하는 사용자들에 대응한다. 바람직한 실시예에서는 사용자 인터페이스만이 사용자가 동일한 에이전시 리소스로부터 링크를 부가할 수 있게 한다. 그러나, 사용자는 스페셜 에이전트 및 블렌더(또한 바람직하게는 크로스-에이전시임) 이외에도 에이전시를 통해 동일한 카테고리의 에이전트를 생성할 수 있다. 스마트 에이전트가 현재 질의에 대하여 동일한 에이전시를 참조한다고 가정하면, 사용자 인터페이스는 사용자가 기존 스마트 에이전시를 정보 오브젝트 관점으로서 사용하여 링크를 부가할 수 있게 한다. 도 16은 링크(술어) 템플레이트, 자체 링크 및 오브젝트를 선택하기 위한 사용자 인터페이스 제어가 구비된 오픈 에이전트 대화를 나타낸다. 도 17-19는 오픈 에이전트 대화를 드러내는 샘플 시맨틱 환경의 트리 뷰를 나타낸다. 도 17은 사용자가 시맨틱 환경을 브라우즈하고 에이전트를 열 수 있게 하는 오픈 에이전트 대화이다. 도 18은 시맨틱 환경에서 에이전시를 네비게이팅하는 방식 및 "Small Preview"를 갖는 "Open Agent" 대화를 나타낸다. 도 19는 에이전트 폼 시맨틱 환경을 열기 위해 또는 덤 에이전트를 생성함으로써 시맨틱 환경에 정규 정보를(예를 들어, 파일 시스템으로부터) 임포트하기 위한 신규 옵션을 나타내는 툴바 상의 "Open" 툴을 나타낸다.

링크 템플레이트는 본질적으로 사용자가 사전규정된 필터를 사용하여 현재 오브젝트 타입에 대한 술어를 네비게이트 할 수 있게 하고, 따라서 사용자가 오브젝트 타입에 대한 모든 술어를 거치는 것을 회피하게 할 수 있다. 링크 템플레이트의 예로는 이하의 것을 포함한다:

. All

. Breaking News(예를 들어 "posted in the last" 등 시간-감도를 참조하는 링크)

. Categorization

. Definite(non-porbabilistic links)

. Probable(probabilistic links)

. Annotations

바람직한 실시예에서, 오픈 에이전트 대화는 사용자가 "link to"로 오브젝트를 선택할 수 있게 하고, 오브젝트의 타입에 따라, 사용자가 오브젝트를 브라우즈할 수 있게 한다(예를 들어, 일자/시간인 경우 캘린더 제어로부터, 문자인 경우 문자 박스로부터, 파일 또는 폴더 경로인 경우 파일 시스템으로부터 등). 사용자 인터페이스 마법사는 또한 사용자가 질의의 결과를 미리 볼 수 있게 한다. 임시 SQML 엔트리가 현재 술어 리스트와 함께 생성되고, 이는 대화 박스 마법사 내에서 미니-브라우저 윈도우에 로드된다. 사용자는 술어를 부가 및 제거할 수 있고, 또한 술어의 "OR" 또는 "AND" 중 어느 것을 원하는지를 나타내는 옵션을 가질 것이다. 사용자 인터페이스는 또한 술어 복제에 대하여 체크할 것이다.

사용자가 스마트 에이전트 생성 마법사를 끝내면, 스마트 에이전트는 시맨틱 환경에 부가되고, SQML은 관련 오브젝트 엔트리와 함께 저장된다. 바람직한 실시예에서, 사용자는 에이전트 특성 검사 특성 시트를 사용하여 스마트 에이전트를 차후에 브라우즈할 수 있다. 이는 사용자가 간단한 시맨틱 환경 특성(명칭, 설명, 생성 일자 등)을 볼 수 있게 하고, 또한 리소스 URL(질의되는 에이전시의 XML 웹 서비스에 대한 WSDL URL) 및 술어 리스트를 볼 수 있게 한다. 사용자는 술어 시트로부터의 리스트를 편집할 수 있다.

디폴트 스마트 에이전트(Default Smart Agent). 디폴트 스마트 에이전트는 컨텍스트 템플레이트가 아니라 정보 오브젝트 타입에 기초한다는 점을 제외하고는 디폴트 스페셜 에이전트와 유사하다. 예를 들어, "Documents"는 사용자의 시맨틱 환경에서 모든 에이전시 상에 모든 문서를 리턴할 것이다; "Email"은 사용자의 시맨틱 환경 등에서 모든 e-메일 메시지를 리턴할 것이다.

스페셜 에이전트(Special Agents). 스페셜 에이전트는 컨텍스트 템플레이트(이하 참조)에 기초하여 사용자가 생성하는 스마트 에이전트이다. 스페셜 에이전트가 바람직하게는 비록 스페셜 에이전트 레퍼런스가 없더라도 에이전트 명칭으로 초기화된다. 예를 들어, 스페셜 에이전트 "Email.Technoolgy.Wireless.All"은 시맨틱 환경에 그 명칭의 에이전트가 존재하지 않더라도 생성될 것이다. 검색 에이전트와 같이, 스페셜 에이전트도 임의의 에이전트를 시맨틱 환경의 임의 부분에서 그 이름으로 검색하도록 정해진다. 바람직한 실시예에서, 스페셜 에이전트를 사용자가 불러내면, 클라이언트는 그 명칭을 포함하는 임의의 에이전트를 검색한다. 그 명칭을 갖는 임의의 에이전트를 발견하면, 클라이언트는 에이전트를 부른다.

바람직한 실시예에서, 사용자는 카테고리 필터(필요한 경우) 및 질의할 에이전시를 나타내는 컨텍스트 템플레이트과 일치된 파라미터를 입력한다. 이들은 오픈 에이전트 대화를 이용하여 수동으로 입력될 수 있거나, 또는 사용자가 "recent" 에이전시, "favorite" 에이전시 또는 이들 모두를 질의하기 원한다는 것을 나타낼 수 있다. 선택적인 실시예에서, 사용자는 선택된 에이전시의 "OR" 또는 "AND"인 카테고리(필요한 경우) 또는 글로벌 에이전시 디렉토리에 알려진 모든 카테고리를 선택하는 선택권을 갖는다. 다른 선택적인 실시예에서, 사용자는 정보 타입(컨텍스트 템플레이트dhk 대립하는 것임) 및 검색을 위한 키워드(술어 또는 카테고리와는 대립하는 것입)를 선택할 수 있다.

디폴트 스페셜 에이전트(Default Special Agents). 바람직한 실시예에서, 시스템 클라이언트는 모든 지원되는 컨텍스트 템플레이트으로 매핑시키는 디폴트 스페셜 에이전트를 인스톨한다. 예를 들어, 바람직한 실시예에서, 디폴트 스페셜 에이전트는 이하의 것을 포함한다:

Headlines

Breakin News

Conversations

Newsmakers

Upcoming Events

Discovery

History

All Bets

Best Bets

Experts

Favorites

Classics

Recommendations

Today

Variety

Timeline

Upcoming Events

Guide

커스텀 스페셜 에이전트(Custom Special Agents). 사용자가 생성한 스페셜 에이전트와는 대조적으로, 커스텀 스페셜 에이전트는 안전하고, 보안이 되며 고성능인 것을 보증하기 위해 특별히 개발되고 서명된 스페셜 에이전트이다. 본 발명은 조직 및 개발자들이 그들 자신의 커스텀 블렌더를 생성할 수 있도록 플러그-인 레이어(plug-in layer)를 제공한다. 커스텀 블렌더의 일 예로는 "나의 가장 최근 문서 또는 e-메일과 관련되는 All.CriticalPriority.All"이 있다. 이러한 커스텀 블렌더는 이하와 같은 리소스 엔트리를 갖는 SQML 파일에 의해 구현될 수 있다:

＜resource type="nervana:url"

agent://all.criticalpriority.all@localhost＞

＜link predicate="nervana:relevantto"

type="nervana:localsemanticref"

recentdocuments＞

＜/link＞

＜link operator="or"

type="nervana:localsemanticref"

recentemail＞

＜/link＞

＜/resource＞

바람직한 실시예에서, 프리젠터(이하 참조)는 "link" 엔트리를 로컬하게 해석하고, 가장 최근의 문서 또는 e-메일 메시지에 대응하는 XML 인자(argument)를 갖는 타겟 리소스에 대한 XML 웹 서비스 요청을 초기화한다. 이는 타겟 에이전트가 기점(origination)을 필터링하는 것과 관련되는 시맨틱을 알지 않고도 순수하게 XML 필터를 갖고 시맨틱 질의에 대한 응답에 촛점을 맞출 수 있게 한다. 선택적인 실시예에서, 상술된 예와 같은 커스텀 블렌더는 디폴트 에이전트이다.

수직 결정 에이전트(Vertical Decision Agents). 수직 결정 에이전트는 수직 산업 시나리오에 대한 결정-지원을 제공하는 에이전트이다.

에이전트 구성체계(Agent Schema). 에이전트는 특정된 파라미터 내에서 동작하고 에이전트 구성체계를 구성하는 소정의 특징들을 나타낸다. 에이전트 구성체계는 본 발명의 기술 내에서 매우 광범위하게 동등하게 적용될 수 있다. 예를 들어, 본 발명의 바람직한 실시예의 에이전트 구성체계가 도 20에 도시된다. 본 발명은 특히 더 이상의 필드를 부가하는 것을 의도한다. 예를 들어, 카테고리 URL(또는 경로) 및 컨텍스트 템플레이트 명칭에 대한 필드가 에이전트 구성체계에 부가되어 에이전트가 나타내는 카테고리 및 컨텍스트 템플레이트에 대한 클라이언 트 및 서버의 빠른 액세스를 적용한다(적용가능한 경우). 이는 시맨틱 환경 매니저가 에이전트의 서로 다른 뷰(예를 들어, 카테고리 별로, 콘텍스 별로 등)를 제공하는 것을 돕는다. 이는 에이전트에 대하여 SQML의 이들 필드의 존재를 보완한다(속성 및/또는 술어를 통해 표현됨). 바람직한 실시예에 포함된 AgentTypeIDs가 도 21에 도시된다. 바람직하게는, AgentQueryTypeIDs가 포함되며, 도22에 나타나있다.

바람직한 실시예에서, SQL 질의 포맷이 사용된다. 그러나, 예를 들어 XQL, XQuery 등 다수의 질의 포맷이 본 발명의 범위 내에서 고려된다.

KIS(50)가 바람직하게는 이러한 구성체계에 대응하여 데이터 스토어의 에이전트 테이블(서버측 에이전트용)을 호스트한다. 도 23은 에이전트 명칭에 대응하는 샘플 시맨틱 질의를 나타내는 것으로, 서버측 에이전트가 본 발명의 KIS 상에 바람직하게 구성되는 방법을 나타낸다.

이하 보다 상세히 설명되듯이, 에이전트는 그들 자신의 스킨을 선택적으로 포함할 수 있다. 에이전트 스킨은 XSLT 파일에 대한 URL 또는 동등한 플래시 MX 또는 ActionScript로 표현된다. 에이전트의 Skin URL이 특정되지 않으면, 에이전트의 오브젝트 타입에 대한 디폴트 스킨이 가정된다.

에이전트 질의 룰(Agent Query Rules). OBJECTID 컬럼을 리턴하기 위해 각각의 서버측 에이전트 질의가 특정되어야 한다. 각각의 테이블은 도입된 오브젝트 타입에 대한 테이블과 함께 오브젝트 테이블을 링크시키는 컬럼을 갖는다. 오브젝트 및 기타 테이블들은 이하 보다 상세히 설명된다.

각각의 에이전시 질의가 서브-질의, 캐스케이디드 질의 또는 조인의 기초를 형성할 수 있기 때문에, 각각의 질의는 이러한 포맷을 따르는 것이 바람직하다. 예를 들어, News.All에 대한 질의는 "SELECT OBJECTID FROM NEWS"("NEWS"는 "news" 구성체계를 갖고 새로운 기사에 대한 메타데이터를 호스트하는 테이블의 명칭이다.)로서 나타날 것이다. 결과적으로, 서버(10)는 이러한 질의를 복합 질의의 일부로서 사용할 수 있다. 예를 들어, 사용자가 문서를 에이전트로 드래그 및 드롭하면, 서버는 이러한 질의를 이하와 같이 실행할 것이다:

SELECT OBJECTID FROM NEWS WHERE OBJECTID IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE SUBJECTID IN (50, 67, 89) AND LINKSCORE＞90)

본 예는 문서가 오브젝트 식별자 50, 67 및 89를 갖고 CATEGORIES 테이블의 카테고리에 속하는 것으로 분류된다는 점과 문서가 카테고리에 속한다는 것을 확립하기 위한 링크 확률의 임계치가 0.9라는 점을 가정한다. 본 예에서, 문서는 News.All 질의에 대한 필터로서 사용되고 질의 문자는 복합 질의의 일부로서 사용된다.

질의에 대하여 일관된 규격을 갖는다는 것은 질의가 마침내 부여되어야할 때까지 시맨틱 질의 프로세서가 질의를 머지(merge)할 수 있게 한다. 예를 들어, 시맨틱 질의 프로세서에 대한 각각의 호출은 결과를 리턴하는 오브젝트 타입이 어느 것인가를 나타낸다. 그리고, 질의 프로세서는 요청된 오브젝트 타입에 대한 구성체계와 일관된 XML 정보를 리턴한다. 환언하면, 질의 프로세서가 바람직하게는 프리젠테이션을 위해 구성체계-특정 결과를 리턴한다. 각각의 질의는 시맨틱 레이어에 저장된다(OBJECTID를 리턴하기 위함). 마지막 예를 이용하기 위해, 사용자가 News.All 에이전트를 불러낼 때, 브라우저는 에이전시 XML 웹 서비스 상에 질의 프로세서를 호출한다. 그리고, 질의 프로세서는 질의를 불러내어 이하와 같은 'News Article' 오브젝트 타입으로 필터링할 것이다:

SELECT * FROM NEWS WHERE OBJECTID IN (SELECT OBJECTID FROM NEWS)

이는 뉴스 구성체계에 대한 모든 필드를 리턴한다. 브라우저는(프리젠터를 통해) 에이전트 스킨 또는 사용자 특정 스킨(에이전트 스킨을 무효화시킬 것임)에 대하여 XSLT(또는 Flash MX나 ActionScript 등의 프리젠테이션 툴)를 사용하여 정보를 표시한다.

질의 가상 파라미터(Query Virtual Parameters). 에이전트 질의가 바람직하게는 특별 가상 파라미터를 포함한다. 전형전인 예에서는 '%USERNAME%을 포함할 것이다. 본 예에서는, 질의를 불러내기 이전에 시맨틱 질의 프로세서(SQP)가 가상 파라미터를 실제 인자(argument)로 해석한다. AgentPeople.MyTeam.All은 이하의 SQL 질의로 구성된다:

SELECT * FROM USERS WHERE Division IN(SELECT Division FROM USERS WHERE Name LIKE %USERNAME%)

본 예에서, 에이전트 명칭은 에이전트가 임의의 사용자에게 적용할 수 있지만 "MyTeam"을 포함한다. %USERNAME% 변수는 SQP에 의해 실제 호출 사용자의 명칭으로 해석된다. SQL은 이하와 같이 해석된다:

SELECT * FROM USERS WHERE Division IN(SELECT Division FROM USERS WHERE Name LIKE JohnDoe)

본 예에서, JohnDoe는 호출자의 사용자 명칭인 것으로 가정된다.

간단한 에이전트 검색(Simple Agent Search). 각각의 에이전트는 간단한 검색 기능성을 지원한다. 바람직한 실시예에서, 사용자는 정보 에이전트에서 스마트 에이전트 상에 우측-클릭을 하여 "Search"를 칠 수 있다. 이는 사용자가 검색 문자를 입력하는 대화 상자를 불러온다. 이는 "nervana:contains" 등 관련 술어를 갖는 적절한 SQML을 생성한다. 본 발명은 "Create Smart Agent" 마법사를 거쳐 "contains text" 술어(선택적으로 동일한 결과를 달성함)을 선택하지 않고도 사용자가 에이전트를 검색하는(그리고 그곳에서 스마트 에이전트를 생성하는) 간단하고 빠른 방식을 제공한다.

에이전시 에이전트 뷰(Agency Agent Views). 본 발명의 선택적인 실시예는 에이전시 에이전트 뷰를 포함한다. 에이전시 에이전트 뷰는 소정의 기준에 기초하여 에이전트를 필터링하는 질의다. 예를 들어, "Documents"라는 에이전트 뷰는 문서 시맨틱 분류(document semantic class)의 오브젝트를 관리하는 에이전트만을 리턴한다. "Reuters News"라는 에이전트는 저작자가 "Reuters"인 새로운 오브젝트를 관리하는 에이전트의 리스트를 리턴한다. 에이전시 에이전트 뷰는 사용자에게 에이전트를 통해 네비게이트하는 용이한 방식을 제공하기 위해 중요하다. 에이전시 매니저는 에이전트 뷰를 생성 및 삭제할 수 있다.

에이전트 공개 및 공유(Agent Publishing and Sharing). 바람직한 실시예는 에이전트가 공개 및 공유되는 것을 용이하게 한다. 이는 바람직하게는 시맨틱 환경을 최근 기호 에이전트들, 그들의 구성체계, 그들의 SQML 버퍼 등을 포함하는 XML 문서로 시리얼화하는 것과 문서를 공개 지점으로 공개하는 것에 의해 구현된다. 이러한 XML 문서는 로컬(사용자-생성의) 에이전트들의 전파 및 공유를 촉진하기 위해 동료, 친구들에게 e-메일로 보내질 수도 있다. 이는 오늘날의 웹 페이지들이 공개되는 방식 및 웹 URLs와 링크들이 e-메일을 통해 링크 및 첨부물을 보냄으로써 공유되는 방식과 유사하다.

2. 지식 통합 서버(KNOWLEDGE INTEGRATION SERVER)

지식 통합 서버(KIS; 50)는 시스템(10)의 서버측 심장부이다. KIS는 다수의 다양한 소스들로부터의 데이터를 시맨틱 네트워크로 시맨틱하게 통합하고 네트워크로의 액세스를 제공하는 에이전트를 호스트한다. KIS는 또한 시맨틱 XML 웹 서비스를 호스트하여 클라이언트에게 에이전트를 통한 시맨틱 네트워크로의 액세스를 제공한다. 사용자에게, KIS 인스톨은 에이전스로 보여질 수 있다. KIS가 바람직하게는 이하의 특성으로 초기화된다:

. Agency Name. 에이전시의 명칭(예컨데 "ABC" 등)

. Agency Friendly Name. 에이전시의 풀 네임(예컨데 "ABC Corporation" 등)

. Agency Description. 에이전시의 설명

. Agency System User Name. 에이전시의 사용자 명칭. 각각의 에이전시는 인스톨된 기업(또는 웹 사이트)의 디렉토리 상에 사용자에 의해 표현된다. 시스템 사용자 명칭은 시스템 인박스를 호스트하기 위해 사용된다(이를 통해 사용자들이 에이전시에 문서, e-메일 및 주석을 공개함). 인증을 위해, 에이전시는 시스템 사 용자 어카운트로의 액세스를 갖는 서버 상에 인스톨되어야 한다.

. Agency Authentication Support Level. 에이전시가 사용자 인증을 지원 또는 요구하는지 여부를 나타냄. 에이전시는 인증을 지원하지 않도록(모든 사용자에게 오픈되고 사용자 상태를 갖지 않는 경우), 지원은 하지만 요구는 하지 않도록, 및 인증을 요구하도록 구성될 수 있다(바람직하게는 인증 암호화 타임을 나타내는 경우임).

. Agency User Directory Type. 이는 에이전시가 사용자를 인증하는 사용자 디렉토리의 타입으로 에이전시는 이로부터 사용자 정보를 얻는다. 예를 들어, 이는 Windows 2000 Active Directory 상의 LDAP 디렉토리, Microsoft Exchange 2000 User Directory, 또는 Lotus Notes User Directory 등 일 수 있다.

. Agency User Directory Name. 이는 에이전시 사용자 디렉토리의 서버 명칭을 나타낸다(Microsoft Exchange 2000 서버 명칭 등).

. Agency User Domain Name. 이는 인증 목적을 위한 사용자 도메인의 명칭을 나타낸다. 이 필드는 옵션으로 에이전시가 인증을 지원하는 경우에만 포함된다.

. Agency User Group Name. 이는 인증 목적을 위한 사용자 그룹의 명칭을 나타낸다. 예를 들어, 에이전시는 "US Employees"라는 도메인 명칭과 "Marketing"이라는 그룹 명칭으로 초기화 될 수 있다. 이러한 경우, 에이전시는 먼저 사용자 명칭을 체크하여 사용자가 사용자 그룹의 멤버인지 확인하고, 사용자 디렉토리 타입에 의해 지시되는 사용자 디렉토리 인증자에게 인증 요청을 보낸다. 호출한 사 용자가 사용자 그룹의 멤버가 아니면, 인증 요청은 거부된다. 이 필드는 에이전시가 인증을 지원하는 경우에만 유효하다.

. Data Store Connection Name. 이는 데이터베이스 스토어로의 접속 명칭을 나타낸다. 이는 가령 Windows 상의 ODBC 접속 명칭(또는 JDBC 명칭 등)으로 표현될 수 있다. KIS는 접속 명칭에 의해 참조되는 데이터베이스를 사용하여 그 테이블을 저장, 업데이트 및 유지할 것이다.

. Dynamic Properties Evaluation. 에이전시 XML 웹 서비스가 바람직하게는 서버가 현재 지원하는 또는 "이해하는(understands)" 시맨틱 도메인 경로의 리스트 등 다이나믹 특성을 리턴하는 방법을 드러낸다. 이는 사용자가 그들의 지원되는 시맨틱 경로 또는 온톨로지/분류학(taxonomies)을 이용하여 클라이언트 상에 에이전시를 브라우즈할 수 있게 한다.

도 24에서 보여지듯이, KIS(50)가 바람직하게는 이하의 주요 구성 요소들을 포함한다: 시맨틱 네트워크(52), 시맨틱 데이터 수집기(gatherer)(54), 시맨틱 네트워크 일치 체커(56), 추론 엔진(58), 시맨틱 질의 프로세서(60), 자연어 분석기(parser)(62), e-메일 지식 에이전트(64) 및 지식 도메인 매니저(66).

a. 시맨틱 네트워크(Semantic Network)

시맨틱 네트워크는 KIS의 핵심적인 데이터 구성 요소이다. 시맨틱 네트워크는 본 발명의 규정된 구성체계들의 오브젝트들을 모두 데이터베이스 테이블을 통해 시맨틱 방식으로 링크한다. 시맨틱 네트워크는 구성체계 및 시맨틱 메타데이터 스토어(SMS)를 구성한다. 시맨틱 네트워크가 바람직하게는 이하 2개의 데이터 구성 체계로 구성된다: Objects 및 SemanticLinks. 부가적인 데이터 구성체계가 시스템 요건 및 기업 요구에 기초하여 포함될 수 있다. SMS가 바람직하게는 데이터베이스 테이블을 통해 모든 시맨틱 데이터가 저장되고 업데이트되는 표준 데이터베이스(SQL 서버, Oracl, DB2 등)이다. 상기SMS는, 바람직하게는, 각각의 프라이머리 오브젝트타입(아래 기술됨)에 대한 테이블들을 포함한다.

예를 들어, 기업 상황으로 지향되는 샘플 시맨틱 네트워크가 도 25를 참조하여 도시되는데, 본 발명의 비즈니스 사용자와 지식 검색, 관리, 전달 및 프리젠테이션의 여러 소스 및 결과 사이의 관계가 도시하고 있다.

오브젝트(Objects). 오브젝트 테이블은 시맨틱 네트워크의 모든 오브젝트를 포함한다. "Object"는 모든 시맨틱 오브젝트 타입이 유도될 "base class"로서 생각될 수 있다. 오브젝트 타입의 바람직한 구성체계가 도 26에 도시된다. ObjectID는 시맨틱 네트워크의 오브젝트를 태그하는 고유한 식별자이다. 시스템의 모든 오브젝트는 오브젝트 구성체계의 확장인 구성체계를 가질 것이다. 선택적으로, 시맨틱 오브젝트 타입(문서, e-메일, 이벤트 등)은 ObjectID 필드만을 가질 것이다. 질의가 불려질 때, 질의 프로세서는 오브젝트 테이블 및 특정 시맨틱 테이블로부터 정보를 모아 최종 결과를 형성할 수 있다. 전자의 어프로치(각각의 구성체계가 오브젝트 구성체계의 확장이 되도록 함)는 조인이 회피되기 때문에 보다 우수한 런타임 성능을 가져온다. 그러나, 후자의 어프로치는, 계산적으로 보다 비용이 들지만, 스토리지 낭비가 덜하다. ObjetTypeID가 바람직하게는 "documents/documents"; "documents/analyst briefs"; 및 "events/meetings" 등 오 브젝트 타입의 계층을 설명하는 스트링으로 해석되는 숫자이다.

SourceID는 오브젝트가 모아졌던 시맨틱 데이터 어댑터(SDA)에 대한 식별자를 참조한다. 시맨틱 데이터 수집기(SDG)는 이 정보를 사용하여 오브젝트가 검색되었던 SDA로부터 상태 정보를 요청함으로써 오브젝트가 여전히 존재하는지 여부를 주기적으로 체크한다.

SemanticLinks. SMS가 바람직하게는 시맨틱 링크를 저장할 SemanticLinks 구성체계(데이터베이스 테이블에 대응함)를 포함한다. 이들 링크는 SMS의 다른 데이터 테이블의 오브젝트들에 주석을 달 것이고, 바람직하게는 시맨틱 네트워크에 대한 데이터 모델을 구성할 것이다. 각각의 시맨틱 링크는 시맨틱 링크 ID를 가질 것이다. 시맨틱 링크 테이블이 바람직하게는 도 27을 참조하여 도시된 필드 명칭 및 타입을 포함한다. SubjectID 및 SubjectTypeID는 그로부터 링크되는(linked from) 오브젝트 ID 및 오젝트 타입 ID이다. ObjectID 및 ObjectTypeID는 그로 링크되는(linked to) 오브젝트 ID 및 오브젝트 타입 ID이다. LinkScore가 바람직하게는 0 내지 100이고, 링크의 시맨틱 강도를 확률로서 표현한다. 이들 필드는 예시적인 뿐인 것으로; 보다 많은 술어는 시맨틱 링크에 대한 사용자의 소망 뿐만 아니라 특정 오브젝트 타입에 기초하여 고려된다. 본 발명의 바람직한 실시예는 도 28에 도시된 술어 타입 ID를 제공한다. 본 발명은 더욱 많은 술어 타입 ID를 고려한다.

예를 들어, "Steve reports to Patrcik"이라는 시맨틱 링크가, 사용자 테이블의 Steve의 ID에 대응하는 서브젝트 ID, PREDICATETYPEID_REPORTSTO의 술어 타입 (이하 테이블 참조), 사용자 테이블의 Patrick의 오브젝트, 100인 링크 스코어("truth"라는 것과 링크가 개연성이 없다는 것을 나타냄) 및 링크에게 자격을 주는 참조 일자와 함께 표현될 것이다.

KIS는 각각의 오브젝트 타입에 대하여 데이터베이스 테이블을 생성, 업데이트 및 유지한다(SMS를 통함). 이하는 주요하고 유도된 오브젝트 타입의 바람직한 그러나 이에 제한되는 것은 아닌 리스트를 나타낸다:

. Person

. User

. Customer

. Category

. Document

. Analyst Brief

. Analyst Report

. Case Study

. White Paper

. Company Profile

. E-Book

. E-Magazine

. Email Message

. Email Annotation

. Email News Posting

. Email Distribution List

. Email Public Folder

. Email Public Folder Newsgroup

. News Article

. Event

. Meeting

. Corporate Event

. Industry Event

. TV Event

. Radio Event

. Print Media Event

. Online Meeting

. Arts and Entertainment Event

. Online Course

. Media

. Book

. Magazine

. Multimedia

. Online Broadcast

. Online Conference

오브젝트 타입들이 바람직하게는 계층적 경로로서 표현된다. 경로는 예를 들어 "event/meetings"가 "qualified Meetings"로 확장되어 "events/meetings/company meetings"가 되듯이 확장될 수 있다. 구성체계 모델은 무한하게 확장 및 구성될 수 있다.

가상 정보 오브젝트 타입(Virtual Information Object Types). 가상 정보 오브젝트 타입은 분명한 오브젝트 타입에 매핑되지 않는 오브젝트 타입으로, 사용자들에게는 여전히 시맨틱하게 관심의 대상이다. 예를 들어, "Customer Email" 오브젝트 타입이 있고, 이는 "Email" 오브젝트 타입으로부터 유도한다. 이러한 오브젝트 타입은 분명한 구성체계를 갖지 않아 결과적으로 KIS 상의 SMS에 분명한 테이블을 갖지 않는다는 점에서 "virtual"이다. 오히려, "Email" 오브젝트 타입으로부터 유도하기 때문에 SMS 상에 "Email" 테이블을 이용한다. 분명한 오브젝트 타입은 아니지만, 사용자들은 실제로 분명하였었던 것처럼 "Customer Email에 대한 브라우징 및 검색에 관심을 둘 것이다.

바람직한 실시예에서, 가상 오브젝트 타입은 SMS 상의 적절한 테이블에 메타데이터를 저장함으로써 구현된다(본 경우, 오브젝트 타입이 "Email"로부터 유도되기 때문에 "Email" 테이블임). 그러나, 오브젝트 타입에 대한 질의의 해석은 분명한 오브젝트 타입에 대한 정규 질의와는 다르게 달성된다. 서버 SQP가 가상 정보 오브젝트 타입("Customer Email" 등)에 대한 시맨틱 질의 요청(XML 웹 서비스를 통함)을 수신하면, 함께 오브젝트 타입을 형성하는 테이블들을 연결하여 상기 요청을 해석한다. 예를 들어, 바람직한 실시예에서, "Customer Email"의 경우, 서버는 이하와 같이 SQL 서브-질의로 질의를 해석할 것이다:

SELECT OBJECTID FROM EMAIL WHERE OBJECTID IN (SELECT OBJECTID FROM CUSTOMERS WHERE EMAILADDRESS IN (SELECT EMAILADDRESS FROM EMAIL)

이러한 질의는 "Select all objects from the Email table that have an email address value that is also in the Customers table."에 대응한다. 이는 "Customer Email"이 고객에 의해 또는 고객에게 보내지는 e-메일을 참조한다는 것을 가정한다. 가상 오브젝트 타입의 다른 정의도 또한 가능하고, 질의 해석이 바람직하게는 상기 정의와 일관된다. SQP가 바람직하게는 이러한 서브-질의를 "Customer Email"에 대한 모든 질의에 적용한다. 이러한 서브-질의는 본질적으로 고객으로부터의 e-메일 메시지에 대한 e-메일 테이블을 필터링한다. 이는 실제로는 존재하지 않는 경우 "Customer Email" 테이블이 존재한다는 환상으로 사용자에게 원하는 결과를 리턴한다.

본 발명은 각각의 오브젝트 타입과 관련된 다양한 구성체계를 고려한다. 기타 구성체계들이 본 발명에 호환 적용성을 갖는 개발에 존재할 수 있다. 예를 들어, "Document" 구성체계가 Dublin Core 구성체계(http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2413.html) 및 기타 산업 표준 구성체계로부터의 필드와 함께 확장될 수 있다. 다른 실시예에서, "News Article" 구성체계는 NewsML 구성체계(http://www.newsml.org)의 확장일 수 있다. 예시적으로만, 본 발명에 따라 이루어진 바람직한 사용자 오브젝트 구성체계가 도 29에 도시된다. 모든 구성체계 가 바람직하게는 오브젝트 구성체계의 필드와 동일한 서브셋을 갖는다. 사용자(개인) 오브젝트 구성체계와 바람직하게 관련된 MailingAddressTypeID가 도 30에 도시된다.

예시적으로만, 본 발명에 따라 이루어진 바람직한 카테고리 오브젝트 구성체계가 도 31에 도시된다.

예시적으로만, 본 발명에 따라 이루어진 바람직한 문서 오브젝트 구성체계가 도 32에 도시된다. "DocumentCategory" 필드는 문서와 함께 태그되는 소유자 카테고리(문서 데이터 소스에 의함)를 지칭하는 것으로, KIS 자체에 의해 관리되는 시맨틱 카테고리를 지칭하는 것은 아니다. "DocumentFormatTypeId" 필드는 문서의 타입을 지칭한다. 바람직한 실시예의 인쇄 매체 타입 ID가 도 33에 도시되고, 바람직한 FORMATTYPEID는 도 34에 도시된다.

예시적으로만, 본 발명에 따라 이루어진 바람직한 e-메일 메시지 리스트 오브젝트 구성체계가 도 35에 도시된다. e-메일 우선순위가 바람직하게는 하위, 중간 및 상위 우선순위에 대응하는 0, 1 또는 2이다. EmailTypeID가 바람직하게는 EMAILTYPEID_EMAIL, EMAILTYPEID_NEWSPOSTING 및 EMAILTYPEID_EMAILANNOTATION을 포함한다(값 1, 2 및 3). 본 발명의 바람직한 실시예의 e-메일 배포 리스트 및 e-메일 공개 폴더 오브젝트 구성체계를 나타내는 예시적인 테이블이 도 36 및 37에 도시된다. 바람직한 실시예에서, PublicFolderTypeID는 도 38에 도시된 것들을 포함한다.

예시적으로만, 본 발명에 따라 이루어진 바람직한 이벤트 오브젝트 구성체계 메시지 리스트 오브젝트 구성체계가 도 39에 도시된다. 도 40은 본 발명의 바람직한 실시예의 이벤트 타입을 나타낸다.

예시적으로만, 본 발명에 따라 이루어진 바람직한 매체 오브젝트 구성체계 메시지 리스트 오브젝트 구성체계가 도 41에 도시된다. 도 42는 본 발명의 바람직한 실시예의 매체 타입을 나타낸다.

예시적으로만, 도 43-45는 본 발명의 바람직한 실시예에서 오브젝트가 카테고리화되고 이용되는 방식을 나타내는 부가적인 샘플을 도시한다. 도 43은 루프 오브젝트 콘테이너 타입을 나타낸다. 도 44는 자격이 주어진 오브젝트 타입에 대한 계층 구조를 나타낸다. 도 45는 네이티브 콘테이너 오브젝트 타입 술어의 샘플을 나타낸다. Person 및 Customer 타입을 제외한 모든 타입이 바람직하게는 루트 타입 "All Infomation"으로부터 모든 술어를 물려 받는다. 본 발명은 예를 들어: All; Breaking News; Categorization; Author; Annotation; Definite Links; Probabilistic Links; 및 Popular를 포함하는 네이티브 콘테이너 오브젝트 타입 술어 템플레이트를 제공한다.

b. 시맨틱 데이터 수집기(Semantic Data Gather)

바람직한 실시예에서, 시맨틱 데이터 수집기(SDG)는 SMS를 통해 시맨틱 네트워크의 엔트리들을 부가, 제거 및 업데이트를 담당한다. SDG는 XML 웹 서비스 참조의 리스트를 구성한다. 이들은 정보 소스 요약 레이어(ISAL)형성한다. 이들 참조 각각은 데이터 소스 어댑터(DSA)를 통해 데이터를 모으도록 초기화된다. 데이터 소스 어댑터는 주어진 오브젝트 타입에 대한 로컬 또는 원격 시맨틱 데이터 소 스로부터 정보를 모으는 XML 웹 서비스이다. 그리고, 이는 데이터 소스에서의 오브젝트 엔트리에 대응하는 XML을 리턴한다. 모든 DSA가 바람직하게는 그를 통해 SDG가 XML 데이터를 모으는 동일한 인터페이스를 지원한다. 이 인터페이스는 이하와 같은 방법을 포함한다:

. 주어진 시작 및 종료 인덱스용 오브젝트(오브젝트 0 내지 49 등)에 대하여 XML 메타데이터를 검색.

. 특정 일자/시간(DSA의 시계 상으로) 이후로 부가되거나 삭제된 오브젝트가 있는지 여부를 체크.

. 특정 일자/시간(DSA의 시계 상으로) 이후로 부가되거나 삭제된 오브젝트용 XML 메타데이터 패치.

. 오브젝트용(인자(argument)로서 통과된) XML 메타데이터를 검사함으로써 시맨틱 데이터 소스에 오브젝트가 여전히 존재하는지 여부를 체크.

DSA XML 웹 서비스에 대한 각각의 호출이 안정성이 없을 것이라면, 바람직하게는 명령 파라미터를 갖는 스트링을 통해, API는 요청에 자격을 주는 정보를 포함할 것이다. 예를 들어, e-메일 인박스에 대한 DSA는 그의 인박스가 모여져야 하는 사용자의 명칭 등의 파라미터를 포함한다. 웹 사이트 또는 문서에 대한 DSA는 서서히 다가가게 되는 URL 또는 디렉토리 경로에 관한 정보를 포함하여야 한다.

각각의 DSA는 그 오브젝트 타입에 대한 구성체계에서 정보를 검색할 것이 요구된다. DSA는 특정 오브젝트 타입에 대하여 구현되어야 하기 때문에, SDG는 DSA에 수집신호를 요청할 때 상기 오브젝트 타입용 구성체계에 대한 XML을 기대할 것 이다.

SDG는 SMS(시맨틱 네트워크)의 모든 데이터베이스 테이블의 통합 및 일관성을 유지하는 것을 책임진다. 본 실시예에서, SDG는 또한 시맨틱 네트워크 매니저(SNM)로서 지칭되기도 한다. 데이터베이스 테이블이 바람직하게는 리던던트 또는 스테일(stale) 엔트리를 포함하지 않는다. SDG는 잘 알려진 구성체계를 갖는 오브젝트를 검색하기 때문에, 오브젝트 타입 각각의 시맨틱이 이해되고, 따라서 SDG는 테이블의 일관성을 유지한다. 예를 들어, SDG가 바람직하게는 DOCUMENTS 테이블에 리던던트 문서 XML 메타데이터를 부가하지 않는다. SDG는 문서의 시맨틱을 사용하여 리던던시를 체크한다. 바람직한 실시예에서 이는 저작자 명칭, 생성 일자/시간, 파일 경로 등을 비교하여 달성된다. SDG는 또한 기타 테이블(EVENTS, CUSTOMERS, NEWS 등)에 대하여도 이러한 체크를 수행한다. 예를 들어, SDG는 제목, 위치 및 일자/시간을 검사하여 이벤트에 대한 리던던시 체크를 수행한다. 따라서, 기타 테이블들이 유지된다. SDG는 또한 변경된 데이터베이스 테이블의 오브젝트를 업데이트한다.

또한 SDG가 바람직하게는 데이터베이스 테이블을 비우는 것을 담당한다. SDG는 주기적으로 DSA를 질의하여 DSA에 의해 관리되는 각각의 테이블의 모든 오브젝트가 여전히 존재하는지 여부를 결정한다. 예를 들어, 문서를 검색하는 DSA에 대하여, SDG는 XML 메타데이터를 DSA 웹 서비스로 전달하고, 오브젝트가 여전히 존재하는지 여부를 질의할 것이다. DSA는 문서에 대한 URL을 오픈하려고 시도한다. 문서가 더 이상 존재하지 않으면, DSA는 이를 SDG에 나타낼 것이다. SDG가 아니라 개별 DSA가 특정 데이터 소스에 대한 보안을 회피하기 위하여 오브젝트 유효성을 책임진다. 예를 들어, 로컬 리소스로의 원격 액세스를 막는 데이터 소스 제한이 있을 수 있다. 이러한 경우, DSA XML 웹 서비스(바람직하게는 데이터 소스에 비하여 로컬로만 동작함)만이 데이터 소스에 대한 액세스를 가질 것이다. 선택적으로, 몇몇 DSA가 SDG 및 기타 서버 구성 요소 쪽으로 에이전시 서버 상에서 동작하고, 그들의 데이터를 원격으로 검색한다.

DSA 조작 오브젝트 유효화를 갖는다는 것은 또한 오브젝트가 여전히 존재하는지 여부를 체크하기 위해 각각의 데이터 소스를 오픈하는 방식의 상세한 것을 SDG가 아는 것을 DSA가 방지한다는 점에서 부가적인 효율 및 보안성을 제공한다. DSA는 이것을 알기 때문에(데이터 소스로부터 XML 데이터를 검색하고, 따라서 데이터 소스에 대하여 특정한 코드를 갖기 때문에), DSA가 이러한 태스크를 조작하는 것이 보다 적절하다.

SDG가 바람직하게는 DSA XML 웹 서비스 URL로 향할 수집기 리스트(gather list)를 유지한다. KIS 매니저는 SDG 수집기 리스트로부터 DSA 엔트리들을 부가, 삭제 및 업데이트할 수 있다. 각각의 수집기 리스트 엔트리가 바람직하게는 이하의 것으로 구성된다:

1. DSA의 명칭 및 XML 웹 서비스 레퍼런스. 이는 본질적으로 데이터 소스, 오브젝트 타입 및 DSA(WSDL 웹 서비스 URL을 통하는 등)를 구현하는 XML 웹 서비스로의 참조의 조합을 참조할 것이다.

예를 들어 이하의 것을 포함한다:

a. Microsoft Exchange 2000 Email DSA. 이 DSA는 Microsoft Exchange 2000 인박스 또는 공개 폴더로부터 e-메일 XML 메타데이터를 수집한다.

b. Microsoft Exchange 2000 Calendar DSA. 이 DSA는 Microsoft Exchange 2000 캘린더로부터 이벤트 XML 메타데이터를 수집한다.

c. Microsoft Exchange 2000 Users DSA. 이 DSA는 Microsoft Exchange 2000 디렉토리로부터 사용자/사람들 XML 메타데이터를 수집한다.

d. Microsoft Exchange 2000 Email Distribution List DSA. 이 DSA는 Microsoft Exchange 2000 디렉토리로부터 e-메일 배포 리스트 메타데이터를 수집한다.

e. Lotus Notes Inbox. 이 DSA는 Lotus Notes 인박스 또는 공개 폴더로부터 e-메일 XML 메타데이터를 수집한다.

f. Siebel CRM Database. 이 DSA는 Siebel CRM 시스템으로부터 고객 XML 메타데이터를 수집한다.

g. Web site. 이 DSA는 웹 사이트로부터 문서 XML 메타데이터를 수집한다.

h. File Directory or Share. 이 DSA는 파일 디렉토리 또는 공유로부터 문서 XML 메타데이터를 수집한다.

i. Saba E-Learning LMS Repository. 이 DSA는 Saba Learning Management System(LMS) 저장소로부터 E-Learning XML 메타데이터를 수집한다.

j. Microsoft Sharepoint Document DSA. 이 DSA는 Microsoft Sharepoint 서버 워크스페이스로부터 문서 XML 메타데이터를 수집한다.

k. Reuters News Repository. 이 DSA는 Reuters 뉴스 기사 저장소로부터 신규 기사 XML 메타데이터를 수집한다.

2. DSA 수집기 엔트리의 상세.

3. DSA에 대한 초기화 정보를 나타내는 스트링.

4. 수집기 스케쥴-이는 XML 메타데이타를 모으기 위해 SDG가 얼마나 자주 DSA에 서서히 접근하는 가를 나타낸다.

바람직한 실시예에서, 에이전시는 사용자 디렉토리 도메인 및 그룹 명칭으로 초기화된다. 이 경우, SDG가 바람직하게는 사용자 디렉토리 DSA에 대한 수집기 리스트 엔트리를 자동적으로 입력한다. 예를 들어, 에이전시가 도메인 명칭이 "Foo"이고 어드레스 책 또는 그룹 명칭이 "Everyone"인 Exchange 2000 User Directory로 구성된다면, SDG는 Exchange 2000 Users DSA에 의한 수집기 리스트 엔트리를 생성한다(이들 파라미터로 초기화됨). 선택적으로, 에이전시는 임의의 e-메일 어플리케이션 서버(Microsoft Exchange 또는 Lotus Notes)로부터 그 사용자 디렉토리를 얻도록 구성될 수 있다. SDG는 시스템 사용자에 대한 Email Inbox 및 Calendar DSA(및, 이하 설명되는 e-메일 지식 에이전트)로 수집기 리스트 엔트리를 초기화한다. 이들 3개의 수집기 리스트 엔트리 DSA(Users, Inbox 및 Calendar)는 디폴트에 의해 초기화된다. 인박스가 바람직하게는 에이전시 e-메일 게시 및 주석을 저장하도록 사용되고, 캘린더 Dsa는 사용자에 의해 에이전시로 배달된 이벤트를 저장하도록 사용된다. 기타 커스텀 DSA가 에이전시 매니저에 의해 부가될 수 있다.

SDG는 또한 오브젝트가 데이터 소스에 또는 데이터 소스로부터 부가되거나 삭제되었다는 것을 SDA가 보고한 최종 시간의 추적을 유지한다. 이러한 시간/일자 정보가 바람직하게는 SDA의 클럭에 기초한다. SDA가 새로운 또는 삭제된 데이터가 존재한다는 것을 보고할 때마다, SDG는 SDA에 대한 엔트리에 시간/일자 정보를 업데이트하고, SDA에 새롭거나 삭제된 모든 정보를 수집한다. 그리고, SDG는 데이터베이스 테이블을 업데이트할 것이다.

SDG가 바람직하게는 SDA로부터 수신한 XML 정보를 본 발명의 시맨틱 네트워크에 매핑시킨다. SDG는 데이터베이스 테이블의 모든 XML 메타데이타를 SMS에 저장한다. 또한, SDG는 SDA로부터 수신한 XML을 해석하고, 필요한 곳에서, 시맨틱 링크를 특정 XML 필드로 매핑시킨다. SDG는 XML이 오브젝트를 함께 "links"하는 정보를 포함하는 경우 시맨틱 링크를 부가하거나 업데이트한다. 예를 들어, e-메일 오브젝트에 대한 구성체계가 바람직하게는 "From", "To", "Cc", "Bcc", 및 "Attachments"를 포함하는 필드를 포함한다. "From", "To", "Cc" 및 "Bcc" 컬럼의 경우, XML의 필드는 e-메일 어드레스(";", "," 또는 스페이스 등의 구획 문자로 구별됨)를 참조한다. 이러한 로(raw) XML은 기타 컬럼들과 함께 EMAIL 데이터베이스 테이블에 저장된다. 또한, SDG는 e-메일 오브젝트의 필드를 해석하여, 이들 필드의 콘텐츠에 의해 식별되는 기타 오브젝트에 시맨틱 링크를 부가한다. 예를 들어, "to" 필드가 "john@foo.com"을 포함하고 "attachments" 필드가 "c:/foo.doc, c:/bar.doc"라는 스트링을 포함하면, SDG는 e-메일을 이하와 같이 처리할 것이다:

1. USERS 테이블에서 e-메일 어드레스가 "john@foo.com"인 임의의 오브젝트 탐색. 또한, FROM, TO, CC 및 BCC 필드에서 e-메일 어드레스를 갖는 기타 USER 오브젝트에 대한 검색.

2. 오브젝트가 발견되면, 서브젝트 및 적절한 술어 타입 id로서 e-메일 오브젝트 id를 갖는 SEMANTICLINKS 테이블에 시맨틱 링크 엔트리를 부가. 이경우, PREDICATETYPEID_CREATOR라는 술어는 e-메일 메시지의 작성자를 참조하는 것이다. PREDICATETYPEID_SENTTO라는 술어는 e-메일 오브젝트와 e-메일 XML 메타데이터에서 "to" 필드의 콘텐츠에 의해 참조되는 USER 오브젝트를 링크시키기 위해 사용된다. PREDICATETUPEID_COPIEDTO 및 PREDICATETYPEID_BLINDCOPIEDTO라는 술어는 "cc" 및 "bcc" 필드에서의 오브젝트를 유사한 형태로 링키시키기 위해 사용된다.

첨부(attachment)의 경우, SDG는 첨부된 문서에 대한 XML 메타데이터를 추출한다. 파일 경로를 갖는 XML 오브젝트가 SMS(또는, 달리 말하면, 시맨틱 네트워크)에 존재하면, SDG는 메타데이터를 업데이트할 것이다. XML 오브젝트가 이미 존재하지 않으면, SDG는 XML 메타데이터를 갖는 새로운 문서 오브젝트를 생성한다. SDG는 e-메일 오브젝트 ID를 갖는 SEMANTICLINKS에 e-메일 오브젝트 ID를 서브젝트로하고, 새로운 문서의 오브젝트 ID를 서브젝트로 하며, PREDICATETYPEID_ATTACHDTO 술어인 엔트리를 부가할 것이다. 이는 사용자가 e-메일 메시지로부터 그 첨부물까지 네비게이트하고, 예를 들어 스마트 렌즈(이하 논의됨)와 같은 시맨틱 툴을 사용하여 시맨틱 네트워크를 계속 브라우즈하기 위한 관점으로 첨부물을 사용할 수 있게 한다.

SDG는 XML 필드의 엔트리와 일치하는 사용자 오브젝트를 찾지 못하는 경우 오부젝트를 생성하지 않는다. 바람직하게는, 사용자가 에이전시에 수동으로 부가되는 경우 SDG가 디렉토리 SDA로부터 정보를 모은다. 에이전시 매니저가 바람직하게는 에이전시 특성으로 사용자 그룹을 통해 에이전시에 사용자를 부가한다.

이하는 시맨틱 네트워크에 로(raw) e-메일 XML 메타데이터를 매핑시키는 예를 나타낸다.

＜email from="john@foo.com"

to="nosa@nervana.net"

cc="steve@nervana.net"

bcc="patrick@nervana.net"

subject="Meeting this Friday"

body="Let us meet on Friday at 2 pm"

attachments="c:/foo.doc; c:/bar.htm"＞

＜/email＞

이상의 내용은 도 46에 도시된 오브젝트 그래프로 변환된다.

c. 시맨틱 네트워크 일관성 체커(Semantic Network Consistency Checker)

시맨틱 네트워크 일관성 체커(CC)는 SDG에 의해 수행되는 일관성 체킹을 보충한다. 상술된 바와 같이, SDG는 시맨틱 네트워크로의 리던던트 엔트리의 부가(여러 데이터 소스로부터)를 배제함으로써 데이터베이스 테이블의 통합을 유지한다. CC는 또한 OBJECTS 및 SEMANTICLINKS 테이블의 일관성을 보장한다. CC는 각각의 오브젝트가 본래 테이블에 존재한다는 것을 보장하기 위해 주기적으로 OBJECTS 테 이블을 체크한다(바람직하게는 OBJECTID 필드 값을 체크함으로써). 예를 들어, OBJECTS 테이블의 문서 오브젝트 엔트리가 바람직하게는 DOCUMENTS 테이블에 존재한다(동일한 오브젝트 ID를 갖고). CC는 본래 테이블(DOCUMENTS, EVENTS, EMAIL 등)에 대응하는 오브젝트 등이 없이도 OBJECTS 테이블의 임의의 오브젝트를 제거한다.

CC는 또한 SEMANTICLINKS 테이블의 일관성을 유지를 담당한다. 이 테이블의 시맨틱이 바람직하게는 다음과 같다: 시맨틱 링크는 그 서브젝트("linked from" 또는 "linked to")가 존재하지 않으면 존재할 수 없다. 이를 나타내기 위해, 오브젝트 A가 술어 P를 갖고 오브젝트 B에 링크하고, A 또는 B가 삭제되면, 그 링크가 삭제된다. CC는 주기적으로 SEMANTICLINKS 테이블을 체크한다. 서브젝트 또는 오브젝트 중 어느 하나가 삭제되었다면, CC는 시맨틱 링크 엔트리를 삭제한다.

일관성 체크는 KIS 자체이서의 코드로 또는 데이터베이스 레벨의 저장된 프로시져나 강요로서 구현되어도 좋다.

d. 추론 엔진(Inference Engine)

추론 엔진은 시맨틱 네트워크에 시맨틱 링크의 부가하는 것을 담당한다. 추론 엔진은 추론 규칙을 채택하며, 이는 발견적 교수법(heuristics) 세트를 포함하여, 진행중인 시맨틱 액티비티에 기초하여 시맨틱 링크를 부가한다. 추론 엔진이 바람직학는 시맨틱 링크 삭제가 허용된다. 결정 에이전트(이하 설명됨)는 추론 엔진을 사용하여 지식-작업자가 결정을 이루는 것을 돕는다.

추론 엔진은 시맨틱 네트워크를 탐사하고 확률론적 추론에 기초하는 새로운 시맨틱 링크를 부가함으로써 동작한다. 예를 들어, 추론 엔진이 바람직하게는 시맨틱 네트워크를 모니터하고 e-메일이 전송되는 방식에서의 패턴, 전송된 e-메일의 타입 및 누가 전송하였나 등을 관측한다. 추론 엔진은 이러한 정보로부터 추론 엔진의 모니터링 범위 내에서 여러 요지(subject matter) 카테고리에 관련되는 사용자의 전문적 기술 등 배경 정보를 추론한다. 예를 들어, 추론 엔진은 시맨틱 링크에 PREDICATETYPEID_EXPERTON이라는 술어를 부가하여 사용자가 특정 카테고리에 전문가라는 것을 나타낸다. 이 경우 서브젝트는 사용자 오브젝트일 것이고, 오브젝트는 카테고리 오브젝트일 것이다. 이를 추론하기 위해, 추론 엔진이 바람직하게는 적어도 특정 주기의 시간 동안 시맨틱 액티비티를 추론하거나, 또는 사용자가 적어도 특정한 소정 수의 메시지를 전송하거나 또는 특정 수의 문서를 저술한 후 링크를 추론만 하도록 구성된다. 추론 엔진은 PREDICATETYPEID_CREATOR및 PREDICATETYEID_CONTRIBUTOR에 관한 통계를 유지함으로써 새로운 링크를 추론한다.

예를 들어, 추론 엔진은 사용자가 이하의 카테고리에 관한 전문가라는 것을 추론할 수 있다:

. 그들이 작성한 e-메일 메시지의 모든 카테고리 중, 이 카테고리는 상위 N 중 하나이다(구성가능함).

. 그들은 동일한 카테고리에 관하여 e-메일 메시지를 주당 평균 M번 이상 작성하였다(구성가능함).

. 그들은 과거 P개월에 적어도 0개의 e-메일 메시지(구성가능함)를 작성하였다(구성가능함).

이러한 데이터를 정확하게 추론하기 위한 보다 복잡한 추론 모델이 고려된다. 예를 들어, 통계적 상관 모델 뿐만 아니라 확률 분포가 채택될 수 있다. 바람직하게는, 이들 모델이 시간에 대한 시나리오 기반으로 개발될 것이다.

추론 엔진은 또한 과거에 부가하였을 수도 있는 링크들을 제거하는 담당을 한다. 예를 들어, 피고용인이 업무를 변경하면, 그 또는 그녀는 특정 카테고리에 대하여 더 이상 전문가가 아니다(다른 피고용인에 비하여). 추론 엔진이 이러한 것을 검출하면(e-메일 패턴을 관찰하는 등에 의해서), 그 사람이 그 카테고리에 대하여 전문가라는 것을 나타내는 시맨틱 링크를 제거한다.

추론된 시맨틱 링크는 확률론적 시맨틱 질의를 포함하는 시나리오에 대하여 중요하다. 예를 들어, 본 발명의 일 실시예에서는, 정보 에이전트를 사용하여, 사용자가 그들의 파일-시스템으로부터 에이전트로 문서를 드래그 및 드롭할 수 있다(가령, People.Research.All). 이 경우, 사용자들은 문서에 대하여 전문가인 연구 부서의 사람들을 알기 원할 것이다. 그리고, 브라우저는 에이전트를 리소스(또는 서브젝트)로하고, 술어는 nervana:experton이며 문서 경로가 오브젝트인 SQML 질의를 불러올 것이다. 그리고, 프리젠터(Presenter)는 그 문서에 대한 XML 메타데이터를 검색할 것이고, 에이전트를 호스트하는 에이전시에 상주하며, 술어 ID 및 문서의 XML 메타데이터를 인자(argument)로 하는 XML 웹 서비스를 호출할 것이다. 에이전시 상의 서버측 시맨틱 질의 프로세서는 이러한 XML 웹 서비스 호출을 처리하고, 상기 호출을 시맨틱 네트워크의 데이터 모델과 일관되는 SQL 질의로 번역한다. 본 예에서, 상기 호출이 바람직하게는 이하와 같이 해석된다:

1. KDM에서의 모든 시맨틱 도메인 엔트리에 대하여, 대응 KBS를 호출하여 문서를 카테고리화함.

2. 리턴된 카테고리들을 시맨틱 네트워크의 카테고리 오브젝트에 매핑시킴(URL 비교에 의함).

3. People.Research.All 에이전트의 질의를 서브-질의로서 사용하는 질의를 불러들임.

본 예에서, 최종 질의는 이하와 같이 나타난다:

SELECT * FROM USERS WHERE DEPARTMENT LIKE "RESEARCH"

AND OBJECTID IN (SELECT OBJECTID FROM SEMANTICLINKS

WHERE OBJECTTYPEID = 32 AND PREDICATETYPEID = 98 AND

SUBJECTID IN (SELECT OBJECTID AS SUBJECTID FROM

CATEGORIES WHERE OBJECTID IN (34, 56, 78)) AND

LINKSCORE＞90)

이러한 질의는 사용자 오브젝트 타입에 대한 오브젝트 타입 ID가 32이고, PREDICATETYPEID_EXPERTON에 대한 술어 타입 ID 값이 98이고, 오브젝트 ID가 34, 56, 78인 카테고리에 속하고 시맨틱 링크 스코어 임계치가 90인 문서를 가정한다.

e. 서버측 시맨틱 질의 프로세서(Server-Side Semantic Query Processor)

서버측 시맨틱 질의 프로세서(SQP)는 KIS의 클라이언트로부터 질의한다. SQP가 바람직하게는 KIS(또는 에이전시) 상의 시맨틱 네트워크로의 주요 엔트리 포인트이다. SQP는 에이전시의 XML 웹 서비스를 통해 드러난다. SQP는 다이렉트 에 이전트 시맨틱 질의 및 일반적인(클라이언트-생성의) 시맨틱 질의를 시맨틱 링크 필터(이하 참조)로 처리한다. 서버측 에이전트 필터에 의한 질의에 대하여, 정보 에이전트는 에이전트 명칭 및 오브젝트 인덱스 인자(argument)를 불러들여질 SQP에 전달한다. 예를 들어, 브라우저는 Documents.Technologh.Wireless.All.이라는 에이전트 상에 오브젝트 0-24를 요청할 수 있다. 본 예에서, SQP는 에이전트 테이블에서 에이전트 질의를 룩업하여 그 질의를 시맨틱 메타데이터 스토어(SMS)를 호스트하는 데이터베이스로 불러들인다. 에이전트 질의가 바람직하게는 SQL 또는 XQuery나 XQL 등 다른 잘 알려진 질의 포맷으로서 저장된다. SQP는 상기 질의 포맷을 데이터베이스(모든 테이블을 유지함)가 이해하는 포맷으로 변환할 수 있다. 대부분의 상용 데이터베이스가 SQL을 이해하기 때문에, 디폴트 에이전트 질의 포맷으로서 바람직하게 동작할 것이다.

에이전트 질의가 바람직하게는 상술된 질의 규칙을 따른다. 따라서, 질의는 에이전트의 오브젝트 타입에 대한 구성체계 필드 보다는 오히려 오브젝트 ID를 리턴한다. 상술된 예에서, Documents.Technology.Wireless.All은 "SELECT OBJECTID FROM DOCUMENTS WHERE ..."라는 에이전트 질의를 불러온다. SQP는 에이전트 질의로 필터링되지만, 오브젝트 타입(본 예에서는, "document" 오브젝트 타입)에 대한 실제 메타 데이터를 리턴하는 질의의 발행을 담당한다. 본 예에서, 질의는 이하와 같이 나타난다:

SELECT * FROM DOCUMENTS WHERE OBJECTID IN (SELECT

OBJECTID FROM DOCUMENTS WHERE ...)

이러한 질의는 본래 에이전트 질의에서의 것들과 일치하는 오브젝트 ID를 갖는 모든 오브젝트에 대한 "document" 구성체계에 대하여 데이터 컬럼을 리턴한다. SQP는 데이터베이스 질의의 메타데이터 결과를 검토하고, 이들을 에이전트의 오브젝트 타입에 대하여 적절한 구성체계(본 경우, "document")를 이용하여 잘-형성된(well-formed) XML로 번역한다. 데이터베이스가 로(raw) XML 검색을 지원하는 경우, SQP는 데이터베이스가 XML 결과를 줄 것을 요청함으로써 질의를 최적화한다. 이는 SQP가 나머지 번역 단계를 수행할 필요가 없기 때문에 보다 우수한 성능을 가져온다. SQP는 에이전시의 XML 웹 서비스를 통해 XML을 호출자에게 다시 전달한다.

SQP가 바람직하게는 시맨틱 브라우저(또는 XML 웹 서비스의 다른 클라이언트)에 의해 전달되는 보다 복잡한 질의를 조작한다. 예를 들어, 이러한 질의는 이하의 XML 웹 서비스 API의 형태를 취할 수 있다:

String

InvokeSemanticQuery(

Integer BeginIndex,

Integer EndIndex,

String AgentName,

Integer NumberOfLinks,

String OperatorNames[],

String LinkPredicateNames[],

String LinkTypeNames[],

String LinkObject[]);

본 에에서, "[]" 심볼은 어레이를 참조한다. API는 제로-기반 시작 인덱스, 제로-기반 종료 인덱스, 선택적 에이전트 명칭, 시맨틱 링크를 나타내는 정수, 연산자 명칭의 어레이, 링크 술어 명칭의 어레이, 링크 타입 명칭의 어레이 및 링크 오브젝트를 참조하는 스트링의 어레이를 취한다. 에이전트 명칭이 NULL("")이면, SQP는 예상되는 에이전트 필터 없이 "as is"라는 질의를 처리한다. 이는 클라이언트로부터 전부 생성된 질의에 의한 경우일 것이다. 어레이는 "NumberOfLinks"라는 파라미터가 각 어레이의 사이즈를 나타내기 때문에 가변될 수 있는 사이즈이다. 연산자 명칭은 논리적 연산자를 포함하여 SQL 또는 기타 질의 포맷으로 질의에게 자격을 주기 위해 사용될 수 있는 유효한 소정의 연산자를 포함한다. 예를 들어, "term:or" 및 "term:and"를 포함한다. 링크 술어 명칭은 하나 이상의 소정의 술어를 포함할 수 있다(예를 들어, "term:relevantto", "term:reportsto", "term:sentto", "term:annotates", "term:annotatedby", "term:withcontext" 등). 링크 타입 명칭은 링크 오브젝트의 타입을 나타낸다. 공통적인 예들은 "url" 및 "object"를 포함한다. "term:url"의 경우, 링크 오브젝트 스트링은 "object://..." 또는 "Agent://..."를 포함하는 잘-형성된 URL이다. "term:object"의 경우, 인자(argument)는 본 발명의 내에서 규정된 오브젝트를 참조하는 잘-형성된 XML 메타데이터 인스트럭션일 것이다. 이러한 오브젝트가 바람직하게는 클라이언트로부터 또는 다른 에이전시로부터 해석된다. API는 XML 결과 를 포함하는 스트링을 리턴한다(XML 웹 서비스 방법 호출 자체에 대한 리턴 값에 부가하여).

예에 의해,

＜resource type="term:url"

Agent://all.criticalpriority.all@abc.com/Agency.asp＞

＜link predicate="term:relevantto"

type="term,:object"

object://4576 ＞

＜/link＞

＜link operator="or"

predicate="term:intersects"

type="term:url"

Agent://email.wireless.all@abc.com/Agency.asp＞

＜/link＞

＜/resource＞

데이터를 갖는 SQML은 abc.com/Agency.asp 상의 웹 서비스에 위치된 에이전시로 분석된다.

InvokeSemanticQuery(

0,

24,

"all.criticalpriority.all",

2,

{ "term:and", "term:or" },

{ "term:relevantto", "term:intersects" },

{ "term:object", "term:url" },

{ "object://4576", "Agent://email.wireless.all@abc.com/Agency.asp" } );

이는 SQL 질의로 바람직하게 분석된다:

TOP 25 * OBJECTS WHERE OBJECTID IN (SELECT OBJECTID FROM OBJECTS WHERE

CREATIONDATETIME='02/26/02' AND (OBJECTID [RELATEDTO] [OBJECT WITH ID

4576]) AND OBJECTID IN (SELECT OBJECTS FROM EMAIL WHERE CATEGORY [IS]

'WIRELESS')

이 SQL 예는 SQP에 의해 생성되는 질의 타입을 예시하기 위하여 약어를 사용한다. SQP는 XML을 검색하고 이를 호출자에게 리턴시킨다. 이 XML은 SRML(Semantic Result Markup Language) 형태이고, 본 발명의 바람직한 실시예에서의 시맨틱 질의 결과에 대한 XML 메타-구성체계 규정이다. 첨부에 도시된 샘플 A는 샘플 SRML 시맨틱 결과 버퍼 또는 문서이다. 이것은 에이전시가 시맨틱 질의에 응답하여 리턴하는 XML의 샘플이다. 클라이언트 스킨은 이들 결과를 취하고, 스킨 및 에이전트(오브젝트 스킨/컨텍스트 스킨/블렌더 스킨), 이용가능한 표시 영역의 양, 장애 고려 및 다른 스킨 속성의 정리에 기초하여 이들을 프리젠테이션 형태로 생성시킨다(XSLT 및/또는 스크립트를 사용하여).

f. 자연어 분석기(Natural Language Parser)

자연어 분석기(NLP)는 바람직하게는 자연어 문자를, SQP를 인식하는 API 호출 또는 데이터베이스에 의해 처리될 수 있는 원 SQL(또는 유사한 질의 포맷)로 변환한다. 자연어 분석기는 시맨틱 브라우저로부터 또는 e-메일 지식 에이전트(하기를 참조)를 통한 e-메일에 의해 직접 문자를 통과시킨다.

g. e-메일 지식 에이전트(Email Knowledge Agent)

KIS는 바람직하게는 e-메일 지식 에이전트(또는 기업체 정보 에이전트(EIA))로 언급되는 하나의 주 공개 구성요소를 포함한다. 본질적으로, 이 에이전트는 디지털 고용인으로서 기능하며, 바람직하게는 고유 e-메일 어드레스(가령, 에이전시 인증자에 의해 선택된 고객 이름)를 포함한다. e-메일 지식 에이전트는, 정보를 공개하고 지식을 공유하는 방법인 "파이어 및 포겟(Fire and Forget)" 방법을 부가함으로써, 마이크로소프트 오피스, 세어포인트 등과 같은 기존의 공개 툴을 보완한다. 이는 정보를 공개하는 사람이 누가 이 정보에 관심이 있는 지를 모르는 경우에 특히 유용하다.

본 발명의 바람직한 실시예에서, 사용자는 e-메일을 코멘트, 주석, 문서, 첨부물 등을 공개하기 위하여 e-메일 지식 에이전트에게 보낸다. e-메일 지식 에이전트는 e-메일로부터 의미를 추출하여 시맨틱 네트워크에 적절히 부가한다. 다른 사용자는 드래그 및 드롭, 스마트 렌즈 등과 같은 다른 플랫폼 프리젠테이션 툴의 에이전트를 통해 공개된 정보를 액세스할 수 있다(후술함).

e-메일 지식 에이전트는 에이전시 인증자에 의해 생성된 시스템 구성요소이다. 서버가 먼저 인스톨된 경우에, 시스템 사용자 이름이 지시된다. 시스템 사용자는 바람직하게 기업체 e-메일 시스템(마이크로소프트 익스체인지, 로터스 노트 등)에서 e-메일 사용자에 해당한다. 본 실시예에서, e-메일 에이전트는 자신의 메일박스, 캘린더, 어드레스 북 등을 갖는다. 차례로, 이들은 시스템 사용자에 대한 e-메일 서버 상의 오브젝트에 해당한다. 서버가 인스톨된 경우, KIS는 시스템 인박스(inbox)를 위해 적절한 DSA를 인스톨한다(e-메일 어플리케이션에 따라). KIS는 바람직하게는 시스템 인박스가 e-메일에 대해서 주기적으로 크롤(crawl)되어야만 하는 것을 나타내는 SDG에서 수집기 리스트 엔트리(gatherer list entry)를 자동적으로 부가한다.

e-메일 지식 에이전트가 우선-클래스 e-메일 어드레스이기 때문에, 또한 통지 소스 및 질의 소스(자연어 및 인스턴트 메시지에 대해)로도 기능한다. 에이전시로부터의 통지는 바람직하게는 e-메일 지식 에이전트에 의해 보내진다(사용자가 관심을 가질 수 있는 새롭고 관련있는 정보 등이 있다는 것을 나타냄). 또한, e-메일 지식 에이전트는 사용자로부터 자연어 질의로서 e-메일을 수신할 수 있다. 이들 메시지는 SQP에 의해 문장분석이 된 후 처리된다. XML 결과는 자연어 질의의 XML 결과를 통해 처리된 XSLT로 생성된 HTML 파일(적절한 디폴트 스킨을 가짐)로서 사용자에게 바람직하게 보내진다.

e-메일 지식 에이전트가 정규의 친숙한 구성요소 또는 "고용인"이기 때문에, 에이전시 인증자는 바람직하게 그 어드레스를 분포 리스트에 부가한다. 이 단계를 통해, SDG가 이들 분포 리스트내의 모든 e-메일을 시맨틱하게 인덱싱하고, 이로써 사용자에게 유용한 분포 리스트내로 e-메일 지식 에이전트를 시임리스하게 통합하여 시맨틱 네트워크를 채운다. 이는, 이미 조직체내에서 사람들이 작업하는 방식을 사용하여, 본 발명의 디지털 정보 신경 시스템을 통합하는 매우 일체화된 방법이다.

주석 : e-메일 지식 에이전트는 바람직하게 주석을 공개하기 위해 사용된다. 본 발명에서, 주석은 바람직하게는 e-메일 메시지이다. 바람직한 실시예에서, 주석 오브젝트 타입은 e-메일 오브젝트 타입의 서브클래스이다. 이로써 사용자는, 시맨틱 브라우저에서 오브젝트를 주석달기 위해서, 통상 가장 일반적인 공개 툴인 e-메일을 사용할 수 있다. 사용자는 오브젝트를 주석달 수 있고 첨부물을 주석에 부가할 수 있다. 이들 첨부물은 KIS 상의 SDG에 의해 시맨틱하게 인덱싱된다. 이로써 사용자가, 말하자면, 문서부터 주석, 문서 첨부물, 로이터 통신의 기사, 다음주에 시작하는 산업 이벤트까지, 이 모두를 검색하는 것이 가능할 것이다.

e-메일을 시맨틱하게 인덱싱하는데 묘사된 프로세스(e-메일 XML 구성체계를 시맨틱 네트워크로의 매핑에 의해)는 또한 주석에 적용된다. 그러나, 본 발명의 바람직한 실시예에서의 주석인 경우, 부가적인 처리가 바람직하다. 상술하면, 사용자가 시맨틱 브라우저(후술함)에서 프리젠터 윈도우에서의 오브젝트 상의 "주석"을 클릭한 경우, 브라우저는 로컬 기계(가령, 마이크로소프트 아웃룩, 마이크로소프트 아웃룩 익스프레스 등) 상의 등록된 e-메일 클라이언트를 로드한다. "투(to)" 필드는 오브젝트를 호스트하는 에이전시에 대해 시스템 사용자의 어드레스로 채워진다. 서브젝트 필드는 특별 스트링, 예를들어 "주석:오브젝트=[objectid]"로 채워진다. e-메일이 e-메일 지식 에이전트의 인박스에 도착한 경우, e-메일 인박스에 대한 DSA는 e-메일을 픽업할 것이다(가령, 서버 이벤트를 통해). SDG는, 이벤트를 수신함으로써 DSA로부터, 또는 다음번에 DSA에게 더 많은 데이터를 요구할 때 DSA로부터, 새로운 e-메일 XML 메타데이터를 검색한다. 바람직한 실시예에서, 이런 조사는 빈번히 발생한다. DSA는 e-메일 오브젝트가 e-메일 오브젝트 타입 또는 주석 오브젝트 타입을 나타내는 사실을 알지 못한 채, e-메일 오브젝트의 XML 메타데이터를 리턴시킨다. SDG는 e-메일 XML 메타데이터를 처리하고, "서브젝트" 필드를 조사한다. SDG의 "annotation:"이라는 접두어를 "보면(see)", 그 e-메일이 실제로 주석인 것을 알게되어, 서브젝트 문자로부터 오브젝트 ID 인자(argument)로 추출하도록 진행한다. SDG는 잔존하는 e-메일 메시지를 위한 시맨틱 네트워크를 업데이트한다(각 메시지를 오브젝트 및 e-메일 테이블에 부가하고, 필요한 곳에 "from", "to", "cc", "bcc", 및 "attachment" 필드 등에 대해 시맨틱 링크를 부가함). 바람직한 실시예에서, SDG는 추가적인 단계를 실행한다. 상술하면, 서브젝트 문자(PREDICATETYPEID_ANNOTATES 술어를 갖는)내의 오브젝트 ID 인자(argument)에 의해 지시된 오브젝트를 e-메일 오브젝트와 링크시키는 시맨틱 링크 엔트리를 부가한다.

본 발명에서, 주석은 특별한 술어를 갖는 다른 시맨틱 링크로서 다루어진다. 그 결과, 시맨틱 링크를 통한 시맨틱 네비게이션, 시맨틱 질의 등과 같은 모든 시맨틱 특징이 주석에 적용된다. 예를들어, 사용자는 지난 6개월내의 자기 팀의 모 든 멤버에 의해 쓰여진 모든 주석에 대해 질의할 수 있다. 이는, 예를 들면 에이전트 People.MyTeam.All의 상부인 에이전트 Annotation.All을 드래깅(dragging)한 다음 그 결과를 소팅하거나 또는 스마트 에이전트를 생성하므로써, 시맨틱 브라우저에서 수행될 수 있다. 상기 스마트 에이전트는 질의를 생성하기 위하여 "스마트 에이전트 생성" 마법사를 호출한다.

h. 지식 도메인 매니저

지식 도메인 매니저는 시맨틱 네트워크 상의 도메인-특정 지능을 부가하고 유지하는 것에 대해 책임을 지는 KIS 상의 구성요소이다. KDM은 도메인-지능을 갖는 시맨틱 네트워크에 필수적으로 주석을 단다. KDM은 지식 기반 서버(KBS)의 하나 이상의 인스턴스와 관련된 URL로써 초기화된다. 그러면 상기 KBS가 하나 이상의 시맨틱 도메인에 대한 "지식"을 효율적으로 저장한다. KBS는 자신이 지원하는 각 시맨틱 도메인에 대한 텍사노미(taxonomy)에 해당하는 온톨로지 및 카테고리를 갖는다. 또한, 시맨틱 도메인(KBS에 접속된)을 갖는 에이전트는 시맨틱 질의에 응답한다. 에이전트가 시맨틱 도메인에 속해 있지 않다면, 시맨틱 질의(온톨로지 또는 텍사노미를 필요로 하는)에 대응하지 않는다. 오히려, 상기 에이전트는 키워드-기반 질의에만 응답한다(상기 에이전트는 컨텍스트 및 시간에 민감한 검색 서비스를 제공하지만, 이용가능한 컨텍스트는 한정됨).

KDM에서의 각 엔트리는 시맨틱 도메인 엔트리이다. 시맨틱 도메인 엔트리는 KBS로의 URL 및 시맨틱 도메인 이름을 갖는다. 시맨틱 도메인 이름은 KBS 상의 특정 온톨로지에 매핑한다. 본 발명의 바람직한 실시예에서, 시맨틱 도메인 이름은 다음의 방식을 따른다.

＜Top Level Domain Name＞＼＜Secondary Level Domain Name＞......

시맨틱 도메인 이름의 예는

ㆍ Industries

ㆍ Industries＼Pharmaceuticals＼LifeSciences

ㆍ Industries＼InformationTechnology

ㆍ General＼Sports.Basketball＼NBA

ㆍ General＼Sports.Basketball＼CBA

를 포함한다.

그 대안으로, 시맨틱 도메인 이름은 완전히 수식화되어 있는한 "도메인 경로(Domain Path)"로 언급될 수 있다. 완전한 수식화된 경로의 시작 부분 앞에 인터넷 도메인 이름을 부가함으로써 이룩된다. 이는 시맨틱 도메인의 "소유자" 또는 "소스"를 나타낸다. 예를들어, "Nervana.NET＼Industries＼Pharmaceuticals"는 "Nervana.NET" 이라는 인터넷 도메인 이름에 따른 "Industries＼Pharmaceuticals" 시맨틱 도메인을 나타낸다. 다른 예에서, "Reuters.com＼Sports＼Basketball"은 "Reuters.com" 상의 "Sports＼Basketball"를 나타낸다다. 이 방식을 사용함으로써, 도메인 이름 및 경로는 글로벌하게 고유한 것으로 유지된다.

지식 도메인 매니저(KDM)는 지식 도메인내의 카테고리에 대한 도메인 엔트리 리스트에서 각 KBS를 주기적으로 요구한다. KDM은 KIS 상의 XML 웹 서비스로 바람직하게 구현된다. KDM은 각 시맨틱 도메인 엔트리에 대한 구성 옵션을 포함한다. 이들 옵션중의 하나는, KDM이 시맨틱 도메인 엔트리에 해당하는 도메인-특정 지능을 갖는 시맨틱 네트워크를 업데이트하는 스케줄을 포함할 수 있다. 예를들어, 에이전시 인증자는 매일 오후 1시에 KBS 상에서 시맨틱 도메인을 크롤하기 위해 KDM(KIS를 통해)을 구성할 수 있다. 업데이트 스케줄은, 운영자가 생각하는, KBS상에서 온탈로지 또는 텍사노미가 변화하는 빈도와, 일치하여야 한다.

KIS는 KDM을 주기적으로 호출하고 카테고리 테이블을 업데이트할 것을 요구한다. 바람직한 실시예에서, KDM은 시맨틱 도메인 엔트리내의 시맨틱 도메인 이름에 대한 업데이트된 카테고리를 얻기 위하여 KBS를 호출한다(XML 웹 서비스 API 호출을 통해). 상기 시맨틱 도메인 엔트리는 특정 텍사노미에 대응한다. API 호출의 예는 GetCategoriesForSemanticDomain (String SemanticDomainName)이다. KBS는 시맨틱 도메인 이름에 의해 언급된 시맨틱 도메인에서 모든 카테고리의 XML 기반 리스트를 리턴시킨다. 이 XML 리스트는 상기에 나타낸 카테고리 구성체계(카테고리 URL, 이름, 설명, KBS URL 및 시맨틱 도메인 이름)와 일관된다. KDM은 이런 정보로 카테고리 테이블을 업데이트한다. 테이블내의 기존 카테고리 엔트리에 대해, KDM은 이름 및 설명을 업데이트한다. 새로운 엔트리에 대해서는, KDM은 오브젝트 매니저로부터 새로운 오브젝트 ID를 요구하여, 카테고리 엔트리에 할당한다. 바람직한 실시예에서, 카테고리는 "오브젝트"이므로, 오브젝트 타입으로부터 기인된 오브젝트 ID를 갖게 된다.

KDM은, 카테고리 엔트리의 URL을 조사하고, 관련있는 KBS URL과 시맨틱 도메인 이름을 얻은 후에, 새로운 리스트에 존재하지 않는 카테고리 테이블의 엔트리를 삭제함으로써, 카테고리 테이블을 KBS 상의 카테고리 리스트와 동기화시킨다. 시맨틱 도메인 엔트리가 KIS로부터 삭제되면, KDM은 그에 대응하는 시맨틱 도메인 이름 및 KBS URL을 갖는 모든 카테고리 엔트리를 삭제한다. 필수적으로, 이는 에이전시로부터 기존 지식을 삭제하는 것과 유사할 것이다.

KDM은 시맨틱 도메인 엔트리에 기초한 시맨틱 네트워크내의 모든 "지식 오브젝트"를 주기적으로 카테고리화한다. 새로운 오브젝트가 SDG에 의해 시맨틱 네트워크에 부가된 경우, SDG는 KDM이 그 오브젝트를 카테고리화할 것을 요구한다. KDM은 시맨틱 도메인 엔트리내의 모든 KBS 예를 열거하고, 인자(argument)로서 오브젝트의 XML을 갖는 XML 웹 서비스 호출을 호출한다. 바람직한 실시예에서, KBS는 다음과 유사한 XML 버퍼의 형태로 결과를 리턴시킨다:

＜results＞

＜result categoryurl="category://foo"

score="91" ＞

＜result categoryurl="category://bar"

score="93" ＞

＜result categoryurl="category://foobar"

score="100" ＞

＜/results＞

이 정보는 KBS 상의 시맨틱 도메인내의 카테고리에 대한 XML 오브젝트의 시맨틱 카테고리화 가중치(weights)를 나타낸다. 본 발명의 바람직한 실시예에서, 시맨틱 도메인 엔트리는 KDM이 KBS로부터 요구해야만 하는 최소 가중치를 나타내는 임계값 (0-100)으로 초기화된다. KBS는 소정의 임계값을 초과하는 스코어를 리턴시킨다. KDM은 이들 카테고리화 결과에 기초하여 시맨틱 네트워크에 주석을 단다. 이는 결과내의 카테고리의 오브젝트 ID를 갖는 "belongs to category"의 술어 타입 ID로 시맨틱 링크를 부가 또는 업데이트함으로써 바람직하게 이룩된다. KDM은 SEMANTICLINKS 테이블을 업데이트할 것이다. 카테고리화된 오브젝트는 오브젝트 ID 값 56을 갖는 것으로 가정하면, 업데이트 질의는 다음과 같이 나타난다:

UPDATE SEMANTICLINKS SET LINKSCORE = 91 WHERE OBJECTID=56 AND

PREDICATETYPEID = 67 AND SUBJECTID IN (SELECT OBJECTID AS SUBJECTID

FROM CATEGORIES WHERE URL LIKE "CATEGORY://FOO")

KDM은 모든 "지식 오브젝트"(문서, 새로운 기사, 이벤트, e-메일 등, 사람과 같은 오브젝트는 바람직하지 않음)를 주기적으로 스캔하고 카테고리화 한다. KBS가 "더욱 지능화(smarter)"되는 것처럼, 시맨틱 네트워크내의 오브젝트가 미리 카테고리화된 경우라도, 이 프로세스는 바람직하게 생성되며, 더 뛰어난 카테고리화가 제공된다. 이 경우, 동일한 카테고리화 요청이 반복될지라도 그 결과는 다를 수 있다. 예를들어, KBS 상의 온톨로지가 업데이트된다면, 이는 생성될 것이다. 따라서, 바람직한 실시예에서, 오브젝트가 시맨틱 데이터 수집기에 의해 시맨틱 네트워크에 부가된 경우 및 시맨틱 네트워크가 가장 최근의 도메인 지식을 보유한다는 것을 주기적으로 보증하기 위하여, 카테고리화는 수행될 것이다.

i. 다른 구성요소

즐겨찾기 에이전트 매니저(The Favorite Agents Manager). 사용자 상태를 지원하는 에이전시 상에, 즐겨찾기 에이전트 매니저는 사용자당 즐겨찾기 에이전트의 리스트를 관리한다. 바람직한 실시예에서, 즐겨찾기 에이전트 매니저는 UserFavoriteAgents 테이블에서 사용자 이름에 대한 즐겨찾기 에이전트로의 매핑(mapping)을 저장한다.

컴파운드 에이전트 매니저(Compound Agent Manager). 컴파운드 에이전트 매니저는 컴파운드 에이전트의 생성, 삭제 및 업데이트를 관리한다. 상술한 바와같이, 컴파운드 에이전트는 시스템내의 다른 에이전트들로 구성되는 에이전트이고, 포함된 에이전트내에서 질의 결과의 결합 또는 교차를 리턴시키기 위해 초기화된다. 컴파운드 에이전트 매니저는 시스템내의 모든 컴파운드 에이전트를 관리하고, CompoundAgentMap 테이블을 통하여 컴파운드 에이전트를 그 다른 에이전트에게로 매핑한다.

컴파운드 에이전트 매니저는, 컴파운드 에이전트를 생성, 삭제, 재명명하고, 이들로부터 에이전트를 제거 및 부가하기 위한 기능들을 노출하고, 결합 또는 교차가 바람직한지의 여부를 지시한다. 컴파운드 에이전트는 나머지 컴파운드 에이전트에 부가될 수 있다. 기동시에, 시맨틱 질의 프로세서는 컴파운드 에이전트 매니저에게 그의 질의를 요청한다. 컴파운드 에이전트 매니저는 그의 에이전트 맵 그래프를 통해 네비게이션하고, 자신에 속한 모든 에이전트의 모든 질의에 대한 복합질의를 리턴시킨다. 에이전트가 삭제된다면, 컴파운드 에이전트가 호출된 경우, 이는 삭제된 에이전트의 질의를 무시한채 새로운 상태를 "픽 업(pick up)"한다. 환언하면, 질의를 합성하는 것은 계속 존재하는 에이전트에 대해서만 행해진다. 컴파운드 에이전트는 에이전트 중의 하나가 삭제된 것을 관측하면, 그의 맵으로부터 삭제된 에이전트의 엔트리를 삭제할 것이다.

사용자 프로파일 매니저(User Profile Manager). 사용자 프로파일 매니저(UPM)는 진행 기준 상의 사용자 프로파일을 추론하기 위해 추론 엔진을 사용한다. UPM은, 사용자로부터의 피드백에 기초하여 시맨틱 네트워크의 사용자들의 기호에 따른 주석을 단다. 바람직한 실시에에서, 이 프로세스는 PREDICATEID_ISINTERESTEDIN 술어의 사용에 관여한다. UPM은 시맨틱 링크를 추론하고, PREDICATEID_ISLIKELYTOBEINTERESTEDIN 술어를 갖는 시맨틱 네트워크에 주석을 단다. 사용자에게 보내지는 모든 질의의 결과는, 시맨틱 네트워크에 PREDICATEID_ISLIKELYTOBEINTERESTEDIN 술어에 대해 요청함으로써, 수식화될 것이다(아웃-오브-밴드). 추론 엔진은 시간을 통해 학습하는 것처럼, 질의 결과는 사용자의 습관에 기초한다.

그 대안으로는, UPM은 사용자 상태 스토어(USS)내에 저장된 사용자 프로파일 정보를 갖고 구성될 수 있다. 이는 사용자의 기호를 나타내는 클라이언트로 수동으로 입력된 정보이다. 이 정보는 사용자와 상호작용하고 있는 서버에서 전송되고 저장된다. 이들 기호는 서로 다른 구성체계에 묶인다. 예를들어, 문서의 경우, 구성체계는 선호되는 카테고리에 기초할 수 있다. 메일 메시지의 경우, 구성체계는 선호되는 카테고리, 저작자, 또는 첨부물에 기초할 수 있다. 상기 문서와 메일은 많은 가능한 예 중에 두개이다. UPS는 USS에서 수동으로 입력된 정보에 기초하여 시맨틱 네트워크에 주석을 단다.

서버 통지 매니저(Server Notification Manager). 서버 통지 매니저(SNM)는 서버측 통지를 배치하고 이들을 사용자에게 전송하는 것을 책임진다. 바람직한 실시예에서, 사용자는 에이전트 레벨에서 서버측 통지를 위해 등록한다. 각 에이전트는 그의 질의 결과의 통지를 해고(fire)할 수 있다. 서버 통지 매니저는 질의 결과를 어떻게 필터링 할지와 질의 결과를 e-메일, 음성, 페이저 또는 임의의 다른 통지 메카니즘, 예를들어 Microsoft .Net 경고 통지 서비스 등을 통한 배송을 위해 어떻게 포맷할 지를 결정한다. 서버 통지 매니저는 사용자가 통지를 "읽기"한 최종시간에 대한 정보를 보유한다. 이는 사용자 인터페이스를 통해 클라이언트로부터 바람직하게 지시된다. 특정 사용자에 대한 최종 "읽기" 시간 이후로 에이전트 상에 새로운 정보가 있는 경우, SNM은 사용자에게 바람직하게는 통지만한다.

에이전트 디스커버리(Agent Discovery). 멀티캐스트 기반 에이전트 디스커버리를 사용하면, 각 에이전시는 로컬 멀티캐스트 네트워크 상의 그의 존재를 알려주기 위한 멀티캐스트 공표(announcement)를 송신한다. 에이전시 인증자는 멀티캐스트 TTL을 설정한다. 본 발명은 9875의 공지된 포트 및 255의 TTL을 갖는 Session Announcement Protocol(SAP)의 사용 또는 맞춤형 TTL을 갖는 독점 공표 포트 중의 하나를 바람직하게 사용한다. SAP에 대해서 상세한 것은, 본 명세서에 참조로서 포함된 http://sunsite.cnlab-switch.ch/ftp/doc/standard/rfc/29xx/2974를 참조한다.

바람직하게는, 정보 에이전트는 SAP 공표를 수신하는 리스너(listener) 구성 요소를 포함한다. 바람직한 실시예에서, 공표는 XML로 송신되고 다음의 정보를 포함한다.

ㆍ 서버 ID (이는 고유 식별자임)

ㆍ 서버 URL (이는 에이전시의 XML 웹 서비스에 대한 HTTP URL)

ㆍ 공표 주기 (T) - 이는 각 공표 간의 시간을 나타냄

ㆍ 최종 공표 및 최종 에이전트 생성 시간(에이전시의 클럭으로)이래로 에 이전시내의 임의의 새로운 에이전트의 존재 여부

각 에이전시는 XML 공표를 송신하고, 패킷을 인코딩하기 위해 Forward Error Correction(FEC) 또는 Forward Erasure Correction을 사용한다. 이는 드롭된 패킷에 대해 시스템을 강하게 한다. 그 대안으로는, 에이전시는 연속적으로(공표 당) 몇몇 XML 공표를 송신하도록 구성될 수 있다.

정보 에이전트 멀티캐스트 리스너는 디렉토리형 시맨틱을 시맨틱 환경 매니저로 노출시킨다. 리스너는, 자신이 공표를 수신하는 에이전시로부터 온 모든 XML 공표를 모은다. 또한, 각 에이전시로부터의 공표를 수신한 최종 시간을 캐쉬할 것이다. 리스너는 데드(dead) 또는 인액티브(inactive)로 생각되는 에이전시를 플래그한다. 이는, 에이전시의 공표 주기보다 더 긴 시간동안 에이전시로부터 아무것도 듣지 못했을 때, 이루어진다. 리스너는 인액티브로 에이전시를 플래그하기 전에 몇 주기동안 대기하도록 구성될 수 있다. 이는 공표가 누락된 경우(아마 트래픽 정체로 인하여)를 조정할 것이다. 리스너는 공표를 수신할 때마다 시맨틱 환경 매니저내의 에이전시 리스트를 업데이트할 것이다.

시맨틱 환경 매니저는 임의의 새로운 에이전트의 존재 여부를 리스너에게 주기적으로 문의한다. 시맨틱 환경 매니저는 에이전시 리스트를 체크하고, 액티브 상태의 각 에이전트에게 그것이 새로운 에이전트들을 가지고 있는지 여부를 문의할 것이다. 시맨틱 환경 매니저는, 국부적으로 유지된 에이전시의 최종 에이전트 생성 시간 및 에이전시의 클럭에 기초한 현재의 시간으로써, 이러한 질의를 수식화한다. 에이전시는 최종 에이전트 생성 시간의 새로운 값에 응답하고 또한 이를 송신한다. 시맨틱 환경 매니저는 에이전시 엔트리내의 이 값을 캐쉬한다. 새로운 에이전트라면, 브라우저는 대화 박스를 통해 사용자에게 알리고 사용자가 이 새로운 에이전트를 보기 원하는 지의 여부를 사용자에게 요구한다.

또한, 본 발명은 피어-투-피어(peer-to-peer) 에이전트 디스커버리를 사용하여 에이전시 공표를 지원한다. 이 모델에서, 공표는 모든 클라이언트가 체크하는 디렉토리 서버에 또는 표준 피어-투-피어 공개 프로토콜을 통해 직접 클라이언트에게 송신된다.

도 47-53은 KIS에 의해 에이전트 관리의 양태를 나타내는 예시적인 스크린삿이다. 도 47-50은 서버측 에이전트 뷰 및 서버측 에이전트를 나타내는 샘플 KIS 에이전시 인증 매니저를 도시한다. 도 51은 SDG(크롤) 업무, 시스템 업무(가령, 추론 엔진), 시스템 에이전트 e-메일(가령, 인박스), 캘린더 및 콘택트 DSA와 모든 SMS 데이터 테이블(오브젝트, 시맨틱 링크, 카테고리 등)을 관리하기 위한 샘플 인증 사용자 인터페이스 소자를 도시한다. 도 52는 KIS 에이전시 인증 매니저내의 본 발명의 "서버 속성" 대화의 샘플을 도시한다. 대화는 서버 인증자가 서버 이 름, 표시 이름, SMS 데이터 저장 속성, KDM 속성(가령, 지식 도메인 경로) 및 사용자 DSA 속성 등의 서버 속성을 어떻게 설정하는 지를 도시한다. 도 53은 바람직한 실시예의 KIS 에이전시 인증 매니저내의 "서버 통계" 대화의 샘플을 도시한다. 대화는 서버측 에이전트(표준 에이전트 및 블렌더)의 총 수, 서버측 표준 에이전트의 총 수, 서버측 에이전트 블렌더의 총수, 서버측 에이전트-뷰의 총 수, 서버측 에이전트 서브스크립션의 총 수, 서버 상에 저장된 정보 오브젝트의 총 수, 시맨틱 링크의 총 수, 서버(에이전시) 상의 사용자 총 수 및 사용자 그룹 총 수 등과 같은 통계의 디스플레이를 도시한다.

3. 지식 기반 서버

지식 기반 서버(KBS)는 KIS에 대한 지식을 호스트하는 서버이다. 대부분의 어플리케이션에서, KIS의 많은 인스턴스들이 전개되지만, 단지 몇개(또는 한개) KBS가 임의의 주어진 조직에 대해 전개될 것이다. 이는 KBS가 재사용될 수 있기 때문이다(이들은 도메인-특정이지만 데이터-독립임). 예를들어, 제약 회사는 제약 온톨로지로 초기화된 하나의 KBS를 전개할 수 있지만, 고용인 분할 당 또는 고용인 그룹 당으로 몇개의 KIS 인스톨레이션을 가진다. KIS는 다음의 구성요소를 바람직하게 포함한다.

1. 하나 이상의 온톨로지는 하나 이상의 시맨틱(지식) 도메인에 해당한다. 시맨틱 도메인은 시맨틱 도메인 이름을 사용하여 나타낸다. 이는 시맨틱 계층내의 도메인 경로로 불리는 이름이다. 예는 Industries.Technology, Industries.Pharmaceuticals.LifeSciences, and General.Sports.Basketball이다. 이들 이름 또는 경로는 상술한 바와같이, 글로벌적으로 고유하게 수식화되어 있다(가령, 인터넷 도메인 이름).

2. 지원된 시맨틱 도메인에 해당하는 하나 이상의 텍사노미. 이들 텍사노미는 카테고리 이름의 계층을 갖는다.

3. 실행될 카테고리화를 갖는 문자 또는 XML 및 시맨틱 도메인 이름의 일부를 갖는 카테고리화 엔진은, 카테고리화 스코어(0-10 또는 바람직하게는 0-100의 스케일)에 따라 문자 또는 XML이 속한 도메인내의 카테고리로 리턴시킨다.

4. 새롭게 지원된 시맨틱 도메인을 부가하고, 주어진 시맨틱 도메인에 대한 카테고리를 열거하고, 문자 또는 XML 데이터 블라브를 카테고리화 하기 위해 API를 노출시키는 XML 웹 서비스.

5. 지식을 모으는 KBS로부터 다른 KBS로의 기준이 되는 XML 웹 서비스. 이 모드에서는, KBS는 프록시로 활동한다. 프록시로 활동하고 지원 시맨틱 도메인, 온톨로지 및 다른 KBS로부터의 텍사노미를 얻기 위해 KBS는 초기화된다.

상술한 바와같이, KIS(KDM을 통해)는 주어진 시맨틱 도메인에 대해 이들을 카테고리화 하기 위해 XML 오브젝트를 KBS로 주기적으로 송신한다.

4. 정보 에이전트(시맨틱 브라우저 플랫폼)

a. 개요

본 발명의 바람직한 실시예인 정보 에이전트에서, 시스템 클라이언트는 시맨틱 브라우저 구성요소 및 시맨틱 사용자 경험을 제공하는 사용자 인터페이스를 포함한다. 바람직한 실시예에서, 정보 에이전트는 다음의 하이-레벨 서비스를 제공 한다.

ㆍ 사용자에게 로컬 및 원격 정보 에이전트를 경유하여 컨텍스트 파워 및 시간 감도 시맨틱 정보 검색을 허용한다.

ㆍ 사용자에게 본 발명의 XML 웹 서비스를 통해 에이전트를 경유하여 노출된 로컬 및 원격 에이전시 상의 정보를 발견하게 한다. 바람직하게 이 정보는 문서, e-메일, e-메일 분포 리스트, 사람, 이벤트, 멀티미디어 및 소비자 등의 잘 알려진 시맨틱 종류로 분류된다.

ㆍ 사용자에게 본 발명의 에이전트를 경유하여 발견된 정보의 시맨틱 뷰를 브라우즈하게 한다.

ㆍ 사용자에게 정보를 에이전시에게 공개하도록 한다.

ㆍ사용자에게 하드-드라이브, 로컬 네트워크 또는 다른 에이전시로부터 에이전시 상에 발견된 정보를 갖는 특정 에이전시 상의 정보를 다이나믹하게 링크하도록 한다. 이는 다이나믹 e-링킹 및 사용자-제어 브라우징을 용이하게 한다.

본 발명의 정보 에이전트의 이점은 사용자가 그들의 파일-시스템 이름공간으로부터의 문서를 열어보는 방식과 유사하게 에이전트를 열어볼 수 있다는 것이다. 정보 에이전트는 정보의 시맨틱 "World"를 오픈하는 그 자신의 환경을 가질 것이다. 예를들어, ABC 회사는 내부 문서, e-메일 등에 대한 에이전트를 갖는 내부 KIS 에이전시를 가질 수 있다. 또한, 제 삼자는 산업 보고서, 산업 이벤트 등의 정보를 점유하기 위해 인터넷 상에서 에이전시를 호스트할 수 있다. 본 발명의 바람직한 실시예에서, ABC사의 직원들은, ABC사의 내부정보에서부터 외부정보이나 ABC사에 관련된 정보에 이르기까지 시맨틱하게 관련짓기 위해서 뿐 아니라, 인터넷상에 있는 자신들의 업무와 관련된 정보를 발견하기 위하여, 에이전트를 열어본다.

b. 클라이언트 구성(Client Configuration)

바람직한 실시예에서, 시스템 클라이언트는 로컬 뿐만 아니라 원격 에이전시에서 발견된 정보를 시맨틱하게 링크할 수 있다. 바람직하게 이는, 글로벌 에이전시 디렉토리로부터의 에이전시, 로컬 영역 네트워크 상의 에이전시(멀티캐스트 또는 피어-투-피어 공개 시스템을 통해 공개됨) 및 에이전트 디스커버리를 사용하여 커스텀 에이전시 디렉토리로부터의 에이전시로 구성된 노출된 시맨틱 환경을 사용함으로서 이루어진다. 바람직한 클라이언트 구성은 에이전트 및 로컬 에이전시를 갖는 프레임워크에 기초하고, 시맨틱 환경 매니저를 포함한다. 상기 시맨틱 환경 매니저는 로컬하게(제한된 영역내에) 저장된 에이전트 및 즐겨찾기 에이전트를 관리하고, 그것의 히스토리 및 즐겨찾기 메타퍼(metaphor)를 필수적으로 통합한다. 시맨틱 환경 매니저는, 시맨틱 환경 브라우저를 통해 사용자에게 지식을 제공하기 위하여, 시맨틱 환경내의 시맨틱 질의 문서를 사용한다. 또한, 클라이언트 구성은 에이전트 디스커버리 정보(가령, 에이전시 리스트, 에이전시 디렉토리 정보 등)를 포함할 것이다.

c. 클라이언트 프레임워크 스펙

개요. 클라이언트 프레임워크 스펙은 정보 에이전트 사용자 인터페이스를 위한 서비스 기반을 제공하고, 기본 서비스 및 인터페이스를 규정하고, 코어 사용자 인터페이스 구성요소를 포함하며, 정보 에이전트의 사용자 인터페이스의 메인 빌딩 블럭에 대해 확장가능하고 구성가능한 환경을 제공한다. 이 섹션은 본 발명의 바람직한 실시예에 따른 클라이언트 프레임워크 스펙에서 설명된다. 프레임워크 코어는 기초 서비스, 구성, 기호 및 보안 메카니즘을 규정한다. 코어 사용자 인터페이스 구성요소는 사용자 인터페이스 서비스 및 서버와 에이전트 구성, 제어와 기동(invocation), 시맨틱 브라우저 프레임워크에 대한 몇몇 구성을 지원하는 모듈을 규정한다. 코어 사용자 인터페이스 구성요소는 윈도우 셀 확장으로 구현되고 사용자 인터페이스(후술함)와 관련된다. 시맨틱 브라우저 프레임워크는 기초 질의, 결과 관리 서비스 및 결과 프리젠테이션에 대한 프레임워크를 제공한다. 시맨틱 오브젝트 프리젠테이션에 관련된 사용자 인터페이스의 스펙는 바람직하게 구성가능하고 확장가능하다; 심지어 디폴트 프리젠테이션 지원이 프리-인스톨 "extension"으로 제공된다. 시맨틱 브라우저 프레임워크는 오늘날의 웹에 사용된 기존 플랫폼(가령, 인터넷 익스플로러)에 대한 행위 확장의 세트로 바람직하게 구현되어, 지원 XML, XSLT, HTML/CSS 및 DOM 기능성에 영향을 준다.

컨텍스트. 클라이언트 프레임워크는 시맨틱 질의 지원, 컨텍스트와 시간-감도 시맨틱 프로세싱과 정보의 링킹 등을 포함하는 본 발명의 시맨틱 서비스 구성요소를 바탕으로 한다. 클라이언트 프레임워크는 셀 확장 및 플랫폼(가령, 인터넷 익스플로러) 확장으로 바람직하게 이루어지고, 기존 툴 및 환경의 컨텍스트내에서 사용자에게 기능성을 제공한다. 예를들어, 정보 에이전트는 셀 확장(윈도우 셀을 확장시키고 표준 익스플로러 뷰 및 사용자 인터페이스 모델을 채용함)으로 구현될 수 있다. 그 선택적인 실시예에서, 본 발명은 독립형의 시맨틱 브라우저 어플리케 이션에서 동등하게 적용가능하다.

요건(Requirement). 클라이언트 프레임워크에 대한 바람직한 요건은 다양성 및 확장성과 관련된다. 이러한 다양성과 확장성은, 사용자 인터페이스가 더 많은 정보 오브젝트 타입, 사용자 프로파일 등이 있는 것으로 쉽고 빠르게 채택될 수 있는 것을 보장한다. 다음의 사항이 포함된다.

ㆍ 질의 결과의 전체 세트를 관리하기 위한 스킨에 대한 지원을 제공

ㆍ 리스트, 테이블, 타임 슬라이드(timed slides) 등을 포함하는 광범위한 접근방식을 허용

ㆍ 스크린-세이버(또는 등가) 모드 제공

ㆍ 오브젝트 클래스로 관련될 수 있는 스킨에 대한 지원

ㆍ 모든 클래스를 조정할 수 있는 디폴트 스킨 보장

ㆍ 스킨은 XSLT만큼 간단해야만 하지만, 스크립트 지원 및 가능한 이븐 코드(적절한 보안 제한을 가짐)를 인정

ㆍ 에이전트(스마트, 덤, 및 스페셜), 에이전시 및 블렌더를 포함하는 결과 뷰에서 시맨틱 환경을 브라우징하기 위한 지원 제공(에이전트 트리 뷰를 보완하기 위해)

ㆍ 구성요소간 잘 규정된 인터페이스 제공하고, 모든 통신이 프레임워크를 경유하여 생성된다는 것을 보증

ㆍ 프레임워크 전체에 걸쳐 견고한 보안 모델 제공

프레임워크 코어(Framework Core)

Semantic Environment Manager(SEM). SEM은 에이전트, 블렌더 및 사용자의 로컬 기계상의 에이전시의 생성, 삭제, 업데이트 및 브라우징을 관리한다. 또한, SEM은 에이전시 멀티캐스트 공표의 리스닝, 기업체 디렉토리 상의 에이전시 브라우징(가령, LDAP를 통해), 커스텀 디렉토리 상의 에이전시 브라우징 및 글로벌 에이전시 디렉토리 상의 에이전시 브라우징을 책임진다.

SEM은 에이전트 속성(에이전트 이름, 설명, 생성 시간, 최종 사용 시간, 에이전트 타입(스마트, 덤, 스페셜 등)), (정보 타입에 기초하여 생성된 에이전트)를 나타내는 에이전트의 정보 오브젝트 타입, (컨텍스트 템플레이트에 기초하여 생성된 에이전트)를 나타내는 에이전트의 컨텍스트 타입, 에이전트 속성, 에이전트의 스킨(필터/소트 기호 및 다른 프리젠테이션 스킴을 포함), 통지 정보 및 방법(에이전트에 대해 요구된다면), 및 에이전트의 SQML 질의로의 버퍼 또는 파일-경로/URL 모두를 포함하여, 시스템 상의 모든 에이전트의 메타데이터를 저장하는 저장 레이어를 포함한다. 정보 에이전트(시맨틱 브라우저)는 윈도우 레지스트리(registry)와 같은 스토어인 로컬 데이터베이스, 또는 로컬 파일 시스템 상의 XML 파일 스토어에 이 에이전트 메타데이터를 저장할 수 있다.

또한, SEM은 에이전트가 즐겨찾기 에이전트인지의 여부를 나타내기 위해 에이전트 속성을 사용한다. 또한, SEM은 즐겨찾기가 아닌 에이전트와 구성가능한 기한 한계(가령, 2주)보다 더 오래된 에이전트는 자동적으로 삭제한다.

정보 에이전트의 셀 확장 및 다른 구성요소(툴바 및 오픈 에이전트 대화 등)은 사용자 인터페이스를 통해 에이전트의 관리, 업데이트, 브라우징, 삭제 및 생성 을 제공하기 위하여 SEM을 채용한다.

기호 매니저(Preference Manager). 이 구성요소는 기호를 주장하는 서비스를 제공하면서, 모든 클라이언트측 기호를 관리하고, 기호를 공유하거나 로밍을 지원하기 위해 필요한 경우 서버와의 통신하며, 다른 구성요소로부터의 기호값을 설정하고 획득하는 것을 지원한다. 이 구성요소는 사용자 인터페이스뿐만 아니라, 몇몇 특정 기호 사용자 인터페이스 구성요소와도 관련되어 있다. 기호는 서브 구성요소로 분할되고, 연관된 클라이언트 클래스에 대한 기호를 추출할 수 있다. 이들은 다음을 포함한다.

ㆍ 코어 기호. 이는 사용자 프로파일 및 개인 정보 등과 같은 기본 구성을 포함한다.

ㆍ 스킨 기호. 또한, 이는 선호되는 스킨을, 선호되는 리스트 스킨 및 스크린 세이버 스킨 뿐 아니라, 오브젝트 클래스와도 관련시킨다. 부가적인 스킨-관련 기호 설정일 수도 있다.

또한, 이 구성요소는 국부적으로 이용가능한 스킨의 세트를 관리한다. 다운로드 가능한 스킨은 이 구성요소를 통해 바람직하게 관리된다.

통지 매니저. 통지는 주어진 스마트 에이전트 상에 새로운 이용가능한 정보가 있는 것을 사용자에게 지시하기 위한 수단을 제공한다. 사용자는 선택적으로, 특정 스마트 에이전트가 통지를 제공 또는 지원하도록 구성하고, 또한 사용자에게 통지를 어떻게 제공할 것인 지를 구성할 수도 있다. 이들 통지는 통지 사용자 인터페이스 구성요소에 의해 제공된다.

통지 매니저는 배경을 관리하고, 스마트 에이전트의 적절한 세트에 대한 질의를 조사하는 것을 책임진다. 라이브 정보 매니저는 결과 브라우저에 유사한 서비스를 제공하는 병렬적 구성요소이다.

통지 매니저는 통지를 위해 표시된 스마트 에이전트의 리스트를 모으고, 새로운 정보에 대한 관련 서버를 주기적으로 조사한다. "New"은 "최종 조사[또는 질의]"로서 규정된다. 조사에 대한 응답마다, 조사에 대한 응답은 통지 매니저가 에이전트와 관련되었음을 입증하는 시간정보 표시를 포함한다.

통지 매니저를 구성하는 것과 관련된 사용자 인터페이스는 에이전트 트리 뷰와 코디네이션으로 바람직하게 구현될 수 있다. 이는 통지를 가능하게 한다(가령, 각각의 스마트 에이전트의 "통지" 팝업 메뉴 옵션). 이용가능한 새로운 결과가 있는 경우, 통지 매니저는 또한 사용자에게 통지하기 위한 대안들을 지원한다. 몇몇 옵션은 에이전트 트리 뷰내의 에이전트에 대한 표시 스타일(가령, 굵게, 칼러로), 리마인더 대화, 오디오 통지, 또는 e-메일, IM 또는 SMS 통지와 같은 좀 더 색다른 액션을 포함한다.

클라이언트측 보안. 클라이언트측 보안에 관한 제문제들은 확장 코드 및 스킨에 관련된다. 스킨은 바람직하게는 XSLT이지만, 또한 스크립트를 지원할 수도 있다. 또한, 생성된 HTML은 ActiveX에 대한 레퍼런스 및 행위를 포함할 수 있다. 프리젠테이션 샌드박스는, 스킨이 스크립트를 통해 잠재적인 마리셔스 코드(malicious code)를 퍼뜨리는 것을 막는 보안 제약을 포함할 수 있다. 예를들어, 구현은 임의의 사인되지 않은 코드(ActiveX 및 DHTML 행위를 포함함)를 완전히 방 지할 수 있다.

바람직하게는, 에이전시와 모든 클라이언트서버의 통신은 공개된 인터페이스로(스킨을 위한)에게 노출되지 않는다. 제 3자는 커스텀 스킨을 제공하기 위해 상기 공개 인터페이스를 커스텀화할 것이다. 주 클라이언트 런타임의 외에는 기능을 고립시킴으로써, 보안을 위태롭게 할 위험성을 감소시킬 수 있다.

코어 사용자 인터페이스 구성요소

에이전트 트리 뷰(Agent Tree View). 이는 에이전트를 제어하고 호출하기 위해 많은 코어 사용자 인터페이스를 지원하는 셀 확장 트리 뷰이다.

시맨틱 환경 브라우징 사용자 인터페이스. 이는 사용자가 시맨틱 환경을 브라우즈하도록 사용자 인터페이스를 제공한다. 이의 예는 "Open Agent Dialog"이다. 이는 에이전트 트리 뷰를 보완한 것으로, 이러한 에이전트 뷰는 이름공간의 계층적 뷰를 또한 표시한다(스크린샷 참조).

에이전트 인스펙터(Agent Inspector). 이는, 특성을 보거나 또는 개별 에이전트, 블렌더 또는 에이전시를 편집(사용자 생성 스마트 에이전트의 경우)하기 위한 사용자 인터페이스를 제공한다.

브라우저 호스트. 이는 시맨틱 브라우저 코어 상의 바람직하게는 "랩퍼(wrapper)"이다-상기 시맨틱 브라우저 코어는 에이전트 트리 뷰내의 에이전트, 에이전시 및 블렌더의 커스텀 뷰를 프리젠테이션할 수 있다. 바람직하게는, 이 브라우저 호스트는 그 자체 어떠한 사용자 인터페이스도 갖지는 않지만, 셀 확장 및 브라우저 프레임워크 사이의 브리지 구성요소이다. 또한, 일체화된 "back/forward" 의 사용자 경험(사용자는 하나의 "back/forward" 히스토리 리스트만 다루어야 함)을 제공하기 위하여, 이 구성요소는 특히 네비게이션("back/"forward") 메카니즘을 포함하여, 윈도우 셀 사용자 인터페이스와 브라우저 기능을 코디네이팅하는 것을 책임진다.

코어 기호 UI. 이는 시맨틱 환경, 서버, 사람 및 에이전트 관리뿐만 아니라, 다방면의 기호 설정까지도 관련된 기호에 대한 사용자 인터페이스를 제공한다. 이는 구식의 특성 시트 대화를 바람직하게 포함하고, 기능적 영역에 이해 분리된 시트로 분할되는 것이 가능하다. 바람직한 실시예에서, 이는 탭된 대화 사용자 인터페이스여야 한다.

스킨 기호 UI. 이는 스킨 매니저에 관련된 기호를 위해 사용자 인터페이스를 제공한다. 이는 바람직하게는 특성 시트 대화이다. 이용가능한 스킨의 리스트는 선택을 위해 리스트로 제공된다. 이 사용자 인터페이스는 사용자가, 디폴트 스킨과는 구별되는 것으로서, 현재 스킨을 설정하게 한다. 바람직하게는 사용자가 현재 스킨을 디폴트로 하게 한다. 에이전트당 스킨 기호에 대해, 바람직하게는, 이는 사용자가 현재 선택되거나 또는 오픈된 에이전트에 대해 스킨을 선택하도록 한다.

통지 UI. 통지 매니저를 구성하는 것과 관련된 사용자 인터페이스는 에이전트 트리 뷰와의 코디네이션으로 바람직하게 구현된다. 또는, 새로운 결과가 이용가능한 경우, 통지 매니저는 사용자에게 통지하기 위한 다른 대안을 지원할 수 있다. 몇몇 옵션은 에이전트 트리 뷰내의 에이전트에 대한 표시 스타일(가령, 굵게, 칼러로), 리마인더 대화, 오디오 통지, 또는 e-메일 IM 또는 SMSM 통지와 같은 색다른 액션을 포함한다. 바람직한 실시예에서, 사용자 인터페이스는, 사용자가 상기 통지 스킴(등)으로부터 선택할 수 있도록 하는 탭된 대화(또는 동등한)를 포함한다.

스크린 세이버. 사용자 인터페이스는 극장 모드 표시에서의 스크린을 채우는, 스크린 세이버와 같이 기능하는 결과 브라우저에 특별한 양상을 바람직하게 제공한다. 바람직한 실시예에서, 스페셜 스킨은 스크린-세이버 모드용으로 사용되어야만 한다. 이들 스킨은 보다 큰 스크린 영역에 영향을 줄 수 있는 다이나믹 표시를 강조할 수 있지만, 대형 폰트 및 보다 큰 공간의 레이아웃을 사용할 수 있다.

브라우저 프레임워크

결과 브라우저. 결과 브라우저는 질의 결과 및 오픈된 임의의 로컬 리소스상의 정보를 표시하는 것을 책임진다. 결과 브라우저는 질의 매니저로부터 하나 이상의 XML 파일을 바람직하게 얻고, 이들을 오브젝트 리스트를 나타내는 단일 XML 파일로 병합한다. 리스트는 초기 단계로서 필터링 또는 소팅된다. 구조로서의 리스트는 리스트를 조정하는 특별한 스킨 클래스(XSLT 변환 시트, 몇몇 스크립트를 포함하는 것이 가능함)에 의해 변환된다. 리스트-스킨은 프라이머리 DHTML(등) 구조, 가령 리스트, 테이블 또는 가능한 타임 시퀀스를 생성한다. 오브젝트 스킨은 각 오브젝트 예에 대한 정보를 제공하는 개별 DHTML 아이템을 관리한다. 리스트-스킨은 개별 오브젝트 스킨(오브젝트 클래스를 스킨으로 매핑)의 디스패치를 조정할 수 있지만, 결과 브라우저는 간략함을 위해 스킨으로의 클래스 디폴트 매핑을 제공한다.

사용자는 프리젠테이션의 주어진 폼을 더욱 선호할 수 있고, 디폴트 스킨(리스트뿐만 아니라, 오브젝트 클래스 둘다)을 선택할 수 있다. 오리지널 질의(즉, SQML)는, 어떤 스킨(특히 어떤 리스트-스킨)이 사용되어야 하는가를 지시하는 파라미터를 또한 포함할 수 있다. 이들은 결과와 함께 결과 브라우저를 통과할 것이다. 결과 브라우저는 라이트(right) 스킨을 선택하고 적용하기 위해 스킨 매니저 장치를 사용한다. 사용자 기호 및 에이전트(저작자) 기호가 어떻게 조합되고 우선화되는지에 대해서는 서로 다른 규칙이 채택될 수 있다.

질의 결과가 다수의 구분되는 XML 파일로 구성된 경우, 일체화된 사용자 경험을 제공하기 위하여, 결과 브라우저는 이들을 단일 XML 문서로 병합한다. 바람직한 실시예는 부가적 결과를 다이나믹하게 조정하는 것을 제공한다. 이 다이나믹 업데이트 모드는 서로 다른 템플레이트 또는 XSLT 템플레이트내의 스크립트 방법을 사용함으로써 바람직하게 구현된다. 그 대안으로는, 리스트 스킨은 사용자 컨텍스트의 혼란없이 문서를 첨가하는 논리(logic)을 관리하기 위해 어떤 행위(또는 로컬 런타임 구성요소)를 요구할 수 있다.

질의 매니저(또는 클라이언트측 시맨틱 질의 프로세서). 질의 매니저는 서버와의 통신을 조정하고, 정보에 대한 요구를 실행하고 XML 결과를 모으는 것을 책임진다. 상기 결과된 XML은 사용자에게 제시(프리젠테이션)하기 위하여 결과 브라우저로 보내진다.

질의 매니저는 스마트 렌즈 기능을 지원하는 서비스를 제공한다. 스마트 렌 즈 요구가 있는 경우, 결과는, 주어진 오브젝트에 대한 스마트 렌즈 결과인 것을 나타내도록 바람직하게 표시되어, XML로서 리턴되고 결과 브라우저로 보내진다. 바람직하게는, 질의 매니저는 질의 요청을 수행하기 위한 개별 서비스를 제공하는 다음의 서브 구성요소를 포함한다.

ㆍ SQML 인터프리터(Interpreter). 이 구성요소는 가능한한 링크된 리소스를 가지면서 통과된 SQML은 요구 세트로 분해되어야만 한다. 각 요구 또는 리소소 링크는 관련 프로토콜(가령, HTTP, 또는 아웃룩과 같은 많은 로컬 의사-프로토콜 중의 하나, 또는 문서)을 갖는 리소스로 분해되고, 관련 프로토콜 핸들러에 디스패치된다. 주어진 SQML 파일은 네트워크 및 로컬 리소스 타입의 블렌드를 포함할 수 있다.

ㆍ 리소스 핸들러(Handler) 매니저. 이는 바람직하게는 리소스 핸들러에 대한 중앙 등록 메카니즘이다. 프로토콜 및 의사-프로토콜을 핸들러와 관련시키고, 리소스 요구의 디스패치를 간략화하는 최소 레이어이다.

ㆍ 리소스 핸들러. 이들은 주어진 "서버"로부터의 리소스를 액세스하는 스펙을 요약하는 구성요소이다. 리소스 핸들러는 임의의 링크된 리소스를 분해하지 못한다. 이는 바람직하게는 SQML 인터프리터의 책임이다(즉, SQML 인터프리터는 이미 분해되고 링크된 리소스 및 이 핸들러에 대한 리소스 요구의 일부로서 제공된 관련 메타 데이터를 가짐). 리소스가 시맨틱 웹 서비스인 경우, 구성요소는 요구를 묶어서 HTTP를 통해 발행시킨다. 리소스가 로컬 리소스(가령, 문서 또는 아웃룩, 리소스)인 경우, 리소스 핸들러는 리소스를 직접 핸들링한다. 문서에 대해서 는, 리소스 핸들러는 메타 데이터를 추출하기 위하여 문서를, 시맨틱의미 추출, 요약 및 카테고리화하는 엔진으로 보낸다. e-메일에 대해서는, 리소스 핸들러는 교환 서버 또는 로컬 PST 파일로부터 메시지를 추출한다. 로컬 리소스 상에 링크가 있는 경우에, 로컬 리소스 핸들러는 시맨틱 관련도를 위해 결과를 필터링하는 처리를 실행해야만 하는 것을 주의해야 한다. 이는 효율성을 위해 핸들러로의 커스텀이될 수 있지만, 중앙의, 일반적인 관련도 엔진이라면 대부분의 경우에 서비스를 제공할 것이다.

ㆍ 관련도 엔진(Relatedness Engine). 이는 관련도를 위해 오브젝트를 비교하기 위한 로직을 모으는 플레이스를 제공한다. 비교는 관계된 구성체계의 블렌드에 따라 바람직하게 의존하지만, 그렇지않으면 간단한 동작(주어진 2개의 오브젝트에 대해)으로서 관련도 측정을 제공한다.

필터/소트 매니저(Filter/Sort Manager). 필터/소트 매니저는 결과 브라우저에 제공된 결과 리스트로의 필터 및 소트의 어플리케이션을 지원한다. 필터/소트 매니저는 현재 설정에 대해 사용자 기호를 얻기 위하여 필터/소트 기호 구성요소의 서비스에 영향을 준다. 이 구성요소의 메인 기능은 일반적인 기호, 에이전트당 기호 및 실제 결과내의 임의의 설정(이것은 지원될수도 있고 안될 수도 있음)을 분석하는 것이다. 사용자가 현재 적용된 필터 및 소트를 변화시키는 경우에, 이 구성요소는 필터/소트 기호 구성요소에 의해 통지된다. 관련 사용자 인터페이스가 셀 확장(가령, 이의 우측-창 뷰)과 관련된 툴 바의 일부이기는 하나, 기능의 적용은 결과 브라우저 스페이스에서 발생하므로, 제어는 일반적으로 간접적이다.

렌즈 모드. 스마트 렌즈가 호출된 경우, 결과 브라우저는 사용자가 선택하는 오브젝트에 대해 렌즈 요구(질의)를 생성시켜야만 한다. 사용자가 각종 오브젝트에 따라 스마트 렌즈 질의를 선택할 수 있고, 결과가 리턴될 때 그 결과를 볼 수 있도록, 질의는 비동기적이다. 이를 위해 제안된 사용자 인터페이스는 스마트 렌즈 아이콘을 위해 약간의 공간을 남겨둔다. 스마트 렌즈 모드에서 사용자가 스마트 렌즈 아이콘을 이동(hover)하는 경우에, 질의가 발행되고, 아이콘은 질의가 진행중인 것을 나타내도록 변화한다. 결과가 리턴된 경우, 스킨내의 전용 스마트 렌즈 템플레이트 및 결과 브라우저에 의해 조정되고, 오브젝트에 따른 스마트 렌즈 아이콘은 결과가 이용가능한 것을 나타내는 것으로 바뀐다. 다시 아이콘을 클릭 또는 이동하면 스킨 특정 방식으로 스마트 렌즈 결과가 표시될 것이다(샘플 스마트 렌즈 창 사용자 인터페이스를 참조). 질의가 충분히 빨리 리턴된다면, 전체 기능은 마우스를 이동하거나 단일 클릭에 의해 활성화된 팝업처럼 느껴진다.

딥 정보 뷰(Deep Info View). 딥 정보가 오리지널 결과에서 이용가능하지 않다면, 이 구성요소는 관련 질의를 생성시킨다. 질의는 바람직하게 비동기이다. 결과가 결과 브라우저로 리턴된 경우, 결과는 적절한 스킨을 통해 처리되어(각 스킨에 대한 스페셜 딥 정보 템플레이트를 사용하여), 결과적 HTML은 관련 오브젝트하의 결과 문서내로 포함된다. 구성체계에 대한 주 스킨은 오브젝트에 따라 HTML내의 딥 정보 소자를 삽입하여 결과 브라우저는 결과가 어디에 포함된지를 알게된다. 딥 정보가 이용가능한 경우(오리지날 결과의 일부로서 또는 딥 정보 질의에 응답하여), 스킨은 이 딥 정보를 직접 표시하거나 또는 이것이 존재한다는 사실을 지시할 것이며, 몇몇 스킨-규정 사용자 인터페이스는 사용자가 표시(가령, 팝업 윈도우로서)를 할 수 있게 할 것이다.

컨텍스트 정보 매니저(Context Info Manager). 결과 브라우저내에 현재 표시된오브젝트에 대하여, 임의의 통지가 디폴트에 의해 바람직하게 제공된다. 새로운 또는 부가적인 정보의 두가지 클래스가 사용자에게 제공될 것이다.

1. 사용자가 오리지널 요구를 만들때 부터 서버에 더해지는 부가적인 결과

이는 헤드라인 또는 액티브 e-메일 쓰레드 등과 같은 것들에 대해 매우 유용하다. 새로운 결과를 뷰에 삽입함으로써, 결과는 결과 브라우저에 의해 조정된다.

2. 사용자가 관심을 가지는 컨텍스트 템플레이트 및 관련 정보

관련성있는 특정 오브젝트를 사용하여, 이는 특정 에이전트(스마트 에이전트, 스페셜 에이전트, 블렌더 또는 에이전시)로 보내진 부가적인 질의에 의해 생성된다. 딥 정보 뷰 및 스마트 렌즈 모드 결과가 조정되는 방식과 유사하게, 질의로 부터 리턴된 XML 처리하고 결과된 HTML을 오브젝트에 따른 기존 HTML에 삽입함으로써, 결과는 조정된다. 스킨은 표시 메카니즘 및 UI를 제어한다. 관련 정보의 예는 오브젝트과 연관된 "Breaking News"이다.

스킨 매니저(Skin Manager). 리스트 스킨, 오브젝트 스킨 및 리스트와 오브젝트 스킨(어떤 오브젝트 스킨은 주어진 리스트 스킨에 대해서만 이해가 된다)간의 의존성에 대한 사용자 기호를 유지한다. 또한 스킨 매니저는 스킨에 대한 제약, 가령 얼마나 큰 스크린이 필요한지, 또는 최적으로 적용되는 양상을 지시하는 각 스킨에 대한 파라미터를 유지한다. 스크린 영역 및 윈도우 사이즈 제약뿐만 아니 라, 양상, 액세스가능성, 언어 및 다른 제약에 대해서도 스킨을 선택하는 것을 도와주는 점에서 상당한 지능이 바람직하게 만들어진다. 초기 버전이 훨씬 간단하다.

스킨 템플레이트(Skin Template). 이는, 스킨 구조 및 그 스킨이 결과 브라우저내로부터 어떻게 적용되는 지를 설명한다. 바람직하게는, 스킨은 결과 XML을 XHTML(및/또는 SVG와 같은 다른 언어) 또는 플래쉬 MX 및 ActionScript와 같은 전용 프리젠테이션 플랫폼으로 변환하는 XSLT 템플레이트이다. 템플레이트는 스타일링 정보, 가령 CSS 스타일링을 삽입할 수 있다. 결과적인 프리젠테이션 코드(가령, XHTML)는 보안의 이유로 코드의 포함을 제한할 수 있다. 결과 브라우저내의 프레임워크 코드는 스킨을 호출한다. 바람직한 실시예는 다음의 스킨 클래스를 포함한다.

ㆍ 리스트 스킨(또는 레이아웃 스킨)(List Skin(또는 Layout Skin)). 리스트 스킨은 질의로부터 총 프리젠테이션 구조로 리턴된 오브젝트 리스트를 변환하는데 사용된다. 이는 간단한 리스트, 테이블 또는 슬라이드의 시간 시퀀스일 수 있다. 리스트 스킨이 어떤 스킨들을 지원할지라도, 리스트 스킨은 구성체계이거나 또는 오브젝트특정인 것은 아니다-상기 어떤 스킨들은 관련 프리젠테이션 형태가 규정하는 제약내에서 작업할 수 있는 것들이다. 가령 테이블 레이아웃을 규정하는 리스트 스킨이, 작은 직각 포맷내에서 정보를 생성할 수 있는 오브젝트 스킨을 요구하거나 선호할 수 있다.

ㆍ 오브젝트 스킨(Object Skin). 오브젝트 스킨은 특정 구성체계이고, 주어 진 정보 오브젝트 타입(또는 정보 클래스)의 개별 오브젝트에 대한 프리젠테이션을 생성한다. 구해진 클래스 또는 서브클래스(몇몇 내용을 생략함으로써)의 영역에 대한 디폴트 스킨으로 기능할 수 있는 일반적 슈퍼-클래스(또는 임의의 다른 슈퍼-클래스)에 대한 스킨을 규정하는 것이 가능하다.

ㆍ 컨텍스트 스킨(Context Skin). 컨텍스트 스킨은 특정 컨텍스트 템플레이트에 묶이고 템플레이트에 의해 지시된 컨텍스트를 가장 효율적으로 전송하는 프리젠테이션을 생성시킨다.

ㆍ 블렌더 스킨(Blender Skin). 블렌더 스킨은 블렌더로부터의 결과를 제공하도록 설계된다. 이들 스킨은 사용자가 블렌더내의 에이전트를 통해, 정보 오브젝트 타입을 통해, 또는 마치 하나의 소스로부터 기인하는 것처럼 모든 결과를 표시하는 병합된 뷰를 통해 결과를 볼 수 있게 한다.

스킨은 형태 및 프리젠테이션 표시 영역 등과 같은 제약을, 제약을 조정함으로써(스태틱 또는 다이나믹하게 브라우저 코어내의 이벤트에 의해 파라미터로서 통과됨) 바람직하게 모델링화한다. 이는, 리스트 스킨이 수령가능한 오브젝트 스킨만을 상술해야만 하는 제약을 부과함으로써, 바람직하게 지원된다. 그 선택적인 방법으로서, 오브젝트 스킨은 주어진 리스트 스킨에 대해 설계되고, 결과 브라우저/스킨 매니저는 현재 리스트 스킨에 대해 오브젝트 스킨을 선택한다.

리스트 스킨 디테일(List Skin Details). 사용자는 현재의 뷰에 대한 단일 리스트 스킨을 선택할 수 있고 이것을 디폴트로 한다. 일반적 디폴트가 무효가 된 경우에 리스트 스킨은 개별 에이전트와 관련될 수 있다. 결과 브라우저는 결과 리 스트를 처리하기 위해 리스트 스킨을 호출하지만, 리스트 스킨은 바람직하게는 개별 오브젝트를 실제적으로 조정하지는 않는다. 리스트 스킨은 프레임워크 프리젠테이션내의 오브젝트당 인스턴스(가령, 시퀀스내의 시간 엔트리, 또는 테이블내의 셀, 또는 리스트내의 아이템)를 생성하고, 오브젝트 스킨은 세부사항들을 채운다.

오브젝트 스킨 디테일(Object Skin Details). 오브젝트 스킨은 특정 구성체계를 XHTML로 변환한다. 비동기 질의에 대한 지원은 딥 정보와 같은 것들을 초래하고, 컨텍스트 템플레이트 정보는 질의 결과 XML 상의 결과 브라우저로부터(DOM을 통해) 관련된 템플레이트를 호출함으로써 제공되어, 결과 XHTML을 DOM 인터페이스를 통해 결과 문서로 삽입한다. 다음의 내용을 포함하는 오브젝트 스킨내의 개별 템플레이트가 존재하는 것이 바람직하다.

ㆍ 프라이머리 구성체계 템플레이트(Primary schema template). 이는 디폴트 표시를 위해, XHTML을 생성시키는 메인 피스(piece)이다. 이는 딥 정보, 스마트 렌즈 정보, 컨텍스트 템플레이트 정보 콘텐츠, 및 관련 표시를 통해 사용자 제어를 제공하는 임의의 스크립트에 대한 랩퍼를 생성해야만 한다.

ㆍ 딥 정보 템플레이트(Deep Information template). 이 템플레이트는 딥 정보에 대한 메타 정보를 조정한다. 이는, 오리지널 결과를 제공하는 인라인 딥 정보를 위해 호출될 수 있고 또한 비동기적으로 요구된 딥 정보를 조정하기 이해 호출된다. 어느 쪽이나, 이 템플레이트는 몇몇 형태로 XHTML을 생성시키며, 상기 XHTML은 딥 정보에 대한 랩퍼 하에서 삽입된다. 삽입은 인라인 딥 정보를 위한 XSLT에서 생성하고, 딥 정보 질의 결과에 대한 DOM 삽입을 통해 달성된다.

ㆍ 컨텍스트 정보 템플레이트(Context information template). 이 템플레이트는 컨텍스트 정보 질의 결과에 대해 결과-정보를 조정한다. 이 템플레이트는 몇몇 형태으로 XHTML을 생성시키고, 상기 XHTML은 라이브 정보에 대한 랩퍼 소자하에서 삽입된다. 삽입은 딥 정보 질의 결과에 대한 DOM 삽입을 통해 달성된다.

ㆍ 스마트 렌즈 정보 템플레이트(Smart lenz information template)). 이 템플레이트는 스마트 렌즈 질의 결과에 대한 결과-정보를 조정한다. 이 템플레이트는 몇몇 형태으로 XHTML을 생성시키고, 상기 XHTML은 라이브 정보에 대한 랩퍼 소자하에서 삽입된다. 삽입은 딥 정보 질의 결과에 대한 DOM 삽입을 통해 달성된다.

바람직한 실시예에서, 템플레이트는 XHTML의 다른 콘텐츠를 변경할 수 없다(동일한 오브젝트에 대해서도). 이것은, 딥 정보, 라이브 정보 또는 스마트 렌즈 결과가 이용가능한 경우를 지시하는 사용자 인터페이스 변화를 코디네이트하기 위한 결과 브라우저에 의존한다. 프레임워크는 사용될(일관성을 위해) 어떤 아이콘을 필요로 하고, 일반적인 이름 또는 소자 타입을 가지게 되어, 결과 브라우저는 필요한 만큼 아이콘들을 변경하고 찾을 수 있다. 또한 결과 브라우저는 상태 변화를 지시하기 위해 이벤트를 생성 및 세울수 있다. 템플레이트-생성 스크립트는 이들 이벤트에 응답하고, 원하는 대로 관련 정보를 표시할 수 있다.

디폴트 스킨(Default Skin). 바람직한 실시예에서, 디폴트 스킨의 세트가 제공된다. 이는 기본 오브젝트 클래스에 대한 스킨을 바람직하게 포함하고, 리스트 스킨의 작은 세트는 질의 결과의 각종 뷰를 허가한다. 바람직한 리스트 스킨은 다음을 포함한다:

ㆍ 상세한 리스트 표시(윈도우 익스플로러 디테일 뷰와 같이)

ㆍ 터뷸러(tabular) 아이콘 뷰(다시, 윈도우 익스플로러 아이콘 뷰와 같지만, 다소 기능이 많음)

ㆍ 시간 프리젠테이션 뷰

e. 클라이언트 프레인워크

바람직한 실시예에서, 시스템 클라이언트는 셀 확장, 프리젠터, 및 컨텍스트 및 의도를 갖는 정보를 표시하기 위해 프리젠터에 의해 사용된 스킨을 포함한다.

셀 확장(shell extension). 익스플로러 셀 확장은 커스텀 코드를 갖는 윈도우 셀을 확장시키는 마이크로소프트 윈도우 소프트웨어 구성요소이다. 셀 확장은 어플리케이션들이 커스텀 코드로서 셀을 사용하게 하고, 또한 데스크탑에서의 클린 통합, 파일-시스템, 인터넷 익스플로러 등과 같은 서비스를 제공한다. 디폴트 셀 확장의 예는 "My Document", "My Computer", "My Network Places", "Recycle Bin" 및 "Internet Explorer"이다.

본 발명의 바람직한 실시예에서의 셀 확장의 사용은 몇몇 장점을 갖는다.

1. 정보를 위해 지식-작업자가 브라우즈하는 방법을 고르게 통합하는 사용자 경험을 제공하는 매우 좋은 방법을 제공한다. 차례로, 전용 클라이언트를 개발해야하는 필요성을 없애고, 마이크로소프트의 인터넷 익스플로러, "My Document" 등을 갖는 비표준 통합을 허용한다.

2. 오늘날의 웹을 받아들이고 오늘날의 웹내의 콘텐츠의 전송을 위해 본 발 명의 정보 신경 시스템에 대한 유입 경로를 제공한다. 예를들면, 사용자는 하드 드라이브(마이크로소프트 익스플로러를 통해) 또는 인터넷(인터넷 익스플로어를 통해)으로부터 본 발명의 셀 확장 상의 원격 에이전트로 문서를 양호하게 드래그 및 드롭한다. 이는 어렵고 전용 클라이언트에게는 비직관적이다. 그럼에도 불구하고, 본 발명은 전용 클라이언트 또는 비윈도우 운영체계 상의 셀 확장의 등가성 및 비개인적 컴퓨터 장치에 대한 운영체계에 대한 이식 가능성(portability)을 고려한다.

본 발명의 셀 확장은 사용자의 시맨틱 환경의 뷰(가령, 히스토리, 즐겨찾기 및 다른 뷰)를 제공한다. 바람직한 실시예에서, 셀 확장은 다음을 제공한다:

1. 사용자에게 에이전트, 문서, 폴더 또는 시맨틱 브라우저의 시맨틱 환경 상의 어드레스를 오픈한다. 에이전트에 대해, 클라이언트는 사용자가 시맨틱 브라우저의 시맨틱 환경을 브라우저할 수 있는 커스텀 "Open Agent" 대화 박스를 표시한다. 이는 사용자의 내 에이전트 리스트, 글로벌 에이전시 디렉토리 상의 에이전시, 로컬 영역 네트워크 상의 에이전시(멀티캐스트를 통해 공표) 및 사용자가 구성한 임의의 커스텀 에이전시 디렉토리 상의 에이전시내의 에이전트를 바람직하게 포함한다. [INSERT RELEVANT SCREEN SHOTS ON UI] 에이전트의 오픈은 결과적으로, 클라이언트가 상기 에이전트의 질의 결과를 표시하도록 한다. 문서의 오픈은 그 문서 오브젝트 타입에 대한 구성체계와 일관되게, 그 문서에 대한 XML 메타데이터를 오픈한다. 폴더의 오픈은 파일-시스템 폴더에 대한 XML 메타데이터를 오픈한다. 사용자는 폴더를 통해 폴더의 딥 또는 중간 콘텐츠를 오픈할 수 있다. 어드 레스의 오픈은 사용자가 클라이언트 프레임워크에 의해 오픈될 임의의 어드레스를 입력할 수 있게 한다. 이는 URL(문서에 대해 XML 메타데이터를 오픈), 파일 시스템 상의 문서, 에이전트 또는 오브젝트를 포함한다(하기의 "URL Naming Convention"을 참조). 에이전트의 경우에, 에이전트 URL은 Agent://＜Agent name＞@＜Agency name＞.＜domain name＞처럼 바람직하게 입력된다. 이는 HTTP URL에 대한 http://＜URL＞ Naming Convention과 유사하다. 오픈 어드레스 옵션은 임의의 어드레스를 오픈할 수 있기 때문에, 이런 경우에 Agent:// prefix(접두사)가 요구된다. "open agent" 옵션의 경우에서는, 사용자는 바람직하게 접두사를 부가할 필요가 없다. 클라이언트 프레임워크는 접두사를 포함하도록 URL을 자동적으로 기준화한다. 이는 사용자가 http:// 접두사를 맞출 필요없이 오늘날의 브라우저내로 "www.foo.com"를 입력시킬 수 있는 방법과 유사하다. 클라이언트는 다른 오브젝트, 예를들면 Microsoft Outlook.PST 파일을 오픈할 수 있는 사용자 기능을 허용하는 것으로 예상된다.

2. 사용자 상태를 지원하는 주어진 에이전시 상의 에이전트로부터 또는 에이전트로 사용자가 브라우즈, 가입 및 미가입할 수 있게 한다.

3. 사용자가 호출된 에이전트 또는 시맨틱 질의 결과를 내 에이전트 리스트에 저장하도록 할 수 있다.

4. 사용자가 블렌더를 생성하고 블렌더로부터 및 블렌더로 에이전트를 부가 및 제거하도록 할 수 있다(드래그 및 드롭을 포함함).

5. 체킹된 최종 시간이후로, 임의의 에이전시 디렉토리 상에 새로운 에이전 시가 있는 경우(예를들어, 글로벌 에이전시 디렉토리, 로컬 영역 멀티캐스트 네트워크 또는 임의의 커스텀 에이전시 디렉토리), 사용자에게 통지한다.

6. 체킹된 최종 시간이후로, 임의의 특정 에이전시 상에 임의의 새로운 에 이전트가 있는 경우, 사용자에게 통지한다.

7. 시맨틱 환경내의 오브젝트에 대해 관계하는 시맨틱 질의에 드래그 및 드롭 액세스를 제공한다. 셀 확장은 사용자가 시맨틱 환경(로컬 드라이브, 네트워크 네이버후드, 인트라넷 또는 인터넷)으로부터 에이전트를 나타내는 셀 폴더로 문서를 드래그 및 드롭할 수 있게 한다. 이는 인자(argument)로서 문서 메타데이터를 갖는 주어진 에이전시에 대한 XML 웹 서비스로 호출하는 원격 절차를 트리거한다.

8. 시스템 클립보드로 복사된 오브젝트에 대한 "첨부" 액세스를 제공한다. 본 발명은 사용자가 후의 액세스를 위해 사용자가 임의의 오브젝트를 복사할 수 있는 시스템 클립보드를 사용한다. 또한, 클립보드는 사용자가 다른 어플리케이션, 예를들어 마이크로소프트 오피스 어플리케이션(가령, 아웃룩으로부터의 e-메일 아이템)으로부터, 멀티미디어 어플리케이션으로부터의 오브젝트를 복사하고 임의의 어플리케이션으로부터 데이터를 복사하게 한다.

9. 사용자가 스마트 렌즈로서 에이전트를 선택할 수 있게 한다. 스마트 렌즈는 사용자가 시스템 클립보드로 복사될 수 있는 에이전트 또는 임의의 오브젝트로부터의 컨텍스트에 기초한 결과 뷰내의 오브젝트를 뷰잉할 수 있게 한다. 예를들어, 일반적으로, 문서 오브젝트가 결과 뷰내에 있고 사용자가 오브젝트를 나타내는 링크로 마우스를 이동하면, 오브젝트 메타데이터가 표시된다. 그러나, 스마트 렌즈가 선택되고(예를들어, 결과 시트 상으로 스마트 렌즈를 첨부함으로써), 사용자가 오브젝트쪽으로 마우스를 이동하면, 스마트 렌즈내의 오브젝트와 관련된 정보 및 커서 아래의 오브젝트가 표시된다. 예를들어, 사용자가 "People.Research.All"을 클립보드로 복사하여 이를 스마트 렌즈로서 붙이고 문서쪽으로 마우스를 이동하면, 메타 데이터는 다음과 같이 발룬 팝업 내에 표시될 수 있다; "이 문서 상에 전문가는 People.Research.All내의 15명을 발견". 다른 예는 "이 문서를 작성한 3명을 발견" 및 "People.Research.All내의 사람에 의해 게시된 이 오브젝트와 관련한 78개의 메시지를 발견". 사용자는 발룬 팝업내의 메타데이터에서 임의의 링크를 호출할 지를 결정한다. 그 대안으로서는, 팝업은 사이드바에서 표시되고 발룬을 필요로 하지는 않는다. 스마트 렌즈가 클립보드상으로 붙여진 경우, 셀 확장은 시스템과 바람직하게 통신하고, 선택된 에이전트의 이름을 반영하도록 마우스 커서를 변화시킨다. 스마트 렌즈가 클립보드로부터 복사되기 때문에, 스마트 렌즈는 글로벌 범위를 바람직하게 갖는다. 환언하면, 예를들어, 윈도우 익스플로어 및 인터넷 익스플로어의 모든 인스턴스는 스마트 렌즈를 "see"하고 이의 액션에 응답한다. 바람직한 실시예에서, 클립보드 상의 현재 오브젝트(가령, 에이전트 또는 다른 오브젝트)에 적용하는 정보 에이전트 툴바에는 스마트 렌즈 툴이 존재한다. 디폴트에 의해 스마트 렌즈 툴은 링크가 시스템에 클릭된 것을 끊을 것이다. 사용자는 스마트 렌즈를 바람직하게 "핀(pin)"할 수 있다. 스마트 렌즈가 핀된 경우에, 스마트 렌즈는 사용자가 핀된 것을 끊을때까지 스마트 렌즈는 액티브로 유지한다. 바람직한 실시예에서, 스마트 렌즈를 핀하기 위해, 사용자는 툴바 상의 "Paste as Smart Lens and pin" 툴을 선택한다.

10. 사용자는 셀 확장으로부터의 에이전트 결과를 "티어-오프(tear-off)"하게 하고 데스크탑 상의 도킹된 결과를 표시할 수 있다. 이 뷰에서, 에이전트 결과 브라우저 윈도우는 시맨틱 티커(ticker)로 작용한다. 이 특징은 사용자가 다른 일을 계속적으로 하면서 시맨틱 정보를 연속적으로 표시할 수 있게 한다.

11. 사용자가 에이전트를 스크린-세어버로서 사용할 수 있다.

12. 사용자가 글로벌 에이전시 디렉토리 상의 이용가능한 스킨을 브라우저하고 호출할 수 있다

프리젠터(Presenter). 프리젠터는 스크립트(또는 다른 플러그-인)로부터의 시맨틱 질의를 취하고 이 결과를 KIS 에이전시 XML 웹 서비스로 넘기는 로컬 구성요소(가령 브라우저 플러그-인)의 세트이다. 본 발명은 시맨틱 질의의 결과를 번역하여, XML을 사용자에게 이벤트적인 프리젠테이션을 위한 다른 행위 또는 스크립트로 통과시킨다.

바람직한 실시예에서, 프리젠터는 SQML 파일을 갖는 셀 확장에 의해 호출된다. 시스템은 직접 XML 웹 서비스와 바람직하게 통신한다. 시스템은 SQML 파일을 분석하여 로컬 또는 원격으로 소싱된(sourced) XML 정보를 오픈하기 이해 호출을 호출한다(SQML 파일내에서 언급된 에이전시 상의 XML 웹 서비스를 통해). 선택적으로는, 에이전트 URL이 시스템으로 통과되면, 프리젠터는 호스트된 에이전트 상의 에이전시의 XML 웹 서비스에 대한 호출을 통해 URL을 호출함으로써 URL을 직접 오픈한다. 바람직한 실시예에서, 시스템은 적절한 시맨틱 오브젝트 타입을 갖는 적 절한 방법을 호출한다. 디폴트 시맨틱 오브젝트 타입의 예는 헤더 파일(semanticruntime.h)을 규정하는 SEMANTICOBJECTYPEID_EVENT, SEMANTICOBJECTTYPEID_EMAILMESSAGE 등이다. 바람직한 실시예는 RegisterSemanticObjectType API를 통해 새로운 시맨틱 오브젝트 타입의 등록을 할 수 있다. 에이전시 상의 이 시맨틱 질의 프로세서는 필터로서 시맨틱 오브젝트 타입을 사용하여 적절한 XML 결과를 리턴시킨다.

바람직한 실시예에서, 본 발명에 따른 스킨(하기를 참조)은 프레임워크로부터 리턴된 XML(XML 웹 서비스로부터의 엔-라우트(en-route))을 DHTML로 변환하기 위해 XSLT(및/또는 스크립트)를 사용한다. 셀 확장은 사용자가 현재의 질의에 대한 새로운 스킨을 선택할 수 있게 한다.

스킨은 바람직하게는 오브젝트-타입 특정, 컨텍스트 템플레이트 특정(스페셜 에이전트에 대한) 또는 블렌더 특정(블렌더에 대한)이다. 또한 스킨은 시맨틱 도메인 이름/경로 또는 에이전트의 온톨로지에 기초하고, 사용자의 페르소나(persona), 조건, 로케이션 등과 같은 다른 속성에 기초하여 커스텀화가 가능할 수 있다. 각 에이전트는 디폴트 스킨을 갖는 에이전시 상에서 구성된다. 본 발명은 루트 에이전시 상으로 공개될 수 있는 커스텀 스킨(가령, 글로벌 에이전시 디렉토리 상)을 또한 고려한다. 클라이언트는 공표된 에이전트에 대한 에이전시로부터 또는 중앙 서버로부터(가령, 글로벌 에이전시 디렉토리) 스킨을 바람직하게 다운로드하여, 스킨을 현재 프리젠테이션에 적용한다. 클라이언트는 에이전트 스킨을 무시하거나 또는 사용자 인터페이스의 일부로 이들을 한정하기 위해 사용자 기호를 선택적으로 포함한다.

바람직한 실시예에서, 스킨 타입(가령, 오브젝트 스킨, 리스트/레이아웃 스킨/컨텍스트 스킨/블렌드 스킨 등)과는 별도로, 스킨은 다음과 같이 카테고리화된다:

ㆍ 디자인 템플레이트 스킨

ㆍ 컬러 템플레이트 스킨

ㆍ 애니메이션 템플레이트 스킨

시맨틱 스킨이 티어-오프(상기 참조)의 일부 또는 스크린세이버로서 표시되는 경우를 제외하고는 시맨틱 스킨은 상호작용하는 것이 바람직하게 요구된다. 각 스킨은 사용자가 "시맨틱 프리젠테이션"에서 특정 지점을 구하도록 한다. 예를들어, 스킨이 초기에 우선 25 아이템만을 표시하면, 스킨은 사용자가 다음 25 아이템을 찾고, 패스트-포워드하고, 리와인드 등을 할 수 있는 시크-바(seek-bar)(또는 다른 사용자 인터페이스 메카니즘)를 가져야만 한다. 몇몇 스킨은 "real-time mode" 옵션을 갖는다. 이 모드에서는, 스킨은 XML 웹 서비스(풀을 통해)로부터의 새로운 오브젝트를 계속 패치한다. 스킨은 원하는 오브젝트의 스키나에 기초한 새로운 정보에 대한 XML 웹 서비스를 조사하는 것을 책임진다. 바람직한 실시예에서, 에이전시가 스캘러빌러티 이유(scalability reason)에 대한 임의의 클라이언트-특정 상태를 유지할 수 없으므로 클라이언트로의 통지는 없다.

스킨은 리얼-타임 모드를 선택적으로 포함한다. 이들 스킨은 우선순위에 기초한 오브젝트를 통해 순환(즉, 프리젠트, 오더 또는 하이라이트)해야만 한다는 점 에서 지능적일 필요가 있다. 예를들어, 새로운 오브젝트가 에이전시 상에서 게시된 것을 나타내는 정보를 프리젠터가 릴레이한다면, 스킨은 이를 즉시 표시/기록/하이라이트하고 남은 오브젝트의 프리젠테이션을 계속한다. 프리젠터는 오더링을 결정하고 스킨은 각종 소트 및 필터 설정을 갖는 다이너미즘(dynamism)을 다룬다. 이는 시맨틱 프리젠테이션이 리얼-타임에서 생성되는 퍼셉션(perception)을 생성한다. 바람직한 실시예에서, 이는 사용자가 스킨을 이용하여 액세스할 수 있는 새로운 데이터가 있는 경우를 생성시킨다. 리스트가 타임-소트된 경우라면, 리얼-타임 프리젠테이션은 상호작용 모드로 사용자 인터페이스가 점핑하므로 사용자를 혼동시킬 수 있다. 몇몇 모드에서 사용자 기호 옵션은 새로운 데이터를 표시하기 위해 스킨을 자동적으로 재설정한다(가령, 새로운 데이터가 리스트의 탑에서 삽입된 경우 소트된 리스트의 상부로 스크롤).

선택적인 실시예에서, 스킨은 이용가능한 프리젠테이션 윈도우의 양에 기초하여 이의 프리젠테이션을 커스텀화 가능하도록 고안된다. 예를들어, 프리젠테이션 윈도우가 상대적으로 작은 경우, 스킨은 페이드-인 및 페이드-아웃을 사용하여 정보를 표시함으로써 스태틱 모드로부터 다이나믹 모드로 변화시킬 수 있다. 스킨은 사용자 상호작용의 기대 레벨에 따라 바람직하게 모달(modal)이다. 예를들어, 스크린 세이버는 브라우저로부터 다르게 작업하고, 도크된 뷰도 마찬가지로 다르다(작고, 또한 사용자 상호작용의 포커스보다는 배경 뷰의 종류로 가정되어 있기 때문에). 뷰는 최소화되거나 숨겨질 때는, 대체의 양상이 사용될 수 있다(특히 새로운 정보를 지시하기 위해). 예는 오디오 통지, 리마인더형 경고, 스타트-바 쇼 및 블링크(아웃룩 리마인터와 같이)이다. 에이전트는 e-메일, 전화 또는 인스턴트 매신저(IM) 통지를 송신하는 데 사용될 수 있다. 선택적인 실시예에서, 본 발명은 웹 사이트로 게시하는 에이전트(가령, 이벤트 캘린더를 위한 자동 HTML 콘텐츠 생성)를 고려한다.

선택적으로, 스킨은 오디오-시각 정보를 생성시킬 수 있다. 예를들면, 문자-대-음성 스킨은 e-메일 오브젝트를 읽을 수 있다. 이 특징은 자동 PC 등의 미허가된 사용자 및 허가된 사용자 뿐만 아니라, 다른 용도에 대한 잠재적인 값을 갖는다.

바람직한 실시예에서, 스킨 프레임워크는 다음의 서비스를 노출시킨다.

1. SQML 기반 시맨틱 질의를 오픈하기 위한 방법, 이는 로컬 SQML 문서, 에이전트등 일 수 있다.

2. 에이전트 URL을 직접 오픈하기 위한 방법.

3. 정보 에이전트 시맨틱 환경을 브라우저하는 방법.

4. 커스텀화 가능한 클립보드 포맷을 사용하여 시스템 클립보드와 인터페이스하는 방법.

5. 주어진 질의 또는 주어진 시맨틱 클래스 ID에 대한 현재 스킨을 존속시키는 방법.

스킨(Skins). 상술한 바와같이, 스킨은 에이전트당 기초하여 사용자 경험을 커스텀화하는데 사용되는 프리젠테이션 템플레이트이다. 바람직한 실시예에서, 스킨은 중앙 서버에 호스트된 XSLT 템플레이트 및/또는 스크립트이다. 본 발명에 따 른 스킨은 XHTML+TIME 코드(가령, 프리젠터 표시, 문자-대-음성, 플러그인을 통해 구조화된 벡터 그래픽(SVG) 등)를 생성시키고, 각종 시스템 서비스를 액세스한다. 바람직한 실시예는 다음의 특징을 지원한다:

1. 표시된 오브젝트의 XML 구성체계에 해당하는 일부 또는 전부의 필드를 표시한다. 스킨은 리턴된 세트내의 오브젝트를 고유하게 구별하는 방법을 사용자에게 제공하거나 또는 종래의 액세스 수단, 예를들어 파일네임, URL 또는 개인 이름(사람에 대해)을 사용자에게 제공한다.

2. 오브젝트가 호스트 에이전시에 의해 이해되었는지의 여부를 지시하는 사용자 인터페이스를 표시한다. 각 오브젝트는 이 정보를 나타내는 "understood" 필드를 바람직하게 포함한다.

3. 시맨틱 오브젝트 타입 SEMANTICOBJECTTYPE_OBJECT에 대해, 스킨은 러(raw) 오브젝트 메타데이터를 선택적으로 표시하거나 또는 러 오브젝트를 표시하는 클래스-특정 오브젝트를 위한 XML 구성체계에 대한 메타데이터를 표시한다. 러 오브젝트를 나타내는 질의에 대한 클래스-특정 XML 구성체계를 표시하는 스킨에 대해, 스킨은 서로 다른 창에서 클래스-특정 정보를 표시하는 "smart"여야만 한다. 이를 이룩하기 위한 바람직한 방법은 프레임, 탭된 박스, 또는 다른 사용자 인터페이스 기술 등이 사용된다. 모든 시맨틱 질의가 러 오브젝트를 지시하므로, 스킨은 필터 SEMANTICOBJECTTYPE_OBJECT(간단히 러 오브젝트를 리턴시킴)를 갖는 질의 또는 요구된 오브젝트 타입 ID를 바람직하게 로드한다. 바람직한 실시예에서, 많은 클래스 중의 러 오브젝트를 갖는 오브젝트 리스트의 프리젠테이션을 준비하기 위해 스킨은 우선 다음의 것을 해야만 한다.

ㆍ 오브젝트 질의를 얻음

ㆍ 각 시맨틱 오브젝트 타입에 대해, 얼마나 많은 오브젝트가 주어진 오브젝트 타입에 대한 에이전트 리소스내에 존지하는 지를 결정해야 한다. 이는 인자(argument)대로, 에이전트 URL인 GetNumObjectsOfClassInAgent를 갖는 에이전시 XML 웹 서비스 및 오브젝트 타입 ID 이름(e-메일, 문서, 이벤트 등)을 호출함으로써 바람직하게 얻어진다. 오브젝트 타입 ID 필터를 만족하고, XML 웹 서비스는 에이전트내의 오브젝트 수를 리턴시킨다.

ㆍ 얼마나 많은 오브젝트 타입이 에이전트 질의내에 있는 지에 따라, 스킨은 프레임 또는 오브젝트 타입의 개수에 대하여 적절한 다른 사용자 인터페이스를 표시한다. 바람직한 실시예에서, 스킨은 오브젝트 타입-특정 메타데이터를 로드할 준비가 된 경우, 인자(argument)로서, 스킨은 에이전트 URL인 ExecuteSemanticQuery를 갖는 에이전시의 XML 웹 서비스 방법 및 시맨틱 오브젝트 타입을 호출한다.

4. 사용자가 오브젝트쪽으로 마우스를 이동한 경우, 오브젝트에 대한 더 많은 메타데이터가 표시될 수 있다.

5. 스마트 에이전트 스마트 렌즈가 선택된 경우, 본 발명의 정보 에이전트는 마우스 아래의 오브젝트를 갖는 스마트 렌즈내의 오브젝트를 매핑하는 컨텍스트 메타데이터를 표시한다. 일 실시예에서, 스마트 렌즈는 프리젠터내에 표시된 오브젝트에 적용한다. 선택적인 실시예에서, 본 발명은 스마트 렌즈가 다른 어플리케이 션(가령, 마이크로소프트 오피스 어플리케이션, 데스크탑 등)에서 호출될 수 있게 한다. 이는 마우스를 트랙하기 위해 시스템 인스톨링 후크를 불러오고, 마우스가 시스템내를 어디던지 움직일 수 있는 경우에 스마트 렌즈 어플리케이션을 부른다. "후크(hook)"는 모든 마우스 이벤트상에서 호출되고, 후크는 마우스를 캡쳐할 것이다. 스마트 렌즈는 비동기적으로 호출될 수 있다. 본 실시예에서, 프리젠터가 새로운 결과를 표시하는 어떤 때라도, 임의의 시맨틱 스마트 렌즈 정보 프리젠테이션이 있는 지를 확인하기 위해 클립보드를 체크한다. 비동기 실시예에서, 프리젠터는 그의 뷰내의 모든 오브젝트에 대한 스마트 렌즈 결과를 자동적으로 캐쉬한다. 이것은 각 오브젝트 옆의 아이콘을 표시하고, 그 안에 컨텍스트-특정 관련 정보가 있는 지를 나타내는 것을 제공한다. 바람직한 실시에에서, 사용자는 뷰내의 임의의 오브젝트에 대한 스마트 렌즈를 호출할 수 있다.

6. 브레이킹 정보(Breaking Information). 각 오브젝트는 오브젝트와 관련하는 "브레이킹 정보"가 존재하는 지의 여부를 지시하는 사용자 인터페이스를 바람직하게 표시한다. 이는 "브레이킹 뉴스"의 시맨틱 등가이다. 사용자 인터페이스는 정보의 중요성을 지시하기 위해 제공되지만, 사용자가 이 정보를 보기를 원하지 않는 경우에는 너무 끼어들지 않아야 한다. 예를들어, 사용자 인터페이스는 오브젝트 표시 윈도우의 코너에서 천천히 반짝거리는 아이콘으로서 표시될 수 있다. 사용자가 아이콘으로 마우스를 이동한 경우, "브레이킹 정보" 상의 메타데이터는 표시된다. 바람직한 실시예에서, "브레이킹 정보"는 브레이킹 뉴스 컨텍스트 템플레이트를 사용하여 모든 에이전트에 대해 호출을 호출하는 고유 스페셜 에이전트에 의해 구현된다.

7. 각 오브젝트는 오브젝트가 임의의 주석을 갖는 지의 여부를 지시하는 사용자 인터페이스를 갖도록 바람직하게 표시될 수 있다. 이 정보는 모든 오브젝트에 대해 모든 질의 결과내의 필드로서 포함된다.

8. 바람직하게는, 각 오브젝트는 클라이언트 상의 스페셜 에이전트 또는 임의의 사전 규정된 컨텍스트 템플레이트 상에 관련 정보가 있는 지의 여부를 지시하는 사용자 인터페이스를 표시된다. 이는 사용자에 의해 생성된 스페셜 에이전트뿐만아니라, 디폴트 스페셜 에이전트(가령 클라이언트에 의해 인스톨된)를 바람직하게 포함한다. 바람직한 실시예에서, 컨텍스트 템플레이트용 컨텍스트 팔레트는 하나 이상의 컨텍스트 팔레트를 표시, 이들을 숨김, 이들을 스크롤(컨텍스트 팔레트를 네비게이션하기 위해)하는 등의 옵션을 갖는 사용자로 표시된다. 컨텍스트 템플레이트 및 컨텍스트 팔레트는 다음에서 더욱 상세히 설명된다. 선택적인 실시예에서, 에이전시 우선순위는 다음을 포함한다.

ㆍ 결정적인 우선순위(Critical Priority). 이것은 가장 높은 우선순위이다. 예를들어, 주어진 문서에 대해, 관련 e-메일 메시지가 막 게시되었거나(본 예에서는 몇분) 또는 절박한 이벤트가 있는 경우에는 이 플래그는 TRUE(에이전시상에서)일 것이다.

ㆍ 높은 우선순위(High Priority). 이것은 그 다음 높은 우선순위이다. 피드백이 매우 끼어들지 않는다면, 사용자 인터페이스 피드백은 우선순위가 사용자의 주의를 보증하기 이해 충분히 높은 것을 명백히 한다. 우선순위는 서로 다른 사용자 가령, 이벤트가 원격(특히 이벤트에 참가하는 원격 사용자에 대한 어떤 방법도 없는 경우)인 경우보다 사용자에게 우선순위가 더 높은 로컬 이벤트인 경우에 대해, 선택적으로 다르다.

ㆍ 중간 우선순위(Medium Priority). 이것은 사용자가 갖는 시간으로 보아야만 하는 정보가 있는 지를 단지 지시한다. 사용자 인터페이스 피드백은 이를 명백히 해준다.

ㆍ 낮은 우선순위(Low Priority). 이것은 적절하지만 최근이 아닌 관련 정보가 있는 지를 지시할 수 있다.

4개의 우선순위 가상 블렌더는 클라이언트 상의 디폴트에 의해 바람직하게 인스톨된다. 이들 블렌더는 내 에이전시 리스트내의 각 에이전시 상의 대응 우선순위 에이전트로부터의 정보를 자동적으로 집합한다. 모든 에이전시 상의 디폴트 우선순위 에이전시가 바람직하게 있다. 바람직한 실시예에서, 관계 시맨틱 질의는 컨텍스트 및 사용자를 고려한다.

바람직한 실시예에서, 각 컨텍스트 템플레이트(또는 현재 선택된 컨텍스트 템플레이트)에 대해, 프리젠터는 사용자가 그들의 내 페이브리트 에이전시 리스트 또는 최근 에이전시에 부가하는 에이전시를 열거하고, 컨텍스트 템플레이트에 기초한 현재 오브젝트와 관련된 임의의 오브젝트가 존재한다면, 다이나믹하게 생성된 SQML을 사용하여 적절한 에이전시를 찾도록 질의한다. 페이브리트 또는 최근 리스트내의 임의의 에이전시를 액세스할 수 없다면, 사용자 인터페이스는 에이전시를 무시함으로써 이것을 명백히 조정할 수 있다. 바람직한 실시예에서, 디폴트에 의 해, 다이나믹하게 생성된 SQML은 현재 선택된 오브젝트의 SRML의 SQML을 인덱싱하고, 컨텍스트 템플레이트의 SQML내의 링크 필터로서(바람직하게 디폴트 술어 "relevant to"를 사용하여) SQML내의 리소스를 삽입함으로써 생성된다. 이는 현재 선택된 오브젝트의 오브젝트 타입을 표시된 컨텍스트 팔레트의 시맨틱으로 매핑을 지능적으로 조정한다. 예를 들면, 만약 현재 선택된 오브젝트가 문서라면, 헤드라인 컨텍스트 팔레트는 헤드라인 컨텍스트 템플레이트를 위한 SQML의 파생물에 기초하여 SQML을 사용한다. 시맨틱 환경내의 각 에이전시는 디폴트 술어를 적절히 사용하여 결과적인 SQML을 시맨틱하게 처리한다. 다른 예에서, 선택된 오브젝트가 사람이라면, 헤드라인 팔레트는 사람과 관련한 헤드라인, 가령, 저술된 "헤드라인" 또는 사람에 의해 주석을 단 것을 보여준다. 선택적으로, 현재 선택된 오브젝트가 문서 또는 e-메일 메시지인 경우, SQML(디폴트 술어를 갖는)은 각 에이전시 상의 시맨틱하게 관련된 헤드라인을 나타내는 시맨틱 결과를 생성한다. 이들 결과는 컨텍스트 팔레트에 바람직하게 표시된다. 다른 컨텍스트 팔레트(가령, 클래식, 뉴스메이커 등)에도 동일하게 적용된다.

사람 오브젝트에 대해, 우선순위 플래그는 바람직하게 사람이 게시하는 오브젝트 또는 사람이 저작된 오브젝트를 참고하거나, 호스트한다. 본 예에서, 시맨틱 고유성을 갖는 메타데이터 필드만이 이 결정(가령, 사람의 e-메일 어드레스)이 이루어지도록 바람직하게 사용된다.

9. 각 오브젝트는 많은 조작 옵션을 포함하는 사용자 인터페이스를 표시한다. 이 예만에 의해, 샘플 사용자 인터페이스는 도 54에 도시한 정보 에이전트(시 맨틱 브라우저) 결과 창에 표시된 정보 오브젝트를 도시한다. 도 54는 레코멘데이션 컨텍스트 창, 브레이킹 뉴스 컨텍스트 창, 동사 팝업 메뉴 등과 같은 툴 옵션을 사용자가 호출하도록 하는 오브젝트 상의 사용자 인터페이스 아이콘 및 발룬 팝업(오브젝트의 메타데이터에 대한)을 나타낸다. 부가적 및 다른 사용자 인터페이스 옵션은 다음을 포함한다:

ㆍ 고유 시맨틱 링크(Intrinsic Semantic Links). 이들은 오브젝트의 시맨틱 클래스에 대해 고유한 링크이다. 고유 시맨틱 링크가 없다면, 표시되기 위해 필요한 것은 아무것도 없다. 이 예에 의해, 바람직한 실시예의 e-메일 오브젝트는 다음의 고유 시맨틱 링크를 포함한다.

1. From List -＞

1. Person A

2. To List -＞

1. Person B

2. Person C

3. Cc List -＞

1. Person D

2. Person E

4. Bcc List -＞

1. Person F

2. Person G

5. Attachments -＞

1. Document 1

2. Document 2

3. Document 3

바람직한 실시예에서, 임의의 이들 시맨틱 링크가 사용자에 의해 호출된 경우, 클라이언트는 관련 오브젝트(오브젝트 자체는 아님)에 대한 메타데이터를 패치한 다. 이는 사용자가 오리지널 오브젝트의 양태에 대해 시맨틱 정보를 익스플로어하게 한다. 스킨은 적절한 방법을 갖는 오브젝트를 호스트하는 에이전시의 XML 웹 서비스를 바람직하게 호출한다. 바람직한 실시예에서, 이 방법의 형태는 ISemanticRuntimeService::LoadNativeSemanticLink이다. 본 실시예는 시맨틱 클랙스 ID, 시맨틱 링크 이름, 인자(argument) 이름 및 인자(argument)의 스트링 형태를 포함한다. 예를들어, 제3 첨부(제로-기반 인덱스를 가짐)에 대해 "navigate"하기 위해, 스킨은 LoadNativeSemanticLink(SEMANTICCLASS_EMAILMESSAGE, "Attachments", "Index", 2)를 호출해야만 한다. 이는 이 관계된 시맨틱 질의를 나타내는 SQML이 생성되고, 이 SQML을 갖고 스마트 에이전트를 로드하는 새로운 임시 스마트 에이전트를 바람직하게 생성한다. 이는 바람직한 시맨틱 네비게이션을 나타낸다. 이 프로세스는 선택적으로 반복한다. 사용자는 임의의 새로운 오브젝트 및 관점 등을 사용하여 새로운 결과를 네비게이트할 수 있다. 본 발명에 따른 e-메일 샘플을 나타내는 고유 시맨틱 링크와 관련된 발룬 팝업의 예는 도 55에 도시된다. 이 샘플 사용자 인터페이스에서, 사용자가 결과 창내의 정보 오브젝트 상 의 "Intrinsic Links"를 선택한 경우, 팝업 메뉴가 표시된다. 이 예시는 고유 시맨틱 링크 사용자가 e-메일 오브젝트에 대해 무엇을 보는 지를 나타낸다. 바람직한 실시예에서, 사용자가 메뉴 옵션을 친 경우에, 팝업 메뉴 아이템은 새로운 SQML 질의(적절한 리소스 및 술어 링크)를 호출한다. 새로운 임시 에이전트가 질의 결과를 나타내면서 생성된다(SQML을 가짐). 사용자는 그들의 페이브리트 리스트내에 에이전트를 저장할 수 있다. 또한 새로운 결과는 고유 시맨틱 링크, 컨텍스트 템플레이트 등을 표시하여, 사용자가 정보를 시맨틱하게 네비게이트할 수 있는 경우에 사용자-제어 브라우징을 지원한다. 자연 동사에 대한 선택적인 구성 및 기능은 다음과 같다:

ALL INFORMATION:

에이전시 상의 관련 정보를 찾음(이는 에이전시로부터만 온다)

에이전시 상의 관련 정보를 가능한한 찾음(이는 에이전시로부터만 온다)

Open Annotations -＞

All

Annotation 1

Annotation 2

Annotation 2

EMAIL: +=

From List -＞

Person A

To List -＞

Person B

Person C

Cc List -＞

Person D

Person E

Bcc List -＞

Person F

Person G

Attachments -＞

Document 1

Document 2

Document 3

PERSON:

Reports To -＞

Direct Reports -＞

Member of Distribution Lists -＞

Information Authored By -＞

Information Annotated By -＞

Information with categories of which this person is an expert -＞

CUSTOMER:

Information Authored By -＞

ㆍ 주석. 이는 사용자가 현재의 오브젝트를 위해 모든 주석에 대해 요약을 바람직하게 네비게이트하게 한다. 바람직한 실시예에서, 스킨은 ISemanticRuntimeService::EnumAnnotations(인자(argument)로서 오브젝트 메타데이터를 가짐)를 호출함으로써 모든 주석을 표시한다. 이는 주석 오브젝트에 대한 메타데이터를 갖는 속성 테이블의 XML 표현을 리턴시킨다. 스킨은 표시될 주석 요약의 몇몇 표현(가령, 주석의 이름 또는 타이틀)을 바람직하게 표시한다. 주석 링크가 사용자에 의해 호출된 경우, 스킨은 주석 오브젝트에 대한 메타데이터를 표시한다. 이들 기능은 클라이언트 상에 적용된 필터에서부터 바람직하게 기인한다. 선택적으로, 이들 기능은 에이전트로서 생성될 수 있다. 본 발명의 이 양태는 시맨틱 내비게이션을 또한 나타낸다. 주석은 "annotations" 질의의 SQML 표현을 사용하여 바람직하게 로드된다. 이는 SQML을 갖는 새로운 스마트 에이전트를 생성한다. 다음으로, 스마트 에이전트는 "recent" 리스트에 부가되고 로드된다(또는 네비게이트됨). 프로세스는 선택적으로 반복적이다. 사용자는 관점 등으로서 새롭게 표시된 주석을 사용하여 네비게이트할 수 있다.

ㆍ 관련된 오브젝트(Related Object). 바람직한 실시예에서, 이는 정보 오브젝트 관점으로서 현재 오브젝트를 사용하여, 사용자의 내 에이전시 리스트에 포함된 각 에이전시 상의 관련 정보를 사용자가 선택적으로 찾게 한다. 이는 (셀 확 장 사용자 인터페이스 상의) 복사와 첨부 또는 신뢰에 대해 다시 소트할 필요없이 바람직하게 이룩된다. 바람직한 실시에에서, 사용자 인터페이스 팝업은 다음의 포맷내의 정보를 나타낸다:

Find Related Objects --＞

All my agencies --＞

Agency Foo --＞

All.All

All.Understood.All

All.CriticalPriority.All

All.HighPriority.All

All.MediumPriority.All

All.LowPriority.All

All.MyFavorites.All

All.Recommended.All

Agencies that understand this object --＞

Agency Bar --＞

All.All

All.Understood.All

All.CriticalPriority.All

All.HighPriority.All

All.MediumPriority.All

All.LowPriority.All

All.MyFavorites.All

All.Recommended.All

"All my agencies" 리스트는 국부적으로 등록된 에이전시 사용자를 열거함으로써 프리젠터에 의해 간단히 얻어진다. 프리젠터는, 당해 오브젝트를 이해하는 지의 여부에 대해 각각 국부적으로 등록된 에이전시를 "asking"에 의해서 "Agencies that understand this object" 리스트를 리턴시킨다. 프리젠터는 오브젝트의 XML 표현을 에이전시로 통과시켜, XML 표현의 시맨틱 프로세스를 시도한다. 에이전시는 오브젝트를 이해하는 지의 여부를 나타내는 플래그를 리턴시킨다. 각 오브젝트는 에이전시가 그의 콘텐츠를 이해하는 지의 여부를 지시하는 필드를 가지기 때문에, 프리젠터는 호스트된 오브젝트 상의 에이전시를 제외함으로써 리턴된 리스트를 최적화한다.

ㆍ 동사(Verbs). 이는 현재 오브젝트와 직접 관련있는 임의의 액션을 사용자가 호출할 수 있게 한다. 예를들어, 문서 또는 e-메일 메시지는 "open" 동사를 가질 수 있다. 이는 워드 프로세서 또는 e-메일 클라이언트를 오픈하고, 정보를 표시한다. 이벤트는 "Add to Outlook Calendar" 동사를 가질 수 있다. 바람직한 실시예에서, 동사, 바람직하게는 클래스-특정은 시스템 프레임워크에 의해 클라이언트 상에서 호출된다. 에이전시는 동사에 대해 아무것도 알 필요가 없다. 본 발명의 바람직한 실시예에서, 모든 오브젝트에 대해 몇몇 동사가 있다. 이들 동사는 팝업 메뉴에서 우선 바람직하게 표시된다. 바람직한 실시예의 동사는 다음을 포한함다:

1. Annotate : 사용자가 이 동사를 호출하는 경우, 스킨은 클라이언트 런타임과 통신하고 주석 방법을 호출한다. 이 방법은 적절한 서브젝트 라인(주석을 해석하기 위해 에이전시가 분석)을 갖는 디폴트 메일 클라이언트를 개시한다. 사용자는 오브젝트에 대한 주석으로서 일반적인 e-메일 메시지를 송신한다. e-메일 주석은 시맨틱 링크를 구성하는 첨부를 선택적으로 포함한다. 이는 사용자가 오브젝트(가령, 문서)로부터 그의 주석으로, 그의 첨부 및 외부 콘텐츠 소스(가령, 스마트 렌즈)로 네비게이트할 수 있게 한다. 선택적인 실시예는 주석, 가령 간단한 형태-기반 또는 대화-기반 주석에 대해서도 지원한다. 그러나 e-메일은 가장 풍부한 시맨틱스를 제공한다.

2. Copy : 이는 오브젝트 XML을 시스템 클립보드로 복사한다.

3. Hide : 이는 사용자가 뷰잉 오브젝트내에서 관심사가 없다는 것을 지시한다.

4. Open : 이는 무엇이 오픈될 것인지에 관한 링크를 수식화한다. 문서의 예에서, "Open Document"가 표시될 수 있다. e-메일 메시지인 경우, "Open Email"이 표시될 수 있다. 클라이언트는 링크의 MIME 타입에 대한 시스템내에 등록된 디폴트 어플리케이션을 갖는 오브젝트를 오픈한다. 선택적인 실시예에서, 본 발명은 "Open with ..." 등과 같은 다른 관련 오픈 동사 형태를 지원하여, 사용자가 특정 어플리케이션을 갖는 오브젝트를 오픈할 수 있게 한다.

5. Mark as Favorite : 이는 에이전시가 사용자 상태를 지원하고, 오브젝트가 페이브리트가 아니라면 바람직하게 표시된다.

6. Unmark as Favorite : 이는 에이전시가 사용자 상태를 지원하고, 오브젝트가 페이브리트라면 바람직하게 표시된다.

본 발명에 따른 동사 사용자 인터페이스와 관련된 발룬 팝업의 예는 도 56에 도시한다. 이 샘플의 사용자 인터페이스에서, 팝업 메뉴는 사용자가 결과 창내의 표시된 정보 오브젝트 상의 "Verbs" 아이콘을 친 경우에 표시된다. 메뉴는 오브젝트 타입(가령, 문서, e-메일 사람 등)에 기초한 정보 오브젝트를 위한 관련되고 지원된 액션을 나타낸다. 본래의 동사에 대한 선택적인 구성 및 기능은 다음과 같다:

ALL INFORMATION:

ㆍ Annotate(아웃룩 오픈; 오브젝트가 에이전시로부터이면, 에이전시의 e-메일 에이전트 어드레스는 "to" 필드에 채워짐; 그렇지 않다면, "to" 필드는 비어 있고 사용자는 오브젝트 주석을 위해 에이전시에 지시할 수 있다; 오브젝트가 에이전시로부터가 아니면, 오브젝트는 URL 또는 풀-블론(full-blown) 첨부로서 e-메일 메시지에 첨부되어야만 한다)

ㆍ Copy

ㆍ Open

ㆍ Mark as Favorite(클라이언트 상에 저장됨)

ㆍ Unmark as Favorite

PERSON AND CUSTOMER :+= "Send Email"

10. 스킨이 새로운 질의 또는 하나 이상의 오브젝트에 대해 메타데이터를 로드한 경우, 스킨은 질의 또는 메타데이터를 갖는 프레임워크를 바람직하게 호출한다. 바람직한 실시예에서, 스킨은 질의를 실행하지 못하지만, 결과를 관리하는 프리젠터 런타임으로 질의를 통과시킨다.

11. 딥 정보(또는 프리젠테이션) 모드 : 본 발명의 선택적인 실시예는 딥 프리젠테이션 모드를 위해 스킨 지원을 제공한다. 본 실시예에서, 스킨은 현재 오브젝트에 대해 관련 정보가 있는 지의 여부를 지시하는 사용자 인터페이스를 표시한다. 또한 스킨은 정보를 설명하는 문자를 표시한다. 예를들어, 주어진 문서 오브젝트에 대해, 스킨은 "Jane Doe는 이 오브젝트 ＜summary of email message＞와 관련된 가장 최근 e-메일 메시지를 게시함"인 문자를 갖는 팝업을 표시할 수 있다. 본 실시예에서, 스킨은 가장 최근 게시된 관련 오브젝트 또는 가장 급하게 올라오는 오브젝트 등과 같은 특정 정보를 구체적으로 나타낸다. 스킨은 사용자가 관심을 가질 수 있는 다른 "truth" 또는 추론 데이터를 선택적으로 표시할 수 있다. 예는 다음을 포함한다:

ㆍ Lisa Heiborn은 최근에 관련 문서를 게시했음: ＜summary＞

ㆍ 이 문서의 가장 가능한 저작자는 ＜foo＞임

ㆍ Steve Judkin은 Patrick Schmitz에게 보고한다. Patrick은 단 하나와 관려뇐 54개의 중요 우선순위 오브젝트를 게시함

ㆍ 이 문서는 3 사람의 가능한 전문가를 가짐:＜name＞

ㆍ Yuying Chen은 이 문서 상에 가장 전문지식을 가진 것으로 보임

본 발명은 스킨이 정보를 얻기 위해 사용하는 몇개의 "semantic depth" 레벨을 갖고 있다. 또한 스마트 렌즈는 딥 프리젠테이션 모드르 지원하기 위해 구성될 수 있다. 환언하면, 바람직한 실시예에서, 오브젝트 상의 스마트 렌즈를 호출하는 것은 상술한 것과 유사한 딥 정보를 리턴시킨다. 스킨은 오브젝트 표시 윈도우의 코너의 아이콘을 나타낸다. 사용자는 "딥 정보"를 표시하는 아이콘을 클릭할 수 있다. "딥 정보"에 대한 메타데이터는 비동기적으로 선택적으로 패치될 수 있다.

본 발명에 따른 딥 정보 모드 사용자 인터페이스와 관련된 발룬 팝업의 예는, 컨텍스트 결과 창에서 제공된 것처럼 도 57에 도시되어 있다. 이 샘플에서는, 사용자는 표시하기 위해 어떤 종류의 딥 정보를 필터링하는 딥 정보에 대한 템플레이트를 선택하고, 시맨틱 환경내에 있는 오브젝트 등(예를들어, "Steve Judkin" 사람 오브젝트, "전문가" 컨텍스트 템플레이트 결과 오브젝트, "다이렉트 리포트" 술어 필터를 사용하는 "다이렉트 리포트" 오브젝트)에 대한 시맨틱(SQML) 링크를 따라, 딥 정보의 "stories"를 보는 옵션을 갖는다. 또한, 사용자는 프리뷰 플레이어/제어를 사용하여 적절한 시맨틱 질의 결과를 프리뷰하는 옵션을 갖는다.

e. 시맨틱 질의 문서

클라이언트의 예상으로부터, 이를 이해하는 모든 것이 질의 문서이다. 본 발명에서는, 클라이언트는 워드 프로세서가 "textual and compound document"를 오픈하는 것가 유사한 방식으로 "질의 문서"를 오픈한다. 클라이언트는 시맨틱 질의 문서를 처리하고 결과를 렌더링하는 것을 주로 책임진다. 시맨틱 질의 문서는 시 맨틱 질의 마크업 랭귀지(SQML)의 형태로 바람직하게 표현되고 저장된다. 이는 "시맨틱 파일 포맷"과 유사하다. 바람직한 실시예에서, SQML 시맨틱 파일 포맷은 다음으로 구성된다.

ㆍ Head : 헤드 태그는 문서를 설명하는 태그를 포함한다.

ㆍ Head:Title-이는 문서의 타이틀을 나타낸다.

ㆍ Filters : 모든 프리젠터 필터는 "필터" 태크내의 엔트리를 사용하여 오브젝트를 리턴시킨다. 이들 엔트리는 오브젝트 타입 이름(문서, 이벤트, e-메일 등)을 선택적으로 갖는다. 어떤 필터도 구체화되지 않는다면, 어떤 오브젝트도 필터링되지 않는다. 태그는 엔트리가 포함되는지 또는 제외되는지를 지시하는 퀄리파이어(qualifier)를 갖는다. 중복된 엔트리("포함" 및 "제외" 태그 둘다를 지시함)의 경우, 인터프리터는 엔트리를 제외시킨다(즉, 타이의 경우, "제외"가 가정됨).

ㆍ Attribute : 이 태그는 문서의 속성을 지시한다.

ㆍ Skin : 이는 모든 스킨-관련 엔트리에 대한 패런트(parent) 태그이다.

ㆍ skin:＜objecttypename＞ : 이는 "object type name"내에서 지시된 오브젝트 타입의 오브젝트를 관리하기 위해 스킨에 대한 정보를 갖는다. 프리젠터는 SQML 문서내의 스킨 엔트리에 해당하는 것을 갖지 않는 오브젝트에 대한 디폴트 및 에이전트 스킨을 사용한다. 옵션은 다음을 바람직하게 포함한다:

ㆍ skin:＜objecttypename＞:color : 이는 이 문서와 같이 사용된 컬러 템플레이트 상의 정보를 갖는다. 주 엔트리는 XSLT URL이다.

ㆍ skin＜objecttypename＞:design : 이는 이 문서와 같이 사용된 디자인 템플레이트 상의 정보를 갖는다. 주 엔트리는 XSLT URL이다.

ㆍ skin:＜objecttypename＞:animation : 이는 이 문서와 같이 사용된 에니메이션 템플레이트 상의 정보를 갖는다. 주 엔트리는 XSLT URL 이다.

ㆍ Query : 이는 질의 문서의 모든 메인 질의 에트리에 대한 패런트 태그이고 다음을 포함한다:

ㆍ Resource : 질의되는 리소스에 대한 레퍼런스이다. 예는 파일 경로, URL, 캐시 엔트리 식별자 등을 포함한다. 이들은 인터프리터에 의해 실제 리소스 매니저 구성요소로 매핑될 것이다.

ㆍ resource:type ; 이름공간을 갖고 수식화된 리소스 레퍼런스의 타입이다. 규정된 리소스 레퍼런스 타입의 예는 nevarna:url(이는 리소스가 잘 형성된 표준 인터넷 URL 또는 "agent://..."와 같은 커스텀 URL인 것을 지시함) 및 nevarna:filepath(이는 리소스 레퍼런스가 파일-시스템 상의 파일 또는 디렉토리로의 경로인 것을 지시함)가 있다.

ㆍ resource:arg : 이는 인터프리터가 리소스 레퍼런스를 실제 리소스로 변환하는 경우, 리소스로 통과될 선택적인 스트링을 나타낸다. 실행가능한 파일에 대한 코맨드 라인 인자(argument)와 등가이다. 몇몇 리소스는 rref의 일부로서 인자(argument)를 해석할 수 있고, rref 인자(argument)의 일부가 아닌 것도 있다. 예를들어, 표준 URL은 URL 자체의 종단에서의 rref 인자(argument)를 통과시킬수 있다("?" 태그를 갖는 접두사로).

ㆍ resource:version : 다음을 참조

ㆍ resource:link : 모든 링크 태그

ㆍ resource:link:predicate : 이는 링크에 대한 술어 타입을 지시한다. 예를들어, 술어 nervana:relevantto는 질의가 "오브젝트 O와 관련된 리소스 R로부터의 모든 오브젝트를 리턴시킴"다는 것을 지시하고, 여기에서 R 및 O는 특정 리소스 및 오브젝트를 각각 지칭함. 술어의 다른 예는 nervana:reportsto, nervana:teammateof, nervana:from, nervana:to, nervana:cc, nervana:bcc, nervana:attachedto, nervana:sentby, nervana:sentto, nervana:postedon, nervana:containstext 등이다.

ㆍ resource:link : 이는 시맨틱 링크의 오브젝트에 대한 레퍼런스를 나타낸다.

ㆍ resource:link:type : 이는 오브젝트 레퍼런스의 타입이 "oref" 태그내인 것을 나타낸다. 예는 xml:string, xml:integer를 포함하는 표준 XML 데이터 타입과, nervana:datetimeref("todat" 및 "tomorrow"과 같은 오브젝트 레퍼런스를 나타냄)를 포함하는 커스텀 타입과, 임의의 표준 인터넷 URL(HTTP, FTP, 등) 또는 본 발명이 시맨틱 XML 오브젝트로서 처리할 수 있는 오브젝트를 나타내는 시스템 URL(object://, 등) 등이 있다.

ㆍ resource:link:version : 이는 리소스 시맨틱 링크의 버전을 나타낸다. 이는 에이전시의 시맨틱 질의 프로세서가 버전된 결과를 리턴시키도록 한다. 예를들어, 시맨틱 브라우저의 하나의 버전은 질의 V1을 사용할 수 있고, 다른 버전 V2를 사용할 수도 있다. 이는 에이전시가 리소스 레벨(가령, 에이전트에 대한) 및 링크 레벨 둘다의 후방 호환성을 제공하도록 한다.

ㆍ Query Type : 이는 이 SQML 버퍼 파일의 질의 타입을 나타내는 것을 지시한다. 바람직한 실시예에서, 이는 에이전트, 에이전시, 스페셜 에이전트 및 블렌더를 포함한다.

ㆍ Query Return Type : 이는 오브젝트 질의의 타입(가령, 문서, e-메일, 헤드라인, 클래식 등)을 리턴시키는 것을 지시한다. 선택적으로, 이는 정보 오브젝트 타입의 이름, 컨텍스트 템플레이트 등을 지시할 수 있다.

예에 의해서, 본 명세서의 첨부 SAMPLE B는 본 발명에 따른 시맨틱 질의 문서를 나타낸다.

바람직한 실시예에서, 프리젠터는 SQML 인터프리터를 포함한다. 프리젠터는 SQML 파일을 오픈시키는 경우, 우선 파일을 분석하고, 유효화시키고, 마스터 엔트리 테이블을 생성시키고, 엔트리 테이블내의 엔트리를 실행시킴으로써 파일을 바람직하게 해석한다. 효과적으로, 파일을 "실행"하기 전에 SQML 파일을 "편집"하고, 다른 모듈을 가지면서 링크되고 실행되기 전에, 언어 컴파일러가 소스 코드를 오브젝트 모듈로 편집하는 방법과 유사하다. SQML 인터프리터의 경우에, 이 프로세스는 레퍼런스를 통해 다른 SQML 파일의 로딩을 선택적으로 호출한다. 이 프로세스는 바람직하게는 주기적이지 않다. 클라이언트는 각 공표된 오브젝트 타입에 대해 정보를 표시하기 위해 "＜skin＞" 태그(사용가능하고 디폴트 또는 에이전트 스킨에 의해 무효로 되지 않는다면)에서 XSLT 템플레이트를 사용한다. 공표된 스킨을 갖 지 않는 임의의 리턴된 오브젝트는 오브젝트 타입의 디폴트 스킨을 가지고 표시되고 또는, 단일 에이전시 엔트리의 경우에서, 에이전트의 디폴트 스킨을 가지고 표시된다(하나가 특정되면).

선택적인 실시예에서, 시맨틱 질의 문서가 오픈된 후일지라도, 클라이언트는 각 오브젝트 타입을 표시하기 위해 새로운 스킨을 로드할 수 있다. 본 실시예에서, "＜skin＞" 태그는 스킨이 초기에 질의를 로드하는 것을 클라이언트에게 바람직하게 통지한다. 본 실시예에서, 특정 스킨은 공표된 오브젝트 타입에 대해서는 바람직하게 적절하다.

바람직한 실시예에서, 프레임워크는 두가지 상태로 문서를 실행하는데, 유효화 상태 및 실행 상태이다. 유효화 상태에 대해서, 우선 인터프리터는 마스터 시맨틱 엔트리 테이블을 만든다. 테이블은 리소스 URL로 잠겨져 있고 또한 조작자, 리소스, 리소스 타입, 술어, 술어 타입 및 링크에 대해 칼럼을 갖는다. 인터프리터가 테이블로 엔트리를 부가한 것처럼, 모든 여분의 엔트리를 제외시킨다. 또한, 인터프리터가 URL을 테이블에 부가하기 전에, 모든 URL을 바람직하게 캐노니컬화(canonicalize)한다. 예를들어, 둘다가 동일한 캐노니컬 형태를 공유하기 때문에, URL "http://www.abccorp.com" 및 "www.abccorp.com"은 동일하게 해석된다. 인터프리터는 분리된 SQML 레퍼런스 테이블을 만들고 유지한다. 이 테이블은 SQML 파일에 대한 캐노니컬 경로를 포함한다. 인터프리터가 오리지널 SQML 파일을 로드하는 경우, 인터프리터는 캐노니컬 파일 경로를 레퍼런스 테이블에 부가한다. SQML 파일이 그 자신을 가리키면, 인터프리터는 엔트리를 무시하거나 또는 에러를 리턴 시킨다. SQML 파일이 다른 SQML 리소스를 가리키면, 인터프리터는 새로운 파일을 레퍼런스 테이블에 부가한다. 새로운 리소스를 로드하는 것은 반복적이고 프로세스는 계속 반복한다. 만약 프로세스동안, 인터프리터가 레퍼런스 테이블의 기존의 SQML 엔트리를 호출하면, 인터프리터는 호출 어플리케이션(SQML 문서에서 반복적인 루프가 존재하는 것을 지시함)으로 에러를 리턴시킨다. 인터프리터가 문서 그래프 경로에서 더 많은 리소스를 찾는다면, 인터프리터는 주어진 리소스에 대해 마스터 엔트리 테이블에 이들을 부가한다. 주어진 리소스에 대해 링크를 엔트리 테이블내의 리소스 엔트리로 다이나믹하게 부가한다. 그 결과, 인터프리터는 그래프내의 각 리소스에 대해 문서 링크 그래프를 효율적으로 평평하게 한다.

인터프리터는 실행 상태로 진행한다. 이 상태에서, 인터프리터는 시맨틱 엔트리 테이블을 리뷰하고 모든 리소스 질의를 비동기적으로 또는 순차 방식으로 실행한다. 다음에, 리소스 타입에 기초한 각 리소스를 처리한다. 예를들어, 파일 리소스에 대해, 파일에 대한 특성 메타데이터를 오픈하고 메타데이터를 표시한다. 이해된 타입(가령, 문서)을 나타내는 HTTP 리소스에 대해, 인터프리터는 URL을 다운로드하고, 추출하여 표시한다. 에이전트 리소스에 대해, 인터프리터는 각 에이전트에 대해 XML 웹 서비스를 호출하고, 오퍼레이터를 갖는 각 링크를 적격화하여 XML 인자(argument)로서 링크를 통과시킨다. 바람직한 실시예에서, 문서 경계와 교차하는 링크에 대하 오브레이터는 항상 AND이다. 환언하면, 반복적인 질의는 필터링되도록 가정되므로, 인터프리터는 함께 공표되지 않은 동일한 리소스에 대한 모든 링크는 AND로 할 것이다. 인터프리터는 에이전트 리소스가 존재하는 것만큼, 많은 호출을 리소소를 나타내는 구성요소로 발행한다. 각 링크에 대해, 인터프리터는 링크를 리소스에 의해 처리를 위해 적당한 질의로 변환함으로써 링크를 분석한다.

＜predicate＞nervana:relevantto＜/predicate＞

＜oref＞c:＼foo.doc＜/oref＞

＜oreftype＞nervana:filepath＜/oreftype＞

예를들어, 속성을 갖는 링크를 포함하는 에이전트는 오브젝트(가령, c:＼foo.doc)의 XML 메타데이터를 추출하고 인자(argument)로서 XML을 갖는 에이전트 리소스에 대해 XML 웹 서비스를 호출함으로써 분석된다. 이는 어떻게 로컬 컨텍스트는 서버가 이해하고 처리할 수 있는 고유(XML 기반)의 질의로 분해하는 지를 나타낸다.

질의를 최적화하기 위해, 에이전시 XML 웹 서비스는 조작자(가령, and, or 등)를 가지고 수식화된 몇몇 인자(argument)를 통과시키는 방법을 노출한다. 인터프리터는 모든 링크 인자(argument)를 갖는 에이전트 리소스에 대해 XML 웹 서비스로 하나의 호출을 바람직하게 발행한다.

시맨틱 질의 구현 시나리오(Semantic Query Implementations Scenarios). 다음은 본 발명의 바람직한 실시예에 따라 시맨틱 질의 문서의 동작과 구현을 나타내는 예시적인 시나리오이다.

시나리오 1 : SQML 문서를 로딩 : 클라이언트는 일시적 파일을 생성하여 이를 간단한 속성을 갖는 버퍼, 즉 로컬 HTML 페이지로 기입한다. 이 페이지는 클라 이언트 프레임워크 구성요소(가령, ActiveX control, Java applet, 인터넷 익스플로러 행위 등)을 포함한다. 페이지는 SQML 파일 및 정보 에이전트 인스턴스를 식별하는 고유 ID를 오픈하는 이 구성요소로 초기화된다. 구성요소 자체는 SQML 파일을 오픈한다. 환언하면, 클라이언트 프레임워크는 무엇이 SQML 질의 문서를 오픈시키는 지를 플러그-인으로 말해준다. 프러그-인은 상술한 바와같이 해석에 의해 시맨틱 질의 문서를 오픈시킨다.

시나리오 2 : 문서 오픈 : 클라이언트는 표준 대화 박스를 오픈하여, 사용자가 오픈될 파일을 선택하도록 한다. 대화 박스는 표준 문서 파일 확장(가령, PDF, DOC, HTM, 등)으로 초기화된다. 사용자가 문서를 선택한 경우, 대화 목스는 모든 오픈된 문서의 리스트를 리턴시킨다. 클라이언트는 새로운 SQML 파일을 생성하여 오픈된 문서의 경로를 갖는 리소스 엔트리에 부가한다. 새로운 SQML 파일은 고유 이름(바람직하게 글로벌 유닉 식별기(GUID)에 기초하여)이 주어진다. 이는 일시적 파일이기 때문에, 이름은 사용자에게 바람직하게 노출되지 않는다. 방법론은 상술한 바와같이 시나리오 1로 진행한다.

시나리오 3 : 문서내의 폴더 오픈 : 클라이언트는 SQML 파일(상술함)을 생성하고 하나의 리소스 엔트리 file://＜folderpath＞?includesubfolders=(true|false)를 갖는 파일을 초기화한다. SQML 파일은 폴더내의 모든 문서를 열거하고 문서에 대한 메타데이터를 표시함으로써 로드된다(시나리오 1).

시나리오 4 : 에이전트로 저장 : 클라이언트는 사용자가 에이전트 이름을 설 정할 수 있는 대화 박스를 오픈한다. 클라이언트는 시맨틱 환경(하기를 참조)내의 에이전트를 새로운 이름으로 재명명한다. 저장된 에이전트는 일시적일 수 있고 또는 다른 이름으로 이미 저장되었을 수도 있다. 정보 에이전트는 바람직하게 에이전트 이름을 제안한다.

시나리오 5 : 블렌더로 저장 : 클라이언트는 유너가 블렌더를 선택할 수 있는 대화 박스를 오픈한다. 대화 박스는 사용자가 새로운 블렌더를 생성하게 한다. 블렌더가 선택된 경우, 클라이언트는 브렌더의 SQML 파일을 SQML 오브젝트 모델로 오픈하여, 새로운 엔트리(현재 로드된 SQML 파일)를 부가한다. 다음에 현재의 엔트리의 레퍼런스 카운트를 증가시킨다.

시나리오 6 : 드래그 및 드롭 ; 클라이언트는, 예를들어 다음과 유사한 단일 리소스 엔트리를 갖는 SQML 파일을 생성하고 오픈한다.

＜resource type="nervana:url"＞

agent://documents.all@abccorp.com

＜link predicate="nervana:relevantto"

type="nervana:filepath"

c:\foo.doc

＜/link＞

＜/resource＞

이 예는 "c:\foo.doc"를 나타내는 아이콘은 에이전트 "agent://documents.all@abccorp.com"를 나타내는 정보 에이전트 내의 아이콘을 통 해 드래그되고 드랍되는 것으로 가정한다.

시나리오 7 : 다수 드래그 및 드롭 : 클라이언트는, 예를들어 다음과 유사한 단일 리소스 엔트리를 갖는 SQML 파일을 생성하고 오픈한다.

＜resource type="nervana:url"＞

agent://documents.all@abccorp.com

＜link predicate="nervana:relevantto"

type="nervana:filepath"

c:\foo1.doc

＜/link＞

＜link type="nervana:filepath"

operator="or"

predicate="nervana:relevantto"

c:\foo2.doc

＜/link＞

＜link type="nervana:filepath"＞

operator="or"

predicate="nervana:relevantto"

type "nervana:filepath"

＜/link＞

＜/resource＞

이 예는 "c:\foo1.doc,""c:\foo2.doc" 및 "c:\foo3.doc"를 나타내는 다수의 아이콘들이 에이전트 "agent://documents.all@abccorp.com. "를 참조하는 정보 에이전트에서 아이콘을 통해 드래그 및 드롭되는 것을 보장한다. 또한, 이 예는 사용자들이 에이전트 리소스에서 타겟팅된 시맨틱 질의의 UNION을 원하는지를 가리키는 것을 보장한다.

시나리오 8: 스마트 렌즈. 스마트 렌즈가 정보 에이전트를 선택할 때, 정보 에이전트는 스마트 렌즈가 정보 에이전트 식별자에 대해 선택되는 시맨틱 환경 매니저(아래 참조)를 가리킨다. 스킨(SKIN)이, 마우스가 오브젝트를 통과하는 것을 통지할 때(예컨대, 문서 오브젝트 모델(DOM)에서 "onmouseover" 이벤트를 통해), 이는 정보 에이전트가 스마트 렌즈 모드이 있는지 여부를 프리젠터가 먼저 발견하게 한다. 클라이언트 프레임워크는 식별자를 갖는 정보 에이전트가 스마트 렌즈 모드에 있는지를 시맨틱 환경 매니저에 문의함에 의해 이를 결정한다. 시맨틱 환경 매니저가 이런 정보를 정보 에이전트 자체로부터 캐쉬하기 때문에, 이는 정보 에이전트를 대신하여 질의에 답을 할 수 있다. 정보 에이전트가 스마트 렌즈 모드에 있다면, 클라이언트 프레임워크는 바람직하게 세막틱 환경 매니저를 통해 시스템 클립보드로부터 SQML 버퍼를 획득한다. 이는 스마트 렌즈가 클립보드로부터 그 정보를 획득한다는 점에서 가상 "첨부"이기 때문에 일어난다. 달리 말하자면, 클립보드에 복사되는 임의의 오브젝트 또는 에이전트는 스마트 렌즈(심지어 규칙적인 문자)로서 사용될 수 있다. 프레임워크는 SQML 버퍼를 획득하며, SQML 버퍼에서 모든 리소스용 리소스 구성요소를 예시한다. 클라이언트 프레임워크는 리소스에 현재 표시되는 오브젝트용 XML 정보를 통과하는 리소스 API GetInformationForSmartLens를 호출한다. 모든 리소스는 바람직하게 스마트 렌즈 메타데이터를 클라이언트 프레임워크에 리턴시킨다. 각각의 리소스는 바람직하게 스마트 렌즈 정보 너겟(nugget)의 리스트 형태로 메타데이터를 리턴시킨다. 각각의 너겟은 문자 엔트리 및 질의 버퍼의 리스트를 (SQML에서) 포함한다. 문자 엔트리는 단순 문자 또는 커스텀 문자 포맷, 예컨대 다음과 유사한 것을 포함한다:

Steve reports to ＜A＞Patrick＜/A＞. Patrick posted ＜A＞54 critical-priority

messages＜/A＞ relating to this one.

각각의 "〈A〉" 태그 쌍은 바람직하게 정보 너겟에서 대응하는 SQML 질의 버퍼를 포함한다. 클라이언트 프레임워크는 문자를 정보 에이전트(예컨대, 바람직하게 마우스가 통과하는 오브젝트를 블럭 또는 숨기지 않는 발룬 팝업(balloon popup) 또는 다른 사용자 인터페이스로서)에서 디스플레이를 위한 DHTML(또는 유사한 프리젠테이션 포맷)으로 포맷팅한다. 클라이언트 프레임워크는 포함하는 "〈A〉" 및 "〈/A〉" 태그가 발견되는 링크(HTML 링크와 유사한)용 사용자 인터페이스를 표시한다. 링크가 관련될 때, 클라이언트 프레임워크는 세막틱 환경 매니저가 새로운 캐쉬 엔트리를 생성하게 한다. 시맨틱 환경 매니저는 엔트리가 저장되는 것이 어떤 파일 경로인지를 가리킨다. 클라이언트 프레임워크는 파일로 클릭되는 〈A〉 태그용 SQML 버퍼를 기록한다. 클라이언트 프레임워크는 SQML 문서를 시맨틱 환경 매니저에 푸시(push)하며, SQML을 정보 에이전트(다이나믹 HTML을 통해)로 로딩한다. 시맨틱 환경 매니저가 현재 문서로서 SQML 문서를 포함하기 때문에, 사용자는 정보 에이전트에서 "저장" 버튼을 통해 문서를 저장할 수 있다(예컨대, "에이전트로 저장" 또는 "블렌더로 저장"). 스마트 렌즈가 표시될 수 있는 정보의 예는 다음과 같다:

The Agent Email.Technology.All@Marketing has a total of 300 objects that relate to this object. Critical Priority: 5 objects, High Priority: 50 objects, Medium Priority: 100 objects, Low Priority: 145 objects.

바람직한 실시예에서, 사용자가 발룬에서 링크들중 임의의 하나를 클릭하지 않는다면, 어떠한 SQML 문서도 생성되지 않고, 어떤 것도 시맨틱 환경에 부가되어 얻을 수 없다. 이는 스마트 렌즈가 바람직하게 단지 "잠재 질의"만을 나타내기 때문이다.

바람직한 실시예에서, SQML에 포함될 수 있는 임의의 정보는 스마트 렌즈(예컨대, 에이전트, 사람, 문서, 헤드라인, 클래식, 에이전시, 문자, HTTP URLs, FTP URLs, 파일 시스템으로부터 파일, 파일 시스템으로부터 폴더, Microsoft Outlook과 같은 e-메일 어플리케이션으로부터의 e-메일 URLs, e-메일 폴더 URLs 등)으로서 관련될 수 있다. 예컨대, 사용자는 문자 기초 어플리케이션으로부터 클립보드로 규칙적인 문자를 복사할 수 있다. 사용자가 정보 에이전트를 기입하고 스마트 렌즈를 선택한다면, 문자의 SQML 버전은 스마트 렌즈("문서" 리소스를 통해)로서 관련된다. "텍스트 스마트 렌즈"가 문서 오브젝트쪽으로 마우스를 이동(hover)한다면, 문자 스마트 렌즈를 나타내는 문서 리소스는 스마트 렌즈 오브젝트와 마우스 아래 의 오브젝트 사이의 사용자 유사성을 나타내는 유사성 몫(quotient)을 선택적으로 표시한다. 마우스 아래의 오브젝트가 사람 오브젝트인 경우, 문서 리소스는 에이전트가 문자에 포함된 정보에 대한 전문가인지를 사람 오브젝트를 나타내는 에이전트에 "문의"할지를 결정한다. 선택적으로, 스마트 렌즈는 사람이 문자와 관련되어 저작된(authored) 유사한 문서 또는 e-메일 메시지에 대한 링크를 표시한다.

바람직한 실시예에서, SQML에 포함될 수 있는 임의의 정보는 스마트 렌즈(예컨대, 에이전트, 사람, 문서, 헤드라인, 클래식, 에이전시, 문자, HTTP URLs, FTP URLs, 파일 시스템으로부터 파일, 파일 시스템으로부터 폴더, Microsoft Outlook과 같은 e-메일 어플리케이션으로부터의 e-메일 URLs, e-메일 폴더 URLs 등)으로서 관련될 수 있다. 예컨대, 사용자는 문자 기초 어플리케이션으로부터 클립보드로 규칙적인 문자를 복사할 수 있다. 사용자가 정보 에이전트를 기입하고 스마트 렌즈를 선택한다면, 문자의 SQML 버전은 스마트 렌즈("문서" 리소스를 통해)로서 관련된다. "텍스트 스마트 렌즈"가 문서 오브젝트쪽으로 마우스를 이동(hover)한다면, 문자 스마트 렌즈를 나타내는 문서 리소스는 스마트 렌즈 오브젝트와 마우스 아래의 오브젝트 사이의 사용자 유사성을 나타내는 유사성 몫(quotient)을 선택적으로 표시한다. 마우스 아래의 오브젝트가 사람 오브젝트인 경우, 문서 리소스는 에이전트가 문자에 포함된 정보에 대한 전문가인지를 사람 오브젝트를 나타내는 에이전트에 "문의"할지를 결정한다. 선택적으로, 스마트 렌즈는 사람이 문자와 관련되어 저작된(authored) 유사한 문서 또는 e-메일 메시지에 대한 링크를 표시한다.

시나리오 9: 복사 및 첨부

복사: 시맨틱 환경내로부터 복사 커맨드의 발동시, 클라이언트 프레임워크는 SQML 버퍼를 커스텀 클립보드 포맷을 갖는 시스템 클립보드에 복사한다. 이것은 다른 어플리케이션(예컨대, 마이크로소프트(사) 워드, 액셀, 노트패드 등)이 포맷을 인식하지 못하고 정보 첨부를 시도하지 못하는 것을 보여준다. SQML 버퍼는 바람직하게 복사되는 오브젝트의 시맨틱과 일치한다. 예컨대, 프리젠터에 표시되는 오브젝트로부터의 복사 동작은 적절한 리소스 타입 및 메타데이터가 오는 URL을 갖는 리소스로서 복사된다. 에이전트를 나타내는 아이콘의 복사는 시맨틱 환경에서 에이전트 엔트리를 참조하는 캐쉬 엔트리 또는 에이전트의 URL을 복사한다. 데스크탑 어플리케이션(예컨대, Microsoft Outlook)으로부터의 정보 복사는 소스 어플리케이션을 참조하는 리소스 타입 및 어플리케이션내의 오브젝트를 가리키는 URL을 갖는 SQML을 복사한다. 이들 URL은 바람직하게 인터프리터(interpreter)에 의해 실행시간에서 어플리케이션 내의 오브젝트로 풀릴수 있다. 예컨대, 시맨틱 환경으로 복사되는 아웃룩으로부터의 e-메일 메시지를 복사하면 다음과 같은 리소스 엔트리가 생성된다:

〈resource type="nervana:outlookemailmessage"〉

outlook://file://c:

＜/resource＞

첨부: 첨부 커맨드의 발동시, 클라이언트 프레임워크는 첨부되는 정보의 클립보드 포맷을 기초로 하여 SQML 파일을 생성한다. 예컨대, 클립보드가 파일 경로를 포함하면, SQML 파일은 파일 경로를 갖는 오브젝트에 대한 링크(첨부가 관련되 는 리소스로부터)를 포함한다. 이런 파일은 상술한 바와 같이 오픈된다. 클립보드 포맷이 URL인 경우, 오브젝트는 URL 오브젝트 타입이다. 포맷이 규칙적인 문자인 경우, 오브젝트는 이 예에서 리소스 타입 nervana:text를 갖는 실제 문자를 포함한다. 선택적으로, 클라이언트 프레임워크는 임시 캐쉬 엔트리를 생성하며, 문자를 그곳에 저장하고(예컨대, .TXT 파일로서), 파일 경로 및 오브젝트 타입(본 예에서는 nervana:filepath)를 참조하여 SQML 오브젝트를 저장한다. 인터프리터가 불러질 때, 이는 문자로된 XML 메타데이터 버전을 생성하며, XML 링크 인자(argument)를 갖는 리소스를 불러온다. 클립보드 포맷이 본 발명의 SQML 클립보드 포맷인 경우, 유사한 프로세스는, 만약 파일이 생성된다면 확장자가 .SQM(또는 .SQML)인 것을 제외하고 수행된다. 이는 오브젝트가 SQML 파일이며 규칙적인 문자 파일이 아닌 인터프리터(interpreter)를 나타낸다.

f. 시맨틱 환경

본 발명의 시맨틱 환경의 바람직한 실시예는 정보 에이전트를 통해 사용자에게 이용가능한 모든 에이전트 및 에이전시의 뷰를 제공한다. 이는 바람직하게 즐겨찾기(favorites), "내 에이전트" 리스트, 최근에 사용된 에이전트, 로컬 에이전시상의 에이전트, 및 원격 에이전시상의 에이전트로 국부적으로 저장된 에이전트를 포함한다. 원격 에이전시는 로컬 영역 네트워크상에서의 멀티캐스트를 통해 그들의 존재를 발표하는 에이전시, 글로벌 에이전시 디렉토리(global agency directory)상에서 이용가능한 에이전시, 및 커스텀(custom) 에이전시 디렉토리상에서 이용가능한 에이전시를 포함한다. 에이전트는 그들의 URL을 부름에 의해 시맨 틱 환경에 다이나믹하게 부가될 수 있다. 바람직한 실시예에서, 시맨틱 환경 계층은 본 명세서에 첨부된 SAMPLE C에 표시된 패턴을 가진다. "최근에 사용된", "최근에 생성된" 에이전트는 바람직하게 "최근 에이전트"에서 제외된다. 선택적으로, "모든 에이전트", "삭제된 에이전트" 및 "커스텀 뷰"가 부가될 수 있다.

에이전시 뷰는 사용자가 에이전시에 의해 메인 뷰에서 에이전트를 볼 수 있게 한다. 오브젝트 타입의 뷰는 사용자가 동일한 에이전트를 보게하나, 오브젝트 타입에 의해 필터링된다. 다른 뷰는 유사한 형태, 예컨대 "By Context"(컨텍스트 템플레이트를 기초로 한) 및 "By Time"에서 동작한다. 시맨틱 환경은 "즐겨찾기"의 통지를 "히스토리"의 통지와 통합한다. 시맨틱 환경은 예컨대 "최근에 사용된 에이전트"와 같은 다이나믹하게 관리되는 뷰를 선택적으로 부가한다. 이들 뷰는 바람직하게 시맨틱 환경 매니저내에서 동작하는 코드에 의해 업데이트된다(이하 참조).

본 발명에 따르는 예시적인 시맨틱 환경은 도 58 및 59에 도시된다. 시맨틱 환경에 통합되는 아이콘은 다음을 포함한다:

Application

All container object types

All document file types

reaking News Agent Icon Qualifier (예컨대, 감탄 부호)

Special Agent Icon Qualifier (예컨대, 헤일로(halo))

Standard Agent for each object types

Agency

Agent View Containers

My Agents

Breaking News Agents

Favorite Agents

Special Agents

Recently Used Agents

스냅샷(Snapshot). 사용자는 바람직하게 시맨틱 환경의 스냅샷을 저장할 수 있다. 시맨틱 환경 스냅샷은 본질적으로 시맨틱 환경 상태의 시간에 기초한 캐쉬(cash)이다. 바람직한 실시예에서, 스냅샷은 다음의 정보를 갖는 국부적으로 저장된 상태를 포함한다:

·새로운 에이전트를 갖는 스냅샷 시간에서의 모든 에이전시

·(에이전시의 시계에 기초하여) 각각의 에이전시의 최종 에이전트 생성 시간

·(에이전시의 시계에 기초하여) 각각의 에이전시의 현재 시간

스냅샷은, 바람직하게는, 사용자에게 액세스(access) 가능하다. 정보 에이전트는 스냅샷 리스트에서 에이전시만을 나타내기 위하여 시맨틱 환경과, 각각의 에이전시용 스냅샷 시간과 최종 에이전트 생성 시간 사이에서 생성된 에이전시들 각각의 에이전트를 필터링한다.

g. 시맨틱 환경 매니저

본 발명은 시맨틱 환경 오브젝트를 관리하기 위하여 API를 보여주는 시맨틱 환경 매니저를 제공한다. 바람직한 실시예에서, 관리된 시맨틱 환경 오브젝트는 SQML 버퍼를 통해 에이전트 레퍼런스(reference)로 우선적으로 구성된다. 시맨틱 환경 매니저는 또한 시맨틱 환경을 네비게이트하기 위하여 API를 보여준다. 바람직한 실시예에서, 시맨틱 환경 매니저는 정보 에이전트의 인스턴스(instance)가 다음의 것을 허용하게 한다:

1. 시맨틱 환경 매니저에서 그 자체의 등록.

시맨틱 환경 매니저는 바람직하게 모든 오픈 정보 에이전트 인스턴스에 대한 정보를 유지한다. 이는 많은 수의 서비스(예컨대, 클립보드 액세스, 스마트 렌즈 액세스 등)가 확장 어플리케이션 및 브라우저 제어내에서 동작하는 프리젠터 구성요소와 같은 어플리케이션을 통해 수행되기 때문에 이같이 된다. 예컨대, 프리젠터가 새로운 SQML 문서를 표시 영역에 로딩할 때, 시맨틱 환경 매니저로부터 캐쉬 엔트리를 획득할 필요가 있다. 시맨틱 환경 매니저에게 소정의 SQML 버퍼용 새로운 캐쉬 엔트리를 생성할 것을 요청한다. 시맨틱 환경 매니저는 캐쉬 엔트리를 생성하며, SQML 버퍼를 그 엔트리에 대응하는 파일 경로에 기록하고, ActiveX 제어, 다이나믹 HTML 행위, 캐쉬 엔트리를 가리키는 자바 애플릿(또는 균등한 클라이언트 실행시간 엔진)으로 초기화되는 임시 HTML 파일을 생성하며, 캐쉬 엔트리 식별자 및 임시 HTML로의 파일 경로를 프리젠터로 리턴시킨다. 예컨대, 바람직한 실시예에서, 임시 HTML 파일은 다음과 같이 명명된다;

c:_39fc54bc-81e5-4954-8cef-3d1a54935a0d.htm

여기서, 39fc54bc-81e5-4954-8cef-3d1a54935a0d는 캐쉬 엔트리 식별자이다. 포함하는 정보 에이전트는 (포함된 정보 에이전트 제어에서의 이벤트를 통해) 로딩되는 새로운 문서를 자동적으로 검출한다. 포함하는 정보 에이전트는 사용자가 "저장"(예컨대, "에이전트로서 저장" 또는 "블렌더안에 저장")을 칠 때 응답할 수 있다. 정보 에이전트는 현재 문서 파일 경로를 획득하고, 파일 경로로부터 캐쉬 엔트리 식별자를 획득하며(파일 경로가 식별자로 부분적으로 명명되기 때문에), 사용자가 "저장(Save as)"을 칠 때 캐쉬 엔트리용 메타데이터(이름, 술어 등)를 표시함에 의해, 이를 달성한다. 정보 에이전트는 시맨틱 환경 매니저에게 새로운 이름으로 캐쉬 엔트리를 재저장 하도록 요청한다. 정보 에이전트는 그 인스턴스의 프로세스 ID를 갖는 시맨틱 환경 매니저에 그 자체(바람직하게는, 시작 시)를 등록한다. 시맨틱 환경 매니저는 정보 에이전트용 새로운 식별자를 할당하며, 정보 에이전트 인스턴스(예컨대, 스마트 렌즈 모드에 현재 있는지 여부)용 메타데이터를 저장한다. 정보 에이전트는 이런 식별자를 저장한다. 정보 에이전트는, 바람직하게는, 호출이 있을 때마다 시맨틱 환경 매니저에 식별자를 통과시킨다. 정보 에이전트는 식별자를 갖는 프리젠터를 초기화한다. 바람직한 실시예에서, 클라이언트 프레임워크는 크로스 어플리케이션 서비스를 필요로 할 때마다 식별자를 갖는 시맨틱 환경 매니저를 호출한다. 시맨틱 환경 매니저는 정보 에이전트 프로세스가 종료될 때 모든 정보 에이전트 엔트리에서 불필요한 정보를 정리하기 위하여 정보 에이전트 인스턴스의 프로세스 식별자를 저장한다. 시맨틱 환경 매니저는 바람직하게 정 보 에이전트가 종료될 때를 "알지" 못하기 때문에 정보 에이전트 엔트리를 제거하기 위하여 이를 수행한다.

2. 새로운 에이전트 레퍼런스를 시맨틱 환경에 부가. 에이전트 레퍼런스 엔트리는 바람직하게 데이터베이스, 파일 시스템 또는 시스템 저장소(store)(예컨대, 윈도우 레지스트리(registry))에 저장된다. 바람직한 실시예에서, 각각의 시맨틱 환경 엔트리는 다음을 포함한다:

a. 식별자(Identifier). 이는 시맨틱 환경에서 에이전트를 식별한다.

b. 이름(Name). 이는 에이전트의 이름을 가리킨다. 정보 에이전트는 새로운 에이전트가 생성될 때 디폴트 에이전트의 이름을 설정한다. 이런 에이전트 이름은 생성의 방식을 기초로 설정된다. 예컨대, 문서 "foo"가 에이전트 "bar"에 복사되고 첨부된다면, 정보 에이전트는 "foo"(현재 시간)에 관한 임시 에이전트 이름 "bar"를 생성한다. 현재 시간은 에이전트를 명명하도록 저장된다(사용자가 동일한 질의를 재발행하는 경우에). 사용자는 원하는 에이전트를 재명명할 수 있다.

c. 질의 버퍼(Query Buffer). 이는 에이전트용 SQML을 포함하는 버퍼를 가리킨다.

d. 종류(Type). 이는 에이전트 종류(예컨대, 표준 에이전트, 블렌더, 검색 에이전트, 스페셜 에이전트 등)를 가리킨다.

e. 생성시간(Creation Time). 이는 에이전트 엔트리가 생성할 때를 나타낸다.

f. 최종수정시간(LastModifiedTime). 이는 에이전트 엔트리가 최종 수정될 때를 나타낸다.

g. 최종사용시간(LastUsedTime). 이는 에이전트 엔트리가 최종 사용될 때를 나타낸다.

h. 사용횟수(UsageCount). 이는 에이전트가 필터 또는 스마트 렌즈 중 어느 하나의 자립헝(standalone)으로 사용되는 횟수를 나타낸다.

i. 속성(Attributes). 이는 에이전트 속성(예컨대, 통상, 임시, 가상, 및 삭제를 위해 표시되는)이다. 엔트리가 임시적이라면, 이는 사용자가 로컬에이전트로서 이를 명백하게 저장하지 않음을 의미한다. 임시 엔트리는 바람직하게 사용자가 드래그 및 드롭을 이용하여 복합 질의를 구성하나 에이전트로서 어떠한 중간 질의도 저장하지 않는 경우에 사용된다. 사용자가 에이전트로서 질의를 저장할 때, 정보 에이전트는 질의 엔트리가 현재 영구적임을 나타내는 임시 플래그를 재설정한다.

j. 레퍼런스횟수(ReferenceCount). 이는 다른 에이전트 및 블렌더에 의하여 에이전트에 대한 레퍼런스의 횟수를 나타낸다. 카운트는 새로운 에이전트 엔트리가 생성될 때 0으로 초기화된다.

3. 시맨틱 환경으로부터 에이전트 삭제. 이는 바람직하게 2개의 형태로 수행된다. 에이전트는 에이전트 엔트리가 "트레쉬 캔(trash can)"에 있음을 나타내는 플래그를 시맨틱 환경 매니저가 설정하는 경우에 삭제를 위해 표시될 수 있다. 에이전트 엔트리는 또한 엔트리가 모두 함께 캐쉬로부터 제거되는 경우에 영구적으로 삭제될 수 있다.

4. 시맨틱 환경에서 에이전트의 특성 변경(예컨대, 사용자가 에이전트를 저장할 때 임시 플래그를 재설정)

5. 시맨틱 환경에서 에이전트의 재명명

6. 바람직하게 다음에 대응하는 엔트리를 검색하기 위해 캐쉬를 열거:

a. 모든 에이전트

b. 삭제된 에이전트

c. 가장 빈번하게 사용된 에이전트

d. 가장 최근에 사용된 에이전트

e. 가장 최근에 생성된 에이전트

f. 상술한 뷰 아래의 각각의 오브젝트 타입용 필터들(예컨대, 문서, e-메일, 이벤트 등)

g. 상술한 뷰에서 에이전트를 호스트하는 에이전시용 필터, 에이전시에 대한 오브젝트 타입용 필터, 및 이들 뷰를 적합하게 하는 에이전트(문서, e-메일 등)

h. 컨텍스트 템플레이트를 기초로 한 스페셜 에이전트용 필터(예컨대, 헤드라인, 클래식, 뉴스메이커 등)

이들 열거와 뷰의 샘플들은 시맨틱 환경 트리 뷰를 보여주는 도 12-14 및 17-19에 도시되어 있다.

7. 정보 에이전트의 인스턴스로부터 인보케이션을 통해 엡데이트된 카운터를 기초로 에이전트 리스트의 필터. 각각의 정보 에이전트의 인스턴스는 바람직하게 하나의 시맨틱 환경 매니저와 통신한다. 그런 방식으로 업데이트는 세션 지향적이기 보다는 사용자 지향적이다. 예컨대, 사용자가 하나의 정보 에이전트에서 에이전트를 오픈한다면, 에이전트 엔트리는 다른 정보 에이전트에서 최근에 사용된 에이전트 뷰안에서 나타날 것이다. 시맨틱 환경 매니저는 에이전트가 사용되는 횟수, 에이전트가 사용되는 최종 시간 등에 대한 정보를 유지한다. 이는 에이전트를 필터링한다. 예컨대, 가장 빈번하게 사용된 에이전트는 가장 높은 사용 카운트를 갖는 N 에이전트를 기초로 필터링된다. 여기서 N은 구성가능하며, 필터는 약간의 안정화 대기 주기이후에만 적용된다(예컨대, 전체 사용 카운트가 적어도 Y인 후, 여기서 Y는 예컨대 2주의 주기에서 에이전트 사용의 예상 횟수와 같은 단순한 교수법(heuristic)에 기초하여 또한 구성가능하다). 최근에 사용된 에이전트는 사용시간(에이전트당 기준으로 저장되며 에이전트가 사용될 때 정보 에이전트의 인스턴스에 의해 업데이트되는)을 기초로 필터링된다. 최근에 생성된 에이전트는 에이전트 생성 시간을 기초로 필터링된다. 삭제된 에이전트는 각각의 에이전트에 대한 "삭제를 위해 표시된" 플래그를 조사함에 의해 필터링된다. 즐겨찾기 에이전트는 각각의 에이전트에 대한 "즐겨찾기로서 표시된" 플래그를 조사함에 의해 필터링 된다. 상술한 각각의 패런트(parent) 뷰에서, 기본적인 뷰는 단순한 필터를 이용하여 대중적이다. 에이전시 뷰는 패런트 뷰에서 리턴된 각각의 에이전트를 조사하고 이로부터 에이전시를 추출함에 의해 보급되어 있다. 이에 표시된 에이전시 각각의 아래에 있는 오브젝트 타입의 뷰는 에이전트 오브젝트 타입(예컨대, 문서, e-메일, 이벤트 등)을 기초로 에이전트를 필터링함에 의해 존재한다. 블렌더 뷰는 "블렌더 (Blender)" 타입을 갖는 에이전트만을 표시함에 의해 필터링된다. 오브젝트 타입 뷰는 에이전트 오브젝트 타입을 이용하여 직접 필터링된다. "내 에이전시(My Agencies)" 뷰는 로컬 에이전시를 표시한다. 이 아래의 각각의 뷰는 바람직하게 각각의 이용가능한 에이전시에 대한 에이전트를 이용하여 필터링된 오브젝트 타입 뷰이다. "컨텍스트에 의한(By Context)" 뷰는 스페셜 에이전트(바람직하게 컨텍스트 템플레이트로 생성된)만을 필터링하고 컨텍스트 이름(예컨대, 헤드라인, 클래식 등)을 체크함에 의해 보급되어 있다.

8. 시맨틱 환경에서 에이전트용 레퍼런스 카운트를 유지. 문서 엔트리의 레퍼런스 카운트를 증분 및 감분하는 것은 호출 구성요소(정보 에이전트)의 책임이다. 정보 에이전트는 바람직하게 이를 드래그 및 드롭, 복사 및 첨부 등에 의해 수행한다. 달리 말하자면, 기존의 에이전트를 레퍼런스하는 새로운 질의를 생성하는 액션이다.

9. 시맨틱 환경을 비움. 이는 모든 에이전트를 삭제한다.

10. 불필요 정보 정리(garbage collection) 수행. 시맨틱 환경 매니저는 모든 오래된(그리고 임시) 에이전트를 자동적으로 삭제한다. 캐쉬는 소정의 시점 이후의 에이전트의 히스토리를 유지하도록 구성된다. 예컨대, 캐쉬가 에이전트에 가치가 있는 2주 동안 정보를 유지하도록만 구성된다면, 2주 이상 오래된 임시 에이전트를 주기적으로 체크한다. 만약 그것이 발견된다면, 0의 레퍼런스 카운트를 갖는 에이전트 엔트리를 자동적으로 삭제한다. 이는 바람직하게 정보 에이전트가 새로운 캐쉬 엔트리를 생성하나 이를 레퍼런스하는 다른 엔트리(에이전트 또는 블렌 더)를 생성하지 않는 경우에 일어난다. 달리 말하자면, 정보 에이전트는 직접 링크(복잡성을 회피하기 위하여)에 대한 링크 트래킹을 수행한다.

시맨틱 환경 매니저는 불필요한 정보 정리를 선택적으로 수행한다. 이는 구성가능한 스케쥴에서 주기적으로 일어난다. 이는 0보다 큰 레퍼런스 카운트를 가지나 다른 엔트리가 삭제될 때 링크가 유지되지 않기 때문에 실제 레퍼런스를 갖지 않는 엔트리에 적용된다. 이런 특징은 에이전트와 블렌더가 저장 또는 편집될 때 에이전트와 블렌더 사이에서 정보 에이전트가 바람직하게 레퍼런스를 트래킹하지 않기 때문에 복잡성을 최소화하도록 바람직한 실시예에 통합된다. 선택적인 실시예에서, 프리젠터는 에이전트가 불려질 때 뒤늦은 에이전트 접속을 위한 탐색을 수행한다. 클라이언트 프레임워크는 링크들중 하나가 삭제될 때 404(발견되지 않는 파일) 에러를 웹 페이지가 리턴시키는 방법과 유사한, 시맨틱 환경으로부터 삭제된 모든 레퍼런스를 무시한다. 달리 말하자면, 본 발명은 불완전한 질의의 상황에 제공된다. 예로서, 가능한 시나리오가 다음과 같다:

Blender B1 -＞ refers to Blender B2 -＞ refers to Agent A1 -＞ refers to Agent A2

이런 경우, 체인의 레퍼런스 카운트가 4일지라도, 각각의 엔트리의 레퍼런스 카운트는 1이다. 위와 같이, 레퍼런스 카운트가 0보다 크다할지라도 진부한(stale) 엔트리를 갖는 것이 가능하다. 불필요한 정보가 정리된 각각의 엔트리에서, 불필요한 정보 정리는 모든 SQML 문서에서 엔트리에 대한 임의의 레퍼런스를 검색한다. 어떠한 레퍼런스도 발견되지 않으면, 엔트리는 제거된다(임시적이거나 기간이 오래된 경우).

11. 통지 관리의 조작. 사용자는 시맨틱 환경에서 임의의 에이전트로부터 통지를 등록할 수 있다(예컨대, 로컬 에이전트, 표준 에이전트, 블렌더 등을 저장). 바람직한 실시예에서, 통지 방법은 e-메일, 실시간 메시지, 종이 메시지, 전화 메시지 등을 전송하는 단계를 포함한다. 시맨틱 환경 매니저는 정보 에이전트를 통해 사용자로부터 통지 요청을 관리하는 통지 매니저(후술함)를 포함한다. 통지 매니저는 통지 요청의 리스트를 저장한다. 통지 요청은 바람직하게 시맨틱 환경 오브젝트 ID(에이전트를 식별하는), 통지의 타입(e-메일, IM 등) 및 목적지, 예컨대 e-메일 어드레스 등을 포함한다. 통지 매니저는 소정의 새로운 오브젝트가 있는지를 "요구"하기 위하여 통지 요청 리스트에 각각의 에이전트를 주기적으로 풀(poll)한다. 통지 매니저는 또한 "최종 요청된 시간"(목적지 에이전트의 시계에 기초하여)을 통과시킨다. 에이전트는 (그 저장된 질의에 관련되며, "최종 요청된 시간"이후에 생성된 질의 결과에 오브젝트의 수를 다시 통과시킴에 의해) 새로운 오브젝트의 수로 응답한다. 에이전트는 (그 시계상의) 현재 시간으로 응답한다. 통지 매니저는 시간 동기 문제를 회피하기 위하여 에이전트의 시간을 저장한다. 선택적으로, 클라이언트 및 모든 에이전시는 그들의 시간이, 모든 시간 비교가 동일한 스케일에 있는 것을 보장하도록 동일한 시간 서버(시간 웹 서비스)를 사용한다.

에이전시 디렉토리. 바람직한 실시예에서, 시맨틱 환경 매니저는 바람직하게 각각의 에이전시 "디렉토리"용 에이전시 리스트를 유지한다. 멀티캐스트 네트 워크는 바람직하게 시맨틱 환경 매니저를 에이전시의 디렉토리로서 본다. 바람직한 실시예에서는 공개 시스템상에서 XML 웹 서비스에 대한 URL로 구성되는 디폴트 글로벌 에이전시 디렉토리가 있다. 이런 XML 웹 서비스는 (바람직하게는, ID, URL 등을 포함하는 상술한 모든 정보를 가지는) 모든 등록된 에이전시의 캐쉬를 저장한다. XML 웹 서비스는 에이전시가 에이전시 디렉토리상의 표현을 레지스터하도록 하는 방법을 나타낸다. XML 웹 서비스는 잔여 엔트리를 필터링한다. XML 웹 서비스는 또한 사용자로 하여금 에이전시 디렉토리상에서 모든 에이전시를 열거하게끔 하는 방법을 드러낸다. 시맨틱 환경 매니저는 이런 방식으로 디렉토리를 열거한다. 바람직하게, 정보 에이전트는 에이전시 디렉토리를 시맨틱 환경의 확장으로 고려하며, 사용자가 에이전시 디렉토리상에 리스트된 에이전시에 대한 에이전트를 브라우징하고 오픈하게 한다. 사용자는 바람직하게 내부 네트워크상에 인스톨된 커스텀 에이전시 디렉토리에 URL을 부가할 수 있다. 본 발명은 커스텀 가능한 에이전시 디렉토리의 생성 및 통합에 대하여 고려한다. 이는 본질적으로 멀티캐스트가 네트워크상에서 가능하지 않은 경우(대역폭 변환 이유로) 또는 와이드 영역 네트워크상의 임의의 서브네트가 멀티캐스트를 지원하지 않는 경우에 디스커버리용 멀티캐스트를 이용하는 것에 대한 대안이다.

h. 환경 브라우저(시맨틱 브라우저 또는 Information AgentTM)

환경 브라우저 또는 정보 에이전트는 정규 웹 브라우저 구성요소(인터넷 익스플로어 ActiveX 제어와 같은)를 호스트하며, SQML 파일을 가져와 프리젠터를 통해 그 결과를 랜더링하는데 일차적인 책임이 있다. 바람직한 실시예에서, 이는 SQML 파일의 SQML 문서 캐쉬 엔트리에 대한 레퍼런스로 초기화되는 로컬 HTML 파일을 오픈함에 의해 이루어진다. HTML 파일은 제어(예컨대, ActiveX, 자바, 인터넷 익스플로어 행위 등)를 통해 프리젠터를 로딩한다. 이런 제어는 캐쉬로부터 (시맨틱 환경 매니저를 통해) SQML 문서를 검색하고, 상술한 바와 같이 SQML 파일을 로딩한다. 제어는 오브젝트가 XHTML(또는 균등한 프리젠테이션 포맷, 바람직하게는 현재의 XSLT 및/또는 스크립트 기초 스킨을 통해)로 변환되어 이용가능하하며, 프리젠테이션용 문서 오브젝트 모델(DOM)으로 푸쉬되는 것을 나타내는 리소스로부터 회수(callback)를 수신하는 웹 브라우저 문서 오브젝트 모델(DOM)에 오브젝트를 부가한다. 정보 에이전트는 사용자가 캐쉬에서 (캐쉬 ID를 통해) SQML 파일 또는 엔트리를 오픈하게 한다. 정보 에이전트는 또한 사용자로 하여금 뒤로(back) 및 앞으로(forward)를 네비게이트하게 하며, 제1 문서를 스택(stack)(오늘날 웹의 브라우저에서 "뒤로(back)", "앞으로(forward)" 및 "홈(home)" 옵션과 유사하나, 이경우 SQML 문서는 해석을 위해 오픈되고 HTML 및 다른 문서와는 상반되게 (결과의) 표시를 위해 오픈되는데 차이가 있다)에서 제1 문서를 네비게이트하게 한다.

도 60-68은 본 발명의 바람직한 실시예에 따르는 정보 에이전트의 예시적인 스크린삿을 제공한다. 도 60은 새로운 스페셜 에이전트, 새로운 블렌더, 또는 새로운 로컬 에이전시를 생성하기 위하여 예컨대 덤(Dumb) 에이전트를 통해 사용자가 시맨틱 환경으로 로컬 검색 결과를 전달하게 하는 툴을 갖는 툴바 팝업 옵션을 도시하는 시맨틱 환경을 예시한다. 선택적으로, 이들 툴은 사용자가 생성하길 원하는 에이전트의 타입(덤, 스마트, 특정) 또는 에이전시를 선택할 수 있는 마법사 (wizard)와 관련된 하나의 툴 버튼으로 없어질 수 있다. 도 61은 사용자가 키보드를 이용하여 시맨틱 환경을 검색하는 단순한 대화상자를 도시한다. 이는 새로운 스마트 에이전트(적절한 SQML을 갖는)를 생성한다. 사용자는 바람직하게 새로운 스마트 에이전트의 이름을 커스텀화 할 수 있으며, 선택적인 설명을 부가한다. 도 62는 사용자가 새롭게 생성 또는 오픈된 에이전트를 시맨틱 환경으로 영구적으로 저장하게 하거나(예컨대, "즐겨찾기(favority)" 리스트로) 또는 에이전트를 블렌더로 저장하게 하는 툴바의 "저장" 툴 팝업 메뉴 옵션을 도시한다. 도 63은 사용자가 스마트 렌즈와 불러오는(현재 클립보드상에 있는 스마트 에이전트 또는 오브젝트에 기초하여) 툴바의 스마트 렌즈 툴 메뉴 옵션을 도시한다. 이는 사용자가 클립보드 콘텐츠를 스마트 렌즈로서 사용하길 원하는 프리젠터에 통신한다. 프리젠터는 바람직하게 사용자가 배회하는(예컨대, 마우스로) 임의의 오브젝트용 스미트 렌즈 기능성을 자동적으로 불러온다. 메뉴는 또한 사용자가 스마트 렌즈를 암시적으로 턴오프할때까지 스마트 렌즈의 턴온을 유지하는(에이전트 네비게이션을 통할지라도) "스마트 렌즈 및 핀으로서 첨부" 옵션을 도시한다. 도 64는 사용자가 시맨틱 환경으로부터 서버측 에이전트를 오픈하며 환경의 "뷰"를 변경할 수 있는(예컨대, 큰 아이콘, 작은 아이콘, 리스트 등) 방법을 도시하는 "오픈 에이전트" 대화상자를 도시한 개략도이다. 도 65는 사용자가 파일 시스템으로부터의 "정규" 문서를 정보 신경 시스템의 시맨틱 환경으로 전달할 수 있는 방법을 나타내는 표준 윈도우 "오픈" 대화상자를 도시한다. 덤 에이전트는 문서를 레퍼런스하여 생성된다. 덤 에이전트가 불려올 때, 문서는 정보 에이전트에서 오픈되며, 시맨틱 툴 모두(예 컨대, 스마트 복사 및 첨부, 컨텍스트 템플레이트 등)는 문서로 가능하게 된다. 이는 브라우저가 파일 시스템상의 "스튜피드(stupid)" 문서를 시맨틱한 "스마트(smart)"하게 하는 방법을 예시한다. 도 66은 사용자로 하여금 로컬 파일 시스템상의 폴더의 문서를 검색하게 하며 이들을 시맨틱 환경에 전달하게 하는 커스텀 "폴더에서 문서 오픈" 대화상자를 도시한다. 이는 문서를 정보 신경 시스템의 시맨틱 툴을 통해 "노출(exposing)"함에 의해 문서를 "스마트"하게 한다(예컨대, 스마트 복사 및 첨부, 컨텍스트 템플레이트 등). 도 67은 사용자가 브라우즈 옵션을 선택할 때 도시되는 "폴더용 브라우즈" 대화상자를 나타낸다. 이는 사용자로 하여금 (로컬 파일 시스템으로부터) 오픈하고자 하는 폴더를 선택하게 한다. 도 68은 사용자가 표준 블렌더 또는 가상 블렌더를 생성하길 원하는지를 사용자로 하여금 선택하게 하는 "블렌더 부가" 마법사로부터의 페이지를 도시한다.

i. 부가 어플리케이션 특징.

어플리케이션 메뉴 확장 및 다른 프레임워크 특징. 시스템 클라이언트는 바람직하게 프로그램 확장을 지원하나 데이터를 클립보드에 복사하는 것을 지원하지 않는 어플리케이션에 메뉴 확장을 인스톨한다. 이들은 마이크로소프트(사) 윈도우 미디어 플레이어 및 아웃룩(e-메일 메시지 헤더용)과 같은 어플리케이션을 포함한다. 본 발명의 바람직한 실시예에서, 확장 매뉴에서 "복사(Copy)"를 읽어온다. 시스템은 선택된 오브젝트를 XML 오브젝트로서 윈도우 시스템 클립보드에 복사한다. 예컨대, e-메일 마이크로소프트(사) 아웃룩용 시스템 플러그인은 e-메일 XML 오브젝트로서 선택된 e-메일 오브젝트를 복사한다. 클립보드를 이미 지원하는 어 플리케이션에서는 어떠한 확장도 필요치 않다.

서버측 즐겨찾기 오브젝트. 사용자 상태를 지원하는 에이전시상에서, 사용자는 오브젝트를 "즐겨찾기"로 마크할 수 있다. 오브젝트가 즐겨찾기로서 마크될 때, 프리젠터는 에이전시의 XML 웹 서비스상에서 방법을 불러온다. XML 웹 서비스는 사용자 오브젝트와 당해 오브젝트 사이의 시맨틱 링크를 부가한다. 바람직한 실시예에서, 사용자는 All.MyFavorites. All Default Agent를 통해 즐겨찾기 오브젝트를 볼 수 있다. 이런 에이전트는 즐겨찾기로 마크되는 모든 오브젝트를 리턴시킨다. 에이전시 매니저는 All.MyFavorites.Technology.XML.All과 같은 서브 에이전트를 생성할 수 있다.

프리젠터는 사용자로 하여금 서버 및 에이전시가 익스포트(export)하는 구조를 재정의하는 수단인 즐겨찾기를 마크 및 언마크(unmark)하게 한다. "즐겨찾기" 시나리오의 사용은 사용자가 관심있는 오브젝트를 볼 수 있으며 이들을 즉시 네비게이트하길 원하지 않는 경우에 특히 필요 하다. 즐겨찾기 특징은 또한 사용자에게 오브젝트를 추천하기 위해 에이전시에 의해 선택적으로 사용될 수 있다. 바람직한 실시예에서, 이들 추천된 오브젝트는 All.Recommended.All Agent를 통해 검색될 수 있다. 에이전시는 사용자가 즐겨찾기인 것으로 마크되는 오브젝트를 우선적으로 기초하여 오브젝트를 추천한다. 서버측 즐겨찾기는 또한 "즐겨찾기" 클래식 및 추천 컨텍스트 템플레이트로 바람직하게 사용된다.

에이전트 스크린 세이버. 본 발명의 바람직한 실시예는 사용자로 하여금 스크린 세이버로서 임의의 가입된 에이전트를 선택하게 한다. 사용자는 바람직하게 에이전트가 스크린 세이버로서 스페셜 에이전트를 사용하는 것이 안전한지를 결정하기위해 감도 데이터를 드러내며, 기회가 주어지는지를 알린다. 바람직한 실시예에서, 시스템 클라이언트는 스트린 세이버로서 임의의 가입된 에이전트를 로딩 할 수 있다. 선택적인 실시예에서, 사용자는 소정의 스크린 세이버 프리젠테이션을 제공하기 위하여 에이전트들을 결합한다. 선택적으로, 스크린 세이버는 예컨대 스크린의 4등분에서 표시된 병렬 에이전트들을 포함하는 구조화된 스킨이다.

에이전트-에이전트 스마트 렌즈. 선택적인 실시예에서, 시스템 클라이언트는 다른 에이전트 또는 블렌더를 불러내기 위한 관련자료로서 스마트 렌즈(에이전트 또는 블렌더중 어느 하나를 통해서 불려나옴)의 사용을 지원한다. 예컨대, 사용자는 결정적인 우선순위가 있으며 또한 목적지 에이전시에 의해 이해되는 모든 오브젝트를 발견하기 위하여, All.CriticalPriority.All을 선택하며, 스마트 렌즈로서 에이전트를 사용하여 All.Understood.All을 브라우징하길 원한다.

스마트 렌즈 샘플 사용자 인터페이스 설명. 도 69-71은 본 발명에 따르는 정보 에이전트의 스마트 렌즈 특징과 연관된 예시적인 발룬(balloon) 팝업 메뉴를 제공한다. 도 69는 스마트 렌즈로서 스마트 에이전트를 갖는 컨텍스트 결과 창(pane)에서의 발룬 팝업 메뉴를 도시한다. 이는 사용자가 정보 오브젝트 상에서 스마트 렌즈 아이콘을 선택할 때 표시되는 팝업 윈도우를 도시한다. 이런 샘플은 "[나의 Nervana UI 스펙]에 관련된 로이터상의 문서(Documents on Reuters Related to [My Nervana UI Specification])"로 제목이 붙은 스마트 에이전트가 클립보드상에 있으며 "Nevana UI에 대한 유잉의 생각(Yuying's Thoughts on the Nervana UI)" 으로 제목이 붙은 e-메일 오브젝트를 통한 스마트 렌즈로서 "게시"되는 경우를 도시한다. 도 70은 스마트 렌즈로서(그리고 에이전트를 통해 "호버"하는) 오브젝트를 갖는 컨텍스트 결과 창에서 발룬 팝업 메뉴의 샘플을 도시한다. 이 샘플은 스마트 렌즈가 (A [SMART LENS] B = B [SMART LENS] A)을 암시하는 것을 설명한다. 컨텍스트 창의 결과 섹션은 바람직한 실시예에서 스마트 렌즈가 암시적인 것을 나타내는 도 69에 도시된 예와 동일하다. 도 71은 스마트 렌즈로서 정보 오브젝트 및 "렌스드 오버(lensed over)"되는 아이템으로서 정보 오브젝트를 갖는 컨텍스트 결과 창에서의 발룬 팝업 메뉴를 도시한다. 이 샘플에서, "나의 Nervana UI 스펙"으로 제목이 붙은 오브젝트는 클립보드(그 SQML 표현)에 복사되며, "Nevana UI에 대한 유잉의 생각"(e-메일 오브젝트)으로 제목이 붙은 다른 오브젝트를 통해(결과 창에서) 스마트 렌즈로서 첨부된다. 이 샘플에서, 사용자는 e-메일 메시지와 문서와의 조합에 시맨틱하게 일치하는 술어를 선택하는 옵션을 가진다. 도 72는 2개의 오브젝트들(스마트 렌즈 오브젝트와 "렌즈드 오버" 오브젝트)(이들 둘은 모두 퍼센트로서 그리고 본예에서는 바 챠트로서)의 컨텍스트 측정을 도시하는 도 71의 발룬 팝업 메뉴의 변동 샘플을 도시한다.

도 73-75는 행위 및 관련을 예시하는 샘플 테이블이 스마트 렌즈를 사용할 때 오브젝트 타입 술어를 포함하는 것을 도시한다. 도 73은 스마트 렌즈 행위가 상호적인, 예컨대 A [Smart Lens] B = B [Smart Lens] A인 모든 정보에 대한 에이전트-오브젝트 시나리오를 도시한다. 도 74-75는 스마트 렌즈 행위가 상호적인 예컨대 A [Smart Lens] B = B [Smart Lens] A인 문서 및 e-메일 각각에 대한 오브젝 트-오브젝트 시나리오를 도시한다.

블렌더 스킨 사용자 인터페이스 설명. 도 76은 시맨틱 결과 플레이어/프리뷰 제어를 설명하는 사용자 인터페이스 샘플이다. 정보 에이전트 프리젠터는 바람직하게 이 제어를 각각의 결과 창에 첨부한다. 플레이어/프리뷰 제어는 사용자로 하여금 결과 창에서 결과를 네비게이트하게 하며, 결과를 애니메이트(재생, 중지, 일시정지, 변화, 가속 등)하게 하며, (예컨대, 블렌더의 결과의 경우에) 그 결과를 필터링하게 한다. 도 77은 블렌더의 시맨틱 결과를 도시하는 사용자 인터페이스 샘플이다. 이 샘플에서, 블렌더 스킨은 블렌더의 각각의 에이전트에 대한 분리된 프레임으로서 표시 영역의 부분을 보유하며, 각각의 프레임에 플레이어/프리뷰 제어를 첨부하여, 사용자로 하여금 블렌더의 각각의 에이전트의 결과를 네비게이트, 제어 및 애니메이트하게 한다. 선택적으로, 블렌더 스킨은 블렌더에서(첨부되는 하나의 플레이어/프리뷰 제어로)의 모든 에이전트로부터의 합체된 결과를 표시할 수 있으며, 정보 오브젝트 타입에 따라 프레임에 결과를 표시할 수 있다.

다수의 드래그 및 드롭. 선택적인 실시예에서, 시스템 클라이언트는 사용자로 하여금 데스크탑으로부터 다수의 문서 또는 폴더를 선택하게 하며 이들을 에이전트 또는 블렌더상의 관련 질의를 기초로 사용하게 한다. 이는 사용자로 하여금 다수의 문서를 정밀한(refining) 툴로서 이용하여 질의를 더 정밀하게 한다. 예컨대, 사용자는 이들이 (필터로서 문서 각각을 이용하여) 결과의 단일화 또는 교차를 원하는지를 선택적으로 나타낸다. 이는 하나의 리소스(링크가 드래그되는 오브젝트)와 다수의 링크들(문서당 또는 드래그된 오브젝트당 하나)를 갖는 SQML 파일을 생성한다. 클라이언트 SQP는 바람직하게 모든 오브젝트 필터들에 대한 XML 메타데이터를 검색하고, XML 인자(aguments)를 갖는 목적지 스마트 에이전트의 XML 웹 서비스를 호출함에 의해 이를 해석한다. 바람직한 실시예에서, 에이전시의 XML 웹 서비스는 XML 메타데이터 인자를 카테고리화하며, 질의의 적당한 SQL 표현을 형성하고, 그 결과를 리턴시킨다.

URL 쇼트컷 컨벤션(Shortcut Convention). 본 발명의 에이전시는 이들이 웹 어플리케이션으로서 선택적으로 인스톨되기 때문에 인터넷 웹을 공유한다. 그 결과, 에이전시는 웹의 명명 구성체계(예컨대, 정규 HTTP URL)을 이용하여 레퍼런스 될 수 있다. 바람직한 실시예에서, 본 발명은 정보 에이전트의 시맨틱 환경에 특정된 쇼트컷 명명 컨벤션 및 URL을 드러낸다.

·에이전트 쇼트컷 URL 컨벤션. 에이전트 쇼트컷 URL 컨벤션은 다음과 같다:

agent://＜agentname＞@＜agencyurl＞?start=＜start＞＆end=＜end＞＆skin=＜skin urlL＞

불러질 때, 이는 바람직하게 매우 적절한 HTTP URL, 예컨대:

http://＜path to Agency ASP; or

CGI script＞?agentname=＜agentname＞＆ start=＜start＞＆end=＜end＞＆skin=＜SkinUrl＞.

로 매핑된다.

에이전트 쇼트컷 URL 컨벤션의 예는 다음과 같다:

agent://email.technology.wireless.all@marketing.abccorp.com?start=0＆en d=25＆skin=http://www.nervana.net/skins/email/abcemailskin.xslt

이런 URL은 다음과 같이 클라이언트에 의해 분석된다; 웹 서비스 프락시 시작, WSDL 파일 http://abc.com/nervanaroot/webservice.wsdl 오픈 및 "마케팅"으로 제목이 붙은 에이전시의 통계를 웹 서비스에 요청. HTTP 액세스에서, 이는 ASP 또는 CGI에 대한 경로로 분석된다. 예컨대:

http://abccorp.com/marketingagency.asp?urltype=agent＆agentname=

email.technology.wireless.all＆

start=0＆end=25＆skin=http://www.nervana.net/skins/email/abccorpemailskin.xslt

시작 인자는 첫번째로 리턴하기 위하여 오브젝트의 0 기반 시작 인덱스를 가리킨다. 종료 인자는 종료 인덱스를 가리킨다. 스킨 URL은 선택적이다. 스킨 URL이 특정되지 않으면, 클라이언트는 에이전트의 디폴트 스킨으로 에이전트를 로딩한다. 국부적으로 저장된 에이전트는 agent://＜agentname＞@localhost로 액세스된다. 예컨대, agent://Documents.[Related to My Business Plan]@localhost는 "Documents.[Related to My Business Plan]"으로 제목이 붙은 국부적으로 저장된 에이전트(나의 에이전트에서)를 로딩한다.

·에이전시 URL 컨벤션. 예는 다음과 같다:

agency://＜agencyname＞.＜domainname＞?query=getproperties|getstats|

getagents@agentviewfilter=＜agentviewfilter＞＆agentnamecontainsfilt

er=＜agentnamecontainsfilter＞＆agenttypefilter=＜agenttypefilter＞＆ag e

ntobjecttypefilter=＜agentobjecttypefilter＞

이 예에서, 질의 인자는 "getproperties"이다. URL은 에이전시 자체의 특성을 검색한다(예컨대, 로컬이든 원격이든 간에 이름, 표시 이름 등). 선택적으로, 특성이 "getstats"이면, URL은 에이전시의 통계(에이전트의 전체 수, 표준 에이전트의 수, 컴파운드 에이전트의 수, 도메인 에이전트의 수, 오브젝트의 전체수, 문서 오브젝트의 수, e-메일 오브젝트의 수 등)를 검색한다. 바람직한 실시예에서, getproperties 플래그는 디폴트이며, 어떠한 인자도 특정되지 않았다고 속성이 검색됨을 나타낸다. getproperties 또는 getstatus 인자중 어느 하나가 특정되지 않으면, 바람직하게 어떠한 다른 인자도 함께 특정되지 않는다.

agentviewfilter 인자는 선택적이며, 호출자로 하여금 검색을 제한하기 위하여 에이전트 뷰를 특정하게 한다. 예컨대, 에이전트 뷰 "로이터 뉴스"는 로이터로부터 뉴스 오브젝트를 관리하는 에이전트만을 리턴시키기 위해 서버상에 인스톨 될 수 있다. agentnamecontainsfilter 인자는 선택적이며, 사용자로 하여금 에이전트 이름용 검색 스트링에 의해 결과를 필터링하게 한다. agenttypefilter는 선택적이며, 사용자로 하여금 에이전트 타입(표준 에이전트, 콤파운드 에이전트, 또는 도메인 에이전트)에 기초하여 에이전트를 필터링하게 한다. agentobjecttypefilter 인자는 선택적이며, 사용자로 하여금 에이전트가 관리하는 오브젝트 타입(예컨대, e-메일, 문서, 사람들 등)로 결과를 필터링하게 한다. 예들은 다음과 같다:

agency://sales.boeing.com?query=getstats (corresponding to the HTTP URL

http://boeing.com/salesagency.asp?urltype=agency＆query=getstats)

agency://sales.boeing.com?agenttypefilter=standard＆agentobjecttypei

dfilter=events (corresponding to the HTTP URL

http://boeing.com/salesagency.asp?urltype=agency＆agenttypefilter=st

andard＆agentobjecttypeidfilter=events

·오브젝트 URL 컨벤션. 에이전시 오브젝트는 클라이언트로부터 직접 액세스될 수 있다. URL은 다음과 같다:

objects://＜querystring＞＜agencyname＞.＜domainname＞?querytype=＜o

bjectid|searchstring＞＆objecttypefilter=＜objecttypefilter＞

objectypefilter 인자는 선택적이며, 오브젝트 종류에 의해 리턴된 오브젝트를 필터링하는데 사용될 수 있다. 공지된 오브젝트 종류(예컨대, 문서, e-메일, 이벤트 등)가 열거된다. 예들은 다음과 같다:

objects://34547848@support.attwireless.com?querytype=objectid will

return the object with the objectid 34547848.

objects://80211@support.attwireless.com?querytype=searchstring＆obj

ecttype=email will return the email objects matching the query string

"80211"

·카테고리 URL 컨벤션. URL은 다음과 같다:

category://＜＜categoryname＞@＜kbsurl＞?semanticdomainname=＜sema

nticdomainname＞

semanticdomainname 인자는 선택적이다. 바람직한 실시예에서, 제거된다면, KBS의 디폴트 도메인이 선택된다. 예는 다음과 같다:

category://technology.wireless.all@abccorp.com/marketingknowledge.asp

이는 abccorp.com/marketingknowledge.asp 웹서비스상에 인스톨된 지식기반에 대한 디폴트 도메인용 "Technology.Wireless.All" 카테고리에 대응한다. 이는HTTP URL:

http://abccorp.com/marketingknowledge.asp?category="technology.wireless.all로 분석된다.

매우 적절한 카테고리 URL의 버전의 예는 다음과 같다:

category://technology.wireless.all@abccorp.com/marketingknowledge

.asp?semanticdomainname="/InformationTechnology"

·공유 및 로밍 클라이언트 정보. 바람직한 실시예에서, 사용자는 에이전트들(블렌더를 포함)를 e-메일, 인스탄트 메시지를 통해 전송함에 의해 다른 것과 이들을 공유할 수 있다. 로컬 정보 사용자는 바람직하게 에이전트 정보를 국부적으로 저장하거나 또는 이들을 갖는 정보 로밍을 가진다(예컨대, 디파트먼트(department) 와이드 로밍용 원도우 2000에서의 AbccorpliMirror 지원을 통해, 글로벌 에이전시 디렉토리(식별용 패스워드를 이용하여)상에서의 전용 XML 웹 서비스를 통해, 또는 마이크로소프트(사)의 패스워드 식별 서비스를 채용하는 Microsoft.NET My Services와의 통합을 통해).

로컬 에이전시. 시스템 클라이언트는 바람직하게 사용자로 하여금 "나의 에 이전시(My Agencies)" 리스트로 KIS의 로컬 인스턴스를 실행하는 로컬 에이전시를 또한 생성하고 부가하게 한다. 이런 실시예에서, 클라이언트는 또한 사용자로 하여금 개인 에이전시를 삭제하는 것을 허용하게 한다.

사용자-경험 일치 및 비분열(Non-Disruptiveness). 본 발명의 정보 에이전트(시맨틱 브라우저)는 일치하고 비분열되는 사용자 경험을 제공한다. 달리 말하자면, 정보 에이전트는 오늘날 웹 브라우저와 계속 공존한다. "뒤로(back)", "앞으로(forward)", "홈(home)", "중지(stop)", "새로고침(refresh)" 및 "인쇄(print)"와 같은 툴은 바람직하게 사용자를 혼동시키지 않기 위하여 오늘날 웹 브라우저와 함께 동작한다. 많은 툴은 기능이 다르다 할지라도 동일하게 유지된다. 또한, 새로운 툴은 바람직하게 시맨틱 브라우저에서 새로운 기능을 반영하는 메뉴 옵션 및 툴바에 부가된다(이들은 스크린삿에서 툴바를 보존함에 의해 보여질 수 있다).

도 78 및 79는 새로운 기능을 사용자에게 도입하며 동시에 은유적인 일치를 유지하기 위한 바람직한 매핑을 나타내는 본 발명의 예시적인 기능 매핑을 예시한다. 도 78은 오늘날 웹 브라우저용 디폴트 사용자 인터페이스 툴세트와 본 발명의 정보 에이전트의 바람직한 실시예와의 비교이다. 도 79는 파일 시스템 마이크로소프트 익스플로러/문서 뷰어(Microsoft Explorer/Document Viewer)용 디폴트 사용자 인터페이스 툴세트와 본 발명의 정보 에이전트의 바람직한 실시예의 비교이다.

5. 본 발명에 컨텍스트를 제공함

a. 컨텍스트 템플레이트

본 발명은 정보 액세스 및 검색을 위한 특정 시맨틱 모델에 매핑되는 시나리오-구동 정보 질의 템플레이트 또는 컨텍스트 템플레이트를 제공한다. 본질적으로, 컨텍스트 템플레이트는 미리 정의된 시맨틱 템플레이트를 채용함에 의해 정보를 사용자에게 전달하는 개인용의, 디지털 시맨틱 정보 검색 "채널"로서 고려될 수 있다. 바람직한 실시예에서, 시맨틱 브라우저(30)는 사용자로 하여금 에이전트의 특성을 초기화하기 위하여 컨텍스트 템플레이트를 이용하여 새로운 "스페셜 에이전트"를 생성하게 한다. 컨텍스트 템플레이트는 바람직하게 하나 이상의 에이전시를 통해 정보를 통합한다.

단지 예시적인 목적으로, 본 발명은 다음의 컨텍스트 템플레이트를 정의한다. 시맨틱 정보의 변동 타입의 통합 및 보급을 향하는 부가적인 컨텍스트 템플레이트는 본 발명의 범위 내에서 고려된다(예컨대, "화난(angry)", "슬픈(sad)" 등의 감정에 관련된 컨텍스트 템플레이트; 로케이션, 이동성, 주변 조건, 사용자 기호 등을 위한 컨텍스트 템플레이트를 포함한다).

"헤드라인(Headlines)" 컨텍스트 템플레이트. 헤드라인 컨텍스트 템플레이트(및 그 결과의 스페셜 에이전트)는 시맨틱 정보가 전달되는 방식에서 CNN의 "Headline News"의 개인용의 디지털 버전과 유사하게 될 수 있다. 컨텍스트 템플레이트는 사용자로 하여금 정보의 생성 또는 공개 시간 및 정보 "플래시니스(freshness)"를 정의하는 구성가능한 시간량에 따라 소트되는 하나 이상의 에이전트로부터 정보 헤드라인을 액세스하게 한다. 예컨대, CNN의 "헤드라인 뉴스(Headline News)"는 매 30분마다 헤드라인을 표시한다. 바람직한 실시예에서, 본 발명의 정보 에이전트(30)은 사용자로 하여금 다음의 필터 및 파라미터를 이용하여 헤드라인 스페셜 에이전트를 생성하게 한다:

·정보 오브젝트 관점(pivots). 결과 블렌더는 이들 오브젝트와 관련되는 결과를 나타낸다. 이는 선택적인 파라미터이다. 이것이 특정되어 있지 않으면, 헤드라인은 (임의의 오브젝트에-기초한 필터없이) 전체 에이전시에 대해 표시된다.

·미리결정된 "플래시니스" 주기. 예컨대, 30분, 1시간 등

·술어. 이는 정보 오브젝트 링크가 검색될 정보에 링크되는 방법을 정의한다. 예는 다음과 같다: "관련된(related to)", "관련가능한(possibly related to)"(텍스트-기초 검색을 이용한다), "저작된(authored)"(사람 오브젝트의 경우에), "저작가능한(possibly authored)", "전문 지식을 갖는다(has expertise on)" 등. 디폴트 술어 "관련된"은 바람직하게 디폴트로 사용된다. 이런 디폴트 술어는 이를 특정 술어에 지능적으로 매핑함에 의해 에이전시에 의해 분석된다.

·에이전시(들). 이는 헤드라인을 체크하는 에이전시들을 포함한다. 적어도 하나의 에이전시는 특정되야만 하며, 특정될 수 있는 에이전시의 수에는 제한이 없다. 사용자는 "최근" 및/또는 "즐겨찾기" 리스트가 사용되야 하는지 여부를 가리킨다.

·카테고리 리스트. 예컨대, "Technology.Wireless.All". 이는 질의용 부가 필터로 작용한다.

플래시니스에 덧붙여, 헤드라인 컨텍스트 템플레이트는 바람직하게 결과의 랭킹을 결정하기 위하여 결과 아이템이 얼마나 "hot"한지를 통합한다. 이는, 오브 젝트의 주제가 "hot"지를 나타내는 좋은 표시자인 에이전시상에서 시맨틱하게 관련된 오브젝트의 수를 찾기 위하여 에이전시를 질의함에 의해 달성된다. 또한, 리턴된 오브젝트(또는 아이템)는 바람직하게 플레시니스 또는 새로운 것으로 분류된다.

예로서, 첨부의 SAMPLE D는 바람직한 실시예의 헤드라인 컨텍스트 템플레이트로부터 출력된 SQML을 예시한다. 이 예에서, 컨텍스트 템플레이트는 30분의 플레시니시 시간 간격을 가지며 "관련된" 술어를 갖는 4개의 다른 에이전시들(마케팅, 재검색, 판매, 및 사람 리소스(resource))로부터 모든 정보를 검색한다. 바람직한 실시예에서, 본 예의 SQML은 컨텍스트 템플레이트용과 같이, 스마트 렌즈, 스마트 복사 및 첨부, 드래그 및 드롭, 및 시맨틱 툴박스에서의 다른 툴을 기초로 하여 선택적일 수 있다.

"브레이킹 뉴스" 컨텍스트 템플레이트. 브레이킹 컨텍스트 템플레이트(및 그 결과 스페셜 에이전트)는 시맨틱 정보가 전달되는 방식에서 CNN의 "Breaking News"의 개인용의 디지털 버전과 유사하게 될 수 있다. CNN의 "Breaking News" 삽입과 같이, 이런 컨텍스트 템플레이트는 사용자로 하여금 정보 생성 또는 공개 시간 또는 이벤트 발생 시간(이벤트의 경우에)에 의해 바람직하게 분류되며, 플래시니스를 정의하는 구성 가능한 시간량과 시간 임계성을 정의하기 위해 이벤트용 구성가능한 "데드라인"을 갖는, 하나 이상의 에이전시로부터 "브레이킹"의 시간 임계 정보를 액세스하게 한다. 예컨대, 컨텍스트 템플레이트는 최종 한시간에서 게시되는 정보 오브젝트 또는 다음날에서 홀딩되는 이벤트를 필터링하도록 정의될 수 있다.

바람직한 실시예에서, 브레이킹 뉴스 컨텍스트 템플레이트는 브레이킹 뉴스 에이전트와는 다르다. 컨텍스트 템플레이트는 하나 이상의 에이전시로 통과하는 스태틱 질의 파라미터를 정의하는 템플레이트이다. 브레이킹 뉴스 에이전트는 사용자가 생성하며 본질적으로 사용자 생성이고 사용자 커스텀화 가능한 임의의 스마트 에이전트이다. 예로서, 브레이킹 뉴스 컨텍스트 템플레이트를 기초로 한 브레이킹 뉴스 스페셜 에이전트는 최종 시간에 게시된 정보 오브젝트 또는 로컬 문서(또는 특정된다면 임의의 다른 로컬 컨텍스트)와 관련된 다음날에 홀딩된 이벤트를 사용자에게 알린다. 그러나, 브레이킹 뉴스 에이전트는 "내 팀의 멤버에 의해 주어지며, 다음 24시간에 시애틀 또는 포틀랜드 중 어느하나에 홀딩되고, 내 하드드라이브상에서의 이런 문서와 관련되는 무선 기술에 대한 이벤트"에 대한 경고를 수신하는 플렉시빌리티(flexibility)를 사용자에게 준다. 브레이킹 뉴스 에이전트는 사용자에게 브레이킹 뉴스 컨텍스트 템플레이트보다 많은 플렉시빌리티과 인격주의(personalization)을 제공한다. 브레이킹 뉴스 컨텍스트 템플레이트의 이점은 전형적인 사용자에 대한 "브레이킹"으로 적절한 파라미터를 이용함에 의해 고유(intrinsic) 경고에 대한 기준을 바람직하게 형성한다는데 있다.

"대화" 컨텍스트 템플레이트. 대화 컨텍스트 템플레이트(및 그 결과 스페셜 에이전트)는 시맨틱 정보를 전달하는 방식으로 CNN의 "Crossfire" 프로그램의 개인용의 디지털 버전과 유사할 수 있다. 정보 보급용 컨텍스트로서 토론(debate) 및 대화(conversation)를 사용하는 "집중포화(Crossfire)"와 유사하게, 바람직한 실시예에서, 대화 스페셜 에이전트는 e-메일 게시, 주석, 및 관련된 정보에 대한 쓰래 드(thread)를 추적(tracking)한다. 대화 컨텍스트 템플레이트는 e-메일 오브젝트 타입으로 필터링된 헤드라인 컨텍스트 템플레이트로서 여겨진다. "헤드라인" 파라미터에 덧붙여, 대화 컨텍스트 템플레이트는 바람직하게(그러나 선택적으로) 다음의 파라미터를 포함한다:

·리턴하는 최소한의 쓰래드 길이. 사용자는 그가 적어도 하나의 응답, 2개의 응답 등으로 e-메일 쓰래드만을 원하는 것을 선택적으로 가리킨다. 많은 경우에, 쓰래드의 수는 시맨틱 중요도의 표시를 제공한다. 디폴트는 0이다.

·분배 리스트 필터. 사용자는 "from", "to", "cc", 또는 "bcc" 라인상에서 하나 이상의 분배 리스트의 멤버를 갖는 것들에 리턴된 e-메일을 선택적으로 제한한다. 이는 사용자로 하여금 바람직한 그룹, 분할 등으로부터 토론(debate)을 모니터링하길 원하게 한다.

·분배 라인 필터. 사용자는 "from", "to", "cc", 또는 "bcc" 라인상에서 필터 e-메일 어드레스를 갖는 것들에 리턴된 e-메일을 선택적으로 제한한다. 리턴된 아이템은 대화 쓰래드의 깊이에 기초하여 또는 플레시니스에 기초하여 선택적으로 분류된다.

"뉴스메이커" 컨텍스트 템플레이트. 뉴스메이커 컨텍스트 템플레이트(및 그 결과 스페셜 에이전트)는 시맨틱 정보를 전달하는 방식으로 NBC의 "Meet the Press" 프로그램의 개인용의 디지털 버전과 유사할 수 있다. 이 경우, 강조는 뉴스 그 자체 또는 대화와는 상반되게 "people in the news"에 있다. 사용자는 정보 오브젝트 피벗으로서 리턴된 사람을 이용하여 네트워크를 네비게이트한다. 뉴스메 이커 컨텍스트 템플레이트는 바람직하게 "people" 또는 "users" 오브젝트 타입 필터, "authored by", "possibly authored by", "hosted by", "annotated by", "expet on" 등의 술어(사람을 정보와 관련시키는 술어)을 갖는 헤드라인 컨텍스트 템플레이트로서 고려될 수 있다. "관련된" 디폴트 술어는 바람직하게 밀접한 관계가 있는 특정 술어 모두를 포함하도록 사용된다. 관련 정보, 예컨대 뉴스메이커의 분류 순서는 "그들이 만든 뉴스(news they make)", 예컨대 헤드라인의 순서에 기초하여 분류된다. 헤드라인 컨텍스트 템플레이트 파라미터에 덧붙여, 뉴스메이커 컨텍스트 템플레이트는 바람직하게 다음의 선택적인 파라미터를 포함한다:

·분배 리스트 필터. 사용자는 "from", "to", "cc", 또는 "bcc" 라인상에서 하나 이상의 분배 리스트의 멤버를 갖는 것들에 리턴된 e-메일을 선택적으로 제한한다. 이는 사용자로 하여금 바람직한 그룹, 분할 등으로부터 토론을 모니터링하길 원하게 한다.

·분배 라인 필터. 사용자는 "from", "to", "cc", 또는 "bcc" 라인상에서 필터 e-메일 어드레스를 갖는 것들에 리턴된 e-메일을 선택적으로 제한한다.

"업커밍 이벤트" 컨텍스트 템플레이트. 업커밍 이벤트 컨텍스트 템플레이트(및 그 결과 스페셜 에이전트)는 정보를 전달하는 방식으로 특정 프로그램의 개인용의 디지털 버전과 유사할 수 있다. 예는 "월드 시리즈(World Series)", "미프로농구 결승(NBA Finals)", "월드컵 축구 결승(Soccer World Cup Finals)" 등과 같은 이벤트용의 특정한 것을 포함한다. 지식-작업자 시나리오에서의 균등물은 하나 이상의 카테고리, 문서 또는 다른 정보 오브젝트 관점과 관련된 모든 업커밍 산업 이 벤트를 모니터링하길 원하는 사용자이다. 업커밍 이벤트 컨텍스트 템플레이트는 바람직하게 단지 업커밍 이벤트가 필터링되고 표시되는 것을 제외하고는 헤드라인 컨텍스트 템플레이트와 동일하다(바람직하게 이벤트 및 시간 임계성(criticality)을 내포하는 시맨틱하게 적절한 "컨텍스트 스킨"을 이용하여). 리턴된 오브젝트는 먼저 리스트된 가장 임박한 이벤트들로 시간 임계성에 기초하여 바람직하게 분류된다.

"디스커버리" 컨텍스트 템플레이트. 디스커버리 컨텍스트 템플레이트(및 그 결과 스페셜 에이전트)는 "디스커버리 채널"의 개인용의 디지털 버전과 유사할 수 있다. 이 경우, 강조는 특정 주제에 대한 "다큐맨터리(documentaries)"상에 있다. "헤드라인 뉴스"의 경우와는 달리, 시맨틱 정보 액세스 및 검색을 위한 우선적인 축은 시간이 아니다. 오히려, 이들 카테고리들 주위의 정보의 지능 집합을 갖는 하나 이상의 카테고리에 있다. 본 발명의 바람직한 실시예에서, 디스커버리 컨텍스트 템플레이트는 소정의 카테고리의 세트와 관련되며 선택적으로 미리결정된 구성가능한 시간 주기내에서 게시되는 정보 오브젝트를 랜덤하게 선택함에 의해 정보의 지능 집합을 시뮬레이트한다. 선택적으로 구성가능한 시간 주기가 있다할지라도, 정보가 순서화되거나 존재하는 방법을 결정하기 위해 시간과는 다른 시맨틱 웨이트(weight)가 바람직하게 고려된다. 본 발명은 다른 축이 사용되는 것을 허용한다. 예컨대, "디스커버된" 카테고리 또는 카테고리들용 시맨틱 웨이트, 시간, 랜덤성, 또는 모든 축의 조합("디스커버리"의 효율성을 증가시킬 수 있는). 디스커버리 컨텍스트 템플레이트는 바람직하게, 에이전트가 리턴하는 정보(에이전시로 게 시되는)의 오래된 정도를 가리키는 선택적인 시간(age) 제한으로 플레시니스 시간 간격이 대체되는 것을 제외하고는, 헤드라인 컨텍스트 템플레이트와 동일한 파라미터를 가진다.

"히스토리" 컨텍스트 템플레이트. 히스토리 컨텍스트 템플레이트(및 그 결과 스페셜 에이전트)는 "히스토리 채널"의 개인용의 디지털 버전과 유사할 수 있다. 이 경우, 강조는 특정 주제에 대한 것뿐만 아니라 히스토리 컨텍스트를 갖는 보급 정보에 있다. 이런 템플레이트에서, 바람직한 축은 카테고리 및 시간이다. 히스토리 컨텍스트 템플레이트는 디스커버리 컨텍스트 템플레이트와 유사하며, "최소 시간(age) 제한"과 일치한다. 파라미터들은, "최대 시간(age) 제한" 파라미터가 "최소 시간(age) 제한" 파라미터(또는 선택적인 "히스토리 시간(age) 간격" 파라미터)로 대체되는 것을 제외하고는 디스커버리 컨텍스트 템플레이트의 파라미터와 바람직하게 동일하다. 또한, 리턴된 오브젝트는 시스템에서의 시간 또는 생성 이후의 시간에 기초하여 역순으로 바람직하게 분류된다.

"All bets" 컨텍스트 템플레이트. 모든 베트 컨텍스트 템플레이트(및 그 결과 스페셜 에이전트)는 시맨틱 또는 키워드상에 기초하거나 또는 문자 기반 검색 중 어느 하나에 기초하여 관련되는 임의의 정보를 리턴하는 컨텍스트를 표현한다. 이 경우, 강조는 관련성과 원격으로 관련되는 보급 정보에 있다. 모든 베트 컨텍스트 템플레이트에 대한 우선적인 축은 바람직하게 단지 관련 가능성이다. 바람직한 실시예에서, 모든 베트 컨텍스트 템플레이트는 관련되는 결과의 가장 넓은 가능한 세트를 리턴시키기 위하여 시맨틱 및 문자 기반 질의 모두를 채용한다.

"Best Bets" 컨텍스트 템플레이트. 베스트 베트 컨텍스트 템플레이트(및 그 결과 스페셜 에이전트)는 단지 매우 높게 관련된 정보를 리턴시키는 컨텍스트를 표현한다. 바람직한 실시예에서, 강조는 매우 높게 관련되고 시맨틱하게 중요하게 고려되는 보급 정보에 있다. 이런 컨텍스트 템플레이트에서, 우선적인 축은 컨텍스트이다. 본질적으로, 베스트 베트 컨텍스트 템플레이트는 시맨틱 질의를 채용하며, 문자 기반 질의 결과의 컨텍스트를 보장할 수 없기 때문에 문자 기반 질의를 사용하지 않는다. 베스트 베트 컨텍스트 템플레이트는 바람직하게 카테고리 필터 또는 키워드로 초기화된다. 키워드가 특정된다면, 카테고리화는 서버에 의해 다이나믹하게 수행된다. 결과는 컨텍스트 점수, 또는 오브젝트와 카테고리 필터와의 "카테고리에 속한(belongs to category)" 시맨틱 링크의 강도에 기초하여 바람직하게 소트된다.

"Favorites" 컨텍스트 템플레이트. 즐겨찾기 컨텍스트 템플레이트(및 그 결과 스페셜 에이전트)는 "favorite" 또는 "popular" 정보를 리턴시키는 컨텍스트를 표현한다. 이 경우, 강조는 다른 것에 의해 부여되며 양호하게 수용되는 보급 정보에 있다. 바람직한 실시예에서, 즐겨찾기 컨텍스트 템플레이트에 대한 축은 당해 리더십(readership)의 레벨, 수신된 오브젝트의 "리뷰", 및 오브젝트상에서 주석 쓰래드의 깊이를 포함한다. 일 실시예에서, 즐겨찾기 컨텍스트 템플레이트는 "즐겨찾기" 시맨틱 링크를 갖는 정보만을 리턴시키며, 오브젝트에 대한 "보트(votes)"의 수를 카운팅함에 의해 소트된다(이런 시맨틱 링크에 기초하여).

"classics" 컨텍스트 템플레이트. 클래식 컨텍스트 템플레이트(및 그 결과 스페셜 에이전트)는 "클래식" 정보를 리턴시키는 컨텍스트, 또는 인식된 값이 있는 정보를 표현한다. 즐겨찾기 컨텍스트 템플레이트와 같이, 강조되는 점은 다른 것에 의해 부여되며 선호적으로 수용되는 보급 정보에 있다. 이런 컨텍스트 템플레이트에서, 바람직한 축은 히스토리 컨텍스트, 당해 리더십의 레벨, 수신된 오브젝트의 "리뷰", 및 오브젝트상에서 주석 쓰래드의 깊이를 포함한다. 클래식 컨텍스트 템플레이트는 바람직하게 즐겨찾기 컨텍스트 템플레이트에 기초하여 구현되나 부가적인 최소 나이 제한 필터, 본질적으로는 "Old Favorites" 컨텍스트 템플레이트로서 기능한다.

"Recommendations" 컨텍스트 템플레이트. 추천 컨텍스트 템플레이트(및 그 결과 스페셜 에이전트)는 "추천된" 정보를 리턴시키는 컨텍스트, 또는 에이전시가 사용자에게 관심있는 것으로 추론되는 정보를 표현한다. 추천은 "추천" 시맨틱 링크를 "시맨틱 링크(SemanticLinks)" 테이블에 부가하고 사용자가 가리키는 즐겨찾기 시맨틱 링크를 마이닝(mining)함에 의해 삽입된다. 추천은 바람직하게 기계 학습 및 공동 필터링과 같은 기술을 이용하여 이루어진다. 이런 컨텍스트 템플레이트의 강조는 사용자에게 관심있기 쉬우나 사용자에게 보여지지 않은 보급 정보에 있다. 이런 컨텍스트 템플레이트에서, 우선적인 축은 바람직하게는 관심 및 플래시니스의 가능성을 포함한다. 바람직한 실시예에서, 컨텍스트 템플레이트는 시맨틱 환경에서 에이전시상의 우선적인 술어 필터로서 PREDICATETYPEID_ISLIKELYTOBEINTERESTEDIN 술어를 갖는 SQML을 생성시킴으로서 구현된다.

"Today" 컨텍스트 템플레이트. 오늘 컨텍스트 템플레이트(및 그 결과 스페셜 에이전트)는 "오늘" 게시 또는 홀딩(이벤트의 경우)하는 정보를 리턴시키는 컨텍스트를 표현한다. 이런 컨텍스트 템플레이트로의 강조는 바람직하게 플래시니스를 결정하기 위하여 필터가 있는 "오늘"에 기초하여 현재로 여겨지는 보급 정보상에 있다. 바람직한 실시예에서, 오늘 컨텍스트 템플레이트는 헤드라인 컨텍스트 템플레이트의 서브세트이며, 여기서 결과 게시 "오늘" 또는 이벤트 홀딩 "오늘"이 표시된다.

"variety" 컨텍스트 템플레이트. 변형 컨텍스트 템플레이트(및 그 결과 스페셜 에이전트)는 랜덤 정보를 리턴시키는 컨텍스트를 표현한다. 이런 컨텍스트 템플레이트로의 강조는 사용자가 가능한 정보 아이템의 넓은 범위를 얻을 수 있게 하기 위하여 랜덤한 보급 정보상에 바람직하게 있다. 바람직한 실시예에서, 우선적인 축은 "랜덤" 아이템이 질의 필터("관련된" 술어를 이용하여)에 시맨틱하게 관련됨에도 불구하고 랜덤성이다.

b. 컨텍스트 스킨

본 발명은 "컨텍스트 스킨(Context Skins)"이라 불리는 스킨의 클래스를 포함한다. 컨텍스트 스킨은 이들이 표현하는 컨텍스트의 시맨틱을 전달하는 프리젠테이션 정보를 포함한다. 예컨대, 오늘 컨텍스트 템플레이트에 대한 컨텍스트 스킨은 자정을 가리키는 시계에 배경 또는 필터 효과를 표시하거나, 또는 "오늘(Today)"의 몇몇 다른 표현을 표시한다. 또 다른 예에서, 변형 컨텍스트 템플레이트에 대한 컨텍스트 스킨은 (결과의 랜덤성을 나타내는) 랜덤하게 구르는 볼링공과 같은 변형 효과를 나타내며; 브레이킹 뉴스 컨텍스트 스킨은 컨텍스트의 임계성을 나타내기 위하여 플래싱(flashing) 문자, 적색광 앰블런스 등을 갖는 광 애니메이션 및 효과를 나타내고; 히스토리 컨텍스트 스킨은 "시간(age)"를 나타내는 그래프를 도시하며; 예컨대, 오래된 차, 시계 등.

컨텍스트 스킨은 바람직하게 표시되는 오브젝트 타입에 대한 프리젠테이션 템플레이트를 "아너(honor)"한다. 예컨대, e-메일 오브젝트는 컨텍스트 템플레이트를 가리키는 그래픽뿐만 아니라 우표 또는 우체국 트럭을 나타내는 배경으로 표시된다. 몇몇 컨텍스트 템플레이트가 에이전시를 통해 절단되기 때문에 - 따라서 온톨로지를 통해 절단되기 때문에, 이들은 온톨로지(예컨대, 산업 정보)를 가리키는 임의의 정보를 표시할 필요가 없다. 그러나, 카테고리 필터로 초기화되는 컨텍스트 스킨은 컨텍스트 템플레이트의 온톨로지 또는 카테고리를 바람직하게 가리킨다. 전형적으로, 이는 온톨로지의 산업 또는 분야를 가리키는 그래픽 요소(및 필터, 변형 등)로 표현될 것이다. 예컨대, 제약 컨텍스트 스킨은 연구소 설비를 나타내는 필터 효과를 가지며; 오일 및 가스 컨텍스트 스킨은 오일 리그(rig)의 픽쳐를 나타내고; 스포츠 컨텍스트 스킨은 스포츠 기어의 픽쳐를 나타낸다.

c. 스킨 템플레이트

본 발명은 사용자의 일(task)에 따라서 다른 종류의 스킨을 선택하게 한다. 다양한 프리젠테이션을 갖는다는 암시는 사용자가 현재 태스크에 기초하여 베스트 프리젠테이션 모드를 선택한다는데 있다. 예컨대, 사용자는 메인 기계에서 동작할 때 그리고 생산성이 가장 크고 효과는 없는 경우에 민감한(subtle) 스킨을 선택한 다. 사용자는 생산성이 또한 중요하나 효과도 또한 좋은 경우에 적당한 스킨을 선택한다. 사용자는 예컨대 사용자가 그들의 주변 시야에서 정보를 뷰잉하는 경우에 제2 기계와 같은 시나리오에 대한 익사이팅(exciting) 스킨을 선택하며, 사용자에게 브레이킹 뉴스를 경고하기 위한 문자-대-음성(text-to-speech)와 같은 특징은 중요하다. 익사이팅 스킨은 애니매이션, 딥 정보에 대한 효과와 같은 스토리보드, 모션 경로상에 표시된 오브젝트, 및 다른 효과를 특징으로 한다. 익사이팅 스킨은 스크린세이버로 가장 일반적으로 사용한다. 스킨들의 선택은 바람직하게 사용자 선택가능한 것이다.

d. 디폴트 술어

바람직한 실시예에서, 각각의 오브젝트 타입은 다른 오브젝트 타입가 링크하는 디폴트 술어를 포함한다. 이는 시맨틱 링크에 사용하기 위해 술어의 분리된 평가를 요구함이 없이 오브젝트들을 다이나믹하게 함께 링킹하는 직관적인 방법을 사용자에게 제공한다. 예컨대, 문서 오브젝트로부터, 문서를 리턴시키는 에이전트로의 드래그 및 드롭 동작은 술어 "관련된(Related to)" 및 "관련가능한(Possible Related to)"를 가질 수 있다. 문서 오브젝트가 문서 에이전트의 상부상에서 드래그될 때, 본 발명의 시맨틱 브라우저는 사용자로 하여금 시맨틱 질의의 사용에 대한 술어를 선택하게 하는 팝업 메뉴 옵션을 표시한다. 선택적인 실시예에서, 다른 관련된 팝업 메뉴, 예컨대 링크 또는 술어 템플레이트를 사용자가 선택하게 하는 제1 팝업 메뉴; 및 선택된 템플레이트에 대한 실제 술어를 표시하는 챠일드(child) 팝업 메뉴를 통합한다. 디폴트 술어는 질의가 관련되는 다이나믹하게 생성된 SQML 에 바람직하게 삽입된다.

예로서, 디폴트 술어는 "관련된(Related to)"이다. 이런 술어는 드래그되는 오브젝트와 관련된 문서 에이전트에 정보를 리턴시키는 질의로 매핑된다. 이 경우 디폴트 술어를 갖는 이점은 본 발명의 시맨틱 브라우저가 이런 술어를 이용하여 질의와 교대로 관련되는 "Open"으로 명명된 팝업 메뉴 옵션을 표시하는 것이다. 시맨틱 브라우저는 특정 술어를 갖는 서브메뉴 옵션을 갖는 "Open with Link"로 명명된 팝업 메뉴 옵션을 또한 표시한다. 디폴트 술어는, 디폴트 술어는 소스 오브젝트 및 그 타겟 에이전트 또는 오브젝트를 제공하는 민감한 옵션임을 안다면 사용자가 다이나믹 링킹을 이용하여 시스템을 브라우징할 수 있기 때문에, 시스템을 보다 용이하게 사용할 수 있게 한다.

드래그 및 드롭 시나리오에서 사용되는 것에 덧붙여, 디폴트 술어는 스마트 렌즈, 스마트 복사 및 첨부 등에 선택적으로 사용된다. 디폴트 술어는 컨텍스트로 주어진 "적당한 것(the right thing)"을 리턴시키는 스마트 링크를 변질된(degenerate) 스마트 링크와 유사하게 된다. 바람직하게 디폴트 술어는 하나의 시맨틱 거리에 대한 적당한 질의 결과로서 "적당한 것(The right thing)"을 교대로 생성하는 "관련된(related to)"이다. 선택적인 실시예에서, 디폴트 술어는 여러개의 특정한 술어를 합병한 것이다. 예컨대, 문서-대-사람 드래그 또는 드롭, 복사 또는 첨부, 또는 스마트 렌즈에 대한 디폴트 술어는 "관련된(related to)"이며, 예컨대, "저작된(authored)", "전문가(expert on)" 및 "주석화된(annotated)" 술어과 연관되어 캐스케이드된 질의와 같은 KIS 에이전시 XML 웹 서비스에 의해 해석된다. 달리 말하자면, "컨텍스트(Relevance)"은 본 발명에 의해 스마트하게 해석되고, 다른 술어들을 함께 합병하는 것과 관련된다.

디폴트 술어는 사용자로 하여금 빠르고 효율적이며 거의 생각할 틈도 없이 시스템을 네비게이트하게 한다. 디폴트 술어는 시스템을 간단하게 하고, 사용함에 있어 직관성을 제공하게 한다. 또한, 사용자는 단지 하나의 술어; "인보크(invoke)"가 있는 오늘날 웹 상에서 HTML 링크를 관련짓는데 이미 사용되기 때문에 디폴트 술어로 만족감을 얻는다.

e. 컨텍스트 술어

컨텍스트 술어는 높은 레벨의 요약으로 정의된 술어는며, 컨텍스트 템플레이트의 관련된 서브세트를 매핑하는 술어는다. 컨텍스트 술어는 사용자로 하여금 낮은 레벨 시스템 술어는 아닌 컨텍스트 템플레이트에 기초한 술어 필터를 선택하게 한다. 질의가 컨텍스트 술어과 관련될 때, 컨텍스트 템플레이트의 필터 파라미터를 포함하는 SQML의 필터링은 새로운 SQML 질의를 생성시킨다. 예컨대, 컨텍스트 술어 "베스트 베트(Best Bets)"는 동일한 이름의 컨텍스트 템플레이트로 매핑되며, "베스트 베트(best bets)"인 이들 정보 오브젝트로 질의를 필터링한다(전형적으로, 이들은 시맨틱 질의로부터 리턴되며 문자 기반 질의로부터는 리턴되지 않는 아이템들이다). 유사하게, 브레이킹 뉴스 컨텍스트 술어는 이들이 브레이킹 뉴스 컨텍스트 템플레이트의 필터 조건을 알맞게 하는지 여부에 기초하여 아이템을 필터링한다. 일반적으로, 컨텍스트 술어는 컨텍스트 템플레이트와 일치하는 오브젝트 타입에 적용된다(예컨대, 컨텍스트 술어 "전문가(Experts)" 및 "뉴스메이커 (Newsmakers)"는 "사람들(Person)" 오브젝트를 리턴시키는 질의에만 유효할 것이다.).

f. 컨텍스트 속성

컨텍스트 속성은 에이전시가 클라이언트로 리턴하는 각각의 XML 오브젝트의 일부로서 캐쉬되는 "가상 속성(virtual attributes)"이다. 이들 속성들은 결과가 표시되고 있는 현재 컨텍스트를 반영한다는 점에서 다이나믹하다. 예컨대, 관련된 곳에서, 컨텍스트 속성 "베스트 베트(Best Bets)"는 현재 질의 SQML에서 시맨틱 질의 필터를 만족시키는 각각의 XML 결과에 첨부된다. 디폴트 술어를 갖는 시맨틱 질의의 결과는 시맨틱과 논시맨틱(텍스트 기반 질의) 결과 모두를 포함한다. 질의를 처리하는 에이전시는 필터로서의 결과 오브젝트를 갖는 SQML상에서 시맨틱 서브질의를 실행함에 의해 "베스트 베트(Best Bets)"인 XML 결과에 대한 컨텍스트 속성을 캐쉬한다. 이 경우, "오브젝트"에 대한 구성체계 및 유도된 타입은 각각의 관련된 컨텍스트 템플레이트(예컨대, "베스트 베트(Best Bets)" 속성, "헤드라인(Headline)" 속성 등)에 대한 속성 필드를 포함해야 한다. 이는 바람직한 구현이다. 선택적으로, 시맨틱 브라우저는 에이전시를 호출하며, 인자로서 각각의 XML 오브젝트를 통과하고, 오브젝트가 컨텍스트 속성을 만족하는지를 "문의"한다. 다른 예는 오브젝트가 현재 질의의 컨텍스트에서의 "Headline", "Classics" 속성 등으로 알맞는지를 가리키는 헤드라인 컨텍스트 속성이다. 시맨틱 브라우저는 컨텍스트 속성이 설정된는지 여부를 가리키는 사용자 인터페이스를 표시해야 한다.

컨텍스트 속성은 시스템을 보다 용이하게 사용하도록 한다는 점에서 종래의 시스템에 비해 이점을 가진다. 예컨대, 사용자는 시맨틱과 논시맨틱 질의 필터들(클라이언트로부터 SQML 인자(argument)를 수신할 때 에이전시에 의해 처리되는) 모두를 포함하는 관계 질의를 생성시키기 위하여 드래그 및 드롭 동작을 수행할 수 있다. 일 실시예에서, 브라우저는 사용자가 브로드(broad) 질의 또는 "베스트 베트(Best Bets)" 질의를 원하는지를 사용자에게 "문의"한다. 이런 모드에서, 사용자는 질의가 발행되기 전에 부가적인 필터에 효율적으로 적용된다. 선택적으로, 시맨틱 브라우저와 일치하는 에이전시는 바람직하게 브로드 질의의 결과를 리턴시키며, 컨텍스트 속성에 각각의 결과가 알맞게 하며 각각의 결과 오브젝트가 "브로드(broad)" 또는 "베스트 베트(Best Bets)"인지를 가리키는 사용자 인터페이스에 대응한다. 샘플은 "사람들(Person)" 오브젝트 타입과 같이 다른 오브젝트 타입에 적용된다. 사람 에이전트와의 관계 질의가 "authors", "experts" 또는"annotators"로 리턴되는지 여부를 사용자가 지정하게 하는 것보다는, 브라우저는 브로드 질의를 발행할 수 있고, 각각의 리턴된 "Person" 오브젝트가 현재 컨텍스트에 대한 "authors", "experts" 또는 "annotators"인지 여부에 따라 결과를 알맞게 할 수 있다(에이전시로부터의 도움에).

g. 컨텍스트 템플레이트

컨텍스트 템플레이트는 시맨틱 브라우저내에서 현재 선택된 오브젝트에 대해 인보킹 컨텍스트 템플레이트를 다이나믹하게 관련된 것이 본 발명의 매우 강력한 특징이다. 본질적으로, 컨텍스트 템플레이트는 바람직하게 자동적으로 불러지며, 사용자가 결과 창에서 임의의 오브젝트를 선택할 때 표시된다. 컨텍스트 팔레트는 사용자가 그 배치에서 현재 표시된 결과에 대한 컨텍스트를 가질 수 있게 한다. 또한, 시맨틱 브라우저는 현재 선택된 오브젝트에 대한 팔레트를 일정하게 리플레시하여, 오브젝트에 대한 컨텍스트는컨텍스트는 있는 것을 보장하게 된다. 바람직한 실시예에서, 이는 리플레시 액션을 트리거하는 타이머를 통해 수행되거나, 또는 팔레트가 리플레시되는 최종시간 이후로 임의의 새로운 오브젝트가 있는지 여부를 컨텍스트 팔레트에 대한 SQML 질의 프로세서에 질의함에 의해 수행된다.

바람직한 실시예에서, 컨텍스트 팔레트에 표시된 결과는 메인 결과 창에 표시된 정보 오브젝트와 동일한 방식으로 "1등급(first-class)" 정보 오브젝트이다. 달리 말하자면, 컨텍스트 팔레트는 본 발명의 시맨틱 툴, 예컨대 스마트 복사 및 첨부, 스마트 렌즈, 딥 정보 등의 모든 것을 바람직하게 사용한다. 컨텍스트 팔레트는 바람직하게 본 발명에서 기대되는 다른 컨텍스트 창에 표시된 결과에 대하여 사실(true)이다.

본 발명은 바람직하게 다음의 컨텍스트 팔레트를 포함한다. 바람직한 실시예에서, 사용자는 선택된 오브젝트에 대한 다른 컨텍스트 팔레트를 통해 "스크롤(scroll)"하는 옵션을 가진다. 부가적이며 다른 컨텍스트 팔레트의 통합은 명확하게 기대되며, 컨텍스트 템플레이트의 부가와 병행한다.

"헤드라인" 컨텍스트 팔레트. 이는 헤드라인 컨텍스트 팔레트를 이용하며, 현재 선택된 오브젝트와의 부가적인 링크와, 오브젝트 타입 조합에 대한 디폴트 술어를 갖는 헤드라인 컨텍스트 템플레이트의 SQML을 가지는 SQML을 채용한다. 특히, SQML은 시맨틱 환경에서 즐겨찾기 에이전트 또는 최근의 에이전트 모두를 매핑 하는 리소스에서 벗어난다(keyed off). 사용자는 즐겨찾기 에이전트, 최근의 에이전트, 또는 컨텍스트 팔레트를 생성시킬때 사용되는 모두를 원하는지 여부에 따라 구성된다. 또한, 헤드라인 컨텍스트 팔레트는 표시될 오브젝트의 수 또는 "플래시니스" 시간 제한에 대한 임의의 필터없이 헤드라인을 보이도록 또한 구성될 수 있다. 이 경우, 팔레트는 공개 또는 포스트 시간에 의해 소트된 모든 관련 결과들을 사용자가 네비게이트하게 한다.

"브레이킹 뉴스" 컨텍스트 팔레트. 이는 오브젝트 타입 조합의 디폴트 술어를 이용하여 시맨틱 환경에서 모든 브레이킹 뉴스 에이전트로부터의 관계 결과를 포함하며, 현재 선택된 오브젝트와 링크된다. 또한, 디폴트 브레이킹 뉴스 컨텍스트 팔레트에 대한 결과가 표시된다. 본 발명의 시맨틱 브라우저는 디폴트 술어를 갖는 부가 링크 및 현제 선택된 오브젝트(파일 경로, 폴더 경로, 오브젝트://URL, 등)의 리소스 퀄리파이어(qualifier)를 갖는 브레이킹 뉴스 에이전트 만큼의 많은(그리고 동일한) 리소스 또는 링크 조합으로 SQML을 다이나믹하게 생성시킨다. 본 발명의 시맨틱 브라우저는 생성된 SQML 질의를 불러오고, SRML 결과로 팔레트 윈도우를 로딩한다. 브레이킹 뉴스 컨텍스트 팔레트는 바람직하게 사용자로 하여금 컨텍스트 팔레트에서 결과를 네비게이트하게 하기 위하여 네비게이션 제어를 포함한다.

"Conversations" 컨텍스트 팔레트. 대화 컨텍스트 템플레이트를 활용하는 것을 제외하고는 헤드라인 컨텍스트 팔레트와 유사함.

"Newsmakers" 컨텍스트 팔레트. 뉴스메이커 컨텍스트 템플레이트를 활용하는 것을 제외하고는 헤드라인 컨텍스트 팔레트와 유사함.

"Upcoming Events" 컨텍스트 팔레트. 업커밍 이벤트 컨텍스트 템플레이트를 활용하는 것을 제외하고는 헤드라인 컨텍스트와 유사함.

"Discovery" 컨텍스트 팔레트. 디스커버리 컨텍스트 템플레이트를 활용하는 것을 제외하고는 헤드라인 컨텍스트 팔레트와 유사함.

"History" 컨텍스트 팔레트. 히스토리 컨텍스트 템플레이트를 활용하는 것을 제외하고는 헤드라인 컨텍스트 팔레트와 유사함.

"All Bets" 컨텍스트 팔레트. 모든 베트 컨텍스트 팔레트를 활용하는 것을 제외하고는 헤드라인 컨텍스트 팔레트와 유사함.

"Best Bets" 컨텍스트 팔레트. 베스트 베트 컨텍스트 템플레이트를 활용하는 것을 제외하고는 헤드라인 컨텍스트 팔레트와 유사함.

"Favorites" 컨텍스트 팔레트. 즐겨찾기 컨텍스트 템플레이트를 활용하는 것을 제외하고는 헤드라인 컨텍스트 팔레트와 유사함.

"Classics" 컨텍스트 팔레트. 클래식 컨텍스트 템플레이트를 활용하는 것을 제외하고는 헤드라인 컨텍스트 팔레트와 유사함.

"Rcommendations" 컨텍스트 팔레트. 추천 컨텍스트 템플레이트를 활용하는 것을 제외하고는 헤드라인 컨텍스트 팔레트와 유사함.

"Today" 컨텍스트 팔레트. 오늘의 컨텍스트 템플레이트를 활용하는 것을 제외하고는 헤드라인 컨텍스트 팔레트와 유사함.

"Variety" 컨텍스트 팔레트. 변형 컨텍스트 템플레이트를 활용하는 것을 제 외하고는 헤드라인 컨텍스트 팔레트와 유사함.

"Timeline" 컨텍스트 팔레트. 이런 컨텍스트 팔레트는 헤드라인, 베스트 베트, 히스토리, 및 업커밍 이벤트 컨텍스트 템플레이트로부터의 병합된 결과를 포함한다. 타임라인 컨텍스트 팔레트는 바람직하게 사용자로 하여금 현재 선택된 오브젝트를 기초로 시맨틱 타임라인상에서 모든 오브젝트들을 네비게이트하게 한다. 타임라인은 그들의 공개/포스트 시간을 기초로 한 정보 아이템, 그들의 약속 시간을 기초로 한 이벤트 아이템 등을 포함한다. 본질적으로, 타임라인 컨텍스트 팔레트에서, 사용자는 정보 전달을 위한 우선적인 축으로서 시간을 이용하여 관련된(및 아마 다른 시맨틱하게 관련된) 오브젝트를 네비게이트한다.

"Guide" 컨텍스트 팔레트. 본 발명의 바람직한 실시예는 통합된 가이트 컨텍스트 팔레트를 포함한다. 이런 컨텍스트 팔레트는 모든 컨텍스트 팔레트들을 결합한다. 달리 말하자면, 가이드 컨텍스트 팔레트에서의 각각의 윈도우는 다른 시스템 컨텍스트 팔레트들 각각으로부터의 하나의 결과에 대응한다. 가이드 컨텍스트 팔레트의 사용자 인터페이스는 사용자로 하여금 각각의 윈도우에서 각각의 컨텍스트 팔레트에 대한 결과를 통해 스크롤하거나, 또는 애니메이션 기술, 예컨대 페이드-인/페이드-아웃(fade-in/fade-out) 기술을 이용하여 결과를 애니메이트하게 한다. 가이드 컨텍스트 팔레트의 바람직한 사용은 최소 뷰잉 공간에서 현재 선택된 오브젝트에 대한 컨텍스트를 보는 것이다. 바람직한 실시예에서, 사용은 나란히(수직하게, 수평하게, 대각 방향으로 등), 도킹된(dockrd), 또는 다른 배열 포맷으로 모든 컨텍스트 팔레트를 뷰잉하는 옵션을 가진다.

컨텍스트 팔레트 사용자 인터페이스. 컨텍스트 팔레트에 대한 사용자 인터페이스는 현재 표시된 에이전트에 대한 레이아웃 스킨을 기초로 바람직하게 구성될 수 있다. 바람직한 실시예에서, 컨텍스트 팔레트는 결과 창의 좌측, 우측, 상부 또는 하부상에서 도킹될 것이다. 컨텍스트 팔레트는 뷰잉 영역의 점유(intrusion)를 최소화하기 위하여 상실되며 풀 뷰로 다이나믹하게 재확장된다. 스킨은 또한 컨텍스트 팔레트 원도우가 가변가능한 사이즈 또는 프리셋, 고정 사이즈로 리사이징(resizing)되게 한다. 선택적으로, 몇몇 스킨들은 컨텍스트 팔레트 결과를 또한 애니메이트한다.

예로서, 도 80은 에이전트 결과 및 대응하는 컨텍스트 팔레트를 도시한 사용자 인터페이스를 예시한다. 이 예에서, 여러 컨텍스트 팔레트들은 상실되며, 컨텍스트 팔레트들은 디스플레이의 우측상에서 또는 결과 창상에서 수직하게 도킹되도록 스킨(skin)(또는 존재)된다.

h. 고유 경고

바람직한 실시예에서, 브레이킹 뉴스 에이전트에 덧붙여, 본 발명은 고유 경고를 제공한다. 브레이킹 뉴스 에이전트와 개념적으로 유사하다 할지라도, 고유 경고는 동작시 기본적으로 다르다. 브레이킹 뉴스 에이전트의 경우, 본 발명은 사용자에 의해 특정된 각각의 브레이킹 뉴스 에이전트를 조사하며 브레이킹되는 현재 오브젝트에 관련된 것이 없는지를 찾도록 질의한 후, 브레이킹 뉴스 통지에 관해 사용자에게 시그널링한다. 고유 경고는 사용자에게 브레이킹 뉴스 에이전트를 특정하거나 또는 브레이킹 뉴스 통지를 도입하기 위하여 임의의 액션을 수행할 것을 요구하지 않는다. 고유 경고는 기본적인 고유 방식으로 이슈화된 오브젝트에 관하여 이벤트가 있을 때(모든 현재 표시된 오브젝트에 대한) 사용자 인터페이스에 자동적으로 시그널링된다. 예컨대, 현재 오브젝트가 문서가라면, 본 발명은 문서가 오는 에이전시를 조사하며, 오브젝트와 관련된 에이전시상에서 임의의 최근에 게시된 정보가 있는지를 에이전시에게 문의한다. 현재 오브젝트가 사람이라면, 본 발명은 에이전시를 조사하며,사람이 최근에 e-메일 전송했는지, 문서를 최근에 게시했는지, 문서를 최근에 주석달았는지, 분배 리스트를 최근에 조인(join) 또는 익사이팅했는지를 문의했는지 등을 문의한다. 이는 사용자로 하여금 시간 감도 방식으로 오브젝트의 네이티브(native) 컨텍스트내에서 적절한 정보를 갖게 한다.

바람직한 실시예에서, 고유 경고의 디폴트 구현은 오브젝트가 오는 에이전시만을 조사한다. 이는 사용자 인터페이스를 간략화하는 이점을 가진다; 사용자가 크로스-에이전시 질의를 수행하길 원한다면, 사용자는 관계 질의들을 부르기 위하여 드래그 및 드롭, 복사 및 첨부 등에 대한 옵션을 가진다. 선택적인 실시예에서, 고유 경고는 브레이킹 뉴스 통지를 위치시키는 노력으로, 오브젝트가 오는 다른 에이전시를 포함하는 다수의 에이전시를 조사한다.

선택적인 실시예에서, 본 발명은 사용자가 오브젝트를 액세스하는지에 대한 정보를 유지할 수 있도록 구성가능하다. 이는 사용자가 읽는 어떤 e-메일 메시지를 e-메일 서버가 트래킹을 유지하는 방법과 유사하다. 에이전시가 오브젝트당(per), 사용자당 서버측 상태를 지원하는 실시예에서, 고유 경고는 에이전시가, 사용자에 의해 액세스되거나 읽혀지지 않는 당해 오브젝트와 관련된 에이전시에 대한 정보가 있다면 "고유 브레이킹 뉴스"만이 있다고 가리키기 때문에 항상 정확하다. 이런 대안은 SQML 질의에 대한 부가 필터의 수단으로 바람직하게 달성된다.

본 실시예에 요구되는 오브젝트당, 사용자당 서버측 상태의 대안은 정보의 대용량을 유지하며 많은 수의 사용자(예컨대, 인터넷-기초 에이전시)를 가지는 에이전시에게는 단점이 된다. 이런 상황에서, 시스템은 상태가 오브젝트당 및 사용자 마다 되어있다면 잘 스케일되지 않는다.

에이전시가 오브젝트당, 사용자당 서버측 상태를 지원하지 않는 선택적인 실시예에서, 에이전시는 고유 경고에 대한 스태틱 플래시니스 시간 제한으로 구성된다. 예컨대, 서버는, 고유 경고 질의가 질의에서 오브젝트와 관련된 새로운 오브젝트의 도착의 30분내에 수신되는지에 대한 긍정적인 응답을 서버가 하는 경우에, 30분의 플래시니스 시간 제한으로 구성된다. 바람직한 실시예에서, KIS 에이전시는 평균 정보 도착율에 대한 정보를 유지한다. 이런 방식으로, 비지(busy) 서버는 새로운 정보를 거의 수신하지 않는 서버보다는 낮은 플래시니스 제한을 가진다. 본 실시예는 평균 도착율이, 경고가 시그널링되는지의 여부에 대한 근사만을 생성하기 때문에 오브젝트당, 사용자당 상태를 유지한다할지라도 정확하지 않는다. 본 실시예는 감소된 정보 상실을 가져온다. 바람직한 실시예에서, 본 발명은 소극적인 방식으로, 통계적 속성을 제안하는, 선택적으로 Intrinsic Alert 신호를 보낸다.(즉, 경고가 단지 최상의 추측)

i. 스마트 추천

스마트 추천은 정보 에이전트 관점으로서 오브젝트를 이용하여 추론된 시맨 틱 링크에서 시맨틱 네트워크에 대한 시맨틱 질의를 표현한다. 예컨대, 추론 엔진은 사용자가 이벤트 등의 프리젠터와의 많은 e-메일 대화와 관여한다는 사실에서, 사용자가 과거에 참여한 이벤트에 기초하여, 사용자가 소정 이벤트에 참여하고자 하는 것을 추론한다. 예로서, 바람직한 실시예에서, 이런 정보는 도 81에 도시된 바와 같은 스마트 추천 팝업 컨텍스트 결과 창에서 이용가능하다. 이는 추천 컨텍스트 템플레이트에 대항한 주어진 오브젝트에 대해 사용자가 보는 것과 유사하다.

바람직한 실시예에서, 각각의 링크는 오브젝트 스킨 또는 특정 추천 정보 창 스킨에 의해 생성되며, 추론된 시맨틱 링크에 대한 술어를 포함하는 SQML과 링크된다.

6. 본 발명의 속성 이점

본 발명의 정보 신경 시스템은 사용자가 액션가능한 지식을 획득하게 하기 위하여 적당한 컨텍스트, 의미 및 데이터 및 정보에 대한 효율적인 액세스를 제공한다. 오늘날 웹 및 개념적인 시맨틱 웹에 대한 정보 신경 시스템의 많은 이점은 도 82에 도시된 기술레이어의 사용으로부터 유도된다. 본 발명의 여러 실시예들은, 시맨틱/의미; 컨텍스트-감도; 시간-감도; 자동 및 지능적 발견특성(Discoverability); 다이나믹 링킹; 사용자 제어 네비게이션 및 브라우징; 네트워크에 비HTML 및 로컬 문서 참여; 표시되는 정보의 시맨틱을 스마트하게 전달하는 다양한 프리젠테이션; 로직, 추론 및 추리; 다양한 사용자 중심의 정보 분석; 다양한 시맨틱 질의; 읽기/기록 웹; 주석; "Web of Trust"; 정보 패키지("블렌더(Blender)"); 컨텍스트 템플레이트; 및 사용자 지향 정보 집합을 포함하는 지식 검 색, 관리 및 배달용 결과 매체 및 통합되고 일체화되어(seamless) 구현된 프레임워크를 생성하는데 요구되는 속성에 관련된 이점을 제시한다.

시맨틱/의미

본 발명은 시맨틱 링크, 온톨로지, 및 XML을 이용하는 다른 잘 정의된 데이터 모델을 채용한다. 그 결과, 상술한 에이전시는 그 정보가 시맨틱을 포함하는 시맨틱 웹의 파워를 가진다. 또한, XML 웹 서비스의 고유 부분으로서 의미를 제공함에 의해, 요지(subject matter) 정보와 연관된 컨텍스트-감도, 시간-감도 등을 더 제공한다.

컨텍스트-감도

상술한 지능 시스템 에이전트는 사용자의 사적 컨텍스트를 모니터링하며, 특정 컨텍스트와 관련된 정보 소스(또는 소스들)에 대한 관련 정보가 있을 때 사용자에게 자동적으로 경고한다. 예로서, 특정 컨텍스트는 다음을 포함한다:

·내 문서

·내 웹 포털

·내 즐겨찾기 웹 사이트

·내 e-메일

·내 콘텐츠

·내 캘린더

·내 소비자

·내 음악

·내 로케이션

·"This" 문서

·"This" 웹 사이트/페이지

·"This" e-메일 메시지

·"This" 콘텍트

·내 캘린더에서 "This" 이벤트

·"This" 소비자

·"This" 음악 트랙, 앨범 또는 플레이 리스트

본 발명은 시맨틱 브라우저(30)를 통해 서버(10)와 연관되며 XML 웹서비스와 연관되는 정보 에이전트의 사용을 통해 컨텍스트-감도 사용자 경험을 제공한다. 예컨대, 사용자는 "내문서(My Document)", "내이메일(My Email)"등(파일 시스템, 마이크로소프트(사) 아웃룩 등과 같은 어플리케이션 아일랜드로부터)에서의 정보를 시맨틱하게 관련된 정보를 갖는 원격 정보 소스에 자동적으로 연결한다. 사용자는 예컨대, 드래그 및 드롭, 스마트 렌즈, 스마트 복사 및 첨부 등의 상술한 새로운 질의 툴과 같은 시맨틱 네트워크 상부에 상주하는 어플리케이션 레벨 개선을 통해 이들 연결이 실시간으로 이루어지는 플렉시빌리티를 가진다. 또한 이런 어플리케이션 툴은 예컨대 오늘날 웹의 기존 브라우저로 통합된 시맨틱 네트워크와 독립하게 사용될 수 있음에 유의해야 한다.

바람직한 실시예에서, 본 발명의 KIS는 시맨틱 웹 또는 (바람직하게 RDF 플러그인을 통해) 시맨틱 마크업을 갖는 다른 저장소(repository)로부터의 시맨틱 정 보를 그 시맨틱 네트워크에 풀링한다. 선택적으로, 본 발명의 시스템(10)은 시맨틱 웹없이 존재한다. 이런 상황에서, KIS는 시스템 매니저가 (예컨대, e-메일, 문서 등)을 선택하는 데이터 소스로부터 그 자신의 시맨틱 네트워크(예컨대 사적 시맨틱 웹)을 구축한다. 본 발명의 시스템(10)은 시맨틱 백엔드(backend)(시맨틱 웹을 선택적으로 포함할 수 있는)를 갖는 실재 시맨틱 어플리케이션을 활용할 수 있다. 시스템(10)은 클라이언트측 어플리케이션(전용 시맨틱 브라우저(30)를 포함함), 로케이션 트래킹 툴 등으로의 통합을 통해 컨텍스트 감도 및 전용 XML 웹 서비스(시맨틱 웹이 술어되지 않은)를 제공한다. 더욱 상세히 말하면, 개념적인 시맨틱 웹이 시맨틱 링킹 및 지식 표현 에 대한 아키텍쳐를 술어한다 할지라도, 컨텍스트 감도, 시간 감도, 다이나믹 링킹, 컨텍스트 템플레이트, 컨텍스트 팔레트 등을 제공하기 위하여 XML을 이용하는 시나리오 및 혁신을 지향하지 않는다. 대조적으로, 본 발명은 시맨틱 데이터 모델 및 시맨틱 네트워크를 통한 시맨틱 링킹을 제공할뿐만 아니라, 전용 XML 웹 서비스와의 통합을 통해 컨텍스트 감도, 시간 감도, 다이나믹 링킹, 컨텍스트 템플레이트, 컨텍스트 팔레트, 등에 대한 소프트웨어 서비스를 제공한다.

시간 감도

본 발명은 시간 감도의 고유 개념(intrinsic notion)을 가진다. 예컨대, 브레이킹 뉴스 에이전트, 브레이킹 뉴스 컨텍스트 템플레이트, 브레이킹 뉴스 컨텍스트 팔레트, 및 고유 경고와 같은 시간 감도와 관련된 특징을 제공함에 의해, 본 발명은 시간의 중요성을 시맨틱 및 프리젠테이션의 요소로서 제시한다. 전체적으로 는 사실이 아닐지라도, 일반적으로 말하는 오래된 정보는 통상 새로운 정보만큼 관련된 것이 통상 아니다. 예컨대, CNN이 브레이킹 뉴스를 보이기 위해 뉴스 방송을 중단할 때, 중단은 시맨틱의 조합(표시될 브레이킹 뉴스의 컨텍스트) 및 뉴스가 정말 브레이킹되는 사실에 기초한다. 웹 저작자가 시간 우선순위 분석으로 특히 구축되는 드문 경우를 제외하고는, 경고 및 프리젠테이션용 축으로서의 이런 시간 감도 요소는 오늘날 웹에서 그리고 개념적인 시맨틱 웹에서는 전반적으로 결여되어 있다.

본 발명은 사용자가 스마트 에이전트를 브레이킹 뉴스 에이전트로 선택하도록 한다. 표시될 임의의 정보는 브레이킹 뉴스 에이전트에 관한 관련된 브레이킹 뉴스가 있는지에 대한 경고를 표시한다. 예컨대, 본 발명에서, 사용자는 브레이킹 뉴스 에이전트로서 "오늘 로이터상에 게시된 모든 문서" 또는 "앞으로 24시간내에 시애틀에서 홀딩되며 컴퓨터 기술에 관한 모든 이벤트"의 에이전트를 생성할 수 있다. 이들 에이전트가 개인용("브레이킹"이 주관적이며 사용자에게 의존한다)이기 때문에, 브라우저는 유일한 개별 지원을 제공한다. 또 다른 실시예에서, 시애틀의 사용자는, 앞으로 24시간내에 시애틀의 이벤트, 다음주(값싼 비행을 찾을 수 있는 시간 동안)에서 서부 해안(West Coast)상의 이벤트, 향후 14일후에 미국에서의 이벤트(대부분의 미국 공군에 대한 사전 통지는 경쟁력있는 가격의 대륙간 비행을 얻을 수 있도록 전달된다), 다음달 유럽에서의 이벤트(호텔 예약을 얻을 수 있는 시간을 요구하기 때문에 일어나기 쉬운), 및 앞으로 6달 후 세계 도처에서의 이벤트에 관한 통지를 스케쥴링할 수 있다.

본 발명은 사용자가 브레이킹 뉴스 에이전트를 생성할 수 있는 것에 기초하여 브레이킹 뉴스 컨텍스트 템플레이트를 더 지원한다. 또한, 본 발명은 사용자로 하여금 "브레이킹 뉴스(Breaking News)"의 템플레이트 기초 정의의 컨텍스트에 모든 표시된 결과를 뷰잉하게 하여 일체화(seamless)하고 지능형의 통합 컨텍스트 및 시간 감도를 뷰잉하게 하는 브레이킹 뉴스 컨텍스트 팔레트를 지원한다.

본 발명은 히스토리 분석을 수행하기 위한 강력한 개인용 히스토리 툴을 더 제공한다. 브라우즈 히스토리, 과거 이벤트, 및 문서 생성 시간을 이용하여, 시스템(10)은 예컨대 질의 "6/1/98에서 6/1/99 사이의 디자인 미팅에 참석한 공동작업자"에 대한 결과를 보이면서, 이벤트로부터 구체화시킴으로서 오류가 있는 메모리를 보상할 수 있다. 선택적으로, 시스템은 이벤트의 클러스터를 찾는다. 예컨대, 조사자는 "7/1/01에서 9/11/01까지 비행기 주식에 관한 천만달러($10M) 보다 큰 모든 주식 시장 거래"에 대해 문의한다.

자동 및 지능 발견특성

본 발명의 시스템(10)은 디스커버리의 고유 통지를 가진다. 바람직한 실시예에서, KIS는 로컬 멀티캐스트 네트워크, 기업체 디렉토리(예컨대, LDAP 디렉토리 또는 윈도우 2000 액티브 디렉토리), 피어-투-피어(peer-to-peer) 시스템 또는 다른 시스템상에서 그 존재를 자동으로 공표한다. 이상적으로, 시맨틱 브라우저(30)는 멀티캐스트 또는 피어-투-피어 공표를 주기적으로 들으며, 기업체 디렉토리 또는 글로벌 에이전시 디렉토리를 체크한다. 브라우저는 또한 사용자로 하여금 부가 에이전시를 위치시키기 위하여 계층적 방식으로 시스템을 네비게이트하게 한다. 이런 식으로, 사용자에게 새로운 에이전시가 이용가능할 때 및 기존 에이전시가 만료될 때가 통지된다. 본 발명의 시맨틱 브라우저는 바람직하게, 새로운 에이전시가 이름공간 스냅샷을 통해 이용가능하며 공표 및 디렉토리 존재를 체크할 때를 사용자에게 즉각적으로 통지한다.

피어-투-피어 특징은 시스템(10)으로 하여금 (조직을 위한 큰 진행 비용인) 임의의 집중 유지관리없이 기업체 디렉토리를 자동적으로 상주시키며 스케일하게 한다는데 있다. 시스템은 바람직하게 서버의 새로운 클래스에 대한 프로그램적인 질의를 사용한다.

다이나믹 링킹

본 시스템(10)은 고유 행위를 갖는 스마트 오브젝트를 채용함에 의해 오늘날 웹 및 개념적인 시맨틱 웹에 대해 기본적인 이점을 제공한다. 시스템은 각각의 에이전시 XML 웹 서비스에 행위 특징을 내장하여, 시맨틱 네트워크에서의 각각의 노드가 오늘날 웹 또는 시맨틱 웹상의 규칙적인 링크 또는 노드보다 더 스마트하게 한다. 달리 말하자면, 바람직한 실시예에서, 본 발명의 시맨틱 네트워크에서의 각각의 노드는 저작과 무관한 다른 노드들과 링크된다. 각각의 노드는 에이전시와 다이나믹하게 링크되는 행위를 가진다. 스마트 에이전트는 또한 드래그 및 드롭과 스마트 복사 및 첨부와 같은 부가적인 특징을 허용하며, 시맨틱 환경에서 에이전시와의 링크를 생성하고, 새로운 링크를 생성하기 위해 스마트 에이전트로부터 렌즈 요청에 응답하며, 그 에이전시에 대한 시간 감도 정보와의 링크를 다이나믹하게 생성하는 고유 경고를 포함하고, (노드가 이름공간에서 브레이킹 뉴스 에이전트와 자 동적으로 링크될 수 있는) 브레이킹 뉴스에 대한 프리젠테이션 힌트를 포함한다. 이런 특징들은 예컨대 새로운 링크를 찾고 네비게이트하는 사용자의 기능을 극적으로 증가시킨다. 사용자가 네트워크에서 노드에 도달할 때, 사용자는 관련성, 시간, 스마트 에이전시 및 에이전트에 대한 컨텍스트를 자동적으로 이용하고 다이나믹하게 네비게이트하는 많은 시맨틱 수단을 가진다. 네트워크에 각각의 노드를 형성함에 의해, 전체 시맨틱 네트워크는 스마트, 가상, 자기 치유 및 자기 저작 네트워크가 된다.

본 발명의 다이나믹 링킹 기술은 사용자로 하여금 로컬/원격 정보 경계를 통해 질의를 발행하게 한다. 예컨대, 본 발명은 (바람직하게 SQML 기술을 이용하여) 사용자로 하여금 "연구시에 내 상사 또는 누군가에 의해 기록되며 내 하드디스크상에서 이런 스펙과 관련된 모든 e-메일 메시지를 찾아라"와 같은 질의를 발행하게 한다. 클라이언트측 질의 처리 기술(바람직하게 SQML을 통해)은 프로세서가 관계질의를 처리하는 원격 XML 웹 서비스와 클라이언트로부터의 메타데이터를 링크하기 때문에, 이런 다양한 질의를 가능하게 한다.

스마트 및 다이나믹 정보 전파. 본 발명에 제공되는 다이나믹 링킹은 지능적으로 정보 전파를 제공한다. 시맨틱 네트워크가 오늘날 웹 또는 시맨틱 웹 보다 많은 축으로부터 네비게이트하기 때문에, 정보 공유 및 전파는 훨씬 더 효율적이며 정보 손실은 최소화된다.

사용자 제어 네비게이션 및 브라우징. 본 발명의 다이나믹 링킹 속성은 스태틱 링크가 브라우징 "막다름(dead-ends)"을 가져오는 오늘날 웹 및 시맨틱 웹에 반대되는 연속적인 시맨틱 브라우징을 가능하게 한다. 오늘날 웹 및 시맨틱 웹에서, 사용자는 전형적으로 소정의 로케이션에 브라우징하거나, 또는 추가 링크가 이용가능하지 않은 임파스(impass)에 효율적으로 도달한다. 다이나믹 링킹에서, 사용자는 시간의 그 지점에서 정보 공간의 속성에 의존하여, 노드 그 자체가 링크를 다이나믹하게 업데이트하는 지능을 포함하기 때문에 확실하게 브라우징을 계속한다.

예컨대, 본 발명에 의해 제공된 시맨틱 XML 웹 서비스 및 링킹의 일체화된 통합을 통해, 사용자는 새로운 스마트 에이전트를 생성하기 위하여 파일, 링크 등을 드래그 및 드롭한다. 바람직하게, 이는 반복적으로 일어난다. 스마트 에이전트는 교대로, 적절한 곳에서, 브레이킹 뉴스 에이전트를 만든다. 프리젠테이션 표시에서의 다른 노드들은 임의의 브레이킹 뉴스 에이전트상에 브레이킹 뉴스가 있는지를 가리키는 힌트를 프리젠테이션한다. 계속되는 예에서, 브레이킹 뉴스 에이전트 질의의 결과는 추가 결과를 나타내는 스마트 렌즈로서 사용될 수 있다. 이런 결과는 바람직하게 네트워크를 통한 컨텍스트 및 시간 감도를 사용자에게 제공하는 고유 경고를 포함한다. 연속적인 결과는 임의의 에이전시에게 복사 및 첨부될 수 있으며, 또한 다른 스마트 에이전트상에 드래그 및 드롭될 수 있다.

바람직한 실시예에서, 본 발명의 다이나믹 링킹은 시맨틱 "샌드박스(sandbox)"내의 오브젝트(시스템(10) 환경에 있으며 시맨틱 브라우저(30)내에 표시되는 오브젝트), 또한 그 환경에 다이나믹하게 부가될 수 있는 외부 오브젝트 모두에 적용된다. 이는 기존 문서(파일 시스템 상에서, 오늘날의 웹, 또는 다른 환경) 으로부터 본 발명의 시스템(10)까지 일체화되고, 다이나믹한 이동 경로를 제공한다.

도 83은 본 발명의 바람직한 실시예에 따르는 다이나믹 링킹, 사용자 제어 네비게이션 및 브라우징을 예시한다. 이런 예의 목적으로 "스마트 렌즈"가 본 발명의 다이나믹, 프로그래머블 시맨틱 링크를 언급함에 유의해야 한다.

네트워크에서 비 HTML 및 로컬 문서 참여

본 발명은 네트워크에 포함되기 이전에 문서가 RDF 또는 XML로 부여되는 것을 요구하지 않는다. 오히려, KIS(또는 에이전시 서버)는 모든 종류의 문서로부터 메타데이터를 자동적으로 추출하며 이들을 시맨틱 네트워크에 부가한다. 또한, 클라이언트측 다이나믹 링킹은 바람직하게 드래그 및 드롭, 스마트 복사 및 첨부와 스마트 렌즈와 같은 특징을 통해, 모든 타입의 로컬 문서가 네트워크와 링크되어 네트워크의 값 및 범위를 증가시킴을 보장한다. 본 발명은 로컬 문서로부터 메타데이터를 추출하며, 시맨틱하게 관련된 정보를 검색하기 위하여 KIS(XML 웹 서비스를 통해) 호출한다. 따라서, 로컬 문서는 네트워크로부터 배제되지 않는다. 본 발명은 사용자에게 덤 환경(예컨대, 오늘날의 웹 또는 파일 시스템)으로부터의 문서를 시스템(10)에 드래그 및 드롭하는 권한을 줌으로써, 시맨틱 지능을 제공한다. 메타데이터가 시스템(10)에 있을 때, 시맨틱 렌즈, 스마트 복사 및 첨부 등과 같은 시맨틱 툴은 오브젝트로 수행된다. 드래그 및 드롭은 사용자 파일 시스템 및 오늘날의 웹으로부터 시스템(10)으로 직접 지원한다.

표시되는 정보의 시맨틱을 스마트하게 전달하는 다양한 프리젠테이션

본 발명은 사용자에게 다양한 프리젠테이션의 권한을 부여한다. XML 웹 서비스가 HTML이 아닌 XML을 다시 전송하기 때문에, 그리고 프리젠테이션이 클라이언트상에서 다이나믹하게 생성되기 때문에, 사용자는 시맨틱 정보를 뷰잉하는 다른 "스킨(Skins)"을 선택한다. 스킨은 바람직하게 XML을 프리젠테이션에 적합한 포맷(에컨대, XHTML + TIME, SVG 등)에 전달하여, 사용자로 하여금 여러 표시 기술의 기능에 기초한 스킨을 선택하게 한다. 예컨대, SVG는 XHTML + TIME을 가지지 않는 많은 특징을 가지며, 그 반대의 경우도 가능하다. 사용자는 SVG가 최적화되는 시나리오에 대한 SVG를 선택할 수 있다. 선택적으로, 사용자는 다른 시나리오용 XHTML + TIME를 선택할 수 있다.

본 발명의 일부로서 스킨의 플렉시빌리티는 부가적인 상황에서 어플리케이션을 제공한다. 여러 선택적인 실시예에서, 예컨대, 장님(bliend) 사용자를 돕기 위해 제1 또는 메인 기계와 동시에 제2 기계상에서 시맨틱 브라우저(30)를 실행하는 문자-대-음성 스킨; 현재 뷰-포트의 사이즈에 적합한 다이나믹하게 리사이징이 가능한 스킨(이로 인해 사용자가 윈도우를 리사이징할 수 있으며 즐거운 사용자 경험을 보유할 수 있다); 시맨틱 힌트를 표시하기 위하여 로컬 상태를 체크하는 스킨(예컨대, 이벤트 정보, 예컨대 프리(free)/비지(busy) 정보의 경우의 사용자의 캘린더); 사용자 네비게이션 시간을 저장하는 인라인 프리뷰 윈도우를 표시하며 생산성을 증가시키는 스킨; 고유 경고, 브레이킹 뉴스, 딥 정보, 스마트 추천, 고유 링크, 렌즈 정보에 대한 다른 커스텀가능한 힌트를 표시하는 스킨 등에 의해 사용이 부여된다. 사용자는 또한 예컨대 그가 스크린세이버 모드에서 에이전트를 뷰잉하 고자 하는 스마트 스크린세이버로 사용되는 스킨을 선택하게 한다. 선택적인 실시예에서, 시스템(10)은 컨텍스트 템플레이트 상기에서 설명한, 예컨대 헤드라인, 뉴스메이커, 대화 등에 대한 스킨을 지원한다.

다양한 프리젠테이션을 가능하게 함에 의해, 본 발명은 사용자로 하여금 현재 태스크에 기초한 베스트 프리젠테이션 모드를 선택하게 한다. 예컨대, 사용자는 생산성이 미학적인 효과 보다 높은 우선순위인 메인 기계상에서 동작하는 정교한 스킨을 선택할 수 있다. 사용자는 생산성이 중요하나 그러나 효과가 요구되거나 허용되는 경우에 적절한 스킨을 선택할 수 있다. 사용자는 이차적인(secondary) 도구가 활용되는, 예컨대, 사용자가 브레이킹 뉴스 등을 경고하기 위한 문자-대-음성과 같은 특징을 소망하며 주면 시야에서 정보를 뷰잉하는 것과 같은 시나리오에 대한 익사이팅 스킨을 선택할 수 있다. 익사이팅 스킨은 애니메이션, 딥 정보에 대한 효과와 같은 스토리보드, 모션 경로상에 표시된 오브젝트, 및 다른 특정 효과를 선택적으로 특징으로 한다.

또한, 본 발명에 따르는 스킨은 포함 및 배제 오브젝트 타입 필터들로 선택적으로 구성된다. 예컨대, 스킨은 "문서"만을 포함하고 "분석 리포트"를 배제하도록 구성된다. 스킨이 궁극적인 프리젠테이션을 결정하기 위하여 XML 결과를 취하기 때문에, 스킨은 리턴된 오브젝트의 오브젝트 타입(또는 다른 속성)의 조사에 기초하여 XML(SRML) 결과에 오브젝트를 포함 또는 배제할 수 있다.

로직, 추론 및 추리

본 발명은 로직, 추론 및 추리를 제공한다. KIS 에이전시상의 시맨틱 데이 터 모델은 바람직하게 시맨틱 네트워크의 데이터베이스 처리를 통해 로직, 시맨틱 질의를 SQL로의 변환 및 로직 처리용 다른 데이터베이스 질의 언어 등에 대한 지원을 제공한다. 또한, 본 발명의 시스템(10)은 바람직하게 특정 카테고리 또는 정보 아이템에 대한 전문가와 같은 링크, 추천, 확률 링크(예컨대, 사람이 문서를 기록하는 확률) 등을 추론하기 위한 추론 엔진을 포함한다. 상술한 바와 같이, 본 발명에 따르는 추론 엔진은 시맨틱 네트워크를 관찰하며, 이를 통하여 새로운 시맨틱 링크를 추론하고, 시맨틱링크 테이블에서 결과 링크를 표현한다.

다양한 사용자 중심의 정보 분석

본 발명은 클라이언트에 대한 다양한 정보 분석을 위한 네이티브 지원을 제공한다. 본 발명의 프리젠터는 사용자가 질의를 발행하기 전에 시맨틱 질의의 결과를 먼저보기 위하여 스마트 렌즈를 바람직하게 활용한다. 사용자는 결과를 먼저보기 위하여 관련 술어 및 다른 필터를 변경시킬 수 있다. 선택적인 실시예에서, 사용자는 질의를 불러오며, 원한다면 새로운 서브질의를 기초로 이를 이용하는 옵션을 가진다.

다양한 시맨틱 질의

본 발명은 매우 다양한 시맨틱 질의를 사용자가 발행하게 한다. 사용자는 예컨대 "내 하드드라이브상의 이런 문서와 관련된"와 같은 필터를 이용함에 의해 로컬 컨텍스트를 통합할 수 있다. 오늘날 웹 또는 시맨틱 웹 모두는 이것이 허용되지 않는다. 또한, 본 발명은 바람직하게 전용 시맨틱 질의 언어(SQML)에 대한 레퍼런스를 활용하며 로컬 및 원격 리소스, 술어, 카테고리 레퍼런스 및 오브젝트 를 포함하는 스마트 에이전트를 통합한다. 본 발명은 바람직하게 단순한 마법사 모델을 이용하여 스마트 에이전트(시맨틱 질의를 표현하는)를 생성 및 편집하기 위한 사용자 인터페이스를 용이하게 이용하는 것을 통합한다. 상술한 바와 같이, 시스템(10)은 반복적인 드래그 및 드롭 특징을 통해 새로운 질의의 기초를 시맨틱 질의를 통하여 형성하게 된다. 예컨대, 문서 또는 HTML 링크는 기존 또는 새로운 스마트 에이전트에 드래그될 수 있어, 연속적인 새로운 스마트 에이전트를 생성한다. 스마트 에이전트는 렌즈로서 선택적으로 사용되며, 오브젝트가 새로운 시맨틱 질의를 형성하기 위하여 이들에 첨부될 수 있고, 그 자체가 시맨틱 질의 콘테이너이며 교대로 필터링될 수 있어 서브 에이전트의 콘테이너 또는 서브 블렌더를 생성하는 블랜더에 부가될 수 있다.

읽기/기록 지원

본 발명의 시스템(10)은 사용자가 시맨틱 네트워크로 직접 정보를 공개하게 하는 XML 웹 서비스를 제공함에 의해 읽기/기록 기능에 대한 지원을 제공한다. 이는 임의의 문서, 주석, 또는 파괴된 링크를 수정하거나 새로운 링크를 제공하는 시맨틱 링크일 수 있다. 이는 XML 웹 서비스 및 운영시스템 계층에서 모두 보안상의 제약을 받는다. 시스템(10)은 인증, 액세스 제어, 및 XML 웹 서비스레이어 아래에 위치한 어플리케이션 서버 및 운영체계로부터의 다른 서비스를 채용한다. 이들 보안 서비스는 바람직하게 시맨틱 네트워크에 대한 읽기 및 기록 액세스를 보안하는데 사용된다.

주석

본 발명은 주석을 위한 첨부(built-in) 지원을 포함한다. 개인 오브젝트와 임의의 다른 정보 오브젝트(예컨대, 문서, e-메일 게시, 온라인 코스 등) 사이에 주석 시맨틱 링크를 정의하는 특정 술어 "주석화된(Annotated By)"이 있다. 시스템(10)은 사용자가 고유 링크, 스마트 렌즈 등을 통해 주석을 네비게이트하게 함에 의해 주석에 대한 프레젠테이션 계층 지원을 포함한다. 본 발명이 주석을 통합하는 방식은 기존 기술(주석달린 정보 오브젝트의 일부로서 주석이 달린 인플레이스(in-place) 기술과 같은)의 이점을 제공한다. 본 발명의 바람직한 실시예에서, 주석은 "1그룹(first-class)" 정보 오브젝트이다. 이는 주석이 (스마트 렌즈를 이용하여) "lens" over, (스마트 복사 및 첨부를 이용하여) 복사 및 첨부 등에/로부터 링크될 수 있음을 의미한다. 본 발명은 주석을 본 발명의 시맨틱 툴의 전체에 노출시켜, 표준 주석 기술로 가능한 것 보다 강력한 사용자 경험을 용이하게 한다. 또한, 본 발명의 주석은 컨텍스트 템플레이트에서 사용된다. 그 결과, 추론 엔진은 시스템이 시간에 대해 보다 스마트하게 하기 위하여 이들을 채택할 수 있다. 또한, 시스템(10)은 특별히 포맷된 e-메일(적절한 메시지 본문(body)를 갖는)을 에이전시의 e-메일 에이전트에 전송함에 의해 오브젝트에 주석을 다는 유일하고 용이한 수단을 제공한다.

"WEB OF TRUST"

본 발명은 XML 웹 서비스를 통해 "Web of Trust"를 제공한다. 이런 서비스는 시맨틱 환경을 업데이트하고, 주장하고, 링크를 고정/업데이트하고자 하는 사용자를 인증한다. 이는 또한 풍부한 콘텐츠가 유료 뷰잉 콘텐츠에 대해 등록된 가입 자에게 KIS 에이전시를 통해 이용가능하게 한다. 전체 네트워크의 가치는 많은 풍부한 콘텐츠 소스를 통해 일체화하게 네비게이트하기 위해 동일한 플랫폼을 활용할 수 있을 때 증가한다.

정보 패키지(블렌더)

본 발명은 정보 패키지 또는 "블렌더"를 제공한다. 블렌더는 스마트 에이전트로부터 시맨틱 질의에 대한 레퍼런스를 포함하는 시맨틱 콘테이너이다. 이는 사용자로 하여금 전체 유닛으로서 관련된 시맨틱 정보를 처리하게 한다. 사용자는 개별적으로 블렌더내의 개별 에이전트를 뷰잉하거나 또는 정보가 하나의 집합 에이전트로부터 있는 전체 블렌더를 뷰잉할 수 있다. 이는 바람직하게 XML 웹 서비스에 대한 호출을 통해 각각의 에이전트를 구동함에 의해 수행된다. 바람직한 실시예에서, 사용자는 서브블렌더를 생성하기 위하여 오브젝트를 블렌더들로 드래그 및 드롭한다. 이는 바람직하게 반복적으로 수행된다. 블렌더는 생성, 삭제 및 편집될 수 있다. 사용자는 스마트 에이전트를 블렌더에/로부터 부가하거나 또는 제거할 수 있다.

블렌더는 다른 섹션을 포함하는 개인 신문의 디지털 균등물로서 여겨질 수 있다. 예컨대, USA Today, New York Times, Wall Street Journal 등은 뉴스, 스포츠, 생활/오락 등과 같은 다른 섹션을 포함한다. 이들 섹션 각각의 블렌더에서 스마트 에이전트 엔트리와 대응하며 전체 신문은 블렌더와 대응한다. 본 발명에 의해 제공되는 플렉스블 뷰잉 및 네비게이션은 각각의 신문을 완전히 또한 연속적으로 한번에 브라우즈하거나, 또는 각각의 섹션의 2페이지에 선행하는 각각의 섹션의 1 페이지에서 시작함에 의해 전체 뉴스를 브라우즈할 수 있는 사용자의 디지털 균등물로 여겨질 수 있다.

컨텍스트 템플레이트

상술한 바와 같이, 본 발명은 정보 액세스 및 검색용 특정 시맨틱 모델에 매핑하는 시나리오 구동 정보 질의 템플레이트인 컨텍스트 템플레이트를 제공한다. 본질적으로, 컨텍스트 템플레이트는 미리결정된 시맨틱 템플레이트를 채택함으로서 정보를 사용자에게 전달하는 개인용, 디지털 시맨틱 정보 검색 "채널"로 여겨질 수 있다. 바람직한 실시예에서, 시맨틱 브라우저(30)는 에이전트의 속성을 초기화하기 위하여 컨텍스트 템플레이트를 사용하는 새로운 블렌더 또는 스페셜 에이전트를 사용자가 생성할 수 있도록 한다. 컨텍스트 템플레이트는 바람직하게 하나 이상의 에이전시들을 통해 정보를 집합한다. 또한, 컨텍스트 템플레이트는 바람직하게 사용자에 의해 표시되거나 선택되는 임의의 정보 오브젝트에 대한 지능, 다이나믹 인플레이스 컨텍스트를 제공하기 위하여 컨텍스트 팔레트로 사용된다.

사용자 지향 정보 집합

본 발명은 사용자 지향 정보 집합에 대한 고유 지원을 가진다. 시나리오는 이들이 정보 저장소를 제거한다할지라도 이들이 하나의 소스로부터 오는 컨텍스트 및 시간 감도 정보를 사용자가 뷰잉하게 한다. 이는 사용자가 올바른 컨텍스트에서 그리고 올바른 시간에서 올바른 정보로 표현되는 사용자 지향 컴퓨팅을 제공함에 의해, 정보의 소스에 무관하게 오늘날의 웹 및 개념적인 시맨틱 웹에 대한 보다 큰 생산적인 사용자 경험을 제공한다. 정보 에이전트는 SQML을 통한 클라이언트측 시맨틱 질의를 이용하며 SQML에 대한 다른 에이전시의 응답으로부터 오는 XML 결과를 집합하여 정보 소스를 통해 정보를 다이나믹하게 집합한다.

E. 시나리오

다음은 다른 실제 상황에 적용되는 본 발명의 바람직하며 선택적인 실시예 동작의 예시적인 시나리오들을 제공한다.

1. 본 발명을 활용하는 시맨틱 질의의 예

a. 파일 경로 c:/spec.doc상에서 스펙과 관련된 모든 컨텍스트 찾기

문서를 나타내는 아이콘을 정보 에이전트를 나타내는 아이콘에 드래그 및 드롭하라. 파일은 시맨틱 브라우저에서 오픈되며, 컨텍스트 팔레트가 표시된다. 바람직한 실시예에서, 이들은 다음의 컨텍스트 템플레이트의 몇몇 또는 모두를 포함한다: 헤드라인, 디스커버리, 뉴스메이커, 업커밍 이벤트, 타임라인, 대화, 변동, 클래식, 베스트 베트, 오늘, 브레이킹 뉴스 등. 이들 팔레트는 이름공간에서 "recent" 및 "favorite" 리스트의 에이전시로부터 관련된 컨텍스트를 포함한다.

b. 무선 기술에 대한 경험을 갖는 "R＆D"로 제목붙은 에이전시에 대한 모든 전문자를 찾기

에이전트를 생성시 "새로운 스마트 에이전트" 마법사 시작과 "사용 컨텍스트 템플레이트" 옵션을 선택하라. "선택 에이전시" 대화로부터 "R＆D" 에이전시 선택과 카테고리 브라우저로부터 "무선"으로 명명된 카테고리 선택하라. 새롭게 생성된 스마트 에이전트 오픈하라.

c. 현재 뷰잉되는 웹 페이지에 대한 링크와 관련된 로이터상의 모든 정보 찾 기

"Reuters"를 나타내는 에이전시 아이콘에 링크를 드래그 및 드롭하라. 새로운 스마트 에이전트는 "Information on Reuters relevant to [link title]" 제목을 생성하며, 정보 에이전트에서 오픈한다.

d. 현재 웹 페이지상에서의 링크와 관련되며 파일 경로 c:/spec.doc상의 스펙과 관련된 로이터에 대한 모든 정보 찾기

문서를 나타내는 아이콘을 상기 생성된("Information on Reuters relevant to [link title]") 에이전트에 드래그 및 드롭하라. 이는 "Information on Reuters relevant to [link title] and relevant to spec.doc"의 새로운 스마트 에이전트를 생성한다. 이는 사용자 제어 브라우징 및 다이나믹 링킹을 설명한다.

e. 이전 질의에서 리턴된 로이터에 대한 제1 기사와 관련된 "마케팅(Marketing)" 내부 에이전시에 대한 모든 e-메일 찾기

로이터 기사 오브젝트 하이라이트 및 "동사(Verbs)" 버튼 클릭하라. 이는 팝업 메뉴를 표시한다. "복사" 선택하라. "마케팅(Marketing)"(쉘 확장 트리 뷰상에서) 에이전시를 나타내는 아이콘 찾기를 하라. 아이콘 우측 클릭. "첨부" 를 친다. 이는 "Information on 'marketing' relevant to [Reuter's article title]" 새로운 스마트 에이전트를 생성하고 오픈한다. e-메일 오브젝트를 나타내는 결과 윈도우의 프레임상에 포커스

f. e-메일의 저작자 네비게이트

e-메일 오브젝트 하이라이트 및 "링크"용 버튼 클릭하라. 이는 고유 링크를 나타내는 팝업 메뉴를 표시한다. "From" 메뉴 아이템 네비게이트하라. 이는 e-메일 오브젝트의 "from" 라인상의 사람 오브젝트를 나타내는 팝업 메뉴를 표시한다. 소정의 오브젝트 선택하라. 이는 e-메일 오브젝트를 저작하는 사람의 메타데이터를 나타내는 정보 에이전트에서 새로운 스마트 에이전트를 오픈한다. 사람의 컨텍스트는 또한 컨텍스트 템플레이트에 표시된다. 사용자는 사람 오브젝트 또는 그 컨텍스트(임의의 컨텍스트 템플레이트상에서)를 이용하여 계속해서 브라우징할 수 있다.

g. e-메일에서 첨부에 대한 네비게이트

e-메일 오브젝트 하이라이트 및 "링크"용 버튼 클릭하라. 이는 e-메일 오브젝트의 고유 링크를 나타내는 팝업 메뉴를 표시한다. "Attachment" 메뉴 아이템 네비게이트하라. 이는 첨부의 제목을 나타내는 팝업 메뉴를 표시한다. 소정의 첨부 선택하라. 이는 정보 에이전트 윈도우에서 새로운 스마트 에이전트로서 첨부를 오픈한다. 첨부용 컨텍스트는 컨텍스트 템플레이트에 표시된다.

h. 첨부와 관련된 "Energy Industry Events"상에 모든 이벤트 찾기

e-메일 오브젝트 하이라이트 및 "Verbs"용 버튼 클릭하라. 이는 팝업 메뉴를 표시한다. "복사" 선택하라. "Energy Industry Events"(쉘 확장 트리 뷰상에서) 에이전시를 나타내는 아이콘 찾기를 하라. 오른쪽 아이콘 클릭하라. "첨부" 친다. 이는 "Information on Energy Industry Events relevant to[email attachment title]"의 새로운 스마트 에이전트를 생성하고 오픈한다.

i. 컨텍스트로서 로이터를 이용하여 "내 문서" 폴더를 브라우즈

정보 에이전트에서, "폴더에서 문서 오픈" 선택하라. 선택적으로, "내 문서" 폴더를 정보 에이전트를 나타내는 아이콘에 드래그 및 드롭하라. 서브 폴더가 포함되는지를 가리킨다. 이는 "내 문서"의 새로운 덤 에이전트를 생성하고 오픈한다. 이런 에이전트를 클릭할 때, 이런 폴더의 문서용 메타데이터는 정보 에이전트에서 오픈된다. 문서들중 하나가 선택될 때, 문서용 컨텍스트 템플레이트가 표시된다. 컨텍스트로서 로이터를 이용하여 문서를 브라우즈하기 위하여, 사용자는 로이터 에이전시를 나타내는 아이콘을 찾으며, 오른쪽 아이콘을 클릭하고 "복사"를 친다. 사용자는 정보 에이전트에서 문서 메터데이터를 나타내는 임의의 결과쪽으로 마우스를 이동하며, 스마트 렌즈를 나타내는 아이콘을 선택한다. 스마트 렌즈 윈도우는 관계 질의의 결과상에서 정보를 나타내면서 표시된다. 문서와 관련된 로이터상에 발견된 아이템의 수와, 가장 최근에 게시된 아이템과 같은 정보가 표시된다. 또한, 프리뷰 제어는 사용자에게 적절한 결과를 프리뷰하게 하도록 표시된다. 사용자는 새로운 관계 질의를 나타내는 에이전트를 오픈하기 위하여 결과 클릭능 선택할 수 있다. 선택한다면, 결과에서 제1 오브젝트용 컨텍스트는 컨텍스트 팔레트를 이용하여 표시된다.

j. XML 기술상의 임의의 것과 관련되며 이런 문서와 관련된 브레이킹 뉴스가 있을 때 e-메일, 음성 또는 페이저에 의한 통지

"브레이킹 뉴스" 컨텍스트를 이용하고 카테고리 필터로서 "XML" 카테고리를 이용하여 새로운 스마트 에이전트를 생성하라. 이런 문서를 나타내는 아이콘을 에이전트에 드래그 및 드롭하라. 이는 적절한 제목을 갖는 새로운 스마트 에이전트 를 생성한다. 정보 에이전트에서 "옵션" 메뉴로 진행 및 통지 섹션(당신의 e-메일 어드레스, 페이저 번호, 전화번호 등)에 적당한 정보를 기입하라. 스마트 에이전트 오른쪽 클릭 및 "통지" 선택하라.

2. 사업적 문제

a. 정보 액세스

오늘날 웹(Today's Web). John Head-Master는 샌디애고의 마케팅 컨설팅 서비스 회사인 FastServe에서 일한다. 매일, 그는 일하러 오고 그의 웹 브라우저를 킨다. 오늘, 그는 새롭고 재미있는 정보를 발견할 수 있는지 알기위해 회사 웹을 브라우즈할 것을 결정한다. 브라우저 홈 페이지는 (기업체 정보 포털을 이용하여) 회사 홈 페이지로 설정된다. 회사 홈 페이지는 회사 내의 다른 부서들에 대한 홈 페이지에 대한 링크를 가진다. John은 이들 링크를 네비게이트하며 이곳으로부터 계속해서 링크의 클릭을 유지한다. 한참후에, 단지 그가 경로를 취할 수 있는 것을 알지 못하는 이유에서, 그는 네비게이트하지 않은 더 많은 정보 소스가 있는 것에 실망한다. 결국, 그는 포기한다.

정보 신경 시스템. John은 그 정보 에이전트(시맨틱 브라우저)를 켠다. 이는 홈 에이전트를 오픈한다. 그 페이지상에서, 그는 상품, 상품 그룹, 리포트, 회사 이벤트, 온라인 코스, 및 비디오 프리젠테이션에 대응하는 지식 링크의 리스트를 본다. 그는 "제품 그룹(product group)" 링크쪽으로 마우스를 이동한다. 자동적으로, 발룬 팝업은 링크에 대한 상품 그룹 및 다른 데이터의 수를 가리키면서 나타난다. 그는 링크를 오픈한다. 상품 그룹 오브젝트의 리스트는 커스텀화가능 한 룩 또는 "스킨"으로 표시된다. 그는 그의 마우스를 첫번째 리스트 쪽으로 옮긴다. 팝업 메뉴는 액션과의 링크상에 즉시 나타난다; "멤버를 보임(Show Member)", "유사한 제품 그룹 리스트(List Similar Product Groups)", 및 "그룹 이벤트 통지(Subscribe to Group Event)". 그는 "그룹 이벤트 통지(Subscribe to Group Event)"를 클릭하며, 이런 상품 그룹과 관련된 모든 이벤트에 대해 e-메일(기업체 정보 에이전트를 통해)에 의해 통지된다. 그는 "멤버를 보임(Show Member)"을 클릭한다. 이는 사람에 대응하는 아이콘으로 새로운 "지식 페이지"를 오픈한다. 그는 수산(susan) 그룹 리더용 아이콘쪽으로 마우스를 이동한다. 발룬 팝업은 수산에 대한 정보를 표시하면서 나타난다. 오른쪽 클릭 메뉴는 액션, "리포트(Report To)", "다이렉트 리포트 리스트(List Direct Reports)", "멤버(Member Of)", "저작자의 문서(Authored Documents)", 및 "최근에 개최된 미팅(Recently Attended Meetings)"로 나타난다. John은 "최근에 개최된 미팅(Recently Attended Meetings)"를 선택한다. 이는 하나의 미팅 오브젝트로 새로운 지식 페이지를 오픈한다. John은 이러한 그리고 연속적인 브라우징한다.

몇몇 포인트에서, John은 전날 만났던 공동 작업자를 찾길 원한다. 그는 "Wilbur Jones"을 타이핑한다. 이는 Wilbur에 대응하는 사람 오브젝트로 리턴한다. John은 정보 지식 관점으로서 Wilbur를 이용하여 브라우징을 계속한다.

결과적으로, John은 그가 필요로 하는 정보를 Wilbur가 보유한 것 같지 않다는 것을 알게된다. John은 정보 에이전트상의 검색 박스에 다음과 같은 질의를 타이핑한다: "업커밍 2002 판매 미팅과 관련된 온라인 코스 및 문서 모두를 리스트". (e-메일 에이전트를 이용하여) 정보 에이전트는 지식 질의에 따르는 액션가능한 온라인 코스 및 문서의 리스트를 리턴시킨다.

b. 지식 구동 소비자 관계 관리

소비자 터치-포인트. Anysoft는 100개의 다른 언어의 50개 상품을 갖는 소프트웨어 제조업자이다. 이들은 최신 정보를 소비자에게 제공하기 위하여 웹사이트(anysoft.com)를 사용한다. 그러나, 소비자는 그들의 웹사이트가 네비게이트하기 매우 어려운 것을 불평하며, 상품에서 정보를 찾으며 통지용 가입자를 찾는 것이 매우 어려운 것을 알게된다.

본 발명의 실시예에 기초한 정보 신경 시스템을 배치함에 의해, Anysoft는 그들의 기존 웹사이트와 공존하는 정보 신경 시스템을 배치한다. 정보 에이전트는 홈페이지로부터 그리고 검색 바로부터 액세스가능하다. 소비자는 상품, 관련된 백색 종이, 공표, 언론 발표, 회사 이벤트 등에 대한 웹 사이트를 네비게이트하는 더욱 더 직관적인 방식을 가진다. 소비자는 자기 네비게이트가능하며 액션가능한 지식 오브젝트를 리턴시키는 자연어 질의를 발행할 수 있다. 이런 특징은 그들의 손가락 끝에서 소비자에게 지식을 액세스하게 한다. 소비자는 또한 그들의 핸드헬드(hand-helt) 장치로부터 anysoft.com 웹 사이트를 네비게이트하기 위해 자연어를 이용할 수 있다.

소비자 피드백 및 트래킹. Comp-Mart는 다수의 분배 채널을 갖는 컴퓨터 주변장의 전매자이다. 그 회서는 그 웹사이트, 그 콜센터, 그 직접 판매력, 그 텔레마케팅 에이전트 등으로부터 소비자 피드백을 얻는다. 피드백은 문서 및 e-메일로 온다. 회사는 소비자 피드백이 정보를 필요로 하는 사람들에게 회사에 대하여 적절하게 라우팅되지 않는다는 문제점을 확인했다. 상품 개발 직원들은, 그들이 정보를 찾을 수 있는 곳을 알지못하며 결정적인 지식이 조직내에 공유되지 않기 때문에, 소비자 피드백을 상품 개발 프로세스에 통합하는데 어려움이 있다는 것을 아는 관리부서에 불평한다.

적절한 정보 신경 시스템에서, 소비자 피드백을 포함하는 e-메일은 회사 시맨틱 환경에 통합된다. 본 발명의 KIS는 소비자 피드백 e-메일과, 문서, 프로젝트 및 밀접한 관계가 있는 상품에 대해 일하는 고용자들과 같은 시맨틱 오브젝트 사이에 시맨틱 링크를 자동적으로 부가한다. 소비자 피드백은 지식 공간에서의 올바른 장소에 지능적으로 넘치게 된다(bubble up). e-메일 에이전트는 소비자 피드백 e-메일을 읽는데 관심을 쉽게 가지는 사람들에게 주기적으로 통지한다.

또한, 정보 신경 시스템에서, 소비자는 정보 지식 관점이 된다. 이는 소비자 피드백으로서 보다 빨리 또한 보다 용이하게 작용하게 하며, 소비자 관련 지식을 조직을 통해 보다 빨리 또한 보다 용이하게 트래킹하게 한다. 정보 신경 시스템은 e-메일, 문서, 유사한 소비자 등과 관련된 소비자 오브젝트에 자동적으로 주석을 단다. 이런 식으로, 소비자에 대한 링크는 e-메일을 통해 전송될 수 있으며, 공동 작업자는 그곳으로부터 관련 정보를 네비게이트할 수 있다. 소비자 오브젝트는 검색, 브라우징 등을 할 수 있다.

c. 지식-구동 직접-판매/현장-서비스

Marsha Mindset는 JustInTime Support Services, a computer service firm in Kansas City, Missouri용 소비자 서비스 에이전트이다. Marsha는 Kansas City metro area 주변의 소비자를 방문하며, 어려울 때는 언제나 본부에 지원하기 위해 e-메일을 송부할 수 있도록 무선 PDA를 가진다. JustInTime은 최근에 KIS 및 e-미일 에이전트를 개발했다. 질의에 지원할 때마다, Marsha는 e-메일 에이전트에 e-메일을 보낼 수 있으며, 이를 자연어로 문의할 수 있다. e-메일 에이전트는 직접적인 답변, 또는 Marsha가 관련된 지원 e-메일, 문서 또는 e-메일하거나 전화를 호출할 수 있는 사람들에 즉각 액세스하게 하는 "지식 링크"로 그녀의 e-메일에 응답한다. JustInTime의 직접 판매력은 또한 현장에서 소비자에게 솔루션을 판매할 때 본 발명의 기술을 이용한다. 판매 대표자는 또한 무선 PDA를 가져오며, e-메일 에이전트에 요청을 발할 수 있다.

d. 케이스 스타디

회사 트레이닝, 지식 전달 및 공유. WaveGen은 미국에서 의사들에게 "관리 보호(managed care)"를 제공하는 바이오테크 회사이다. 이 회사는 그 고용자들(그 판매담당)을 트레이닝하기 위한 Saba 학습 관리 시스템 플랫폼을 최근에 개발했다. 이는 트레이닝 비용을 감소시킴으로써, 회사의 판매력을 나라안에서의 다른 헬스케어 영역에서의 의사들 보다 좋게 제공하게 된다. 또한 바이오테크 연구 공동체에서의 최근 발견을 정기적으로 알리면서 회사 연구에 지원을 한다.

회사는 또한 지식의 가치있는 소스를 유지하는 적절한 다른 소프트웨어 자산을 가진다. 이는 문서 및 미디어 파일, e-메일용 Microsoft Exchange, 및 온라인 회의용 공동제작 소프트웨어를 호스트하는 콘텐츠 관리 솔루션을 개발했다. 그러 나, 회사는 이들 모든 솔루션들이 통합되지 않았기 때문에 지식 전달이 매우 효율적이지 않다는 것을 알게됐다. 판매 대표자는 회사의 상품을 의사들에게 선보일때(pitching) 이들을 지원하기 위해 조직 내 또는 그 외부에서 지식의 중요한 소스를 발견하기 위한 툴을 가지지 못함을 알았다. 기업체 정보 포털은 업커밍 코스 및 중요한 이벤트의 판매력을 알리는데 현재 사용된다. 그러나, 판매 대표자는 많은 지식(e-메일, 문서 등에 저장되는)이 어느 누구도 이들을 필요로 하는지를 알지 못하기 때문에 그 관심을 가겨오지 못함을 불평한다.

또한, 판매 대표자는 마이크로소프트 아웃룩(Microsoft Outlook)을 사용하여 업커밍 의사 방문용 캘린더에 약속을 부가한다. 그러나, 이들은 이들이 약속에 대한 연상만을 얻으며, 상품을 보다 효율적으로 판매하는데 도움을 줄 수 있는 많은 정보가 의사와의 약속 이전에 자동적으로 이용가능하지 않다는 불평을 한다.

WaveGen은 본 발명으로부터의 기술에 기초하여 정보 에이전트를 최근에 개발했다. 이 회사는 KIS 및 e-메일 에이전트를 개발하여, 지능 정보 결합을 용이하게하며, 회사 판매 및 연구 팀이 소비자를 지원하고 회사 상품을 개선하는데 보다 좋은 결정을 하도록 도움을 주기 위한 라우팅을 제공한다. 정보 에이전트를 이용하여, 판매력은 문서뿐만 아니라, 그들의 일(task)에 보다 직접적으로 결합되는 "지식 오브젝트"에도 즉각적인 액세스를 한다. 예컨대, 판매 대표자는 XML 오브젝트로서 "Doctor Jones"를 갖는 에이전트를 가진다. 이는 문서 또는 웹 페이지가 아니다. 오히려, 소비자의 시맨틱 표현이다. 판매 대표자는 "최근 e-메일 메시지", "관련된 문서", "속성들", "중요한 날", "관련된 업커밍 온라인 코스" 등과 같은 시맨틱 링크를 볼 수 있다. 이런 식으로, 소비자는 판매 에이전트가 내부 웹을 네비게이트하는 관점이 된다. 이들 링크는 파일 공유, e-메일 저장, Microsoft Exchange등으로부터 결과를 생성시킨다. 그러나, 아일랜드(island)와 같은 이들 지식 소스를 검색하거나 또는 네비게이트하는 대신에, 판매 대표자는 판매 대표자의 일과 관련된 시맨틱 관계에 기초한 새로운 지식을 발견할 수 있다.

이런 식으로, 판매 대표자는 판매 대표자의 손끝에서 보다 더 강력한 지식을 가질 수 있어, 보다 나은 소비자 서비스를 가능하게 한다. 이런 지식은 공동 작업자들, 다른 판매 에이전트에 의해 공개된 문서들, 존재하는 것으로 알려지지 않은 분배 리스트상에 전송된 e-메일 등으로 열거된다. KIS는 모든 이들 본질적으로 다른 소스들로부터 시맨틱 결합들이 자동적으로 이루어짐에 의해 스마트한 것이 되게 한다. 판매 대표자는 이런 "페이지"를 공동 작업자에게 e-메일할 수 있다. 이는 공동 작업자가 동일한 Dr.Jones" 관점을 이용하여 정보 에이전트를 네비게이트할 수 있기 때문에 지식 공유의 매우 강력한 형태가 된다.

e-메일 에이전트는 또한 판매 대표자가 자연어를 통해 지식 질의를 발행하게 한다. 질의 결과는 추론 엔진으로부터 유도되며, 기존 지식으로부터 추정되는 지식을 기초로 할 수 있다. 본 발명의 정보 신경 시스템의 강력한 특징은 지식 전달, 공유, 디스커버리 모두가 시맨틱 네트워크를 기초로 자동적으로 일어난다는데 있다.

3. 상황

a. 시맨틱 정보 디스커버리, 검색 및 네비게이션

Joe 지식 작업자는 정보 에이전트(본 발명의 XML 기초 시맨틱 브라우저)를 시작한다. 그가 로그인할 때, 그에게 시맨틱 인트라넷상에서 이용가능한 새로운 에이전트가 있음을 나타내는 대화상자가 프롬프트된다. 그는 다음의 것을 포함하는 조직 내 및 그 외부로부터의 에이전트의 리스트를 본다:

·Documents.Technology.All

·Documents.Marketing.All

·People.Divisions.Sales.All

·People.Division.Sales.Managers

·OnlineCourses.Sales.101

·OnlineCourses.Technology.XML.101

·Meetings.ThisWeek.All

·Meetings.LastWeek.All

·Books.Computers.Programming.All

·Newsgroups.Microsoft.Public.Soap

·Email.Mine.All

·Email.Mine.ProjectX.All

·Events.Technology.Wireless.All

·Reports.Gartner.Software.All

·Reports.IDC.All

·Videos.ExecutivePresentations.All

그는 Meeting.ThisWeek.All을 선택한다. 정보 에이전트는 그가 이번주에 참석하는 미팅을 나타내는 오브젝트의 리스트를 표시한다. 이런 정보는 Microsoft Exchange로부터 오나, 이는 그에게 나타나지 않는다. Joe는 제1 미팅 오브젝트에 대한 링크쪽으로 마우스를 이동한다. 발룬 팝업은 새로운 트레이닝 코스가 인트라넷상에서 이용가능하게 된 것을 가리키면서 표시된다. 발룬은 또한 Joe와 관련된 IDC상에 새로운 리포트가 있음을 가리킨다. 발룬에 덧붙여, 팝업 메뉴는 오브젝트의 오른쪽에 표시된다. 이 메뉴는 다음과 같은 동사(Verbs)를 가진다:

·List participants

·List possible replacement participants

·Show Related Objects -＞

·On News.Reuters.MarketForecasts.All

·On Documents.Technology.All

·On Events.Corporate.Today.All

·Subscribe for follow-up

Joe는 "Subscribe for follow-up"을 선택한다. 이는 서버상에서 미팅 팔로우-업(follow-up) 에이전트와 콘텍트된다. 이런 에이전트는 관련 정보의 주기적인 업데이트를 미팅 참석자들에게 전송한다. 이는 브라우저 또는 e-메일을 통해 이루어질 수 있으며, Joe는 Events.Corporate.Today.All에 관한 관련된 오브젝트를 선택한다. 이는 이벤트 정보 오브젝트의 리스트를 표시한다. Joe는 제1 오브젝트쪽으로 마우스를 이동하며 팝업 메뉴가 표시된다. Joe는 "Add to calendar"를 선택 하며, 이벤트는 그 캘린더에 부가된다. Joe는 회사 이벤트와 관련된 모든 산업 이벤트를 찾길 원하는지를 결정한다. 그는 에이전트 Events.Technology.All에 오브젝트를 드래그하며, 그 마우스를 릴리스(release)한다. 마우스가 릴리스될 때, 브라우저는 Events.Technology.All(웹 사이트 및 다른 아일랜드를 통해)로부터 그리고 그가 드래그하는 오브젝트가 회사 이벤트와 관련되는 정보 오브젝트를 로딩한다.

다음주에, Joe는 e메일 에이전트로부터 e-메일을 얻는다. e-메일에서, 에이전트는 Joe에게, 이벤트를 캘린더에 부가하는 모든 이가 회사 미디어 서버로부터 회사 트레이닝 비디오를 또한 관찰하는 것을 알았다고 알린다. e-메일은 Joe를 정보 에이전트에 다시 가져가는 XML 링크를 포함한다. 브라우저는 비디오용 메타데이터를 표시한다. 팝업상에 아이템들중 하나는 "비디오 보기(Watch Video)"이다. Joe는 이를 선택하며 비디오를 관찰한다.

Joe가 그 웍스테이션을 로그인하는 다음주에, 그는 새로운 에이전트가 있음을 알게된다. 그는 Books.Ebay.Computers.All에 가입하며 이를 내 에이전트 리스트에 부가한다. 자동적으로, 본 발명의 실시예는 이런 에이전트를 Joe의 시맨틱 환경에 부가한다. 정보 에이전트는 암시적인 질의를 수행하며, 이런 에이전트를 포함하는 추천(컨텍스트 및 시간 감도에 의해 랭킹된)을 제공한다. 그는 이런 에이전트를 클릭하며, 시맨틱 정보 오브젝트(책을 나타내는)가 결과 창에 표시된다. 그가 오브젝트들중 하나쪽으로 마우스를 이동할 때, 팝업 발룬은 그에게 책의 저작자로 호스트되는 관련된 산업 회의가 있다는 사실을 경고하면서 즉시 표시된다. 그가 팝업 링크를 클릭할 때, 이벤트 오브젝트는 브라우저에 로딩되며, 이벤트를 그 캘린더(마이크로소프트 아웃룩 또는 MSN 캘린더(Microsoft's HailStorm Web services를 통해 액세스되는)와 같은 인터넷 기초 캘린더, AOL 캘린더 등)에 부가하게 하는 동사(verb)를 가지고 완성한다.

시나리오의 설명. 이런 시나리오는 본 발명에서 지식 작업자가 "연합된 지식(federated knowledge)"에 대한 액세스를 어떻게 얻을 수 있는지 나타낸다. 본 예에서, Joe의 회사는 Gartner, IDC, Reuters, Ebay 등으로부터 그 지식 공간으로 "유입된(imported)" 지식 에이전트를 가진다. 이같이, 이들 에이전트는 지식을 회사의 시맨틱 네트워크에 자동적으로 부가한다. 사나리오는 또한 Joe가 직관적으로 명명된 스마트 에이전트를 통해 전체 조직의 지식 공간의 "오브젝트 모델" 뷰를 어떻게 얻을 수 있는지를 나타낸다. Joe는 시맨틱 환경을 "기입"하기 위해 그리고 이곳으로부터 이런 방식으로 네비게이트하기 위해 이들 에이전트를 이용할 수 있다. 모든 정보 오브젝트는 실시간으로 전달되며, 액션가능하다(적절하게 표시되는 관련된 동사를 가지며). 이런 식으로, Joe는 오브젝트가 오는 것이 무슨 정보 아일랜드인지 또는 이들을 생성시키는 것이 무슨 어플리케이션인지에 대해 주의할 필요가 없다.

시나리오는 또한 Joe가 새로운 정보만이 아니라 새로운 에이전트도 어떻게 발견할 수 있는지를 나타낸다. 시나리오는 기업체에서 다른 것을 통지하는 것이 무엇을 하는 것인지에 기초하여 Joe에게 추천을 제공하는 액션 - 공동제작의 필터링을 통해 -에서 지식 공동 제작을 나타낸다.

마지막으로, 시나리오는 시간 감도 정보가 이해하는 컨텍스트의 포인트에 사용자의 관심을 어떻게 자동적으로 가져오는지를 예시한다. e-메일 에이전트는 Ebay로부터의 책을 업커밍 산업 이벤트와 자동적으로 연결하며, 이벤트와의 컨텍스트 및 기간 감도 랭킹을 추론 및 할당하고, 이벤트가 시맨틱 브라우저를 통해 정보를 즉시 표시하는 것을 보장하는데 충분한 결정적인 것인지를 결정한다.

b. 피어-투-피어 지식 공유 및 캡쳐

Nancy 하드 작업자는 40,000 고용자를 갖는 포춘 500대 기업에서 일한다. 그녀는 여러 웹 사이트들에 가입하며, 친구들 및 동료로부터 e-메일로 정보를 전송한다. 그녀는 파트너 회사에서의 누군가로부터 문서의 다발을 받고, 조직 내에서 정보를 공유하고자 한다. 그녀는 그녀가 멤버인 모든 분배 리스에 문서를 전송한다. 기업체 정보 에이전트는 또한 이들 리스트의 멤버이다(에이전트는 서버가 인스톨될 때 모든 공개 분배 리스트에 그 자체를 부가한다.). 에이전트가 정보를 수신할 때, 이를 분류하고 이에 시맨틱 네트워크를 부가한다. 추론 엔진은 정보를 픽업한다.

수천의 동료들은 Nancy가 문서를 전송하는 분배 리스트들중 임의의 하나의 멤버가 아니다. 그러나, 이들 모두는 통합자를 사용하며, Email.Public.All 에이전트에 가입한다. 이들이 지식 웹의 다른 관련된 부분을 브라우징할 때, 발룬 팝업은 Email.Public.All 에이전트상에 새롭고 관련된 e-메일이 있음을 표시한다. 동료들은 그때 에이전트를 오픈하며, e-메일 오브젝트는 표시된다. e-메일 아이템상의 메뉴 아이템들중 하나는 "메시지가 전송되는 분배 리스트를 보임"이다. 동료 들은 이를 선택하며, 분배 리스트 정보 오브젝트는 브라우저에 표시된다. 동료들은 분배 리스트쪽으로 마우스를 이동하며, 팝업 메뉴 아이템은 표시된다. 제1 아이템은 "멤버를 보임(Show Member)"이다. 제2 아이템은 "John"이다. 동료들은 분배 리스트에 참가한다.

시나리오의 설명. 이런 시나리오는 정보가 어떻게 공개되고, e-메일을 통해 공유 및 캡쳐되는지를, 그리고 시맨틱 네트워크의 이용에 의해 다른 동료들이 다르지만 관련된 "지식 앵글(angle)"로부터 이런 정보(및 이들의 알지못하는 분배 리스트의 존재에 대해)에 대해 찾는다. 시나리오는 완전히 일체화하며 사용자에게 저장소에 정보를 공개하거나 또는 정보 자체를 분류할 것을 요구하지 않는 방식으로 피어-투-피어 지식 공유를 나타낸다. 본 발명의 임의의 실시예에서는 모든 것이 자동적으로(배경에) 일어나며, 지식은 관련 장소에 넘쳐나게 될 것이다.

본 발명이 바람직한 실시예 및 선택적인 실시예로 상술한 바와 같이 설명되었다 할지라도, 많은 변경은 본 발명의 기술적 사상 및 범위를 벗어남이 없이 이루어질 수 있다. 따라서, 본 발명의 범위는 바람직한 또는 선택적인 실시예의 개시로 인해 제한되지 않는다.

본 발명에서 개시된 내용은 미국 및 국제 저작권법에 의해 보호된다.(ⓒ2002 Nosa Omoigui. All Rights Reserved.) 이 특허 서류에 의해 개시되는 것 중에는 저작권으로 보호받는 것이 포함되어 있다. 저작권자는 특허상표청의 특허 파일이나 기록상에 표시된 그대로 특허 서류나 특허 공개가 팩시밀리에 의하여 복제되는 것에 아무런 이의가 없다. 그러나, 그 외 다른 모든 저작권은 여전히 저작권자가 보 유한다.

본 발명과 관련된 코드 스팩에 대하여 네개의 샘플에 대하여 예를 들면 다음과 같다.

예시 : 코드 스팩

샘플 A - SRML 문서

＜?xml version="1.0" encoding="utf-8" ?＞

＜srml xmlns="http://schemas.nervana.net/srml" xmlns:n="http://schemas.nervana.net/srml" xmlns:rdf="http://rdfland.org" xmlns:dc="http://dcland.org" dummyarg="hello"＞

＜results content="new"＞

＜queryref guid="12345678-1234-1234-1234-123456789ABC" /＞

＜document＞

＜objectref guid="12345678-0000-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞Nsync - A Constraint Based Toolkit for Multimedia＜/dc:title＞

＜dc:creator＞Brian Bailey＜/dc:creator＞

＜dc:creator＞Joseph A. Konstan＜/dc:creator＞

＜dc:description＞

＜n:abstract＞Nsync (pronounced 'in-sync') is adeclarative synchronization toolkit, implemented entirely in Tcl, designed to ease the complexity of designing innovative, interactive multimedia applications.＜/n:abstract＞

＜/dc:description＞

＜dc:date＞2001-07-02＜/dc:date＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞application/pdf＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜dc:identifier＞bailey97nsync.pdf＜/dc:identifier＞

＜/rdf:Description＞

＜size＞84957＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-0001-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞A Comparison of Streams and Time Advance As Paradigms for Multimedia Systems＜/dc:title＞

＜dc:creator＞Roger B. Dannenberg and Dean Rubine＜/dc:creator＞

＜dc:description＞

＜n:abstract＞A common model for multimedia systemsis the stream, an abstraction representing the flow of continuous time-dependent data such as audio samples and video frames.＜/n:abstract＞

＜/dc:description＞

＜dc:date＞2001-07-0218:48＜/dc:date＞

＜dc:identifier＞dannenberg94comparison.pdf＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞application/pdf＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞55421＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-0002-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞Do You Have the Time? Composition and Linking in Time-based Hypermedia＜/dc:title＞

＜dc:creator＞Lynda Hardman, et al.＜/dc:creator＞

＜dc:description＞

＜n:abstract＞In this paper we discuss the concept of presentation time - the timing of the individual parts of a presentation and the temporal relations among them.＜/n:abstract＞

＜/dc:description＞

＜dc:date＞2001-06-2916:57＜/dc:date＞

＜dc:identifier＞hardman99do.pdf＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞application/pdf＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞266873＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-0003-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞Interval-based conceptual models＜/dc:title＞

＜dc:creator＞Little and Ghafoor＜/dc:creator＞

＜dc:date＞2001-07-0218:52＜/dc:date＞

＜dc:identifier＞little93intervalbased.pdf＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞application/pdf＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞364367＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-0004-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞Efficient Generation of Motion Transitions using Spacetime Constraints＜/dc:title＞

＜dc:creator＞Charles Rose＜/dc:creator＞

＜dc:description＞

＜n:abstract＞This paper describes the application of space time constraints to creating transitions between segments of human body motion.＜/n:abstract＞

＜/dc:description＞

＜dc:date＞2001-06-2917:22＜/dc:date＞

＜dc:identifier＞rose96efficient.pdf＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞application/pdf＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞1217898＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-0005-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞MODELING TECHNIQUES FOR HYTIME＜/dc:title＞

＜dc:creator＞Lloyd Rutledge＜/dc:creator＞

＜dc:description＞

＜n:abstract＞Hypermedia/Time-based Structuring Language (HyTime) defines constructs for representing general hypermedia document concepts.＜/n:abstract＞

＜/dc:description＞

＜dc:date＞2001-06-2917:07＜/dc:date＞

＜dc:identifier＞rutledge95modeling.pdf＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞application/pdf＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞129404＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-0006-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞The Compositional Specifcation of Timed Systems＜/dc:title＞

＜dc:creator＞Joseph Sifakis＜/dc:creator＞

＜dc:description＞

＜n:abstract＞In this tutorial, we present an overview of existing executable timed formalisms with a global notion of time, by putting emphasis on problems of compositional description.＜/n:abstract＞

＜/dc:description＞

＜dc:date＞2001-07-0211:37＜/dc:date＞

＜dc:identifier＞the-compositional-specification-of.pdf＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞application/pdf＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞132810＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-0007-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞A Simple, Intuitive Hypermedia Synchronization Model and its Realization in the Browser/Java Environment＜/dc:title＞

＜dc:creator＞Jin Yu＜/dc:creator＞

＜dc:description＞

＜n:abstract＞This paper presents a simple and intuitive hypermedia synchronization model - the Media Relation Graph (MRG)＜/n:abstract＞

＜/dc:description＞

＜dc:date＞2001-07-0211:55＜/dc:date＞

＜dc:identifier＞yu98simple.pdf＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞application/pdf＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞288218＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-0008-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞A Continuous Media Player＜/dc:title＞

＜dc:creator＞Lawrence A. Rowe and Brian C. Smith＜/dc:creator＞

＜dc:description＞

＜n:abstract＞The design and implementation of a continuous media player for Unix workstations is described.＜/n:abstract＞

＜/dc:description＞

＜dc:date＞2001-06-2917:08＜/dc:date＞

＜dc:identifier＞a-continuous-media-player.pdf＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞application/pdf＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞231817＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-0009-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞Multimedia Documents with Elastic Time＜/dc:title＞

＜dc:creator＞Michelle Y. Kim＜/dc:creator＞

＜dc:description＞

＜n:abstract＞We present the elastic time model for multimedia documents. ＜/n:abstract＞

＜/dc:description＞

＜dc:date＞2001-07-0212:07＜/dc:date＞

＜dc:identifier＞p143-kim.pdf＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞application/pdf＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞272532＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-000A-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞Clock Hierarchies: An Abstraction for Grouping and Controlling Media Streams＜/dc:title＞

＜dc:creator＞Kurt Rothermel＜/dc:creator＞

＜dc:description＞

＜n:abstract＞In this paper, we propose a set of powerful abstractions for controlling and synchronizing continuous media streams in distributed environments.＜/n:abstract＞

＜/dc:description＞

＜dc:date＞2001-07-0218:51＜/dc:date＞

＜dc:identifier＞rothermel96clock.pdf＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞application/pdf＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞93052＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-000B-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞Temporal Relations in Multimedia Objects: WWW Presentation from HyTime Specification＜/dc:title＞

＜dc:creator＞Maria da Graca C. Pimentel＜/dc:creator＞

＜dc:description＞

＜n:abstract＞Initially, this paper discusses the use of HyTime for the specification of binary temporal relations. Next, the paper discusses an approach to the automatic transformation of the HyTime synchronization specifications into elements to be presented in the context of the World Wide Web environment.＜/n:abstract＞

＜/dc:description＞

＜dc:date＞2001-06-2916:48＜/dc:date＞

＜dc:identifier＞temporal-relations-in-multimedia.pdf＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞application/pdf＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞102862＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-000C-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞Event and Action Representation and Composition for multimedia application scenario modelling.＜/dc:title＞

＜dc:creator＞M. Vazirgiannis＜/dc:creator＞

＜dc:description＞

＜n:abstract＞In this paper we present a model for the representation of multimedia applications based on the scenario concept.＜/n:abstract＞

＜/dc:description＞

＜dc:date＞2001-07-0211:43＜/dc:date＞

＜dc:identifier＞vazirgiannis96event.pdf＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞application/pdf＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞387575＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-000D-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞Representing Time in Multimedia Systems＜/dc:title＞

＜dc:creator＞Thomas Wahl, Kurt Rothermel＜/dc:creator＞

＜dc:description＞

＜n:abstract＞This paper evaluates and classifies a selection of the most common existing models applying fundamental statements of the time theory and temporal logic.＜/n:abstract＞

＜/dc:description＞

＜dc:date＞2001-06-2916:49＜/dc:date＞

＜dc:identifier＞wahl93representing.pdf＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞application/pdf＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞67658＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-000E-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞Nsync - A Toolkit for Building Interactive Multimedia Presentations＜/dc:title＞

＜dc:creator＞Brian Bailey＜/dc:creator＞

＜dc:description＞

＜n:abstract＞We have developed a multimedia synchronization toolkit, called Nsync (pronounced 'in-sync'), to address the complicated issues inherent in designing flexible, interactive multimedia presentations.＜/n:abstract＞

＜/dc:description＞

＜dc:date＞2001-06-2917:09＜/dc:date＞

＜dc:identifier＞bailey98nsync.pdf＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞application/pdf＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞115592＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-000F-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞Issues in Temporal Representation of Multimedia Documents＜/dc:title＞

＜dc:creator＞Nabil Layaida＜/dc:creator＞

＜dc:description＞

＜n:abstract＞We present in this position paper a set of relevant issues that may help in the design of multimedia document representation. These are based on our experience in designing and implementing an authoring and browsing tool called MADEUS.＜/n:abstract＞

＜/dc:description＞

＜dc:date＞2001-07-0211:54＜/dc:date＞

＜dc:identifier＞issues-in-temporal-representation.pdf＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞application/pdf＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞17348＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-0010-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞Spatio - temporal composition in multimedia applications＜/dc:title＞

＜dc:creator＞Dr. Michael Vazirgiannis＜/dc:creator＞

＜dc:description＞

＜n:abstract＞The motivation for this research work is the lack of a complete declarative way for representative spatio-temporal composition of objects in the current multimedia document standards and authoring tools.＜/n:abstract＞

＜/dc:description＞

＜dc:date＞2001-07-0211:43＜/dc:date＞

＜dc:identifier＞spatio-temporal-composition-in.pdf＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞application/pdf＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞89176＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-0011-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞An Object-Oriented Framework for the Integration of Interactive Animation Techniques＜/dc:title＞

＜dc:creator＞Robert C. Zeleznik, et al.＜/dc:creator＞

＜dc:description＞

＜n:abstract＞We present an interactive modeling and animation system that facilitates the integration of a variety of simulation and animation paradigms.＜/n:abstract＞

＜/dc:description＞

＜dc:date＞2001-06-2916:30＜/dc:date＞

＜dc:identifier＞zeleznik91objectoriented.pdf＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞application/pdf＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞133440＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-0012-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞Dealing with Synchronization and Timing Variability in the Playback of Interactive Session Recordings＜/dc:title＞

＜dc:creator＞Nelson R. Manohar＜/dc:creator＞

＜dc:description＞

＜n:abstract＞In this paper, we describe scheduling and synchronization support for a novel multimedia document, referred to as a session object.＜/n:abstract＞

＜/dc:description＞

＜dc:date＞2001-07-0216:30＜/dc:date＞

＜dc:identifier＞p45-manohar.htm＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞text/html＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞99000＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-0013-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞Multimedia Made Easy Through DirectAnimation＜/dc:title＞

＜dc:description＞

＜n:abstract＞This paper describes Microsoft DirectAnimation, the component of the DirectX API family that provides animation and integrated media support for Web pages, CD-ROM titles, and multimedia applications.＜/n:abstract＞

＜/dc:description＞

＜dc:date＞1998-10-0216:30＜/dc:date＞

＜dc:identifier＞DirectAnimation.doc＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞application/msword＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞152000＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-0014-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞Windows Media Technologies＜/dc:title＞

＜dc:description＞

＜n:abstract＞This paper gives a technical overview of the streaming media components of the Windows Media Technologies: Windows NT Server NetShow Services, NetShow Theater Server and the Microsoft Windows Media Player.＜/n:abstract＞

＜/dc:description＞

＜dc:date＞1998-07-0216:30＜/dc:date＞

＜dc:identifier＞NetShow3.doc＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞application/msword＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞631000＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-0015-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞Integrating Timing into XML Documents＜/dc:title＞

＜dc:creator＞Patrick Schmitz＜/dc:creator＞

＜dc:date＞2000-07-0216:30＜/dc:date＞

＜dc:identifier＞IntegratingTimingWithXML.ppt＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞powerpoint＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞195000＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-0016-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞The SMIL 2.0 Timing and Synchronization model＜/dc:title＞

＜dc:creator＞Patrick Schmitz＜/dc:creator＞

＜dc:description＞

＜n:abstract＞A powerful, flexible model is needed to unify scheduling, interaction, advanced control for animation, and runtime synchronization management. SMIL 2.0 defines a language and semantic model that addresses these needs.＜/n:abstract＞

＜/dc:description＞

＜dc:date＞2001-07-0216:30＜/dc:date＞

＜dc:identifier＞SMILTimingForTheWeb.doc＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞application/msword＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞175000＜/size＞

＜/document＞

＜document＞

＜objectref guid="12345678-0017-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞A Unified Model for Representing Timing in XML Documents＜/dc:title＞

＜dc:creator＞Patrick Schmitz＜/dc:creator＞

＜dc:description＞

＜n:abstract＞We need to provide a common model for timing so that authors are not forced to learn and remember different models for different document types or different authoring scenarios.＜/n:abstract＞

＜/dc:description＞

＜dc:date＞2001-07-0216:30＜/dc:date＞

＜dc:identifier＞TimingIntegrationPositionPaper.htm＜/dc:identifier＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞text/html＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜/rdf:Description＞

＜size＞10000＜/size＞

＜/document＞

＜email＞

＜objectref guid="12345678-0018-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞Some ideas on the Nervana client＜/dc:title＞

＜dc:creator＞Patrick Schmitz＜/dc:creator＞

＜dc:date＞2002-04-0410:30＜/dc:date＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞text＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜dc:identifier＞outlook:fooBarWhoKnows123xyz＜/dc:identifier＞

＜/rdf:Description＞

＜subject＞Some ideas on the Nervana client＜/subject＞

＜from＞Patrick Schmitz [cogit@ludicrum.org]＜/from＞

＜to＞Nosa Omoigui [nosa@nervana.net]＜/to＞

＜to＞Steven Judkins [stevenj007@hotmail.com]＜/to＞

＜cc＞Omoigui, Eghosa D [eghosa.d.omoigui@intel.com]＜/cc＞

＜cc＞Jerome Beard [jbeard@picsmart.net]＜/cc＞

＜size＞434＜/size＞

＜/email＞

＜email＞

＜objectref guid="12345678-0019-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞FW: The Next Web (Business Week)＜/dc:title＞

＜dc:creator＞Nosa Omoigui＜/dc:creator＞

＜dc:description＞

＜n:abstract＞On the other hand, partly because the industry is acutely aware of EDI's problems and limitations, executives are optimistic. "It'll be a chicken-or-egg situation until a killer app comes along--but I'm very confident that that will happen,"says W. Daniel Hillis, a supercomputer pioneer who now heads startup Applied Minds Inc.＜/n:abstract＞

＜/dc:description＞

＜dc:date＞2002-02-2513:44＜/dc:date＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞text＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜dc:identifier＞outlook:fooBarWhoKnows123xyz＜/dc:identifier＞

＜/rdf:Description＞

＜subject＞FW: The Next Web (Business Week)＜/subject＞

＜from＞Nosa Omoigui [nosa@nervana.net]＜/from＞

＜to＞Patrick Schmitz [cogit@ludicrum.org]＜/to＞

＜to＞Steven Judkins [stevenj007@hotmail.com]＜/to＞

＜to＞Omoigui, Eghosa D [eghosa.d.omoigui@intel.com]＜/to＞

＜to＞EghosaO@aol.com＜/to＞

＜to＞ChereceO@aol.com＜/to＞

＜to＞Jerome Beard [jbeard@picsmart.net]＜/to＞

＜cc＞Nosa Omoigui [nosa@nervana.net]＜/cc＞

＜size＞434＜/size＞

＜/email＞

＜email＞

＜objectref guid="12345678-001A-1234-1234-123456789ABC" /＞

＜rdf:Description＞

＜dc:title＞Software's Giants Gird for Upheaval [Fortune]＜/dc:title＞

＜dc:creator＞EghosaO@aol.com＜/dc:creator＞

＜dc:description＞

＜n:abstract＞A vague new thing called web services is stirring up new battles among Microsoft, Oracle, IBM, and all of software's biggest names.＜/n:abstract＞

＜/dc:description＞

＜dc:date＞2002-03-0213:41＜/dc:date＞

＜dc:type＞text＜/dc:type＞

＜dc:format＞text＜/dc:format＞

＜dc:language＞en＜/dc:language＞

＜dc:identifier＞outlook:fooBarWhoKnows123xyz＜/dc:identifier＞

＜/rdf:Description＞

＜subject＞Software's Giants Gird for Upheaval [Fortune]＜/subject＞

＜from＞EghosaO@aol.com＜/from＞

＜to＞Nosa Omoigui [nosa@nervana.net]＜/to＞

＜to＞cogit@ludicrum.org＜/to＞

＜to＞lisah@stanfordalumni.org＜/to＞

＜to＞stevenj007@hotmail.com＜/to＞

＜size units="KB"＞13＜/size＞

＜/email＞

＜/results＞

＜/srml＞

샘플 B - 세만텍 질의 문서

＜?xml version="1.0" encoding="utf-8"?＞

＜sqml＞

＜head title="foo"＞ ＜/head＞

＜filters＞

＜include＞

＜type class="nervana:objecttype"＞

documents

＜/type＞

＜/include＞

＜/filters＞

＜attributes＞＜/attributes＞

＜skins＞

＜documents

color="http://nervana.net/dc.xslt"

design="http://nervana.net/dd.xslt"

animation="http://nervana.net/da.xslt"＞

＜/documents＞

＜email

color="http://nervana.net/ec.xslt"

design="http://nervana.net/ed.xslt"

animation="http://nervana.net/ea.xslt" ＞

＜/email＞

＜/skins＞

＜query＞

＜resource type="nervana:filepath"＞

c:\f2 foo.doc

＜/resource＞

＜resource type="nervana:url"＞

file://c:\f2 bar.doc

＜/resource＞

＜resource type="nervana:url"＞

file://c:?includesubfolders=true

＜/resource＞

＜resource type="nervana:url"＞

http://www.bar.com/doc.htm

＜/resource＞

＜resource type="nervana:url"＞

ftp://gate.com/doc.txt

＜/resource＞

＜resource type="nervana:url"＞

\servers\f2 file.pdf

＜/resource＞

＜resource type="nervana:text" arg="contains=fox"＞

The quick brown fox

＜/resource＞

＜resource type="nervana:cacheentry"＞

ef9c90ea-282d-46d6-b355-ac8a4fc2f3e5

＜link predicate="nervana:relatedto"

type="nervana:url"＞

c:\f2 foo.doc

＜/link＞

＜/resource＞

＜resource type="nervana:url"＞

agent://email.all@ibm.com

＜/resource＞

＜resource type="nervana:url"＞

objects://rad.com/agency.asp

＜link predicate="nervana:containstext"

type="xml:string"＞

80211

＜/link＞

＜/resource＞

＜resource type="nervana:url"＞

objects://rad.com/agency.asp

＜link predicate="nervana:postedon"

type="nervana:datetimeref"＞

today

＜/link＞

＜/resource＞

＜resource type="nervana:url"＞

objects://rad.com/agency.asp

＜link predicate="nervana:postedon"

type="xml:datetime"＞

01-10-2002

＜/link＞

＜link operator="or"

predicate="nervana:postedbefore"

type="xml:datetime"＞

01-11-2002

＜/link＞

＜/resource＞

＜resource type="nervana:url"＞

agent://documents.all@abccorp.com

＜link predicate="nervana:relatedto"

type="nervana:url"＞

objects://98@in.com/m.asp

＜/link＞

＜link operator="and"

predicate="nervana:isofpriority"

type="nervana:priority"＞

criticalpriority

＜/link＞

＜/resource＞

＜/query＞

＜/sqml＞

샘플 C - 세만텍 환경 계층

Information Agent (the root of the Semantic Environment)

My Agents

Frequently Used Agents

Agencies

Agency A1

Documents

Documents.All

Documents.CriticalPriority.All

Email

Email.Technology.Wireless.All

Annotations

Annotations.RecentlyPosted.PastOneDay.All

People

People.Research.All

Events

Events.All

Events.Upcoming.NextOneDay.All

Agency A2

Documents

Documents.Technology.XML.XPath.All

Email

Email.Favorites.All

E-Learning Courses

ELearning.All

Agency A3

News Articles

News.Technology.Semiconductors.All

Agency AN

Recently Used Agents

[Similar hierarchy as above but for recently used Agents]

Recently Created Agents

[Similar hierarchy as above but for recently created Agents]

Favorite Agents

[Similar hierarchy as above but for Agents marked by the user as favorites]

All Agents

[Similar hierarchy as above but for all Agents in the My Agents list]

Deleted Agents

[Similar hierarchy as above but for Agents marked for deletion]

Custom View

[Similar hierarchy as above but for Agents consistent with the custom view]

샘플 D - 헤드라인 컨텍스트 템플레이트로부터 SQML 출력

＜?xml version="1.0" encoding="utf-8"?＞

＜sqml＞

＜head title="foo" type="all information"＞ ＜/head＞

＜filters＞

＜include＞

＜type class="nervana:objecttype"＞

all information

＜/type＞

＜/include＞

＜/filters＞

＜query＞

＜resource type="nervana:Agency"＞

wsAgency://marketing.com/Agency.wsdl

＜link predicate="nervana:postedinthelast"

type="nervana:time:minutesref"＞

30

＜/link＞

＜link predicate="nervana:relevantto"

type="nervana:sqml"＞

[object sqml]

＜/link＞

＜/resource＞

＜resource type="nervana:Agency"＞

wsAgency://research.com/Agency.wsdl

＜link predicate="nervana:postedinthelast"

type="nervana:time:minutesref"＞

30

＜/link＞

＜link predicate="nervana:relevantto"

type="nervana:sqml"＞

[object sqml]

＜/link＞

＜/resource＞

＜resource type="nervana:Agency"＞

wsAgency://sales.com/Agency.wsdl

＜link predicate="nervana:postedinthelast"

type="nervana:time:minutesref"＞

30

＜/link＞

＜link predicate="nervana:relevantto"

type="nervana:sqml"＞

[object sqml]

＜/link＞

＜/resource＞

＜resource type="nervana:Agency"＞

wsAgency://humanresources.com/Agency.wsdl

＜link predicate="nervana:postedinthelast"

type="nervana:time:minutesref"＞

30

＜/link＞

＜link predicate="nervana:relevantto"

type="nervana:sqml"＞

[object sqml]

＜/link＞

＜/resource＞

＜/query＞

＜/sqml＞

[청구의 범위]

[청구항 1]

지식 검색, 관리, 전달 및 프리젠테이션용 시스템에 있어서,

도메인-특정 시맨틱 정보를 부가하고 유지하도록 프래그래밍가능한 제1 서버;

상기 제1 서버와 통신하며, 시맨틱 정보를 분류하며 카테고리화하는데 사용되는 도메인-특정 정보를 호스트하도록 프로그래밍가능한 제2 서버; 및

상기 제1 및 제2 서버들과 통신하기 위하여 사용자 인터페이스를 사용자에게 제공하는 클라이언트를 포함하며,

상기 제1 및 제2 서버의 프로세서들은,

정보 소스들로부터 정보를 보안하는 단계와,

상기 정보 소스들로부터 상기 정보를 시맨틱하게 링킹하는 단계와,

상기 시맨틱하게 링킹된 정보의 시맨틱 속성을 유지하는 단계와,

사용자 질의에 기초하여 요청된 시맨틱 정보를 전달하는 단계와,

커스텀화가능한 사용자 기호에 따라서 시맨틱 정보를 표현하는 단계를 함께 수행하도록 동작하는 것을 특징으로 하는 지식 검색, 관리, 전달 및 프리젠테이션용 시스템.

[청구항 2]

제1항에 있어서, 상기 제1 서버는, 시맨틱 네트워크, 시맨틱 데이터 수집기 (Gatherer), 시맨틱 네트워크 일치 체커, 추론 엔진, 시맨틱 질의 프로세서, 자연어 분석기(Parser), e-메일 지식 에이전트, 또는 지식 도메인 매니저 중 적어도 하나를 제공하는 구조 또는 방법론(methodology)을 더 포함하는 것을 특징으로 하는 시스템.

[청구항 3]

제1항에 있어서,

상기 정보 소스로부터의 정보는 오브젝트들 또는 이벤트들로 이루어지며,

싱기 오브젝트들 또는 이벤트들은 서로 시맨틱하게 관련된 액티브 에이전트들이며, 미리 결정된 테마에 따라 프리젠테이션용 데이터 오브젝트를 리턴하는 질의를 표현하는 것을 특징으로 하는 시스템.

[청구항 4]

제3항에 있어서, 상기 데이터 오브젝트에 따라 상기 미리결정된 테마가 사용자에 의해 커스텀화가능한 것을 특징으로 하는 시스템.

[청구항 5]

제1항에 있어서, 상기 클라이언트는 상기 사용자 질의로부터 나오는 시맨틱 정보를 전달하며 표현하는 것을 특징으로 하는 시스템.

[청구항 6]

시맨틱 정보를 분류하고 카테고리화하는데 사용되는 도메인-특정 정보를 부가, 유지 및 호스트하도록 프로그램밍된 서버 시스템을 이용하여 지식 검색, 관리, 전달 및 프리젠테이션 방법에 있어서,

정보 소스들로부터 정보를 보안하는 단계와,

상기 정보 소스들로부터 정보를 시맨틱하게 링킹하는 단계와,

상기 시맨틱하게 링킹된 정보의 시맨틱 속성을 유지하는 단계와,

사용자 질의에 기초하여 요청된 시맨틱 정보를 전달하는 단계와,

커스텀화가능한 사용자 기호에 따라 시맨틱 정보를 표현하는 단계

를 포함하는 것을 특징으로 하는 지식 검색, 관리, 전달 및 프리젠테이션 방법.

[요약서]

[요약]

본 발명은 지식 검색, 관리, 전달 및 프리젠테이션용 통합 구현 프레임워크 및 결과 매체에 관한 것이다(도 8). 시스템은 도메인-특정 시맨틱 정보를 부가 및 유지를 담당하는 제1 서버와, 컨텍스트 및 시간 감도 시맨틱 정보 검색 서비스를 통신 매체를 통해 프리젠테이션 플랫폼을 동작시키는 클라이언트에 제공하기 위해 함께 동작하는 제1 서버에 의한 사용을 위해 시맨틱 및 다른 지식을 호스트하는 제2 서버를 포함한다. 시스템 내에서, 소정 계층의 모든 오브젝트 또는 이벤트는 미리 결정되고 커스텀화가능한 테마 또는 "스킨"에 따라 프리젠테이션용 데이터 오브젝트를 클라이언트에 되돌리는 각각의 다른 프리젠테이션 질의(기본 액션 코드로 이루어짐)에 시맨틱하게 관련된 액티브 에이전트이다. 이 시스템은 클라이언트를 위해 에이전트를 커스텀화하며 "블랜드"하고, 기본적인 관련된 질의가 최종 정보의 프리젠테이션을 최적화하는 다양한 수단을 제공한다.

[대표도]

도 8

[색인어]

지식 검색, 시맨틱 정보, 사용자 질의, 자연어, 지식 에이전트

[도면

[도 1]

[도 2]

[도 3]

[도 4]

[도 5]

[도 6]

[도 7]

[도 8]

[도 9]

[도 10]

[도 11]

[도 12]

[도 13]

[도 14]

[도 15]

[도 16]

[도 17]

[도 18]

[도 19]

[도 20]

[도 21]

[도 22]

[도 23]

[도 24]

[도 25]

[도 26]

[도 27]

[도 28]

[도 29]

[도 30]

[도 31]

[도 32]

[도 33]

[도 34]

[도 35]

[도 36]

[도 37]

[도 38]

[도 39]

[도 40]

[도 41]

[도 42]

[도 43]

[도 44]

[도 45a]

[도 45b]

[도 46]

[도 47]

[도 48]

[도 49]

[도 50]

[도 51]

[도 52]

[도 53]

[도 54]

[도 55]

[도 56]

[도 57]

[도 58]

[도 59]

[도 60]

[도 61]

[도 62]

[도 63]

[도 64]

[도 65]

[도 66]

[도 67]

[도 68]

[도 69]

[도 70]

[도 71]

[도 72]

[도 73]

[도 74]

[도 75]

[도 76]

[도 77]

[도 78]

[도 79a]

[도 79b]

[도 79c]

[도 79d]

[도 80]

[도 81]

[도 82]

[도 83]

[부록 B]

추가 발명

정보 신경망 시스템을 위한 추가 발명

저자: Nosa Omoigui

1. 스마트 선택 렌즈

개요

스마트 선택 렌즈(Smart Lens)는 정보 신경망 시스템(Information Nervous System) 정보 매체의 스마트 렌즈 특징과 유사하다. 이 경우, 사용자는 객체(object)내의 텍스트를 선택할 수 있고, 이 선택된 텍스트를 (선택변화인 새로운 "이미지(images)"를 동적으로 발생시키는) 객체로 이용하여 렌즈가 적용될 것이다. 이러한 방식으로, 사용자는 전체 객체에 걸쳐 렌즈가 강제 적용되거나 전혀 그렇지 않는 것과는 반대로 객체 메타데이터(object metadata)의 구성 가능한 서브세트(subset)에 걸쳐 렌즈화할 수 있다. 그것은 콘텍스트가 오버로딩된 선택 커서/동사와 유사하다. 예컨대, 사용자는 프레젠터에 있는 한 줄의 텍스트를 선택하여 이 텍스트가 나타나는 객체상에서 "Paste as Lens" 아이콘을 맞출 수 있다. 이때, 상기 프레젠터는 이 텍스트를 다음과 같은 메소드 호출(method call)을 갖는 클라이언트 실행 시간(client runtime) 성분 (예: ActiveX 객체)으로 보낼 것이다:

bstrSRML = GetSRMLForText(bstrText);

이것은 인자 텍스트(argument text)를 보호하고 있는 임시 SRML 버퍼를 반환한다. 이때, 상기 프레젠터는 다음과 같이 메소드를 호출한다:

bstrSQML = GetQueryForSmartLensOnObject(bstrSRMLObject);

이 메소드는 클립보드로부터 SQML을 획득하고, 상기 객체에 대한 인자 SRML을 취하고, SRML에 있는 리소스를 SQML(디폴트 술어 "relevant to"를 가짐)의 링크로서 포 함하고 있는 새로운 SQML을 동적으로 생성한다. 이때, 상기 메소드는 상기 새로운 SQML을 반환한다. 이어서, 상기 프레젠터가 메소드를 호출한다:

ProcessSemanticQuery(bstrSQML);

이것은 발생된 렌즈 SQML을 통과한 다음, 그 결과 및 SRML 결과의 항목 번호를 비동기적으로 선택한다. 이러한 호출시 상세를 위해, 명세서 "정보 신경망 시스템 의미론적 실행시간(Information Nervous System Semantic Runtime OCX)"를 참조할 것. 이어서, 상기 프레젠터는 미리보기 윈도우(preview window) (또는 최근 스킨에 근거한 등가물)을 다음과 같이 디스플레이한다:

[Lens Agent Title]

Found 23 items

[PREVIEW OBJECT 1]

[PREVIEW WINDOW CONTROLS]

여기서, 상기 "Lens Agent Title"는 클립보드상의 agent의 title이다. 미리보기 윈도우 ( 및 미리보기 윈도우 컨트롤)의 상세를 위해서는, 메일 특허 출원서를 참조할 것.

미리보기 윈도우는:

타이머의 시한 경과후(대략 500ms), 사라져야 하고, 마우스 이동시 타이머는 리셋되어야 한다(이렇게 함으로써 사용자가 동일 영역에서 마우스를 움직일 때 윈도우가 번쩍거림을 방지할 것이다)

(결국) 천천히 페이드 아웃시켜야 한다

또한, 본 발명의 양호한 실시예는 다음과 같은 특징을 지녀야 한다:

1. 객체당 하나의 선택 범위이면서 결과 세트당 다중 선택이 최선의 선택(the best option)이다. 이외에, 결과적으로 혼동스런 사용자 경험 및 복잡한 UL이 야기되어 (객체 마다(per object)와는 반대로) 객체마다 선택시 렌즈 아이콘을 보여준다.

2. (SQML이 에이전트 렌즈와 일관되게 동적으로 발생됨에도 불구하고 정규 SQML 질의인) 뛰어난 렌즈 질의 요구(lens query requests)는 상기 프레젠터가 이 렌즈 질의요구를 더 이상 필요로 하지 않을 경우(예컨대, 만약, 프레젠터가 새로운 페이지로 네비게이팅하거나, 우리가 객체에 대한 새로운 렌즈 정보를 요구하는 경우)에는 취소되어야 한다. 어떤 경우에, 이것은 렌즈 질의가 한번에 몇몇 객체만을 요구할 가능성이 있기 때문에 성능( 및 대역폭) 관점에서 볼때 중요하지 않다. 비록, 이들 질의가 최소되지 않더라도, 프레젠터가 그 결과를 무시할 수 있다. 어떤 경우, 프레젠터는 조금씩 누설되는 진부한 결과를 취급해야 한다-프렌젠터는 (렌즈 질의가 취소되든 안 되든간에) 어쨌든 이러한 일을 해야 할 것이다. 프레젠터가 취소요구를 발생시키는 시점과 취소가 실제로 이루지는 시점사이에는 윈도우가 존재할 것이다. 일부 결과는 이 기간 동안에 누출될 수 있고 조금씩 누설될 필요가 있다. 이것은 비동기적인 취소 구현의 전형이다-소프트웨어 컴포넌트는 항상 불량하거나 진부한 결과를 무시할 준비를 갖출 필요가 있다.

3. 프레젠터는 (최근 렌즈 요구상태를 나타내는) 두개의 아이콘과 툴-팁(tool-tips)를 가져야 한다:

사용자가 마우스 커서를 객체위에 머물게 하거나(호버링) 객체위를 클릭할 때, 프 레젠터는 "렌즈정보 요청(Requesting Lens Info)"으로 툴 팁을 위에 올려놓을 수 있다. 그 정보가 돌아오면, 커서 호버링(hovering)을 통해 "Found 23 Objects" 팁이 보여지고 클릭킹(clicking)동작을 통해 결과가 보여질 것이다. 이때, 이러한 틈새형 툴 팁(interstitial tool tip)은 그 결과가 도달할 때 정지하는 경우 미리보기 윈도우로 전환될 수 있다

또한, 스마트 렌즈와 같은 스마트 선택 렌즈은 텍스트형 메타데이터이외의 객체에 적용될 수 있다. 예컨대, 상기 스마트 선택 렌즈는 이미지, 비디오, 오디오 스트림,또는 다른 메타데이터에 적용가능하다. 이 경우, 프레젠터는 데이터 타입 및 "선택 영역(selection region)"과 일관된 적절한 SRML을 반환할 것이다. 이 영역은 이미지, 또는 비디오 영역, 오디오 스트림의 시간 길이 등이 될 것이다. 스마트 렌즈 기능성의 나머지는 전술한 바와 같이 (렌즈아래의 데이터 유형에 대한 스키마에 기초한) SRML에 기초하여 적절한 SQML이 발생되면서 적용될 것이다.

2. 스마트 선택 렌즈

개요

또한, 정보 신경망 시스템은 "사람(person)" 객체(사람, 사용자, 고객, 등)에 대한 드래그(drag)와 드롭(drop) 또는 복사하기(copy) 및 붙이기(paste)를 지원한다. 이 경우, 두 가지 시나리오가 있다:

1. 사람이 오는 장소로부터 정보 커뮤니티(또는 에이젼시)를 나타내는 스마트 요구(smart request)위에 사람 객체를 붙인다. 이 경우, 서버의 의미론적 질의 프로세 서(semantic query processor)는 단순히 사람을 인자(argument)로 사용하여 클라이언트로부터의 SQML를 해결한다. 예컨대, 만약 사용자가 사람 "Joe"를 스마트 요구의 상단인 "로이터 신문의 헤드라인 기사(Headlines on Rueters)"위에 붙이거나 (드래깅하고 드래핑)하면, 클라이언트는 부가 인자(additional argument)를 사용하여 새로운 스마트 요구를 생성할 것이다. 이 로이터 정보 신경망 시스템 웹 서비스(Reuter Information Nervous System Web Service)는 "Joe"에 의해 발행되거나 주석이 달린 모든 헤드라인 기사를 반환함으로써 이러한 요구를 해결해 줄 것이다. 이 경우에, 서버는 근본적으로 (~에 의해 발행되거나 주석이 달린) 시나리오에 대해 이치가 맞는 적절한 디폴트 술어를 적용할 것이다.

2. 사람이 오지 않은 장소로부터 사람 객체를 정보 커뮤니티(또는 에이젼시)를 나타내는 스마트 요구위에 사람 객체를 붙인다. 이 경우, 사람 객체는 (SMS상의) 목적지 정보 커뮤니티의 의미 네트워크(semantic network)안에 없기 때문에, 서버의 의미적 질의 처리기(semantic query processor)는 사람 인자를 이해하지 못할 것이다. 이와 같이, 서버는 사람이 전문가(양호한 실시예에서)이거나 또는 뉴스메이커인 카테고리를 이용하여 사람 인자를 해결해야 한다. 예컨대, 전술한 예를 보면, 만약 사용자가 사람 "Joe"를 스마트 요구의 상단인 "로이터 신문의 헤드라인 기사"위에 붙이거나 (드래깅하고 드래핑)하고, Joe가 로이터 정보 커뮤니티(Reuters Information Community)의 사람이 아니라면, 로이터 웹 서비스(양호한 실시예에서)는 "Joe의 전문지식과 관련한" 헤드라인 기사를 반환해야 한다. 이렇게 되기 위해서는 클라이언트가 SQML을 목적지 웹 서비스에 전송하기 전에 두 가지 통과 방법을 취해야 한다. 첫 번째로, 사람이 속한 정보 커뮤니티에 사람의 전문지식을 나타내는 표현 데이터를 요구해야 한다. 상기 웹 서비스는 이러한 요구를 다음과 같은 동작을 통해 해결한다:

a. 의미론적 도메인 정보(semantic domain information) (예: 로이터)를 위해 사람 객체가 붙여지거나 드롭핑되는 정보 커뮤니티에 대해 질의한다-이것은 계층분류(taxonomy) 및 온톨로지(ontology)를 나타낸다.

b. 의미론적 도메인 정보를 위해 사람 객체가 온 출처인 정보 커뮤니티에 대해 질의한다.

c. 만약, 의미론적 도메인이 동일하거나, 적어도 하나의 공통 의미 도메인(common semantic domain)이 존재하면, 클라이언트는 사람의 전문지식 카테고리를 위해 사람이 온 출처인 정보 커뮤니티에 대해 질의한다. 이때, 클라이언트는 인자(arguments)인 이들 카테고리를 이용하여 SQML를 구축하고 이 구축된 SQML를 사림이 붙여지고 드롭핑된 정보 커뮤니티로 통과시킨다.

d. 만약, 의미 도메인들이 동일하지 않거나, 적어도 하나의 공통 의미 도메인이 존재하면, 클라이언트는 사람이 전문가로 분류된 카테고리에 속하는 여러 객체를 위해 사람이 온 출처인 정보 커뮤니티에 대해 질의한다. 양호한 실시예에서는, 그러한 구현을 통해, 전문지식 카테고리를 정확히 표현하는 충분히 많은 갯수의 객체(이 개수는 실험근거하여 선택되어야 한다.)를 선택해야 한다. 이 경우 객체를 선택하는 이유는 목적지 웹 서비스가 사림이 온 출처인 정보 커뮤니티의 카테고리를 이해하지 못하고 이들 객체를 그자신의 카테고리에 맵핑할 수 없기 때문이다. 이 와는 달리, (인터넷상의 중앙 집중형 웹 서비스를 통해) 서로 다른 정보 커뮤니티사이의 카테고리들을 맵핑하는 카테고리 맵퍼(mapper)이 이용될 수 있다. 이 경우, 목적지 정보 커뮤니티는, 비록 이들 카테고리를 이해하지 못하더라도 항상 카테고리를 SQML의 일부로서 통과할 것이다- 이때, 정보 커뮤니티는 카테고리 맵퍼 웹 서비스를 이용하여 이들 카테고리를 내부 카테고리로 맵핑할 것이다. 카테고리 맵퍼 웹 서비스는 카테고리를 해결할 수 있는 메소드는 물론, 카테고리 맵핑을 퍼블리시(publishing) 할 수 있는 메소드를 가질 것이다.

3. 스마트 요구의 저장 및 공유

개요

정보 신경망 시스템 시맨틱 브라우저(정보 에리전트 또는 라이브러리언)의 사용자들은 또한 스마트 요구를 디스크에 저장할 수 있고 이들 요구를 첨부파일로 메일전송하거나, 이들 요구를 인스턴트 메신저 (역시 첨부파일로 전송) 또는 다른 수단을 통해 공유할 수 있을 것이다. 또한, 클라이언트는 메소드를 노출하여 스마트 요구 문서를 이메일 또는 인스턴트 메신저에 첨부파일로서 공유할 것이다.

공유가능한 스마트 요구 문서는 (이진 포맷으로된 시큐어 스트림을 통해) SQML을 보호하고 있는 바이너리 문서이다. 이 스마트 요구 문서는 명세서의 지적 소유권을 보호하는 의미적 질의에 대한 안전한 연속적인 표현을 제공한다. 이러한 지적 소유권의 보호는 상기 의미적 질의(SQML)의 XML 버전을 강력하게 암호화하거나 강력한 일 방향 해시을 통해 달성될 수 있다. 공유가능하 sans서는 상기 요구를 나 타내는 확장자(.REQ)를 갖는다. 클라이언트 운영 시스템상의 확장자 핸들러는 상기 확장자를 표현하기 위해 설치된다. 상기 확장자를 갖는 문서가 열리면, 확장자 핸들러는 상기 문서를 열게 된다. 이 확장자 핸들러는 SQML을 시큐어 스트림에서 추출하여 상기 문서를 연 다음, SQML을 갖는 의미적 이름공간(semantic namespace)에서 스마트 요구를 생성한다. 이때, 이 확장자 핸들러는 의미적 이름공간에 있는 스마트 요구를 열게 된다.

의미적 이름공간의 스마트 요구가 저장되거나, 사용자가 이 스마트 요구를 이메일 첨부파일로 전송하고 싶은 경우, 클라이언트는 스마트 요구를 이진 .REQ 포맷으로 나타내는 SQML을 직렬화(serialization)하고, 이것을 요구된 디렉토리 경로에서 저장하거나, 첨부파일인 .REQ 문서를 갖는 이메일 클라리언트를 연다.

이하의 도 1은 스마트 요구로 SQML 버퍼를 보호하고 있는 바이너리 문서를 도시함은 물론, 확장자 핸들러가 어떻게 문서를 여는지에 대해 예시하고 있다. (SRML을 통해) 결과를 공유하기 위해 유사한 모델이 이용될 수 있다. 이 경우, 바이너리 문서는 전술한 경우에서와 같이 SQML보다는 SRML을 보호한다.

도 1: 공유가능한 스마트 요구 시스템 상호작용

이하의 도 2는 윈도우 쉘 (window shell)내의 등록 연관부분을 갖는 (우측 끝부분에 있는 "내 연구 보고서(라이브)에 관한 로이터 신문상의 헤드라인 기사" 및 "(2003년 1월 21일 오전 8시 17분) 로이터 신문상의 헤드라인 기사"라는 제목의) 두 개의 .REQ 문서를 예시하고 있다. 첫 번째 요구 문서는" 라이브"이고, 두 번째 요구 문서는 특정 시간에서의 스냅 샷(snapshot)이다(이들 요구문서는 둘 다 시간 민감성 요구임). 상기 운영 시스템은 시맨틱 브라우저 애플리케이션(Nervana 라이브러리언)을 상기 문서와 연관시켰음을 유념해야 한다. 문서가 열리면, 의미적 질의는 상기 애플리케이션에서 열리게 된다.

도 2: 저장된 두개의 의미적 요구 문서(하나는 라이브이고 다른 하나는 스냅샷)를 보여주는 스크린샷.

엔티티를 저장하고 공유하기- 엔티티를 나타내기 위해 .ENT 확장자를 갖는 것을 제외하고 위와 같이 동일한 프로세스가 적용된다. 엔티티 문서가 호출되면, Nervana 라이브러리언은 브라우저에에서 엔티티 SQML을 연다.

확장자 특성 쉬트-이것은 의미적 환경에서 (문서의 종류에 따라) 임시 스마트 요구 또는 엔티티를 생성하거나 스마트 요구 또는 엔티티를 위한 특성 쉬트를 표시 할 것이다.

확장자 툴 팁-이것은 사용자가 라이브러리언 문서(요구, .REQ 또는 엔티티, .ENT)위에 마우스 커서를 호버링할 때 도움이 되는 툴 팁을 디스플레이할 것이다.

4. 스마트 스냅샷의 저장 및 공유

개요

정보 신경망 시스템 역시 발명자가 호출하는 것, "스마트 스냅샷(Smart Snapshot)"의 공유를 지원한다. 스마트 스냅샷은 제 시간에 고정된 사머트 요구이다. 이것을 통해 사용자가 스마트 요구를 "라이브"상태에 있도록 하고 싶은 것이 아니고 공유하고 싶다느 시나리오가 가능해 질 것이다. 예컨대, 디폴트에 의해 만약 사용자가 스마트 요구 "이 문서와 관련한 로이터 통신의 긴급 뉴스"를 동료와 함께 공유한다면, 이 동료는 ("현재 시각"에 기초한) 스마트 요구의 라이브 결과를 보게 될 것이다. 그러나, 만약 사용자가 "이 문서와 관련한 로이터 통신의 [현재] 긴급뉴스"를 공유하길 원하면, 스마트 스냅샷이 이용될 것이다.

스마트 스냅샷은 SQML 문서의 "속성(attributes)" 섹션이 SQML 문서를 스냅샷(플래그 QUERYATTRIBUTES_SNAPSHOT)으로 표현되는 속성을 포함하는 것을 제외하고 스마트 요구와 동일하다(이것은 또한 SQML 질의 문서에 의해 표현됨). SQML 문서의 생성 날짜/시간은 SQML에 저장된다(이전에는 SQML 스키마가 그 문서 생성 날짜/시간을 위한 필드를 포함하다). 사용자 자신이 스마트 요구를 공유하고 싶다는 것을 지시할 때, 사용자 인터페이스(시맨틱 브라우저, 정보 에이젼시, 또는 라이브러리 언)는 사용자 자신이 스마트 요구(라이브) 또는 스마트 스냅샷을 공유하고 싶어하는지의 여부를 프롬프팅한다. 만약, 사용자가 스마트 요구를 지시하면, 바이너리 문서는 편집된 SQML(스냅샷 속성을 포함함)로 전집화되고 전술한 바와 같이 프로세스의 나머지가 수반된다.

바이너리 문서의 수신인이 이 문서를 (이메일, 인스턴트 메신저등을 통해) 수신하여 그것을 열면, 확장자 핸들러는 상기 문서를 열고, 전술한 바와 같이) 스마트 요구로서 의미적 이름공간속에 엔트리를 추가한다. 수신인이 상기 스마트 요구를 열면, 클라이언트의 의미적 질의 처리기는 (전술한 바와 같이) 처리된 SQML을 서버의 XML 웹 서비스에 전송할 것이다. 이때, 상기 서버의 의미적 질의 처리기는 상기 SQML을 처리하고 SQMLO 생성 날짜/시간에 관한 의미적 질의를 호출하여 스냅샷 속성을 부여한다. 이와 같이, 결과는 원래 날짜/시간과 관련되어 발신자의 의도가 부여될 것이다.

5. 가상 정보 커뮤니티

가상 정보 커뮤니티(Virtual Information Communities)(에이젼시)는 정보 커뮤니티의 퍼블리셔가 서버 그룹을 퍼블리시하여 이들 서버 그룹이 하나의 서버인 것처럼 보이도록 하는 정보 신경만 시스템의 특징을 의미한다. 예컨대, 로이터는 산업별 로이터 정보 커뮤니티(약학, 오일 및 가스, 제조, 금융 서비스, 등등)를 가질 수 있으나, 하나의 로이터" 정보 커뮤니티의 노출을 선택할 수도 있다. 이를 위해, 로이터는 (차라리 XML 웹 서비스의 WSDL에 대한 URL보다는) 가상 정보 커뮤니티를 위한 SQML을 퍼블리시 하고 공표할 것이다. SQML은 실제 정보 커뮤니티의 WSDL의 블렌더(또는 콜렉션)를 포함할 것이다. 이때, 시맨틱 브라우저는 SQML을 선택하고 정보 커뮤니티를 위한 아이콘을 디스플레이할 것이다(마치 그것이 단일 서버인 것처럼). 정보 커뮤니티에 대한 작용이 SQML의 각 서버에 전달될 것이다. 만약, 사용자가 그러한 작용에 접근하지 못하면 그에 따라 웹 서비스 호출은 실패할 것이고, 그러한 작용이 이루어질 것이다(사용자가 정보 커뮤니티를 포함하고 있는 블렌더를 수동으로 생성하는 경우와 차이가 없음).

6. 시간 민감성 의미적 질의의 구현

시간에 민감한 의미적 질의는 해당 정보 커뮤니티(에이젼시)에서의 지식의 발생속도를 설명하기 위해 지능형(인텔리전트) 방식으로 구현되어야 한다. 예컨대, 초당 10개의 문서를 수신하는 서버상의 "긴급 뉴스"는 한달에 10개의 문서를 수신하는 서버상의 "긴급 뉴스"와는 같지 않다. 이와 같이, 서버측 의미적 질의 처리기는 정보가 서버에 누적되는 속도에 따라 그 시간 민감성 의미적 질의 핸들링을 조절해야 한다. 이를 구현하기 위해, 예컨대, 다음과 같이 일반 경험적 법칙이 사용될 수 있다:

가장 최근의 N개의 객체(여기서, N은 분당 새로운 객체의 수에 따라 조절됨)

캡(cap)이 객체의 수에 기초하며, 최근 N 분에 수신된 모든 객체(즉, 분(캡, 최근 N 분에 수신된 모든 객체).

또한, N은 질의가 헤드라인인지 아니면 긴급 뉴스인지의 여부에 따라 조절될 수 있다 양호한 실시예에서, 뉴스메이커 질의는 헤드라인과 동일한 시간 민감성 파라미터로 구현되어야 한다.

7. 음성 합성 스킨(Text-to-Speech Skins)

개요

음성 합성(Text-to-Speech)은 모든 객체 레벨 및 요구 레벨에서 구현된다. 모든 객체 레벨에서는, 객체 스킨이 객체의 SRML을 가져오기 위해 스크립트를 실행하고 이 SRML을 해석한 다음, (SRML 필드에 있는) 텍스트의 선택 피스를 음성 합성 엔진으로 통과시킨다(예: 음성 출력을 발생시키는 마이크로소프트 윈도우 음성 SDK).

이하의 도 3은 음성 합성 객체 스킨을 통해 발생되는 이메일 메시지를 예시하고 있다. 도 3에 도시된 파이프라인이 실행되면 다음과 같은 음성 출력이 발생된다:

1. 이메일 메시지 읽기

2. 적절한 지연

3. 노사 오모이구이로부터 수신된 메시지

4. 적절한 지연

5. 존 스미스에게 전송된 메시지

6. 적절한 지연

7. 누군가에게 복사된 메시지

8. 적절한 지연

9. 메시지 개요는 "웹 서비스는 분배 컴퓨팅을 위해 사용되는 소프트웨어 구축 블록이다" 이다.

10. 적절한 지연

11. 메시지 제목은 웹 서비스이다.

12. 적절한 지연

13. [선택적] 메시지 본문은 "웹 서비스는 분배 컴퓨팅을 위해 사용되는 소프트웨어 구축 블록이다" 이다.

이 예는 다음과 같이 음성 스킨 템플레이트를 취한다:

1. 이메일 메시지 읽기

2. 적절한 지연

3. ＜message author name＞으로부터의 메시지

4. 적절한 지연

5. ＜message to: recipient name＞에 전송된 메시지

6. 적절한 지연

7. ＜message cc: recipient name＞에 복사된 메시지

8. 적절한 지연

9. 메시지 제목은 ＜message subject text＞이다

10. 적절한 지연

11. 메시지 개요 :＜message body summary＞이다

12. 적절한 지연

13. [선택적] 메시지 본문은: ＜message body＞이다.

또한, 다른 템플레이트는 쉽게 이해할 수 있고 발생중인 객체 유형의 의미론(semantics)을 전달하는 음성을 발생시키는데 사용될 수 있다. 위에서 도시된 예(이메일의 경우)와 같이, 상기 구현에서는 객체 유형의 의미론을 캡쳐링하기 위해 모든 정보 객체 유형에 대한 적절한 음성 합성 템플레이트(text-to-speech templates)를 사용해야 한다.

요구 레벨에서, 시맨틱 브라우저의 프리젠테이션 엔진(프리젠터)은 (사용자 선택 커서 위치에 기초하여) 발생중인 모든 현재 객체에 대한 SRML을 가져오고 각각의 객체에 대한 음성 합성 객체 스킨을 호출하는 스킨을 로딩한다. 이 과정에서는 근본적으로 차례로 발생중인 각각의 XML 객체에 대해 음성 합성 동작이 반복된다.

도 3: 음성 합성 개체 스킨을 예시한 블록도.

이하의 도 4는 요구 스킨을 통해 시맨틱 브라우저에서 표현되는 여러 개의 이메일 객체를 예시하고 있다.

도 4: 음성 합성 요구 스킨을 예시한 블록도.

8. 언어 번역 스킨

언어 번역 스킨은 언어축상에서 변환이 이루어진다는 것을 제외하고 DAM성 합성 스킨과 유사하게 구현된다. XSLT 스킨(스마트 스타일)은 소프트웨어 엔진으로 하여금 언어 번역을 실시간으로 자동 수행하도록 한 다음, 언어의 영역을 설명하기 위해 유니코드(문자당 16 비트)로 인코딩되는 XML을 발생시킨다. 이때, 최종 프리젠테이션 출력을 발생시키는 XSLT 변환으로 인해, 변역된 XML의 컨텐츠가 주어진 적절한 문자 집합을 사용하여 출력이 발생된다.

9. 사용자 경험의 제 1 클래스 객체인 카테고리

언어 이것은 정보 커뮤니티상의 카테고리가 최종 사용자에게 노출되는 특징을 의미한다. 최종 사용자는 카테고리에 대한 질의를 정보 형태, 예컨대 "웹 서비스"로서 발생시킬 수 있을 것이다. 이때, 메타데이터는 어떤 제 1 클래스 정보 객체 유형의 경우에서와 같이, 시맨틱 브라우저에서 디스플레이될 것이다. 또한, 카테고리 객체를 피봇으로 사용하여 시각화(visualizations), 동적 링크, 콘텍스트 팔레트(context palettes), 등을 입수할 수 있다. 이러한 특징은, 파라미터인 카테고리를 갖는 스마트 요구(스마트 에이전트)로 시작하는 것과 반대로, 사용자가 카테고리로 시작한 다음, 그것을 동적 네비게이션용의 피봇으로 사용하고 싶어하는 경우에 유용하다.

10. 분류된 주석

분류된 주석은 제1 클래스 객체인 카테고리로부터 발생된다. 사용자는 카테고리에 대해 직접 주석을 달수 있음으로 인해, 카테고리에 맵핑되는 이메일 리스트를 시뮬레이팅한다. 그러나, 많은 카테고리(예컨대, 약학분야)가 존재하는 경우, 이것은 권장되지는 않는데 그 이유는, 정보가 많은 카테고리에 속할 수 있고 사용자가 어떤 카테고리의 주석을 달 것인지에 관해 생각하지 않았어야 하기 때문이다-사용자는 주석이 자동으로 분류되거나 카테고리보다 더욱 콘텍스트적인 문서 또는 이메일 메시지 같은 객체의 주석다는 정보 커뮤니티(에이젼시)에 그 주석을 직접 퍼블리시해야 하기 때문이다.

11. 추가 콘텍스트 템플레이트

1. 전문가-이것은 최초 특허 출원서에서는 특수 에이전트로 표시되었으나, 콘텍스트 템플레이트 섹션으로부터 잘못 남겨졌다. 전문가는 콘텍스트 템플레이트(context template)이고, 그 이름이 함축하는 것은 하나 이상의 주제(subject matter) 또는 콘텍스트(PREDICATETYPEID_EXPERTON predicate에 의해 표시됨)에 대한 전문지식을 갖고 있는 사람들을 나타낸다.

2. My Items의 주석-이것은 주석의 변형이면서도 호출 사용자에 의해 퍼블리싱된 항목으로 필터링되는 콘텍스트 템플레이트이다. 이것은 사용자로 하여금 사용자 자신이 게시하거나 주석을 달아놓은 항목에 대해 구체적으로 피드백하여 모니터하도록 할 것이다.

12. 사용자 상태 불러오기 및 내보내기

1. 시맨틱 브라우저는 사용자 상태(user state)의 불러오기 및 내보내기(importation and exportation)를 지원할 것이다. 사용자는 그 자신의 개인상태를 문서에 저장하고 이것을 또 다른 머신에 전송하거나 그 역으로 수행할 것이다. 이러한 상태는 다음과 같은 것들에 대한 정보 (및 메타데이터)를 포함할 것이다:

디폴트 사용자 상태(예: 컴퓨터 정교함 레벨, 관심 있는 디폴트 영역, 디폴트 잡 롤(defaut job role), 디폴트 스마트 스타일,등)

프로파일

(프로파일 당) 엔티티

(프로파일 당) 스마트 요구

(프로파일 당) 로컬 요구

(프로파일 당) 가입된 정보 커뮤니티

시맨틱 브라우저는 사용자로 하여금 불러오기 하거나 내보내기 할 사용자 상태 유형을 선택하도록 해줄 UI(마법사와 유사함)를 보여줄 것이다. 상기 UI는 또한, 사용자에게 아이덴티티/로그온 정보을 포함할 것인지를 물어볼 것이다. 상기 UI가 호출되면, 시맨틱 브라우저는 모든 사용자 상태 유형의 메타데이터에 해당하는 필드를 갖는 XML 문서속에 사용자 상태를 직렬화할 것이다. 상기 XML 문서를 불러오면, 시맨틱 브라우저는 XML 문서 노드를 네비게이팅하고 사용자 상태 유형을 상기 XML 문서의 노드에 해당하는 클라이언트 환경에서 추가하거나 세팅할 것이다.

13. 로컬 스마트 요구

로컬 스마트 요구는 사용자로 하여금 정보 커뮤니티(에이젼시)의 카테고리를 이용하여 로컬 정보를 브라우징 하도록 해줄 것이다. 분류된 로컬 요구의 경우, 시맨틱 클라이언트는 로컬 하드 드라이브, 이메일 저장소 등을 크롤링(crawling)하고, (개요를 포함하는) 메타데이터를 추출하고, 의미적 메타데이터 저장장치(SMS)의 로컬 버전에 메타데이터를 저장한다. 클라이언트는 (그 XML 웹 서비스를 통해) XML 메타데이터(객체당)를 분류를 위한 정보 커뮤니티로 전송한다. 이때, 정보 커뮤니티는 카테고리 할당 메타데이터로 반응한다. 이때, 클라이언트는 (로컬 SMS를 통 해) 로컬 시맨틱 네트워크를 갱신하고, 서버가 그랬던 것처럼 의미적 질의에 응답한다. 근본적으로, 이것은 로컬 서버를 갖는 것과 동등하다.

14. 통합 네비게이션

통합 네비게이션은 사용자로 하여금 (우측에 있는 주 결과에 있는) 프리젠터 내부에서 동적으로 네비게이팅하도록 하며, 네비게이션이 좌측에 있는 쉘 확장 네비게이션과 통합하도록 한다. 근본적으로, 이것은 두개의 스택을 통합한다. 양호한 실시예에서, 이것은 이벤트 시그널링을 통해 달성된다. 프리젠테이션이 새로운 요구에 대해 동적으로 네비게이팅하고자 할때, 이 프리젠테이션은 최신 브라우저 뷰를 확인하는 GUID로부터 일부 상태를 셋오프한다. 상기 GUID는 "네비게이션 이벤트(Navigation Event)", "다음번 이름공간 객체(Next Namespace Object) ID", 및 "다음번 경로(Next Path)"라고 불리는 필드를 갖는 레지스트리의 키에 맵핑한다. 상기 "네비게이션 이벤트" 필드는 로딩될 때 최신 브라우저 뷰에의해 생성된 이벤트 핸들를 나타내는 DWORD 값을 유지한다. 프리젠터가 새로운 요구에 대해 네비게이팅을 원할 때, 이 프리젠터는 의미적 환경(semantic environment)에서 상기 요구를 생성하고 상기 요구의 반송된 ID를 캐싱(cashing)한다. 이때, 프리젠터는 (요구의 정보/콘텍스트에 따라) 상기 요구의 적절한 이름공간을 동적으로 획득하고, 이것 역시 캐싱한다. 이때, 프리젠터는 두개의 필드(이들 두개의 값을 갖는 "다음번 이름공간 객체 ID", 및 "다음번 경로")를 세팅한다. 이어서, 프리젠터는 "네비게이션 이벤트"을 세팅한다 (윈도우에서는 이것이 "SetEvent"라고 명명된 Win32API 를 호출하여 행해진다).

네비게이션 이벤트를 캐치하기위해, 브라우저 뷰는 처음 시작할 때 워커 스레드(worker thread)를 개시한다. 이 스레드는 네비게이션 이벤트에 대해 대기한다 (그리고, 브라우저 뷰가 종료될 때 시그널링된 셧다운 이벤트에 대해서 동시에 대기한다-윈도우에서는, 이것이 "WaitForMultipleObjects"라 명명된 Win32API를 통해 행해진다). 만약 네비게이션 이벤트가 시그널링되면, "Wait"API가 반송되는데, 이것은 네비게이션 이벤트가 시그널링되었다는 것을 의미한다. 이때, 상기 워커 스레드는 네비게이션 상태(객체 id 및 경로)를 검색하기위해 레지스트리를 참조한다. 그런 다음, 워커 스레드는 쉘 브라우저를 호출하여 상기 객체 id 및 경로를 네비게이팅한다(윈도우에서는, 이것이 "PIDL"를 검색한 다음, IShellView를 구현하는 쉘 뷰 인스턴스에 대해 IShellBrowser::BrowseTo를 호출하여 행해진다.

15. 방문 결과에 대한 힌트

Nervana 시맨틱 브라우저(semantic browser)는 사용자로 하여금 생각의 속도(the speed of thought)로 지식 공간을 동적으로 네비게이팅하도록 해준다. 사용자는 콘텍스트, 정보 또는 시간축을 따라 네비게이팅할 수 있다. 그러나, 사용자는 네비게이팅함에 따라 중복 정보(redundant information)를 제공받을 수도 있다. 예컨대, 사용자는 로컬 문서에서부터 "긴급 뉴스"까지 네비게이팅한 다음, "긴급 뉴스" 결과 객체들 중 하나에서부터 "헤드라인 기사"까지 네비게이팅할 수 있다. 그러나, 의미론적으로, 헤드라인 기사들 중 일부는 긴급 뉴스가 중복될 수도 있다(특 히, 충분한 시간이 경과되지 않는 경우). 이것은 웹 브라우징과 서로다른 "각도"에서 동일한 페이지를 반복해서 적중시키는 것과 동등하다.

Nervana 시맨틱 브라우저는 최근에 제공된 결과의 로컬 캐시를 구비함으로써 이것을 핸들링한다. 이때, 프리젠터는 서로 다른 칼라 또는 일부 다른 UI 메카니즘으로 중복 결과를 보여줌으로써 이 중복 결과를 사용자에게 지시할 것이다. 로컬 캐시는 노후를 겪는다(전형적인 "브라우징 경험"을 한지 여러 시간 또는 측정된 시간이후가 바람직함). 구 엔트리는 깨끗이 처리되고 캐시는 궁극적으로 충분한 시간이 경과된 후 리셋팅된다.

시맨틱 브라우저는 또한, 복제 결과(duplicate results)를 프리젠터에서 발생시키기 전에-예컨대, 동일한 메타데이터를 갖는 객체가 서로 다른 정보 커뮤니티상에 나타나는 경우에 복제결과를 제거함으로써 이 복제결과를 핸들링할 것이다. 시맨틱 브라유저는 메타데이터 비교과정을 수행하여 이를 검출할 것이다. 문서, 이메일등과 같은 비구조화 데이터의 경우, 시맨틱 브라우저는 개요(summaries)를 비교할 것이다-(특히, 길이가 매우 긴 문서의 경우, 비록 이것이 절대적으로 보장되는 것은 아니지만) 만약 이 개요들이 동일하면 문서들은 매우 동일하다.

16. 지식연합(Knowledge Federation)

지식 연합은 지식 커뮤니티의 한계내에서 외부 지식이 연합되도록 해주는 기술이다.

예컨대, 많은 회사들은 로이터사(Reuters)와 같이 외부 컨텐츠 제공자에 의존하여 정보를 제공받는다. 그러나, 정보 신경망 시스템에서는, 주석, 개인 출판 등과 관련하여 보안 및 사생활 논란이 야기한다. 많은 기업체 고객들은 민감한 주석이 외부 컨텐츠 제공자에 의해 호스팅되고 관리되는 원격 서버상에 저장되는 것을 원치 않을 것이다.

이를 해결하기 위해, 외부 컨텐츠 제공자는 회사에 의해 호스팅되고 관리될 KIS 메타데이터 캐시상에서 그들의 컨텐츠를 제공할 것이다. 예컨대, 로이터사에서는 인텔시과 같은 고객에게 그들의 컨텐츠를 제공하지만 인텔사에서는 상기 KIS를 호스팅하고 관리할 것이다. 인텔 KIS는 로이터 KIS를 크롤링하여 KIS 서버를 연결하거나, 로이터 RSA를 크롤링할 것이다. 이러한 방식으로, 민감한 인텔사 주석(annotation)은 로이터 컨텐츠를 콘텍스로서 이용하여 "Post-lts"로서 퍼블리싱되는 한편, 인텔사는 여전히 그 민감한 데이터에 대한 제어를 유지할 것이다.

연합 정보 커뮤니티에 대한 카테고리 네이밍-예: 인텔사에서 배치된 로이터 정보 커뮤니티(에이젼시)는 Reuters@Intel로 명명될 것이고, 카테고리는 "Reuters@Intel/Information Technology/Wireless/80211"과 같이 명명된다.

17. 익명의 주석 및 발행물

시맨틱 브라우저는 또한 사용자로 하여금 정보 커뮤니티(에이젼시)를 익명으로 주석을 달고 퍼블리싱하도록 할 것이다. 이러한 모드에서, 메타데이터는 (사용자 아이덴티티로) 완전히 저장되지만, 플래깅(flagged)되는데, 이것은 발행자가 퍼블리셔가 익명으로 남아 있길 원한다는 것을 의미한다. 이러한 방식으로, 추론 엔진 (Inference Engine)은 완전한 메타데이터를 이용하여 추론할 수 있지만, 퍼브리셔에 대한 요구는 퍼블리셔의 아이덴티티를 폭로하지 않을 것이다. 또한, 관리자는 추론 엔진이 익명의 주석(anonymous annotations) 또는 발행물(publications)을 이용하여 추론할 수 없도록 정보 커뮤니티(에이젼시)를 구성할 수 있을 것이다.

18. 시맨틱 브라우저의 오프라인 지원

시맨틱 브라우저는 또한 오프라인을 지원할 것이다. 이 브라우저는 모든 원격 호출을 위한 캐쉬를 구비할 것이다. 이 캐쉬는 XML 데이터에 대한 엔트리를 포함할 것ㄱ이다. 이것은 SRML이 되거나 호출에서 XML 웹 서비스로 반송되는 어떤 다른 데이터가 될 수 있다. 각각의 호출에는 시맨틱 브라우저에 의해 독특한 서명(signature)이 부여되고, 이 서명은 XML 데이터로 해시하는데 사용된다. 예컨대, 의미적 질의는 그 SQML에 의해 해시된다. 다른 원격 호출은 메소드 이름, 인자 이름 및 유형(argument name and types)과, 인자 데이터의 조합을 이용하여 해시된다.

XML 웹 서비스에 대한 모든 호출의 경우, 시맨틱 실행시간 클라이언트(semantic runtime client)는 호출 서명을 추출하여 이것을 로컬 캐쉬에 있는 엔트리로 맵핑할 것이다. 만약, 브라우저(또는 시스템)이 현재 오프라인 상태라면, 클라이언트는 캐쉬에 있는 XML 데이터(이것이 존재할 경우)을 반송할 것이다. 만약, 이 XML 데이터가 존재하지 않으면, 클라이언트는 (프리젠터와 같이) 호출자(caller)에게 에러 메시지를 반송할 것이다. 만약, 브라우저가 온라인 상태에 있다면, 클라이언 트는 XML 웹 서비스로부터 XML 데이터를 검색하고, 파일 경로가 서명 해시(signature hash)에 의해 표시되는 파일 엔트리의 이전 컨텐츠를 오버라이팅하여 캐쉬를 갱신할 것이다. 이것으로 인해 원격 호출이 실제로 진행하며-이 원격 호출은 시스템/브라우저가 네트워크 트래픽 및 다른 조건으로 인해 온라인 상태에 있더라도 그렇지 않을 지도 모른다는 것을 가정할 수 있다. 이러한 경우, 캐쉬는 오버라이팅되지 않는다(그것은 단지 새로운 데이터가 있을때만 오버라이팅된다; 그것은 제일 먼저 소거되지 않는다).

19. 시맨틱 브라우저의 보장된 크로스 플랫폼 지원

주요 애플리케이션에서 논의된 바와 같이, 정보 신경망 시스템은 크로스 플랫폼 방식(cross-platform manne)으로 구현되어야 한다. 표준 프로토콜은 가능한 장소에서 이용되어야 하고 웹 서비스 레이어(Web service layer)는 상호작용가능한 웹 서비스 표준을 이용해야 하고, 독점 구현(proprietary implementations)을 피해야 한다. 근본적으로, 테스트 결과, 시맨틱 브라우저는 그것이 말하고 있는 정보 커뮤니티(또는 에이젼시) 웹 서비스가 또 다른 웹 서비스상의 특정 플랫폼에서 실행되는지의 여부를 "알" 필요가 없다. 예컨대, 시맨틱 브라우저는 (독점 애플리케이션 서버의 2가지 예를 가져오기 위해) 그것이 말하고 있는 웹 서비스가 Microsoft's .NET^TM 플랫폼 또는 Sun's J2EE 플랫폼상에서 실행되고 있는지의 여부를 알 필요가 없다. 정보 커뮤니티 웹 서비스와 클라이언트-서버 프로토콜은 Microsoft's .NET^TM 및 J2EE^TM과 같은 서로 다른 웹 서비스 구현에 의해 공통으로 지원되는 웹 서비스 표준을 이용해야 한다.

이상적인 세계에서는, 웹 서비스 밴더(Web service vendor) 구현을 통해 승인되고 적절히 구현되는 공통 표준 세트가 존재할 것이다. 그러나, 이것은 실제 세계에서는 그렇지 않을 수도 있다. 시맨틱 브라우저가 서로 다른 웹 서비스 구현에서 독특한 기능성을 핸들링해야 하는 경우를 처리하기 위해, 정보 커뮤니티 스키마는 웹 서비스 플랫폼 구현을 나타내는 필드를 포함하도록 확장되어야 한다. 예컨대, 정보 커뮤니티의 .NET^TM는 플랫폼이 .NET^TM이라는 것을 나타내는 필드로 퍼블리싱되어야 한다. J2EE^TM에도 동일하게 적용된다. 이때, 시맨틱 브라우저는 (WSDL URL을 통해 직접 정보 커뮤니티에 검색하거나, 멀티캐스트, 기업체 디렉토리(enterprise directory)(예: LDAP), 글로벌 정보 커뮤니티 디렉토리등을 통해 어나운스먼트를 수신함으로써) 정보 커뮤니티에 대한 메타데이터를 검색할 때 상기 필드에 액세스할 것이다.

이때, 시맨틱 브라우저는 정보 커뮤니티가 실행하는 플랫폼에 따라 플랫폼 특정 호출을 발생한다¹. 이것은 권장되는 해결방안이 아니지만, 만약 플랫폼 특정 호출을 만들 필요가 있다면, 이러한 모델은 양호한 실시예에서 이용되어야 한다.

20. 지식 모델링

지식 모델링(knowledge modeling)이라 함은 기업체에서 정보 신경망 시스템을 배치할려고 하는 권장되는 방법을 말한다. 이것은 (하이 레벨의 지식 도메인 당) 여러 개 KIS 서버와, 계층분류 및 온톨로지를 호스팅하는 한 대(또는 몇 대의) KDS(이전에는 KBS) 서버의 배치를 내포하고 있다. KIS 서버는, 네트워크에서의 네비게이션 및 추론에 대한 충분한 지식 공유 가능성이 없도록 너무 협소함과, (데이터베이스 및/또는 추론 엔진에서 요구하는 기억장치 및 CPU 마력에 있어) 스칼라빌리티(scalability)가 문제가 되도록 너무 높음 사이에 조화를 이루기 위해 도메인 마다 배치되어야 한다. 또한, KIS 서버는, 다중 그룹이 동일한 KIS를 공유하면서 액세스 제어를 그룹 레벨에서 부과하는 것과는 반대로, 액세스 제어가 서버 레벨(보다 높은 수준의 보안인 경우)에서 필요한 장소에 배치되어야 한다. 예컨대, 대규모 제약 회사에서는 전체 회사를 위한 온톨로지용 정보 커뮤니티 KIS와, 커팅 에지 연구개발(cutting-edge R＆D)을 위해 일하고 전략적 특허를 출원하는 연구원을 위한 또 다른 KIS를 갖출 수 있다. 이들 두 가지 KIS 서버는 동일한 정보 소스르르 크롤링할 수도 있지만, 후자인 KIS 서버는 연구개발 그룹으로부터만 사용자를 가질 수 있기 때문에 더욱 안전할 것이다. 또한, 이들 연구원의 간행물 및 주석은 법인 KIS상에서는 볼 수 없을 것이다.

이하의 도 5는 제약 회사용의 지식 아키텍쳐의 예를 도시한 것이다.

도 5: 제약회사 예를 위한 지식 모델링을 예시한 블록도.

21. KIS 하우스키핑 법칙

지식 통합 서버(Knowledge Integration Server: KIS)는 관리자로 하여금 오래되거나 진부한 데이터를 제거하기 위해 "하우스키핑(housekeeping)" 법칙을 셋업하도록 한다. 이것은 KIS상의 SMS가 무한하게 크게 성장하는 것을 방지해 줄 것이다. 이들 법칙은 일정한 년수(구 데이터를 유지하기 위한 회사의 정책에 따라 2-5년)보다 더 오래된 메타데이터를 제거하는 것만큼 단순할 수 있는데, 이것은 어떠한 주석도 갖지 않고 좋아하는 것으로서 마킹되지(marked) 않는다.

22. 클라이언트 컴포넌트 통합 및 상호작용 워크플로우

1) 쉘(shell): 사용자는 UI 네비게이션 또는 마법사(wizard)를 통해 SQML 질의(즉, 에이젼트)를 함축적으로 생성한다.

2) 사용자는 (트리 또는 폴더 뷰를 통해) 에이젼트를 오픈한다.

3) 질의 버퍼는 파일로 저장되고, 생성된 레지스트리 엔트리는 에이젼트용으로 생성된다.

a) 레지스트리 엔트리는 다음 항목들을 포함한다: 에이젼트 이름, 생성 날짜, 에이젼트(요구)-GUID, SQML 경로, 코멘트, 이름공간 객체 유형(에이젼시, 에이젼트 등), 및 속성

3) 쉘: 요구가 프리젠터에게 전달된다.

a) (요구를 발생시킨 이름공간, 및 SQML 파일 URL)을 포함하는 레지스트리 요구 GUID 엔트리가 생성된다.

b) 브라우저가 초기화되고 명령어 라인 http://PresenterPage.html#RequestGUID http://presenterpage.html으로 열린다. 프리젠터는 페이지에 포함된 디폴트 크롬을 로딩한다.

c) 프리젠터 페이지는 프리젠터 바이너리 활동(binary behavior) 및 시맨틱 실행시간 OCX를 로딩한다.

5) 프리젠터는 질의 관리자를 통해 SQML을 로딩하고 요구를 발생시킨다.

a) 프리젠터는 SQML 파일 경로를 얻기 위해 요구 GUID를 해결한다.

b) SQML 파일을 버퍼에 로딩하고, 리소스 핸들링 요구를 생성하여 리소스 핸들러로 보내고, 그 결과를 대기 및 수집한다. 로컬 리소스의 개요(summarization)가 여기서 발생한다. 모든 개요는 두 가지 경로중 하나를 따른다: 이파일 경로에 의해 표시된 문서를 요약하거나, (클립보드, 아웃룩, 익스체인지 등으로부터 추출된) 이 텍스트를 요약한다. 두 개의 경로는 시맨틱 서버 XML 웹 서비스에 대한 요구에 포함되기 적합한 동일한 형식으로 개요를 생성한다.

c) SQML 파일을 위에서 리소스 개요를 포함하는 각각의 서버 요구 버퍼에 컴파일링한다.

d) 의미론적 실행시간 클라이언트 질의 관리자를 호출하여 서버 요구를 초기화한다.

7) 질의 관리자: 서버 요구를 모니터링하고 데이터에 대한 콜백(callback)을 수행한다. 또한, 그것은 요구 완료 또는 시간종료에 대한 이벤트 신호를 보낸다. 콜백은 프리젠터 내부에서 수행되는데, 이것은 XML을 통과하기 위한 내부 처리 메시징(inter-process messaging)을 의미한다.

8) 프리젠터: 데이터를 수신하고 적절한 스킨을 로딩한다.

a) SRML 데이터를 버퍼에서 수신한다; 이것은 증분적으로 발생할 것이다.

b) 이 에이젼트와 연관된 양호한 스킨(스마트 스타일)이 존재하는지를 판단한다.

c) XSLT를 통해 SRML을 양호한 스킨 포맷으로 변환한다. 이것은 결과가 들어옴에 따라 결과 트리에 대한 멀티스테이지이다(루트는 리스트이고, 그 다음엔 객체이고, 이어서 Deep/Lens/BN infom가 됨).

d) 결과를 페이지에 있는 타겟 DIV로 디스플레이한다. 타겟은 행동 자체에 대한 인자이고 루트 페이지에 의해 정의된다.

9) 프리젠터: (콘텍스트 템플레이트 마다) 콘텍스트 패널, 심층 정보(deep info), 스마트 복사 및 붙이기, 및 다른 의미론적 명령어를 채우기 위해 의미론적 실행시간을 호출한다. 프리젠터는 또한 스마트 스타일을 로딩하고, 이것은 요구의 의미론과 일치하는 의미론적 이미지, 모션등을 로딩한다.

이하의 도 6은 클라이언트 컴포넌트 통합 및 상호작용 워크플로우를 예시한 것이다.

도 6: 클라이언트 컴포넌트 통합 및 상호작용 워크플로우를 예시한 블록도.

심층 정보 명세

정보 신경망 시스템에 대한 심층 정보 명세

저자: Nosa Omoigui

1. 심층 정보

심층정보 개요

서론

Nervana "심층 정보(Deep Info)" 툴은 Nervana 정보 객체을 위한 콘텍스트 민감성 스토리 타입 정보(context-sensitive story-like information)를 제공하는 것을 목적으로 한다. 심층 정보는 근본적으로 소실될 수도 있고 특정 콘텍스트가 부여되는 정보를 Nervana 사용자에게 제공한다. 심층 정보는 (최근 아티스트, 최근 노래 및 어떤 경우엔 그 노래에 사용되는 최근 악기에 관한 정보를 보여주는) MTV상의 뮤직 비디오로 디스플레이되는 콘텍스츄얼 정보와 유사하다.

상기 "심층 정보"라 함은 콘텍스츄얼 정보가 개체가 오는 출처인 에이젼시의 의미 네트워크(semantic network)의 다중 호프(hops)에 뻗치게 될 것이라는 사실을 의미한다. "심층 정보"는 (SQML을 통한) 의미적 질의 링크로 텍스츄얼 메타데이터 또는 메타데이터를 플래닝할 수 있는 "심층정보 너겟(deep info nuggets)"으로 구성된다.

심층 정보 너겟에는 5가지 유형이 있다:

1. 기본 시맨틱 링크 너겟

2. 콘텍스트 템플레이트 너겟

3. 트리비아(trivia) 너겟

4. 매치메이커(matchmaker) 너겟

5. 회귀성(recursive) 너겟

기본 시맨틱 링크 너겟

기본 시맨틱 링크 실체로, 심층 정보 너겟은 단순히 최신 객체의 시맨틱 링크을 전달한다. 이들 너겟은 시맨틱 링크 거리 1을 내포하고 있다. 이 경우, "링크" 콘텍스트/태스크 페인(task pane)에 디스플레이될 것과 중복된다.

예:

패트릭 쉬미츠는 Nosa Omoigui에게 보고한다

패트릭 쉬미츠는 5개의 디렉트 보고서를 갖는다

패트릭 쉬미츠는 47개의 객체에 대해 주석을 달았다

패트릭 쉬미츠는 13개의 객체를 저술하였다

패트릭 쉬미츠는 56개의 이메일 객체에 복사하였다.

콘텍스트 템플레이트 너겟

콘텍스트 템플레이트 너겟은 수중에 있는 정보에 기초하여 각각의 적합한 콘텍스트 템플레이트에 대한 콘텍스츄얼 정보를 디스플레이한다. 이들 너겟은 각각의 콘텍스트 템플레이트에 대한 콘텍스트 바 또는 콘텍스트 패널에 디스플레이될 너겟과 동일하다. 예를 들면 다음과 같다:

패트릭 쉬미츠는 3개의 긴급 뉴스 항목을 게재하였다.

패트릭 쉬미츠는 14개의 클래식스을 송부하였다.

패트릭 쉬미츠는 7개의 헤드라인 기사를 작성하였다.

패트릭 쉬미츠는 356개의 객체에 대한 뉴스메이커이다.

트리비아 너겟

에이젼시 상의 모든 이메일 객체인 경우:

스티븐 저킨스는 모든 이메일 객체의 리스트상에 나타난다.

스티븐 저킨스는 이메일 객체의 23%에 대해 응답하였다.

패트릭 쉬미츠는 이메일 객체의 50%에 대해 주석을 달았다.

이들중 3개 만이 2보다 큰 스레드 깊이(thread depth)를 갖는다.

에이젼시 상의 모든 사람 객체인 경우:

패트릭 쉬미츠는 사람 객체의 47%에게 이메일을 전송하였다.

사람 객체의 14%는 Nosa Omiogui에게 보고하였다.

리사 헤일브론은 사람 객체중 85%와 토의하였다.

사람 객체의 12%는 적어도 하나의 토픽에 대한 뉴스메이커이다.

모든 사람 객체는 이번주 적어도 하나의 토의에 연관되어 있다.

사람 객체의 33%는 적어도 하나의 토픽에 관한 전문가이다.

사람 객체의 8%는 세가지 이상의 토픽에 관한 전문가이다.

에이젼시 상의 주어진 분배 리스트인 경우:

스티븐 저킨스는 대부분의 이메일을 이 분배 리스트에 송부하였다.

리사 헤일브론은 이 분배 리스트상의 대부분의 이메일에 응답하였다.

Nosa Omiogui는 이 분배 리스트에 게재한 적이 없다.

패트릭 쉬미츠는 이번 달에 87개의 메시지를 이 분배 리스트에 송부하였다.

리차드 노보트니는 금년에 345개의 메시지를 이 분배 리스트에 송부하였다.

에이젼시 상의 모든 분배 리스트인 경우:

스티븐 저킨스는 대부분의 이메일을 모든 분배 리스트에 송부하였다.

리사 헤일브론은 상기 분배 리스트의 2%의 이메일에 대해서만 응답하였다;

Nosa Omiogui는 어떤 리스트에도 송부하지 않았다.

패트릭 쉬미츠는 매주 적어도 한번 모든 리스트에 송부하였다.

리차드 노보트니는 3 개의 리스트에 메시지를 송부하였다.

에이젼시 상의 모든 정보 객체인 경우:

스티븐 저킨스는 가장 다작하는 발행자였다(그는 모든 정보 객체중 5%를 발행하였다).

리사 헤일브론은 가장 다작하는 주석자였다(그녀는 모든 정보 객체중 2%에 대해 주석을 달았다).

Nosa Omiogui는 가장 활동적인 뉴스메이커였다.

패트릭 쉬미츠는 가장 많은 통합 전문지식을 갖고 있다.

스티븐 저킨스는 금년에 출판된 정보에 대해 가장 많은 전문지식을 갖고 있다.

개빈 쉬미츠는 대부분의 토의에 연관되어 있다(정보 객체의 12%).

리차드 노보트니는 이번 달에 대부분의 토의에 연관되어 있다(정보 객체의 18%).

매치메이커 너겟

사람-대-사람(Person to Person)

시맨틱 링크 기반

패트릭 쉬미츠는 13명에게 메일을 전송하였다.

47명의 사람들이 패트릭 쉬미츠와 동일한 수신인 리스트(To list)상에 나타났다.

47명의 사람들이 패트릭 쉬미츠와 동일한 참조 수신인 리스트(CC list)상에 나타났다.

전체 89명의 사람들이 패트릭 쉬미츠가 보낸 이메일에 대해 참조되었다.

24명의 사람들이 패트릭 쉬미츠와 동일한 정보에 대해 주석을 달았다.

3명의 사람들이 패트릭 쉬미츠와 동일한 모든 분배 리스트상에 있다.

29명의 사람들이 패트릭 쉬미츠의 분배 리스트중 적어도 하나 위에 있다.

콘텍스트-템플레이트 기반

12명의 사람들이 패트릭 쉬미츠와 동일한 정보 카테고리에 대한 전문지식을 갖고 있다.

14명의 사람들과 패트릭 쉬미츠가 동일한 정보 항목에 대한 뉴스메이커이다.

27명이 사람들이 패트릭 쉬미츠와 토의하고 있다.

정보-대-사람(Information to Person)

시맨틱 링크 기반

패트릭 쉬미츠는 이 정보 항목을 송부하였다.

스티븐 저킨스는 이 정보 항목을 작성하였다.

이 정보 항목은 2 사람에게 복사되었다.

세명의 사람이 이 정보 항목에 대해 주석을 달았다.

콘텍스트-템플레이트 기반(콘텍스트 템플레이트 너겟과 유사함)

이 정보 항목에 관해 4명의 전문가가 있다.

이 정보 항목에 관해 27명의 뉴스메이커가 있다.

정보-대-정보(Information to Information)

콘텍스트-템플레이트 기반(콘텍스트 템플레이트 너겟과 유사함)

578개의 관련 "모든 베트(all bets)"가 있다.

235개의 관련 "모든 베트"가 있다.

4개의 관련 긴급 뉴스항목이 있다.

46개의 관련 헤드라인 기사가 있다.

시맨틱 링크 기반(사람을 통해서)

동일한 전문가가 이것을 갖는 21개의 정보 항목이 있다.

동일한 뉴스메이커가 이것을 갖는 23개의 정보 항목이 있다.

이것을 송부한 동일한 사람에 의해 송부된 34개의 정보 항목이 있다.

이것을 작성한 동일한 사람에 의해 작성된 34개의 정보 항목이 있다.

이것에 대해 주석을 달아놓은 사람들에 의해 주석이 달린 44개의 정보 항목이 있다.

회귀성 너겟

회귀성 너겟으로, 현재 정보 너겟의 주제위에 심층 정보를 디스플레이하면 콘텍스츄얼 계층이형성된다. 이때, 시스템은 주제의 객체유형에 기초하여 너겟을 회귀하여 디스플레이한다. 회귀성 너겟으로, 본 시스템은 근본적으로 소스 객체에서 출발하는 의미 네트워크를 심층검사하고, 네트워크의 경로를 따라 너겟들을 계속해서 디스플레이한다. 그것은 어느 깊이에서 심층검사를 중지시킬 TBD이다. 다음은 예를 든 것이다:

패트릭 쉬미츠는 이 이메일을 작성하였다

패트릭 쉬미츠는 Nosa Omoigui에게 보고하였다

Nosa Omoigui는 6개의 디렉트 보고서를 갖고 있다.

스티븐 저킨스는...

스티븐 저킨스는....을(를) 송부하였다.

스티븐 저킨스는 ...에 관한 전문가이다.

스티븐 저킨스는...에 관한 뉴스메이커이다,.

스티븐 저킨스는 6번의 토의에 연관이 있다

[등등]

리차드 노보트니는...

[나머지 6개의 디렉트 보고서]

Nosa Omoigui는 ...13개의 객체에 대해 주석을 달았다.

[13개 객체에 대한 보다 많은 콘텍스트 템플레이트 너겟]

Nosa Omoigui는 278개의 객체를 작성하였다.

Nosa Omoigui는 23개의 객체에 대해 주석을 달았다.

패트릭 쉬미츠는 5개의 디렉트 보고서를 갖고 있다.

존 도는....

디렉트 보고서에 기초한 보다 많은 네이티브 너겟

패트릭 쉬미츠는 47개 객체에 대해 주석을 달았다.

정보 신경망 시스템을 위한 보안 명세

저자: Nosa Omoigui

1. 인증

인증 개요

서론

'사람(People)' DSA는 LDAP 디렉토리 URL과 그룹 이름(Group Name)을 가지고 초기화될 것이다. 사용자(Users)' DSA도 또한 LDAP 디렉토리 URL과 그룹 이름으로 초기화될 것이다. 전형적으로, '유저'는 '사람'의 서브셋(subset)이 될 것이다. 예를 들어, 한 제약 회사는 여러 가지 다양한 제약 범주(예를 들자면, 생물 공학, 생명 과학, 약리학 등)에 대한 KIS를 설치할지도 모른다. 이들 각각은 그 범주내에 지식을 갖고 있거나 관심을 가지는 사용자 그룹을 갖게 될 것이다. 그러나, KIS는 그 회사의 모든 피고용인으로서의 '사람' 그룹을 또한 가지게 될 것이다. 이는 KIS의 사용자가 그 전체 피고용인 회원들이 KIS의 사용자가 아닐지라도 그들 회원에 대한 제어가 가능하게 할 것이다. 게다가, 추론 엔진(inference engine)은 반드시 KIS의 사용자들이 아닐지라도, 그 회사의 사람들을 시멘틱 링크로 전문적으로 추론할 수 있을 것이다.

이는 KIS 레벨의 액세스 제어에 또한 중요하다. 그러한 사용자 그룹은 KIS 지식에 엑세스하는 사람들을 포함할 것이다. 그러나, 이 사람 그룹은 비록 이들이 KIS에 엑세스하지 않을지라도 KIS에 관련있는 사람들을 포함할 것이다.

사람과 사용자 DSA 모두는 의미적 메타데이터 저장장치 (SMS)내의 사람 테이블에 설치되며 적절하게 객체형 유형 id를 나타낸다. 이 때, 그 패스워드는 SMS의 사람 테이블에 저장되지 않는다는 것을 주의한다.

사용자 DSA는 사용자 인증 테이블(User Authentication Table: UAT)에 또한 설치된다. 이는 사용자 이름을 패스워드로 맵핑하는 인-메모리 해쉬 테이블(in-memory hash table)이다. 이 서버의 웹 서비스는 IPasswordProvider 인터페이스 또는 그 등가물로 실행될 것이다. 그 PasswordProvider 객체의 실행은 그 맵핑된 패스워드를 특정 사용자 이름으로 되돌릴 수가 있다. 예 C# 가 이하에서 이를 다음과 같이 보여준다:

다음의 C# 코드는 사용자의 인증이 이루어진 후에 웹 서비스가 그 사용자 정보를 검색할 수 있는 방법을 보여준다:

그 다음 너바나(Nervana) 웹 서비스로 가서 그 사용자 이름으로 서버 시멘틱 런타임(Server Semantic Runtime)을 불러올 수 있다. 그런 후, 그 실행시간에 이를 SQL로 맵핑하여 적절한 필터를 사용하여 시멘틱 질의를 만든다.

너바나 ASP.NET 응용을 위하여, 다음의 리스트가 Web.config file의 부모 구조부재의 한 어린아이로써 추가된다.

클라이언트측의 인증 요구

그 요청에 대한 유저네임 토큰(Username Token)을 만들기 위해, 너바나 클라이언트는 SOAP 요청의 일부로써 사용자이름과 패스워드를 통과해야만 한다. 너바나 클라이언트는 그 요청의 일부로써 멀티플 토큰을 통과해야만 한다. 이는 사용자의 아이덴티티가 멀티플 인증 프로바이더를 통하여 통합되는 경우에 중요하다. 이 너바나 클라이언트는 사용자가 제공한 모든 사용자 어카운트 정보(사용자 이름과 패스워드 정보를 포함하여)를 모아서, 이들을 WS-Security 토큰으로 변환하고, 그런 후, SOAP 질의를 만들 것이다. 그 클라이언트 코드는 다음의 것과 같을 것이다(참조: http://www.msdn.microsoft.com):

서버상에서 사용자이름 토큰 확인하기

(http://msdn.microsoft.corn/library/default.asp?url=/library/en-us/dnwssecur/html/wssecwithwsdk.asp)

비록 WSDK가 그 보안 헤더 구문을 확인하여 그 패스워드 프로바이더(Password Provider)로부터 그 패스워드에 대한 패스워드 해쉬를 확인한다 할지라도, 그 질의상에서 반드시 실행되어야만 할 몇 가지 또 다른 확인이 있다. 예를 들어, 만약 패스워드 요소를 포함하지 않는 유저네임 토큰이 입력된다면 WSDK는 그 패스워드 프로바이더를 부르지 않는다. 만약 확인할 패스워드가 없다면, 그 패스워드 프로바이더를 부를 이유가 없다. 이는 유저네임 토큰의 포맷을 우리자신이 확증할 필요가 있다는 것을 말한다.

그 요청에 하나이상의 유저네임 토큰이 포함될 또 다른 가능성이 있다. WS-Security가 여러 가지 목적으로 사용될 수 있는 요청에 대한 여러 개의 토큰을 포함하는 서포트(support)를 제공한다.

상기의 코드는 그 해쉬된 패스워드를 포함하는 유저네임 토큰을 확인하고 단일 유저네임 토큰을 가진 요청만을 인정하는 너바나 웹 방법으로 변형될 수 있어야만 한다. 그 변형된 코드는 이하에 표기된 바와 같다:

2. 사람 그룹

KIS는 사람 그룹에 대한 메타데이터를 포함할 것이다. 이들은 현대의 작동 시스템에서의 사용자 그룹과 다르지 않다. 이들 사람 그룹은 너바나 제 1 객체 클래스 (예를 들어, 이는 객체(Object) 클래스로부터 이어져 내려오게 될 것이다). 또한, 이 사람 그룹 개요는 다음과 같을 것이다:

대개의 경우에는, 사람 그룹은 디렉토리 시스템(LDAP와 같은)내의 사용자 그룹에 배치될 것이다. 예를 들어, KIS 서버 어드민(admin)은 구성가능한 사용자 그룹 셋을 찾는 KIS를 가지게 될 것이다. 사용자 그룹을 찾아서 SMS내에 그 사람 그룹과 사용자 테이블을 설치하는 사람 DSA가 될 것이다. 이 사람 DSA는 다음의 동작을 실행할 것이다:

그룹(만약 SMS내에 존재하지 않는다면)을 만들거나 그 그룹(만약 존재한다면)의 메타데이터를 업데이트한다.

그 그룹(소스에서, 즉 본 바람직한 실시예에서는 LDAP 디렉토리)내의 모든 사용자를 열거한다.

그 그룹내의 모든 사용자에 대한 사람 객체를 만든다(또는 그 객체가 SMS내에 이 미 존재한다면 메타데이터를 업데이트한다).

그 사람 객체를 그 그룹 객체에 배치함으로써(BELONGS_TO_GROUP 시멘틱 링크 유형을 이용하여) 의미적 네트워크(SMS내의 '시멘틱링크(SemanticLinks)' 테이블을 경유하여)를 업데이트한다. 이는 SMS가 그룹 회원 정보(더하여 그룹과 사용자에 대한)를 갖는 시멘틱 링크를 가진다는 것을 보장한다.

3. 아이덴티티 메타데이터 연합

아이덴티티 메타데이터 연합(Identity Metadata Federation:IMF)는 정보 커뮤니티(Information Community)(에이전시)가 인터넷상에서 배치되었으나 서비스 기업이나 개인 고객들에게 사용되는 특징을 가지고 있다. 예를 들어, 로이터(Reuters)는 독점 콘텐츠에 따른 모든 고객들에 대한 정보 커뮤니티를 구성할 수 있다. 멀티플 고객이 정보 커뮤니티(대개 동일한 산업에서)를 공유하는 그러한 경우에, 로이터는 각 고객에 대한 SMS에 그룹을 가지게 될 것이다. 그러나, 이들 각 고객은 사람 메타데이터가 사용가능하도록 하기 위해서 로이터에 보여지게 되는 기업 디렉토리를 가지고 있어야만 할 것이다. 이는 특히 보안과 개인 관점으로부터 야기되는 문제들을 가지게 될 것이다. 기업은 그들의 피고용인의 메타데이터에 대한 액세스를 가지는 콘텐츠 프로바이더를 가지는 것이 편하지는 않을 것이다. IMF는 사용자의 인증을 위한 메타데이터로서만 충분한 인터넷-호스티드 정보 커뮤니티(에이전시)를 가짐으로써 이 문제를 처리한다. 예를 들면, 로이터는 SMS에 기업 고객의 사용자 에 대한 로그온(logon) 정보만을 저장할 것이다. 시멘틱 브라우저가 그러한 불충분한 메타데이터를 포함한 SRML을 받았을 때, 그 다음 클라이언트는 그 기업 디렉토리(만약 그 기업 디렉토리 메타데이터가 웹 서비스 디렉토리를 통하여 사용가능하도록 만들어졌다면 LDAP 액세스나 UDDI를 경유하여)에 대해 또 다른 질의를 하여 그 사용자에 대한 완벽한 메타데이터를 가져올 수 있다. 이는 그 외부적으로 저장된 메타데이터가 나머지 정보를 불러오게 할 수 있는 아이덴티티 정보를 가질 수 있기 때문에 가능하다. 클라이언트가 그 기업의 방화벽(firewall)내에서 그 나머지 메타데이터를 가져오기 때문에, 그 민감한 기업 메타데이터는 그 외부 세계와 공유되지 않는다.

4. 액세스 제어

액세스 제어 방법

KIS는 액세스 제어 시멘틱스를 구비하여 실행할 것이다. 이 KIS는 "디폴트 액세스(default access)" 방법을 실시한다. 이 방법으로 인해, 액세스가 거절된 경우를 제외하고는 그 SMS내의 어떤 메타데이터에 대한 사용자의 요청에 대한 액세스를 허용할 것이다. 그렇게, 이 시스템은 확장되어 새로운 액세스 형태에 상반되는 것으로써 새로운 거절 형태를 제공할 수 있다. 게다가, 이는 만약 거절에 대한 어떤 근거가 없다면, 사용자는 액세스가 허용될 수 있다는 것을 의미한다(이는 보다 단순하고 간단한 액세스 제어 모델을 보여준다).

이 KIS는 액세스 제어 매니저(Access Control Manager:ACM)를 구비할 것이다. 이 ACM은 SQP가 클라이언트로부터의 소정의 시멘틱 요청에 대한 그 질의에 첨부될 거절 시멘틱 질의 (Denial Semantic Query:DSQ)을 발생하는 데에 일차적으로 책임을 가진다. 그 ACM은 다음의 방법(예 C#)을 보여줄 것이다:

String GetDenialSemanticQuery(String CallingUserName)

이 방법은 호출하는 사용자 이름에서 얻어져서 예외 객체(exception objects) 을 보호하는 SQL 질의(또는 그에 동등한 것)로 돌아간다. 이들은 SQP에 의해 사용자 호출로 돌아갈 수 없는 객체이다(즉, 사용자가 액세스하지 않는 객체).

SQP는 다음과 같은 거절 질의를 포함하는 최종 원(raw) 질의를 구축한다:

Aggregate Raw Query AND NOT IN (Denial Query)

예를 들어, 만약 그 집합적인 원 질의가

SELECT OBJECTID FROM OBJECTS WHERE OBJECTTYPEID=5이면,

그 거절 질의는 다음과 같다:

SELECT OBJECTID FROM OBJECTS WHERE OWNERUSERNAME＜＞'JOHNDOE', ²

그 최종 원 질의(이는 SQP가 마지막으로 실행되어 SRML으로 일련화되어서 사용자 호출로 돌아가는 것임)가 다음과 같이 될 것이다:

SELECT OBJECTID FROM OBJECTS WHERE OBJECTTYPEID=5 AND NOT IN (SELECT OBJECTID FROM OBJECTS WHERE OWNERUSERNAME＜＞'JOHNDOE')

의미론적으로, 이는 다음과 동등하다:

"Select all objects that have an objected type id of 5 but that are not in an object list not owned by John Doe."

다시 말해 이는 다음과 의미론적으로 동등하다.

"Select all objects that have an objected type id of 5 that are owned by John Doe."

일반적인 액세스 제어 규칙

의미적 질의 처리기 (SQP)에 의해 처리된 각각의 의미적 질의는 액세스 제어 확인을 포함할 것이다. 이는 그 호출하는 사용자가 자신이 액세스하는 메타데이터만을 얻을 수 있다는 것을 보장할 것이다. 그 SQP는 의미적 질의를 처리할 때 다음의 액세스 제어 규칙을 실행할 것이다:

1. 만약 질의가 '사람(People)' 객체(사람, 사용자, 고객, 전문가, 뉴스메이커, 등)에 대한 것일 경우, 그 반환된 사람 객체는 다음의 하나가 되어야만 한다:

호출하는 사용자를 포함하거나, 또는

적어도 하나의 사람 그룹를 호출하는 사용자와 공유하며, 그 호출하는 사용자 또는 그 시스템에 의해 소유되는 사람들을 포함한다.

이에 상응하는 거절 질의는 다음의 규칙을 가진다: 그 반환된 객체는 다음의 조건을 만족해야만 한다:

호출하는 사용자 +가 아니다

호출하는 사용자 또는 시스템 +에 의해 소유되지 않는다

어떤 사람 그룹을 호출하는 사용자와 공유하지 않는 사람들을 가진다

거절 질의 SQL의 견본

이하에서 SQL은 ACM에 의해 발생되고 SQP에 의해 첨부되어서 액세스 제어 방법을 실행할 수 있는 액세스 제어 거절 질의를 도시한다. 이 예에서, 그 호출하는 사용자의 이름은 'JOHNDOE'이다.

2. 만약 질의가 사람(People)이 아닌 객체(문서, 전자메일, 사건, 등)에 대한 것일 경우, 그 반환된 객체는 다음의 하나가 되어야만 한다:

호출하는 사용자나 그 시스템 사용자에 의해 소유되어서

그 객체로써 호출하는 사용자에 대해 시멘틱 링크의 주체가 되거나, 혹은

그 주체로써 호출하는 사용자에 대한 시멘틱 링크의 객체가 되거나, 혹은

적어도 하나의 사람 그룹를 호출하는 사용자와 공유하는 사람이 되는 객체에 대해 시멘틱 링크의 주체가 되거나, 혹은

적어도 하나의 사람 그룹를 호출하는 사용자와 공유하는 사람이 되는 주체에 대 해 시멘틱 링크의 객체가 된다

이에 상응하는 거절 질의는 다음의 규칙을 가진다: 그 반환된 객체는 다음의 조건을 만족해야만 한다:

호출하는 사용자 +에 의해 소유되지 않는다

그 시스템 사용자 +에 의해 소유되지 않는다

그 객체 +로써 호출하는 사용자에 대해 시멘틱 링크의 주체가 되지 않는다

그 주체 +로써 호출하는 사용자에 대한 시멘틱 링크의 객체가 되지 않는다

적어도 하나의 사람 그룹를 호출하는 사용자 +와 공유하는 사람이 되는 객체에 대해 시멘틱 링크의 주체가 되지 않는다

적어도 하나의 사람 그룹를 호출하는 사용자와 공유하는 사람이 되는 주체에 대해 시멘틱 링크의 객체가 되지 않는다.

거절 질의 SQL의 견본

이하에서 SQL은 ACM에 의해 발생되고 SQP에 의해 첨부되어서 액세스 제어 방법을 실행할 수 있는 액세스 제어 거절 질의를 도시한다. 이 예에서, 그 호출하는 사용자의 이름은 'JOHNDOE'이다.

병합된 거절 질의 SQL의 견본

이러한 두개의 규칙을 병합함으로써, ACM은 다음의 병합된 질의를 액세스 거절에 대한 SQP로 반환한다:

시나리오 예

예를 들어,

로이터 에이전시(KIS)는 로이터에 관계된 각 기업 고객에 대한 사람 그룹을 가질 것이다. 이 에이전시는 공통의 정보 베이스(로이터 콘텐츠)를 가질 것이나 기업 고객당 사람 그룹을 가질 것이다. 이들 그룹은 경쟁 상대를 포함할 것이다. 그렇게, 그 지식의 흐름, 발생과 추론은 그 경쟁 상대의 경계범위를 지나가지 않아야 한다는 것이 확실하게 보장되어야한다는 것은 중요하다. 예를 들어, A회사의 피고용인은 A회사와 경쟁하는 B회사의 피고용인으로부터 직접적으로 지식을 빼어오지 말아야하며, 비직접적으로도(추론을 통해) 그 지식을 가져오지 말아야 한다. A회사의 피고용인은 B회사의 피고용인에 의해 의견된 항목에 대한 충고를 가질 수 없다. 또는 A회사의 피고용인은 B회사를 위해 일하는 전문가들을 찾을 수 없다. 물 론, 이는 A회사와 B회사가 몇가지 면(이 경우에, 그들은 지식을 공유하기를 원할지도 모른다)에서 서로 협력자가 아니라는 것을 가정한다. 그 지식을 공유하는 협력자의 경우에, 로이터는 A회사와 B회사의 사람 그룹을 포함한 사람 그룹(LDAP를 경유한)을 만들 것이다. 그 다음, 로이터 에이전시 KIS는 다음의 사람 그룹을 가질 것이다: A회사, B회사와 A와 B회사. 또한 SMS는 이들 그룹("그룹에 속하는(belongs to group)" 시멘틱 링크 유형)에 속하는 A회사와 B회사의 사람들을 나타내는 메타데이터를 가질 것이다. 이 처리중에서, 상기에서 언급한 규칙들이 A회사와 B회사간에 지식이 공유된다는 것을 보장할 것이다.

주석에 대한 액세스 제어 규칙

주석의 경우에, 호출하는 사용자는 그 주석을 질의하는 것에 상반되는 것으로써, 의미적 네트워크를 편집할 것이다. 이 경우, 다음의 규칙이 적용될 것이다:

1. 만약 주석될 객체가 사람 객체라면, 그 객체는 다음중의 하나가 되어야만 한다:

호출하는 사용자, 또는

적어도 하나의 사람 그룹을 호출하는 사용자와 공유하며, 그 호출하는 사용자 또는 그 시스템에 의해 소유되는 사람이다

2. 만약 주석될 객체가 사람(Person)이 아닌 객체(예를 들어, 문서, 전자메일, 사건, 등)에 대한 것일 경우, 그 객체는 다음의 하나가 되어야만 한다:

호출하는 사용자에 의해 소유되거나

시스템에 의해 소유된다

거절 질의 SQL의 견본

이하에서 SQL은 ACM(주석에 대한 액세스 제어를 확인하는)에 의해 발생되고 SQP에 의해 첨부되어서 액세스 제어 방법을 실행할 수 있는 액세스 제어 거절 질의를 도시한다. 이 예에서, 그 호출하는 사용자의 이름은 'JOHNDOE'이다.

액세스 제어 시행

ACM은 주석에 대한 액세스 제어와 KIS상에서 다른 라이트(write) 동작을 실행한다. KISXML 웹 서비스는 다음과 같은 주석 방법(예 C#)을 보여준다:

AnnotateObject(String CallingUserName, String ObjectID):

이 방법은 ACM을 호출하여 거절 질의를 가진다. 그런 다음, 다음과 같은 최종 질의를 만든다:

Annotation Object Query AND NOT IN (Denial Query)

그 주석 객체 질의는 항상 다음과 같이 이루어진다:

SELECT OBJECTID FROM OBJECTS WHERE OBJECTID=ObjectID,

여기서 ObjectID는 그 AnnotateObject 방법에 대한 인자(argument)이다.

그 다음 ACM은 최종의 액세스 제어 질의 SQL을 구축하고 이 SQL을 사용하여 액세스 제어에 대한 확인을 실행한다. ACM은 그 SQL을 반환할 필요가 없기 때문에, 이는 액세스 제어에 대한 확인을 실행하기 위해 그 SQL을 바로 호출하기만 한다. 또한, 이는 이진법(binary)인 확인(액세스 또는 비 액세스(no access)이기 때문에, ACM은 단지 그 거절 질의가 적어도 하나의 열을 반환하는 지를 확인한다. 예를 들어, 최종 질의는 다음과 같이 보여질 것이다:

SELECT OBJECTID FROM OBJECTS WHERE OBJECTID = ObjectID AND NOT IN (SELECT OBJECTID FROM OBJECTS WHERE OWNERUSERNAME＜＞'JOHNDOE')

그 다음 ACM은 이 질의(SQL 질의 프로세서를 경유하여)를 실행하여 그 결과 세트내의 그 열의 수에 대한 카운트를 요청한다. 만약 하나의 열이 있다면, 액세스는 허가되며, 다른 액세스는 거절된다. 이러한 모델은 거절 질의 모델(ACM은 거절 질의를 구축하여 모든 액세스 제어 확인을 위한 근거로써 이를 항상 사용한다)과 일치를 보이도록 하기 위하여 이러한 방식으로 실행된다.

의미론적 정의 및 시각화 명세

정보 신경망 시스템을 위한 의미론적 질의 정의 및 시각화

명세서

저자: Nosa Omoigui

1. 의미론적 이미지 및 모션

개요

의미론적 이미지 및 모션은 Nervana 의미론적 사용자 경험의 중요한 일부이다. 이것에 의해서, Nervana 에이젼시 (정보 커뮤니티)에 저장되어 있고 Nervana XML 웹 서버를 통해 액세스되는 이미지/모션 메타데이터를 갖는 다는 것을 의미한다. Nervana를 통해, 최종 사용자들은 그 이미지에 대한 콘텍스트 및 시간 민감성 접근을 할 수 있을 것이다. 호출될 때, Getty Images (또는 Corbis)를 이메일 메시지의 스마트 렌즈로서 사용한다고 가정한다. 이는 메시지에 의미론적으로 관련된 이미지를 열 것이다. 또는, 귀하의 하드 드라이브에서 Getty 에이전트로 문서를 드래그/드롭하여 의미론적으로 관련된 이미지를 본다. 이는 이미지 메타데이터 (이미지 스키마와 일관성)를 갖는 것을 포함한다. Nervana 툴박스는 동일할 것이고, 우리는 단지 이미지에 대한 새로운 정보 객체 유형을 추가할 것이다. 또한, 의미론적 이미지에 대한 의미론적 스킨 - 다른 관점, 견본, 슬라이드 쇼, 필터링, 집합체 등일 수 있다. 의미론적 이미지의 예를 위해서는, 다음 사이트를 방문하시오:

http://creative.gettyimages.com/source/search/resultmain.asp?source=advSearch＆hdnSync=Medicine%7E0%2C12%2C449%2C3%2C15%2C1%2C0%2C0%2C0%2C0%2C12287%2C0%2C7%2C14%2C6%2C3%2C3%2C0%2C12%2C449%2Cen%2Dus＆UQR=tfxfwz

업계 고유의 의미적 이미지 및 모션

업계 고유의 의미적 이미지/모션은 (업계에 맵되는) 하나 이상의 카테고리에 대한 의미적 결과를 위한 프리젠테이션 분위기의 일부로서 사용될 이미지/모션이다. 예를 들어, http://www.crobis.com 및 http://gettyimages.com를 방문해서 (집합적으로, 로이터 분류에 따라 타겟 업계에 맵되는) 다음의 키워드를 위한 검색을 입력한다 - 이하 참조. 이들 이미지/모션들은 (콘텍스트 템플릿 및 카테고리에 맵되는) 콘텍스트 및 카테고리 스킨을 위한 배경, 필터 효과, 변환 및 애니메이션으로서 사용될 것이다. 또한, 이들 이미지/모션들은 매우 흥미있는 스크린세이버를 위한 이들 이미지의 일부에서 추출된 모션 경로에 대한 시각화에 사용될 것이다. 예를 들어, 주변의 다른 이미지 및 애니메이션을 갖는 크롬과 함께, 이들 의미적 이미지 (예를 들어, "전기 설비" 업계를 위한 전구 내에서 회전하는 메타데이터) 중의 하나에서 추출된 모션 경로를 따라 메타데이터와 시각화를 디스플레이한다고 가정한다.

- 제약

- 의약

- 건강관리

- 생활 과학

- 생물학

- 오일 및 가스

- 화학

- 에너지

- 전기 설비

- 가스 설비

- 물관련 설비

- 연예

- 환경 서비스

- 출판

- 부동산

- 금융

- 중개업

- 금융 서비스

- 은행

- 소비자

- 소비자 제품

- 소비자 서비스

- 통신

- 원거리통신

- 원거리통신 장비

- 원거리통신 서비스

- 원거리통신 기술

- 원거리통신 규정

- 담배

- 자동차

- 보험

- 컨설팅

- 정보 기술

- 기술

- 컴퓨터 장비

- 컴퓨터 제조업자

- 컴퓨팅

- 반도체

- 나노기술

- 공공부문

- 정부

- 국가 보안

- 여행

- 관광

- 운송

- 비행기

- 소매

- 패션

- 광고

- 항공우주

- 방위

- 농업관련 사업

- 농업

- 음료

- 비지니스 서비스

- 전자상거래

- 음식

- 산림 제품

- 건강관리 제공업체

- 접객

- 인터넷

- 법률

- 법적 요건

- 제조

- 마케팅

- 미디어

- 네트워킹

이는 정보 유형 및 콘텍스트 템플릿에도 동일하게 적용된다. 스킨은 콘텍스트/정 보 유형 및 카테고리에 기초하여 스마트한 것을 수행하여야 하고, 영리하게 이들 속성에 걸친 의미론적 이미지/모션을 혼합 및 일치시켜야 한다. 예를 들어, "무선 기술에 대한 헤드라인"이란 제목의 에이전트는 "헤드라인" 이미지/모션과 "무선" 이미지/모션 간에 토글링하는 이미지/모션에 기초한 애니메이션을 보여주는 크롬 (및/또는 스마트 모래시계 - 이하 참조)을 가질 수 있다. "제품 명세서에 관련된 나의 그룹 내의 누군가에 의한 무선 헤드라인 및 반도체 및 이메일에 대한 속보"라는 제목의 블랜더는 "헤드라인", "뉴스", "무선", "반도체" 및 "이메일"에 대한 이미지/모션 간에 "토글하는" 크롬 (및/또는 스마트 모래시계)을 가질 수 있다.

프리젠터의 질의 프로세서는 (에이전트/블랜더 SQML로부터의) 모든 콘텍스트 템플릿 및 정보 유형 및 모든 카테고리를 열거할 수 있고, 이에 따라 크롬 애니메이션을 설립할 수 있다.

정보 유형으로부터, (Corbis 및 Getty에서) 다음 검색어를 입력한다:

- Documents

- Email

- Books

- Magazines

- Multimedia

- Online Learning

- People

- Users

- Customers

또한, 콘텍스트 템플릿을 위해 다음 검색어를 입력한다:

- Headlines

- News

- Discovery

- Conversations

- Experts

- Favorites

- Places

- Time ("스케줄" 및 "공개될 이벤트"의 경우)

- Schedule

- Appointment

또한, 의미론적 이미지/모션은 완전히 랜덤해서는 안된다는 것에 유의하여야 한다. 그러나, 이들은 경계 세트로부터 나와서는 안된다. 이들은 주의 깊게 선정된 다음, 스킨은 선정된 세트로부터 랜덤하게 선택할 수 있다. 그러나, 이들 이미지/모션은 전체 구간, 즉 Corbis 또는 Getty로부터 랜덤해서는 안된다. 이들은 멍청한 이미지, 만화 및 일부 잠재적으로 공격적인 이미지들일 것이다. 또한, 이들 가이드 라인들 중의 일부는 스킨 테마가 미묘, 온건한, 재미있는지 또는 매우 재미있는 모드인지에 따라 변하여야 한다. 미묘한 모드에서는, 스킨은 시각화 피봇 당 하나의 이 미지/모션을 선택하기를 결정할 수 있다. 다른 모드에서는, 이는 사용자에게 무료한 경험을 겪게 할 가능성이 있다.

저-플래시 모드에서는, 스킨은 파워포인트 슬라이드 덱 배경 (예를 들어, 알파 블렌디드)와는 달리, 크롬의 일부로서 의미론적 이미지/모션을 사용할 수 있다. 의미론적 이미지/모션은 (콘텍스트 바, 패널 또는 팔렛 위의) 시각화의 일부에서는 물론 스마트한 모래시계 (이하 참조)에 또한 사용될 수 있다. 콘텍스트 및 정보 유형의 시각화를 위해, 의미론적 이미지/모션은 주의깊게 선정되어 정보 유형 및 콘텍스트를 분명하게 가리켜야 한다. 또한, 선택 모드는 또한 스킨 속성일 수 있다.

또한, 스킨 당 사용되는 가능한 의미론적 이미지/모션의 수는 의미론적 이미지/모션이 어디에 디스플레이되는 지에 따라 캡될 필요가 있을 것이다. 그러나, 일부 시나리오에서는 이는 반드시 필요하지 않을 수도 있다. 예를 들어, 블렌더 스킨은, 블렌더로부터 현재 디스플레이되는 것과 일치하도록, 사용자가 블렌더 결과를 (페이지마다 또는 에이전트마다) 네비게이트함에 따라 크롬 배경 간을 사이클할 수 있다. 이 또한 스킨 속성일 수 있다.

클라이언트측 의미론적 이미지 및 모션 캐쉬

프리젠터는 클라이언트 (설치시) 상에 다운로드되어 저장된 의미론적 이미지/모션 을 갖는 스마트한 확장 가능한 클라이언트 측 캐쉬를 가질 것이다. 이때 스킨은 이와 같은 미리 캐쉬된 의미론적 이미지/모션으로부터 선택할 수 있3다. 이미지/모션은 타겟 업계에 맵되는, (그 또는 그녀가 선택하는) 사용자의 관심 카테고리 및 관심 영역에 기초하여 미리 캐쉬될 수 있다. 이때 스킨은 이미지 서버에의 주문 이미지 질의를 갖는 미리 캐쉬된 의미론적 이미지/모션을 보충할 수 있다 (Nervana 또는 Corbis 또는 Getty Images와 같은 제3 자에 의해 호스트되는 서버 측 이미지/모션을 노출시키는 XML 웹 서비스).

프리젠터는 또한, 최근에 다운로드된 이미지/모션이 이전 이미지/모션 (동점결승전으로서) 이전에 선택되도록 똑똑한 짓을 하고 기본적인 기능을 가질 것이다. "용법 카운트"는 또한 각각의 이미지/모션과 함께 캐쉬되고, 프리젠터는 어떤 이미지/모션을 언제 필터링하는데 있어서의 이와 같은 카운트를 사용한다. 이와 같은 "로드 밸런싱"은 보다 신선하고 반복적이지 않은 사용자 경험을 낳게 될 것이다.

캐쉬는 예를 들어 주문시 (사용자의 의미론적 질의에 기초하여) 가득 채워져야 한다. 보잉에서 사용자의 기계를 위한 제약 이미지/모션을 미리 캐쉬하는 것은 소용이 없다. 또한 캐쉬 크기는 캡핑되어야 하고, 이미지 캐쉬 매니저는 LRU 알고리즘 또는 이의 등가물을 사용하여 "구" 및 "미사용" 이미지를 숙청하여야 한다. 이와 같이, 캐쉬는 사용자의 에이전트 사용 패턴 및 좋아하는 에이전트 리스트와 "의미론적 동기"할 수 있다.

2. 스마트 모래시계

Nervana 프리젠터가 "의미론적 사용자 경험"을 제공하는 호출의 대부분은 XML 웹 서비스에 대한 원격 호출일 것이다. 이와 같이, UI에는 예측할 수 없고, 잠재적으로 구속되지 않은 지연이 존재할 것이다. 업체 내에서는 상당한 크기의 대역 및 서버 마력을 예상할 수 있지만, Nervana 사용자 인터페이스는 메소드 호출에 알려지지 않은 지연에 대한 "계획"을 세워야한다.

오늘날의 운영체제는 디스크 또는 네트워크에의 구속되지 않은 I/O 호출에 있어서의 이와 같은 문제를 가지고 있다. 일부 CPU-지향 연산도 또한 상당히 지연되고 있다.l Windows 및 Mac UI에서, 사용자는 흔히 "모래시계"의 형태로 "대기" 커서를 거쳐 지연을 인지하게 된다.

Nervana에서, 프리젠터는 "스마트 또는 의미론적 모래시계"에 상당하는 것을 디스플레이할 수 있는 ("SQML "메소드 호출"에의 직접 액세스를 거쳐) 의미론적 힌트를 가질 것이다. 이는 "로딩" 및 몇몇 다른 효과를 디스플레이하는 틈새 페이지 형태일 것이다. 보다 중요하게, 프리젠터는 질의를 제시하는 카테고리 및 이미지 유형 또는 콘텍스트 템플릿에 대한 힌트를 얻기 위해 SQML을 읽음으로서 질의의 의미를 전달할 수 있다. 프리젠터는 이미 결과를 수신하였다 하더라도, 이들 힌트를 이용하여 질의에 부합하는 의미론적 이미지 및 텍스트를 디스플레이할 수 있다. 질의가 갖는 힌트가 많을 수록 모래시계는 보다 정확한 것을 얻는다. "로딩" 페이지는 웹 서비스로부터 실제 결과가 도달하기 전일지라도 "다음에 올 것"의 분위기를 전달하고, 프리젠터에 의해 (필요에 따라) 병합되어 최종 결과를 만든다.

""스마트 모래시계"는 주 결과 창유리 바로 위가 아니라, 아마도 스마트 렌즈 풍선 팝업 윈도우즈 및 인라인 미리보기 윈도우 (반드시 웹 서비스에의 호출 사이트 및 "포커스"가 있는 곳)상에 디스플레이될 수 있다. 프리젠터는 질의를 제한하므로서 "모래시계"를 디스플레이하기 전에 (아마도, 몇 백 밀리초 후 - 그 구현은 이를 위해 도면에 도달하는 가용성 테스트를 사용하여야 한다) 스마트한 것을 할 수 있을 것이다.

3. 시각화 - 콘텍스트 템플릿

개요

서론

콘텍스트 템플릿은 시나리오 구동 정보 질의 템플릿을, 정보 액세스 및 검색을 위한 특정 의미론적 모델에 맵핑된다. 반드시, 콘텍스트 템플릿은 정의된 의미론적 템플릿을 이용하여 사용자에게 정보를 전달하는 사적인 디지털 의미론적 정보 검색 '채널"로 간주될 수 있다. 콘텍스트 템플릿은 바람직하게 하나 이상의 에이젼시 간의 정보를 집합하다.

이하 설명되는 콘텍스트 템플릿을 정의한다. 다양한 종류의 의미론적 정보의 통합 및 전파를 지향하는 부수적인 콘텍스트 템플릿이 고려된다 (예는 "노여움" "슬픔"과 같은 감정에 관련된 콘텍스트 템플릿, 위치, 이동성, 주위 분위기, 사용자 작업 등을 위한 콘텍스트 템플릿을 포함).

긴급 뉴스

긴급 뉴스 콘텍스트 템플릿은 의미론적 정보를 어떻게 전달하는지에 있어서 CNN의 "속보" 프로그램 삽입의 사적이고 디지털 버전으로 유사화될 수 있다. 이 콘텍스트 템플릿으로 사용자는 하나 이상의 에이젼시로부터 극히 시간이 중요하고 정보 생성 및 공표 시간 및 정보 중요성을 정의하는 구성 가능한 크기의 시간에 따라 분류된 정보에 액세스할 수 있게 한다.

샘플 객체 및 콘텍스트 바 시각화

1. 공개될 속보 항목의 총 개수의 배경에 걸친 가장 최근의 또는 계류 중인 속보의 발표 또는 예정된 시간을 나타내는 똑딱거리는 시계

2. 의미론적 이미지(들)에 걸친 가장 최근의 또는 계류 중인 속보의 발표 또는 예정된 시간을 나타내는 똑딱거리는 시계

3. 의미론적 이미지(들) 및 속보 항목의 총 개수의 배경에 걸친 가장 최근의 또는 계류 중인 속보의 발표 또는 예정된 시간을 나타내는 똑딱거리는 시계

4. 단순 배경에 걸친 가장 최근의 또는 계류 중인 속보의 발표 또는 예정된 시간을 나타내는 똑딱거리는 시계

5. 다양한 배경에 걸친 모든 속보 항목(순차적으로)의 발표 또는 예정된 시간을 나타내는 똑딱거리는 시계

6. 다양한 배경에 걸친 가장 최근 또는 계류 중인 속보 항목의 발표 또는 예정된 시간을 나타내는 똑딱거리는 달력

7. 다양한 배경에 걸친 모든 속보 항목(순차적으로)의 발표 또는 예정된 시간을 나타내는 똑딱거리는 달력

8. 축적 폰트 크기 - 가장 최근 또는 계류 중인 속보 항목의 발표 또는 예정된 시간에 따라

9. 축적 폰트 크기 - 속보 항목의 개수에 따라

10. 가장 최근 또는 계류 중인 속보 항목의 발표 또는 예정된 시간에 따른 애니메이션 속도를 갖는 애니메이트된 폰트 (예를 들어, 플래싱 텍스트, 회전 텍스트, 이동 경로 상의 텍스트 등)

11. 속보 항목의 수에 따른 애니메이션 속도를 갖는 애니메이트된 폰트 (예를 들어, 플래싱 텍스트, 회전 텍스트, 이동 경로 상의 텍스트 등)

12. 가변 폰트 색 - 가장 최근 또는 계류 중인 속보 항목의 발표 또는 예정된 시간에 따라

13. 가변 폰트 색 - 속보 항목의 개수에 따라

14. 속보 의미론적 이미지(들) 또는 등가물의 애니메이트된 그래픽

15. 속보 항목의 수

16. 순차적으로 애니메이트된 속보 항목의 제목 (리스트 뷰)

17. 순차적으로 애니메이트된 속보 항목의 제목 및 세부내용 (리스트 뷰)

18. 객체 주변의 궤도 운동 경로를 따라 이동하는 의미론적 이미지/모션

19. 의미론적 이미지/모션 배경 상의 항목의 수를 나타내는 풍선 팝업

20. 단순 배경을 갖지만 의미론적 이미지/모션으로 애니메이트된 항목의 수를 나타내는 풍선 팝업

헤드라인

헤드라인 콘텍스트 템플릿은 의미론적 정보를 전달하는 CNN의 "헤드라인 뉴스" 프로그램의 사적이고 디지털적인 법전에 비유될 수 있다. 콘텍스트 템플릿은 사용자로 하여금 하나 이상의 에이젼시로부터 정보 생성 및 공표 시간 및 정보 "신선함"을 정의하는 구성 가능한 크기의 시간에 따라 분류된 정보 헤드라인을 액세스할 수 있게 한다. 예를 들어, CNN "헤드라인 뉴스"는 헤드라인은 매 30분(24시간)마다 디스플레이한다. 바람직한 실시예에서, 헤드라인 콘텍스트 템플릿은 순차적으로 연결된 다음의 서브 질의를 갖는 서버 상에서 SQL 질의로서 구현될 것이다: Recommendations Published Today, Favorites Published Today, Best Bets Published Today, Upcoming Events Occurring Today 및 Tomorrow, Annotated Items Published Today.

모든 서브 질의는 발표 날짜/시간에 따라 분류되어 함께 연결된다. 부수적인 필터 가 SQML 내 선언 리스트에 기초하여 질의에 적용될 것이다.

시각화 - 스마트 모래시계, 틈새 페이지, 천이 효과, 배경 크롬 등을 위한 샘플 이미지

대화

대화 콘텍스트 템플릿은 의미론적 정보를 어떻게 전달하는가에 있어서 CNN의 "Crossfire"의 사적이고 디지털 버전에 비유될 수 있다. 대화와 토론을 정보 전파을 위한 콘텍스트로서 이용하는 "Crossfire"와 같이, 바람직한 실시예에서, 대화 콘텍스트 템플릿은 이메일 게제, 주석, 및 관련 정보를 위한 스레드를 추적한다.

대화 콘텍스트 템플릿은 다음 정보 객체 유형으로 구성된다:

1. 적어도 하나의 (이메일 메시지에 대한 이메일 응답)의 스레드 깊이의 이메일

2. 적어도 하나의 (객체의 주석의 주석)의 스레드 깊이의 주석

3. 내부 뉴스 게제 (뉴스 게제에 대한 뉴스 게제 응답)

질의는 스레드 깊이에 따라 분류되고, 부수적인 필터는 SQML내 선언 리스트에 기초하여 질의에 적용될 것이다. 또한, 콘텍스트 스킨은 스레드에 의해 정보 항목을 디스플레이하여야 한다.

시각화 - 스마트 모래시계, 틈새 페이지, 천이 효과, 배경 크롬 등을 위한 샘플 이미지

샘플 객체 및 콘텍스트 바 시각화

1. 의미론적 이미지/모션의 애니메이트된 그래픽(아이콘 및 콘텍스트 가이드 뷰)

2. 단순 배경 위의 최대 스레드 깊이 (아이콘 및 콘텍스트 가이드 뷰)

3. 의미론적 이미지/모션 위의 최대 스레드 깊이 (아이콘 및 콘텍스트 가이드 뷰)

4. 순서적으로 애니메이트된 대화의 제목 (리스트 뷰)

5. 순서적으로 애니메이트된 대화의 제목 및 세부내용 (타일 뷰)

6. 단순 배경 위의 대화의 수 (아이콘 및 콘텍스트 가이드 뷰)

7. 의미론적 이미지/모션(들) 위의 대화의 수 (아이콘 및 콘텍스트 가이드 뷰)

뉴스메이커

뉴스메이커 콘텍스트 템플릿은 의미론적 정보를 어떻게 전달하는가에 있어서 NBC의 "Meet the Press" 프로그램의 사적이고 디지털 버전에 비유될 수 있다. 이 경우, 뉴스 자체 또는 대화와는 반대로 "뉴스의 사람들"이 강조되어야 한다. 사용자들은 사람을 정보 객체 피봇으로 사용하여 네트워크를 네비게이트한다. 뉴스메이커 콘텍스트 템플릿은 바람직하게 "사람들" 또는 '사용자들" 객체 유형 필터 및 "에 의해 주관되고", "가능하게 ... 에 의해 저작되고", "에 의해 주최되고", "에 의해 주석되고", ".. 전문가" 등 선언) (사람을 정보에 연관시미)을 갖는 헤드라인 콘텍스트 템플릿으로 간주될 수 있다. 바람직하게, "관련된" 디폴트 선언은 모든 특정한 선언을 전달하는데 사용된다. 관련 정보, 즉 뉴스메이커의 분류 순서는 "그들이 만드는 뉴스", 즉 헤드라인의 순서에 기초하여 분류된다.

질의는 헤드라인의 수에 따라 분류될 것이다. 부수적인 필터는 SQML 내 선언 리스트에 기초하여 질의에 적용될 것이다.

시각화 - 스마트 모래시계, 틈새 페이지, 천이 효과, 배경 크롬 등을 위한 샘플 이미지

샘플 객체 및 콘텍스트 바 시각화

1. 대화에서 2 대화 헤드의 애니메이트된 그래픽(아이콘 및 콘텍스트 가이드 뷰)

2. 의미론적 이미지/모션(들)의 애니메이트된 그래픽(아이콘 및 콘텍스트 가이드 뷰)

3. 뉴스메이스커의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

4. 의미론적 이미지/모션(들) 위의 뉴스메이스커의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

5. 순서적으로 애니메이트된 뉴스메이커의 제목 (리스트 뷰)

6. 순서적으로 애니메이트된 뉴스메이커의 제목 및 세부내용 (타일 뷰)

업커밍 이벤트

업커밍 이벤트 콘텍스트 템플릿(및 그 결과로 나타나는 특수 에이전트)는

공개될 이벤트에 대한 정보를 전달하는 특수 프로그램의 사적이고 디지털 버전에 비유될 수 있다. 예는 "The World Series", "The NBA Finals", "The Soccer World Cup Finals"등과 같은 이벤트를 위한 스페셜은 포함한다. 지식 노동자 시나리오에 상당하는 것은 하나 이상의 카테고리, 문서 또는 다른 정보 객체 피봇에 관한 모든 공개될 인더스트리 이벤트를 모니터하기를 위하는 사용자이다. 업커밍 이벤트 콘텍스트 템플릿은 바람직하게, (바람직하게, 이벤트 및 시간 중요성을 암시하는 의미론적으로 적당한 "콘텍스트 스킨"을 사용하여) 공개될 이벤트만이 필터링되고 디스플레이 된다는 것을 제외하고 헤드라인 콘텍스트 템플릿과 동일하다. 결과로 나타나는 객체는 바람직하게 먼저 열거되는 가장 절박한 이벤트를 갖는 시간 중요성에 기초하여 분류된다.

시각화 - 스마트 모래시계, 틈새 페이지, 천이 효과, 배경 크롬 등을 위한 샘플 이미지

샘플 객체 및 콘텍스트 바 시각화

1. 공개될 이벤트의 총 수의 배경 위의 다음 이벤트까지의 시간을 나타내는 똑딱거리는 시계 (아이콘 및 콘텍스트 가이드 뷰)

2. 의미론적 이미지/모션(들) 위의 다음 이벤트까지의 시간을 나타내는 똑딱거리는 시계 (아이콘 및 콘텍스트 가이드 뷰)

3. 의미론적 이미지/모션(들) 위 및 공개될 이벤트의 총 수 위의 다음 이벤트까지의 시간을 나타내는 똑딱거리는 시계 (아이콘 및 콘텍스트 가이드 뷰)

4. 단순 배경 위의 다음 이벤트까지의 시간을 나타내는 똑딱거리는 시계 (아이콘 및 콘텍스트 가이드 뷰)

5. 다양한 배경 위의 모든 공개될 이벤트(순차적으로)까지의 시간을 나타내는 똑딱거리는 시계 (아이콘 및 콘텍스트 가이드 뷰)

6. 다양한 배경 위의 다음 공개될 이벤트의 예정된 시간을 나타내는 달력 (아이콘 및 콘텍스트 가이드 뷰)

7. 다양한 배경 위의 모든 공개될 이벤트(순차적으로)까지의 예정된 시간을 나타내는 달력 (아이콘 및 콘텍스트 가이드 뷰)

8. 달력 모션을 나타내는 애니메이트된 그래픽 (아이콘 및 콘텍스트 가이드 뷰)

9. 의미론적 이미지/모션(들) (예를 들어, 스케줄 북)의 애니메이트된 그래픽 (아이콘 및 콘텍스트 가이드 뷰)

10. 의미론적 이미지/모션(들)의 공개될 이벤트의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

11. 단순 배경 위의 공개될 이벤트의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

12. 순차적으로 애니메이트된 공개될 이벤트의 제목 (리스트 뷰)

13. 순차적으로 애니메이트된 공개될 이벤트의 제목 및 세부내용 (타일 뷰

디스커버리

디스커버리 콘텍스트 템플릿은 "Discovery Channel"의 사적이고 디지털 버전에 비유될 수 있다. 이 경우, 특정 주제에 대한 "다큐멘터리"에 강조를 두어야 한다. 디스커버리 콘텍스트 템플릿은, 소정 세트의 카테고리에 관련되고 선택적으로 선정되고 구성가능한 시간 기간 내에 게시되는 정보 객체를 랜덤하게 선택하므로서 지적인 정보의 집합을 시뮬레이션한다. 시간에 반대되는 의미론적인 가중치는 정보가 어떻게 주문되거나 제시될지를 판단하기 위한 바람직한 고려이다. 이 콘텍스트 템플릿은 카테고리화 선언을 위한 의미론적 링크 강조에 의해 모든 정보 유형을 필터 링하므로서 구현될 수 있다. 이 경우, 필터는 "Best Bets의 필터"미만이어야 하는데, 콘텍스트 템플릿은 필터링 면에서 "Best Bets"와 "All Items' 사이에 놓인다.

시각화 - 스마트 모래시계, 틈새 페이지, 천이 효과, 배경 크롬 등을 위한 샘플 이미지

샘플 객체 및 콘텍스트 바 시각화

1. 의미론적 이미지/모션(들)의 애니메이트된 그래픽 (예를 들어, 망원경, 항해 우주선, 바다에서 옛날)

2. 순차적인 애니메이션으로의 제1 N 정보 항목의 제목 (타일 )

3. 순차적인 애니메이션으로의 제1 N 정보 항목의 제목 및 세부내용 (리스트 뷰)

4. 의미론적 이미지/모션(들) 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

5. 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

히스토리

히스토리 콘텍스트 템플릿은 "History Channel"의 사적인 디지털 버전에 비유될 수 있다. 이 경우, 특정 주제에 대해서 뿐만 아니라 역사 콘텍스트에 대한 전파 정보에 강조를 두어야 한다. 이 템플릿을 위해, 바람직한 방법은 카테고리 및 시간이다. 히스토리 콘텍스트 템플릿 "최소 연령 제한"에 일치하여 디스커버리 콘텍스트 템플릿과 유사하다. 파라메타는 바람직하게 "최대 연령 제한" 파라메타가 "최소 연령 제한" 파라메타 (또는 선택적인 "히스토리 시간" 파라메타)로 교체된다는 것을 제외하고는 디스커버리 콘텍스트 템플릿과 동일하다. 또한, 반환된 객체는 바람직하게 시스템의 연령 또는 생성 이래의 연령에 기초하여 역으로 또는 랜덤하게 분류된다.

시각화 - 스마트 모래시계, 틈새 페이지, 천이 효과, 배경 크롬 등을 위한 샘플 이미지

시각화 - 샘플 객체 및 콘텍스트 바 애니메이션

1. 의미론적 이미지/모션(들) 또는 그 등가물의 애니메이트된 그래픽

2. 순차적인 애니메이션으로의 가장 오래된 (또는 랜덤) N 정보 항목의 제목 (리스트 뷰)

3. 순차적인 애니메이션으로의 가장 오래된 (또는 랜덤) N 정보 항목의 제목 및 세부내용 (파일 뷰)

4. 의미론적 이미지/모션(들) 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

5. 단순 배경 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

모든 항목

올 항목 콘텍스트 템플릿은, 의미론, 또는 키 워드 또는 텍스트 기준 검색에 기초하여 관련된 임의의 정보를 반환하는 콘텍스트를 나타낸다. 이 경우, 콘텍스트에 원격으로 관련될 수 있는 전파 정보에 강조를 두어야 한다. 올 항목 콘텍스트 템플릿에 대한 주 축은 바람직하게 단지 관련의 가능성이다. 바람직한 실시예에서, 올 항목 콘텍스트 템플릿은 관련 있을 수 있는 가능한 방송 결과를 반환하기 위해 의미론 및 텍스트 기준 질의 모두를 이용한다.

시각화 - 스마트 모래시계, 틈새 페이지, 천이 효과, 배경 크롬 등을 위한 샘플 이미지

시각화 - 샘플 객체 및 콘텍스트 바 애니메이션

1. 의미론적 이미지/모션(들) 또는 그 등가물의 애니메이트된 그래픽

2. 순차적인 애니메이션으로의 가장 최근의 N 정보 항목의 제목 (리스트 뷰)

3. 순차적인 애니메이션으로의 가장 최근의 N 정보 항목의 제목 및 세부내용 (타일 뷰)

4. 의미론적 이미지/모션(들) 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

5. 단순 배경 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

베스트 벳츠(Best Bets)

베스트 벳츠 콘텍스트 템플릿(및 그의 결과로 나타나는 스페셜 에이전트)는 단지 극히 관련 있는 정보만을 반환하는 콘텍스트를 나타낸다. 바람직한 실시예에서, 극히 관련이 있으며 의미론적으로 중요한 것으로 간주되는 전파 정보에 강조하여야 한다. 이와 같은 콘텍스트 템플릿을 위해, 주 축은 관련성이다. 필수적으로, 베스트 벳츠 콘텍스트 템플릿은 의미론적 질의를 이용하며, 텍스트 기준 질의 결과의 관련성을 보장할 수 없기 때문에 텍스트 기준 질의를 이용하지 않을 것이다. 베스트 벳츠 콘텍스트 템플릿은 바람직하게 카테고리 필터 또는 키워드로서 초기화된다. 만일 키워드가 특정되면, 서버는 카테고리화를 동적으로 수행한다. 결과는, 바람직하게 관련성 점수 또는 객체에서 카테고리 필터까지의 "카테고리에의 소속" 의미적 링크의 강도에 기초하여 분류된다.

시각화 - 스마트 모래시계, 틈새 페이지, 천이 효과, 배경 크롬 등을 위한 샘플 이 미지

시각화 - 샘플 객체 및 콘텍스트 바 애니메이션

1. 의미론적 이미지/모션(들) 또는 그 등가물의 애니메이트된 그래픽

2. 순차적인 애니메이션으로의 가장 최근의 N 정보 항목의 제목 (리스트 뷰)

3. 순차적인 애니메이션으로의 가장 최근의 N 정보 항목의 제목 및 세부내용 (타일 뷰)

4. 의미론적 이미지/모션(들) 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

5. 단순 배경 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

페이보릿츠(Favorites)

페이보릿츠 콘텍스트 템플릿(및 그의 결과로 나타나는 스페셜 에이전트)는 "즐겨찾는" 또는 "인기있는" 정보를 반환하는 콘텍스트를 나타낸다. 이 경우, 다른 사람들에 의해 승인되고 우호적으로 승인된 정보를 전파하는 것을 강조하여야 한다. 바람직한 실시예에서, 페이보릿cm 콘텍스트 템플릿을 위한 축은 독자의 관심 레벨, 수신된 객체의 "검토" 및 객체 상의 주석 스레드의 깊이를 포함한다. 한 실시예에서, 페이보릿츠 콘텍스트 템플릿은 "즐겨찾는" 의미적 링크를 갖는 정보만을 반환하고, (의미론적 링크에 기초한) 객체를 위한 "투표"의 수를 카운트하므로서 분류된다.

시각화 - 스마트 모래시계, 틈새 페이지, 천이 효과, 배경 크롬 등을 위한 샘플 이미지

시각화 - 샘플 객체 및 콘텍스트 바 애니메이션

1. 의미론적 이미지/모션(들) 또는 그 등가물의 애니메이트된 그래픽

2. 순차적인 애니메이션으로의 가장 최근의 N 정보 항목의 제목 (리스트 뷰)

3. 순차적인 애니메이션으로의 가장 최근의 N 정보 항목의 제목 및 세부내용 (타일 뷰)

4. 의미론적 이미지/모션(들) 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

5. 단순 배경 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

클래식스

클래식스 콘텍스트 템플릿(및 그의 결과로 나타나는 스페셜 에이전트)는 "클라식컬" 정보 또는 인식된 값의 유형인 정보를 반환하는 콘텍스트를 나타낸다. 페이보릿츠 콘텍스트 템플릿과 유사하게, 다른 사람들에 의해 승인되고 우호적으로 승인된 정보를 전파하는 것을 강조하여야 한다. 이 콘텍스트 템플릿을 위해, 바람직한 축은 역사적 콘텍스트, 독자의 관심 레벨, 수신된 객체의 "검토" 및 객체 상의 주석 스레드의 깊이를 포함한다. 클래식스 콘텍스트 템플릿은 바람직하게 페이보릿츠 콘텍스트 템플릿 그러나, 최소 연령 제한 필터와 투표 점수를 갖는 것에 기초하여 구현되어, 필연적으로 "올드 페이보릿츠" 콘텍스트 템플릿으로서 기능한다.

시각화 - 스마트 모래시계, 틈새 페이지, 천이 효과, 배경 크롬 등을 위한 샘플 이미지

시각화 - 샘플 객체 및 콘텍스트 바 애니메이션

1. 의미론적 이미지/모션(들) 또는 그 등가물의 애니메이트된 그래픽

2. 순차적인 애니메이션으로의 가장 최근의 N 정보 항목의 제목 (리스트 뷰)

3. 순차적인 애니메이션으로의 가장 최근의 N 정보 항목의 제목 및 세부내용 (타일 뷰)

4. 의미론적 이미지/모션(들) 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

5. 단순 배경 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

레커멘데이션즈(Recommendations)

레커멘데이션즈 콘텍스트 템플릿은 "권장된" 정보, 또는 에이젼시가 사용자들에게 관심있을 것이라고 언급한 정보를 반환하는 콘텍스트를 나타낸다. 레커멘데이션즈 콘텍스트 템플릿은 "권장" 의미론적 링크를 "시멘틱링크스" 테이블에 부가하고 사용자가 가리키는 즐겨찾는 의미론적 링크를 조사함으로서 삽입된다. 레커멘데이션즈 콘텍스트 템플릿은 바람직하게 기계 학습 및 협동 필터링과 같은 기법을 사용하여 만들어진다. 이 콘텍스트 템플릿에서는 사용자에게 관심있지만, 사용자가 이미 보았을 전파 정보를 강조하여야 한다. 이 콘텍스트 템플릿을 위해, 주요 축은 관심의 유사성 및 신선함을 포함한다.

시각화 - 스마트 모래시계, 틈새 페이지, 천이 효과, 배경 크롬 등을 위한 샘플 이미지

시각화 - 샘플 객체 및 콘텍스트 바 애니메이션

1. 의미론적 이미지/모션(들) 또는 그 등가물의 애니메이트된 그래픽

2. 순차적인 애니메이션으로의 가장 최근의 N 정보 항목의 제목 (리스트 뷰)

3. 순차적인 애니메이션으로의 가장 최근의 N 정보 항목의 제목 및 세부내용 (타일 뷰)

4. 의미론적 이미지/모션(들) 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

5. 단순 배경 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

투데이

투데이 콘텍스트 템플릿은 "오늘" (이벤트의 경우) 게시되거나 유지하는 정보를 반환하는 콘텍스트를 나타낸다. 이 콘텍스트 템플릿에서는, 바람직하게 신선함을 판단하기 위해 필터인 "오늘"에 기초하여 현재인 것으로 간주되는 정보를 전파하는 것에 강조를 둔다.

시각화 - 스마트 모래시계, 틈새 페이지, 천이 효과, 배경 크롬 등을 위한 샘플 이미지

시각화 - 샘플 객체 및 콘텍스트 바 애니메이션

1. 의미론적 이미지/모션(들) 또는 그 등가물의 애니메이트된 그래픽

2. 순차적인 애니메이션으로의 가장 최근의 N 정보 항목의 제목 (리스트 뷰)

3. 순차적인 애니메이션으로의 가장 최근의 N 정보 항목의 제목 및 세부내용 (타일 뷰)

4. 의미론적 이미지/모션(들) 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

5. 단순 배경 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

주석달린 항목(Annotated Items)

주석달린 항목 콘텍스트 템플릿은 주석된 정보를 반환하는 콘텍스트를 나타낸다. 이 콘텍스트 템플릿에서는, 한명 이상의 사용자가 주석달린 항목을 가지고 있다는 사실에 기초하여 중요한 것으로 간주되는 정보를 전파하는 것에 강조를 둔다.

시각화 - 스마트 모래시계, 틈새 페이지, 천이 효과, 배경 크롬 등을 위한 샘플 이미지

시각화 - 샘플 객체 및 콘텍스트 바 애니메이션

1. 의미론적 이미지/모션(들) 또는 그 등가물의 애니메이트된 그래픽

2. 순차적인 애니메이션으로의 가장 최근의 N 정보 항목의 제목 (리스트 뷰)

3. 순차적인 애니메이션으로의 가장 최근의 N 정보 항목의 제목 및 세부내용 (타일 뷰)

4. 의미론적 이미지/모션(들) 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

5. 단순 배경 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

주석(Annotations)

주석 콘텍스트 템플릿은 주석된 정보를 반환하는 콘텍스트를 나타낸다. 이 콘텍스트 템플릿에서는, 주석달린 정보를 전파하는 것에 강조를 둔다.

시각화 - 스마트 모래시계, 틈새 페이지, 천이 효과, 배경 크롬 등을 위한 샘플 이미지

시각화 - 샘플 객체 및 콘텍스트 바 애니메이션

1. 의미론적 이미지/모션(들) 또는 그 등가물의 애니메이트된 그래픽

2. 순차적인 애니메이션으로의 가장 최근의 N 정보 항목의 제목 (리스트 뷰)

3. 순차적인 애니메이션으로의 가장 최근의 N 정보 항목의 제목 및 세부내용 (타일 뷰)

4. 의미론적 이미지/모션(들) 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

5. 단순 배경 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

전문가(Experts)

시각화 - 스마트 모래시계, 틈새 페이지, 천이 효과, 배경 크롬 등을 위한 샘플 이미지

시각화 - 샘플 객체 및 콘텍스트 바 애니메이션

1. 의미론적 이미지/모션(들) 또는 그 등가물의 애니메이트된 그래픽

2. 순차적인 애니메이션으로의 가장 최근의 N 정보 항목의 제목 (리스트 뷰)

3. 순차적인 애니메이션으로의 가장 최근의 N 정보 항목의 제목 및 세부내용 (타일 뷰)

4. 의미론적 이미지/모션(들) 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

5. 단순 배경 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

장소(Places)

시각화 - 스마트 모래시계, 틈새 페이지, 천이 효과, 배경 크롬 등을 위한 샘플 이미지

시각화 - 샘플 객체 및 콘텍스트 바 애니메이션

1. 의미론적 이미지/모션(들) 또는 그 등가물의 애니메이트된 그래픽

2. 순차적인 애니메이션으로의 가장 최근의 N 정보 항목의 제목 (리스트 뷰)

3. 순차적인 애니메이션으로의 가장 최근의 N 정보 항목의 제목 및 세부내용 (타일 뷰)

4. 의미론적 이미지/모션(들) 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

5. 단순 배경 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

4. 시각화 - 블렌더스

블렌더스(Blenders)

시각화 - 스마트 모래시계, 틈새 페이지, 천이 효과, 배경 크롬 등을 위한 샘플 이미지

시각화 - 샘플 아이콘 애니메이션

1. 의미론적 이미지/모션(들) 또는 그 등가물의 애니메이트된 그래픽

2. 액션에 있어서의 블렌더 또는 믹서의 애니메이트된 그래픽

3. 순차적인 애니메이션으로의 블렌더 항목의 제목 (리스트 뷰)

4. 순차적인 애니메이션으로의 블렌더 항목의 제목 및 세부내용 (타일 뷰)

5. 의미론적 이미지/모션(들) 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

6. 단순 배경 위의 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

5. 정보 객체 유형

문서

책

잡지

프리젠테이션

이력서

스프레드쉬트

텍스트

웹 페이지

화이트 페이퍼

이메일

이메일 주석

이메일 분배 리스트

이벤트

미팅

멀티미디어

온라인 코스

사람

고객

사용자

6. 프리젠테이션 스킨 유형

타임라인(Timeline)

시각화 - 스마트 모래시계, 틈새 페이지, 천이 효과, 배경 크롬 등을 위한 샘플 이미지

시각화 - 샘플 객체 및 콘텍스트 바 애니메이션

1. 단순 배경 위의 정보의 유효 시간 (공개 시간, 예정 시간 등)을 나타내는 달력 (아이콘 및 콘텍스트 가이드 뷰)

2. 단순 배경 위의 모든 정보 항목 (순차적으로)의 유효 시간을 나타내는 달력 (아이콘 및 콘텍스트 가이드 뷰)

3. 달력 모션을 나타내는 애니메이트된 그래픽 (아이콘 및 콘텍스트 가이드 뷰)

4. 의미론적 이미지/모션(들) (예를 들어, 시간 워프 이미지/모션)의 애니메이트된 그래픽 (아이콘 및 콘텍스트 가이드 뷰)

5. 의미론적 이미지/모션(들) 위의 정보 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

6. 단순 배경 위의 정보 항목의 총 수 (아이콘 및 콘텍스트 가이드 뷰)

7. 순차적으로 애니메이트된 정보 항목의 제목 (리스트 뷰)

7. 순차적으로 애니메이트된 정보 항목의 제목 및 세부내용 (타일 뷰)

8. 항목들이 유효 날짜/시간에 기초하여 밀집된 채 선형 스케줄 제어를 스크롤하기

9. 유효 날짜/시간에 의해 분류된 애니메이트된 타임라인 시계 제어

의미론적 실행시간에 대한

클라이언트 제어 API 규격

정보 신경망 시스템에 있어서의 클라이언트측 실행시간 제어

API

저자: Nosa Omoigui

1. Nervana 의미론적 실행시간 제어에 대한 개요

의미론적 실행시간 제어의 개관

서론

Nervana 의미론 실행시간 제어는 Nervana 의미론의 사용자 경험을 바탕으로 의미론적 데이터를 표시하는데 이용되는 속성과 방법을 나타내는 ActiveX이다. 이제어는, Nervana 의미론에 대한 사용자 경험 요건에 따라, (SRML 스키마를 이용하여) XML 데이터를 입수하여 DHTML+TIME 또는 SVG 출력으로서 배출하는 XSLT 스킨으로부터 주로 호출된다. 특히, Nervana 제어는 상부에 XSLT 스킨이 위치하는 "SDK"를 포괄하여, 의미론적 내용에 의해 발생하는 사용자 경험을 창출하도록 한다.

2. Nervana 의미론적 실행시간 제어 API

EnumObjectsInNamespacePath

서론

EnumObjectsInNamespacePath 방법에서는 이름공간 경로(namespace path)에 있는 객체를 반환한다.

사용 시나리오(usage scenario)

Nervana 클라이언트 어플리케이션(가령, 시맨틱 브라우저) 또는 Nervana 스킨은, 사용자가 시맨틱 브라우저으로부터 이름공간을 네이비게이트할 수 있도록 이 방법을 호출하여 이름공간 경로를 오픈한다.

프로토타입(prototype)

CompileSemanticQueryFromBuffer

서론

CompileSemanticQueryFromBuffer 방법은 SQML 버퍼를 오픈하여 하나 이상의 실행준 비된 SQML 버퍼로 컴파일한다. 가령, 혼합기(blender)를 포함하고 있는 SQML 파일은, 각 혼합기 입력내용을 표시하는 SQML 버퍼 내로 컴파일될 것이다. 만일 상기 혼합기가 다수의 혼합기들을 포함하고 있다면, 이들 혼합기들은 개봉될 것이고, SQML 버퍼는 각 포함된 혼합기로 반환될 것이다. 컴파일된 또는 "실행준비된" SQML 버퍼는, 에이전트(agency)에 의해 의미론적으로 처리될 수 있다. 그 의미는 다수의 에이전트를 갖는 혼합기가 각 에이전트로부터의 적절한 SQML을 갖는 버퍼로 컴파일된 SQML을 가질 수 있다는 것이다.

주: 버퍼가 이미 컴파일되어 있다면, 본 방법은 S_FALSE로서 응답하고, 응답인자는 무시된다.

사용 시나리오

Nervana 클라이언트 어플리케이션(가령, 시맨틱 브라우저) 또는 Nervana 스킨은, SQML 버퍼를 컴파일하고 즉시 실행할 수 있도록 생성된 "컴파일된 코드"를 검색하기 위하여 본 방법을 호출한다. 통상적인 방안으로서, 상기 어플리케이션 또는 스킨은 SQML 버퍼를 컴파일하고 다음에 각 개별 SQML 질의가 위치하는 프레임 윈도우를 준비한다. 그러고 나서, CompileSemanticQueryFromBuffer를 호출함으로써 각 SQML 의미론 호출명령을 내려서 개별 프레임에 그 결과를 표시하도록 할 수 있다.

프로토타입

OpenSemanticQueryFromBuffer

서론

OpenSemanticQueryFromBuffer 방식은 SQML 버퍼를 오픈하여 XML 결과를 (SRML 형식으로) DOM으로 비동기적으로 보낸다. 이 때부터 Nervana 스킨은 상기 처리를 싱크(sink)시킨다. 주: SQML 버퍼는 "컴파일"되어서 실행준비되어야 한다. SQML 버퍼가 실행준비되지 않으면, 호출은 이루어지지 않는다. SQML 버퍼를 컴파일하기 위해서는 CompileSemanticQueryFromBuffer를 호출한다.

사용 시나리오

Nervana 클라이언트 어플리케이션(가령, 시맨틱 브라우저) 또는 Nervana 스킨은, 컴파일된 SQML 버퍼를 오픈하기 위해 이 방법을 호출할 수 있다.

프로토타입

GetSemanticQueryBufferFromFile

서론

GetSemanticQueryBufferFromFile 방식은 SQML 파일을 오픈하여 버퍼내용으로서 응답한다. 이로써 버퍼는 컴파일 및/또는 오픈될 수 있다.

사용 시나리오

Nervana 클라이언트 어플리케이션(가령, 시맨틱 브라우저) 또는 Nervana 스킨은, SQML 파일을 그 처리 전에 버퍼 내로 변환시키기 위하여 상기 방식을 호출한다.

프로토타입

GetSemanticQueryBufferFromNamespace

서론

GetSemanticQueryBufferFromNamespace 방식은 이름공간 객체를 오픈하고 그 SQML 버퍼를 검색한다.

사용 시나리오

Nervana 클라이언트 어플리케이션(가령, 시맨틱 브라우저) 또는 Nervana 스킨은, ID 및 이름공간 객체의 경로에 이미 악세스했을 때에 SQML 버퍼를 오픈하기 위하여 상기 방식을 호출한다.

프로토타입

GetSemanticQueryBufferFromURL

서론

GetSemanticQueryBufferFromURL 방식은 SQML 버퍼에 있는 URL을 포장(wrap)하여 그 버퍼로서 응답한다.

사용 시나리오

Nervana 클라이언트 어플리케이션(가령, 시맨틱 브라우저) 또는 Nervana 스킨은, 임의 유형 SQML의 URL을 변환하기 위하여 이 방식을 호출한다. 이 URL에는 파일경로, HTTP URL, FTP URL, "wsobject://"로 시작하는 Nervana 에이전트 객체 URL, "wsagency://"로 시작하는 Nervana 에이전트 URL이 포함될 수 있다.

프로토타입

GetSemanticQueryBufferFromClipboard

서론

GetSemanticQueryBufferFromClipboard 방식은 클립보드 내용을 SQML로 변환하여 이 버퍼로서 응답한다.

사용 시나리오

Nervana 클라이언트 어플리케이션(가령, 시맨틱 브라우저) 또는 Nervana 스킨은, 클립보드로부터 의미론적 질의를 얻기 위하여 이 방식을 호출한다. 그리고 어플리케이션은 질의 버퍼에 적재할 수 있다.

프로토타입

Stop

서론

Stop 방식은 현재 오픈되어 있는 요청을 정지시킨다.

사용 시나리오

Nervana 클라이언트 어플리케이션(가령, 시맨틱 브라우저) 또는 Nervana 스킨은, 방금 막 발생된 적재 요청을 정지시키기 위하여 상기 방식을 호출한다.

프로토타입

Refresh

서론

Refresh 방식은 현재 오픈되어 있는 요청을 리프레시한다.

사용 시나리오

Nervana 클라이언트 어플리케이션(가령, 시맨틱 브라우저) 또는 Nervana 스킨은, 현재 적재된 요청을 리프레시하기 위하여 상기 방식을 호출한다.

프로토타입

CreateNamespaceObject

서론

CreateNamespaceObject 방식은 이름공간 객체를 생성하여 그 GUID로서 응답한다.

사용 시나리오

Nervana 클라이언트 어플리케이션(가령, 시맨틱 브라우저) 또는 Nervana 스킨은 일 반적으로, 새로운 질의 문서가 오픈되었을 때 임시 이름공간 객체를 생성하기 위하여 상기 방식을 호출한다.

프로토타입

DeleteNamespaceObject

개요

DeleteNamespaceObject 방식은 이름공간 객체를 삭제한다.

사용 시나리오

Nervana 클라이언트 어플리케이션(가령, 시맨틱 브라우저) 또는 Nervana 스킨은, 일시적 이름공간 객체를 삭제하기 위하여 상기 방식을 호출한다.

프로토타입

CopyObject

개요

CopyObject 방식은 적절한 SQML 클립보드 형식을 이용하여 의미론적 개체를 SQML 버퍼로서의 클립보드에 복사한다. 이 객체는 관련된 의미론적 질의를 담당하는 에이전트에게 전달되거나, 다른 객체 또는 에이전트에 대한 렌즈로서 사용될 수 있다.

사용 시나리오

Nervana 스킨은 일반적으로, 사용자가 객체의 팝업 메뉴에서 "Copy" 메뉴를 클릭할 때 상기 방식을 호출한다.

프로토타입

CanObjectBeAnnotated

개요

CanObjectBeAnnotated 방식은 주어진 객체에 주석(annotate)될 수 있는지를 체크한다.

사용 시나리오

Nervana 스킨은 일반적으로 "Annotate" 명령을 나타내는 UI를 표시할지 여부를 결정하기 위하여 상기 방식을 호출한다.

프로토타입

AnnotateObject

개요

AnnotateObject 방식은 현재 설치된 이메일 클라이언트를 불러서, 객체가 전달된 이메일 에이전트에게 해당 객체의 이메일 annotation을 전송시킨다.

사용 시나리오

Nervana 스킨은 일반적으로, 사용자가 객체의 팝업 메뉴에서 "Annotate" 메뉴를 클릭할 때 상기 방식을 호출한다.

프로토타입

CanObjectBePublished

개요

CanObjectBePublished 방식은 주어진 객체가 발행될 수 있는지 체크한다.

사용 시나리오

Nervana 스킨은 일반적으로, "Publish" 명령을 나타내는 UI를 표시할지 여부를 결정하기 위하여 상기 방식을 호출한다.

프로토타입

PublishObject

개요

PublishObject 방식은 현재 설치된 이메일 클라이언트를 불러서 객체가 전달된 이메일 에이전트에게 해당 객체의 이메일 publication을 전송시킨다.

사용 시나리오

Nervana 스킨은 일반적으로, 사용자가 객체의 팝업 메뉴에서 "Publish" 메뉴를 클릭할 때 상기 방식을 호출한다.

프로토타입

OpenObjectContents

개요

OpenObjectContents 방식은 적절한 뷰어를 이용하여 객체를 오픈한다. 가령, 이메 일 객체는 이메일 클라이언트로 오프하고, 문서는 브라우저로 오픈한다.

사용 시나리오

Nervana 스킨은 일반적으로, 사용자가 객체의 팝업 메뉴에서 "Open" 메뉴를 클릭할 때 상기 방식을 호출한다.

프로토타입

SendEmailToPersonObject

개요

SendEmailToPersonObject 방식은 이메일을 개인이나 고객 객체에게 전송하기 위하여 호출된다. 이 방식은 이메일 클라이언트를 호출하여 개인 또는 고객 객체의 이메일 주소와 함께 전송한다.

사용 시나리오

Nervana 스킨은 일반적으로, 사용자가 개인 또는 고객 객체의 팝업 메뉴에서 "Send Email" 메뉴를 클릭할 때 상기 방식을 호출한다.

프로토타입

GetObjectAnnotations

개요

GetObjectAnnotations 방식은, 객체가 에이전트에 대해서 갖고 있는 주석을, 그 시점부터 호출된다.

사용 시나리오

Nervana 스킨은 일반적으로, 객체가 갖고 있는 주석의 명칭을 표시할 경우에, 가령, 팝업메뉴에서 또는 윈도우의 주석 메타데이터를 표시하고자 할 경우에, 상기 방식을 호출한다.

프로토타입

IsObjectMarkedAsFavorite

개요

IsObjectMarkedAsFavorite 방식은 객체가 에이전트가 선호하는 것으로 지정된 경우에, 그 시점부터 호출된다.

사용 시나리오

Nervana 스킨은 일반적으로, UI가 "Mark as Favorite" 또는 "Unmark as Favorite" 명령어를 표시할 것을 결정하기 위하여 상기 방식을 호출한다. 만일 객체가 선호사항으로서 지정될 수 없다면 (가령, 에이전트가 지정하지 않았다면), E_INVALDARG의 에러코드를 응답한다.

프로토타입

MarkObjectAsFavorite

개요

MarkObjectAsFavorite 방식은 에이전트측에 객체를 선호사항으로서 지정하기 위하여 그시점부터 호출된다.

사용 시나리오

Nervana 스킨은 일반적으로 "Mark as Favorite" 명령어를 사용자가 클릭할 때 상기 방식을 호출한다.

프로토타입

UnmarkObjectAsFavorite

개요

UnmarkObjectAsFavorite 방식은 에이전트측에 객체를 선호사항으로서 지정해제하기 위하여 그 시점부터 호출된다.

사용 시나리오

Nervana 스킨은 일반적으로 사용자가 "Unmark as Favorite" 명령어를 클릭할 때 상기 방식을 호출한다.

프로토타입

IsSmartAgentOnClipboard

개요

IsSmartAgentOnClipboard 방식은 스마트에이전트가 클립보드에 복사되었는지 여부를 체크할 때호출된다.

사용 시나리오

Nervana 스킨은 일반적으로 UI에서 "Paste" 아이콘을 표시하거나 "Paste"명령을 불러올 때에 상기 방식을 호출한다.

프로토타입

GetSmartLensQueryBuffer

개요

GetSmartLensQueryBuffer 방식은 스마트렌즈의 질의 버퍼를 얻기 위하여 호출된다. 이 방식은, 클립보드에 있는 스마트에이전트에 대한 객체 및 주어진 객체에 의미론적으로 적합한 객체를 나타내는 질의 SQML을 응답한다.

사용 시나리오

Nervana 스킨은 일반적으로 사용자가 "Paste as Smart Lens"를 선택하여 클립보드에 있는 스마트에이전트로부터 스마트렌즈를 불러올 경우에 상기 방식을 호출한다.

프로토타입

OpenObjectContents

개요

상기 방식은 적합한 뷰어를 이용하여 객체를 오픈한다. 가령, 이메일 클라이언트에서는 이메일 객체가 오픈되고, 문서는 브라우저에서 오픈된다.

사용 시나리오

Nervana 스킨은 일반적으로, 사용자가 객체상의 팝업메뉴에서 "Open" 메뉴를 클릭할 때에 상기 방식을 호출한다.

프로토타입

3. 이메일 제어 API

Email_GetFromLinkObjects

개요

Email_GetFromLinkObjects 방식은 에이전트로부터 온 이메일객체에 대한 "From" 링크의 메타데이터를 그 시점으로부터 얻기 위하여 호출된다.

사용 시나리오

Nervana 스킨은 일반적으로, 이메일 객체로부터의 "From" 링크를 네비게이트 하거나, "from" 리스트에 있는 개인의 이름을 갖는 팝업메뉴를 표시하기 위하여 Email_GetFromLinkObjects 방식을 호출한다.

프로토타입

Email_GetToLinkObjects

개요

Email_GetToLinkObjects 방식은 에이전트로부터 온 이메일객체에 대한 "To" 링크의 메타데이터를 그 시점으로부터 얻기 위하여 호출된다.

사용 시나리오

Nervana 스킨은 일반적으로, 이메일 객체로부터의 "To" 링크를 네비게이트 하거나, "To" 리스트에 있는 개인의 이름을 갖는 팝업메뉴를 표시하기 위하여 Email_GetToLinkObjects 방식을 호출한다.

프로토타입

Email_GetCcLinkObjects

개요

Email_GetCcLinkObjects 방식은 에이전트로부터 온 이메일객체에 대한 "CC" 링크의 메타데이터를 그 시점으로부터 얻기 위하여 호출된다.

사용 시나리오

Nervana 스킨은 일반적으로, 이메일 객체로부터의 "CC" 링크를 네비게이트 하거나, "CC" 리스트에 있는 개인의 이름을 갖는 팝업메뉴를 표시하기 위하여 Email_GetToCcObjects 방식을 호출한다.

프로토타입

Email_GetBccLinkObjects

개요

Email_GetBccLinkObjects 방식은 에이전트로부터 온 이메일객체에 대한 "BCC" 링크의 메타데이터를 그 시점으로부터 얻기 위하여 호출된다.

사용 시나리오

Nervana 스킨은 일반적으로, 이메일 객체로부터의 "BCC" 링크를 네비게이트 하거나, "BCC" 리스트에 있는 개인의 이름을 갖는 팝업메뉴를 표시하기 위하여 Email_GetToLinkObjects 방식을 호출한다.

Email_GetToCcObjects 방식을 호출한다.

프로토타입

Email_GetAttachmentLinkObjects

개요

Email_GetAttachmentLinkObjects 방식은 에이전트로부터 온 이메일객체에 대한 "Attachment" 링크의 메타데이터를 그 시점으로부터 얻기 위하여 호출된다.

사용 시나리오

Nervana 스킨은 일반적으로, 이메일 객체로부터의 "Attachment" 링크를 네비게이트 하거나, "Attachment" 리스트에 있는 개인의 이름을 갖는 팝업메뉴를 표시하기 위하여 Email_GetAttachmentLinkObjects 방식을 호출한다.

프로토타입

3. 개인 제어 API

Person_GetDirectReports

개요

Person_GetDirectReports 방식은 에이전트로부터 온 개인객체에 대한 "Direct Reports" 링크의 메타데이터를 그 시점으로부터 얻기 위하여 호출된다.

사용 시나리오

Nervana 스킨은 일반적으로, 개인 객체로부터의 "Direct Reports" 링크를 네비게이트 하거나, "Direct Reports" 리스트에 있는 direct reports의 이름을 갖는 팝업메뉴를 표시하기 위하여 상기 방식을 호출한다.

프로토타입

Person_GetDistributionLists

개요

Person_GetDistributionLists 방식은 에이전트로부터 온 개인객체에 대한 "Member of Distribution Lists" 링크의 메타데이터를 그 시점으로부터 얻기 위하여 호출된다.

사용 시나리오

Nervana 스킨은 일반적으로, 개인 객체로부터의 "Member of Distribution Lists" 링크를 네비게이트하거나, 개인이 멤버로 되어 있는 Distribution List의 이름을 갖는 팝업메뉴를 표시하기 위하여 상기 방식을 호출한다.

프로토타입

Person_GetInfoAuthored

개요

Person_GetInfoAuthored 방식은 에이전트로부터 온 개인객체에 대한 "Info Authored by Person" 링크의 메타데이터를 그 시점으로부터 얻기 위하여 호출된다.

사용 시나리오

Nervana 스킨은 일반적으로, 개인 객체로부터의 "Info Authored by Person" 링크를 네비게이트하거나, 권한있는 개인에 대한 시간에 좌우된 또는 최근의 정보를 갖는 미리보기 윈도우를 표시하기 위하여 상기 방식을 호출한다.

프로토타입

Person_GetInfoAnnotated

개요

Person_GetInfoAnnotated 방식은 에이전트로부터 온 개인객체에 대한 "Info Annotated by Person" 링크의 메타데이터를 그 시점으로부터 얻기 위하여 호출된다.

사용 시나리오

Nervana 스킨은 일반적으로, 개인 객체로부터의 "Info Annotated by Person" 링크를 네비게이트하거나, 주석있는 개인에 대한 시간에 좌우된 또는 최근의 정보를 갖는 미리보기 윈도우를 표시하기 위하여 상기 방식을 호출한다.

프로토타입

Person_GetAnnotationsPosted

개요

Person_GetAnnotationsPosted 방식은 에이전트로부터 온 개인객체에 대한 "Annotations Posted by Person" 링크의 메타데이터를 그 시점으로부터 얻기 위하여 호출된다.

사용 시나리오

Nervana 스킨은 일반적으로, 개인 객체로부터의 "Annotation Posted by Person" 링크를 네비게이트하거나, 개인이 발송한 시간에 좌우된 또는 최근의 주석을 갖는 미리보기 윈도우를 표시하기 위하여 상기 방식을 호출한다.

프로토타입

Person_SendEmailTo

개요

Person_SendEmailTo 방식은 개인 또는 고객 객체로 이메일을 전송할 때 호출된다. 상기 방식은 이메일 클라이언트를 오픈하여 개인 또는 고객 객체의 이메일주소와 함께 발송한다.

사용 시나리오

Nervana 스킨은 일반적으로, 사용자가 개인 또는 고객 객체의 팝업메뉴에서 "Send Email" 메뉴를 클릭할 때에 상기 방식을 호출한다.

프로토타입

3. 시스템 제어 이벤트(events)

Event:OnBeforeQuery

개요

OnBeforeQuery 이벤트는 현재의 의미 요청에 일치하는 자원들에 대해 질의를 하기 전에 촉발된다.

사용 시나리오

Nervana 클라이언트 어플리케이션(가령, 시맨틱 브라우저) 또는 Nervana 스킨은, 질의를 취소하거나 질의를 발하기 전에 질의를 캐시상태를 원할 경우에 상기 이벤트를 싱크시킨다.

프로토타입

Event:OnQueryBegin

개요

OnQueryBegin 이벤트는 현재의 의미 요청에 일치하는 자원에 대해 최초로 질의를할 때에 촉발된다.

사용 시나리오

Nervana 클라이언트 어플리케이션(가령, 시맨틱 브라우저) 또는 Nervana 스킨은, 질의 진행 중에 캐시상태를 원할 경우에 상기 이벤트를 싱크시킨다.

프로토타입

Event:OnQueryComplete

개요

OnQueryComplete 이벤트는 현재의 의미 요청에 일치하는 자원들에 대해 질의를 하 기 전에 촉발된다.

사용 시나리오

Nervana 클라이언트 어플리케이션(가령, 시맨틱 브라우저) 또는 Nervana 스킨은, 질의를 취소하거나 질의를 발하기 전에 질의나 캐시상태를 원할 경우에 상기 이벤트를 싱크시킨다.

프로토타입

Event:OnQueryResultsAvailable

개요

OnQueryResultsAvailable 이벤트는 비동기적 방식 호출에 의해 유효한 결과가 있을 때에 촉발된다.

사용 시나리오

Nervana 클라이언트 어플리케이션(가령, 시맨틱 브라우저) 또는 Nervana 스킨은, 제어기측에서 방식 호출에 대한 의답을 얻을 경우에 상기 이벤트를 싱크시킨다.

프로토타입

부록A

질의 마스크값

스마트 요청 감시 규격

정보 신경망 시스템에 있어서의 스마트 요청 감시 명세

저자: Nosa Omoigui

1. 개 요

스마트 요청 감시는, 정보 신경망 시스템의 한 특징으로서, 시맨틱 브라우저(정보 에이전트 또는 사서(librarian))의 사용자로 하여금 스마트 요청을 병행적으로 모니터(즉, 감시)하도록 한다. 이 기능은 매우 중요한 특징인데, 그 이유는 사용자가 동시에 복수의 요청을 추적하도록 함으로써 생산성을 증대시키기 때문이다.

이 기능은 클라이언트측 의미론적 실행시간, 의미론 브라우저 및 스마트 요청을 감시하는 형태적 방식을 제공하는 스킨에 구현된다(이는 TV의 PIP(picture-in-picture) 기능과 유사한 메카니즘으로 이루어진다). 이를 위해서는 아래의 소프트웨어 컴포넌트가 사용된다.

1. The Request Watch List(RWL)

2. Request Watch Groups

3. The Notification Manager(NM)

4. Watch Group Monitors(WLM)

5. The Watch Pane

6. The Watch Window

제2장 Request Watch Groups (RWGs)

개요

Request Watch List는 클라이언트 실행시간을 관리하는 스마트 요구(또는 스마트 에이전트)의 리스트이다. 이 리스트는 필수적으로 사용자가 감시하고자 하는 스마트 요구를 포함하고 있다. Request Watch List에는 내용리스트인, the Request Watch List Entry(RWLE)와 아래의 데이터구조를 포함하고 있다.

도 1: Request Watch List 내용의 데이터구조를 나타내는 표

Request Watch List(RWL)는 RWLE 구조의 배열 또는 벡터를 포함한다. Request Watch List 관리자는 RWL을 관리한다. 시맨틱 브라우저는 사용자가 스마트 요구를 RWL에 추가토록 하는 UI를 포함하는데, 이 UI는 RWLM과 대화하여 RWL에 RWLE를 추가하고 RWL로부터 RWLE를 삭제를 한다. RWL은 클라이언트측 의미론적 실행시간에 의해 중앙에서 저장 (및 유지)된다(XML 파일 기반 문서 또는 상점형 윈도우즈 레지스트리와 같이).

Request Watch Groups

RWL은 또한 Request Watch Groups(RWGs)에 의해 취합(population)될 수 있다. Request Watch Group은 사용자가 스마트 요구의 집합을 감시하도록 하는 수단을 제공한다. 또한, 사용자가 단순하게 시맨틱 브라우저를 이용하여 자동으로 RWL을 재구성 방식으로 취합할수 있도록 해 준다. RWG에는 두 가지 유형이 있는데, 하나는 자동 RWG이고 다른 하나는 수동 RWG이다. 자동 RWG는, 선정된 프로필(현재 표시되는 요청 등의 프로필)에 따라 시맨틱 브라우저에 의해 동적으로 취합된다. 고객 요청(감시 그룹)은 사용자로 하여금 수동으로 스마트 요청(통상의 스마트 요구 또는 혼합기)의 그룹을 취합하여 집합적으로 감시토록 한다

사용자는 아래와 같은 유형의 ("All Profiles"를 포함하는 하나 이상의 재구성 가능한 프로필에 대한) 자동 RWG를 추가할 수 있다(

1. 긴급뉴스 - 이는 긴급뉴스 스마트 요구를 RWL에 (소정의 프로필에 대해서) 자동 으로 추가하도록 시맨틱 브라우저에게 지시한다.

2. 헤드라인 - 이는 헤드라인 스마트 요구를 RWL에 (소정의 프로필에 대해서) 자동으로 추가하도록 시맨틱 브라우저에게 지시한다.

3. 기사거리 - 이는 기사거리 스마트 요구를 RWL에 (소정의 프로필에 대해서) 자동으로 추가하도록 시맨틱 브라우저에게 지시한다.

4. 카테고리화된 긴급뉴스 - 이는 카테고리화된 긴급뉴스 스마트 요구를 RWL에 (콘텍스트적 프로필에 대해서) 자동으로 추가하도록 시맨틱 브라우저에게 지시한다. 시맨틱 브라우저는, 현재 표시되고 있는 스마트 요구가 카테고리를 갖고 있다면, 현재 표시되고 있는 스마트 요구의 각 서브카테고리에 해당하는 카테고리 필터와 함께 (및 콘텍스트적 또는 현재의 프로필에 대한) 스마트 요구를 동적으로 추가하게 된다. 예를 들어, 스마트 요구인 "기술에 대한 긴급뉴스"가 현재 시맨틱 브라우저에 표시되고 있고, 이 "기술"의 카테고리가 5개의 서브카테고리(가령, 무선, 반도체, 나노기술, 소프트웨어, 전자)를 갖고 있다면, 현재의 스마트 요구가 적재될 때에 아래와 같은 스마트 요구가 동적으로 RWL에 추가될 것이다.

· 기술.무선에 대한 긴급뉴스[＜Contextual Profile Name＞]

·기술.반도체에 대한 긴급뉴스[＜Contextual Profile Name＞]

·기술.나노기술에 대한 긴급뉴스[＜Contextual Profile Name＞]

·기술.소프트웨어에 대한 긴급뉴스[＜Contextual Profile Name＞]

·기술.전자에 대한 긴급뉴스[＜Contextual Profile Name＞]

또한, 이들 입력내용에 대한 RWLE는, 현재 시맨틱 브라우저의RequestViewInstanceID에 의해 초기화된다. 사용자가 새고운 스마트 요구를 네이비게이트한다면, 이전에 적재된 스마트 요구에 대한 카테고리화된 긴급뉴스는 RWL로부터 제거되고, (어떠한 카테고리를 갖든) 새로운 카테고리화 긴급뉴스가 새로운 스마트 요구에 추가되어, 새로운 스마트 요구 뷰에 해당하는 새로운 RequestViewInstanceID로 초기화된다. 이로써 해당 카테고리화 긴급뉴스 (서브카테고리에 대한) 가 현재 표시되는 요청에 근거하여 동적으로 표시되는 스마트 사용자경험을 생성하게 된다. 이로써 사용자는 감시 그룹 또는 감시 집합으로서 카테고리화된 긴급뉴스 스마트 요청을 감시할 수 있게 된다.

5. 카테고리화된 헤드라인 - 이는 카테고리화된 헤드라인 스마트 요구를 RWL에 (콘텍스트적 프로필에 대해서) 자동으로 추가하도록 시맨틱 브라우저에게 지시한다. 이는 카테고리화된 긴급뉴스와 같은데, 다만 다른 점은 이는, 헤드라인의 경우에 사용된다는 점이다. 이로써 사용자는 감시 그룹 또는 감시 집합으로서 카테고리화된 헤드라인 스마트 요청을 감시할 수 있게 된다.

6. 카테고리화된 기사거리 - 이는 카테고리화된 기사거리 스마트 요구를 RWL에 (콘텍스트적 프로필에 대해서) 자동으로 추가하도록 시맨틱 브라우저에게 지시한다. 이는 카테고리화된 긴급뉴스와 같은데, 다만 다른 점은 이는, 기사거리의 경우에 사용된다는 점이다. 이로써 사용자는 감시 그룹 또는 감시 집합으로서 카테고리화된 기사거리 스마트 요청을 감시할 수 있게 된다.

7. 선호내용 요청 - 이는 모든 선호내용 스마트 요구를 RWL에 (소정의 프로필에 대해서) 자동으로 추가하도록 시맨틱 브라우저에게 지시한다. 이로써 사용자는 그룹 으로서 자신이 선호하는 내용의 스마트 요구를 감시할 수 있게 된다.

8. 선호하는 긴급뉴스 - 이는 모든 선호하는 긴급뉴스 스마트 요구를 RWL에 (소정의 프로필에 대해서) 자동으로 추가하도록 시맨틱 브라우저에게 지시한다. 이로써 사용자는 그룹으로서 자신이 선호하는 긴급뉴스에 대한 스마트 요구를 감시할 수 있게 된다.

9. 선호하는 헤드라인 - 이는 모든 선호하는 헤드라인 스마트 요구를 RWL에 (소정의 프로필에 대해서) 자동으로 추가하도록 시맨틱 브라우저에게 지시한다. 이로써 사용자는 그룹으로서 자신이 선호하는 헤드라인에 대한 스마트 요구를 감시할 수 있게 된다.

10. 선호하는 기사거리 - 이는 모든 선호하는 기사거리 스마트 요구를 RWL에 (소정의 프로필에 대해서) 자동으로 추가하도록 시맨틱 브라우저에게 지시한다. 이로써 사용자는 그룹으로서 자신이 선호하는 기사거리에 대한 스마트 요구를 감시할 수 있게 된다.

Request Watch Group 관리자의 사용자

인터페이스

아래의 그림 2는 시맨틱 브라우저의 "스마트 요구 감시" 대화상자를 나타낸다. 대화상자의 윗부분은 자동감시 그룹을 추가하기 위해 사용된다. 사용자는 자동감시 그룹의 종류와 프로필유형("All Profiles", "Contextual Profile", 및 실제의 프로필이름)을 선택할 수 있고, 이들을 자동감시 그룹 리스트에 추가할 수 있다. 사용자는 또한 자동감시 그룹을 삭제할 수 있다. 대화상자의 아래 부분은 수동 감시그룹으로 스마트 요구를 추가하거나 수동 감시그룹에서 스마트 요구를 제거하는 데 사용된다.

그림 2. "스마트요구 감시" 대화상자

3. 통지관리자(The Notification Manager, NM)

통지관리자(NM)는 의미론적 실행시간 클라이언트의 일 구성요소로서, RWL의 스마트 요구을 감시하는 역할을 한다. 통지관리자는 RWL의 각 스마트 요구를 (클라이언트의 의미적 질의 처리기를 통해) 주기적으로 불러와 "결과 카운트" 및 "최종 업데이트 시간"으로 RWLE를 업데이트하는 쓰레드(thread)를 갖고 있다. 바람직한 실시예에 있어서, 통지관리자는 매 5~30초마다 스마트 요구를 불러와야 한다. 통지관리자는, (사용상의 대역폭을 줄이고 웹서비스에 미치는 소형화의 영향을 줄이기 위해) RWL의 크기에 의존하여 요청 체크를 스마트하게 주기적으로 조절한다.

시간에 민감한 스마트 요구(긴급뉴스, 헤드라인, 기사거리)에 대해서는, 통지관리자는 별도의 시간 필터없이 스마트 요구를 불러와야 한다. 그러나, 시간에 민감하지 않은 요청(콘텍스트 유형에 반대되는 정보 또는 선호사항 및 추천사항 등과 같이 시간에 민감하지 않은 콘텍스트 템플릿)에 대해서는 통지관리자는 시간필터(예, 마지막 10분)를 이용하여 스마트 요구에 대한 질의를 해야 한다.

4. 감시그룹 감시자(Watch Group Monitors)

의미론적 실행시간 클라이언트는, 발명자가 명명한 감시그룹 감시자(WGM)를 관리한다. 사용자가 감시그룹 리스트를 부가해놓은 각 감시그룹에 대해서 클라이언트는 감시그룹 감시자를 생성한다. 감시그룹 감시자는 그 감시그룹에 있는 각 요청 중에 서 새로운 결과의 개수를 추적한다. 감시그룹 감시자는 새로운 결과를 갖는 감시그룹 중의 RWLE에 대해서 대기행렬(queue)를 생성하는데, 감시그룹 감시자는 결과들의 최신성을 최소화하기 위하여 이 대기행렬을 관리한다. 감시그룹 감시자는 주기적으로 통지관리자를 폴링하여 해당 감시그룹의 각 요청에 대해서 새로운 결과가 있는지를 지켜보도록 한다. 만일 새로운 결과가 있다면, 그 요청을 대기행렬에 추가하는데, 이는 요청의 "마지만 결과 시간"에 의존하여 수행한다. 이는 가장 최신의 결과를 우선적으로 요청하기 위한 것이다. 다음에, 표시기(presenter)에서 실행되고 있는 현재 표시된 시각적인 스타일(스킨)이 의미론적 실행시간 OCX를 호출하여 감시그룹 감시자 대기행렬에서 요청을 제거한다. 이로써 요청감시 사용자인터페이스는 새로운 결과값과 일치하게 되고, 최신성이 이러어진다. 현재 표시되는 요청에서 더 이상의 새로운 결과가 없으면, 스마트 스타일은 감시그룹 감시자 대기행렬에서 다음 요청을 제외하게 된다.

5. 감시판(The Watch Pane)

Watch Pane(WP)은 표시기(주요 결과 패널 옆에 있음)에 표시되도록 하는 패널을 의미하는데, 사용자의 감시그룹의 시각적 표시를 위한 것이다. 감시판은 사용자로 하여금 각 감시그룹을 살펴볼 수 있도록 하여 그 요청에 새로운 결과가 있는 지를 알도록 한다. 감시판은 또한 사용자로 하여금, 감시그룹의 실시간 상태 표시에 의해 현재의 화면을 변경할 수 있도록 한다. 이하의 화면은 현재 정의되어 있는 것들이다.

- 타일형식 화면 - 이는 모든 스마트 요구에 있는 새로운 결과의 전체 개수와 함께 감시그룹의 제목을 표시한다.

- 시계형식 화면(ticker view) - 이는 모든 감시그룹의 스마트 요구의 새로운 결과의 총개수를 표시하지만, 각 스마트 요구의 새로운 결과의 개수를 순차적으로 표시하는 애니메이션으로도 나타낸다(시계처럼).

- 미리보기 화면 - 시계형식 화면과 유사한데, 다른 점은 대부분의 스마트 요구별 최근 결과가 티커의 새로운 결과 개수 옆에 함께 표시된다는 점이다.

- 상세 화면 - 이 화면을 통해서 감시판은, 각 스마트 요구에서의 새로운 결과의 개수를 표시하는 티커와 함께 모든 감시그룹의 스마트 요구에 있는 새로운 결과의 개수를 표시하고, 모든 스마트 요구별 새로운 결과를 슬라이드쇼로서 보여준다.

6. 감시창(The Watch Window)

감시판은 또한 사용자로 하여금 감시그룹을 감시하도록 한다. 사용자는 감시판에 있는 감시그룹 중 하나를 선택하여 메인 결과판(또는 유사한 기술에 의해)으로 드래그함으로써 이를 수행할 수 있다. 이로써 감시창(WW)이 형성된다. 이는 TV의 PIP기능과 유사한데, 다른 점은 본 기술의 경우에는 의미론적 요청 및 결과가 TV 채널과는 달리 "감시"된다는 것이다. 감시창은 상술한 화면 형태의 어떠한 것으로도 구현될 수 있다. 그러나 감시창이 상세 화면에 구현될 때에, 감시창의 화면 제어가 표시될 수 있다. 아래의 제어방식이 현재 정의되어 있다.

- 요청 고정(pinning) - 사용자는 감시그룹의 특정 요청을 고정시킬 수 있다. 이로 써 감시창은 고정된(pinned) 요청만에 대한 새로운 결과를 (사이클에) 표시하게 되고, 현재의 요청이 고정되어 있는 한, 감시그룹에 있는 다른 요청에 대해서는 진행하지 않게 된다.

- 요청 교환(swapping) - 사용자는 현재 표시되는 요청을 시맨틱 브라우저에서 표시될 메인 요청과 교환다. 스마트스타일은 OCX상의 방식을 불러서, 교환된 요청(SQML 버퍼에 의해 해시처리됨)과 함께 임시 요청을 생성하고 나서, 표시기에 해당 위치(표시창)에 메인 요청을 표시한다는 것을 알리면서 그 요청을 네비게이트한다.

- 정지, 재생, 탐색, FF, RW, 가속 - 사용자는 "감시그룹 요청 스트림"을 정지, 재생, 탐색, 고속진행, 되감기, 가속할 수 있다. 예를 들어, 고속진행은 현재 표시되는 것보다 몇 개 앞서 있는 요청을 표시하게 된다.

- 결과 제어 - 사용자는 감시그룹에 있는 각 요청의결과를 제어할 수 있다. 실제로, 결과는 스트림 내에 있는 스트림인데, 사용자는 현재의 감시그룹에서 현재의 요청에 대한 결과를 제어할 수 있다.

- 자동표시 모드 - 표시해야 할 결과물이 없을 때에는 자동으로 감시창을 숨기고, 새로운 결과가 있을 때에는 감시창이 페이드인되도록 한다. 이로써, 새로운 요청결과가 있을 때에는 감시창이 페이드인되는 점을 이용하여, 사용자는 화면상에 그들의 부동산의 활용을 극대화할 수 있다. 이러한 특징에 의해서 사용자는 개인적 및 의미론적 방법으로 정보 대화 중에 그들의 관심사를 관리할 수 있게 된다.

- 감추기, 닫기, 최소화, 최대화 - 명칭에서 알 수 있듯이, 사용자는 감시창의 감 추기, 닫기, 최소화, 최대화할 수 있다.

아래의 그림 3은 감시창을 나타낸다.

도 3: 감시창을 나타내는 도면.

스마트스타일(Smart Style) 규격

정보 신경망 시스템에 있어서의 스마트스타일 규격

저자: Nosa Omoigui

1. 서론

개관

스마트 스타일

- 스타일 주제에 적용된 색상 주제 및 애니메이션 주제가 스마트스타일을 창출한다.

- 스마트는 그 요청, 콘텍스트판, 미리보기 모드, 핸드헬드 모드, 라이브 모드, 슬라이드쇼 모드, 스크린세이버 모드, 혼합/취합 모드, 접근가능성, 및 사용자 설정의 인식에 대한 분위기에 적용가능한 것을 의미한다.

스타일 분류

- 약함 - 과제 지향 생산성을 위한 스타일

- 보통 - 약간의 표시 효과를 갖는 과제지향 생산성을 위한 스타일

- 우수 - 우수한 효과(주요기계와 부차적 기계 및 불활성 상태의 Nervana 윈도우 모두에 대하여 우수함. 가령 사용자가 그 주요 기계를 사용시에는 부차적 기계)

- 공상과학물(Sci-Fi) (영화 매트릭스 팬에게는, 생산성에 대한 특별한 필요성 없이도 스마트 스크린세이버에 대해서 훌륭한 스타일이 됨. 예를 들어, 사용자가 자신의 책상에서 멀리 있을 때)

스타일 주제

- 가변적이고 무제한 - 당사 혹은 스킨의 다른 저자에 의해 생성됨

색상 주제

- 가변적이고 무제한 - 당사 혹은 스킨의 다른 저자에 의해 생성됨

애니메이션 주제

- 가변적이고 무제한 - 당사 혹은 스킨의 다른 저자에 의해 생성됨

함축적이고 동적인 스마트 스타일 특성

- 분위기(mood) - 스마트 스타일은 요청의 분위기를 전달시켜야 한다(즉, 요청은 g스마트스타일로 전달되는 변수이다). 이는 스마트 요청(콘텍스트 템플릿 또는 정보의 유형, 카테고리, 필터의 유무(가령 로컬 문서), 상기 필터의 정보 유형 등)의 특성을 전달하는 의미론적 이미지, 의미론적 모션, 시각화 등을 내포한다.

- 콘텍스트판(context pane) - 가령, 상세한 정보판(대상별), 감추기(docking)할 수 있는 미리보기판, 감추기할 수 있는 콘텍스트 PIP 감시그룹/판 등

- 미리보기 모드(preview mode) - 각 스마트 스타일은 그 결과를 미리보기로 표시할 수 있어야 한다(작은 창으로).

- 핸드헬드 모드(handheld mode) - 각 스마트 스타일은 그 결과를 핸드헬드 장치에 최적화된 결과로서 표시할 수 있어야 한다.

- 라이브 모드(live mode) - 각 스마트 스타일은 실시간의 의미적 시각화대f상별로)를 표시하는 동안 "라이브" 모드가 있어야 한다. 이 모드는 온 오프 선택할 수 있다(가령, 사용자가 실시간 의미론적 시각화를 원치 않거나, 대상별 실시간웹서비스 호출을 일으키는 대역폭을 절약하기 위해서).

- 슬라이드쇼 모드(slideshow mode) - 각 스마트 스타일은 요청의 결과를 라이브 스트림으로서 "재생"할 수 있어야 한다.

- 스크린세이버 모드(screensaver mode) - 각 스마트 스타일은 요청의 결과를 스크린세이버로서 재생할 수 있어야 한다. 이는 슬라이드쇼 모드의 변형이다(단, 전체 스크린/시어터 모드는 제외).

- 혼합/취합 모드(blender/collection mode) - 각 스마트 스타일은, 표시 요청이 혼합/취합일 경우에는 적합하게 그 UI를 변경해야 한다.

- 접근가능성(accessibility) - 각 스마트 스타일은 접근가능성을 지원해야 한다(미확정).

- 사용자 설정의 인식(user settings recognition) - Nervana Librarian을 이용하여 사용자는 자신이 초보자인지, 중급자인지, 고급자인지, 그리고 자신의 직업이 무엇인지(연구직, 판매직, 영업, 경영자 등)를 나타낼 수 있다. 각 스마트 스타일은 이들을 적절하게 고려해야 한다.

각 스마트 스타일은 아래와 같은 일을 한다.

- 현재 요청의 분위기(의미론적 이미지, 모션, 색조(chrome) 등을 포함 - 이들은 요청의 의미에 일치한다)를 시각화

- 현재 요청에 있는 항목수의 변경을 시각화

- 각 객체 (고유)의 분위기를 시각화

- 각 객체의 콘텍스트(헤드라인, 긴급뉴스, 전문가 등)의 분위기를 시각화.

. 이진수/절대값 (긴급뉴스가 있는가 없는가? 전문가가 몇 명 있는가? 몇 개의 헤드라인이 있는가?)

. 정도에 대해 (긴급뉴스는 얼마나 돌발적인가? 헤드라인이 얼마나 중요한가? 전문가의 전문성은 어느 수준인가?)

. 사용자의 관심을 받아들여야 하는 것에의 일치성

- 각 객체의 콘텍스트 변화를 시각화 (새로운 긴급뉴스가 있음, 새로운 주석이 있음, 등)

- 표시되는 각 개체의 상대적 중요성을 시각화 (크기가 다른 화면, 다른 활자 , 다른 색조 등)

- 요청 네이비게이션 및 "적재(loading)" 상태(적재되는 새로운 요청의 분위기를 입력하는 간격)를 시각화

- 개별 PIP 윈도우를 시각화 (애니메이션 제어에 의해 애니메이션됨)

- PIP 윈도의 크기 변경/이동/감추기

- 미리보기 윈도우의 시각화(콘텍스트 팔레트, 각 객체에 대한 콘텍스트 시각화 UI, 시간표 등)

- 분위기 및 통지의 시각화에 일치하는 사운드 (보드를 통하여)

아래의 그림 1은 "스마트 스타일" 대화상자의 캡쳐화면이다. 이로써 사용자는 스타일 분류, 스타일 주제, 색상 주제, 애니메이션 주제를 움직임으로써 스마트 스타일을 브라우즈할 수 있다. 미리보기 윈도우에 의해서 사용자는 현재 선택된 스마트 스타일을 미리볼 수 있다.

도 1: 스마트 스타일 대화상자

의미론적 질의 마크업 언어(SQML) 규격

정보 신경망 시스템에 있어서의 클라이언트측 의미론적

질의문서 규격

저자: Nosa Omoigui

1. SQML 개관

Semantic Query Markup Language (SQML)의 개관

개요

Nervana Semantic DHTML의 동작은 클라이언트의 시각으로부터 수행되는 인터넷 익스플로러 DHTML 동작인데, 그것이 이해하는 모든 것들은 질의 문서가 된다. 클라이언트는, 워드프로세서에서 "문자 및 복합 문서"를 오픈하는 것처럼 "질의 문서"를 오픈한다. Nervana 클라이언트는 주로 Nervana 의미론적 질의 문서를 처리하고, 결과를 생성한다. Nervana 의미론적 질의 문서는 Nervana SQML의 형식으로 표현되고 저장된다. 이는 "의미론적 파일 포맷"과 유사한 것이다.

SQML 의미론적 파일 포맷은 아래의 것들을 포함한다.

- 헤드 - HTML의 경우와 같은 "헤드" 태그로서 문서를 규정하는 태그를 포함한다.

o Title - 문서의 명칭

o Comments - 문서의 코멘트

o UserName - 문서 생성자의 사용자이름

o SystemName - 문서가 생성된 장치의 시스템명

o Subject - 문서의 주제

o Creator - 문서의 생성자

o Company - 문서가 생성된 회사

o RequestType - 요청의 유형을 나타냄. 이는 "스마트 요구" (하나 이상의 정보 커뮤니티 웹서비스에 대한 요청을 나타냄) 또는 "dumb 요청"(하나 이상의 로컬 또는 네트웍 자료에 대한 요청을 나타냄)일 수 있다.

o ObjectType - 이는 질의에 의해 응답된 객체 유형의 질을 나타낸다.

o URI - 문서의 위치

o CreationTime - 문서의 생성 시간

o LastModifiedTime - 문서의 마지막 변경 시간

o LastAccessedTime - 문서의 마지막 접근 시간

o Attributes - 문서의 속성. 현재, 이 속성에 대해 규정된 것은 없음.

o RevisionNumber - 문서의 개정 횟수

o Language - 문서의 작성 언어

o Version - 질의의 버전을 나타냄. 이로써 웹서버의 의미론적 질의 처리기는 버전지정된 결과를 응답한다. 가령, 브라우저의 한 버전을 질의의 V1로 사용하고, 다른 버전은 V2로 사용할 수 있다. 이로써 웹서비스는 자원수준(가령, 에이전트용) 및 링크수준 모두에 있어서 뒤로의 호환성을 제공할 수 있다.

- 타겟 - 질의 문서가 지향하는 정보 커뮤니티 웹서비스의 이름 및 URL을 나타낸다.

o Type - 타겟의 유형을 나타냄. 이는 태그가 실제 웹서비스 타겟을 나타내는 서브타겟을 포함하는 경우의 "targetentries", 또는 질의 처리기가 모든 연결된 정보 커뮤니티를 사용하는 경우의 "allsubscribedtargets"일 수 있다.

- Categories - 질의문서가 참조하는 카테고리 URL의 목록을 나타낸다. 각 "카테고 리" 항목에는, 명칭 속성, 및 카테고리가 온 지식 도메인 서버(KDS)의 URL을 나타내는 URL 속성을 포함한다.

o Type - 타겟의 유형을 나타냄. 이는 서브태그가 카테고리 항목의 리스트를 참조하는 경우의 "targetentries", 모든 카테고리가 정보 커뮤니티 웹서비스로부터 요청되는 경우의 "allcategories", 또는 질의 처리기가 사용자의 선호 카테고리를 취득하여 이들 카테고리를 포함하는 컴파일된 SQML를 생성하는 경우의 "myfavoritecategories" (이 컴파일된 SQML는 서버로 전송됨)일 수 있다.

- Query - 질의 문서의 주요 질의 항목에 대해 부모 태그이다.

- 자원 - 질의받을 "dumb" 자원에 대한 참조 자료. 예로서는 파일 경로, URL, 캐시 항목 식별자 등을 들 수 있다. 이들은 인터프리터(해석자)에 의해 실제 자원 관리자 컴포넌트로 매핑될 수 있다.

o Type - 자원 참조자료의 유형으로서 이름공간으로 자격부여(qualify)된다. 정의된 자원 참조자료 유형의 예로서, nervana:url (이는, 자원 참조자료가 잘 형성된 표준 인터넷 URL, 또는 커스텀 Nervana URL과 같은 "agent://..."임을 나타냄), nervana:filepath(이는 자원 참조자료가 파일체계의 파일 또는 디렉토리로의 경로임을 나타냄), nervana:namespace(이는 자원이 클라이언트의 의미론적 이름공간으로부터 옴을 나타냄)를 들 수 있다.

o Url - Universal resource identifier를 의미함. 경로 및 인터넷 URL의 경우에, 이는 URL 자체를 나타내며, 이름공간 항목의 경우에 이는 입력항목의 GUID 식별자를 나타낸다.

o Mid - SQML 해석기에 의해 자원을 문서의 메타데이터 섹션으로 매칭하는데 사용하는 metadata identifier를 의미한다. 메타데이터 ID는 메타데이터 섹션 내에서 동일한 ID로 매핑된다.

o Args - 자원 ID의 인자(argument)를 나타낸다.

- Links - ("타겟"만을 위한) 의미론적 링크로의 참조를 나타낸다.

o Type - 링크의 유형을 나타냄. 이는 링크가 명시적 입력항목임을 나타내는 "linkentries"일 수 있다.

o LinkEntries - 링크 항목의 세부를 나타냄.

. Predicate - 링크에 대한 술어(predicate)의 유형을 나타냄. 가령, 술어 "nervana:relevantto"는 질의어가 "객체 O에 해당하는 자원 R로부터 모든 객체를f 반환"하는 것을 나타낸다(여기서 R과 O는 각각 자원과 객체를 나타냄). 술어의 다른 예로서, nervana:reportsto, nervana:teammateof, nervana:from, nervana:to, nervana:cc, nervana:bcc, nervana:attachedto, nervana:sentby, nervana:sentto, nervana:postedon, nervana:containstext 등을 들 수 있다.

. Type - "Link" 태그에 나타나는 객체 참조자료의 유형을 나타낸다. 예로서, xml:string, xml:integer, 이들에 대한 Nervanadml 등가물과 같은 표준 XML 데이터 유형과, nervana:datetimeref("today" 및 "tomorrow"와 같은 객체 참조자료를 참조할 수 있음)와 같은 커스텀 Nervana 유형과, 기타 표준 인터넷 URL(HTTP, FTP 등) 또는 Nervana가 의미론적 XML 객체로서 처리할 수 있는 객체를 참조하는 Nervana URL(objects:// 등)을 들 수 있다.

- Metadata - 메타데이터 항목에 대한 참조자료를 포함.

o MetadataEntry - 메타데이터 항목의 세부항목을 나타낸다.

. Mid - 메타데이터 ID (GUID)를 나타냄

. Value - 메타데이터 자체를 나타냄.

예: 문서(정보 또는 콘텍스트 기반)

2. SQML의 생성

SQML은 몇 가지 방법으로 생성된다.

- 스마트 요청의 생성

- 로컬 요청의 생성

- 입력엔티티(entity)의 생성

- 시맨틱 브라우저에서 하나 이상의 로컬 문서를 오픈

- 클라이언트에 의해 (동적으로) - 드래그＆드롭, 스마트 복사 및 붙여넣기, intrinsic alert, 콘텍스트 패널/링크 호출 등

3. SQML 파싱

클라이언트측에서 생성되는 SQML은, 서버의 XML 웹서비스에 으해 또는 다른 측 사이트에서 (실시간으로) 원격 소비되도록 준비되어 있지 않다. 특히 이는 SQML이 문서, 명칭, 또는 스마트 요구(의미론적 환경에서 고유한 ID에 의해 구별됨)과 같은 로컬 콘텍스트를 참조하는 경우이다. 바람직한 실시예에서, 클라이언트는 원격 소비의 준비가 되어 있는 SQML을 항상 생성한다. 이는 문서의 메타데이터 섹션에 있는 모든 참조자료용 메타데이터를 캐시처리(caching)함으로써 이루어진다. 질의가 호출될 때 참조 자료가 지시하는 자원 또는 객체가 더 이상 존재하지 않는 경우가 있기 때문에 이는 중요하다. 예를 들어, 사용자는 새로운 관련 요청을 생성하기 위하여 인터넷으로부터 스마트 요구로 문서를 드래그 및 드롭할 수 있다. 클라이언트는 메타데이터(요약을 포함함)를 링크에서 추출하여 이를 SQML로 삽입한다. 질의의 해상도가 메타데이터만을 사용하므로, 질의는 일단 SQML 문서로 삽입되면 소비의 준비를 하게 된다. 그러나 객체가 참조하는 링크는 사용자가 발견한 때에는 이미 존재하지 않을 수 있다. 어떤 경우에, 링크가 끊어진 후에 사용자가 관련된 요청을 호출하더라도 요청은 여전히 작동할 수 있다. 왜냐하면 메타데이터는 이미 SQML에 캐시화되어 있기 때문이다.

클라이언트 SQML parser는 SQML의 메타데이터의 업데이트를 늦게 수행한다. 요청이 호출된 때에, SQML에 있는 모든 파라미터(자원 등)의 메타데이터를 업데이트 시도함으로써, 객체가 관련된 요청을 생성하는데 사용되고 나서 변경되는 경우를 제어할 수 있다. 객체가 존재하지 않으면, 클라이언트는 이미 객체가 갖고 있는 메타데이터를 이용한다. 그 밖에 클라이언트는 업데이트를 하고 업데이트된 메타데이터를 사용한다. 이로써, 비록 객체가 삭제되더라도, 사용자 경험은, 사용자가 실제로 메타데이터가 온 시점으로부터 객체를 오픈하려고 시도할 때까지는 방해를 받지 않게 된다.

엔티티(Entities) 규격

정보 신경망 시스템에 있어서의 엔티티 규격

저자: Nosa Omoigui

1. 개요

개관

엔티티(Entities)는 정보 신경망 시스템의 매우 강력한 특징이다. 엔티티에 의해 사용자는, 정상적으로 어떻게 시스템을 동작시키도록 매핑하는 콘텍스트의 정의를 할 수 있게 된다. 엔티티의 예는 다음과 같다.

1. 행위 항목(action items)

2. 회사(companies)

3. 경쟁자(competitors)

4. 고객(customers)

5. 회의(meetings)

6. 조직(organizations)

7. 협업자(partners)

8. 제품(products)

9. 프로젝트(projects)

10. 화제(topics)

또한, 산업에서 지정한 엔티티가 있다. 가령, 약학 분야에서는, 엔티티에는 약w물, 약물반응에 대한 논쟁, 특허, FDA 의료소송 등이다. 특히, 엔티티는 스마트콘텍스트 객체인 의미론적 포섭(semantic envelope)이다. 엔티티도 다른 스마트 객체와 마찬가지로 드래그/드롭할 수 있다. 그러나 엔티티는 SQML로 표현되는 것으로 SRML 로 표현되지 않는다(즉, 이는 매우 풍부하게 의미론적이기 때문에 질의 객체가 된다). 엔티티는 스마트 요청에 파라미터로서 포함될 수 있다. 사용자는 자신의 과제에 근거하여 엔티티를 생성할 수 있다. 엔티티는 다음과 같은 정보를 포함한다.

1. Name/Description - 엔티티에 대한 알기 쉬운 이름

2. 엔티티의 카테고리 - 표준 산업 분류에 따름

3. 콘텍스트적 자원 - 여기에는 키워드, 로컬 문서, 인터넷 문서 또는 스마트 객체(사람 등)가 포함될 수 있다.

엔티티는 시맨틱 브라우저로 오픈할 수 있고, 스마트 요구(가령, 내 프로젝트의 헤드라인)의 변수처럼 네이베게이션의 기준축으로 사용될 수 있고, 드래그드롭될 수 있고, 복사 및 붙여넣기를 할 수 있고, 스마트렌즈로서 사용할 수 있으며, 스마트 스타일로 시각화될 수 있고, intrinsic alert의 기본으로 사용할 수 있고, d.ENT 문서와 같이 저장할 수 있으며, 이메일 전송, 공유 등을 할 수 있다. 즉,엔티티는 제1등급의 스마트객체인 것이다.

의미론적 실행시간 클라이언트는, 엔티티를 참조하는 새로운 풍부한 SQML을 생성하기 위하여, 관계되는 요청의 주제에 대한 엔티티의 풍부한 메타데이터를 부가함으로써 동적으로 SQML을 생성한다.

포트폴리오

포트폴리오는 엔티티의 특수한 유형으로서, 엔티티의 집합을 포함한다. 복잡함을 최소화하기 위하여, 포트폴리오는 단수로 한다. 포트폴리오에 의해 사용자는 엔티 티 그룹을 하나의 유닛처럼 관리할 수 있다. 포트폴리오는 제1등급의 엔티티로서 엔티티의 상술한 모든 특성을 그대로 갖고 있다. 포트폴리오가 스마트 요청 내에서 파라미터로 사용될 때에, OR 정성자(qualifier)는 (기본적으로) 그 포함하는 엔티티에 적용된다. 즉, 포트폴리오 P가 엔티티 E1, E2를 포함하고 있다면, "P에 대한 헤드라인"으로 명명된 스마트 요청은 "E1 또는 E에 대한 헤드라인"으로서 처리될 것이다. 사용자는 각 개별 스마트 요청에서 이 설정을 (AND 정성자로) 변경할 수 있다.

샘플 시나리오

1. 약품 "특허" 엔티티는 특허에 관련된 키워드와 관련 문서를 포함할 수 있다.

2. CIA에서는 테러리스트를 추적하기 위하여 "테러리스트" 엔티티를 생성할 수 있다. 여기에는 테러리즘에 대한 카테고리, 의심가는 계좌 이체, 의심가는 무기판매, 분류된 문서, 키워드, 정보 커뮤니티에서의 테러 전문가가 포함될 수 있다.

3. 어제 미팅시의 모든 긴급뉴스 찾기.

4. 내 경쟁자에 대한 헤드라인 찾기(이는 경쟁자 엔티티를 생성하고, 각 술어에 대한 OR 정성자를 이용하여 파라미터로서의 엔티티와 함께 스마트 요구를 생성함으로써 수행된다).

5. 내 투자 포트폴리오 회사에 대한 전문가 찾기 (개별 엔티티 생성, 이들 엔티티를 포함하는 포트폴리오 생성, "Expert" 콘텍스트 템플릿을 갖고 인자로서 포트폴리오를 갖는 스마트 요청 생성).

도해

아래 그림은 시맨틱 브라우저에 표시된 엔티티 화면을 나타낸다 (좌측).

확장가능한 클라이언트측 사용자 프로파일 규격

정보 신경망 시스템에 있어서의 확장가능한 클라이언트측

사용자 프로필 규격

저자: Nosa Omoigui

1. 개요

개관

확장가능한 클라이언트측 사용자 프로필은 시맨틱 브라우저 사용자로 하여금 다른 업무역할, 정체성, 인물, 업무스타일 등에 대해 다른 상태를 갖도록 해준다. 가령, 사용자는 "Work"에 대한 프로필과 "Home"에 대한 프로필을 생성할 수 있다 . 많은 투자 분석가들은 다양한 산업계의 회사들을 추적한다. 본 시맨틱 브라우저를 이용하면, 그들은 그들이 찾는 각 산업계에서의 프로필을 생성할 수 있다. 컨설턴트들은 프로젝트별로(그리고 산업별로) 이동하게 되는데, 각 프로젝트에서 생성된 요청과 엔티티들을 저장하길 원할 것이다. 프로필은 이러한 것들을 실현시키는 사용된다.

프로파일에는 아래와 같은 사용자 상태를 포함한다.

- 이름/설명 - 프로필의 설명적 명칭.

- 인증 정보 - 사용자 이름(현재는 사용자의 이메일주소로 태그되어 있다)과 비밀번호

- 관심 또는 선호분야 카테고리 - 사용자에게 정보 커뮤니티 (에이전트)를 제안하는데 사용되며 (정보 커뮤니티를 동일하거나 유사한 카테고리로 비교함으로써), 요청에 대한 기본적인 질의 필터로서 프로필에 대해서 생성된다.

- 스마트 스타일 - 프로필과 함께 생성된 요청과 엔티티에 대해서 기본적으로 사용될 스마트 스타일.

- 기본 플래그 - 프로필이 기본 프로필인지 여부를 나타낸다. 기본 프로필은, 사용자가 요청과 엔티티를 생성하거나, 정보 커뮤니티를 검색하고자 할 때 기본적으로 시작된다. 사용자가 명시적으로 다른 프로필을 선택하지 않는 한, 기본 프로필이 사용된다.

프로필은 생성, 삭제, 변경, 이름바꾸기를 할 수 있다.

정보 커뮤니티 브라우징 및 가입 규격

정보 신경망 시스템에 있어서의 정보 커뮤니티 브라우징 및

가입 규격

저자: Nosa Omoigui

제1장 개요

개관

Nervana 시맨틱 브라우저는 사용자로 하여금 주어진 프로필에 대한 정보 커뮤니티(에이전시)로의 가입 및 가입해제를 가능케 한다. 이들 정보 커뮤니티는 의미론적 환경에서의 프로필 내용에 근거하여 사용자에게 즉시 유용성을 준다. 또한 이들 정보 커뮤니티는, 동일한 프로필을 이용하여 생성된 모든 요청에 대해서 결과가 표시될 때마다, 기본적으로 intrinsic alert, 콘텍스트패널 등에 대해 질의를 받게 될 것이다.

의미론적 환경에는, 각 프로필에 대해서 가입된 정보 커뮤니티를 나타내는 상태를 포함한다. 클라이언트측 의미론적 질의 처리기(SQP)는 이 정보를 주어진 프로필의 요청에 대한 결과로부터 출발한 동적 요청에 대한 정보를 이용한다 (SQP는 의미론적 실행시간 클라이언트에 프로필에 대한 정보 커뮤니티에 대해 질문을 하고, 나서 이들 정보 커뮤니티에 대한 XML 웹서비스 호출신호를 적절하게 전송할 것이다).

아래의 그림 1에는 정보 커뮤니티의 가입 및 가입해제를 위한 사용자 인터페이스가 도시되어 있다. 대화상자는 복합적인 콤보박스로서 사용자로 하여금 프로필에 의한 필터링, 관심산업 및 관심분야별, 키워드로, 발행시점별(모든 발행시점, 근거리 망, 기업디렉토리, 국제 정보 커뮤니티 디렉토리), 생성시간별(언제나, 오늘, 어제, 금주, 지난 주)로 모두 보기, 새로운1)/ 가입한/ 제안된/가입해제한 커뮤니티 보기를 가능토록 한다. 의미론적 실행시간 클라이언트는 필터를 사용하여 발행시점 최 종점 수신자에게 (각 발행시점에 대해서) 질의를 한다. 그리고 나서 클라이언트는 결과를 모아서 결과판에 표시를 한다. 사용자는 또한 콤보박스를 통해 결과판에 있는 각 정보 커뮤니티의 카테고리를 볼 수 있다.

주 1) "새로운"은 주어진 프로필에 대해서 시스템이 체크한 마지막 시간 이후로 새로운 정보 커뮤니티가 발행되었는지를 체크함으로써 실현된다. (각 프로필은 발행시점 수신자가 질의했던 "마지막으로 체크한 시간"에 대한 상태를 포함하고 있다.)

도 1: 정보 커뮤니티 대화상자

Claims (4)

1. 지식 검색, 관리, 전달 및 프리젠테이션 시스템에 있어서,

   시맨틱 정보를 유지하도록 프로그램가능한 서버; 및

   사용자가 상기 서버와 통신하도록 사용자 인터페이스를 제공하는 클라이언트를 포함하며; 또한

   상기 서버의 프로세서는:

   정보 소스들로부터 정보를 획득하는 단계; 및

   상기 정보의 하나 이상의 시맨틱 프로퍼티들을 시맨틱하게 확인하는 단계; 및

   상기 하나 이상의 시맨틱 프로퍼티들에 기초해서 사용자 쿼리들에 답변하는 단계를 수행하도록 동작하는 것을 특징으로 하는 지식 검색, 관리, 전달 및 프리젠테이션 시스템.
2. 제 1 항에 있어서, 상기 첫 번째 서버는 시맨틱 네트워크, 시맨틱 데이터 수집기(gatherer), 시맨틱 네트워크 일관성 검사기, 추론 엔진, 시맨틱 쿼리 프로세서, 자연 언어 파서, 이메일 지식 에이전트 및 지식 도메인 관리자 중 적어도 하나를 제공하도록 되어있는 구조와 방법론을 포함하는 것을 특징으로 하는 지식 검색, 관리, 전달 및 프리젠테이션 시스템.
3. 제 1 항에 있어서,

   상기 정보는 객체들 또는 이벤트들을 포함하며; 또한

   상기 객체들 또는 이벤트들의 시맨틱 프로퍼티들이 상기 쿼리들의 시맨틱 및 프로퍼티들과 시맨틱적으로 링크되도록 하기 위한 액티브 에이젼트들에 의해 표현되는 것을 특징으로 하는 지식 검색, 관리, 전달 및 프리젠테이션 시스템.
4. 시맨틱 정보를 분류하며 또한 유형화하기 위해 사용되는 도메인 특유의 정보를 추가하고, 유지하며 또한 호스팅하도록 프로그램된 서버 시스템과 함께 사용하기 위한 지식 검색, 관리, 전달 및 프리젠테이션 방법에 있어서,

   정보를 정보 소스들로부터 획득하는 단계;

   상기 정보 소스들로부터의 정보를 시맨틱적으로 링크하는 단계;

   상기 시맨틱적으로 링크된 정보의 시맨틱적인 애트리뷰트들을 유지하는 단계;

   사용자의 쿼리에 기초해서 요청된 시맨틱 정보를 전달하는 단계; 및

   주문식 사용자 선호도에 따라 시맨틱 정보를 제공하는 단계를 포함하는 것을 특징으로 하는 지식 검색, 관리, 전달 및 프리젠테이션 방법.

Images