1. E-Commerce Integration Meta-Framework 인공지능 연구실 한기덕

2. 2 개요  1. ECIMF 의 소개  2. Semantic Web 과 Ontology  3. ECIMF Project Details  4. General Methodology  5. Proof-of-concept : scenario analysis

3. 3 1. Introduction  E-Commerce Integration Meta-Framework 란 ? – 존재하는 system 을 이용하여 사용자의 system 과 관 계없이 secure interoperability 을 제공하기 위해 모든 e-commerce 사용자를 위한 methodology, prototype tools, modeling language 를 제공하는 meta-framework – 이 meta framework 의 중요 목적은 존재하는 각각의 e-commerce frameworks 사이의 개념과 내용을 mapping 을 통해 interoperability 를 수월하게 하는 것 이다.

4. 4 1. Introduction  Interoperability 란 ? – 사전적 의미 : 1. 정보 처리 상호 운용 ( 의 가능성 ). 2. 동맹국에 의한 시설 · 서비스의 상호 이용. –Business 의 측면에서 두 기업이 같은 e- commerce framework 를 사용하여 사업 과정 을 설명하는 것

5. 5 2. Semantic Web & Ontology  Semantic Web –Machine-processible semantics of data Semantic annotation, XML, RDF –Explicit representation of the semantics of data accompanied with domain theories (i.e. ontologies) –Lead to a highly knowledgeable world-wide system  Ontology –“specifications of a shared conceptualization of a particular domain” –Describe the semantics of information exchange –Ontology description tools : ontolingua, OIL, DAML  자료 출처 – 주제어 가중치에 의한 문서 치리 기법과 온톨로지 – 강승식 ( 국민대 교수, KIPONTO 2003)

6. 6 Thesaurus vs. Ontology  Thesaurus – 어휘를 중심으로 분류하여 관련어를 표시한 사전 통제된 색인언어의 어휘집으로, 개념간의 특정 관계를 형식적으로 조직 화하여 명시한 것 – 관련어 : 상하위어, 유의어, 반의어 등 포함 ( 예 ) Roget, WordNet, Goi-Taikei 등  Ontology – 실세계에 존재하는 모든 개념들, 그 개념들의 속성, 개념간 의미 관계 에 관한 정보를 가지고 있는 지식베이스 – 의미 관계 : 계층관계, 격 관계, 기타 의미관계 – 언어 독립적인 정보 ( 예 ) Mikrokosmos, SENSUS, HowNet 등  자료 출처 – 자연어처리를 위한 실용적인 온톨로지의 반자동 구축 – 강신재 ( 대구대 교수, KIPONTO 2003)

7. 7 Semantic Network  형식적인 면에서 시소러스와 유사  한 어휘가 가지고 있는 다른 어휘들간의 관계를 Network 으로 나타 낸 것 – 단어의 의미, 개념간의 연상관계, 지식 등을 표현하는 네트워크  세 가지 특징 – 개념들이 특정한 관계에 의해 연결되어 있는 지식에 대한 사고 방식 을 보여 준다. – 노드와 링크, 관계 표시 등의 결합으로 이루어진 도식적인 표현 (diagrammatic representation) 을 가진다. – 지식 표현을 관리할 수 있는 알고리즘을 이용한 다양한 추론 기술과 데이터베이스와 같은 역할을 고려한 전산적 표현 (computational representation) 을 가진다.  자료 출처 – 자연언어처리를 위한 온톨로지 – 옥철영 ( 울산대 교수, KIPONTO 2003)

8. 8 3. ECMIF Project Details  Meta-framework modeling methodology – 다른 e-commerce frameworks 사이를 mapping 하기 위해 요구되는 상호 작용과 변환을 모 델링 하기 위한 접근 Top-down 분석, business process integration 에 기 반 Multi-layered modeling approach 내용에 대응되는 개념을 측정 (semantic translation)

9. 9 3. ECMIF Project Details  Meta-framework modeling language –E-commerce frameworks 의 개념, 사용되는 내용, 그 들 사이의 상호작용과 변환을 묘사하기 위한 정밀 한 표기법 Semantics of the base building blocks (actors, messages, transactions), data models Access to external resources (URLs, directories, catalogues, databases, etc..) –Business process modeling 을 위해서 ECMIF 는 modeling notation 과 다른 layers 의 business processes 사이의 변환을 표현하기 위한 언어에 추가하여 ebXML BP work(cf. ebBPSS) 의 결과를 재사용하는 것을 제안한다.

10. 10 3. ECMIF Project Details  Proof of Concept –Project 는 개념의 증명을 제공하기 위해서 제 안된 methodology( 임의의 구체적인 e- commerce frameworks 사이의 interoperability 를 설명 ) 의 현실화를 위해 필요한 tool-chain 의 구현을 목표로 한다

11. 11 4. General Methodology  ECIMF methodology : interoperability layers

12. 12 4. General Methodology  Relationship between the ECIML and other modeling standards.

13. 13 ECIMF Methodology Interoperability 의 Four Layers  1 Layer : Business Context Matching – 통합 직무의 범위를 설정하는 것을 다룬다. – 모든 가능한 상호작용을 위한 완벽한 통합 설계서 를 만드는 것이 불가능하다. 그래서 작업은 business 경우를 풀기 위해 범위의 제한이 필요하다. – 각 Party 를 위한 모델이 준비되어지고, 그것이 어느 것에 매칭되는지 결정한다. 예를 들면 Business 파트 너가 같은 Business 목표를 가지고 있는지를 판단하 는 것이다.

14. 14 ECIMF Methodology Interoperability 의 Four Layers  2 Layer : Semantic Translation –Key 개념과 의미 일치가 확립된다. 즉, frameworks 의 각각의 내용이 근접한 정도에 의해 변환된다.

15. 15 ECIMF Methodology Interoperability 의 Four Layers  3 Layer : Business Process Mediation –Business semantics 를 유지할 동안 한 framework 에서 다른 framework 의 대화를 가 능하게 하는 중간 Agent 를 소개함으로써 가 능한 중재 Logic 이 정의된다.

16. 16 ECIMF Methodology Interoperability 의 Four Layers  4 Layer : Syntax mapping – 이미 구축된 Semantic 일치 (2 Layer) 와 번역 법칙 (1 Layer) 에 근거하여 메시지 안의 Data 요소 사이의 Mapping 이 정의된다. 또한 전달 Protocol 과 Packaging 변환이 설정된다.

17. 17 1 Layer : Business Context Matching  Business Context 는 다음과 같다 – 약속을 정의한 합의서 / 계약서 – 약속을 이행하는 협조 방식 (Business Processes 사용 ) – 의미, 주기와 상태, 사업 자료와 사업 규칙 요 약 내용을 가진 Business Objects

18. 18 2 Layer : Semantic Translation  Semantic Translation 이 필요한 가장 일반 적인 경우는 각 사업자가 다른 상품 Catalogue 를 사용할 때 수행되어진다.

19. 19 2 Layer : Semantic Translation  Mapping concepts from different ontologies

20. 20 2 Layer : Semantic Translation  Semantic Translation meta-model

21. 21 2 Layer : Semantic Translation  Rule:rule1  | | |  | | +-- ContextSet:set1 {Ontology 1}  | | \Context:Party  | | \Context:Address  | | \Context:PartyIdentification  | | \Context:Name  | +--ContextSet:set2 {Ontology 2}  | \Context:Agent  | \Context:Location  | \Context:Name  | \...  \Formula:formula1  | \body: "set2.Name = set1.Name"  \Formula:formula2  | \body: "set2.Location.Address.Street1 =  set1.Address.Street;  set2.Location.Address.Street2 =  concat(set1.Address.Zip, set1.Address.City);"  \Formula3:Formula... .....

22. 22 3 Layer : Business Process Mediation  Example scenario that requires Process Mediator.

23. 23 4 Layer : Syntax mapping  Data element mapping –Semantic mapping rules 사용. Syntax mapping 은 XSLT 에 의해 수행, 추가적으로 non-XML 포맷을 위 한 straightforward wrappers  Message format mapping – 형식 명세서에 따라 메시지의 정당성을 확신하게 한다.  Message packaging mapping –ebXML CPP/CPA ?  Transport protocol mapping –ebXML CPP/CPA ?

24. 24 5. Proof-of-concept : scenario analysis  이 장에서는 어떻게 ECIMF 가 두 e- commerce 파트너 사이의 상호 운용을 위 한 방법들을 준비하는지 예를 보여준다.

25. 25 Business Context Matching  Business Context model as seen by the shipping agency

26. 26 Business Context Matching  Business Context model as seen by the customer

27. 27 Process Mediation

28. 28 Process Mediation

29. 29 Semantic Translation  Semantics of the two corresponding concepts Customer: TV-setSemantic TranslationShipping Agency: Box PropertiesMapping RulesProperties Height Width Depth Represent the physical dimensions of the TV set chassis. Tv_set → Box: dimension values will always be higher, but discrete. Need to be obtained from a cardboard box catalogue (external resource) Height Width Depth Represent the physical dimensions of the cardboard box used to ship the electronic equipment of any kind. The values are discrete, because only certain box sizes are available. Box → Tv_set: dimension values will always be lower. Need to be obtained from a TV products catalogue (external resource) using productID Not available (N/A) Tv_set → Box: needs to be obtained from a product catalogue (external resource) Weight Represents the weight of the box with the contents. Box → Tv_set: not needed N/A Tv_set → Box: needs to be obtained from a product catalogue (external resource) StackingLevels Represents the number of levels the boxes can be stacked, one on top of the other. Box → Tv_set: not needed N/A Tv_set → Box: always set to True. Fragile Marks the payload as fragile (requiring special care during transportation) Box → Tv_set: not needed Color Tv_set → Box: not needed N/A Box → Tv_set: needs to be obtained from a product catalogue (external resource)

30. 30 Semantic Translation  Analyze the message delivery control mechanisms Customer (RNIF)Semantic TranslationShipping Agency (EDI) SecureFlow consists of a business document (containing business data), and a responding business signal (acknowledgement). The RNIF business documents map 1:1 to EDI business messages, e.g.: QuoteRequest ↔ REQUOTE QuoteConfirm ↔ QUOTES PORequest ↔ ORDERS POConfirm ↔ ORDRSP etc... However, individual data elements can be missing, and will have to be collected from the previous messages, or supplied explicitly in the rules, or obtained from external resources. In this particular case, the EDI system uses APERAK and CONTRL messages only to signal exceptions. Acknowledgements are implicit, in the form of response business documents. ReceiptAck This signal means that the document business data has been accepted for further processing (which implies also well-formedness) RNIF → EDI: not needed – don ’ t forward.N/A – implementation choice (positive acknowledgements are implicit). EDI → RNIF: needs to be synthesized from the response document. Possible problems with timing constraints … (ack. too late) ReceiptAckException This signal means the document was not well- formed (parsing errors). Business data was not considered at all. The semantics of both messages is identical, which means a 1:1 mapping can be applied, both ways. CONTRL This message is sent when parsing errors occur. Business data was not considered at all.

31. 31 Syntax mapping  Message syntax mapping

32. 32 Generation of MANIFEST  ...  ... (here it follows, defined using ebXML BPSS)...  ...   urn:ont1...   urn:...TV-set 

33. 33 Shared ontology approach to semantic translation

34. 34 Example of ECIT (ECIMF- compliant agent) facilitating message exchange