New Working Ideas for MMFI4Ontology Registration

9th Open Forum on Metadata RegistriesHarmonization of Terminology, Ontology

and Metadata20th – 22nd March, 2006 , Kobe Japan.

Presentation Title:

Day: Slot No.

Name:

Organization:

3 P 25

WANG Chong, HE Keqing, HE Yangfan, WANG Jian

State Key Laboratory of Software Engineering,Wuhan University, P.R.China

New Working Ideas for MMFI4Ontology Registration

9th Open Forum for Metadata Registry, Kobe, 2006

2

Outline

Background Introduction of MMFI4Onto NWI : Registration of Process OntologyⅠ NWI : Harmonization with other standardsⅡ Future work


3

Outline



4

Resources on web

rich semantics heterogeneous structure various representation unsteady ……

characterized with

knowledge sharing effective utilization ……

hamper

information resource service resource infrastructure resource ……


5

Resource management Objective

– Registration– Sharing and reuse – Interoperation

• between human beings• between human beings and machines• between machines

Resolution– Ontology is used as the foundation of communication.

– A common facility should be provided to register resources on semantic web.


6

Why Ontology

Ontology – describes concepts and the relationship between

them in the universe of discourse.– has been identified as a knowledge representation

mechanism for semantics.

Ontology captures the semantics of information from various sources, gives them a concise, uniform and declarative description, and has gained significance in terms of the demands in academia and industry.

From D. Fensel:Ontologies: A Silver Bullet for Knowledge Management and Electronic Commerce.


7

Framework for resource registration (1/3)

Scalable, Compatible and Open

From Takeshi Chusho, Hiroshi Tsukui and Katsuya Fujiwara: A Form-based and UI-Driven Approach for Enduser-Initiative Development of Web Applications

In a framework, the frozen spot implies the fixed and reusable part that we need not customize. A high reuse rate reduces the end-user's work in application development. Conversely, the hot spot implies the flexible part that we need to customize.

Extensible


8


Coordinate with other existing standards– Build a bridge for interoperation between systems based on

different registry mechanisms

– Supplement with no change to the original structure of those registry models

Harmonization



9


Extended hot spot should follow the specification of frozen spot.

Interoperation can be implemented among those extended parts.

Interoperation



10

Summary of background

Ontology is – the key issue for semantic annotation;– important for interoperation between various resources.

In order to promote sharing and interoperation between resources, a framework is needed to register ontology and other resources on web.

Framework for Metamodel Interoperability: Metamodel for Ontology Registration (MMFI4Onto)

is such a facility.


11

Outline



12

MMFI & MMFI4Onto

MMFI for Ontology Registration

MMFI for Mapping MMFI for Modeling Constructs

Metamodel Instance

Universe Of Domain

Interoperability,Exchanging

MMFI4Onto

MOF,ISO 11179(MDR)

MMFI Core Model

SKLSE(WHU)


13

MMFI Core Model & MMFI4Onto


14

Reference Ontology & Local Ontology (1/3)

Local Ontology (LO)– used by information systems– modification to RO

• adding new component• adding new atomic construct• ……

Reference Ontology (RO)– specified by standard organizations

– stable


15

Frozen spot– Reference Ontology (RO), Reference Ontology

Component (ROC), Reference Ontology Atomic Construct (ROAC)

Hot spot– Local Ontology (LO), Local Ontology Component

(LOC), Local Ontology Atomic Construct (LOAC)



16

For RO and its components, growing means– adding new ROAC for RO versioning– renaming for knowledge updating– ……

For LO and its components, growing means– reusing constructs from some ROs– adding new LOAC or LOC for specific demands– ……



17

Other definitions in MMFI4Onto

Metaclasses:– Ontology is the super class of RO and LO.– Ontology Component is the super class of ROC and LOC.– Ontology Atomic Construct is the super class of ROAC and LOAC.

Relations:– Ontology consists of Ontology Component.– Ontology Component consists of Ontology Atomic Construct.

In MMFI4Onto specification, these three metaclasses are abstract classes. They can be regarded as the

frozen spots without growing.


18

Frozen spots without growing

Frozen spots with growing

Hot spots

Kernel Model of MMFI4Onto

Ontology Ontology Component Ontology Atomic Construct

Ontology Language

Reference Ontology

Local Ontology

Reference Ontology Atomic Construct

Local Ontology Atomic Construct

modelType

1

0..*

sameAs

0..*

0..1

Reference Ontology Component

Local Ontology Component

sameAs

0..*

0..1sameAs

0..*

0..*

sameAs

0..*

0..*

Frozen spot

Hot spot


19

Outline

Background Introduction of MMFI4Onto NWI : Registration of Process OntologyⅠ NWI : Coordination with other standardsⅡ Future work


20

Why registration for Process Ontology

Web service– one of the important resources– characterized with dynamic features and processes.

Current version of MMFI4Onto concentrates on the registration of static ontology, rather than process ontology and/or service ontology.

Register process ontologies. Govern the construction of customized services. Reduce the cost of service development.

Extending MMFI4Onto


21

Brief introduction of OWL-s (1/2)-- Layered approach to language development

SWRL (Rules)

XML (Extensible Markup Language)

RDF (Resource Description Framework)

RDFS (RDF Schema)

OWL ([DLP], Light, DL, Full)

OWL-S (Services)

OWL-s (W3C)– is an extended ontology language– a specific OWL profile for Web

Service

SWRL: Semantic Web Rule Language (W3C)


22

Brief introduction of OWL-s (2/2)

(from W3C, OWL Web Ontology Language for Services (OWL-s) Specification)

OWL-s is used as a language for describing services, reflecting the fact that it provides a standard vocabulary that can be used together with the other aspects of the OWL description languages to create service description.

OWL-s is meant to support categories of service.


23

Ontology images compliments of Terry Payne, University of Southampton

Upper Ontology of Service Ontology


24

Selected classes and properties of the Service Profile

IOPE


25

Top level of the Process Ontology


26

ProcessOnto Model in MMFI4Onto

Process Ontology

Composite Process

Control Construct Atomic Process

InputPostcondition

PreconditionOutputSequence

Any-Order

Split+Join

Split

Choice

Repeat-Until

Repeat-While

If-Then-Else

Iterate

Ontology

Ontology Component

Ontology Atomic Construct

……


27

RPO/LPO in ProcessOnto Model (1/2)

Reference Process Ontology (RPO) is– fixed web services– with wide acceptance and relevant applications

Local Process Ontology (LPO) is– for particular application domains– generated by

• reusing sub-processes (atomic process and/or smaller composite process) from RPOs

• adding some new sub-processes


28

RPO/LPO in ProcessOnto Model (2/2)

Similarly, interoperation between LPOs is based on the common foundation provided by RPO.

Interoperation between Process Ontology includes– reuse

– matching

– automatic discovery

– automatic composition

– ……


29

An example: service registration and interoperation based on

ProcessOnto Model

--BravoAir example

from W3C, http://www.daml.org/services/owl-s/1.0/examples.html


30

……- <process:CompositeProcess rdf:ID="BravoAir_Process"> <rdfs:label>This is the top level process for BravoAir</rdfs:label> - <process:composedOf>- <process:Sequence>- <process:components rdf:parseType="Collection"> <process:AtomicProcess rdf:about="#GetDesiredFlightDetails" /> <process:AtomicProcess rdf:about="#SelectAvailableFlight" /> <process:CompositeProcess rdf:about="#BookFlight" /> </process:components> </process:Sequence> </process:composedOf> </process:CompositeProcess>……- <process:CompositeProcess rdf:ID="BookFlight">- <process:composedOf>- <process:Sequence>- <process:components rdf:parseType="Collection"> <process:AtomicProcess rdf:about="#Login" /> <process:AtomicProcess rdf:about="#ConfirmReservation" /> </process:components> </process:Sequence> </process:composedOf> </process:CompositeProcess> ……- <process:AtomicProcess rdf:ID="ConfirmReservation"> <process:hasInput rdf:resource="#ReservationID_In" /> <process:hasInput rdf:resource="#Confirm_In" /> <process:hasOutput rdf:resource="#PreferredFlightItinerary_Out" /> <process:hasOutput rdf:resource="#AcctName_Out" /> <process:hasOutput rdf:resource="#ReservationID_Out" /> <process:hasEffect rdf:resource="#HaveSeat" /> </process:AtomicProcess>- <process:Input rdf:ID="ReservationID_In"> <process:parameterType rdf:resource="&website#ReservationNumber" /> </process:Input>- <process:Input rdf:ID="Confirm_In"> <process:parameterType rdf:resource="&website#Confirmation" /> </process:Input>- <process:UnConditionalOutput rdf:ID="PreferredFlightItinerary_Out"> <process:parameterType rdf:resource="&website#FlightItinerary" /> </process:UnConditionalOutput>- <process:UnConditionalOutput rdf:ID="AcctName_Out"> <process:parameterType rdf:resource="&website#AcctName" /> </process:UnConditionalOutput>- <process:UnConditionalOutput rdf:ID="ReservationID_Out"> <process:parameterType rdf:resource="&website#ReservationNumber" /> </process:UnConditionalOutput>- <process:UnConditionalEffect rdf:ID="HaveSeat"> <process:ceEffect rdf:resource="&website#HaveFlightSeat" /> </process:UnConditionalEffect>……

Registration Info of BravoAir reservation service

Ontology– BravoAirProcess

Ontology Component– AtomicProcess:GetDesired

FlightDetails– CompositeProcess:BookFli

ght– ……

Ontology Atomic Construct– hasInput:ReservationID_In– hasOutput:ReservationID_

Out– Sequence– ……


31

Service interoperation based on ProcessOnto Model

The same Atomic process

Flight Reservation Service

Bank Service

Reference Process Onto for e-business Online Service

Service Registration based on MMFI4Ontology Registration

……AtomicProcess=#LoginAtomicProcess =#ConfirmReservation……

……AtomicProcess=#LoginAtomicProcess =#ConfirmTypeOfCard……

Local Process Onto BLocal Process Onto A


32

Outline



33

Role of MMFI

MMF For Interoperability


34

Issue : ⅠCoordination with other standards


35

Abstraction Layer where MMFI Resides in

MMFI4Onto

Pattern :

Universe of Discourse

Modeling Constructs

Stereotype :

Template:

MetamodelMetaModel

Metamodel

Modeling Facility

M3

M2

M1

M0

ModelModel

ModelModel

Model

MOFMMFI


36

How to coordinate?

MMFI– specify the basic concepts and relations to register

information models– correspond to specific registry mechanisms

MMFI4Onto– supplement the capability of existing standards– promote interoperation between them– enable collaboration and harmonization


37

Issue : ⅡImplement MMFI4Onto for

specific application


38

Implement MMFI4Onto with OASIS/ebXML

Purpose– Software Component (SC) Registry and Repository

(R&R) based on ebXML • describe complex attributes of SC with ontology• register and query SC

Implement MMFI4Onto– register attribute ontology for knowledge sharing– classify and register SC based on registered ontology


39

Overview of OASIS/ebXML RIM

ebXML Registry Information Model (RIM)


40

ClassificationNode & Classification Scheme

ClassificationNode instances are RegistryObject instances that are used to define tree structures under a ClassificationScheme, where each node in the tree is a ClassificationNode and the root is the ClassificationScheme.

ClassificationScheme

ClassificationNode

ClassificationNode

ClassificationNode


(from OASIS/ebXML Registry Information Model v2.1 )


41

Implementation of MMFI4Onto (1/3)

Basic idea：– To establish the inheritance relationship between RIM and

MMFI4Onto

Solution：– Ontology inherits ClassificationScheme– Ontology Component inherits ClassificationScheme

• a part of ontology• with certain structure

– Ontology Atomic Construct inherits ClassificationNode• unit


42

Ontology Atomic Construct Ontology Component Ontology

Kernel Model from MMFI4Onto

RegistryObject

ExtrinsicObject


AssociationClassification RegistryEntryClassificationNode


Registry Information Model from ebXML

Implementation of MMFI4Onto (2/3)-- Extend RIM for MMFI4Onto Registry


43

Implementation of MMFI4Onto (3/3)

Evaluation– supplement semantics

– support registration of complex resources

– no change to the original structure in RIM

– recognize registered instances by both MMFI4Onto and RIM

– realize interoperation between them


44

Outline



45

Future work (1/2)

MMFI4Onto

– Kernel Model, Evolution Information Model and Evolution

Rule Model

• consistency preservation (algorithm, implementation, etc.)

– ProcessOnto Model

• detailed registration for Semantic Web Service

• algorithms for service matching, composition and

decomposition, etc.


46

Future work (2/2)

Applications based on MMFI4Onto

– corresponding workbench

Collaboration with the other standards

– UDDI

– ……


47

Any Question?

Thank You!

[email protected]@public.wh.hb.cn

[email protected][email protected]

New Working Ideas for MMFI4Ontology Registration

Documents

Transcript of New Working Ideas for MMFI4Ontology Registration