• WSMO – a conceptual model for:
  • Ontologies
  • Web Services
  • Goals
  • Mediators
• However, WSMO does not provide a concrete syntax and semantic
• A unifying language (syntax and semantics) is needed for specifying WSMO Ontologies, Web Services, Goals, and Mediators
  • The Web Service Modeling Language (WSML)
• Existing semantic Web languages are not expressive enough to capture all aspects of WSMO
  • RDFS: only a very limited ontology language, and no support for Web services, Goals, or Mediators
  • OWL: a language for modeling ontologies based on the Description Logic paradigm, however does not offer direct means to describe Web Services, Goals and Mediators
  • OWL-S: an OWL ontology for the modeling Web services, but is not expressive enough for capturing all aspects of Web service; new languages such as SWRL or KIF have been embedded in OWL-S, however such combinations are often ambiguous and complicated

• Three pillars of WSML, namely 
  • a language independent conceptual model for Ontologies, Web Services, Goals and Mediators, based on WSMO
  • Reuse of several well-known logical language paradigms in one syntactical framework
  • Web Compliance
• One syntactic framework for a set of layered languages
  • Different Semantic Web and Semantic Web Service applications need languages of different expressiveness 
  • No single language paradigm will be sufficient for all use cases
  • WSML investigates the use of Description Logics and Logic Programming for Semantic Web Services
• Separation of conceptual and logical modeling
  • The conceptual syntax of WSML has been designed in such a way that it is independent of the underlying logical language
  • No or only limited knowledge of logical languages is required for the basic modeling of Ontologies, Web Services, Goals, and Mediators
  • The logical expression syntax allows expert users to refine definitions on the conceptual syntax using the full expressive power of the underlying logic, which depends on the particular language variant chosen by the user

• Semantics based on well known formalisms 
  • WSML captures well known logical formalisms such as Datalog and Description Logics in a unifying syntactical framework
    • WSML maintains the established computational properties of the original formalisms through proper syntactic layering
  • The variants allow the reuse of tools already developed for these formalisms
    • Efficient querying engines developed for Datalog 
    • Efficient subsumption reasoners developed in the area of Description Logics
    • Inter-operation between the above two paradigms is achieved through a common subset based on Description Logic Programs
• WWW Language 
  • WSML adopts the IRI standard, the successor of URI, for the identification of resources, following the Web architecture
  • WSML adopts the namespace mechanism of XML and datatypes in WSML are compatible with datatypes in XML Schema and datatype functions and operators are based on the functions and operators of XQuery
  • WSML defines an XML syntax and an RDF syntax for exchange over the Web

• WSML Variants - allow users to make the trade-off between the provided expressivity and the implied complexity on a per-application basis

• The figure shows the different variants of WSML and the relationship between the variants. In the figure, an arrow stands for "extension in the direction of". The variants differ in the logical expressiveness they offer and in the underlying language paradigm. By offering these variants, we allow users to make the trade-off between the provided expressivity and the implied complexity on a per-application basis. As can be seen from the figure, the basic language WSML-Core is extended in two directions, namely, Description Logics (WSML-DL) and Logic Programming(WSML-Flight, WSML-Rule). WSML-Rule and WSML-DL are both extended to a full First-Order Logic with nonmonotonic extensions(WSML-Full), which unifies both paradigms. 

• WSML-DL - an extension of WSML-Core which fully captures the Description Logic SHIQ(D), which captures a major part of the (DL species of the) Web Ontology Language OWL

• No support for nominals (i.e. enumerated classes) as in OWL
• Allows to write enumerations of individuals
• oneOf(Monday, Tuesday, Wednesday, Thursday, Friday,Saturday, Sunday)
• Support for Qualified Cardinality Restrictions (QCR)
  • Used to constrain the number of values of a particular property
  • ”The normal hand has exactly five fingers of which one is a thumb”
  • OWL does not support QCR: Class(NormalHand restriction (hasFinger cardinality (5)))
  • No possibility to model the fact that one finger is a thumb in OWL

• WSML-Rule - an extension of WSML-Flight in the direction of Logic Programming
  • Captures several extensions such as the use of function symbols and unsafe rules, and does not require stratification of negation
  • The semantics for negation is based on the Stable Model Semantics 

• WSML-Full - unifies WSML-DL and WSML-Rule under a First-Order syntactic umbrella with extensions to support the nonmonotonic negation of WSML-Rule
  • Allows the full syntactic freedom of a First-Order logic and the full syntactic freedom of a Logic Programming language with default negation in a common semantic framework
• Compared to WSML-DL, WSML-Full adds full first-order modeling: n-ary predicates, function symbols and chaining variables over predicates
• Compared to WSML-Rule, WSML-Full adds disjunction, classical negation, multiple model semantics, and the equality operator

• The figure below shows the relation between WSML and the existing or emerging SW standards: WSML is a more general language and integrates and extends the existing SW language standards. The figure depicts the part of W3C languages which is under consideration.

• WSML adopts the namespace mechanism of RDF; a namespace can be seen as part of an IRI 
  • Namespaces can be used to syntactically distinguish elements of multiple WSML specifications and, more generally, resources on the Web
  • A namespace denotes a syntactical domain for naming resources
• An identifier in WSML is either a data value , an IRI , an anonymous ID , or a variable
  • The sets of identifiers of the following items are disjoint: ontology, goal, Web service, ooMediator, ggMediator, wgMediator, wwMediator, capability, interface, choreography, orchestration, state signature, grounding identifier, variant identifier, datatype wrapper identifier, built-in predicate identifier
• Namespaces were first introduced in XML for the purpose of qualifying names which originate from different XML documents. In XML, each qualified name consists of a tuple <namespace, localname>. RDF adopts the mechanism of namespaces from XML with the difference that qualified names are not treated as tuples, but rather as abbreviations for full URIs. 
• WSML adopts the namespace mechanism of RDF. A namespace can be seen as part of an IRI. 

• Namespaces can be used to syntactically distinguish elements of multiple WSML specifications and, more generally, resources on the Web. A namespace denotes a syntactical domain for naming resources.
• Whenever a WSML specification has a specific identifier which corresponds to a Web address, it is good practice to have a relevant document on the location pointed to by the identifier. This can either be the WSML document itself or a natural language document related to the WSML document. Note that the identifier of an ontology does not have to coincide with the location of the ontology. It is good practice, however, to include a related document, possibly pointing to the WSML specification itself, at the location pointed to by the identifier.
• For identifiers: If the same identifier is used for different definitions, it is interpreted differently depending on the context. In a concept definition, an identifier is interpreted as a concept; in a relation definition this same identifier is interpreted as a relation. If, however, the same identifier is used in separate definitions, but with the same context, then the interpretation of the identifier has to conform to both definitions and thus the definitions are interpreted in a connectional way. For example, if there are two concept definitions which are attached to the same concept identifier, the resulting concept definition includes all attributes of the original definitions. Also if the same attribute is defined in both concept definitions, the range of the resulting attribute will be equivalent to the connection of the ranges of the original attributes.

• WSML has direct support for different types of concrete data, namely, strings, integers and decimals, which correspond to the XML Schema primitive datatypes string, integer and decimal
• Concrete values can then be used to construct more complex datatypes, corresponding to other XML Schema primitive and derived datatypes, using datatype constructor functions
• Examples:
  xsd#date(2005,3,12) 
  xsd#boolean("true") 
  age ofType xsd#integer 
  hasChildren ofType xsd#boolean

• The IRI (Internationalized Resource Identifier) mechanism provides a way to identify resources
  • IRIs may point to resources on the Web (in which case the IRI can start with 'http://'), but this is not necessary (e.g. books can be identified through IRIs starting with 'urn:isbn:')
    • "http://example.org/PersonOntology#Human" 
    • "http://www.uibk.ac.at/"
• An IRI can be abbreviated to a Compact URI - it consists of two parts, namely, the namespace prefix and the local part
  • A Compact URI is written using a namespace prefix and a localname, separated by a hash ('#'): namespace_prefix#localname
    
    dc#title (http://purl.org/dc/elements/1.1#title) 
    foaf#name (http://xmlns.com/foaf/0.1/name) 
    xsd#string (http://www.w3.org/2001/XMLSchema#string) 
    Person (http://example.org/#Person) 
    hasChild (http://example.org/#hasChild)

• An anonymous identifier represents an IRI which is meant to be globally unique
  • Unnumbered anonymous IDs are denoted with ‘_#’. Each occurrence of ‘_#’ denotes a new anonymous ID and different occurrences of ‘_#’ are unrelated
  • Numbered anonymous IDs are denoted with ‘_#n’ where n stands for an integer denoting the number of the anonymous ID
    
    _#[a hasValue _#1] and _#1 memberOf b. 
    _#1[a hasValue _#] and _# memberOf _#.

• Anonymous identifiers are disallowed for the following elements:
  • the top-level elements ontology, goal, webService, ooMediator, ggMediator, wgMediator and wwMediator
  • capability, interface, choreography and orchestration

• Variable names start with an initial question mark "?"
• May only occur in place of concepts, attributes, instances, relation arguments or attribute values
  • A variable may not, for example, replace a WSML keyword however
• Variables may only be used:
  • Inside of logical expressions, and 
  • As values in a non-functional property definition or in the sharedVariables block within capability definitions
• Examples: ?x, ?y1, ?myVariable

• WSML Prologue contains all those elements that are in common between all types of WSML specifications and all WSML variants:
  • WSML Variant e.g. the WSML variant reference for a WSML-Flight specification is:
    wsmlVariant _http://www.wsmo.org/wsml/wsml-syntax/wsml-flight
  • Namespace References, e.g. 
    
    namespace {_"http://www.example.org/ontologies/example#",
    dc _"http://purl.org/dc/elements/1.1#", 
    foaf _"http://xmlns.com/foaf/0.1/", 
    wsml _"http://www.wsmo.org/wsml-syntax#", 
    loc _"http://www.wsmo.org/ontologies/location#", 
    oo _"http://example.org/ooMediator#"}
    
    namespace _"http://www.example.org/ontologies/example#"
  • WSML header - consists of items that any WSML specification may have: annotations, import ontologies and use mediators

• Annotations
  
  annotations
  dc#title hasValue "WSML example ontology"dc#subject hasValue "family" 
  dc#description hasValue "fragment of a family ontology to provide WSML examples"
  dc#contributor hasValue { _"http://homepage.uibk.ac.at/~c703240/foaf.rdf", 
  _"http://homepage.uibk.ac.at/~csaa5569/", 
  _"http://homepage.uibk.ac.at/~c703239/foaf.rdf", 
  _"http://homepage.uibk.ac.at/homepage/~c703319/foaf.rdf" }
  dc#date hasValue xsd#date("2004-11-22")
  dc#format hasValue "text/html"
  dc#language hasValue "en-US"
  dc#rights hasValue _"http://www.deri.org/privacy.html"
  wsml#version hasValue "$Revision: 1.238 $" 
  endAnnotations
  
• Importing Ontologies
  importsOntology {_"http://www.wsmo.org/ontologies/location", _"http://xmlns.com/foaf/0.1"}
• Using Mediators
  usesMediator _"http://example.org/ooMediator"

• WSML allows inheritance of attribute definitions, which means that a concept inherits all attribute definitions of its superconcepts
  
  concept Human subConceptOf {Primate, LegalAgent}

  annotations
  dc#description hasValue "concept of a human being" 
  dc#relation hasValue humanDefinition 
  endAnnotations
  hasName ofType foaf#name 
  hasRelative impliesType Human 
  hasAncestor impliesType Human 
  hasParent impliesType Human 
  hasChild impliesType Human 
  hasWeightInKG ofType xsd#float 
  hasBirthdate ofType xsd#date 
  dateOfDeath ofType xsd#date 
  hasBirthplace ofType loc#location 
  isMarriedTo impliesType Human 
  hasCitizenship ofType oo#country

• Axioms can be used to define concepts, e.g.  
  
  axiom humanDefinition 
  definedBy
  ?x memberOf Human equivalent ?x memberOf Primate and ?x memberOf LegalAgent. 

• WSML allows two kinds of attribute definitions
  • Constraining definitions: An attribute definition of the form A ofType D, where A is an attribute identifier and D is a concept identifier, is a constraint on the values for attribute A; If the value for the attribute A is not known to be of type D, the constraint is violated and the attribute value is inconsistent with respect to the ontology
  • Inferring definitions: An attribute definition of the form A impliesType D, where A is an attribute identifier and D is a concept identifier, implies membership of the concept D for all values of the attribute A
• Attributes which do not have a datatype range can be specified as being reflexive, transitive, symmetric, or being the inverse of another attribute 
• WSML allows the specification of cardinality and range constraints (defined like integrity constraints in databases)

concept Human 

annotations

            dc#description hasValue "concept of a human being" 

endAnnotations

hasName ofType foaf#name 

hasRelative symmetric impliesType Human

hasAncestor transitive impliesType Human

hasParent inverseOf(hasChild) subAttributeOf(hasAncestor) impliesType Human 

hasMother ofType FemaleHuman

hasMother impliesType Mother

hasChild subAttributeOf(hasRelative) impliesType Human

hasWeightInKG ofType (1) xsd#float

hasBirthdate ofType (1) xsd#date

dateOfDeath ofType (0 1) xsd#date

hasBirthplace ofType (1) loc#location

isMarriedTo symmetric impliesType (0 1) Human

hasCitizenship ofType oo#country 

• The memberOf keyword identifies the concept to which the instance belongs, e.g. 
  
  instance Mary memberOf {Parent, Woman} 
  annotations
  dc#description hasValue "Mary is parent of the twins Paul and Susan" 
  endAnnotations
  hasName hasValue "Maria Smith" 
  hasBirthdate hasValue xsd#date(1949,9,12) 
  hasChild hasValue {Paul, Susan}
  
• WSML allows instances which are not members of a particular concept, e.g. 
  
  instance Mary 
  hasName hasValue "Maria Smith"

• Relations in WSML can be used in order to model interdependencies between several concepts (respectively instances of these concepts)
• The parameters of a relation are strictly ordered and their domain can be optionally specified using the keyword impliesType or ofType
• Examples of relations and relation instances:
  
  relation distanceInKm (ofType City, ofType City, impliesType _decimal) subRelationOf measurement 
  relation distanceInKm/3 
  
  relationInstance distance(Innsbruck, Munich, 234)

• The usage of axioms in WSML allows for example to refine the definition already given in the conceptual syntax, e.g.
  
  axiom humanDefinition 
     definedBy
              ?x memberOf Human equivalent ?x memberOf Animal and ?x memberOf LegalAgent.
  
• WSML allows the specification of database-style constraints, e.g. 
  
  axiom humanBMIConstraint 
    definedBy!-
              naf bodyMassIndex[bmi hasValue ?b, length hasValue ?l, weight hasValue ?w] 
             and ?x memberOf Human and
             ?x[length hasValue ?l, 
             weight hasValue ?w, 
             bmi hasValue ?b].

• The desired and provided functionality of services are described in WSML in the form of capabilities
  • The desired capability is part of a goal and the provided capability is part of a Web service 
• Core elements of capabilities:
  • Shared variables: the variables which are shared between the preconditions, postconditions, assumptions and effects 
  • Preconditions: conditions on the inputs of the service
  • Postconditions: the relation between the input and the output of the service
  • Assumptions: what must hold (but cannot be checked beforehand) of the state of the world for the Web service to be able to execute successfully
  • Effects: the real-world effects of the execution of the Web service which are not reflected in the output
• A WSML goal or Web service may only have one capability

• An interface describes how the functionality of the Web service can be achieved by providing a twofold view on the operational competence of the Web service: Choreography decomposes a capability in terms of interaction with the Web service; and Orchestration decomposes a capability in terms of functionality required from other Web services
• Basic mechanism for representing choreographies:
  • A signature defines predicates and functions to be used in the description. Ground facts specify the underlying database states. 
    • Signatures are defined using ontologies
    • The ground facts that populate database states are instances of concepts and relations defined by the ontologies
    • State changes are described in terms of creation of new instances or changes to attribute values of objects.
  • State changes are described using transition rules, which specify how the states change by falsifying (deleting) some previously true facts and inserting (making true) some other facts
    
    if Condition then Rules
    forall Variables with Condition do Rules
    choose Variables with Condition do Rules

• Properties which strictly belong to a Web service, goal, capability, interface or mediator and which are not functional and behavioral
• A WSML Web service, goal, capability, interface or mediator may specify multiple non-functional properties
• Example:
  
  nonFunctionalProperty
  po#Price hasValue ?price 
  annotations
  dc#description hasValue ”If the client is older than 60 or younger than 
  10 years old the invocation price is lower than 10 euro” 
  endAnnotations
  
  definedBy
  ?client[age hasValue ?age] memberOf hu#human and ?age[amount hasValue ?years, units hasValue hu#YearsDuration] 
  memberOf hu#age and (greaterEqual(?years, 60) or lessEqual(?years,10)) 
  implies ?price[hasAmount hasValue ?amount, hasCurrency hasValue cur#Euro] memberOf
  po#AbsoulePrice and lessEqual(?amount, 10).

• A WSML goal specification is identified by the goal keyword optionally followed by an IRI which serves as the identifier of the goal, e.g.
  goal _"http://example.org/Germany/GetCitizenShip" 
  A WSML Web service specification is identified by the webService keyword optionally followed by an IRI which serves as the identifier of the Web service, e.g.
  webService _"http://example.org/Germany/BirthRegistration" 
  WSML allows for the specification of four kinds of mediators, namely ontology mediators, mediators between Web services, mediators between goals and mediators between Web services and goals, e.g.
  ooMediator _"http://example.org/ooMediator"

• Logical expressions occur within axioms and the capabilities which are specified in the descriptions of goals and Semantic Web services
• We give a syntax specification for general logical expressions in WSML; the general logical expression syntax encompasses all WSML variants and is thus equivalent to the WSML-Full logical expression syntax
  • Vocabulary
  • Terms
  • Set of Fromulae
• We specify for each of the WSML variants the restrictions the variant imposes on the logical expression syntax

• WSML allows 
  • logical connectives: and, or, implies, impliedBy, equivalent, neg, naf, forall and exists and the following auxiliary symbols: '(', ')', '[', ']', ',', '=', '!=', memberOf, hasValue, subConceptOf, ofType, and impliesType
  • use of the symbol ':-' for Logic Programming rules and the use of the symbol '!-' for database-style constraints
  • use of true and false as predicates with the standard pre-defined meaning

• No human can be both male and female:
• !- ?x[gender hasValue {?y, ?z}] memberOf Human and ?y = Male and ?z = Female. 
• A human who is not a man is a woman:
• ?x[gender hasValue Woman] impliedBy neg ?x[gender hasValue Man]. 
• The brother of a parent is an uncle:
• ?x[uncle hasValue ?z] impliedBy ?x[parent hasValue ?y] and ?y[brother hasValue ?z]. 
• Do not trust strangers:
• ?x[distrust hasValue ?y] :- naf ?x[knows hasValue ?y].

• WSML-Core is based on the Logic Programming subset of Description Logics 
• WSML-Core allows only a restricted form of logical expressions; there are two sources for these restrictions
  • The restriction of the language to a subset of Description Logics restricts the kind of formulas which can be written down to the two-variable fragment of first-order logic . Furthermore, it disallows the use of function symbols and restricts the arity of predicates to unary and binary and chaining variables over predicates
  • The restriction of the language to a subset of Datalog (without equality) disallows the use of the equality symbol , disjunction in the head of a rule and existentially quantified variables in the head of the rule

• WSML-Core does not allow for the specification of the attribute features reflexive, transitive, symmetric, inverseOf and subAttributeOf
• Cardinality constraints are not allowed and thus it is not possible to specify functional properties
• Allowed attribute values are restricted to strings, numbers, ids, or a lists of such values; constructed data values are not allowed
• Does not allow for the specification of relations
• Does not allow the specification of relation instances 
• For axioms, WSML-Core only allows the use of a restricted form of the WSML logical expression syntax 
• Goals and Web services: the logical expressions in the 'assumptions', 'preconditions', 'effects' and 'postconditions' of a capability and 'definition' of a non-functional property are limited to WSML-Core logical expressions

• The attribute 'hasAncestor' is transitive:
• ?x[hasAncestor hasValue ?z] impliedBy
• ?x[hasAncestor hasValue ?y] and ?y[hasAncestor hasValue ?z]
• A female person is a woman:
• ?x memberOf Woman impliedBy ?x memberOf Person and ?x memberOf Female
• A student is a person:
• Student subConceptOf Person

• WSML-DL is an extension of WSML-Core to a full-fledged description logic with an expressiveness similar to OWL DL
• WSML-DL is both syntactically and semantically completely layered on top of WSML-Core 
  • Every valid WSML-Core specification is also a valid WSML-DL specification
  • All consequences inferred from a WSML-Core specification are also valid consequences of the same specification in WSML-DL
• The difference between WSML-Core and WSML-DL lies in the logical expression syntax
  • The logical expression syntax of WSML-DL is less restrictive than the logical expression syntax of WSML-Core
• Restrictions: it disallows the use of function symbols, restricts the arity of predicates to unary and binary and prohibits chaining variables over predicates

• The concept Human is defined as the disjunction between Man and Woman:
• ?x memberOf Human equivalent ?x memberOf Woman or ?x memberOf Man
• The concepts Man and Woman are disjoint:
• ?x memberOf Man implies neg ?x memberOf Woman
• Every Human has a father, which is a Human and every father is a human:
• ?x memberOf Human implies exists ?y ( ?x[father hasValue ?y] and ?y memberOf Human ) and forall ?y ( ?x[father hasValue ?y] implies ?y memberOf Human )

• WSML-Flight is both syntactically and semantically completely layered on top of WSML-Core
• WSML-Flight adds the following features to WSML-Core:
  • N-ary relations with arbitrary parameters 
  • Constraining attribute definitions for the abstract domain 
  • Cardinality constraints 
  • (Locally Stratified) default negation in logical expressions (in the body of the rule) 
  • Expressive logical expressions, namely, the full Datalog subset of F-Logic, extended with inequality (in the body) and locally stratified negation 
  • Meta-modeling. WSML-Flight no longer requires a separation of vocabulary (wrt. concepts, instances, relations)

• No human can be both male and female:
• !- ?x[gender hasValue {?y, ?z}] memberOf Human and ?y = Male and ?z = Female
• The brother of a parent is an uncle:
• ?x[uncle hasValue ?z] impliedBy ?x[parent hasValue ?y] and ?y[brother hasValue ?z]
• Do not trust strangers:
• ?x[distrust hasValue ?y] :- naf ?x[knows hasValue ?y] and ?x memberOf Human and ?y memberOf Human

• WSML-Rule is an extension of WSML-Flight in the direction of Logic Programming
• WSML-Rule no longer requires safety of rules and allows the use of function symbols
  • The only differences between WSML-Rule and WSML-Flight are in the logical expression syntax
• WSML-Rule is both syntactically and semantically layered on top of WSML-Flight 
  • Each valid WSML-Flight specification is a valid WSML-Rule specification

• Both the father and the mother are parents:
• ?x[parent hasValue ?y] :- ?x[father hasValue ?y] or ?x[mother hasValue ?y] 
• Every person has a father:
• ?x[father hasValue f(?x)] :- ?x memberOf Person 
• There may only be one distance between two locations, and the distance between locations A and B is the same as the distance between B and A:
• !- distance(?location1,?location2,?distance1) and distance(?location1,?location2,?distance2) and ?distance1 != distance2
• distance(?B,?A,?distance) :- distance(?A,?B,?distance)

• WSML-Full unifies the Description Logic and Logic Programming variants of WSML, namely, WSML-DL and WSML-Rule, in a principled way, under a common syntactic umbrella, inspired by First-Order Logic
• Differences between WSML-DL and WSML-Full: 
  • WSML-Full adds full first-order modeling: n-ary predicates, function symbols and chaining variables over predicates
  • WSML-Full allows non-monotonic negation
• Differences between WSML-Rule and WSML-Full: 
  • WSML-Full adds disjunction, classical negation, multiple model semantics, and the equality operator

• WSML2Reasoner is a highly modular framework that combines various validation, normalization and transformation algorithms that enable the translation of ontology descriptions in WSML to the appropriate syntax of several underlying reasoning engines
• WSML2Reasoner has been implemented and tested using various reasoning engines that support all WSML variants with the exception of WSML-Full
• The WSML2Reasoner framework has a flexible architecture that allows the easy integration of existing reasoning components
  • It first maps WSML to either generic Datalog or OWL (Web Ontology Language), and then uses a plug-in layer that translates to the specific internal representation of a single reasoning engine

• Integrated Rule Inference System (IRIS) - http://iris-reasoner.org/ 
  • Supports WSML-Core, WSML-Flight, WSML-Rule
  • Is an extensible reasoning engine for expressive rule-based languages; supports Datalog extended with stratified and well-founded negation, function symbols, unsafe-rules, XML schema data-types and an extensible set built-in predicates

• KAON2
  • Supports WSML-Core, WSML-Flight, WSML-DL
  • Is an infrastructure for managing OWL-DL, SWRL, and F-Logic ontologies
  • Reasoning in KAON2 is implemented by novel algorithms which reduce a SHIQ(D) knowledge base to a disjunctive datalog program
• MINS (Mins Is Not Silri)
  • Supports WSML-Core, WSML-Flight, WSML-Rule
  • Is a reasoner for Datalog programs with negation and function symbols which supports well-founded semantics 
• PELLET 
  • Supports WSML-Core, WSML-DL
  • Is an OWL DL reasoner written in Java
  • Is based on the tableaux algorithms for expressive Description Logics (DL) and supports the full expressivity of OWL DL, including reasoning about nominals (enumerated classes)

• Query 1: To find all the students and the principle of the school they attend:
  ?child[attends hasValue ?school] and ?principle[principleOf hasValue ?school]
• Query 2: To find all the people that work at springfield_elementary:
  ?employee[hasWorkingPlace hasValue springfield_elementary]
• Query 3: To find out who is the reverant of the church that each character attends:
  ?worshiper[worshipsAt hasValue ?church] and ?reverant[reverantOf hasValue ?church]
• Query 4: To find all the characters that Dan Castellanata does the voices for on the simpsons:
  ?character[hasActor hasValue dan_castellanata]
• Query 5: To find out who is in love with who in the simpsons world:
  ?character1[inLoveWith hasValue ?charachter2]
• Query 6: To find all actors who play characters of the opposite sex:
  ?actor[hasGender hasValue ?actorgender] memberOf actor and ?character[hasGender hasValue ?charactergender] memberOf character and ?character[hasActor hasValue ?actor] and ?actorgender != ?charactergender
• Demo: Use the IRIS Reasoner in WSMT for answers to these queries!

• 1 new variant and 4 updated versions of WSML developed in SOA4All project:
  • WSML-Quark
  • WSML-Core 2.0
  • WSML-DL 2.0
  • WSML-Flight 2.0
  • WSML-Rule 2.0

• Basic Idea: Update WSML to align it with new research
• WSML-Core 2.0:
  • Still based on DLP ~ Semantically stronger version
  • Extended with individivual equivalence
  • Requires slightly more powerful rules engine
• WSML-DL 2.0:
  • Based on ELP (decidable fragment of the Semantic Web Rule Language (SWRL))
  • Contains OWL 2 RL, EL
  • Allows restricted form of rules to be included
• WSML-Flight/Rule 2.0:
  • Updated for layering
  • Ensure compatibility with RIF (Rule Interchange Format)
  • Technically contains same expressivity as OWL 2 QL

• New language variant
• Specifically for very light-weight knowledge representation
  • classification systems, ultra-light-weight
  • hierarchical schema (sub-concept)
• Reasoning is reduced to graph reachability
  • is-subconcept-of(C1,C2)
  • get-sub-concepts(C)
  • get-super-concepts(C)
• Hybrid algorithms
  • trade off between query time, indexing time and index size
  • tune for specific knowledge bases

• Provides a formal syntax and semantics for representing WSMO Ontologies, Web services, Goals, and Mediators
• Defines several language variants (WSML-Core, WSML-DL, WSML-Flight, WSML-Rule, WSML-Full) and thus allows users to make a trade-off between the provided expressivity and the implied complexity
• Designed based on the principles of the Semantic Web
• Brings together different logical language paradigms and unifies them in one syntactical framework, enabling the reuse of proven reasoning techniques and tools
• WSML2Reasoner is a reasoning framework for WSML
• WSML is evolving

• http://www.wsmo.org/TR/d16/d16.1/v1.0/
• J. de Bruijn, D. Fensel, U. Keller, M. Kerrigan, H. Lausen, and J. Scicluna. Modeling Semantic Web Services - The Web Service Modeling Language. Springer, 2008
• J. de Bruijn, H. Lausen, A. Polleres, D. Fensel: The Web Service Modeling Language WSML: An Overview. ESWC 2006: 590-604
• J. de Bruijn, S. Heymans: A Semantic Framework for Language Layering in WSML. RR 2007: 103-117
• D. Roman, J. de Bruijn, A. Mocan, H. Lausen, J. Domingue, C. Bussler, D. Fensel: WWW: WSMO, WSML, and WSMX in a Nutshell. ASWC 2006: 516-522
• http://www.wsmo.org/wsml
• http://www.wsmo.org/TR/d16/
• http://www.wsmo.org/TR/d16/d16.3/v1.0/
• http://www.wsmo.org/TR/d32/v1.0/
• http://www.wsmo.org/TR/d36/v1.0/
• http://www.wsmo.org/TR/d37/v0.2/
• http://tools.sti-innsbruck.at/wsml2reasoner/
• http://sourceforge.net/projects/wsml2reasoner/
• http://wsmt.sourceforge.net
• http://en.wikipedia.org/wiki/WSMO