ebXML, SOAP&WSDL&UDDI, XML Security, RDF&OWL · PDF fileHow to exchange a sequence of...

© Michael Sonntag 2004

StandardsebXML, SOAP&WSDL&UDDI, XML Security, RDF&OWL

XML Techniques for E-Commerce, Budapest 2004

Mag. iur. Dr. techn. Michael Sonntag

Institute for Information Processing andMicroprocessor Technology (FIM)

Johannes Kepler University Linz, AustriaE-Mail: [email protected]://www.fim.uni-linz.ac.at/staff/sonntag.htm

© Michael Sonntag 2004

QuestionsQuestions??Please ask immediately!

? ?

??

??

Michael Sonntag 3XML Techniques for E-Commerce: Standards

Content

We will cover four different groups of standards briefly:Business data interchange: ebXML

» Defining the data to be exchanged between companiesWeb services: SOAP, WSDL, UDDI

» How to transfer data, provide electronic services, integrate softwareXML Security: XML Encryption, XML Signature

» Securing data to be transferred against repudiation an eavesdroppingMetadata standards: RDF, OWL

» Annotating web shop data, defining the meaning of data for exchange


Standards

XML

HTML

XML

FOXML

Schema

XMLName-space

XSLT

XPath

JavaebXML, SOAP,

SecurityMetadata,

...


ebXML

ebXML = Electronic Business XMLShould be a successor for EDI

» EDI problems: ex(t/p)ensive software and hardware, difficult to implement, integration into existing software

Is a comprehensive global frameworkFor the exchange of business data

Components:Business process models

» Includes e.g. parties and message sequencesMessage formatsRepositories/Directories

Main advantage: Simpler and cheaperMore suitable for SMEs

How to exchange a sequence of messages


ebXMLConcepts

Each company describes its business processManually or from a standard definitionE.g. "Buying something" = Send request, wait for ack., wait for acceptance, send invoice, send goods, ...

Process and company data is stored in a registryAllows finding out what they do and how they do itPractice: Probably not public!

Describing a business arrangementWhat processes were actually agreed upon to be performed

Defined service for message exchangeHow to deliver/receive messages with non-repudiation, encryption, signatures, ...


ebXMLUse case

The first company (ACME AG) provides information about the processes it can perform in a registry

This is a "CPP" (Collaboration Party Profile)

ACME AGCPPebXML Registry


ebXMLUse case

The second company (Widgets Inc.) queries the registry and finds a suitable trading partner (=ACME)

It retrieved the CPP and compares it with its desires

CPP

CPP

ebXML Registry

Widgets Inc.

ACME AG


ebXMLUse case

Both agree on certain processes to be performedThe result is a "CPA" (=Collaboration Protocol Agreement)

» This could be derived automatically if desired and both provide CPP's!

CPP

CPPCPA

ebXML Registry

Widgets Inc.

ACME AG


ebXMLUse case

ACME and Widget exchange messages and perform the processes/protocols they agreed upon

ebXML Registry

CPP

CPPCPA

Msg#1 Msg

#2

Widgets Inc.

ACME AG


ebXMLImportant issues

Documents shown are clearly defined, verifiable, secure, ...Software on both sides is standard and unmodified

Both must provide a data mapping to their local systems only!

ebXML Registry

CPP

Widgets Inc.

CPPCPA

Msg#1 Msg

#2

WDB

ACME AG

ADB


CPP

Specifies what a party can do:Business Transactions: Models the processes and the roles

» Separate specificationDelivery Channel: Message sending/receiving characteristicsDocument Exchange Layer: Encryption, signature, reliabilityTransport Layer: Transport protocol, endpoint address

Contains:Contact information: company can consist of several "parties"

» E.g. office supply and production supply departmentsSecurity details: what certificates/where to find, public keys, ...Message structure: what messages consist ofComments


CPA

Specifies what the parties will do:Describes the visible (i.e. external and enforceable) interactions between the partiesIndependent of the internal processes of all parties

» Mapping should be simple because everything exchanged is XML!Intersection of the CPP's of the trading partners

Must be mutually agreedAutomatically derived or manually negotiated

Contains:Additional status value (proposed, signed, ...)Lifetime: Consent may be time-limitedConstraints on conversations: E.g. at most ? concurrent,? total maximum, …


Message transfer

Secure and reliable exchange of messages between partiesMessage structure for packaging the actual content

» "Just another" kind of packagingBehavior of message service handler (MSH)

» This is something "new"!Doesn't define a spec. interface (data format + semantics, not API)!

» Can be implemented in Java or C, with different names, etc.!Extension to SOAP and "SOAP Messages with Attachments"Optional: Reliable messaging

Ensuring messages are delivered e.g. exactly onceEnsuring information survives any single failure

Optional: Message orderingEnsuring messages arrive in specific order (at application!)

Optional: Multi-hop messaging (using intermediaries)


Message transfer schematic

Message Service Interface: Defined by the actual ebXML implementation

» Independent from the application!Header Processing: Creation/Parsing of ebXML headers

» Uses the CPAMessage Packaging: Final packaging of ebXML into SOAPwA (Enveloping, ...)

» Headers + Payload (= business content)Delivery Module: Actual connection using certain protocols, incl. acknowledgments

» Persistence, retries, error notifications, ...

ebXML Application

Message Service Interface

Erro

r H

andl

ing

Authentication, authorization,

non-repudiation

Header Processing

Encryption and/or Signatures

Message Packaging

Delivery ModuleSend/Receive

Transport Mapping and Binding

Transport: HTTP, SMTP, ...


Implementations

Some implementations (and applications) existMainly from large companies and for enterprise systemsCase studies seem to be not that frequent currently

Free software also partially availableJAXR: Java API for XML Registries

Can access XML registries, also supports ebXML and UDDI

Still nothing for the "small company" out of the boxBut selected applications can be created probably rather easily

Problem: Better than EDI, but still expensive to setupIntegration, specification of documents, administration, …


Standards

XML

HTML

XML

FOXML

Schema

XMLName-space

XSLT

XPath

JavaebXML, SOAP,

SecurityMetadata,

...


UDDI: Universal Discovery, Description & Information ProtocolFor finding the location/available procedures to call

» "Yellow pages" of web services providing metadata about themWSDL: Web Service Description Language

Describing the procedures availableSOAP: Simple Object Access Protocol

RPC (Remote Procedure Call) protocol over the Web» Other styles also supported, e.g. free messaging

For all three "services" alternatives exist, but these seem to be those most widely used and the best candidates for the future!

Web services:SOAP, WSDL, UDDI


Communication protocol for message exchange between applications via the Internet

Usually sent via HTTP, but other possible (e.g. SMTP)» Good/Bad: Can get around firewalls by this!

Stateless: Each message stands aloneOne-way: There is no response to a message

» The other side may, however, decide to send a new message, whichmight be semantically in reply to this one!

Routing, reliability, etc.: Not addressed!Consists of up to three parts:

Envelope: Marks this XML document as a SOAP message» Header (optional): Context info, custom extensions» Body (required): The actual call/response» Fault (optional): Exceptions, errors, … that occurred during processing

SOAPSimple Object Access Protocol


<?xml version="1.0"?><soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"><soap:Header> ... ... </soap:Header><soap:Body> ... <soap:Fault> ... </soap:Fault></soap:Body>

</soap:Envelope>

SOAPMessage structure

SOAP Envelope

SOAP Header

SOAP Body

Header block

Header block

Body child element

Body child element

SOAP Fault

Either:One or more child elementsOr a single fault element


SOAP messages may be sent over several "hops"These are called "intermediaries"The last recipient is the "ultimate receiver"

SOAP does NOT specify how these are selected!No routing; e.g. a header element could contain a route, but each intermediary would have to understand it and act accordingly!

Processing of header blocks depends on the role of the "node"Role "next": Header block is intended for the next intermediary

» Must be examined, but not necessarily processed!Role "ultimateReceiver": Intermediaries must ignore this blockRole "none": May not be processed

» But might be referenced from a different header block!Which role a node plays is defined by the application!

» Additional roles can be defined by the application

SOAPIntermediaries


Special header attributes:A header block marked as mustUnderstand MUST be processed

» If it is not understood, a failure message must be created!» The message may not be processed any further» This is intended for important information about block handling

– E.g. requiring that it be encrypted before sending it onwardsA header block marked as relay MUST be relayed if it is NOT processed by this intermediary

» If it is processed, it MUST always be removed– Another header block could however reinsert it!

» If it is not processed, it must be passed on to the next recipient– Default would be to remove it, if it is targeted at this intermediaries role!

SOAP"mustUnderstand" and "relay" attributes


Describes error during processing of the header or the bodyMust contain code and reason

» Code may contain subcodes» Reason is a textual description, perhaps in several languages

Can contain node, role (of the node) and detail» Node: The node that generated the fault (important for intermediaries)» Detail: Application defined information; can be any XML content

The only child element within a SOAP bodySome faults are predefined

VersionMismatch, MustUnderstand, DataEncodingUnknownSender: Incorrect message; do not resendReceiver: Recipient problem; may be resent identically

SOAPFaults


Theoretically SOAP need not be represented as XMLIt just hast to adhere to the "XML Infoset", which is more or less the "content" and "style" of XML (is abstract data set)

Similarly, SOAP need not be sent by HTTP (e.g. SMTP possible)This is the main protocol, however, and the only one standardized!GET: Send a simple request and expect a SOAP reply

» No SOAP request possible, only a simple URL» The "object" identified by the URI should stay the same (read-only)!

POST: Sending a SOAP request and expecting a SOAP reply» The "object" identified by the URI can also be modified (read-write)!

In both cases the SOAP reply (=complete XML document) is just sent instead of the HTTP content (after the HTTP headers)

» This also applies to the request for HTTP POST

SOAPHTTP Binding


Connection test message ("Ping") from a real systemDescribed using WSDLTransmitted by SOAP over HTTP

PingPong.wsdl: Description of this callPing.txt: Sending a RPC command

SOAPAction: Specific additional SOAP header; describes actionPOST command: Wants to send additional details

» In this case: Procedure parameter "message" of type string– Value: "Hello"

Pong.txt: Reply to the commandNew SOAP message with the parameter "result" of type string

– Value: "Test.ping.Ping2ResponderAgent responds to Hello"

PingPong.wsdl, Ping.txt, Pong.txt

SOAPExample messages


For describing the syntax of web services and their locationsConsists of the following elements:

Definitions: Root node for defining several servicesService: Specifies the ports which can be used for bindings

» Connecting ports and bindings» Port: Single endpoint address for a binding (e.g. URL)

Binding: How an operation is invoked» Protocol and data formats for the operations and messages» How to encode the parameters; RPC or messaging

PortType/Operation: Description of the action(s) ("Procedure name")» Specifies input and output message

Message: Definition of the data communicated» What will be sent over the network as a unit; data types of content

Types: Defines complex data types used (e.g. in messages)

WSDLWeb Service Description Language


Four kinds of transmissionOne-way: Send a message; no response receivedRequest-response: Send and wait for resultNotification, Solicit-response: Reverse op.; not completely specified

Bindings defined for SOAP, HTTP and MIMEHTTP: Pure; different from SOAP transported by HTTP!MIME: E.g. sending it directly in E-Mail attachments

From WSDL necessary classes can be generated automatically!Stub (Proxy): On the client side; called by the application

» Packs everything into XML (from the native programming language)Skeleton: On the server side; called by the SOAP implementation

» Calls the actual implementation (or is replaced by it)Helper classes: For any datatypes specified, locating endpoints, …

This makes RPCs over SOAP transparent for the application!With some restrictions: error handling, acquiring the endpoint

WSDL


Inquiry and discoveryFour core types

» businessEntity: Information about the parts publishing the data– E.g. Name, description, contact information

» businessService: Describing a particular family of technical services– E.g. Purchase: Submission, confirmation, notification

» bindingTemplate: Technical information on a a single service– E.g. entry point, content specification

» tModel: Descriptions of specifications for services or taxonomies– E.g. webservice type, protocol, category system; could be WSDL– Not contained within the registry itself; this contains only pointers to it!

Everything is accessed by unique identifiers (UUID)Security

Access control through a policySupport XML signatures verify integrity/publisher

UDDIUniversal Discovery, Description & Information


ReplicationSupport for messages to keep several registries with same content

SubscriptionPublishing: Uploading information to a registrySubscribing: Notification on changes within the registry

Internationalization: Mostly provided by XML alreadyUses the "xml:lang" attributeSupports language dependent collation

UDDI provides both data structures and API!Inquiry, publish, …: WSDL specificationCommunication with registry: To be implemented with SOAP

UDDI


Standards

XML

HTML

XML

FOXML

Schema

XMLName-space

XSLT

XPath

JavaebXML, SOAP,

SecurityMetadata,

...


Consists of two independent parts:XML Signature: Providing non-repudiationXML Encryption: Providing secrecy

Both trivially accomplished by existing technologies/standardsBut only for the complete file!

» This prevents e.g. writing the signature into the XML file itself!» Locating parts is no longer possible in encrypted files» Tags are also encrypted ⇒ known plaintext attack possible» No schema validation while encrypted

Solution: Standards for encrypting/signing parts of XML filesProblem: XML content may differ binary but be logically the same

E.g. linefeeds, blanks, entity style/replacement, CDATA sections,…Solution: Canonical XML

» Specific "formatting" which always produces the same binary result

XML Security


Produce a unique physical representation of an XML fragmentNot foolproof: Even more strict is "Exclusive XML Canonicalization"Works not really well for parts which are not well-formed

Unifies:Character set: Always UTF-8 in NFC (=Normalization Form C)Linebreaks: Always #xAAttribute values: Normalized, double quotes, default attr. addedContent text: CDATA, entities, special characters, …Superfluous elements: XML declaration, DTD, unneeded NSExtraneous whitespace: Within tags, outside of document elementOrdering: Attributes within a tag, namespace declarations

Limitations:Base URIs, notations, external unparsed entity references, attribute types in DTD

C14N:XML Canonicalization


Encrypted can be:The whole XML documentsA single XML elementXML element content: several (sub-)elementsXML element content: character data

Encrypted data can again be encrypted without problemEncrypted data is represented by the following information

Encryption method: The algorithm usedKey information: How to find the key for decryption or the key itself

» Symmetric encryption: The key itself (encrypted!)» Asymmetric encryption: The public key used» General: Name or pointer to the key to be used

The enciphered data: Value or pointer to itAdditional properties

XML EncryptionStructure


Algorithms are identified by URIsSome of them must be implemented (not used!), some are optional

Block encryption: TripleDES, AES-128, AES-256, AES-192Stream encryption: None specified!Key transport: RSA-v1.5, RSA-OAEPKey agreement: Diffie-HellmanSymmetric key wrap: TripleDES, AES-128, AES-256, AES-192Message digest: SHA1, SHA256, SHA512, RIPEMD-160Message authentication: XML digital signatureCanonicalization: (Exclusive) canonical; with(-out) commentsEncoding: Base64

The encoded result is for almost all algorithms binary data!

XML EncryptionAlgorithms

Required Recommended Optional


Currently there exists no API specificationThis is under development by Sun in JSR 106Implementation available from Apache in Java and C

» Requires external library for the actual encryption, … algorithms!Very simple to use

But take care of the problems (see next slide!)» E.g. the encrypted order has some weird namespace declarations!

The real problem is often somewhere else: Key management!Where to (securely!) store encryption/signature keys?How to identify the key to use (certificates, public registries, …)?

Encrypt.java, Decrypt.javaOrder_3.xml, Order_encrypted.xml, Order_decrypted.xml

XML EncryptionJava


When namespaces are used, these may be inherited by the element which is to be encrypted

Or explicitly removed by specifying ' xmlns:ns="" 'When this is encrypted and later decrypted and put into a different context, the result might be invalid!

With empty namespace even in the same context» On canonicalization this might be stripped away, so after decryption

the default namespace is inherited instead of removed!xml:base, xml:lang, xml:space attributes: May cause problems

These are also inherited!

The application must take care to specify these things explicitly or know exactly into which context to put the result of decryption!

XML EncryptionProblems


A signature consists ofThe actual signature value (base64 encoded)Signature information:

» Canonicalization, signature, digest method» What was actually signed: URI/XPath, …; additional transformations

Information on the key to use for verification» E.g. certificate (X.509, PGP, …), key name, …

Object information: What is actually signedAdditional properties: E.g. timestamp

Three kinds of signatures existEnveloping: Signed data contained within the Object informationEnveloped: An ancestor of the signature is signed

» The signature itself must be excluded from digesting, obviously!Detached: External content (identified by URI or Transform)

XML Signature


Describe how to obtain the data object to be digestedOrdered list: Result of first is input for second, …

Each transform consists of an algorithm and appr. AttributesExamples:

Two enveloped signatures required: Each signature must exclude itself, but it must also exclude the other signature

Enveloped transform: Equivalent to the following XPath transform<XPath xmlns:dsig="&dsig;">count(ancestor-or-self::dsig:Signature | here()/ancestor::dsig:Signature[1]) >count(ancestor-or-self::dsig:Signature)</XPath>

» If the direct parent signature is in the set of all outer signatures, this element is excluded from signing

XML SignatureTransformations


Algorithms are identified by URIsSome of them must be implemented (not used!), some are optional

Digest: SHA1Encoding: Base64MAC: HMAC-SHA1

MAC=Message Authentication Code (=crypt. hash algorithm)Signature: DSAwithSHA1, RSAwithSHA1Canonicalization: Canonical XML omitting comment, with comm.Transform: Enveloped signature, XPath, XSLT

XML SignatureAlgorithms

Required Recommended Optional


Currently there exists no API specificationUnder development by Sun in JSR 105 (proposed final draft)Implementation available from Apache in Java and C

» Requires external library for the actual signature, … algorithms!Example:

Please note that the verification checks only the cryptographic quality of the signature!

» I.e. verification will success for ANY signature with ANY key!– Real application should check whether the certificate is something

trusted/expected or use their own certificatesThe resulting signed document is no longer valid!

» The signature (or any other extensions) is not specified in the schemaSign.java, Verify.java

Order_3.xml, Order_signed.xml

XML SignatureJava


Both do not specify new algorithmsThese must be acquired separately (patent problems, …)!

Combining both can lead to problemsSigning encrypted data: How to know what is really signed?

» Should be avoided; task of the application!Encrypting signed data: How to know whether signature verification should be done before decryption or afterwards?

» If complete structure is encrypted ⇒ no problem» When only subparts are encrypted, this gets important!» Example: Signing the payment information and later on encrypting the

creditcard number, but leaving the name in cleartext» There exists a separate specification for this!

– Introduces "exception" elements to the transformation

XML Signature + Encryption


Standards

XML

HTML

XML

FOXML

Schema

XMLName-space

XSLT

XPath

JavaebXML, SOAP,

SecurityMetadata,

...


RDF and OWL try to add semantics to XMLXML Schema describes the syntax; but the meaning is not in there!

Application areas:Languages of the "Semantic Web"

» Bringing "meaning" to the WWW (=Metadata on resources)Artifical Intelligence

» Knowledge bases (Representing and deriving knowledge)» Exchanging facts

Agents: Inter-agent communication, machine readable descriptionsE-Commerce: "Translation" between applications

» Like a "stylesheet": This element from company A means the same as that element from company B

» Example: "deliveryDate": Is this the expected date of delivery or the actual one? What will be delivered then? Is it the time of sending or of receiving the goods? …

RDF, OWL:Metadata specifications


Relation between XML and RDF, DAML+OIL, OWL, DC

DC

XML, SchemaRDFRDF

DAML+OIL OWL

Many different languages for semantics» For different applications / from different sources

RDF = Resource Description FrameworkDAML + OIL

» = DARPA Agent Markup Language + Ontology Inference LayerOWL = Web Ontology Language

» Successor of DAML+OILDC = Dublin Core Metadata

» Origin: libraries, describing web objects


Reasons & Goals for RDF

RDF = Resource Description FrameworkMotivation:

Web metadata: Information about web resourcesApplications requiring open information models: E. g. Scheduling

» Must work together with many different systems/applicationsMachine processable: Retrieving information and deriving new oneInterworking of applications: Common format and derivingAutomated processing of web information by software agents

Common language for all and everything!Did not quite succeed: As base useful, but additions needed

» Especially agreed upon vocabularies/ontologies!Has a very simple but strict structure

» Still powerful: You can express everything with it!


Format for metadataMainly intended for the WWW, but universally usable; now the WWW is only a small part any more

Strong tie with XML (=Representation)XML + Schema (Datatypes) + Namespaces

» Can also be representation in other ways, however, e. g. pure text!Formals semantics

Allows employing inference rules (deriving new knowledge from the sum of already known facts and rules)

RDF: Data model, RDF Schema: Specification of semanticsRDF Schema: This is NO vocabulary!

System of types and constructs for defining vocabularies!

RDFBasic structure (1)


Completely based on triplets (everything!)Subject, Predicate, Object

Subject and object are identified by URI'sURL (Uniform Resource Locator): Web addressURI (Uniform Resource Identifier): Can specify everything; need not be a web address (could e. g. also be an URN)!

» Nodes can also remain anonymousContainers exist for easily integrating several objects (bag, sequence, alternative)

RDFBasic structure (2)

Subject ObjectPredicate


Structure of statements in XML:<rdf:Description about=“………”>

<……….>……… </……….>

</rdf:Description>

Is always called "Description"

Statements can be combinedReduces typing only, semantics exactly the sameCan be expanded at any time and by anybody

RDFStructure

Subject

Predicate

Object


RDFExample

The resource “http://www.fim.uni-linz.ac.at/” was created by the person with the number 8154711. The name of this person is Michael Sonntag and it has the E-Mail address [email protected]

<rdf:RDF ……><rdf:Description rdf:about="http://www.fim.uni-linz.ac.at/">

<s:Creator rdf:resource="http://www.uni-linz.ac.at/staffID/8154711"/></rdf:Description><rdf:Description rdf:about="http://www.uni-linz.ac.at/staffId/8154711">

<s:Name>Michael Sonntag</s:Name><s:EMail>[email protected]</s:EMail>

</rdf:Description></rdf:RDF>

The object from the first statement is the subject in the second one!Shortened form:<rdf:RDF ……><rdf:Description rdf:about="http://www.fim.uni-linz.ac.at/">

<s:Creator rdf:resource="http://www.uni-linz.ac.at/staffID/8154711"s:Name=“Michael Sonntag”s:EMail=“[email protected]” />


S OP

O SP

Object for first part, subject for second!FIM.rdf, FIM_Short.rdf


RDFGraphical example

Same statement as above, graphically displayed:<rdf:RDF ……><rdf:Description rdf:about="http://www.fim.uni-linz.ac.at/">

<s:Creator rdf:resource="http://www.uni-linz.ac.at/staffID/8154711"s:Name=“Michael Sonntag”s:EMail=“[email protected]” />


http://www.fim.uni-linz.ac.at

http://www.fim.uni-linz.ac.at/staffID/8154711

Creator

Michael Sonntag [email protected]

Name EMail


RDF Schema(=RDFS)

Something different than XML Schema!Specifies not the structure but the meaning!

Object oriented idea: Classes and inheritanceBasis: Resource (Everything is a resource)"Class": A class

» Derivations: subClassOf"Property": Features of a class / contained data

– Describes the class itself– Describes members of the class

» Specialization: subPropertyOf– E. g. biologicalFather is specialization of biologicalParent

Multiple inheritance possibleVery powerful; can make things extremely difficult to understand!


OWL: Successor of DAML+OIL

OWL = Web Ontology LanguageVery similar to DAML+OIL, ist predecessorTherefore also an extension of XML, RDF and RDF Schema

Goal: Separating definition of semantics ⇔ ApplicationBasic idea: From singular facts and rules new facts can be deduced (inferred) automatically

» Example:Rule: MotherOf subpropertyOf ParentOfFact: Maria MotherOf HerbertResult: Maria ParentOf Herbert

Using XML this would be for the application to know and decide and would not NOT be encoded in XML!

» Here this is an automatic conclusion from the rules and facts stated above; no "application knowledge" (=programming) needed for this


OWL subtypes

Three subtypes: Lite, DL (Description Logic), FullLite: Classification hierarchy and simple constraints

» Implementation rather easyDL (Description Logics): Maximum expressiveness but still "runable"

– Similar to description logics, therefore the name– This is similar to DAML+OIL from the semantics point of view

» Computational completeness: All possible conclusions are guaranteed to be computed

» Decidability: All computations will finish in finite timeFull: Maximum expressiveness

» E. g. a class can also be treated as an individual= a class itself can be an instance of another class

» No guarantee on completeness and decidability possible» Implementation very hard


OWL:Concepts

OWL mostly specified special "Tags" on classes and properties"Tags" in the sense of "marker", "meaning" , etc.Specifies additional "properties" for them

» E. g. this property 'A' is the same as another one ('B')– Therefore if we know that something has 'A', we also know that it has 'B'

This applies to semantics, not syntax!E. g. the property is

»called different and has »different classes as arguments,»but its meaning is the same

Syntax: Just another name


OWL: Datatypes (1)

Datatypes are taken from RDFThere they are mostly imported from XML Schema

» Examples: class, subClassOf, property, subPropertyOfPractical use: Use XML Schema datatypes directly

Additional datatype: rdfs:LiteralImported from RDF Schema

» Plain literal: Ordinary string» Typed literal: Instance of a datatype class (see below)

In addition the constructed (composed) datatypes!Each class can be seen as a datatype and used as suchThis is the main reason for OWL!

A special enumeration datatype in OWL (owl:oneOf)Describing a class by exhaustively listing all its instancesNot in OWL-Lite!


OWL:Datatypes (2)

From RDF Schema (across DAML+OIL) imported:rdfs:domain: Restriction of the individuals, which can have a certain property (≈ defining which methods an object can have)

» Which class can have this property (source)– Similar to a "reverse view" of an interface in Java:

Specifies which classes can contain a certain method or fieldrdfs:range: Restriction of the individuals this property can assume as its value

» Which values the instance can have (destination)– "Real" datatype of the property; what can be put "into" the field

Individuals: Instances of classes (similar to objects)


A Person has (can have) the property (attribute) IDAn Item has (can have) the property (attribute) IDAn ID is an unsigned integer

Properties:Domain and Range

Person Item

ID

unsignedInteger

Domain

Range

Domain

Range DomainRange.owl


OWL:Constructs

OWL supports the following constructs to define ontologies:Equivalence: Classes/properties/instances are the same

» E.g. sameAs = the two individuals are identical (not merely equal!)Difference: Explicitly defining things to be apart

» E.g. allDifferent = for defining names to be uniqueProperty characteristics: inverse, transitivity, symmetry, functional

» E.g. if "X prop1 Y" and "prop1 inverseOf prop2" then "Y prop2 X"Restrictions: Reducing the available set for values of properties

» E.g. someValuesFrom = Each individual has >=1 values of spec. classCardinality: Specifying the number of "partners" of a property

» E.g. minCardinality = Each individual has this property at least x timesSets: Class definition by intersection, union, complement

» E.g. "A intersectionOf B" = individuals which are of class A and also of class B are automatically of this (defined by this statement) class


LiteratureebXML

ebXML Homepage http://www.ebxml.org/Collaboration-Protocol Profile and Agreementhttp://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-cppaCPPA Specification 2.0 (23.9.2002)http://www.oasis-open.org/committees/download.php/204/ebcpp-2.0.pdfMessaging services homepagehttp://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-msgebXML Messaging Services Specification 2.1 (WD 25.3.2004)http://www.oasis-open.org/committees/download.php/6130/wd-ebMS-2_1-04.pdffreebXMLhttp://www.freebxml.org/Mertz: Understanding ebXMLhttp://www-106.ibm.com/developerworks/xml/library/x-ebxml/Chase: Introduction to ebXMLhttp://www-106.ibm.com/developerworks/xml/edu/x-dw-xebxml-i.html


LiteratureSOAP, WSDL, UDDI

SOAP Version 1.2 Part 0: Primerhttp://www.w3c.org/TR/2003/REC-soap12-part0-20030624/SOAP Version 1.2 Part 1: Messaging Frameworkhttp://www.w3c.org/TR/2003/REC-soap12-part1-20030624/Web Service Description Language (WSDL) 1.1http://www.w3.org/TR/wsdlUDDI Homepagehttp://www.uddi.org/Apache Axishttp://ws.apache.org/axis/Java SAAJ (SOAP with Attachments API for Java)http://java.sun.com/xml/saaj/index.jspJava Web Services Developer Packhttp://java.sun.com/webservices/downloads/webservicespack.html


LiteratureSecurity

XML Encryption (several standards)http://www.w3.org/Encryption/2001/XML Signature (several standards)http://www.w3.org/Signature/XML Canonicalizationhttp://www.w3.org/TR/2001/REC-xml-c14n-20010315Exclusive XML Canonicalizationhttp://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/Apache XML Securityhttp://xml.apache.org/security/


LiteratureRDF / OWL

Noy/McGuinness: Ontology Development 101http://www.ksl.stanford.edu/people/dlm/papers/ontology101/ontology101-noy-mcguinness.html

RDF:http://www.w3.org/RDF/DAML+OIL:http://www.daml.org/OWL:http://www.w3.org/2004/OWL/

ebXML, SOAP&WSDL&UDDI, XML Security, RDF&OWL · PDF fileHow to exchange a sequence of...

Documents

Transcript of ebXML, SOAP&WSDL&UDDI, XML Security, RDF&OWL · PDF fileHow to exchange a sequence of...