* 참고 : Web 2.0 Innovation

Atom :  웹로그나 최신 소식과 같은 웹 컨텐츠의 신디케이션을 위한 XML 기반의 문서 포맷이자,
           웹로그 편집을 위한 HTTP 기반의 프로토콜.
           XML에 의한 컨텐츠 전송 기술.다만 RSS에서의 RDF/XML 구문은 사용하지 않음.
           RSS와 함께 RSS/Atom 피드라고 불리기도 함
           RSS의 버전 난립과 RSS에서의 RDF 작성시 복잡한 문장구성 문제를 해소하기 위해 RSS의
           이념을 계승하면서 IETF에서 새롭게 정의한 표준안
           Rss에서는 Site에 대한 Summery만 가능하고, Article에 대한 Summery가 불가능한데 비하여,
           Atom에서는 Article 각각에 대하여 Summery를 작성할 수 있도록 되어있고 그 내용에 plain text나
           XML Tag를 기록할 수 있도록 하여 보다 높은 확장성과, 글 내용의 재활용이 가능함
           내부적으로 AtomAPI에서 REST에서의 HTTP 리소스 패턴 네가지(Post, Get, Put, Delete)를
           사용하고 있음.

SEO (Search Engine optimization) : 검색엔진 최적화, 특정 검색어를 검색엔진을 통해 검색했을 때
                   검색결과의 상위에 자신의 웹페이지가 표시되도록 웹페이지를 구성하는 일 또는 이를 위한
                   기술. 보다 많은 트래픽을 자신의 사이트로 유도하기 위해 다양한 SEO 대책을 실시하게됨
                   검색엔진이 쉽게 이해할 수 있는 XHTML, HTML 태그를 구사하거나 본문 곳곳에 검색어
                   배치, 신뢰할 수 있는 외부 사이트로부터 링크 걸기 등의 방법이 사용 됨.
                   블로그 툴에 의해 만들어진 컨텐츠 들은 별도의 SEO를 거치지 않아도 자체적으로 아주
                   효과적인 SEO를 보여준다.

SEM (Search Engine Marketing) : 검색엔진에 의해 검색된 페이지에서의 사용자에 대한 가시성을
                   높이는 방법으로 홍보를 하고자 하는 인터넷 마케팅의 한 형태. SEO가 하나의 접근
                   방법으로 여겨지고 있음.

Search Spam (검색스팸) : SEO가 악용되어 검색어와 전혀 관련없는 웹사이트가 검색되는 것, 그 기술

REST (Representational State Transfer) : XML over HTML. WEB과 같은 분산 하이퍼미디어를 위한
                    소프트웨어  아키텍처의 한 형식. 인터넷 서비스의 프로그램 장착에 있어 간단한 HTTP
                    (Post, Get, Put, Delete)를 사용하고 XMl을 이용하여 태그 확장 및 데이터 처리를
                    가능케 하는 아키텍처.
                    도메인 지향 데이터를 HTTP위에서 SOAP이나 쿠키를 통한 세션 트랙킹 같은 부가적인
                    전송 레이어 없이, 전송하기 위한 아주 간단한 인터페이스
                    OPEN API를 SOAP으로만 이용하기에는 심플하지 못함이 나타남에 따라 그 SOAP에 대한
                    대안으로 REST가 발전해오게 되었음. 구글의 Open API도 초기 SOAP 기반이었으나 현재
                    REST 기반으로 대체됨. 대부분 포탈이나 검색엔진에서 SOAP을 지원하나 실제 REST가
                    대세가 됨

Microformat  : XHTML 에 메타데이타를 넣어 컨텐츠 정보를 상세하게 구조화하려는 표준화 방안
                    간단한 XHTML, XML을 이용하여 블로그 기사를 구조하함으로써 사람에게나
                    프로그램에게나 보기 쉬운 형태로 만들어준다.
                    적용예 - hCard, hCalendar, hReview, relLicense(라이센스 정보를 정의하는 XML포맷)

XFN(XHTML Friend Network) : 소셜 네트워킹의 정보를 정의하는 XML 포맷

Structured Blogging : 블로그 기사 등의 정보를 구조화된 XML 포맷으로 엄밀하게 정의하려는 활동
                               Structured Blogging.org에서 추진

Permalink :  = 고정링크 = 변경되지 않는 고유의 URL (=URI)
                 표준을 준수하는 모든 블로그 글은 이러한 고유의 URL을 가지고 있음

Tracback : 블로그에서 사용하는 기능으로 다른 사람의 블로그를 읽고 그에 대한 의견을 자신의
                블로그에 쓴 뒤 원래의 글과 서로 링크시킬 수 있는 기능. 링크 후에는 링크한 다른 사람의
                블로그 컨텐츠에 트랙백으로 자신이 쓴 글이 연결되었다고 표시됨.
                기존 댓글이 의견을 다는 해당 컨텐츠에만 표시되는 것에 비해 양방향 커뮤니케이션을 더욱
                강화한 방법이라 할 수 있다. 국내에서 엮인글, 관련글 로도 부름

Live Web : 블로그의 등장으로 컨텐츠가 날로 증가하고 링크에 의해 정보의 조직화가 이루어져
                각 블로그 기사로부터 연결되는 하이퍼링크나 트랙백을 통해 다이나믹하게 연결되는
                블로그 컨텐츠를 살아 있는 웹이라는 뜻으로 이렇게 부름

Blogosphere : 블로그나 블로거에의해 구성되어 있는 정보공간이나 커뮤니티를 뜻함.
                     블로그계 또는 블로그권으로 번역하기도 함

Alpha Blogger : Blogosphere  안에서 많은 독자들에게 읽히고 있는 영향력 있는 블로거를 칭함
                       Power Blogger라고도 함

CMS(Contents Management System) :  웹사이트 컨텐츠의 작성,편집,전송을 관리하는 시스템

Blog : Web Log 라고도 하며 보통 시간순으로 새로운 정보를 표시하는 일기 형식의 웹 사이트 또는
         컨텐츠 관리 방법. CMS의 일종으로 봄

Wiki : 웹 브라우저에서 간단하게 기사의 작성, 편집 등을 할 수 있도록 하는 오픈소스 CMS
        많은 사람이 공동으로 컨텐츠를 추가, 편집, 관리할 수 있는 기능을 제공함
        편집자가 XHTML 등의 마크업 언어에 대한 지식이 없다 하더라도 문서구조를 정리하거나
        하이퍼링크를 작성할 수 있는 독자적 컨텐츠 정형규칙이 정해져 있음
        적용예 - Wikipedia, MediaWiki, Livedoor Wiki

Pod Casting : = Audio Casting , mp3 음성 + RSS 2.0 Feed
                    mp3 음성이 RSS 2.0 Feed와 함께 전송됨. 애플의 아이튠즈나 팟캐스팅을 지원하는
                    RSS 리더에 팟캐스팅 방송 RSS를 등록해두면 업데이트 될 때 자동적으로 새로운 파일을
                   수신하고, 수신된 컨텐츠는 업데이트된 항목이 자동적으로 아팟이나 지원하는 mp3
                   플레이어에 전송됨

Video Casting
         영상 + RSS Feed

Feed Search :  <-> Link Search
          RSS/ATOM Feed 대상의 검색 기능, 메타데이타 검색
          Web2.0 및 Semantic Web 이 활성화 될 수록 태깅 검색이 링크검색보다도 더 중요해지고
          트래픽 증가가 예상됨

Social Tagging : 큰 범주에서는 단순히 태깅을 의미하기도 하며 작은 의미상 규정으로 하면 어떤
         컨텐츠에 대해 자신이원하는 키워드를 붙여 분류한 것을 공개하여 다른 사람들도 태그를 달 수
         있도록으로써 태그 분류의 정확성을 높여가는 태깅 형태
         적용 예 - 테크노라티 (Technorati)

Social Bookmark : 인터넷에서 웹페이지를 북마크 하여 관리, 공유 하는 서비스로 사용자 태그를
                          추가할 수 있다.

Tag Cloud : weighted list라고도 불리는 태그 클라우드는 태그로 된 각 단어들을 시각화 하는 방법으로
                 보다 많은 링크가 되어있는 태그의 텍스트를 크게 표시해주는 시각화 방법
                 Flicker, Technorati 등에서 먼저 시작됨

FOAF(Friend of a Friend) : 친구를 통해 친구를 만들어 나가는 인간관계를 말함
                                      시맨틱 웹 기술을 적용해 관계성을 확장하는 대표적인 기술로
                                      SNS에서의 관계성 확장을 표현하는 기술 (사례:링크나우,세다리 등)

Content Syndication : 컨텐츠 배급(공급) : XML을 기초로 하는 데이터 형식으로서 사용자의
         블로그에 포함되어 있는 RSS(Really Simple Syndication)기능을 통해 사용자들이 자기가
         원하는 정보를 수동적으로 받아볼 수가 있도록 함으로써 정보가 능동적으로 사용자들을
         찾아간다는 개념

인터넷 광고 :
     CPM(Cost Per Millenium) 방식 - 광고노출 횟수로 광고가격 책정, 전달의 노출 횟수 기준으로 광고
                                                   단가 지불하고 해당 키워드 광고를 광고주가 구매하는 방식
                                                   구매한 이후의 광고 효과에 대해 책임지지 않음, 정액제 형태
    P4P(Pay for Performance) 방식 - 실제 클릭이 발생했을 때 광고비를 지불하난 CPC(Cost per Click)
                                                   방식임. 오버추어(검색결과인것처럼 위장,퇴조) 및 구글(광고임을
                                                   알림, 증가), 종량제 형태

오늘은 RDF와 Ontology(온톨로지)의 역사(?), 발전과정에 대해 좀 살펴보겠습니다.

*  참고 : 시맨틱웹(김중태 저) 및 웹 검색 자료

[RDF - Resource Desdcription Framework]

 - RDF Schema(스키마) = RDFS : 메타데이타의 무결성을 보증하기 위해 사용하는 메타언어라 할 수 있다. RDFS는 자원과 특성의 집합을 네임스페이스로 표현한다.
 - RDF는 자원(Resource), 속성(Property), 속성값(Property Value)을 묶어서 하나의 단위로 취급한다
 - RDF는 의미(Semantics), 구조(Structure), 구문(syntax)에서 공통 규칙을 이용한다
 - RDF는 언어의 주어, 동사, 목적어에 해당하는 Subject, Predicate, Object를 가지며, 이를 포함한 것을 문장(Statement)라고 한다


[Ontology]

 - OIL(Ontology Interface Layer)은 RDF로 표현된 메타데이타에서 필요한 정보를 추론하고, 통합하기 위한 도구이다.
 - DAML+OIL(DARPA Agent Markup Language+Ontology Interface Layer)은 RDF의 단점을 보완해 온톨로지를 구축하기 위한 확장언어이다.
 - OWL(Ontology Web Language)은 온톨로지의 공유와 출판을 위해 마련한 시맨틱 마크업언어로 DAML+OIL을 기반으로 하고 있다
 - OWL의 개발 이유는 기존에 나온 자바나 스크립트 언어로는 온톨로지 구축이 비효율적이라고 판단했기 때문
 - 초기의 Markup 언어인 CycL(CYCR Language), KIF(Knowledge Interchange Format), Ontolingua 등이 온톨로지 표현에 적합하지 않았던 이유도 크다
 - 대표적인 OWL
    1) OIL (Ontology Inference Layer) : RDF, RDF Schema 기반의 연구 진행, 유럽 IST(Information Society Technologies)  중심으로 연구
    2) DAML(DARPA Agent Markup Language) : RDF, RDF Schema 기반의 연구 진행, 미국 국방과학연구소(DARPA)의 지원, Agent 사이의 통신에 유용하나 온톨로지 표현에 문제가 있어 DAML+OIL로 연구 진행됨
    3) SHOE(Simple HTML Ontology Extensions) : 메릴랜드 대학 중심으로 연구, HTML에서 온톨로지 표현이 가능한 언어
    4) N3(Notation 3) : 사용자 중심으로 설계된 언어로 RDF와 함께 서로 보완 역할을 수행하도록 만들었다.
 - ezOWL(Easy OWL) : ETRI에서 개발한 비주얼 방식의 온톨로지 저작도구, DAML+OIL, RDF/RDFS 지원


             

SOAP과 RDF

원격 프로시져 호출을 넘어서..

난이도 : 초급

Uche Ogbuji, 컨설턴트, Fourthought, Inc

2002 년 2 월 01 일

이 글을 통해 RDF 모델에서 정보를 교환하는데 SOAP이 사용될 수 있는 방법들이 검토된다. RDF 모델의 기본적인 데이터를 PC 교환이나 RDF/XML 직렬화 형식에서 모델의 부분들을 직접 전달하는데 필요한 SOAP 인코딩으로 변환하는방법을 연구한다.

SOAP은 저수준 인터넷 프로토콜을 통해 XML payload를 전송하는데 쓰이는 전송 프로토콜이다. 1.2 이전의 전송 스팩은 프로그래밍 언어 구조체의 직렬화로 연동된 XML의 기본 인코딩에 빌트인되었다. 그와같은 인코딩은 원격 프로시져 호출(RPC) 시스템의 요소이다. RPC 인코딩의 다른 예제는 "구(classic) RPC의 External Data Representation (XDR)이고 CORBA의 Common Data Representation (CDR)이 있다. 이와 같이 유사한 것들로 인코딩을 번들한 결과 SOAP은 명확히 애플리케이션 프로그래밍 느낌을 띠게되고 일반적인 데이터 교환의 유용성은 의심스러워졌다.

초기의 "SOAP의 향기"는 많은 논란을 일으켰다. 우선, 혼합 전송과 데이터 인코딩은 통신에 있어서 매우 어지러운 접근방식이다. 수십년동안 네트워킹 관례로 되어있는 레이어드 프로토콜을 무시한 것이다. 결국, HTML 마크업 스팩은 HTTP 스팩으로 삽입되지 않는다. 두 번째, 탁월성을 위해 RPC 비슷한 인코딩을 선택한다면 SOAP을 이상한 지점에 놓는 것이다; 이것은 이전 XML RPC 메커니즘 보다 좀 더 강력한 힘을 가지고 있지만 실제로는 덜 효과적이다. XML의 수다스러움과 HTTP, SMTP 등과 같은 좀 더 일반적인 아키텍쳐 때문이다. 차세대 RPC 로서 SOAP의 유일한 장점은 Microsoft와 CORBA 진영을 통합했다는 것이다; 이는 중요하지만 SOAP이 반드시 약속해야할 부분은 아니다.

RPC로서의 SOAP의 한가지 중요한 결과는 그와 같은 시스템이 일반적으로 차세대 EDI 의 야망을 가진 웹 서비스에게는 완벽히 맞지 않는다는 점이다. 만일 웹 서비스가 네트워크를 통한 새로운 방식의 비지니스가 된다면 프로그래밍 언어 API의 레벨이 아닌 비지니스와 합법적 요청의 레벨에서 통신하는 전송 메커니즘을 필요로 한다. 그리고 국제적 전자 비지니스 통신을 위한 시스템을 만드는데 XML을 사용하는 것이 목적인 ebXML 이니셔티브는 몇몇의 다른 영향력있는 곳과 마찬가지로 SOAP 사용을 주저하게 한다.

그 이후로 상황은 많이 안정되었다. SOAP 1.2은 특별한 인코딩 의존성을 다소 탈피했고, 대부분의 프로들은 ebXML을 포함하여 SOAP을 사용하고 있다. 대부분의 SOAP 구현은 여전히 특별한 SOAP 인코딩을 독점적으로 사용하고 있지만 점점 개방될 것이다. 광범위한 인코딩 선택을 위해 플러그인 아키텍쳐를 이용하여 좀더 다양한 통신 문제를 다루게 될 것이다. 그중 하나의 문제는 메테데이터를 교환하는 것이다.

Resource Description Framework (RDF)은 그와 같은 메타데이터 교환을 해결하는 몇 가지 도구를 갖춘 모델링 시스템이다. 이 글에서는 그와 같은 메타데이터의 인코딩을 위해 어떻게 RDF가 SOAP과 함께 사용될 수 있는지를 검토한다. 또한 RDF에 인코딩된 데이터 인스턴스가 어떻게 직접적으로 SOAP 인코딩으로 변환하지 않고 직접 전송될 수 있는지도 검토한다. SOAP과 RDF에 익숙해져야 한다. (참고자료). IBM developerWorks XML 존의 Thinking XML 칼럼을 참조하기 바란다.

RDF라는 멋진 배

RDF를 갖추고 있을 경우 한 시스템에서 또 다른 SOAP으로 옮기기 위해 할 수 있는 일을 설명하겠다. Thinking XML 칼럼에서 소개한 지속적인 이슈 추적 프로젝트에서 예제를 들어 설명하겠다. 한 시스템에 추가된 이슈의 상세한 부분을 하나의 원격 머신으로 교환하기 원한다고 해보자. 이것은 분산화된 이슈 트래커의 기초가 될 수도 있다. RDF 직렬화에서 이슈가 어떻게 보이는지의 예제는 Listing 1에 나와있다.

Listing 1: RDF/XML serialization

<?xml version="1.0"?> <rdf:RDF xmlns:it="http://rdfinference.org/schemata/issue-tracker/" xmlns:dc="http://purl.org/dc/elements/1.1#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xml:base="http://rdfinference.org/versa/issues"> <it:issue rdf:ID="0101"> <dc:relation rdf:resource="http://rdfinference.org/versa/0/2"/> <dc:identifier>0101</dc:identifier> <dc:creator rdf:resource="mailto:uche.ogbuji@fourthought.com"/> <dc:date>2002-01-27</dc:date> <dc:title>Data type conversions</dc:title> <dc:description>Not all the data type conversions listed make sense. In particular the question of how to convert numeric types to resources and vice versa require much thought.</dc:description> </it:issue> </rdf:RDF>

이것은 웹 서비스에 대해 발생한 예제 이슈이다. 이슈 그 자체는 URI http://rdfinference.org/versa/issues#0101에 의해 구분된다. 이는 문서의 기본 URI를 받아서 이슈를 나타내는 유형화된 노드에서 rdf:ID 속성에 의해 주어진 것 처럼 조각을 추가하는 것이다. 문서 요소의 기본 URI는 xml:base 속성을 사용하여 http://rdfinference.org/versa/issues 처럼 주어진다. 그런다음 이슈 자체에 대한 여러 문장을 만들면서 Dublin Core의 dc:relation 메타데이터 태그를 사용하여 이슈가 참조할 리소스를 주는 것이 중요하다. 또한 친근한 디스플레이를위해 이슈의 전체 URI를 단축한 식별자, 이슈의 작성자, 제출 날자, 간단한 제목, 설명등을 제공한다.

가장 중요한 문제는 어떻게 이것이 추상적 RDF 모델로 변환되는 지가 중요하다. 예를 들어, 그림 1은 RDF 시각화 툴로 만들어졌다. Dan Brickley의 온라인 RDF visualizer를 사용하여 비슷한 그래프를 만들 수 있다.

그림 1: 샘플 RDF 모델의 그래프

이제 SOAP 메시지로 이 모델을 전송하는 두 가지 방법을 살펴보자; 우선 SOAP 인코딩으로 변환하고 그 다음 직접 RDF에서 인코딩 한다.

SOAP 인코딩 사용하기

우선, 전송에 필요한 메소드를 이해해야 한다. 여러분이 정의한 RDF는 데이터 묶음이고 메시지로 데이터 묶음을 전송하는 것이다. 이 데이터를 받은 사람이 무엇을 할것인지에 따라 이름을 정한다. 이 경우 원격 서버에 추적할 새로운 이슈가 있다는 것을 알린다. 그래서 newIssue 메소드를 호출했다. 이제부터 여러분은 SOAP 인코딩을 사용하고 있다는 것을 주목하고 메소드 이름을 RPC용 SOAP 바인딩을 가진 프로그래밍 언어에 적합하도록 맞추어야 한다.

그런다음 새로운 이슈 객체를 전송할 방법을 찾아야 한다. 새로운 객체의 ID와 속성을 전송하는 방법이 있다. 기본적으로 새로운 이슈 객체의 각 속성을 없애고 메시지 매개변수로 변환한다. SOAP 인코딩은 타입 정보로 가득 차있기 때문에 각 매개변수를 type (Listing 2 참조)으로 꾸며야 한다.

Listing 2: newIssue SOAP message

http://www.w3.org/2001/12/soap-envelope"> <env:Body> <itsoap:newIssue env:encodingStyle="http://www.w3.org/2001/12/soap-encoding" xmlns:itsoap="http://rdfinference.org/schemata/issue-tracker/soap" xmlns:it="http://rdfinference.org/schemata/issue-tracker/" xmlns:dc="http://purl.org/dc/elements/1.1#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <dc:identifier xsi:type="xs:nonNegativeInteger">0101</dc:identifier> <dc:relation xsi:type="xs:anyURI">http://rdfinference.org/versa/0/2</dc:relation> <dc:creator xsi:type="xs:anyURI">mailto:uche.ogbuji@fourthought.com</dc:creator> <dc:date xsi:type="xs:date">2002-01-27</dc:date> <dc:title xsi:type="xs:string">Data type conversions</dc:title> <dc:description xsi:type="xs:string">Not all the data type conversions listed make sense. In particular the question of how to convert numeric types to resources and vice versa require much thought.</dc:description> </itsoap:newIssue > </env:Body> </env:Envelope>

모든 값들은 SOAP 인코딩 규칙이 요구하는 대로 엘리먼트의 내용에 위치된다. 여기에는 RDF의 리소스로서 마킹된 값들도 포함하고 있다. 그리고 anyURI데 이터 타입에 주어진다. 이것은 URI 레퍼런스인 값들 뿐만아니라 전체 URI도 허용한다는 것을 주목하자. 그와 같은 모든 메시지가 이 포맷을 갖고 있다면 메시지 엘리먼트에 대한 XML 스키마 정의를 내림으로서 매번 데이터 타입을 반복해야 하는 필요를 없앨 수 있다. Listings 3 과 Listing 4 는 그와 같은 schemata의 조각들이다.

Listing 3: newIssue SOAP message element용 schema fragment

<?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope"> <env:Body> <itsoap:newIssue env:encodingStyle="http://www.w3.org/2001/12/soap-encoding" xmlns:itsoap="http://rdfinference.org/schemata/issue-tracker/soap" xmlns:it="http://rdfinference.org/schemata/issue-tracker/" xmlns:dc="http://purl.org/dc/elements/1.1#" > <dc:identifier>0101</dc:identifier> <dc:relation>http://rdfinference.org/versa/0/2</dc:relation> <dc:creator>mailto:uche.ogbuji@fourthought.com</dc:creator> <dc:date>2002-01-27</dc:date> <dc:title>Data type conversions</dc:title> <dc:description>Not all the data type conversions listed make sense. In particular the question of how to convert numeric types to resources and vice versa require much thought.</dc:description> </itsoap:newIssue > </env:Body> </env:Envelope>

Listing 4: newIssue SOAP message parameter elements용 schema fragment

<!-- with target namespace = http://purl.org/dc/elements/1.1# --> <xsd:element name="identifier" type="xsd:nonNegativeInteger"/> <xsd:element name="relation" type="xsd:anyURI"/> <xsd:element name="creator" type="xsd:anyURI"/> <xsd:element name="date" type="xsd:string"/> <xsd:element name="title" type="xsd:string"/> <xsd:element name="description" type="xsd:string"/>

 

이러한 것들은 SOAP 메시지를 Listing 5 처럼 단순하게 만든다.

Listing 5: 인라인 타입의 데코레이션이 없는 newIssue SOAP message

<?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope"> <env:Body> <itsoap:newIssue env:encodingStyle="http://www.w3.org/2001/12/soap-encoding" xmlns:itsoap="http://rdfinference.org/schemata/issue-tracker/soap" xmlns:it="http://rdfinference.org/schemata/issue-tracker/" xmlns:dc="http://purl.org/dc/elements/1.1#" > <dc:identifier>0101</dc:identifier> <dc:relation>http://rdfinference.org/versa/0/2</dc:relation> <dc:creator>mailto:uche.ogbuji@fourthought.com</dc:creator> <dc:date>2002-01-27</dc:date> <dc:title>Data type conversions</dc:title> <dc:description>Not all the data type conversions listed make sense. In particular the question of how to convert numeric types to resources and vice versa require much thought.</dc:description> </itsoap:newIssue > </env:Body> </env:Envelope>

미가공(raw) RDF 보내기

이 글을 시작하면서 언급했지만 SOAP을 사용하기 위해서 SOAP 메시지를 RPC 형식으로 바꿀 필요는 없다. RPC 통합 필요성을 절감하는 것이 아니라면 데이터를 보내고 이를 원격 시스템에서 자유롭게 프로세스하는 접근 방식을 취할 수 있다. SOAP을 위한 공식적인 RDF 인코딩은 없지만 이 논의는 RDF와 SOAP의 규약과 규정에 근거한 것이다.

가장 단순한 접근 방식은 rdf:RDF 엘리먼트를 SOAP 바디의 하나의 상위 레벨 엘리먼트로 만드는 것이다. (Listing 6).

Listing 6: RDF와 같은 SOAP 메시지

<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope"> <env:Body> <rdf:RDF env:encodingStyle="http://rdfinference.org/rdfws/soap-encoding" xmlns:it="http://rdfinference.org/schemata/issue-tracker/" xmlns:dc="http://purl.org/dc/elements/1.1#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" > <it:issue rdf:about="http://rdfinference.org/versa/issues#0101"> <dc:relation rdf:resource="http://rdfinference.org/versa/0/2"/> <dc:identifier>0101</dc:identifier> <dc:creator rdf:resource="mailto:uche.ogbuji@fourthought.com"/> <dc:date>2002-01-27</dc:date> <dc:title>Data type conversions</dc:title> <dc:description>Not all the data type conversions listed make sense. In particular the question of how to convert numeric types to resources and vice versa require much thought.</dc:description> </it:issue> </rdf:RDF> </env:Body> </env:Envelope>

 

인코딩 ID가 사용되고, http://rdfinference.org/rdfws/soap-encoding 는 비표준이고 기본적으로 RDF/XML을 SOAP 메시지 바디로 직접 임베딩하는 것을 명령하고 있다. 메시지 형식과 단순한(plain) 형식 사이의 한 가지 주요한 차이점은 rdf:about 이 이슈 리소스를 구분하기 위해 사용된다는 점이다. SOAP 전송을 위해 RDF 모델을 직렬화하는 중요한 원칙이 있다: 인라인 선언을 피하는 것이다. xml:base을 사용하여 ID에 대한 기본 위치를 고정할 수 있다면 그와같은 원칙은 불필요하다. 하지만 인라인 전송 리소스의 생명주기와 소유권을 위한 어떤 분명한 의미를 상상하기는 힘들다. 어떤 상황에서도 피할 수 없다.

위로

결론

SOAP과 RDF가 상호작동할 수 있는 방법에 있어서 다른 접근방식들이 있다. 실제로 이것은 RDF 사용자들이 웹 서비스를 발견할 때 지속적으로 흥미를 가져가는 부분이다. 자세한 내용은 참고자료 부분을 참조하기 바란다. XML 기반 데이터를 직렬화하는 일반적인 시스템은 웹 서비스 세계를 더욱 풍요롭게 만들것이다.