Request for Study Period on “MFI for ROR” Hajime Horiuchi Tokyo International University

“Sharing and advancing knowledge and experience about standards, technologies and implementations.

Request for Study Request for Study Period on “MFI for ROR”Period on “MFI for ROR”

Hajime HoriuchiHajime Horiuchi

Tokyo International UniversityMay 28, 2008

1

SC32WG2N1130


Topics

• Type of Registry (Difference of Architectures ) • What is ROR• Background of ROR project• Overall structure of ROR• Issues

2


SemanticRegistry

DD/DS

Metadata Registry

Evolution of Registry Technology

3

Sharing of knowledge

Sharing of development Methodology

Sharing of Data

Sharing of Software

Discover & Casting Web Service

ROR

Cross Domain Interoperation


A Taxonomy of Architecture Types

4

Domain Specialty

Diversity of Stakeholder

SOS

Process Contents

SOA/SaaS

limited Alliance

High(Narrow)

ROR

Cross IndustriesMetadata Dependent(Non Structural)

Model Dependent(Structural)

Low(Generic)

High

Target of the Standardizations

System of Systems

Registry Of Registries

Cross Homes

102 108


DIFFERENCE OF REGISTRY TYPE

5


Registry to Support Engineering

6

Domain Specialty


SOS

SOA/SaaS

limited Alliance

High(Narrow)

ROR



Low(Generic)

High

System of Systems


Cross Homes

102 108

Registry to support Engineering


Registry to Support Engineering

7

Process Models

Products Models

Registry

Product Specifications

Integration

Part Library

Domain Ontology


Registry to support Cross Industries

8

Domain Specialty


SOS

SOA/SaaS

limited Alliance

High(Narrow)

ROR



Low(Generic)

High

System of Systems


Cross Homes

102 108

Registry for Interoperation


Registry to support Cross Industries

9

Product Information

Registry

Business Information

PartyInformation

Business Process Model

SupplyChain

Domain Ontology


Registry for Discovery

10

Domain Specialty


SOS

SOA/SaaS

limited Alliance

High(Narrow)

ROR



Low(Generic)

High

System of Systems

Cross Homes

102 108

Registry for Discovering


SOA/Could Computing

11

Cloud

Saas

Saas

Saas

Saas


Registries to support SOA

12

Saas

Saas

Saas

Saas

Saas

Object-URI

Ontology

Access Protocol

Object-URI

Ontology

Access Protocol

Object-URI

Ontology

Access Protocol


In the Future ?

13

Web service

Saas

Saas

Saas

Saas

Registry as Service

Registry as Service


TO SUPPORT CROSS INDUSTRIES

ROR: Registry of Registries

14


What is ROR• ROR (Registry of Registries) is trial uses of the MFI on

the cross industries business processes– MFI: ISO/IEC 19763 (Metamodel Framework for

Interoperability)

• Goal:– Reification of the interoperability among heterogeneous

domain registries

• A formal committee under IPSCJ(JTC1 Japan)– SC32WG2 + TC184/SC4 + ECOM + LCDM members– Just started at officially on this April

15


Original goals of ISO/IEC19763 standards

16

SC32 Seoul 0205064PDES/STEP

RegistryManufacturing

ebXML Registry

UDDI

Component Registry

GCI Registry

EAN Registry

CPFR Registry

RosettaNetRegistry

Business Negotiation

Vender Catalog

Shipper Catalog

Business Category

Shipping

Customer Support

Consumer Profile

CALS

Production Planning & Procurement

System Development

11179 Registry

Heterogeneous RegistriesRegistry Interoperation

Registry Registry Registry

ROR

ManufacturingLogisticRetails

Registry

ROR: Registry of Registry


WHY WE NEED ROR ?

17


What is the Registry, again

• Registry has several meanings, all of which generally relate to its original or historical meaning as a written, official or formal record of information, or the place where such records are kept.

• Office where registrations are recorded; database for storing system configuration information.

(Wikipedia)

18


Current status of the registry

• Today, a lot of actual registries are enforced and working in various business domains.

• They were developed mostly according to requirements in their specific domains.

• Each registry has own structure, fashion and procedure. • Most of them did not pay attentions to other registries.• Even if, they could follow particular standards, most of

those standards themselves might be domain specific.

19


Different Views by industries on 　　　 a same product

20

PLIB Item Master DB

Product-Number Item-Number

Home electronicProducts

Attributes for Manufacturing

AttributesforRetailing

Home Electronic Category

Electronic Parts Category

No interoperability

Metadata

ISO13584 　　standards

GS1, EPCG


Closed Processes and Registries

21

Design

Assembling

Inspection

Delivery

Merchandising

Buying

Selling

Invoice

PLIB Item Master

Manufacturing Retailing


Emerging needs for the Model Sharing

22

Product

Manufacturing Product Life Cycle Management Hazardous

Materials Management

Actual reification of Cross Industries Interoperation is needed

Product Traceability

Retail ing

Logistic & Distribution

Industrial Waste Processing

Consumer

Artery & Vein


Every domain has own Registry

23

Product

Manufacturing Product Life Cycle Management Hazardous

Materials Management

Product Traceability

Retail ing

Logistic & Distribution

Industrial Waste Processing

Consumer

Artery & Vein

Registry

Registry

Registry

Registry

Registry

Registry


Some of actual registries in Japan

– JEITA （ ECALGA, PLIB ）– JEMA （ Heavy electric parts ）– JEMIMA(Electric Measurement Instruments )– CEDI （ Petro Chemical ）– JAPIA/JAMA （ Automobile ）– JASTPRO （ Shippers codes ）– JEDIC （ EDI standards ）– JICFS/DRS （ Company code, Item code in retailing ）– JACIC LCDM （ Construction Engineering ）– www.registry.go.jp etc.

24


ISO- EDIFACT- ebXML 　 - PLIB

UN/CEFACT

De JureIETF- AS2W3C- XML

OASIS- ebMS-WS- R&R

ANSIX12

CEN

RosettaNet

CIDX

SWIFTHL7

WCO

GS1

EPC グローバル

Industrial St.

EDI Related Standards

JISEDIFACT/CII

JADM

eBusinessAsia

25


Product Tracing by RFID tag

26


Web Service Providers

27

受発注

出荷納入

請求支払

部品メーカ

セットメーカ

素材メーカ

受発注

出荷納入

請求支払

受発注

出荷納入

請求支払

販売店

メーカ

メーカ

受発注

出荷納入

請求支払

受発注

出荷納入

請求支払

電子電機化学

写真

自動車

量販店標準化

素材情報

部品情報

販売情報

EDI

EDI

EDI電子タグ

ＱＲコード

完成品情報

在庫管理

標準化

環境負荷物質

ROR

A Draft of Framework for Information Infrastructure (ECOM, 2007)

Portal Service

Cargo TrackingPLIB MSDS

Retail Item DB

Tax DB

OrderingService

MSDS Reg.Service

Part Retrieval Service

Item Reg.Service

Accounting Service

Business 　 Oriented Process Integration

Material Oriented Process Integration

UDDI


What is MFI• Metamodel Framework for Interoperability • ISO/IEC19763 series of standards • A set of Metamodels for;

Registering Models (Not for describing model or ontology)

• MFI is an Application of MOF (1.4) 28


ROR by MFI

29

Registry

Registry Registry Registry Registry

Registry

Core model

Mapping

Registration Procedure

Metamodel for model mapping

MFI （ ISO/IEC19763 ） series of standards

ROR (Cross Domain Registry)

Metamodel for ontology registration

Industrial registries

Metamodel for process registration


Basic Ontology

Cross Domain ROR

30

Model Mapping Service

Industrial domain

Domain　Model

基本情報要素Data Elements

Registry

ROR

Domain Ontology

Ontology Search Service

Terminology

Terminology

Terminology

Registration Quality

RA

RA

RegistrationProcedure

UUID

OID

UID

Registry

Domain Ontology

Terminology

RA

UID

Registration Authority

Value Domain

Industrial domain

MFI Registry

Domain A Domain B


ISSUES FOR ROR&

MFI Standards

31


Issues

• How to Discover and Cast registries• How to Make Mappin • How to provide a Universal ID• How to specify Data Quality• Registration Procedure

All of above are under discussion.

32


Use Case

33

PLIB Item Master DB






GS1, EPCG

Mapping


Issues

34

RA/RO RegistrationProcedure Global Unique ID

DataQualitySpecification

Mapping

Change Control

Ontology

Casting

PLIB Item Master DB






GS1, EPCG

Mapping


How to Cast a registry call

35

ROR

PLIB Metamodel

ITEM Master Metamodel

PLIB Model

ITEM MasterInstance

Level 1

Level 2

Level 3

Search

JAITA JAMIMA

PLIB Model

Inquire

M1

M2


Level 1 Mapping Variation

• Exactly Same• Similar to• Looks like

36


How to Map

• MFI-2 (Core Model) is used for registration of metamodel

• MFI-4 (Model Mapping) to be used for describe model mapping

• The ebXML Core Component to be used for type matching

37


Use case 2

• Stock take Metamodel of target registries• If they do not have any metamodel, metamodel

should be developed using CWM metamodels• Assign Core component of the ebXML to each

element of the Schema

38


Metamodel Mapping

39

MFI:Metamodel for Mapping

Item Master Metamodel

PLIBMetamodel

Mapping Rule Instance

ebXML CCMetamodel

MappingProcess

CWM CWM


MFI 4: Model Mapping

40

Transformation

name:　　stringkind:　　type　code

LevelPair　Rule

definitionKind:　　type　codename:　　stringlowerRuleType:　　type　codeupperRuleType:　　type　coderuleDefinition:　　URI

MM-M　Transformation MM-M　Rule

M-V　RuleM-V　Transformation

Administered　Item

ModelConcept

ModelInstances

m=v=map

1..*

mm=m=map

1..*

sourceUpper

1..*

targetLower

1..*

targetUpper

1..*sourceLower

1..*

targetUpper1..*

sourceUpper1..*


Type Matching through CC

41

ebXML Core Component

PLIB Element

Item Master Element

TS- TV-42- name (ACC-nn) TV-42-Toshiba name (ACC-nn)

(ACC: nn)

1

*

1

* GS1 ID

Mapping


ebXML Core Component• Standardized Information elements for Business

Information to be used in the electronic business

42

Business InformationCore Component

BCC

ACC

ASCC

CCT

ABIE

BIE

Text Location

Person

Resident

Patient.Person

Health.record

*..1

0..*

Core Component Type

Basic Core Component

Aggregated Core Component

Business Information Entity

Aggregated Business Information Entity


Metamodel of CC

43

Aggregate Core Component (ACC)

+ Object Class Term: String

«abstract»ACC Property

+ Cardinality+ Sequencing Key: String

Association Core Component (ASCC)

+ Association Type: Association Type = aggregation {readOnly}

Basic Core Component (BCC)

ASCC Property

+ Property Term: String

BCC Property

+ Representation Term: String+ Property Term: String

Registry Class

+ Unique Identifier: String+ Version Identifier: String

Common Information

+ Dictionary Entry Name (DEN): String+ Definition: String+ Business Term: String [0..*]

Localized Information

+ Language Code: String+ Other Language DEN: String [0..1]+ Other Language Definition: String+ Other Language Business Term: String [0..*]

Usage Rule

+ Unique Identifier: String [0..1]+ Name: String [0..1]+ Description: String+ Formal Constraint: String [0..1]+ Formal Constraint Type: String [0..1]+ Condition Type: String [0..1]

«abstract»Core Component (CC)

«enumeration»Association Type

aggregation composition

1

0..*

1

0..*

1

0..*

0..*

1..*

0..*

10..*

0..*

1

CCTS : Core Component Tech. Spec. V-3.0


CWM: Relational Data model

44


CWM: Metamodel for Record

Traditional COBOL file, CSV file

45


icon

(ABS)

class

class_BSU

identified_by

property_BSU

data_type_BSU

dates

(ABS) graphics

its_superclass

item_names

(ABS) document

time_stamps

revision

defined_types S[0:?]

described_by L[0:?]defined_by

synonymous_name S[0:?]

short_name

preferred_name

names

remark

source_doc_of_definition

note

definition

supplier_BSU

(DER) known_applicable_properties SET[0:?](DER) subclasses SET[0:?]

(DER) known_applicable_data_types SET[0:?]

String

String

String

String

String

String

String

PLIB Class (Not UML)

46


(ABS) data_type

icon

property_BSU

(ABS)

property_DETmathematical_string

item_names

(ABS) document

(ABS) graphics

dates

(ABS) graphics

(ABS)

class

definition

note

remark

source_doc_of_definition

figure

det_classification

String

String

String

String

String

String

String

String

identified_by

domain

formula

preferred_symbol

synonymous_symbol S[0:2]

revision

time_stamps

synonymous_names S[0:?]preferred_name

short_name

described_by L[0:?]

names

PLIB　Property　(Not　UML)

47


Mapping

48

PLIB Class

Part

PLIB property

Part_Number

RecordFile

ITEM_Master

RecordField

Item_Number


Re: GEN(General kNowledge Navigator)

OKABE, Masao

Corporate Systems Department

Tokyo Electric Power Company Inc. (TEPCO)

2008.5.20

49

“Sharing and advancing knowledge and experience about standards, technologies and implementations. 50

What is GEN?• GEN is General kNowledge Navigator,

– which is a kind of ontology editor/repository mainly for knowledge management for human,

– which TEPCO already developed but may need some refinements and enhancements.

• GEN is very generic like Protégé.So, it can be easily enhanced either to– an ontology repository that is managed by RoRor– an experimental implementation of OOR or RoR itself.


Two possible positions of GEN

Note ：* 1: ISO 18629 Process Specification Language * 2 :ISO 13584 Parts Library * 3: INTAP Owl Ontology repository, whose specifications are under development by INTAP, Japan

Semantic Webontologies

Ontologies other than Semantic Web

・・・

Ontologies in RDF/XMLidentified by URI

・・・

Swoogle

IOO IOO repository*4

for OWL-DL ontologies

GEN for GEN for knowledge knowledge managementmanagement

Repository for PSL *2

OOR based on GEN= MFI Ontology registration registry based on GEN= RoR from the perspective of MFI Ontology registration based on GEN

Repositoriesthat conform to PLIB *3

Repository that conforms to (X)MDR


Architecture of GEN (1 of 2)• Gen is a client-server system with

– PCs installed GEN-client with Squeak virtual machine as clients

and

・・・

a network Drive installed omniBase DB as a file server.


Architecture of GEN (2 of 2)• It is easy to transform it to rich client Web

environment with– Web browsers installed GEN and Squeak as plugins

and

• But it is not so easy to transform it to thin-client Web environment without Squeak plugin.

・・・

DB server with omniBase DB or any other object-oriented DB such as GemStone.

Web server with Squeak

+


Main functionalities of GEN (1 of 2)• Main functionalities of GEN are;

1. Process Ontology （業務プロセスオントロジー）–to describe process flows

2. Know-how Ontology （業務ノウハウオントロジー）–for large-grained ontology for engineering rules for specific jobs

3. Basic Ontology （基礎オントロジー）–for small-grained ontology, usually common to all jobs

4. Notepad （雑記帳）–to take any kinds of notes freely and easily

5. Collaborative evolution on ontologies above and multi-version support

6. Links to anything identified by URI outside GEN

7. Scheduling expert subsystem for a specific job


Main fanctionalities of GEN (2 of 2)• Among them, the followings are essential and reusable to

an ontology repository which managed by RoR and/or an experimental system of OOR and RoR.

2. Know-how Ontology （業務ノウハウオントロジー）

3. Basic Ontology （基礎オントロジー）

5. Collaborative evolution on ontologies above and multi-version support

6. Links to anything identified by URI outside GEN


Know-how Ontology and Basic Ontology (1 of 4)

• From the point of GEN functionalities, Know-how Ontology and Basic Ontology are exactly the same. – Know-how Ontology is for large-grained ontology and Basic

Ontology is for small-grained ontology.• For details, see my presentation on Open Forum 2008.

• These functionalities are similar to the one of Protégé 3.X, but are more end-user oriented.

• End-user can design a schema of ontology (i.e. class structure), concerning only “reference” and/or “attribute”.– Need not care about a directional “slot” and its “inverse slot”.– To define one “reference” automatically creates bidirectional

relation and a inverse references, which is also naviable.


Know-how Ontology and Basic Ontology (2 of 4)• Know-how Ontology and Basic Ontology do not support import/export facilities

to any specific syntax and format such as OWL in RDF/XML.

• But, the (meta) structure of them are almost same as RFDS except that its data types are different from the ones of RDF(S) and its cardinality constraint is similar to the one of UML, which is not supported

either in RDF(S) nor even in OWL 1.0.

• It is not difficult to enhance GEN so that it can import/export ontolgies in RDF(S)/XML under the restrictions above.

• But it is better to use OWL2.0 syntax sugar to express its UML-like cardinality constraints and automatically defined inverse object properties.



• It might be better to enhance GEN to support facilities;

to define a sub-class in terms of property, which a basic feature of DL, and

to support SPAQRL-like query.


• User interface is a kind of mixture of Protégé, IE and Explorer.

– 選択されているインスタンスのアドレス


59

Class hierarchy tree

“Definition”, “Format” and “Instance Browser” tabs

コメント、リンク領域

go back, forth and upAddress of the instance selected and their history

“Comment” and “Unstructured link” tabs

Instance browser Instance expression

Comments


Proposal• TEPCO may make GEN a kind of closed share-domain program with several NPOs

such as – Wuhan university, – Korean university, – Lawrence Berkeley National Laboratory, – Tokyo International Universityand/or SC32/WG2.

Note: I cannot commit this now. I need to negotiate this with TEPCO.

• With your help, at least GEN should be internationalized and be made applicable to rich-client Web environment.

• Then, based on GEN, we all can develop easily an experimental implementation of OOR or RoR and also an ontology in GEN that can be managed by OOR or RoR.


Thank you

[email protected]

61

Documents

Request for Study Period on “MFI for ROR” Hajime Horiuchi Tokyo International University