© 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
Michael Sonntag 4XML Techniques for E-Commerce: Standards
Standards
XML
HTML
XML
FOXML
Schema
XMLName-space
XSLT
XPath
JavaebXML, SOAP,
SecurityMetadata,
...
Michael Sonntag 5XML Techniques for E-Commerce: Standards
Standards
XML
HTML
XML
FOXML
Schema
XMLName-space
XSLT
XPath
JavaebXML, SOAP,
SecurityMetadata,
...
Michael Sonntag 6XML Techniques for E-Commerce: Standards
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
Michael Sonntag 7XML Techniques for E-Commerce: Standards
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, ...
Michael Sonntag 8XML Techniques for E-Commerce: Standards
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
Michael Sonntag 9XML Techniques for E-Commerce: Standards
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
Michael Sonntag 10XML Techniques for E-Commerce: Standards
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
Michael Sonntag 11XML Techniques for E-Commerce: Standards
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
Michael Sonntag 12XML Techniques for E-Commerce: Standards
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
Michael Sonntag 13XML Techniques for E-Commerce: Standards
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
Michael Sonntag 14XML Techniques for E-Commerce: Standards
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, …
Michael Sonntag 15XML Techniques for E-Commerce: Standards
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)
Michael Sonntag 16XML Techniques for E-Commerce: Standards
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, ...
Michael Sonntag 17XML Techniques for E-Commerce: Standards
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, …
Michael Sonntag 18XML Techniques for E-Commerce: Standards
Standards
XML
HTML
XML
FOXML
Schema
XMLName-space
XSLT
XPath
JavaebXML, SOAP,
SecurityMetadata,
...
Michael Sonntag 19XML Techniques for E-Commerce: Standards
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
Michael Sonntag 20XML Techniques for E-Commerce: Standards
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
Michael Sonntag 21XML Techniques for E-Commerce: Standards
<?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
Michael Sonntag 22XML Techniques for E-Commerce: Standards
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
Michael Sonntag 23XML Techniques for E-Commerce: Standards
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
Michael Sonntag 24XML Techniques for E-Commerce: Standards
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
Michael Sonntag 25XML Techniques for E-Commerce: Standards
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
Michael Sonntag 26XML Techniques for E-Commerce: Standards
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
Michael Sonntag 27XML Techniques for E-Commerce: Standards
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
Michael Sonntag 28XML Techniques for E-Commerce: Standards
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
Michael Sonntag 29XML Techniques for E-Commerce: Standards
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
Michael Sonntag 30XML Techniques for E-Commerce: Standards
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
Michael Sonntag 31XML Techniques for E-Commerce: Standards
Standards
XML
HTML
XML
FOXML
Schema
XMLName-space
XSLT
XPath
JavaebXML, SOAP,
SecurityMetadata,
...
Michael Sonntag 32XML Techniques for E-Commerce: Standards
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
Michael Sonntag 33XML Techniques for E-Commerce: Standards
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
Michael Sonntag 34XML Techniques for E-Commerce: Standards
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
Michael Sonntag 35XML Techniques for E-Commerce: Standards
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
Michael Sonntag 36XML Techniques for E-Commerce: Standards
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
Michael Sonntag 37XML Techniques for E-Commerce: Standards
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
Michael Sonntag 38XML Techniques for E-Commerce: Standards
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
Michael Sonntag 39XML Techniques for E-Commerce: Standards
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
Michael Sonntag 40XML Techniques for E-Commerce: Standards
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
Michael Sonntag 41XML Techniques for E-Commerce: Standards
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
Michael Sonntag 42XML Techniques for E-Commerce: Standards
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
Michael Sonntag 43XML Techniques for E-Commerce: Standards
Standards
XML
HTML
XML
FOXML
Schema
XMLName-space
XSLT
XPath
JavaebXML, SOAP,
SecurityMetadata,
...
Michael Sonntag 44XML Techniques for E-Commerce: Standards
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
Michael Sonntag 45XML Techniques for E-Commerce: Standards
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
Michael Sonntag 46XML Techniques for E-Commerce: Standards
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!
Michael Sonntag 47XML Techniques for E-Commerce: Standards
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)
Michael Sonntag 48XML Techniques for E-Commerce: Standards
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
Michael Sonntag 49XML Techniques for E-Commerce: Standards
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
Michael Sonntag 50XML Techniques for E-Commerce: Standards
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]” />
</rdf:Description></rdf:RDF>
S OP
O SP
Object for first part, subject for second!FIM.rdf, FIM_Short.rdf
Michael Sonntag 51XML Techniques for E-Commerce: Standards
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]” />
</rdf:Description></rdf:RDF>
http://www.fim.uni-linz.ac.at
http://www.fim.uni-linz.ac.at/staffID/8154711
Creator
Michael Sonntag [email protected]
Name EMail
Michael Sonntag 52XML Techniques for E-Commerce: Standards
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!
Michael Sonntag 53XML Techniques for E-Commerce: Standards
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
Michael Sonntag 54XML Techniques for E-Commerce: Standards
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
Michael Sonntag 55XML Techniques for E-Commerce: Standards
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
Michael Sonntag 56XML Techniques for E-Commerce: Standards
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!
Michael Sonntag 57XML Techniques for E-Commerce: Standards
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)
Michael Sonntag 58XML Techniques for E-Commerce: Standards
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
Michael Sonntag 59XML Techniques for E-Commerce: Standards
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
Michael Sonntag 60XML Techniques for E-Commerce: Standards
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
Michael Sonntag 61XML Techniques for E-Commerce: Standards
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
Michael Sonntag 62XML Techniques for E-Commerce: Standards
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/
Michael Sonntag 63XML Techniques for E-Commerce: Standards
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/