Standards ebXML, SOAP&WSDL&UDDI, XML Security, RDF&OWL

Standards ebXML, SOAP&WSDL&UDDI, XML Security, RDF&OWL
Mag. iur. Dr. techn. Michael Sonntag Standards ebXML, SOAP&WSDL&UDDI, XML Security, RDF&OWL XML Techniques for E-Commerce, Budapest 2005 Institute for Information Processing and Microprocessor Technology (FIM) Johannes Kepler University Linz, Austria

Please ask immediately!
? ? Questions? ? ? Please ask immediately! ? ?

Content Why XML in E-Business?
We will cover four different groups of standards briefly: Business data interchange: ebXML Defining the data to be exchanged between companies Web services: SOAP, WSDL, UDDI How to transfer data, provide electronic services, integrate software XML Security: XML Encryption, XML Signature Securing data to be transferred against repudiation an eavesdropping Metadata standards: RDF, OWL Annotating web shop data, defining the meaning of data for exchange

ebXML, SOAP, Security Metadata, ...
Standards ebXML, SOAP, Security Metadata, ... HTML Java XML XML FO XML Schema XSLT XML Name-space XPath

Why XML? HTML, EDI, ... have been sufficient in the past!
HTML is a presentation language and very hard to parse Syntax is quite open, different "versions", ... EDI is extremely complicated and difficult XML is like relational databases RDB = Storage, XML = Transmission A framework for structured content But the actual rows/elements must be defined by the user! Difficulty: Mapping from one XML schema to another Syntax is rather easy: XSL for "rewriting" Semantics is much more difficult! Often not available in "usable" form; e.g. in a text document Semantic description possible today; semantic "rewriting" still far away Some early and easy examples possible through automatic deduction

The N2 problem Each company has its own way of doing business and therefore also its own data schema Mapping data schemas to each other has a complexity of O(N2) This is not feasible for more than very few partners! But how often must company A map data from B directly to C? Solution: Define your own "canonical" schema and convert all data to it (and then back to a different schema if required) Complexity: O(N), or more exactly 2N (from and to each partner) Still a difficulty: Exchanging the internal software, processes, etc. All transformations would have to be modified Solution: A single transformation from the canonical data schema to your own internal representation Practice: Database and schema identical at start; drift apart later on Important: Allow separation right from the beginning!

The N2 problem Complete meshing Direct mappings
Client 1 Client 2 Client 3 Internal representation T 1 T 4 T 2 T 3 T 5 T 6 T 7 Client 1 Client 2 Client 3 Internal representation T 1 T 2 T 3 Client 1 Client 2 Client 3 Canonical schema Internal representation T 0 T 1 T 2 T 3 Complete meshing Direct mappings Intermediate data schema

Automatic conversions
The conversions from before should be made automatically This requires: Exact syntax definition (incl. charset, size of data elements, ...) Exact semantics definition Is "delivery date" the date of sending or the expected date of receipt? All definitions must be explicitly clear and unambiguous Platform independence: All software/hardware/platforms supported What would be nice in addition: Automatically verifying input and output whether it is syntactically correct and "makes sense"; as extensive as possible Easily extensible: Adding new data, messages, protocols Strict definition: If there exists a way, there should be only one way Simplicity: Learning curve should be low and flat Possibility for industry standards

How to exchange a sequence of messages
ebXML ebXML = Electronic Business XML Should 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 framework For the exchange of business data Components: Business process models Includes e.g. parties and message sequences Message formats Repositories/Directories Main advantage: Simpler and cheaper More suitable for SMEs How to exchange a sequence of messages

ebXML Concepts Each company describes its business process
Manually or from a standard definition E.g. "Buying something" = Send request, wait for ack., wait for acceptance, send invoice, send goods, ... Process and company data is stored in a registry Allows finding out what they do and how they do it Practice: Probably not public! Describing a business arrangement What processes were actually agreed upon to be performed Defined service for message exchange How to deliver/receive messages with non-repudiation, encryption, signatures, ...

ebXML Use case ebXML Registry CPP ACME AG The first company (ACME AG) provides information about the processes it can perform in a registry This is a "CPP" (Collaboration Party Profile)

ebXML Use case ebXML Registry CPP ACME AG CPP Widgets Inc. 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

ebXML Use case CPP CPA CPP
ebXML Registry CPP ACME AG CPA CPP Widgets Inc. Both agree on certain processes to be performed The result is a "CPA" (=Collaboration Protocol Agreement) This could be derived automatically if desired and both provide CPP's!

ebXML Use case CPP Msg #1 CPA Msg #2 CPP
ebXML Registry CPP ACME AG CPA Msg #1 CPP Msg #2 Widgets Inc. ACME and Widget exchange messages and perform the processes/protocols they agreed upon

ebXML Important issues
DB ebXML Registry CPP ACME AG CPA Msg #1 CPP Msg #2 W DB Widgets Inc. 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!

CPP Specifies what a party can do: Contains:
Business Transactions: Models the processes and the roles Separate specification Delivery Channel: Message sending/receiving characteristics Document Exchange Layer: Encryption, signature, reliability Transport Layer: Transport protocol, endpoint address Contains: Contact information: company can consist of several "parties" E.g. office supply and production supply departments Security details: what certificates/where to find, public keys, ... Message structure: what messages consist of Comments

CPA Specifies what the parties will do:
Describes the visible (i.e. external and enforceable) interactions between the parties Independent 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 agreed Automatically derived or manually negotiated Contains: Additional status value (proposed, signed, ...) Lifetime: Consent may be time-limited Constraints on conversations: E.g. at most ? concurrent, ? total maximum, …

Message transfer Secure and reliable exchange of messages between parties Message structure for packaging the actual content "Just another" kind of packaging Behavior 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 once Ensuring information survives any single failure Optional: Message ordering Ensuring messages arrive in specific order (at application!) Optional: Multi-hop messaging (using intermediaries)

Message transfer schematic
ebXML Application Message Service Interface Error Handling Authentication, authorization, non-repudiation Header Processing Encryption and/or Signatures Message Packaging Delivery Module Send/Receive Transport Mapping and Binding Transport: HTTP, SMTP, ... Message Service Interface: Defined by the actual ebXML implementation Independent from the application! Header Processing: Creation/Parsing of ebXML headers Uses the CPA Message 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, ...

Implementations Some implementations (and applications) exist
Mainly from large companies and for enterprise systems Case studies seem to be not that frequent currently Free software also partially available JAXR: Java API for XML Registries Can access XML registries, also supports ebXML and UDDI Still nothing for the "small company" out of the box But selected applications can be created probably rather easily Problem: Better than EDI, but still expensive to setup Integration, specification of documents, administration, …

Web services: SOAP, WSDL, UDDI
UDDI: Universal Discovery, Description & Information Protocol For finding the location/available procedures to call "Yellow pages" of web services providing metadata about them WSDL: Web Service Description Language Describing the procedures available SOAP: 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!

SOAP Simple Object Access Protocol
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 alone One-way: There is no response to a message The other side may, however, decide to send a new message, which might 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

SOAP Message structure
<?xml version="1.0"?> <soap:Envelope xmlns:soap=" soap:encodingStyle=" <soap:Header> </soap:Header> <soap:Body> ... <soap:Fault> ... </soap:Fault></soap:Body> </soap:Envelope> Either: One or more child elements Or a single fault element SOAP Envelope SOAP Header Header block Header block SOAP Body Body child element SOAP Fault Body child element

SOAP Intermediaries 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 block Role "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

SOAP "mustUnderstand" and "relay" attributes
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 onwards A 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 Faults Describes error during processing of the header or the body Must 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 body Some faults are predefined VersionMismatch, MustUnderstand, DataEncodingUnknown Sender: Incorrect message; do not resend Receiver: Recipient problem; may be resent identically

SOAP HTTP Binding Theoretically SOAP need not be represented as XML
It 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

PingPong.wsdl, Ping.txt, Pong.txt
SOAP Example messages Connection test message ("Ping") from a real system Described using WSDL Transmitted by SOAP over HTTP PingPong.wsdl: Description of this call Ping.txt: Sending a RPC command SOAPAction: Specific additional SOAP header; describes action POST command: Wants to send additional details In this case: Procedure parameter "message" of type string Value: "Hello" Pong.txt: Reply to the command New SOAP message with the parameter "result" of type string Value: "Test.ping.Ping2ResponderAgent responds to Hello" PingPong.wsdl, Ping.txt, Pong.txt

WSDL Web Service Description Language
For describing the syntax of web services and their locations Consists of the following elements: Definitions: Root node for defining several services Service: 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)

WSDL Four kinds of transmission
One-way: Send a message; no response received Request-response: Send and wait for result Notification, Solicit-response: Reverse op.; not completely specified Bindings defined for SOAP, HTTP and MIME HTTP: Pure; different from SOAP transported by HTTP! MIME: E.g. sending it directly in 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 and programming AXIS: One Java XML framework for web services
Supports WSDL and SOAP (with attachments) And some other goodies! From WSDL description, Java code is generated automatically Only the actual "servicing code" must be filled in In general the following parts are required (unless optimized!) Stub: Client side representation Packages everything into a SOAP message and unpacks the result Skeleton: Server side representation Unpackages the request, calls the actual implementation and packages the result (or the error) into a SOAP message Locator For locating the server to call (explicitly, UDDI, manually, etc.) Additional classes (e.g. custom types, interfaces)

Stubs and skeletons Client application Webservice implementation Locator Stub Empty representation Skeleton Calls actual implementation Registry Transport (e.g. HTTP) Stub must look exactly like the actual implementation for the client Skeleton calls actual implementation with exactly the same parameters and accepts all results (incl. all exceptions, errors, ...) The whole subsystem must be invisible to client and application

UDDI Universal Discovery, Description & Information
Inquiry and discovery Four 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 policy Support XML signatures verify integrity/publisher

UDDI Replication Subscription
Support for messages to keep several registries with same content Subscription Publishing: Uploading information to a registry Subscribing: Notification on changes within the registry Internationalization: Mostly provided by XML already Uses the "xml:lang" attribute Supports language dependent collation UDDI provides both data structures and API! Inquiry, publish, …: WSDL specification Communication with registry: To be implemented with SOAP

Web service example: Amazon.com
Allows users to interface and extract lots of data One-way service only: Retrieving/Querying data only One exception: Sending a shopping cart back to Amazon so visitors to your site can directly purchase goods selected on your site! New extension: Search engine integration (Alexa.com) Web search, URL information, crawl metadata (size, checksum, links, images, ...), web map (list of in- and outbound links) Limited to requests/day per subscription ID Free for now, but will be charged for later Available data: Product data: availability, price, size, image,.... Customer content: Reviews, wish lists, lists Seller information: General info and customer feedback For third-party shops/sellers affiliated with Amazon zShops and Marketplace product data

Web service example: Amazon.com
Several restrictions apply, e.g. No copying of content (selling, redistribution, price extraction, ...) Usage restrictions (violence, illegal activities, ...) Frequency limit (1 call/second/IP-address) Caching limited to 24 hours Incentive to use it Percentage of sales made through this Put some recommendations on your website, insert a "local" whopping cart and hope your visitors buy from Amazon later Interface: REST (=HTTP GET) or SOAP Result: XML REST: XSLT transformation with provided stylesheet also supported More info:

XML Security Consists of two independent parts:
XML Signature: Providing non-repudiation XML Encryption: Providing secrecy Both trivially accomplished by existing technologies/standards But 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 files Problem: 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

C14N: XML Canonicalization
Produce a unique physical representation of an XML fragment Not 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 #xA Attribute values: Normalized, double quotes, default attr. added Content text: CDATA, entities, special characters, … Superfluous elements: XML declaration, DTD, unneeded NS Extraneous whitespace: Within tags, outside of document element Ordering: Attributes within a tag, namespace declarations Limitations: Base URIs, notations, external unparsed entity references, attribute types in DTD

XML Encryption Structure
Encrypted can be: The whole XML documents A single XML element XML element content: several (sub-)elements XML element content: character data Encrypted data can again be encrypted without problem Encrypted data is represented by the following information Encryption method: The algorithm used Key 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 it Additional properties

XML Encryption Algorithms
Algorithms are identified by URIs Some of them must be implemented (not used!), some are optional Block encryption: TripleDES, AES-128, AES-256, AES-192 Stream encryption: None specified! Key transport: RSA-v1.5, RSA-OAEP Key agreement: Diffie-Hellman Symmetric key wrap: TripleDES, AES-128, AES-256, AES-192 Message digest: SHA1, SHA256, SHA512, RIPEMD-160 Message authentication: XML digital signature Canonicalization: (Exclusive) canonical; with(-out) comments Encoding: Base64 The encoded result is for almost all algorithms binary data! Required Recommended Optional

XML Encryption Java Currently there exists no API specification
This is under development by Sun in JSR 106 Implementation 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.java Order_3.xml, Order_encrypted.xml, Order_decrypted.xml

XML Encryption Problems
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 Signature A signature consists of Three kinds of signatures exist
The 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 signed Additional properties: E.g. timestamp Three kinds of signatures exist Enveloping: Signed data contained within the Object information Enveloped: 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 Transformations
Describe how to obtain the data object to be digested Ordered list: Result of first is input for second, … Each transform consists of an algorithm and appr. Attributes Examples: 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 Signature Algorithms
Algorithms are identified by URIs Some of them must be implemented (not used!), some are optional Digest: SHA1 Encoding: Base64 MAC: HMAC-SHA1 MAC=Message Authentication Code (=crypt. hash algorithm) Signature: DSAwithSHA1, RSAwithSHA1 Canonicalization: Canonical XML omitting comment, with comm. Transform: Enveloped signature, XPath, XSLT Required Recommended Optional

Sign.java, Verify.java Order_3.xml, Order_signed.xml
XML Signature Java An API specification was created in JSR 105 Implementation available in WSDL 1.6 We use the version from Apache Which might not yet conform exactly to this specification) 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 certificates The resulting signed document is no longer valid! The signature (or any other extensions) is not specified in the schema Sign.java, Verify.java Order_3.xml, Order_signed.xml

XML Signature + Encryption
Both do not specify new algorithms These must be acquired separately (patent problems, …)! Combining both can lead to problems Signing 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

RDF, OWL: Metadata specifications
RDF and OWL try to add semantics to XML XML 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 descriptions E-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? …

Relation between XML and RDF, DAML+OIL, OWL, DC
Many different languages for semantics For different applications / from different sources RDF = Resource Description Framework DAML + OIL = DARPA Agent Markup Language + Ontology Inference Layer OWL = Web Ontology Language Successor of DAML+OIL DC = Dublin Core Metadata Origin: libraries, describing web objects DC XML, Schema RDF DAML+OIL OWL

Reasons & Goals for RDF RDF = Resource Description Framework
Motivation: Web metadata: Information about web resources Applications requiring open information models: E. g. Scheduling Must work together with many different systems/applications Machine processable: Retrieving information and deriving new one Interworking of applications: Common format and deriving Automated 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!

RDF Basic structure (1) Format for metadata
Mainly 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 semantics RDF Schema: This is NO vocabulary! System of types and constructs for defining vocabularies!

Subject Object Predicate
RDF Basic structure (2) Completely based on triplets (everything!) Subject, Predicate, Object Subject and object are identified by URI's URL (Uniform Resource Locator): Web address URI (Uniform Resource Identifier): Can specify everything; need not be a web address (could e. g. also be an URN)! Nodes can also remain anonymous Containers exist for easily integrating several objects (bag, sequence, alternative) Subject Object Predicate

RDF Structure Subject Object Predicate Structure of statements in XML:
<rdf:Description about=“………”> <……….>……… </……….> </rdf:Description> Is always called "Description" Statements can be combined Reduces typing only, semantics exactly the same Can be expanded at any time and by anybody Subject Object Predicate

RDF Example S O P O S P FIM.rdf, FIM_Short.rdf
The resource “ was created by the person with the number The name of this person is Michael Sonntag and it has the address <rdf:RDF ……> <rdf:Description rdf:about=" <s:Creator rdf:resource=" </rdf:Description> <rdf:Description rdf:about=" <s:Name>Michael Sonntag</s:Name> </rdf:RDF> The object from the first statement is the subject in the second one! Shortened form: <s:Creator rdf:resource=" s:Name=“Michael Sonntag” /> S O P O S P Object for first part, subject for second! FIM.rdf, FIM_Short.rdf

RDF Graphical example Same statement as above, graphically displayed:
<rdf:RDF ……> <rdf:Description rdf:about=" <s:Creator rdf:resource=" s:Name=“Michael Sonntag” /> </rdf:Description> </rdf:RDF> Creator Michael Sonntag Name

RDF Schema (=RDFS) Something different than XML Schema!
Specifies not the structure but the meaning! Object oriented idea: Classes and inheritance Basis: 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 possible Very powerful; can make things extremely difficult to understand!

OWL: Successor of DAML+OIL
OWL = Web Ontology Language Very similar to DAML+OIL, ist predecessor Therefore also an extension of XML, RDF and RDF Schema Goal: Separating definition of semantics  Application Basic idea: From singular facts and rules new facts can be deduced (inferred) automatically Example: Rule: MotherOf subpropertyOf ParentOf Fact: Maria MotherOf Herbert Result: 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), Full
Lite: Classification hierarchy and simple constraints Implementation rather easy DL (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 time Full: 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 RDF
There they are mostly imported from XML Schema Examples: class, subClassOf, property, subPropertyOf Practical use: Use XML Schema datatypes directly Additional datatype: rdfs:Literal Imported 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 such This is the main reason for OWL! A special enumeration datatype in OWL (owl:oneOf) Describing a class by exhaustively listing all its instances Not 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 field rdfs: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)

Properties: Domain and Range
Person Item ID unsignedInteger Domain Range A Person has (can have) the property (attribute) ID An Item has (can have) the property (attribute) ID An ID is an unsigned integer Domain DomainRange.owl Range

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 unique Property 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. class Cardinality: Specifying the number of "partners" of a property E.g. minCardinality = Each individual has this property at least x times Sets: 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

Literature ebXML ebXML Homepage http://www.ebxml.org/
Collaboration-Protocol Profile and Agreement CPPA Specification 2.0 ( ) Messaging services homepage ebXML Messaging Services Specification 2.1 (WD ) freebXML Mertz: Understanding ebXML Chase: Introduction to ebXML

Literature SOAP, WSDL, UDDI
SOAP Version 1.2 Part 0: Primer SOAP Version 1.2 Part 1: Messaging Framework Web Service Description Language (WSDL) 1.1 UDDI Homepage Apache Axis Java SAAJ (SOAP with Attachments API for Java) Java Web Services Developer Pack

Literature Security XML Encryption (several standards) XML Signature (several standards) XML Canonicalization Exclusive XML Canonicalization Apache XML Security

Literature RDF / OWL Noy/McGuinness: Ontology Development 101 RDF: DAML+OIL: OWL:

Standards ebXML, SOAP&WSDL&UDDI, XML Security, RDF&OWL

Similar presentations

Presentation on theme: "Standards ebXML, SOAP&WSDL&UDDI, XML Security, RDF&OWL"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Standards ebXML, SOAP&WSDL&UDDI, XML Security, RDF&OWL

Similar presentations

Presentation on theme: "Standards ebXML, SOAP&WSDL&UDDI, XML Security, RDF&OWL"— Presentation transcript:

Similar presentations

About project

Feedback