KR100904890B1 - 임베디드 멀티미디어 기기에 적합한 ｍｐｅｇ-7메타-데이터 저장 방법 - Google Patents

Abstract

본 발명은 XML과 RDBMS의 장점을 유지할 수 있는 임베디드 멀티미디어 기기에 적합한 MPEG-7 메타-데이터 저장 방법을 제공하기 위한 것으로서, 임베디드 멀티미디어 기기를 위해 선택된 MPEG-7 스키마에서 주석을 작성하여 주석 메타-스키마(annotation meta-schema)를 생성하는 단계와, 상기 생성한 주석 메타-스키마를 기반으로 XML 스키마의 내장형 데이터 타입들을 SQLite의 내장형 데이터 타입으로 매핑하여 RDBMS(Relational Database Management System)에 테이블 및 칼럼을 생성하는 단계와, 상기 생성한 주석 메타-스키마를 이용해서 패스 메타-스키마(path meta-schema)를 생성하는 단계와, 상기 생성된 패스 메타-스키마를 이용하여 해당하는 엘리먼트에 대한 RDBMS의 테이블 및 칼럼 정보를 추출하는 단계와, 상기 추출한 테이블과 칼럼 정보를 기반으로 질의를 RDBMS의 문법으로 변환하고 RDBMS에 접근하는 단계와, 상기 RDBMS의 접근을 통해 특정 작업을 해당 테이블이나 칼럼에 요구하여 입력된 질의를 처리하는 단계를 포함하여 이루어지는데 있다.

주석 메타-스키마, 패스 메타-스키마, RDBMS, SQLite, XML 스키마, MPEG-7, 임베디드 멀티미디어 기기, 메타-데이터, 모델 매핑, 구조 매핑

Description

임베디드 멀티미디어 기기에 적합한 ＭＰＥＧ-7 메타-데이터 저장 방법{MPEG-7 meta-data storage method suitable for the embedded multimedia device}

도 1 은 본 발명의 실시예에 따른 임베디드 멀티미디어 기기에 적합한 MPEG-7 메타-데이터 저장 방법을 나타낸 흐름도

도 2 는 본 발명의 실시예에 따른 저장 모델의 테이블 및 칼럼 생성을 통해 구성된 부모 자식 간의 관계를 나타낸 엘리먼트 구조

본 발명은 XML 문서로 작성된 메타-데이터를 RDBMS에 저장하는 방법에 관한 것으로, 특히 임베디드 멀티미디어 기기에 적합한 MPEG-7 메타-데이터 저장 방법에 관한 것이다.

플래시 메모리에 저장되어 있는 음악, 비디오와 같은 멀티미디어 컨텐츠들의 검색을 용이하게 하기 위하여 메타-데이터(meta-data)를 활용하게 되는데, 이러한 메타-데이터를 XML로 작성하여 보관하게 되면, 데이터 표현형식에 일관성을 제공하고, 네트워크를 통해 쉽게 전송할 수 있으며, 또한 플랫폼에 독립적으로 사용할 수 있다는 XML의 장점을 그대로 유지할 수 있다.

하지만 이러한 XML 문서는 텍스트 형식으로 작성되기 때문에 보안이 취약할 수밖에 없으므로, XML로 제작된 메타-데이터를 관계형 데이터베이스 관리 시스템(Relational Database Management System : RDBMS)에 저장함으로써, RDBMS가 지원하는 강력한 관리 및 보안기능을 보완할 수 있고, 잠금 메커니즘을 통해 데이터 원본의 무결성을 확보할 수 있다.

현재 XML 문서를 RDBMS에 저장하기 위한 방법으로는 크게 모델 매핑(model mapping)과 구조 매핑(structure mapping) 방법이 제안되었다.

모델 매핑은 고정된 데이터베이스 스키마(schema)를 사용하여 XML 문서 구조와 데이터를 XML 스키마의 도움없이 저장할 수 있는 방법으로, 대표적인 방법으로는 에지 어프로치(edge approach), 모넷(monet), XRel, Xparent 등이 있다. 이처럼 모델 매핑을 사용하면 복잡한 Xpath를 기반으로 한 쿼리를 지원할 수 있고, 기존의 DBMS에 XML 문서를 저장할 수 있다는 장점이 있다. 하지만 모델 매핑은 부모 자식 간의 관계 혹은 형제간의 관계를 나타내는 쿼리가 복잡하다는 단점을 가지고 있다.

구조 매핑은 데이터베이스 스키마를 임의로 변경할 수 있고, 이를 위한 매핑 지식(knowledge)을 저장하고 있으며, 메타-스키마(meta-schema)로 불리는 매핑 지식을 사용해서 RDBMS에 저장되어 있는 자료들의 검색 및 저장을 가능하게 하는 방법이다. 대표적인 구조 매핑 방법으로는 XRay와 XML-DBMS 등이 있다. 이처럼 구조 매핑을 사용하면 다양한 사용자 쿼리 요구에 부응할 수 있도록 테이블과 칼럼을 생성할 수 있으므로, RDBMS 내에서 많은 메모리와 처리량을 필요로 하는 조인의 횟수 를 줄일 수 있는 DBMS 스키마를 작성할 수 있다. 하지만 구조 매핑은 사용자 쿼리에 응답하기 위해서 메타-스키마를 사용하는데, 이 메타-스키마를 메모리에 올리게 되면 지나친 메모리 사용량이 문제가 된다. 한편 이를 해결하기 위해 메타-스키마를 저장장치에 올려놓고 필요할 때마다 페이징으로 메모리에 탑재하면 처리속도가 느려진다는 단점이 발생한다.

최근 임베디드 멀티미디어 기기의 처리 속도와 저장 공간이 늘어남에 따라서, 장치 내에 저장되는 자료의 양도 갈수록 방대해지고 있다. 특히 MPEG-7의 경우, 메타-스키마의 크기가 방대하기 때문에 임베디드 멀티미디어 기기의 메모리에 올릴 수도 없으며, 이에 따라, 처리속도가 느려진다는 단점이 있다.

따라서 많은 멀티미디어 컨텐츠 중에서 사용자에게 최적인 컨텐츠 검색의 필요성이 더욱 요구되고 있다.

따라서 본 발명은 상기와 같은 문제점을 해결하기 위해 안출한 것으로서, 메타-데이터를 생성하기 위해 필요한 기술어(descriptor)들을 MPEG-7 표준에서 추출하고, 이 스키마를 따라서 생성된 XML 문서를 RDBMS에 저장하도록 함으로써, XML과 RDBMS의 장점을 유지할 수 있는 임베디드 멀티미디어 기기에 적합한 MPEG-7 메타-데이터 저장 방법을 제공하는데 그 목적이 있다.

본 발명의 다른 목적은 사용자 쿼리에 따른 최적의 테이블과 칼럼 생성을 유지하면서도 사이즈가 큰 메타-스키마(path meta-schema)의 크기를 획기적으로 줄일 수 있는 임베디드 멀티미디어 기기에 적합한 MPEG-7 메타-데이터 저장 방법을 제공 하는데 있다.

상기와 같은 목적을 달성하기 위한 본 발명에 따른 임베디드 멀티미디어 기기에 적합한 MPEG-7 메타-데이터 저장 방법의 특징은 주석 메타-스키마를 생성하는 주석 메타-스키마 생성부와, 매핑을 수행하는 매핑부와, 테이블과 칼럼을 생성하는 테이블 및 칼럼 생성부와, 패스 메타-스키마를 작성하기 위한 패스 메타-스키마 작성부와, 질의를 RDBMS의 문법으로 변환하여 RDBMS에 접근하기 위한 XML-RDBMS 프로세서를 포함하여 구성되는 임베디드 멀티미디어 기기에 적합한 MPEG-7 메타-데이터를 저장하기 위한 수단을 이용하여, (a) 상기 주석 메타-스키마 생성부를 이용하여 임베디드 멀티미디어 기기를 위해 선택된 MPEG-7 스키마에서 주석을 작성하여 주석 메타-스키마(annotation meta-schema)를 생성하는 단계와, (b) 상기 매핑부를 이용하여 상기 생성한 주석 메타-스키마를 기반으로 XML 스키마의 내장형 데이터 타입들을 SQLite의 내장형 데이터 타입으로 매핑하고, 상기 테이블 및 칼럼 생성부를 이용하여 RDBMS(Relational Database Management System)에 테이블 및 칼럼을 생성하는 단계와, (c) 상기 패스 메타-스키마 작성부를 이용하여 상기 생성한 주석 메타-스키마를 기반으로 패스 메타-스키마(path meta-schema)를 생성하는 단계와, (d) 상기 XML-RDBMS 프로세서를 이용하여 상기 생성된 패스 메타-스키마를 이용하여 해당하는 엘리먼트에 대한 RDBMS의 테이블 및 칼럼 정보를 추출하는 단계와, (e) 상기 XML-RDBMS 프로세서를 이용하여 상기 추출한 테이블과 칼럼 정보를 기반으로 질의를 RDBMS의 문법으로 변환하고 RDBMS에 접근하는 단계와, (f) 상기 RDBMS의 접근을 통해 특정 작업을 해당 테이블이나 칼럼에 요구하여 입력된 질의를 처리하는 단계를 포함하여 이루어지는데 있다.

바람직하게 상기 (a) 단계의 주석 작성은 XML 인스턴스 작성 시에 삭제한 조상 엘리먼트들의 주석을 MPEG-7 스키마에서 암시적으로 해당 엘리먼트에 삽입하는 것을 특징으로 한다.

바람직하게 상기 (a) 단계의 주석 작성은 사용자 인터페이스를 통해서 확인 된 엘리먼트 및 속성만으로 XML 문서를 작성하는 단계와, 테이블을 생성하고자 하는 엘리먼트에, 속성을 가지는 엘리먼트 바로 다음에, 엘리먼트의 데이터 타입이 기본형이거나 XML 스키마 파생형의 경우의 엘리먼트 중 어느 하나에 주석을 삽입하는 단계를 포함하는 것을 특징으로 한다.

바람직하게 상기 (b) 단계는 상기 생성된 주석 메타-스키마를 입력으로 깊이 우선 검색(Depth-First-Search) 알고리즘을 이용하여 주석 태그를 검색하는 단계와, 상기 검색된 태그 내의 함수에 따라서 테이블 또는 칼럼을 생성하는 단계를 포함하는 것을 특징으로 한다.

바람직하게 상기 (c) 단계는 상기 주석 메타-스키마에서 주석을 탐색하여 엘리먼트, 속성정보 및 테이블을 구분하는 구분단계와, 상기 탐색을 통해 구분된 정보를 이용하여 해당 엘리먼트, 속성의 패스 정보와, 그들이 속해있는 테이블 및 칼럼 정보를 저장하여 패스 메타-스키마를 생성하는 단계를 포함하는 것을 특징으로 한다.

바람직하게 상기 구분단계는 엘리먼트의 구분은 ‘/’로, 속성정보의 구분은‘@’로, 테이블의 구분은 칼럼에 입력된 ‘NULL’을 통해 구분하는 것을 특징으로 한다.

바람직하게 상기 (e) 단계는 입력되는 XML 문서를 상기 주석 메타-스키마를 이용하여 XML 문서의 유효성(Validation)을 판단하는 단계와, 상기 판단 결과 유효성이 없는 것으로 판단되면, 에러 메시지를 출력하고 작업을 종료하는 단계와, 상기 판단 결과 유효성이 있는 것으로 판단되면, 유효 ID를 설정하고, 값(Value)을 가지고 있는 엘리먼트와 에트리뷰트를 읽는 단계와, 상기 읽은 정보를 인덱스 값으로 상기 패스 메타-스키마를 탐색하여, RDBMS에 저장할 테이블과 칼럼 정보를 검색하는 단계와, 상기 검색된 테이블 및 칼럼 정보를 기반으로 XQL 또는 XQuery 질의를 RDBMS(SQLite) 문법으로 변환하고, RDBMS에 접근하는 단계를 포함하는 것을 특징으로 한다.

바람직하게 상기 (f) 단계는 하나의 파일에 저장되어 있는 모든 엘리먼트들을 검색하는 방법, 부모 및 형제노드를 검색하는 방법 중 어느 하나의 방법을 이용하는 것을 특징으로 한다.

바람직하게 상기 모든 엘리먼트들을 검색하는 방법은 테이블에서 같은 DescriptionID_FID(칼럼 이름)를 가지고 있는 칼럼들만 추출하는 것을 특징으로 한다.

바람직하게 상기 부모노드를 검색하는 방법은 주석 메타-스키마 중 엘리먼트를 구분한 '/' 위의 엘리먼트를 부모노드로 추출하는 것을 특징으로 한다.

바람직하게 상기 형제노드를 검색하는 방법은 부모노드 검색을 통해 부모노드를 검색하는 단계와, 상기 검색된 부모노드 패스 이후로 ‘/’가 단 한번만 사용된 엘리먼트를 모두 형제노드로 추출하는 단계를 포함하는 것을 특징으로 한다.

바람직하게 상기 형제노드를 검색하는 방법은 패스 메타-스키마 내에 형제넘버 칼럼을 형성하고, 주석 메타-스키마 작성 시에 형제노드들에 같은 번호를 가지도록 설정하는 단계와, 형제노드 엘리먼트 검색시 형제넘버를 가지고 있는 엘리먼트들과 그에 해당하는 패스 정보를 구하여 형제노드를 추출하는 단계를 포함하는 것을 특징으로 한다.

본 발명의 다른 목적, 특성 및 이점들은 첨부한 도면을 참조한 실시예들의 상세한 설명을 통해 명백해질 것이다.

본 발명에 따른 임베디드 멀티미디어 기기에 적합한 MPEG-7 메타-데이터 저장 방법의 바람직한 실시예에 대하여 첨부한 도면을 참조하여 설명하면 다음과 같다. 그러나 본 발명은 이하에서 개시되는 실시예에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시예는 본 발명의 개시가 완전하도록하며 통상의 지식을 가진자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이다.

도 1 은 본 발명의 실시예에 따른 임베디드 멀티미디어 기기에 적합한 MPEG-7 메타-데이터 저장 방법을 나타낸 흐름도이다.

도 1을 참조하여 설명하면, MPEG-7에서는 멀티미디어 컨텐츠의 검색을 위한 다양한 방법들의 표준을 제안하고 있는데, 여기서는 한정된 메모리와 제한된 데이터 처리능력을 갖추고 있는 임베디드 멀티미디어 장치의 환경에 적합하도록, MPEG-7 스키마 중에서 필요한 부분들만을 추출하여, 개발자들에게 제공한다.

그러면 개발자들은 임베디드 멀티미디어 기기에 적합한 MPEG-7 메타-데이터를 저장하기 위한 수단을 이용하여, 먼저 주석 메타-스키마 생성부를 이용하여 임베디드 멀티미디어 기기를 위해 선택된 MPEG-7 스키마에서 실제 사용할 부분들에 주석(annotation)을 작성해서(S10), 주석 메타-스키마(annotation meta-schema)를 생성한다(S20).

그리고 개발자들은 매핑부를 이용하여 상기 생성한 주석 메타-스키마를 바탕으로 XML 스키마의 내장형 데이터 타입들을 SQLite의 내장형 데이터 타입으로 매핑한 후(S30), 테이블 및 칼럼 생성부를 이용하여 관계형 데이터베이스 관리 시스템(Relational Database Management System : RDBMS)에 저장하기 위해 주석 메타-스키마를 기반으로 RDBMS에 테이블과 칼럼을 생성한다(S40).

또한, 패스 메타-스키마 작성부를 이용하여 상기 주석 메타-스키마(annotation meta-schema)를 이용해서 패스 메타-스키마(path meta-schema)를 작성한다(S50). 참고로 패스 메타-스키마는 XML 문서를 입력하거나, RDBMS에 저장되어 있는 XML 인스턴스(instance)를 검색하기 위해서 주석 메타-스키마를 활용할 경우, 트리의 깊이만큼 탐색해야 하지만, 패스 메타-스키마를 활용할 경우 사용하는 인덱싱 알고리즘에 따라서 차이는 있지만, 한 두 번의 검색만으로 찾고자 하는 XML 문서가 저장되어 있는 위치를 알아낼 수가 있다.

따라서 XML 문서가 들어오면 XML-RDBMS 프로세서는 패스 메타-스키마에서 현재 XML 문서의 패스(path) 정보에 해당하는 테이블과 칼럼 정보(이름)를 추출하고(S60), XML-RDBMS 프로세서는 추출된 해당하는 테이블과 칼럼 정보를 바탕으로 XQL 또는 XQuery를 RDBMS의 문법으로 변환하여 RDBMS에 접근한다(S70).

그리고 RDBMS의 접근을 통해 자료의 저장 및 검색 등 필요한 작업들을 해당 테이블이나 칼럼에 요구한다(S80). 이때, RDBMS의 접근방법으로는 하나의 파일에 저장되어 있는 모든 엘리먼트들을 검색하는 방법, 부모 및 형제노드를 검색하는 방법 중 어느 하나의 방법을 이용한다.

이와 같은 단계로 이루어지는 임베디드 멀티미디어 기기에 적합한 MPEG-7 메타-데이터 저장 방법에 따른 과정을 실시예를 통해 보다 구체적으로 설명하면 다음과 같다.

먼저, 주석(annotation)의 작성(S10) 및 주석 메타-스키마(annotation meta- schema)의 생성(S20)을 상세히 설명한다.

사용자가 기존의 MPEG-7 스키마에서 자신이 필요한 부분들만 선택하여 XML 스키마를 선택할 경우, 사용자가 작성한 XML 인스턴스(instance)를 주석이 추가된 MPEG-7 스키마로써는 유효함(validation)을 확인할 수 없다. 왜냐하면, 사용자 임의로 중간노드를 제거할 수도 있기 때문에 유효함 체크(Validation Checking)를 위한 필요한 엘리먼트(Element)들이 존재하지 않는 문제가 발생할 수 있다.

이러한 문제를 해결하기 위해서 다음과 같은 두 가지 방법을 이용한다.

첫 번째는 사용자의 XML 인스턴스를 작성할 때, XML 스키마에 존재하지만 사용자의 필요에 의해 삭제한 조상 엘리먼트들의 주석을 사용자가 알지 못하게 MPEG-7 스키마에서 암시적으로 해당 엘리먼트에 추가하는 방법을 사용한다. 이 방법은 간단한 계산을 통해 상기 문제를 해결할 수 있는데 반해, 조상 엘리먼트들의 추가로 인한 불필요한 저장 공간의 사용이 발생되는 단점을 갖게 된다.

이의 대안으로 두 번째는 XML 인스턴스 작성 시에 삭제한 조상 엘리먼트들의 주석을 MPEG-7 스키마에 추가하지 않고, 사용자 인터페이스를 통해서 확인된 부분들만(엘리먼트 및 속성)으로 XML 문서를 작성하고, 다음 알고리즘과 같이 주석을 추가한다. 이렇게 함으로써, XML 스키마 처리시 발생할 수 있는 여러 가지 문제점(데이터 타입 상속에 부적절한 주석 적용, XML 스키마를 파싱하여 해당하는 정보들만 메모리에 올리는 문제 등)들을 해결할 수 있다.

다음 알고리즘은 MPEG7의 간단한 저장모델을 바탕으로 작성된 메타-스키마이다.

이때, 주석(Annotation) 태그는 <sqlite_Table>, <sqlite_Attribute>, <sqlite_Element>이고, 주석 활성화(action) 함수는 createColumn(), columnIntoTable(), createPrimaryKey(), createForeignKey()이다.

그리고 주석 정보는 위와 같이 엘리먼트에서 <sqlite_Table>, <sqlite_Element>, <sqlite_Attribute>로써 삽입한다. 이때, 테이블 생성과 관련한 정보를 나타내는 <sqlite_Table>는 문서내의 어느 엘리먼트에도 존재할 수 있지만, 테이블에 엘리먼트와 속성 정보를 삽입하는 태그인 <sqlite_Element>와 <sqlite_Attribute>의 경우에는 기본형이나 기본형에서 파생된 XML 스키마 데이터 타입인 경우에만 나타난다. 즉, 엘리먼트의 데이터 타입이 여러 개의 엘리먼트를 가지는 복합 데이터 타입이 아니라, 현재 데이터가 최종 데이터 타입인 경우에만 <sqlite_Element>를 삽입하여 해당 테이블에 칼럼을 생성하는 동작을 수행한다.

또한, <Format>이라는 엘리먼트 내에 ‘Name’이라는 자식(Child) 엘리먼트가 있고, 이 ‘Name’엘리먼트의 속성으로 href, xml:lang가 있을 때, 각각의 엘리먼트와 속성에 주석을 작성한다. 그리고 FileFormat에 대한 테이블을 생성하고, ‘Name’엘리먼트의 기본값이 일련값을 가지므로 주석을 추가할 수 있고, href와 xml:lang은 각각 ‘Name’의 속성을 나타내므로 ‘Name’ 다음에 위치한다.

다음으로, <sqlite_Table>, <sqlite_Attribute>, <sqlite_Element>와 같은 주석 태그들에 대해서 알아보고, createColumn(), columnIntoTable(), createPrimaryKey(), createForeignKey()와 같이 주석 태그 속에서 동작하는 함수들의 종류와 그 사용방법에 대해서 설명한다.

< sqlite _ Table > Tablename , createPrimaryKey (), createForeignKey()</ sqlite _ Table > - (1)

상기 (1)은 테이블에 대한 주석을 나타내고, Tablename의 테이블을 생성하라는 의미이다. 그리고 createPrimaryKey는 이 테이블에서 PrimaryKey를 생성하는 것을 의미하고, createForeignKey는 ForeignKey를 생성하라는 것을 의미한다. PrimaryKey와 ForeignKey를 생성하지 않을 경우에는 NULL을 표시한다. 그리고 PrimaryKey를 생성할 때, createPrimaryKey()의 인자값으로 default 값만 사용하고자 하는 경우 PrimaryKeyDefault라고 표시하고, ForeignKey의 경우에서도 createForeignKey()의 인자값으로 default 값만을 사용하고자 한다면, ForeignKeyDefault라고 표시한다. createPrimaryKey()와 createForeignKey() 함수의 자세한 용법은 아래 Table_Action 부분에서 상세히 설명한다.

아래 테이블 생성의 예를 잠시 들어보면 <sqlite_Table> Description, PrimaryKeyDefault, NULL</sqlite_Table>의 PrimaryKeyDefault는 createPrimaryKey(default, default, default, default)와 같은 역할을 한다. 따라서 createPrimaryKey(Description, Description_PID, Integer, Btree)와 같은 동작을 수행하여 Description 테이블에 데이터 타입은 Integer로 Description_PID 칼럼을 생성하고, Btree로 인덱싱을 한다. ForeignKeyDefault의 경우도 PrimaryKeyDefault의 경우와 같이 동작한다. 마지막으로, 하나의 비디오 파일에 속하지만, 서로 다른 계층 속에 있는 엘리먼트들의 자료들을 비교 및 분석하는 경우, 그 엘리먼트들의 공통 부모까지 조인을 해야 하는 문제가 발생한다. 현재 엘리먼트와 부모만이 ForeignKey로 연관되어 있기 때문에 이러한 문제가 발생하는데, 이와 같은 빈번한 조인을 방지하기 위해, 모든 테이블의 생성시, 최상위 테이블인 Description의 PrimaryKey를 ForeignKey로써 디폴트로 생성하도록 한다. 따라서 모든 테이블에 Description_FID를 디폴트로 생성한다.

< sqlite _ Attribute > Attributename , Action </ sqlite _ Attribute > - (2)

상기 (2)는 속성과 관련한 주석을 의미하고, Attributename은 실제 XML 인스턴스에서의 속성이름을 말하고, Action 내에서 한번 더 중복되어 표기될 수 있다. 이렇게 하는 이유는 현재 엘리먼트에 속한 속성 정보(이름)를 효율적으로 검색하기 위해서이다. Action 부분에는 실제 수행할 함수 이름을 나타낸다. 예를 들어, 현재 Attribute를 현재테이블의 칼럼으로 생성하려면 createcolumn() 함수를 사용하여 새로운 칼럼을 생성할 수 있다. Attribute는 엘리먼트의 속성을 나타내므로, 속성을 나타내고자 하는 엘리먼트의 바로 뒤에 sqlite_Attribute를 표시한다. 따라서 <sqlite_Attribute>가 발견되면, 가장 가까운 엘리먼트를 찾아서 그곳의 속성으로 나타내도록 한다. 예를 들어 다음과 같은 주석을 가진 XML 문서가 있을 때, Organization 속성은 MediaIdentification 엘리먼트에 속하고, 타입(type)은 EntityIdentifier 엘리먼트에 속하는 속성이라는 것을 의미한다.

< sqlite _ Element > Elementname , Action </ sqlite _ Element > - (3)

상기 (3)은 엘리먼트와 관련한 주석을 나타낸다. Elementname은 실제 XML 인스턴스에서의 엘리먼트 이름을 뜻하고, Action 부분에서는 실제 수행할 함수 이름 을 나타낸다. 위와 같이 현재 엘리먼트의 칼럼을 생성하고자 한다면, 여기서 createcolumn() 함수를 사용하면 된다. 앞서 설명했듯이, <sqlite_Element> 주석을 표시할 수 있는 엘리먼트는 사용자 지정의 데이터 형이 아니라, 기본형 혹은 XML 스키마에 정의되어 있는 파생형의 데이터 타입이어야 한다.

한편, Action에는 두 개의 함수가 들어갈 수 있는데, 하나는 칼럼을 생성하는 것을 의미하는 createcolumn이고, 다른 하나는 특정 테이블에 칼럼을 생성하라는 것을 나타내는 columnIntoTable이다.

createcolumn ( Columnname , Type , IndexType ) - (4)

상기 (4)는 Columnname의 이름을 가지고 Type의 데이터유형을 가지는 칼럼을 테이블에 생성하라는 것을 의미한다. Type에서는 Sqlite의 데이터 유형들이 표시되고, 현재 엘리먼트나 속성이 속한 조상 엘리먼트 중에서 테이블을 생성한 가장 가까운 조상 테이블에 칼럼을 생성한다. 이때, Indexing 알고리즘으로 사용할 방법을 IndexType으로 지정한다. 사용가능한 IndexType Btree, BinaryTree, Hash등이 있고, 사용하지 않을 경우 NULL을 표시한다. 아래 예제에서, Type 속성의 경우 부모 엘리먼트의 MediaIdentification 테이블에 타입(Type) 칼럼을 생성한다.

columnIntoTable ( Columnname , Tablename , Type , IndexType ) - (5)

상기 (5)는 Columnname의 이름을 가지고, Type의 데이터 유형을 가지는 칼럼을 생성하라는 것은 createcolumn()과 유사하지만, 생성할 테이블을 지정할 수 있다. createcolumn()의 경우에는 가장 가까운 조상 테이블을 조사하여 저장하지만, 여기서는 칼럼을 생성할 테이블을 직접 지시할 수 있다. Tablename에 저장할 테이블의 이름을 표시하는데, 만약 존재하지 않는다면, Error 메시지를 나타낸다.

다음으로 테이블을 생성할 때 관련있는 두 개의 함수에 대해서 설명한다.

두 개의 함수는 PrimaryKey의 생성과 관계있는 createPrimaryKey()와 ForeignKey의 생성과 관계있는 createForeignKey()가 있다.

createPrimaryKey ( Tablename , PrimaryKeyname , Type , IndexType ) - (6)

상기 (6)은 Tablename의 테이블에 PrimaryKeyname의 이름을 가진 PrimaryKey를 Type의 데이터 유형으로 생성한다. Indexing 알고리즘은 IndexType에서 지정한다. 각각의 인자들을 디폴트로 표시할 수 있는데, 이때의 디폴트 값은 다음 표 1과 같다.

인자 이름	Default Value
Tablename	<sqlite_Table>의 첫 번째 인자와 동일한 이름을 생성한다.
PrimaryKeyname	Tablename에 ‘_PID’를 붙여서 새로 만든다.
Type	Integer
IndexType	Btree

상기 (7)은 DestinationTablename 테이블의 PrimaryKeyname를 가리키는 ForeignKeyname 칼럼을 Type의 데이터유형으로 SourceTablename 테이블에 생성한다. 이때, Indexing 알고리즘을 IndexType으로 지정한다. 이때의 디폴트 값은 다음 표 2와 같다.

인자 이름	Default Value
SourceTablename	<sqlite_Table>이 속한 Element의 조상 중에서 테이블을 생성한 가장 가까운 조상을 나타낸다.
ForeignKeyname	SourceTablename의 PrimaryKey 이름에 '_FID'를 추가하여 이름을 만든다.
Type	Integer
DestinationTablename	<sqlite_Table>의 첫 번째 인자가 나타내는 이름과 동일한 이름을 나타낸다.
PrimaryKeyname	DestinationTablename에 '_PID'를 추가해서 이름을 생성한다.
IndexType	Btree

다음 예는 MediaIdentification 엘리먼트에서 MediaIdentification 테이블을 생성하고, EntityIdentifeier 엘리먼트, Type 속성, Organization 속성을 MediaIdnetification 테이블에 칼럼으로 각각 생성하는 것을 보여주고 있다.

이와 같은 방법을 통해 주석 메타-스키마의 생성이 완료되면, 다음으로 SQLite의 내장형 데이터 타입으로 매핑하는데, 이 매핑 방법(S30)을 상세히 설명하면 다음과 같다.

XML 스키마에 내장형 데이터 타입으로는, 기본형 DataType과 이 기본형으로부터 파생한 DataType으로 45가지 정도가 존재하다. 하지만, XML 인스턴스를 저장할 실제 저장 공간에 SQLite의 경우 5가지의 데이터 타입이 존재하지 않으므로, XML 인스턴스의 상당부분을 SQLite의 텍스트 데이터 타입에 저장하고, SQLite내의 관련함수를 이용하여, 이러한 인스턴스를 처리해야 한다. 주석의 타입에 들어가는 자세한 데이터 타입 변환은 다음 표 3 및 표 4와 같이 정의되어 매핑된다.

XML 스키마 기본형 Data Type	SQLite Data Type
boolean, number, decimal,	Integer
float, double	Real
string, duration, dateTime, time, date, gYearMonth, gYear, gMonthDay, gDay, gMonth, hexBinary, base64Binary, AnyURI, QName, QName, Notation	Text

XML 스키마 파생형 Data Type	SQLite Data Type
integer,nonPositiveInteger, negativeInteger, long, int, short, byte, nonNegativeInteger, unsignedLong, unsignedInt, unsignedShort, unsignedByte, positiveInteger	Integer
normalizedString, token, language, IDREFS, ENTITIES, NMTOKEN, NMTOKENS, name, NCName, ID, IDREF, ENTITY	Text

이때, 상기 표 3은 XML 스키마 기본형의 SQLite 타입 변환을 나타내고, 상기 표 4는 XML 스키마 파생형의 SQLite 타입 변환을 나타낸다.

이처럼 SQLite의 내장형 데이터 타입으로의 매핑(S30)이 완료되면, 다음으로 RDBMS에 테이블과 칼럼을 생성하는데(S40), 이 테이블과 칼럼의 생성 방법(S40)을 상세히 설명하면 다음과 같다.

XML 인스턴스를 RDBMS에 저장하기 위해서 해당하는 인스턴스를 저장할 공간을 RDBMS내에 테이블과 칼럼으로 만들어야 한다. 따라서 주석 메타-스키마를 입력으로 받고, 이 자료를 Depth-First-Search 알고리즘을 이용하여 <sql_Table>, <sql_Attribute>등의 주석 태그를 검색하고, 검색된 태그 내의 createColumn()등의 함수에 따라서 테이블 또는 칼럼을 생성한다.

도 3을 참조하여 주석 메타-스키마를 바탕으로 생성한 테이블과 칼럼을 살펴보면, ForeignKey를 이용하여 부모 자식 간의 관계를 나타내었고, 엘리먼트가 자식으로 엘리먼트를 가지는 혼합 데이터 유형을 자식으로 가지고 있는 경우 새로운 테이블을 생성하여 분기하도록 하였다.

또한, MediaFormat의 자식으로 Content, FileFormat, FileSize, BitRate가 있는데, 이중에서 Content와 FileFormat이 자식으로 Name 엘리먼트를 가지는 혼합 데이터 타입이므로 Content와 FileFormat은 각각 새로운 테이블을 생성하고, MediaFormat과 ForeignKey를 이용하여 부모 자식 간의 관계를 유지하고 있다.

그리고 Audio의 경우와 같이 테이블이나 칼럼을 생성하지 않는 엘리먼트라도 자식 엘리먼트에서 테이블이나 칼럼이 생성된다면, 태그간의 상호관계에 대한 사용자의 이해도를 높이기 위해서 XML 인스턴스 생성시에 [Audio]와 같은 태그를 포함하도록 한다.

이처럼 RDBMS에 테이블과 칼럼의 생성이 완료되면(S40), 다음으로 패스 메타-스키마(path meta-schema)를 생성하는데(S50), 이 패스 메타-스키마를 생성하는 방법(S50)을 상세히 설명하면 다음과 같다.

참고로 XML 문서로 되어 있는 메타-데이터를 RDBMS에 저장하거나, RDBMS에 저장되어 있는 메타-데이터를 검색하기 위해서는 사용자가 쿼리하고자 하는 엘리먼트나 속성들이 저장되어 있는 RDBMS 테이블과 칼럼 이름이 필요한데, 이렇게 엘리먼트나 속성들을 테이블과 칼럼에 연관시켜주는 테이블을 패스 메타-스키마(Path MetaSchema)라 명칭한다.

이와 같은 패스 메타-스키마를 생성하는 방법은 주석 메타-스키마에서 <sqlite_Table>등과 같은 주석을 탐색하고, 해당 엘리먼트나 속성의 패스(Path) 정보와 그들이 속해있는 테이블 및 칼럼 이름을 저장한다. 참고로 엘리먼트의 구분은 ‘/’를 이용하고, 속성정보를 나타낼 때는 ‘@’를 표시한다. 그리고 <sqlite_Table> 주석과 같이 테이블을 생성하는 경우 칼럼에는 NULL을 입력하고, 테이블은 현재 엘리먼트에 종속되어 있기 때문에, 부가적인 패스 정보가 들어가지 않는다.

아래 예제를 살펴보면, 3개의 테이블을 생성하고, 한 개의 속성을 만드는데, 첫 번째, Description의 경우, 패스(path)는 MPEG7/Description이 되고, 테이블 이름은 Description, 칼럼은 NULL이 된다.

하지만, Attribute를 생성하는 경우를 살펴보면, 패스정보는 MPEG7/Description/MultimediaContent/Audio/MediaInformation@id가 되고, 이 속성이 속한 테이블은 MediaInformation이며, 칼럼은 id이다.

간단한 저장 모델에 대한 주석 메타-스키마의 패스 메타-스키마를 생성하면, 다음 표 5와 같다.

Path	Table	Column
MPEG7/Description	Description	NULL
MPEG7/Description/MultimediaContent	MultimediaContent	NULL
MPEG7/Description/MultimediaContent/Audio/MediaInformation	MediaInformation	NULL
MPEG7/Description/MultimediaContent/Audio/MediaInformation@id	MediaInformation	id
MPEG7/Description/MultimediaContent/Audio/MediaInformation/MediaIdentification	MediaIdentification	NULL
MPEG7/Description/MultimediaContent/Audio/MediaInformation/ MediaIdentification/EntityIdentifier	MediaIdentification	EntityIdentifier
MPEG7/Description/MultimediaContent/Audio/MediaInformation/MediaIdentification/EntityIdentifier@Type	MediaIdentification	Type
MPEG7/Description/MultimediaContent/Audio/MediaInformation/MediaIdentification/EntityIdentifier@Organization	MediaIdentification	Organization
MPEG7/Description/MultimediaContent/Audio/MediaInformation/MediaProfile	MediaProfile	NULL
MPEG7/Description/MultimediaContent/Audio/MediaInformation/MediaProfile/MediaFormat	MediaFormat	NULL
MPEG7/Description/MultimediaContent/Audio/MediaInformation/MediaProfile/MediaFormat/FileSize	MediaFormat	FileSize
MPEG7/Description/MultimediaContent/Audio/MediaInformation/MediaProfile/MediaFormat/BitRate	MediaFormat	BitRate
MPEG7/Description/MultimediaContent/Audio/MediaInformation/MediaProfile/MediaFormat/Content	Content	NULL
MPEG7/Description/MultimediaContent/Audio/MediaInformation/MediaProfile/MediaFormat/Content/Name	Content	Name
MPEG7/Description/MultimediaContent/Audio/MediaInformation/MediaProfile/MediaFormat/Content/Name@href	Content	href
MPEG7/Description/MultimediaContent/Audio/MediaInformation/MediaProfile/FileFormat	FileFormat	NULL
MPEG7/Description/MultimediaContent/Audio/MediaInformation/MediaProfile/FileFormat/Name	FileFormat	Name
MPEG7/Description/MultimediaContent/Audio/MediaInformation/MediaProfile/FileFormat/Name@href	FileFormat	href
MPEG7/Description/MultimediaContent/Audio/MediaInformation/MediaProfile/FileFormat/Name@xml:lang	FileFormat	xml:lang

이와 같이 생성된 패스 메타-스키마를 패스 정보 키로서 Btree나 Hash등의 Indexing 알고리즘을 적용하면, 짧은 시간 내에 엘리먼트나 속성이 생성되어 있는 테이블과 칼럼정보(이름)를 얻을 수 있다(S60).

이처럼 테이블과 칼럼정보(이름)를 획득하게 되면(S60), 다음으로 XQL 또는 XQuery 질의를 질의 변환기를 통해 RDBMS(SQLite) 문법으로 변환하고, RDBMS에 접근하는데(S70), 이 방법(S70)을 상세히 설명하면 다음과 같다.

RDBMS에 XML 문서 처리를 위한 모든 테이블과 칼럼이 생성되고, 주석 메타-스키마를 바탕으로 패스 메타-스키마를 작성하고 나면, XML-RDBM 프로세서는 입력으로 들어오는 XML 문서를 주석 메타-스키마를 이용하여 XML 문서의 유효성(Validation)을 체크한다.

이때, 상기 체크 결과 주석 메타-스키마에 존재하지 않는 태그가 입력으로 들어오면, 처리할 수 없다는 "No Element or Attribute Exists" 에러 메시지를 내고 작업을 마친다.

그리고 상기 체크 결과 XML 문서가 유효성을 통과하면, 먼저, DescriptionID를 설정하고, 값(Value)을 가지고 있는 엘리먼트와 에트리뷰트를 읽어 들인다. 그리고 이들의 패스 정보를 인덱스 값으로 패스 메타-스키마를 탐색하여, RDBMS에 저장할 테이블과 칼럼 정보를 검색한다. 이어 XML-RDBMS 프로세서는 이 검색된 테이블 및 칼럼 정보를 바탕으로 RDBMS에 접근하게 된다. 그러면, 현재 엘리먼트의 값(Value)을 해당 칼럼에 저장할 수 있다.

이처럼 검색된 테이블 및 칼럼 정보를 바탕으로 RDBMS에 접근하게 되면(S70), 다음으로 저장된 자료들에 대한 검색 및 수정 등을 통해 필요한 작업들을 해당 테이블이나 칼럼에 요구하여 질의문을 처리하는데(S80), 이 방법(S80)을 상세히 설명하면 다음과 같다.

다양한 질의문이 들어 올수가 있는데, 이러한 질의문의 기본이 되는 것은 현재 특정 파일 내에 속하는 모든 정보를 검색하는 방법, 부모 및 형제노드를 검색하는 방법들이다.

따라서 특정 파일 내에 속하는 모든 정보 검색을 위해서는 테이블에서 같은 DescriptionID_FID를 가지고 있는 칼럼들만 추출하면 된다.

그리고 부모노드 검색은 엘리먼트의 구분을 ‘/’로 하였기 때문에, 한 단계만 위로 올라가면 된다. 아래 (8)의 경우 Name의 부모를 검색하고자 한다면, '/' 위가 부모의 패스를 나타내므로 쉽게 부모를 검색할 수 있다.

MPEG7/Description/MultimediaContent/Audio/MediaInformation/MediaProfile/FileFormat/Name - (8)

다음으로 형제노드 검색을 위해서는 두 가지 방법이 사용된다.

첫 번째는 먼저 부모노드 검색을 통해서 부모노드를 찾고, 주석 메타-스키마에서 부모노드 패스이후로 ‘/’가 단 한번만 사용된 엘리먼트를 모두 찾으면, 형제노드 엘리먼트를 모두 구할 수 있다. 즉, 아래 (9)의 경우에서 형제노드를 구하기 위해서 먼저 부모노드의 패스를 찾고, ‘MediaFormat/’ 이후로 엘리먼트의 이름만 적힌 경우를 모두 찾으면, MediaFormat, FileSize, BitRate가 Content의 형제노드임을 알 수 있다.

MPEG7/Description/MultimediaContent/Audio/MediaInformation/MediaProfile/MediaFormat/Content - (9)

두 번째로, 상기 첫 번째가 형제노드를 검색하는 횟수가 많아지면, 처리속도의 효율을 높이기 위해서 패스 메타-스키마 내에 SiblingNumber 칼럼을 만들고, 형제노드들은 같은 번호를 가지도록 한다. 그러면 쉽게 처리속도를 개선할 수 있게 된다. 따라서 형제노드 엘리먼트를 검색하고자 한다면 같은 SiblingNumber를 가지고 있는 엘리먼트들과 그에 해당하는 패스 정보를 구하면 된다. 이때 속성은 NULL 값을 가진다.

이에 따라 구조 매핑이 가지는 장점인 사용자 쿼리에 따른 최적의 테이블과 칼럼 생성을 유지하면서도, 사이즈가 큰 메타-스키마의 크기를 획기적으로 줄임으로써, 사용자의 쿼리에 응답할 때, 메모리의 사용량을 줄였고, 메타-스키마가 트리구조가 아니고, 인덱싱(Indexing)을 통한 접근이 가능하기 때문에 처리속도가 빨라지게 됨을 알 수 있다.

상기에서 설명한 본 발명의 기술적 사상은 바람직한 실시예에서 구체적으로 기술되었으나, 상기한 실시예는 그 설명을 위한 것이며 그 제한을 위한 것이 아님을 주의하여야 한다. 또한, 본 발명의 본 발명의 기술적 분야의 통상의 지식을 가진자라면 본 발명의 기술적 사상의 범위 내에서 다양한 실시예가 가능함을 이해할 수 있을 것이다. 따라서 본 발명의 진정한 기술적 보호 범위는 첨부된 특허청구범위의 기술적 사상에 의해 정해져야 할 것이다.

이상에서 설명한 바와 같은 본 발명에 따른 임베디드 멀티미디어 기기에 적합한 MPEG-7 메타-데이터 저장 방법은 다음과 같은 효과가 있다.

첫째, 기존의 방법으로 MPEG-7에 대한 메타-스키마를 생성한다면, 임베디드 멀티미디어 기기의 메모리에 올릴 수 없을 정도로 사이즈가 크지만, 본 발명과 같이 패스 메타-스키마를 사용한다면, 메모리에 관련정보를 올려놓고 사용자 쿼리에 빠르게 응답할 수 있다는 장점이 있다.

둘째, 메타-스키마(주석 메타-스키마) 생성시에 주석을 스키마의 속성으로 입력하는 것이 아니라, XML의 엘리먼트로 추가하였기 때문에, 별도의 파싱 없이 하나의 엘리먼트 내에서 여러 개의 테이블, 칼럼 생성이 가능하다.

셋째, MPEG-7 표준에서 추출한 스키마들을 바탕으로 멀티미디어 컨텐츠에 대한 메타-미디어를 XML문서로 작성하고, 이들을 RDBMS에 저장하는 방법들을 제안함으로써, 임베디드 멀티미디어 기기에서 MPEG-7 표준을 따라서 제작된 멀티미디어 메타-데이터의 검색 및 저장을 효율적으로 개선할 수 있다.

Claims (13)

1. 주석 메타-스키마를 생성하는 주석 메타-스키마 생성부와, 매핑을 수행하는 매핑부와, 테이블과 칼럼을 생성하는 테이블 및 칼럼 생성부와, 패스 메타-스키마를 작성하기 위한 패스 메타-스키마 작성부와, 질의를 RDBMS의 문법으로 변환하여 RDBMS에 접근하기 위한 XML-RDBMS 프로세서를 포함하여 구성되는 임베디드 멀티미디어 기기에 사용되는 MPEG-7 메타-데이터를 저장하기 위한 수단을 이용하여,

   (a) 상기 주석 메타-스키마 생성부를 이용하여 임베디드 멀티미디어 기기를 위해 선택된 MPEG-7 스키마에서 주석을 작성하여 주석 메타-스키마(annotation meta-schema)를 생성하는 단계와,

   (b) 상기 매핑부를 이용하여 상기 생성한 주석 메타-스키마를 기반으로 XML 스키마의 내장형 데이터 타입들을 SQLite의 내장형 데이터 타입으로 매핑하고, 상기 테이블 및 칼럼 생성부를 이용하여 RDBMS(Relational Database Management System)에 테이블 및 칼럼을 생성하는 단계와,

   (c) 상기 패스 메타-스키마 작성부를 이용하여 상기 생성한 주석 메타-스키마를 기반으로 패스 메타-스키마(path meta-schema)를 생성하는 단계와,

   (d) 상기 XML-RDBMS 프로세서를 이용하여 상기 생성된 패스 메타-스키마를 이용하여 해당하는 엘리먼트에 대한 RDBMS의 테이블 및 칼럼 정보를 추출하는 단계와,

   (e) 상기 XML-RDBMS 프로세서를 이용하여 상기 추출한 테이블과 칼럼 정보를 기반으로 질의를 RDBMS의 문법으로 변환하고 RDBMS에 접근하는 단계와,

   (f) 상기 RDBMS의 접근을 통해 특정 작업을 해당 테이블이나 칼럼에 요구하여 입력된 질의를 처리하는 단계를 포함하는 것을 특징으로 하는 MPEG-7 메타-데이터 저장 방법.
2. 제 1 항에 있어서, 상기 (a) 단계의 주석 작성은

   XML 인스턴스 작성 시에 삭제한 조상 엘리먼트들의 주석을 MPEG-7 스키마에서 암시적으로 해당 엘리먼트에 삽입하는 것을 특징으로 하는 MPEG-7 메타-데이터 저장 방법.
3. 제 1 항에 있어서, 상기 (a) 단계의 주석 작성은

   사용자 인터페이스를 통해서 확인된 엘리먼트 및 속성만으로 XML 문서를 작성하는 단계와,

   테이블을 생성하고자 하는 엘리먼트에, 속성을 가지는 엘리먼트 바로 다음에, 엘리먼트의 데이터 타입이 기본형이거나 XML 스키마 파생형의 경우의 엘리먼트 중 어느 하나에 주석을 삽입하는 단계를 포함하는 것을 특징으로 하는 MPEG-7 메타-데이터 저장 방법.
4. 제 1 항에 있어서, 상기 (b) 단계는

   상기 생성된 주석 메타-스키마를 입력으로 깊이 우선 검색(Depth-First-Search) 알고리즘을 이용하여 주석 태그를 검색하는 단계와,

   상기 검색된 태그 내의 함수에 따라서 테이블 또는 칼럼을 생성하는 단계를 포함하는 것을 특징으로 하는 MPEG-7 메타-데이터 저장 방법.
5. 제 1 항에 있어서, 상기 (c) 단계는

   상기 주석 메타-스키마에서 주석을 탐색하여 엘리먼트, 속성정보 및 테이블을 구분하는 구분단계와,

   상기 탐색을 통해 구분된 정보를 이용하여 해당 엘리먼트, 속성의 패스 정보와, 그들이 속해있는 테이블 및 칼럼 정보를 저장하여 패스 메타-스키마를 생성하는 단계를 포함하는 것을 특징으로 하는 MPEG-7 메타-데이터 저장 방법.
6. 제 5 항에 있어서,

   상기 구분단계는 엘리먼트의 구분은 ‘/’로, 속성정보의 구분은‘@’로, 테이블의 구분은 칼럼에 입력된 ‘NULL’을 통해 구분하는 것을 특징으로 하는 MPEG-7 메타-데이터 저장 방법.
7. 제 1 항에 있어서, 상기 (e) 단계는

   입력되는 XML 문서를 상기 주석 메타-스키마를 이용하여 XML 문서의 유효성(Validation)을 판단하는 단계와,

   상기 판단 결과 유효성이 없는 것으로 판단되면, 에러 메시지를 출력하고 작업을 종료하는 단계와,

   상기 판단 결과 유효성이 있는 것으로 판단되면, 유효 ID를 설정하고, 값(Value)을 가지고 있는 엘리먼트와 에트리뷰트를 읽는 단계와,

   상기 읽은 정보를 인덱스 값으로 상기 패스 메타-스키마를 탐색하여, RDBMS에 저장할 테이블과 칼럼 정보를 검색하는 단계와,

   상기 검색된 테이블 및 칼럼 정보를 기반으로 XQL 또는 XQuery 질의를 RDBMS(SQLite) 문법으로 변환하고, RDBMS에 접근하는 단계를 포함하는 것을 특징으로 하는 MPEG-7 메타-데이터 저장 방법.
8. 제 1 항에 있어서, 상기 (f) 단계는

   하나의 파일에 저장되어 있는 모든 엘리먼트들을 검색하는 방법, 부모 및 형제노드를 검색하는 방법 중 어느 하나의 방법을 이용하는 것을 특징으로 하는 MPEG-7 메타-데이터 저장 방법.
9. 제 8 항에 있어서,

   상기 모든 엘리먼트들을 검색하는 방법은 테이블에서 같은 칼럼 이름을 가지고 있는 칼럼들만 추출하는 것을 특징으로 하는 MPEG-7 메타-데이터 저장 방법.
10. 제 8 항에 있어서,

    상기 부모노드를 검색하는 방법은 주석 메타-스키마 중 엘리먼트를 구분한 '/' 위의 엘리먼트를 부모노드로 추출하는 것을 특징으로 하는 MPEG-7 메타-데이터 저장 방법.
11. 제 8 항에 있어서, 상기 형제노드를 검색하는 방법은

    부모노드 검색을 통해 부모노드를 검색하는 단계와,

    상기 검색된 부모노드 패스 이후로 ‘/’가 단 한번만 사용된 엘리먼트를 모두 형제노드로 추출하는 단계를 포함하는 것을 특징으로 하는 MPEG-7 메타-데이터 저장 방법.
12. 제 8 항에 있어서, 상기 형제노드를 검색하는 방법은

    패스 메타-스키마 내에 형제넘버 칼럼을 형성하고, 주석 메타-스키마 작성 시에 형제노드들에 같은 번호를 가지도록 설정하는 단계와,

    형제노드 엘리먼트 검색시 형제넘버를 가지고 있는 엘리먼트들과 그에 해당하는 패스 정보를 구하여 형제노드를 추출하는 단계를 포함하는 것을 특징으로 하는 MPEG-7 메타-데이터 저장 방법.
13. 제 1 항에 있어서,

    상기 (f) 단계의 특정 작업은 자료의 저장 및 검색 중 어느 하나인 것을 특징으로 하는 MPEG-7 메타-데이터 저장 방법.

Images