outsourced types

8/6/2019 Outsourced Types

http://slidepdf.com/reader/full/outsourced-types 1/16

Extending conceptual models for web based

applications

Phillipa Oaks, Arthur H.M. ter Hofstede, David Edmond, and Murray Spork

Center for Information Technology InnovationFaculty of Information Technology

Queensland University of TechnologyGPO Box 2434, Brisbane, QLD 4001, Australia

(p.oaks,a.terhofstede,d.edmond,m.spork)@qut.edu.au

Abstract. The next phase envisioned for the World Wide Web, is globalheterogeneous ad-hoc interaction between intelligent agents, web ser-

vices, databases and semantic web enabled applications. Although atpresent this appears to be an unreachable objective, there are practicalsteps that can be taken to advance the vision. We propose Outsourcedtypes, an extension to classical conceptual models. Outsourced typesallow the definition of application components in terms of public stan-dards and explicit semantics, thus building-in to web-based applications,the foundation for shared understanding and interoperability. The use of external definitions and the need to store outsourced type informationinternally, brings to light the issue of multiple identities in a global envi-ronment, where individuals or instances may be identified by more thanone externally controlled identification scheme. We describe the require-ments for a service to handle multiple identities, and demonstrate howit can be used to deal with multiple identities in conceptual models.

1 Introduction

The world wide web (WWW) has already made interaction between people andweb pages possible. The next wave of interaction promised by the web will be be-tween software applications operating without the need for human intervention.These web-based applications could be federated databases, intelligent agents,grid services, Web services and other kinds of distributed applications.

The vision for web applications describes loosely coupled applications oper-ating on different platforms and interoperating by talking to each other without

prior agreements in place. To do this, applications need a way to recognise andutilize information from diverse contexts, as well as being able to describe their

own context in a manner that can be used by other applications. At presentthere are no explicit methods for developing conceptual models for web-based

This work was supported by the Australian Research Council SPIRT Grant “Self-describing transactions operating in a large, open, heterogeneous, distributed envi-ronment” involving QUT, UNSW and GBST Holdings Pty Ltd.



2

applications that take into account the wider web context that provides the basisfor interoperability.

The lack of an agreement between the interaction partners to constrain thetype and format of shared data would, under normal circumstances, make in-teroperability impossible because the applications and their clients may haveall the necessary data, but not in the format understood by the other party.One way to solve data mismatch problems is for a web application to providepointers to services that can translate, verify, generate, extract, and format datainto a form it can deal with. Similarly an application can provide informationabout the semantics of elements by referring to publicly accessible standards andspecifications.

The focus of this paper is on how to describe the elements that constituteweb applications in order to enable those applications to interoperate withoutprior agreements in place. To do this we introduce outsourced types, an extensionto conceptual models. Outsourced types ensure web applications are developed

from the conceptual level with the capability to use and understand informationspecified elsewhere. The information associated with outsourced types will allowa user, agent, web service or other application software; to identify a specificinstance of an outsourced type, to be provided with a list of services associatedwith that type, and to receive information on how the type is defined and used.The specification of web applications with outsourced types will increase thepotential for successful heterogeneous interoperation.

In the next section we present a conceptual model to describe a case studyillustrating the use of outsourced types. In section 3 we suggest some simplequestions that can be used to identify the kind of objects that may be candidatesfor outsourcing. Section 4 introduces a meta-model for outsourced types andsections 4.1 to 4.3 discuss each part of the outsourced type description withthe main focus on how to provide unique identities for instances of outsourced

types in a global context. In section 5 we illustrate how conceptual models mustbe augmented to allow the generation of relational schemas for the storage of outsourced type information.

2 Case study

Object Role Modelling (ORM)[1] is a visual conceptual data modeling technique,mainly used for the design of relational databases. It is used to describe objecttypes and their relationships in a particular application domain. ORM has anassociated modeling methodology, the Conceptual Schema Design Procedure(CSDP). ORM and CSDP were selected to model the case study because of their ability to produce robust and graphic models that “rigorously capture the

semantic nuances of an information system” (John Zachman in [1]).The case study is drawn from the field of securities lending. In this domain,the owners of securities1 can lend those securities in exchange for cash collateral

1 Financial instruments or securities, in this context, are those traded on stock ex-changes such as the NYSE, the LSE or the ASX.



3

"Collateral"

has borrow orloan amount

R123 5000R234 10000

Financial

Instrument

Date

is ofamount

R123,AUD 5000R123,ASX:BHPO 10000R234,USD 55000

is for borrow or

loan securityR123 ASX:BHP

R234 ASX:BHP

has loanpremium for non-

cash collateral1.5 R123

has rebate forcash collateral

150 R123

70 R234

Request(id)

has margin of

collateral overloan value

3 R12310 R234

has term of loan

3 R12330 R234

offers deliveryfrom

2002-02-20 R1232002-02-21 R234

Request plays or takes

R123 BorrowR234 LendRatio

(%)+

Quantity(nr)+

has currency ofloan

R123 AUDR234 AUD

Currency

{Lend,Borrow}Role

(descr)

involves collateral

R123 AUDR123 ASX:BHPOR234 USD

{1..360}

Duration(nr days)+

Ratio(basis

points)+

* 1% = 100 basis pointsBasis Point - One one-hundredth of a percent

placed by

ABN:00123456 R123DUNS:111222333R234

MarketParticipant

Fig. 1. Request model

or other securities. Depending on the type of collateral, the owner will be rec-ompensed by interest on the deposit of cash collateral, or a flat fee for non-cashcollateral. Borrowers may have any one of several reasons to borrow securities,traditionally the most common, is to cover short sales2. Lenders usually partic-ipate in the transaction to generate additional income from their investments.

The model (figure 1) shows the information necessary to describe a requestthat borrowers or lenders could place in a market to indicate a willingness toborrow or lend securities. The request itself is not a web service but provides

the context for several associated services such as Placing and Retrieving loanrequests. Requests could be constructed in many ways depending on the capabil-ities of the applications making and taking the request. A stored request couldbe revealed as a web accessible form [2], serialized in XML [3, 4], RDF/RDFS3,or OWL4 documents, or it could be revealed gradually as part of an interactiveinformation service.

The shaded ellipses in the figure represent outsourced types. Outsourcedtypes are necessary for this application, designed to operate in a global environ-ment, for several reasons. The Date type, is based on the ISO 8601 [5] standardfor dates and times because date representations differ from country to country.For example in the USA 6/7/02 is 7 June 2002, in Australia it is 6 July 2002.The Currency type (based on the ISO 4217 standard for currency codes [6])ensures there is no confusion when applications deal with money outside of theirnational borders.

2 Short sale - the sale of a security before it is purchased.3 http://www.w3.org/RDF/4 http://www.w3.org/2001/sw/WebOnt/



4

In a heterogeneous environment interaction partners will not always use ex-actly the same data types, naming conventions or representation standards. Datamay need to be converted from one representation to another, and outsourcedtypes allow the specification of the requirements for operations to perform thistype of conversion service.

Outsourced types are an abstraction mechanism that allow the conceptualmodeler to delegate (or outsource) the responsibility for the definition of the in-ternal structure of the type. Instead, the modeler can associate external serviceswith the outsourced type, thus providing the ability to manipulate and queryan instance of the outsourced type without having to understand its internalrepresentation. For example the financial instrument outsourced type can definea requirement for the retrieval of the name of its issuer, without having thatinformation explicitly defined in the local model. A full description of the kindsof information associated with outsourced types is presented in section 4.

Two populations are shown in the model (figure 1). The first example shows

a request (R123) to Borrow the borrow or loan amount of 5000 of the Financialinstrument identified as ASX:BHP shares5. The request offers two types of Col-

lateral, the Currency AUD (Australian dollars cash) and the Financial instrument

identified as ASX:BHPO shares. The loan value of AUD50000 is derived by mul-tiplying the value of the ASX:BHP shares (AUD10) by the number of sharesrequired. The margin of collateral over loan value is how much more collateral,over and above the loan value, is required by the lender. The lenders return isthe loan premium for non-cash collateral of 1.5% on the ASX:BHPO shares andthe rebate for cash collateral of 150 basis points6 on the cash value for a 3 dayloan.

The second example shows an offer (R234) to Lend the Financial instrument

ASX:BHP with the borrow or loan amount of 10000 shares. In this example,the loan value is calculated in Currency AUD (Australian dollars, which is the

currency BHP shares are quoted on the ASX), however the Collateral requiredis amount of 55000 in Currency USD. The margin of collateral over loan value is10% greater than the value of the loan, and the lender will give rebate for cash

collateral of 70 basis points on the interest generated by investing the collateralfor up to 30 days.

Over the duration of a securities loan, the value of the loan and the con-sequent value of the collateral required will fluctuate, depending on the valueof the Financial instrument and the current exchange rate between Australianand US dollars. The runtime re-calculation of the value of the loan means sev-eral operations are required to provide this information. The requirements fora service to retrieve the current market price of shares can be associated withthe Financial instrument, and the requirements for an exchange rate conversionservice can be associated with the Currency type. At present, it is not possibleto specify operations or functional requirements in ORM models [7]. Outsourcedtype definitions allow the specification of this kind of information at a conceptual

5 ASX = Australian Stock Exchange, http://www.asx.com.au6 Basis Point - One one-hundredth of a percent



5

level, where the description is in terms of what is required (capabilities) ratherthan who by, or how the operations should be provided (implementation).

3 Extending ORM with outsourced types

ORM already has the external type construct to represent information found inanother ORM model. Outsourced types however, allow ORM models to includeexternal descriptions from many other sources in a similar manner to the newontology languages such as RDF and OWL.

The CSDP is a seven step procedure to transform facts related to the domainof interest into a well defined conceptual schema. Steps 1 to 3 are concerned withidentifying entity types, value types and fact types. Steps 4 to 7 of the CSDPare when the constraints on entity types and the roles they play in relationships,are identified and incorporated into the schema diagram. The decision to use

outsourced types can be taken when all the elements in the domain model havebeen identified, so the decision comes after step 3 of the CSDP.Three questions help to decide whether an entity type should be defined as

an outsourced type. At the conceptual level the concerns are to manage com-plexity, to reuse external definitions when they are appropriate and to preparefor interaction as a web-based application.

Elementary types: The first decision is trivial and asks whether the objecttype represents an elementary or complex type. Elementary objects representinga number such as Quantity in figure 1 will not usually be treated as outsourcedtypes. However to promote interoperability, elementary types can be defined interms of an external definition such as XML Schema Part 2: Datatypes7.

Imported definitions: The second question asks whether there exists a defini-tion for this object type in any other schema. These definitions can come from

any model, schema or definition that is not the current model.At the beginning of our investigation, we assumed all imported definitions

should be treated as external, that is, supplied with an outsourced type definitionfor onward exposure to clients of the application being modeled, but as we havedeveloped the meta-model, this requirement became blurred. On one hand animported element could be treated as an outsourced type only if it is also exposedto users. On the other hand, outsourced types can be used as a guide for softwaredevelopers in the way an element should be implemented.

The more external information is reused in local models, the greater will bethe basis for shared understanding and interoperability. Software modelers anddevelopers need to reuse publicly accessible information sources for cost effective-ness, consistency and to provide interoperability both within an organisationalcontext and in the global world of web applications.

Exported definitions: The final question asks if the object type is to be ex-ported or exposed to clients of this model. Exposure can either be direct orindirect. Direct exposure happens when objects are shared as part of the normal

7 http://www.w3.org/XML/Schema



6

operation of an application, such as function names, parameters, return valuesor message components.

Indirect exposure happens when up or down stream services8

require clarifi-cation of the semantics of the terms used by the application. For example a userof the securities lending request, may ask “what is a financial instrument?”, andthe application could return the URI of a dictionary definition, or an ontologyentry, or a list of alternative terms. Or the user could ask “what is the currencyof Indonesia?” and the code or a pointer to a list of currency codes could be re-turned . In the next section we use an ORM meta-model to describe outsourcedtypes.

4 Meta model

eachOutsourced object type is anUnnested Entity Type that"is outsourced"eachService description is anInformation source thatis of Informationsource type "Service description"

Outsourcedobject type

has instancesgoverned by

identification scheme

Market ParticipantD-U-N-SMarket ParticipantTFN*Market ParticipantACN*Fin. Instrument ISINFin. Instrument ASXFin. Instrument ISO4217Currency ISO4217Date ISO8601

Information source(name)

Organisation

is owned orcontrolled by

D-U-N-S D & BISIN ISO*A SX A us tr al ia n S to ck E xc ha ng eI IS O4 21 7 I SO *ISO8601 ISO*ACN ASIC*TFN* ATO*

is published by publishes

D-U-N-S D & BISIN ISO*ASX Australian Stock ExchangeISO4217 ISO*ISO8601 ISO*ACN ASIC*ISO15022 ISO*Collins Paperback Collins Intl.Aust.Corporations Act 2001 Aust. Federal Govt.

has source type

My Model#234 OntologyOxford Concise DictionaryOxfordOnline DictionaryRogetsOnline ThesaurusCollins PaperbackDictionary

ISO 8601 StandardISO4217 StandardMarketDetai lService Servicedescription

contains is contained in

ksl-daml-instances.daml www.daml.org/ontologies/77#StockMy Model#23 www.qut /examp le /models/234#FI

RogetsOnl ine www.rogetsthesaur i. comwww.rogetsthesauri.com www.rogetsthesauri/#date

UnnestedEntity Type

has additional

informationFin. Instrument My Model#234Fin. Instrument OxfordOnlineDate RogetsOnlineCur rency Col lins P aperback Date ISO8601Currency ISO4217Fin. Instrument ksl-daml-instances.daml

Location(uri)is found at

ksl-daml-instances.daml www.daml.org/ontologies/77OxfordOnline www.oxfordonline.comRogetsOnline www.rogetsthesaur i.comRogetsOnline www.rogetsthesaur i/#dateD-U-N-S www.dnb.comMarketDetailService /example/docs/MktDetailSvc.rdf

Outsourced object type (Organisation) has instances governed by identification

schemeSource (D-U-N-S)

Source (D-U-N-S) is owned or controlled bySource (DNB)Outsourced object type (Organisation) has instances governed by identificationschemeSource (ABN)

Source (ABN) is owned or controlled by Organisation(ASIC)Source(DNB) is found atLocation (www.dnb.com)

Source (D-U-N-S) has source typeInformation source type (Identity Scheme)

Source (An ORM Metamodel)is contained inSource (Journal of Conceptual Modeling)

Source (An ORM Metamodel) is found atLocation (http://www.inconcept.com/JCM/

October2000/halpin.html)

has associatedservice description

Fin.Instrument MarketDetailServiceCur rency Convers ionS ervice Date ComparisonService

Service description

requires

MarketDetailService GetMarketPriceMarketDetailService GetIssuerDetailsConversionService FromAUDToUSD

Capabilitydescription

imposes

Price:<0.05 MarketDetai lServiceProvider:Aust ConversionServiceQ os :Hi gh C omp ari son Ser vi ce

Non-functionalconstraintsdescription

* ASIC = Australian Securities and Investment Commision* ISO = International Standards Organization * TFN = Australian Tax File Number

* ATO = Australian Taxation Office * ABN = Australian Business Number* ACN = Australian Company Number

is Outsourced

Informationsource type

(name)

{'Coding Scheme','Dictionary','Entity','Glossary','Identity scheme','Ontology',Service description,'Specification','Standard','Taxonomy','Thesaurus',...}

Fig. 2. Meta-model of outsourced object types

8 Upstream services are users or clients, downstream services are providers of func-tionality.



7

A meta-model is a way of describing models in terms of those, or other,models. In this section an ORM meta-model is used to describe the componentsand structure of outsourced object types. Three kinds of information have beenidentified for inclusion in an outsourced type description:

1. One or more identification schemes; the identity of the schemes that issueidentities for instances of the type.

2. Formal and informal definitions; a way of referring to descriptive informationabout the type itself and its instances.

3. A specification of the operational and non-functional capabilities to be asso-ciated with the outsourced type; a way of describing the actions and opera-tions that need to be provided for or by the outsourced type in this context.

Figure 2 is a populated ORM meta-schema for outsourced types. Outsourced

object types are a subtype of ORM Unnested Entity Types as defined in anORM meta-schema [8]. They participate in three relationships which match thethree types of information identified above.

The first is the mandatory role has instances governed by identification scheme.The mandatory constraint means that there must be a way of identifying thescheme that issued the outsourced types’ instance identifier. This rule makesexplicit the entity identification rules inherited from ORM while recognisingthat instance identifiers may come from different identification schemes.

The second role is has additional information, this allows other information tobe associated with the type, such as a definition in a thesaurus or ontology. Theinformation is intended to be used to aid the comprehension of the syntax andsemantics of the type and its roles in this context.

The central element in the meta-schema is Information source. The value con-straint attached to has source type shows an Information source can be of manydifferent types. One type in particular, the Service description, is shown as asubtype of Information source because we want to indicate that it contains aparticular kind of information and provides a link to the third role played byoutsourced types, has associated service description. This relationship allows var-ious requirements for downstream services to be associated with an outsourcedtype and its instances.

Information sources may also have other properties, they can contain or becontained within another source, they can be found at a particular location andinformation sources are published and/or controlled by some organisation.

The meta model describes the abstract syntax of the proposed extension.

An abstract syntax describes what can be done but not how it is represented.A sample representation of a concrete syntax is given in the shaded boxes inthe meta model. A concrete syntax appropriate for web application descriptionsis necessary but outside the scope of this paper. The following sections discussfurther the three parts of the outsourced type description



8

4.1 Service descriptions and capability oriented modeling

The lack of prior agreements between interaction partners means that there may

be mismatches between the data required for a service invocation and the dataavailable. In this case service descriptions are used to describe the operationaland non-functional capabilities for data translation and manipulation that mustbe provided by or for the outsourced type in this context. Some of the opera-tional capabilities will be generic, such as creating instances, comparison , format

translation and getting and setting values, others will be specific to the type, suchas retrieving the current market price from a financial instrument. A descriptionof the non-functional aspects of services can be found in [9].

The delegation of tasks to external services is a natural extension of theobject oriented and component programming paradigms. This kind of modulari-sation allows applications to concentrate on core competencies and delegate lessrelevant concerns to specialist services in non-core areas. At the conceptual levelthe modeler is only responsible for providing a description of what a service is

required to do or provide. At runtime, the choice of which service implementa-tion to use should be based on how well the service fulfils the required functionaland non-functional constraints; rather than (as now) the functionality that canbe inferred from a WSDL9 service description.

4.2 Other information sources

A web-based application should be able to provide clarification of the terms ituses by referring to definitions, ontologies and other sources of information. Theassociation of other sources of information with the outsourced type is primarilyfor the benefit of inference tools, it allows modelers to explicitly provide thesemantics of the terms used in this context. As application terminology is of-ten unique to a particular designer or software provider, support for dynamicruntime disambiguation and inferencing must be provided by the service itself.In addition, the use of common type systems such as external standards forthe internal representation of data provides interoperability with all the otherprograms using the same standards. References to type definitions and alter-native sources of information will enable inference engines to disambiguate theterms used in this context and is a practical step towards the goal of globalinteroperability.

The outsourced type Date demonstrates how external sources of informationcan be used. The outsourced type definition can refer directly to the ISO 8601Date specification, or it can take advantage of the XML Schema Datatypesspecification or schemas developed for use with RDF such as the Dublin Core(DC) element set10. Both the XML Schema and the DC date specifications are

based on ISO8601. For those applications that are not aware of the ISO standardor its syntax (ccyy-mm-dd), the outsourced type definition can also specify therequirements for services to translate dates to and from ISO format.

9 http://www.w3.org/2002/ws/desc/10 http://dublincore.org/documents/1999/07/02/dces



9

4.3 Identification

In the past, each application would provide its own unique identification mecha-nism for the local application context. However, in the global environment thereis often more than one externally controlled identification scheme, and entitiesmay have valid identities in several schemes. It is difficult to maintain unique-ness constraints over relationships when the same entity may have several valididentifiers in different schemes. It is also difficult to ensure both parties are dis-cussing the same instance, for example, failed trades, due to mistaken identityin cross border securities trading, costs millions of dollars every year [10].

In ORM each instance of an entity must have a unique identifier. An appli-cation that has outsourced entity types must be able to use different identifica-tion schemes while ensuring that different identities for the same instance are

recognised , and the opposite case where the same identifier in different schemes,identifies different instances. The use of external identification schemes means it

may not be possible to enforce some constraints within the local context, such as,the constraint that identities within a scheme must be unique. Such a constraintis only enforceable by the schemes’ controller.

Each identification scheme will be owned or controlled by a different orga-nization and each will serve a different purpose in addition to having differ-ent rules and jurisdiction over the target group. The coverage of identificationschemes may range from fully disjoint to fully overlapping depending on whichaspects/properties/roles of the entity that the scheme is interested in. Similarlythe scope of schemes may not be equivalent, for example the Australian ABNscheme [11] simply states that an Australian business exists and is registered(to pay tax), whereas a D-U-N-S11 implies some rating or assessment has takenplace before the identifier is issued. Identification schemes themselves may haveproperties such as; trustworthiness, accessibility, reliability and quality.

It may be necessary for some applications to limit the identification schemesthat can be used; either by limiting the number of schemes, by specifying ac-ceptable schemes by name, or by specifying the scope of acceptable schemes.The limitations on schemes could also be instance dependent, for example, if aPerson is involved in a relationship “pays tax” and the person is from USA thenonly accept USA TFN’s or USA SSN’s to identify that Person.

In some cases it may not be possible to determine if an instance has an iden-tity in a particular scheme, due to limitations on access to information withoutpayment of a subscription or because of security concerns. Security is also anissue when it is necessary to pass identity information to downstream services,there may be user constraints on who the information can be passed to, or howthe information can be used.

We are mainly concerned with outsourced types that may have differentidentities in different identification schemes rather than those that are coveredby a particular scheme and/or are in themselves a unique representation, suchas dates.

11 http://www.dnb.com



10

There are two conceptual modeling issues related to multiple identities thatare a consequence of using outsourced types in a global context. The first issue isthat there may not be an exhaustive list of all the possible identification schemesto start with, hence the model will not “know” about new schemes introducedafter the modeling process is complete. Consequently a form of schema evolutionis required to introduce new identity schemes.

In terms of our meta-model, an evolution mechanism for the introductionof new identification schemes would require information about the organizationthat controls, owns or publishes the scheme; whether or not its origin is basedupon some other published information, such as a standard or law; and a sourceof information about the scheme itself.

The second modeling issue related to using outsourced types, is ensuring theuniqueness constraints described in the base model are not violated when usinginstances of outsourced types. There are several options to prevent constraintviolations at the implementation level.

One option is to choose one or more of the external identification schemes tobe the canonical representation within the local application. A cover constraintis a requirement that all possible instances can be identified by the selectedidentification scheme or schemes. The schemes should be selected to minimisethe possibility of overlapping identities, and they should have a similar interestin aspects of the instances they identify.

In terms of the case study, we could choose the ISO 15022 standard for Inter-national Security Identification Numbers (ISIN) [12] as it is an internationallyagreed standard for the identification of securities. In reality we cannot use it onits own as it is not yet implemented in all countries. This means we would haveto use ISIN along with all the identification schemes used in all the countriesnot yet covered by the ISIN scheme.

Another option is to create an internal canonical identification scheme, andmap identities from multiple external schemes to the canonical identifier. Inmost applications, including the case study, it will be necessary to record whichidentification scheme a client prefers to enable the reverse mapping back to therepresentation the client understands. A mechanism to do this is discussed morefully in section 5.

The advantage of this approach is that complete coverage can be guaranteed,at least internally. Complete coverage ensures the single canonical identificationof any instance; and any instance previously unknown can be assigned a newidentifier in the local scheme. The use of a single (locally) controlled canonicalidentifier also ensures that the constraints concerning the outsourced types aresatisfied.

The canonical identity function could also be delegated to an external service

by using a Service description attached to the outsourced type. The capabilitiesand non-functional requirements for an identity service of this type are describedbelow.

The identification of Financial Instruments is just one example of the mul-tiplicity of identification schemes in the global context. In the first case above,



11

several existing schemes could be chosen to provide complete coverage. Howeverit will be difficult to find a manageably small number of schemes so that thiscan be done without overlapping identities. For this reason we tend to preferthe second option of a single canonical representation. The single canonical rep-resentation can be managed by a single party that has the ability to: ensureuniqueness constraints are preserved, include new identification schemes, andgenerate new identifiers when appropriate.

Given the above discussion and our preference for a unique canonical iden-tifier, the external capabilities required from an identification service for eachoutsourced type are:

– Provide a unique identifier for each instance of the outsourced type.– Provide a list of identifiers associated with each canonical representation.– Provide a list of canonical representations and schemes associated with an

identifier (to allow user selection when the scheme name is uncertain andthe identifier is ambiguous).

– Convert from an identifier and scheme to a canonical representation.– Convert from one scheme and identifier pair to another scheme and identifier,

if the identifier is represented in the other scheme.– Reverse-map the canonical representation back to the original identifier and

scheme.

The following internal capabilities must also be satisfied:

– Detect identical instances using different identification schemes.– Detect non-identical instances with the same identifier from different schemes.– Incorporate new identification schemes.– Incorporate new identifiers, ensuring requirements for uniqueness are met.

5 Realisation

Outsourced types provide a means to describe entities in terms of external in-formation, however web-based applications will need to store this informationlocally. In this section we discuss how ORM schemas, using outsourced types,must be modified to recognise multiple identity schemes. The storage of otherinformation related to an outsourced type instance will also need to be dealtwith but that is outside of the scope of this paper.

The problem we address here is, the existence of multiple external identityschemes is not evident from the representation of outsourced types in the localORM model. This means the relational mapping procedure (Rmap) [1], used toconvert an ORM model to a database schema, will be unaware of the multiple

identities that may be associated with an instance of an outsourced type.The following examples illustrate how the model must be augmented as a

precursor to Rmap. The procedure substitutes a canonical identifier for eachexternal identifier and its associated identification scheme, while retaining infor-mation about which scheme is being used in each role. There are many cases



12

that could be considered, each representing a different relationship and its con-straints that an outsourced type can participate in with other outsourced andnon-outsourced types. In this section we illustrate two sample cases that rep-resent different uniqueness constraints on binary relationships between an out-sourced and a non-outsourced entity type. The precursor to the Rmap transfor-mation is done in two stages.

1. In the first stage a canonical identifier is introduced in place of an externalidentifier and its associated identification scheme. To retain knowledge aboutthe relationship between the canonical identifier, the external identifier, andits associated identification scheme a ternary relationship, henceforth calledthe identity catalogue, is created. The identity catalogue is attached to theoutsourced type, which now uses the canonical identifier as its primary ref-erence scheme.The identity catalogue is used to record all the identifiers and schemes thatare known or can be found for a particular canonical identifier. There aretwo ways to build this list of schemes and their identifiers. The first option isto actively search for alternative identities and schemes when the databasetable is first created; the second option is to check and add new schemeswhen they are introduced to the application. The options represent a trade-off between the possibly lengthy time taken to populate the table when itis created and quick updates; or a longer time taken to make updates whilenew information is checked and incorporated into the table.

2. In the second stage a new binary relation is introduced to make explicitthe association of the canonical identifier and the identification scheme usedin a specific role. The association of this new relation with the entities inthe model depends upon the uniqueness constraints governing the wholerelationship. This is illustrated below in relation to the one to many and

many to many relationships.

Configuring a One to Many relationship. Figure 3(a) is in two parts, the topsection shows the original relationships between an outsourced type (Person)and local entity types (Event and Country). A problem with this model is theidentification scheme for Person is a composite of the identification scheme andan identity in that scheme. The composite identification means it is not possibleto ensure the uniqueness constraints over the represents or participates in rolescan be enforced. In the example, a Person may only represent one country but weare unable to determine from the identifiers, TFN:z024 and SSN:z021, that thesereally are different people. For this reason we introduce a canonical identifier(cid) for each outsourced entity instance and substitute the cid for the compositeidentification in the original participates in and represents roles.

The lower part of the figure is extended with an identity catalogue, to makethe relationships between the cid, and all its related identification schemes andidentities explicit. The identity catalogue is subject to two uniqueness con-straints. The first is over the external identifier and its identification scheme. Thisconstraint states that each identifier is unique within its identification scheme.



13

Country(code)

v is it s v is it ed b y

T FN :z0 21 U S

T FN :z0 21 C AS SN:x 32 1 RAS SN:0 b2 2 RAPI N:z 021 U KPI N:z 021 U S

p1 TFN z021p1 SSN x321p2 SSN 0b22

p2 TFN 234i4p3 PIN z021p3 TFN 12tx4

PersonIdentity(code)

Person

A person visits zero or more countries.A country is visited by zero or more people.

Person(cid)

PersonIdScheme!(code)

Country(code)

is identified

inidentifies

( p1, US) TFN( p1, CA) TFN( p1, RA) SSN( p2, RA) SSN( p3, UK) PIN( p3, US) PIN

p1 USp1 CAp1 RAp2 RAp3 UKp3 US

Visit

visits visited by

Person(cid)

Country(code)

representsrepresented

byT FN :z 02 1 US

S SN:0 b2 2 USSSN:RN0023 NZT FN :z 02 4 AU S SN:z 02 1 CA

p1 TFN z021p1 PIN 22145

p2 SSN 0b22p2 TFN 11268p3 SSN RN0023p4 TFN z024p5 SSN z021

PersonIdScheme!(code)

PersonIdentity(code)

Person

Country(code)

A person may represent zero or one country.A country is represented by zero or more

people.

representsrepresented

byp1 USp2 USp3 NZp4 AUp5 CA

has representativeidentity in

p1 TFNp2 SSNp3 SSNp4 TFN

p5 SSN

participatesin

S ho tp ut p 1Highjump p2Highjump p3Longjump p4Longjump p5

Event

has participantidentity in

PIN p1TFN p2SSN p3TFN p4

SSN p5

participatesin

Shotput PIN:22145

Highjump TFN:11268Highjump SSN:RN0023Longjump TFN:z024Longjump SSN:z021

Event

A person may participate in zero or one event.A event is participated in by zero or morepeople.

(a) (b)

Fig. 3. One to Many and Many to Many relationships

The second constraint states that each combination of cid and identificationscheme is unique. The combination of these two constraints means that a personwith identities in different identification schemes can be uniquely identified by asingle cid.

The next stage in the translation procedure is to make explicit the relation-ship between the cid and the identification scheme used in a particular role.The equality constraint between participates in and has participant identity in en-sures that when a cid appears in the participates in relation, then this cid andthe identification scheme used for this role are recorded in the new relation has

participant identity in. This relation records which specific scheme, amongst po-tentially many schemes, is relevant for the participates in relation. Similarly anew relation, has representative identity in, is constructed to represent the rele-vant identities and schemes for the represents relation. In both cases, as Person

is on the “one side” of the one to many relation we attach the new relationshipsto Person.

Configuring a Many to Many relationship. Figure 3(b) shows a visitation re-lationship between People and Countries. The primary concern in this case isto ensure that each row of the visits/visited by relationship is unique. In theoriginal schema we would be unable to enforce this constraint given the currentinformation. For example, TFN:z021 and SSN:x321 are different identity codes,

but are alternative identifiers for the same Person instance (p1).Although there are alternative ways to prepare the many to many conversion

for Rmap, we have elected to introduce an objectified relation Visit to representthe necessary information. The uniqueness constraint over the Visit roles ensuresthe original uniqueness requirement (that there are no duplicate rows) is main-



14

tained. The constraint ensures a Person cid, the PersonIdScheme used for thisparticular visit and a Country can all be associated with a single instance of aVisit.

A join subset constraint is placed over the roles involving a Person and aPersonIdScheme with the corresponding roles in the identity catalogue. This con-straint means that for every fact in which a certain Person is used in conjunctionwith a Person Id Scheme, we should have information about this combination inthe identity catalogue.

6 Related work

There are two main strands of interest and activity in the Web services area.The first strand is the focus of several industry organizations including the Webservices Interoperability Organization12 and the World Wide Web Consortium

(W3C) Web services Activity13

which includes the Web services Architecture andWeb services Description working groups. This strand is largely based upon theSOAP , WSDL and UDDI specifications. These services will, in the main, requireoff-line agreement between the parties over the semantics of WSDL interfacesand the message flow pattern before they can be used for automated interaction.

Web Services Description Language (WSDL) defines a grammar for describ-ing the functionality of Web services. It has become the de-facto standard forthe description of Web services and is currently (October 2002) in the process of being updated and revised by the World Wide Web Consortiums’ Web servicesDescription Working Group14. WSDL does not provide facilities for describingthe semantics implicit in a Web service description. SOAP provides a mechanismto wrap and transport XML messages, and the UDDI specification provides amechanism to advertise Web services in a UDDI registry. These three specifi-

cations provide a framework for automated interaction but do not provide thefacilities required for automated interoperability.

The second strand are semantic web services [13–15]. These services are onthe boundary between the Semantic Web and Web services, where semanticcontent and some intelligence are used in conjunction with the specificationslisted above to provide a greater range of automated invocation and usability.In these services the interaction sequence will be determined by the goals of theuser rather than the internal processes of the service provider.

The Web Service Modeling Framework (WSMF) [16, 14] is one of the interest-ing proposals in this area. The WSMF is based on two principles, the de-couplingof the various components that make up a Web service, and the use of medi-ators to translate between heterogeneous data representations and interactionstyles. Outsourced types, as described in this paper, fit into this framework byproviding an explicit basis for data and semantic mediation.

12 http://www.ws-i.org13 http://www.w.org/2002/ws14 http://www.w3.org/2002/ws/desc/



15

7 Conclusion

There are several benefits of using outsourced types, the primary ones are the re-duction in complexity of the local model, the potential to reuse definitions (bothlocally and globally) and the enhanced potential for heterogeneous interoper-ability via the use of shared information. Outsourced types allow the modelerto make explicit the semantics of the entity types in the application context.The outsourced type definition also provides the basis for downstream servicecomposition by allowing specific statements of what capabilities the outsourcedtype is expected to provide for the local model.

Ontologies have been the subject of much work recently [17, 18] and theycan provide high level views of a domain or lower level context specific views.One advantage of our method of extending conceptual models is that the ORMmodel can be used as the basis of a local ontology [19, 2] or an application profile[20] that ties the local context to the global context via outsourced types. ORM

provides the assurance of a methodology and modeling language that have beenproven with time and experience to assist in building well formed conceptualmodels. The building of valid and useable ontologies will be better accomplishedby using this accepted and proven conceptual modeling methodology.

References

1. Halpin, T.: Information Modeling and Relational Databases: from conceptual anal-ysis to logical design. Morgan Kaufmann Publishers, San Diego, CA, USA (2001)

2. Dumas, M., Aldred, L., Heravizadeh, M., ter Hofstede, A.H.: Ontology Markup forWeb Forms Generation. In: Proceedings of WWW2002 Workshop on Real WorldRDF and Semantic Web Applications, Honolulu, Hawaii, USA (2002) 59–68

3. Demey, J., Jarrar, M., Meersman, R.: A markup Language for ORM Business Rules

(2002) International Workshop on Rule Markup Languages for Business Rules onthe Semantic Web, Sardinia (Italy) in conjunction with the First InternationalSemantic Web Conference (ISWC2002).

4. Bird, L., Goodchild, A., Halpin, T.A.: Object Role Modelling and XML-Schema.In: Proceedings of the 19th International Conference on Conceptual Modeling(ER), Salt Lake City, Utah, USA, Springer-Verlag (2000) 309–322

5. International Organization for Standardization: ISO 8601:2000 Data elements andinterchange formats – Information interchange – Representation of dates and times(2000) Available at: http://www.iso.org, (25 February 2002).

6. International Organization for Standardization: ISO 4217:2001 Codes for the rep-resentation of currencies and funds. (2001) Available at: http://www.iso.org, (25February 2002).

7. Weber, R., Zhang, Y.: An analytical evaluation of NIAM’s grammar for conceptualschema diagrams. Information Systems Journal 6 (1996) 147–170

8. Halpin, T.: An ORM Metamodel. Journal of Conceptual Modeling Issue 16

(2000)9. O’Sullivan, J., Edmond, D., ter Hofstede, A.: What’s in a service? Towards ac-

curate description of non-functional service properties. Distributed and ParallelDatabases Journal - Special Issue on E-Services 12 (2002) 117–133



16

10. London Stock Exchange: Exchange to introduce new global num-bering system (2002) Press Release, 7 November 2002, available from:http://www.londonstockexchange.com/newsroom/releases, (28 November 2002).

11. Australian Securities and Investment Commission: What’s in a name?business names, company names, domain names and trade marks (2001)http://www.asic.gov.au/asic/asic.nsf, (11 July 2002).

12. von Rochow, I.B., Yous, N.: ISO 6166: Securities - International securi-ties identification numbering system (ISIN) (2001) Information available from:http://www.anna-web.com/, (4 September 2002).

13. Bussler, C., Fensel, D., Payne, T., Sycara, K.: Semantic Web Services (2002) ISWCTutorial, Chia, Sardinia, Italy. http://www.daml.ri.cmu.edu/tutorial/iswc-t3.html,(8 July 2002).

14. Bussler, C., Fensel, D., Maedche, A.: A Conceptual Architecture for Semantic WebEnabled Web Services. SIGMOD Record, Special Section on Semantic Web andData Management 31 (2002)

15. Ankolekar, A., Burstein, M., Hobbs, J.R., Lassila, O., Martin, D.L., McIl-raith, S.A., Narayanan, S., Paolucci, M., Payne, T., Sycara, K., Zeng,H.: Daml-s: Semantic markup for web services (2001) Available fromhttp://www.daml.org/services/daml-s/2001/10/daml-s.html31 January 2002.

16. Fensel, D., Bussler, C.: The Web Service Modeling Framework WSMF (2002)to appear in Electronic Commerce Research and Applications. Available from:http://www.cs.vu.nl/ dieter/wese/wsmf.paper.pdf, (30 September 2002).

17. McGuinness, D.L.: Ontologies and Online Commerce. IEEE Intelligent Systems(2001) 9–10

18. Das, A., Wu, W., McGuinness, D.L.: Industrial Strength Ontology Management.In Cruz, I., Decker, S., Euzenat, J., McGuinness, D., eds.: The Emerging SemanticWeb. Frontiers in Artificial Intelligence and Applications, Volume 75. IOS Press(2002)

19. Meersman, R.: Ontologies and Databases: More than a Fleeing Resemblance. Avail-able from: http://www.starlab.vub.ac.be/staff/robert/, (22 April 2002) (2002)

20. Baker, T., Dekkers, M., Heery, R., Patel, M., Slokhe, G.: What Terms Does YourMetadata Use? Application Profiles as Machine Understandable Narratives. Jour-nal of Digital Information 2 (2001)

outsourced types

Documents