Tutorial on Knowledge Markup and Resource Semantics

1
Tutorial onKnowledge Markup andResource
Semantics

• Harold BoleyStefan DeckerMichael Sintek

IJCAI-01 Seattle6 August 2001 (version 20
August 2001)
2
Overview and Tutorial Mindmap

• Increasing demand for formalized knowledge on
  the Web AIs chance!
• XML- RDF-based markup languages provide a
  'universal' storage/interchange format for such
  Web-distributed knowledge representation
• Tutorial introduces knowledge markup resource
  semantics we show how to marry AI
  representations (e.g., logics and frames) with
  XML RDF incl. RDF Schema

Namespaces
CSS
DTDs
XSLT
Stylesheets
DAML
Agents
Transformations
Ontobroker
XQL
XML
HornML
Rules
Queries
RuleML
XQuery
Mindmap
XML-QL
SHOE
RDFS
Frames
Acquisition
TopicMaps
Protégé
3
Web Languages forKnowledge Capturing

• Human knowledge is (partially) captured on the
  Web as informal texts, semiformal documents, and
  structured metadata
• Each kind of knowledge has its (preferred) markup
  language

Knowledge Markup
4
Web Languages forMachine Interpretation

• XML (Extensible Markup Language) Semiformal
  documents range between non-formatted texts and
  fully formatted databases
• RDF (Resource Description Framework) Structured
  metadata describe arbitrary heterogeneous Web
  pages/objects in a homogeneous manner

Knowledge Markup
Machines (e.g. search engines) can analyze XML or
RDF markups better than full HTML
5
The Semantic Web Activityof the W3C

• The Semantic Web is a vision the idea of having
• data on the Web defined and linked in a way that
• it can be used by machines not just for display
  purposes,
• but for
• automation,
• integration and
• reuse of data across various applications.
• (http//www.w3.org/2001/sw/Activity)

Semantic Web
6
The Semantic Web Layered Architecture
Tim Berners-Lee Axioms, Architecture and
Aspirations W3C all-working group plenary
Meeting 28 February 2001
Semantic Web
(http//www.w3.org/2001/Talks/0228-tbl/slide5-0.ht
ml)
7
The Semantic Web Layered Architecture Where are
the Semantic Web Semantics?
Tim Berners-Lee Axioms, Architecture and
Aspirations W3C all-working group plenary
Meeting 28 February 2001
Semantic Web
(http//www.w3.org/2001/Talks/0228-tbl/slide5-0.ht
ml)
This tutorial discusses knowledge markup for the
Semantic Web, together with the required resource
semantics
8
Partial Orders
Practical need for Web semantics
Corresponding semantic techniques
Hierarchical structure (i.e., the taxonomy part
of an ontology) for arbitrary domains of
discourse
Partial orders over sets of arbitrary objects
(classes, relations, ...) permit inheritance down
the gt-links of tree-generalizing DAGs (Directed
Acyclic Graphs)
Partial Orders
9
Financial Math Excerpt from Mathematics
International Ontology as RDF Schema
Prolog-like Syntax subsumes(fm,management_mathema
tics_fm). subsumes(fm,math_fm).
XML Syntax RFML
DAG (Relfuns sortbase browser)
Application
RDF Schema ltrdfClass rdfID"management_mathemat
ics_fm"gt ltrdfssubClassOf rdfresource"fm"/gt
lt/rdfClassgt ltrdfClass rdfID"math_fm"gt
ltrdfssubClassOf rdfresource"fm"/gt lt/rdfClassgt

XSLT Stylesheet
rfml2rdfs.xsl
DAG (FRODO RDFSViz rendering) taxonomy.gif
10
Metadata (Resource) Semantics
Practical need for Web semantics
Corresponding semantic techniques
Annotating arbitrary Web objects in RDF/XML for
semantic retrieval
Metadata semantics in XML-based RDF and RDF
Schema enables high-precision search engines for
Berners-Lees "Semantic Web"
Metadata
11
Knowledge Markup Resource Semantics XML
Documents with RDF Annotations
http//addr.flat.com
http//addr.nest.com
ltaddressesgt ltrdfRDF xmlnshttp//www.w3.org/gt
ltrdfDescription aboutgt
ltShapegtflatlt/Shapegt ltConvertsTo
resourcehttp//addr.nest.com/gt
lt/rdfDescriptiongt lt/rdfRDFgt ltaddressgt
ltnamegtMe2XMLlt/namegt ltstreetgt96 Hyper
Roadlt/streetgt lttowngtBostonlt/towngt
lt/addressgt ltaddressgt ltnamegtRDF4Alllt/name
gt ltstreetgt2001 Broadwaylt/streetgt
lttowngtNew Yorklt/towngt lt/addressgt . .
. lt/addressesgt
ltaddressesgt ltrdfRDF xmlnshttp//www.w3.org/gt
ltrdfDescription aboutgt
ltShapegtnestedlt/Shapegt ltConvertsTo
resourcehttp//addr.flat.com/gt
lt/rdfDescriptiongt lt/rdfRDFgt ltaddressgt
ltnamegtMe2XMLlt/namegt ltplacegt ltstreetgt96
Hyper Roadlt/streetgt lttowngtBostonlt/towngt
lt/placegt lt/addressgt . . . lt/addressesgt
KM RS
12
Extensible Markup Language
XML
XML
13
General Advantages of XML for KR
XML offers new general possibilities, from
which AI knowledge representation (KR) can profit
(1) Definition of self-describing data in
worldwide standardized, non-proprietary
format (2) Structured data and knowledge
exchange for enterprises in various
industries (3) Integration of information from
different sources (into uniform documents)
XML
14
Specific Advantages of XML for KR
XML provides the most suitable infrastructure for
knowledge bases on the Web (incl. for W3C
languages such as RDF) Additional special KR
uses of XML are

• Uniform storage of knowledge bases
• Interchange of knowledge bases between different
  AI languages
• Exchange between knowledge bases and databases,
  application systems, etc.

XML
Even transformation/compilation of AI source
programs using XML markup and annotations is
possible
15
Address Example External to HTML
External Presentation
Xaver M. Linde Wikingerufer 7 10555 Berlin
HTML tags are still presentation-oriented
XML
HTML Markup
ltemgtXaver M. Lindelt/emgt ltbrgt Wikingerufer
7 ltbrgt ltstronggt10555 Berlinlt/stronggt
16
Address Example HTML to XML
HTML Markup
While not conveying any formal semantics
ltemgtXaver M. Lindelt/emgt ltbrgt Wikingerufer
7 ltbrgt ltstronggt10555 Berlinlt/stronggt
XML tags are chosen for content-structuring needs
XML
XML Markup
ltaddressgt ltnamegtXaver M. Lindelt/namegt
ltstreetgtWikingerufer 7lt/streetgt lttowngt10555
Berlinlt/towngt lt/addressgt
17
Address Example XML to External
XML Markup
ltaddressgt ltnamegtXaver M. Lindelt/namegt
ltstreetgtWikingerufer 7lt/streetgt lttowngt10555
Berlinlt/towngt lt/addressgt
XML
XML stylesheets are, e.g., usable to
generate different presentations
External Presentations
Xaver M. Linde Wikingerufer 7 10555 Berlin
Xaver M. Linde Wikingerufer 7 10555 Berlin
. . .
18
Address Example XML to XML
XML Markup 1
ltaddressgt ltnamegtXaver M. Lindelt/namegt
ltstreetgtWikingerufer 7lt/streetgt lttowngt10555
Berlinlt/towngt lt/addressgt
XML stylesheets are also usable to transform XML
representations
XML
XML Markup 2
ltaddressgt ltnamegtXaver M. Lindelt/namegt
ltplacegt ltstreetgtWikingerufer 7lt/streetgt
lttowngt10555 Berlinlt/towngt
lt/placegt lt/addressgt
19
Address Example Some Stylesheets Will Contain
Term-(Tree-)Rewriting Rules
address
name
street
town
T
S
N
XML
address
name
place
street
town
N
T
S
20
Address Example XML Queries
XML Markup
subelements
element
ltaddressgt ltnamegtXaver M. Lindelt/namegt
ltstreetgtWikingerufer 7lt/streetgt lttowngt10555
Berlinlt/towngt lt/addressgt
s
XML Query (XML-QL)
WHERE ltaddressgt ltnamegtXaver M.
Lindelt/namegt ltstreetgtslt/streetgt
lttowngttlt/towngt lt/addressgt CONSTRUCT
ltbindinggt ltsgtslt/sgt lttgttlt/tgt
lt/bindinggt
XML
XML queries can select subelements of XML elements
ltbindinggt ltsgtWikingerufer 7lt/sgt
lttgt10555 Berlinlt/tgt lt/bindinggt
21
Address Example Prolog Queries
Prolog Term
substructures
address( name("Xaver M. Linde"),
street("Wikingerufer 7"), town("10555
Berlin") )
s
structure
XML
Prolog Query
Prolog queries can select substructures of Prolog
structures
address( name("Xaver M. Linde"),
street(S), town(T) )
S "Wikingerufer 7" T "10555 Berlin"
22
Address Example The Element Tree
XML
23
Address ExampleDocument Type Definition and
Tree (1)
Document Type Definition (DTD)
Extended Backus-Naur Form (EBNF)
lt!ELEMENT address (name, street, town)
gt lt!ELEMENT name (PCDATA) gt lt!ELEMENT
street (PCDATA) gt lt!ELEMENT town (PCDATA) gt
address name street town name
PCDATA street PCDATA town PCDATA
XML
24
Address ExampleDocument Type Definition and
Tree (2)
Document Type Definition (DTD)
lt!ELEMENT address (name, place) gt lt!ELEMENT place
(street, town) gt lt!ELEMENT name (PCDATA)
gt lt!ELEMENT street (PCDATA) gt lt!ELEMENT
town (PCDATA) gt
Document Type Tree
XML
address
name
place
street
town
PCDATA
PCDATA
PCDATA
25
Well-Formedness and Validity
XML principles for a document being
well-formed
XML principle for a document
being valid with respect to (w.r.t.) a DTD

• Open and close all tags
• Empty tags end with /gt
• There is a unique root element
• Elements may not overlap
• Attribute values are quoted
• lt and are only used to start tags and entities
• Only the five predefined entity references are
  used

• Match the constraints listed in the DTD (or,
  generate from DTD as linearized derivation tree,
  as shown later)

XML
Checked by validators such as http//www.stg.brown
.edu/service/xmlvalid/
26
Mail-Box Example Address Variant
XML
Node-Labeled, (Left-to-Right-)Ordered Element
Tree
27
""-Disjoined Street/Mail-Box ExampleDocument
Type Definition and Tree
Document Type Definition (DTD)
lt!ELEMENT address (name, (street box), town)
gt lt!ELEMENT name (PCDATA) gt lt!ELEMENT
street (PCDATA) gt lt!ELEMENT box (PCDATA)
gt lt!ELEMENT town (PCDATA) gt
"" Choice The above box address and the
original street address are valid w.r.t. this
""-DTD
XML
Document Type Tree
address
name
street
town
box
PCDATA
PCDATA
PCDATA
PCDATA
28
Phone Fax Example Address Variant
Prolog Term
address( name("Xaver M. Linde"),
street("Wikingerufer 7"), town("10555
Berlin"), phone("030/1234567"),
phone("030/1234568"), fax("030/1234569") )
XML
Node-Labeled, (Left-to-Right-)Ordered Element
Tree
address
town
name
fax
phone
phone
street
Xaver M. Linde
Wikingerufer 7
10555 Berlin
030/1234567
030/1234569
030/1234568
29
""/""-Repetitive-Phone -Fax ExampleDocument
Type Definition and Tree
Document Type Definition (DTD)
lt!ELEMENT address (name, street, town, phone,
fax) gt lt!ELEMENT name (PCDATA) gt lt!ELEMENT
street (PCDATA) gt lt!ELEMENT town (PCDATA)
gt lt!ELEMENT phone (PCDATA) gt lt!ELEMENT
fax (PCDATA) gt
""/"" One/Zero or More The above
two-phone/one-fax address is valid w.r.t. this
""/""-DTD but the original no-phone/no-fax
address is not (?1 phone!)
XML
Document Type Tree
address
name
street
phone
fax
town
PCDATA
PCDATA
PCDATA
PCDATA
PCDATA
30
Country Example Address Variant
Prolog Term
address( name("Xaver M. Linde"),
street("Wikingerufer 7"), town("10555
Berlin"), country("Germany") )
XML
Node-Labeled, (Left-to-Right-)Ordered Element
Tree
address
name
street
town
country
Xaver M. Linde
Wikingerufer 7
10555 Berlin
Germany
31
"?"-Optional-Country ExampleDocument Type
Definition and Tree
Document Type Definition (DTD)
lt!ELEMENT address (name, street, town, country?)
gt lt!ELEMENT name (PCDATA) gt lt!ELEMENT
street (PCDATA) gt lt!ELEMENT town (PCDATA)
gt lt!ELEMENT country (PCDATA) gt
"?" One or Zero The above country address and
the original countriless address are valid
w.r.t. this "?"-DTD
XML
Document Type Tree
address
country
name
street
town
PCDATA
PCDATA
PCDATA
PCDATA
32
Country Address A Complete XML Document
Referring to an External DTD
XML Document (just ASCII, e.g. stored in a file)
lt?xml version"1.0" standalone"no"?gt lt!DOCTYPE
address SYSTEM "country-address.dtd"gt ltaddressgt
ltnamegtXaver M. Lindelt/namegt
ltstreetgtWikingerufer 7lt/streetgt lttowngt10555
Berlinlt/towngt ltcountrygtGermanylt/countrygt lt/addr
essgt
XML
The XML declaration uses standalone attribute
with "no" value DTD import The DOCument TYPE
declaration names the root element address and,
after the SYSTEM keyword, refers to an external
DTD "country-address.dtd" (or, at some
absolute URL, to an "http//www.test.org/country-a
ddress.dtd")
33
Horn Logic Markup Languages
HornML
HornML
34
Herbrand Terms Individual Constants,Variables,
Flat Ground Structures, ...
Representation of Herbrand terms in XML as ltindgt
and ltstrucgt elements (ltvargt similar)

• Individual constant for channel-tunnel between
  Britain and France element ltindgtchannel-tunnel
  lt/indgt
• Ground structure undersea-connection(britain,fra
  nce)is ltstrucgt element with embedded element
  for constructor, followed by elements for
  argument terms

HornML
ltstrucgt ltconstructorgtundersea-connectionlt/const
ructorgt ltindgtbritainlt/indgt
ltindgtfrancelt/indgt lt/strucgt
35
Herbrand Terms ...,Nested Ground Structures
ltstrucgt ltconstructorgtservice-tunnellt/constructo
rgt ltstrucgt ltconstructorgtundersea-connectio
nlt/constructorgt ltindgtbritainlt/indgt
ltstrucgt ltconstructorgtsurrounded-countrylt/co
nstructorgt ltindgtbelgiumlt/indgt
ltindgtluxembourglt/indgt ltindgtgermanylt/indgt
ltindgtswitzerlandlt/indgt
ltindgtitalylt/indgt ltindgtspainlt/indgt
lt/strucgt lt/strucgt lt/strucgt
Embedded ltstrucgt elements
service-tunnel( undersea-connection(
britain, surrounded-country(
belgium, luxembourg, germany,
switzerland, italy, spain)))
HornML
36
Interim Discussion Tag and Type

• In Prolog not clear, in isolation, that
  channel-tunnel is individual constant, whereas
  service-tunnel is constructor
• In XML, as in strongly typed LP languages, made
  explicit - however at every occurrence of a
  symbol
• Example gives impression of self-description
  advantage - but also space requirement - of
  this generous application of syntactic sugar

HornML
37
Horn Clauses Relation Symbol Applications
Predicate or relation symbol in XML is ltrelatorgt
element. For example, relation symbol travel
is ltrelatorgttravellt/relatorgt Relation symbol
application to terms is labeled
with ltrelationshipgt element. Application
travel(john,channel-tunnel) on two individual
constants thus is ltrelationshipgt
ltrelatorgttravellt/relatorgt ltindgtjohnlt/indgt
ltindgtchannel-tunnellt/indgt lt/relationshipgt
HornML
38
Horn Clauses Facts
Hence, Horn fact can be asserted as lthngt element
that possesses ltrelationshipgt elements as
subelements In the example, the Prolog
fact travel(john,channel-tunnel). becomes lthngt
ltrelationshipgt ltrelatorgttravellt/relatorgt
ltindgtjohnlt/indgt ltindgtchannel-tunnellt/i
ndgt lt/relationshipgt lt/hngt
HornML
39
Horn Clauses Rules
Then, Horn rule is asserted as lthngt Element that
has a head ltrelationshipgt element followed by at
least one body ltrelationshipgt element So, above
example generalized to Prolog rule travel(Someone
,channel-tunnel) - carry(eurostar,Someone). lthngt
ltrelationshipgt ltrelatorgttravellt/relatorgt
ltvargtsomeonelt/vargt ltindgtchannel-tunnellt/
indgt lt/relationshipgt ltrelationshipgt
ltrelatorgtcarrylt/relatorgt ltindgteurostarlt/indgt
ltvargtsomeonelt/vargt lt/relationshipgt lt/hngt
and rewritten as
HornML
40
Attributes for Extended Logics
Nested elements - trees - allow representation
of arbitrary information, but in some situations
lead to unnecessarily deeply/widely nested
representations Therefore XML attributes Start-T
ag is attributed with n attribute-value pairs
aivi Element lttag a1v1 ... anvngt . . . lt/taggt
Helpful Prolog uses of XML attributes are arity
labelings of relation symbols such as our binary
relation symbol travel Prologs travel/2 in XML
with an arity attribute becomes ltrelator
arity"2"gttravellt/relatorgt Analogously,
annotations become possible on arbitrary element
levels mode declarations for logic
variables, determinism specifications for clauses
or procedures, and context conditions for entire
knowledge bases
HornML
41
ID and IDREF
Attribute types ID and IDREF for naming
and referencing of elements ID-typed value must
uniquely identify an element and IDREF-typed
value must occur as ID value of an element E.g.,
clause can be named (in a hypothesis knowledge
base) lthn id"john-channel"gt ltrelationshipgt
ltrelatorgttravellt/relatorgt
ltindgtjohnlt/indgt ltindgtchannel-tunnellt/indgt
lt/relationshipgt lt/hngt
HornML
42
ID and IDREF
Now a modal Prolog fact belief(mary,travel(john
,channel-tunnel)). can access the "john-channel"
assertion lthngt ltrelationshipgt
ltrelatorgtbelieflt/relatorgt ltindgtmarylt/indgt
ltprop idref"john-channel"/gt
lt/relationshipgt lt/hngt Propositional argument of
the belief operator written as ltprop
idref"john-channel"/gt (XML abbreviation of empty
elements lttag ...gt lt/taggt to lttag .../gt) Also
disbelief fact has "john-channel" access with
idref ID/IDREF break out of the tree and
enable sharing
HornML
43
DTDs Elements as Derivation Trees
Up to now Examples for Horn Logic in XML
etc. Now General language definition XML's
Document type definitions (DTDs) initially only
as ELEMENT declarations for non-attributed
elements For nonterminals DTD ? ordinary
context-free grammar in modified (EBNF)
notation For terminals Usually arbitrary
permutations of the base alphabet ("PCDATA'')
instead of fixed terminal sequences DTD grammar
derives context-free word patterns derivation
trees themselves - linearized through brackets -
as generated result XML element is valid with
respect to DTD can be generated from DTD as
linearized derivation tree
HornML
44
DTDs Defining Horn Logic in XML
Syntactic ELEMENT declaration of Horn logic as a
knowledge base (kb) of zero or more Horn clauses
(hn) lt!ELEMENT kb (hn) gt lt!ELEMENT
hn (relationship, relationship) gt lt!ELEMENT
relationship (relator, (ind var struc))
gt lt!ELEMENT struc (constructor, (ind var
struc)) gt lt!ELEMENT relator (PCDATA)
gt lt!ELEMENT constructor (PCDATA) gt lt!ELEMENT
ind (PCDATA) gt lt!ELEMENT var (PCDATA) gt
HornML
Note struc recursion!
45
DTDsGeneration of the Example Rule (1)
(Start-)symbol kb brackets derived clause(s) as
linearized start-tag/end-tag-tree representation
ltkbgt . . . lt/kbgt kb ltkbgt hn lt/kbgt . . .
ltkbgt lthngt relationship relationship lt/hngt
lt/kbgt . . . ltkbgt lthngt ltrelationshipgt
ltrelatorgtPCDATAlt/relatorgt ltvargtPCDATAlt/vargt
ltindgtPCDATAlt/indgt lt/relationshipgt
ltrelationshipgt ltrelatorgtPCDATAlt/relatorgt
ltindgtPCDATAlt/indgt ltvargtPCDATAlt/vargt
lt/relationshipgt lt/hngt lt/kbgt
HornML
46
DTDsGeneration of the Example Rule (2)
ltkbgt lthngt ltrelationshipgt
ltrelatorgttravellt/relatorgt
ltvargtsomeonelt/vargt ltindgtchannel-tunnellt/ind
gt lt/relationshipgt ltrelationshipgt
ltrelatorgtcarrylt/relatorgt
ltindgteurostarlt/indgt ltvargtsomeonelt/vargt
lt/relationshipgt lt/hngt lt/kbgt
HornML
47
Attribute DTDs (1)
DTDs for attributed elements ATTLIST
declarations, which associate element name with
an attribute name plus attribute type and
possible occurrence indication 1st Example
declare the relator attribute arity as
CDATA-typed (cf. PCDATA) and occurring
optionally (IMPLIED) lt!ATTLIST relator arity
CDATA IMPLIED gt 2nd Example (Preparation)
define the extended Horn logic with (named hn
clauses and) embedded propositions lt!ELEMENT
relationship (relator, (indvarstrucprop))
gt lt!ELEMENT prop EMPTY gt
HornML
48
Attribute DTDs (2)
2nd Example (Execution) Append an ATTLIST
declaration that specifies, for the hn
respectively prop elements, the attributes id -
as optional ID type - respectively idref - as
mandatory IDREF type lt!ATTLIST
hn id ID IMPLIED gt lt!ATTLIST
prop idref IDREF REQUIRED gt With entire DTD
now, e.g., earlier "john-channel"-named fact and
its accessing facts can be generated
HornML
49
Horn Queries in XML Notation
Assume fact lthngt ltrelationshipgt
ltrelatorgtcarrylt/relatorgt ltindgteurostarlt/indgt
carry(eurostar,fred). ltindgtfredlt/indgt
lt/relationshipgt lt/hngt A Horn-logic interpreter
can use it to answer this query ltrelationshipgt
ltrelatorgtcarrylt/relatorgt ltindgteurostarlt/indgt
carry(eurostar,Someone)
ltvargtsomeonelt/vargt lt/relationshipgt by
binding ltvargtsomeonelt/vargt Someone
to ltindgtfredlt/indgt fred
HornML
50
Horn Queries in XML-QL Implementation
Assume the fact is extended by prem(ises)/arity/po
s(ition) attributes lthn prem'0'gt
ltrelationship arity'2'gt ltrelatorgtcarrylt/rel
atorgt ltind pos'1'gteurostarlt/indgt
ltind pos'2'gtfredlt/indgt lt/relationshipgt lt/hngt
Then in XML-QL the query can be implemented like
this WHERE lthn prem'0'gt ltrelationship
arity'2'gt ltrelatorgtcarrylt/relatorgt
ltind pos'1'gteurostarlt/indgt ltind
pos'2'gtsomeonelt/indgt lt/relationshipgt
lt/hngt CONSTRUCT ltbindinggt ltsomeonegtsomeonelt/so
meonegt lt/bindinggt
HornML
51
Horn Inferences in XML Notation (1)
With carry basis fact carry(euro
star,fred). a rule is usable to dynamically
derive travel assertions as needed, without
having to store them all-inclusively and
statically travel(Someone,channel-tunnel)
- carry(eurostar,Someone). That is, its
earlier XML version is useable by a Horn-logic
interpreter for inferential queries like
travel(fred,Where) ? carry(eurostar,Someone) ?
true
HornML
Someonefred Wherechannel-tunnel
Wherechannel-tunnel
52
Horn Inferences in XML Notation (2)
Rule lthngt ltrelationshipgt
ltrelatorgttravellt/relatorgt ltvargtsomeonelt/vargt
ltindgtchannel-tunnellt/indgt
lt/relationshipgt ltrelationshipgt
ltrelatorgtcarrylt/relatorgt ltindgteurostarlt/indgt
ltvargtsomeonelt/vargt lt/relationshipgt lt/hngt
Fact lthngt ltrelationshipgt
ltrelatorgtcarrylt/relatorgt ltindgteurostarlt/indgt
ltindgtfredlt/indgt lt/relationshipgt lt/hngt
HornML
3-Step Animation
ltind where"channel-tunnel"gt true lt/indgt
ltrelationshipgt ltrelatorgttravellt/relatorgt
ltindgtfredlt/indgt ltvargtwherelt/vargt lt/relationship
gt
ltrelationship someone"fred" where"channel-tunnel
"gt ltrelatorgtcarrylt/relatorgt
ltindgteurostarlt/indgt ltvargtsomeonelt/vargt lt/relati
onshipgt
53
Horn Inferences in XML Notation (2)
Rule lthngt ltrelationshipgt
ltrelatorgttravellt/relatorgt ltvargtsomeonelt/vargt
ltindgtchannel-tunnellt/indgt
lt/relationshipgt ltrelationshipgt
ltrelatorgtcarrylt/relatorgt ltindgteurostarlt/indgt
ltvargtsomeonelt/vargt lt/relationshipgt lt/hngt
Fact lthngt ltrelationshipgt
ltrelatorgtcarrylt/relatorgt ltindgteurostarlt/indgt
ltindgtfredlt/indgt lt/relationshipgt lt/hngt
HornML
3-Step Animation
ltrelationshipgt ltrelatorgttravellt/relatorgt
ltindgtfredlt/indgt ltvargtwherelt/vargt lt/relationship
gt
54
Horn Inferences in XML Notation (2)
Rule lthngt ltrelationshipgt
ltrelatorgttravellt/relatorgt ltvargtsomeonelt/vargt
ltindgtchannel-tunnellt/indgt
lt/relationshipgt ltrelationshipgt
ltrelatorgtcarrylt/relatorgt ltindgteurostarlt/indgt
ltvargtsomeonelt/vargt lt/relationshipgt lt/hngt
Fact lthngt ltrelationshipgt
ltrelatorgtcarrylt/relatorgt ltindgteurostarlt/indgt
ltindgtfredlt/indgt lt/relationshipgt lt/hngt
HornML
3-Step Animation
ltrelationship someone"fred" where"channel-tunnel
"gt ltrelatorgtcarrylt/relatorgt
ltindgteurostarlt/indgt ltvargtsomeonelt/vargt lt/relati
onshipgt
55
Horn Inferences in XML Notation (2)
Rule lthngt ltrelationshipgt
ltrelatorgttravellt/relatorgt ltvargtsomeonelt/vargt
ltindgtchannel-tunnellt/indgt
lt/relationshipgt ltrelationshipgt
ltrelatorgtcarrylt/relatorgt ltindgteurostarlt/indgt
ltvargtsomeonelt/vargt lt/relationshipgt lt/hngt
Fact lthngt ltrelationshipgt
ltrelatorgtcarrylt/relatorgt ltindgteurostarlt/indgt
ltindgtfredlt/indgt lt/relationshipgt lt/hngt
HornML
3-Step Animation
ltind where"channel-tunnel"gt true lt/indgt
56
Horn Inferences SLD-Resolution,XML-QL
Implementation, Open World

• This inference is carried out as an
  SLD-resolution step
• The procedural semantics of SLD-resolution can be
  used
• An XML-QL implementation seems possible as for
  queries
• A functional-logic generalization of HornML is
  RFML
• If distribution of the clauses over different
  documents in the
• Web is assumed, in this open world logical
  completeness,
• in particular, can hardly still be asked for

HornML
57
Model-Theoretic Semantics
Practical need for Web semantics
Corresponding semantic techniques
Modeling formal XML elements by constructing sets
of logically derivable XML elements
Model-theoretic semantics explicates rule
consequences by generating Herbrand models for
XML knowledge bases of relations and functions
Herbrand Models
58
Collocation Inference Model-Theoretic Semantics
via Consequence Generation
start fact base for addresses address(
name("Me2XML"), place( street("96
Hyper Road"), town("Boston") ) ).
address( name("RDF4All"), place(
street("2001 Broadway"), town("New
York") ) ). address(
name("XML4You"), place( street("96
Hyper Road"), town("Boston") )
). end fact base for addresses
HornML
59
The Rule Markup Language
RuleML
RuleML
60
Agenda

• Introduction and Background
• The RuleML Initiative as a Web Ontology Effort
• Modular Syntax Semantics of RuleML
• RuleML DTDs release 0.8
• Negation Handling in RuleML
• Priorities/Evidences in RuleML
• RuleML Implementations via XSLT Rule Engines
• Example A Semantic Web Scenario in Insurance
• Conclusions

RuleML
61
Introduction and Background
Semantic Web rules less studied than
corresponding ontology (taxonomy) markup Rule
Markup Initiative fills this gap by exploring
rule systems (e.g.,extended Horn logics)
suitable for the Web Syntax (XML and RDF),
semantics, tractability/efficiency,
transformation, and compilation
RuleML
? RuleML ?

• Derivation rules may be evaluated bottom-up as
  in deductive databases, top-down as in logic
  programming, or by tabled resolution as in XSB
• Reaction rules also called "ECA" --
  Event-Condition-Action" -- or Trigger" rules
• Possible combinations

62
The RuleML Initiative as a Web Ontology Effort

• RuleML Initiative started in August 2000 during
  the Pacific Rim International Conference on
  Artificial Intelligence (PRICAI 2000)

• February/March 2001 First RuleML BOF at W3C
  Plenary and WG Meeting event

RuleML

• Ontology equation Ontology Taxonomies
  Axioms(with Axioms having the form of Rules)
  gives big picture

• System of sublanguages from RDF-like triples to
  a labeled Horn logic with equations plus URI
  individuals and relations

63
Modular Syntax Semantics of RuleML
RuleML hierarchy top-level
RuleML

1. Integrity constraints reaction rules that signal
   inconsistency when certain conditions are
   fulfilled
2. Derivation rules reaction rules whose action
   happens to only 'assert' a conclusion when
   certain conditions (premises) are fulfilled
3. Facts derivation rules with empty conjunction of
   premises

64
Modular Syntax Semantics of RuleML (Contd)
derivation rules
Sublanguage hierarchy
ur-equalog
Rooted DAG will be extended with branches for
further sublanguages
equalog
ur-hornlog
hornlog
ur-datalog
ur-datalog join(ur,datalog)
RuleML
datalog
bin-datalog
urc-datalog
ur
URL/URI-like ur-objects
urc-bin-datalog
RDF Rules
urc-bin-data-ground-log
urc-bin-data-ground-fact
RDF- like triples
65
Modular Syntax Semantics of RuleML (Contd)
Separation of concerns
Sublanguage hierarchy 12 sublanguages together
constitute modularized basic RuleML definition.
Except 'UR' (URL/URI) group correspond to
well-known rule systems, each with semantic
(model- and proof-theoretic) characterization
RuleML
Concrete markup In recent months, RuleML 0.7
DTDs have been developed into RuleML 0.8 DTDs
without affecting the above semantics. The new
markup uses XML in RDF's 'explicit role-markup'
style, relativizing XML's positionality to places
where RDF's Seq containers or DAMLOIL lists are
used
66
RuleML DTDs release 0.8
RDF-like triple
ltfactgt lt_headgt ltatomgt lt_oprgtltrel
href"http//www.eeebizz.com/rdf-schApproval"/gtlt/
_oprgt ltind href"http//www.eeebico.org/docs
/joint-mission.html"/gt ltindgtfulllt/indgt
lt/atomgt lt/_headgt lt/factgt
Concrete markup
roles
RuleML
Advantage of roles is object-centered modeling
If some item is to be added to a fact or atom,
then this is easy to attach, RDF-like Item
insertion, XML-like, into child sequence would
cause all subsequent children to assume new
position (problem for XSLT)
67
Negation Handling in RuleML
The Closed-World Negation NOT
UML Diagram
RuleML
IF isPresent(?someCar) AND NOT
isAssignedToRentalOrder(?someCar) AND NOT
requiresService(?someCar) AND THEN
isAvailable(?someCar)
68
Negation Handling in RuleML (Contd)
NOT in RuleML an example
lt_bodygt ltandgt ltatomgt
lt_oprgtltrelgtisPresentlt/relgtlt/_oprgt
ltvargtCarlt/vargt lt/atomgt
ltnotgt ltatomgt
lt_oprgtltrelgtisAssignedToRentalOrderlt/relgtlt/_oprgt
ltvargtCarlt/vargt
lt/atomgt lt/notgt . . . lt/andgt
lt/_bodygt
RuleML
69
Negation Handling in RuleML (Contd)
Open-World Reasoning with NOT and NEG

• NOT non-truth (or failure)
• NEG falsity
• Default rules
• IF NOT hasApproval(?URL) THEN NEG
  isOfficialDocument(?URL)

RuleML
70
Priorities/Evidences in RuleML

• Quantitative Priorities
• Static numerical salience
• Dynamically calculated priorities
• Qualitative Priorities
• Using the Overrides Fact over rule labels

RuleML
71
Priorities/Evidences in RuleML (Contd)
Static Salience Example
ltimpgt lt_rlabgtltindgtbeginnerslt/indgtlt/_rla
bgt lt_sprioritygtltindgt0.75lt/indgtlt/_sprio
ritygt lt_headgt ....... lt/_headgt
lt_bodygt ltatomgt lt_oprgtltrelgtcustomer
Under25lt/relgtlt/_oprgt ltvargtcustomerlt/vargt
lt/atomgt lt/_bodygt lt/impgt
RuleML
72
Priorities/Evidences in RuleML (Contd)
Dynamic Salience Example
ltimpgt lt_rlabgtltindgtbeginnerslt/indgtlt/_rla
bgt lt_dprioritygtltrelgtcalculateSaliencelt
/relgtlt/_dprioritygt lt_headgt .......
lt/_headgt lt_bodygt ltatomgt lt_oprgtltrelgtc
ustomerUnder25lt/relgtlt/_oprgt
ltvargtcustomerlt/vargt lt/atomgt
lt/_bodygt lt/impgt
RuleML
73
RuleML Implementations via XSLT Rule Engines

• XSLT
• is a Rule Based Language
• is a Transformation Tool for RuleML Knowledge
  Bases (KB)
• Using Style sheets to exchange RuleML KBs
• Implementations
• With GEDCOM, Mike Dean created the first
  operational RuleML (0.7) rulebase, where rules on
  family relationships (child, spouse, etc.) are
  run via XSLT translators to the XSB, JESS, and
  N3/cwm engines
• With Mandarax RuleML, Jens Dietrich has
  implemented the first complete input-processing-ou
  tput environment for RuleML (0.8)

RuleML
74
A Semantic Web Scenario in Insurance
Principle Uniform RuleML representation of
derivation rules and underlying document
metadata
RuleML

• A teenager after her first car accident
• how much will my premiums increase and how does
  this accident affect my insurance policy?

75
A Semantic Web Scenario in Insurance (Contd)
ltimpgt lt_rlabgtltindgtbeginnerslt/indgtlt/_rlabgt
lt_sprioritygtltindgt0.75lt/indgtlt/_sprioritygt
lt_headgt ltatomgt lt_oprgtltrelgtcalculat
ePremiumlt/relgtlt/_oprgt ltvargtcustomerlt/vargt
ltindgt40lt/indgt lt/atomgt lt/_headgt
lt_bodygtltandgt ltatomgt
lt_oprgtltrelgtInsurancePolicylt/relgtlt/_oprgt
ltvargtcustomerlt/vargtltvargtinsurancelt/vargt
lt/atomgt ltatomgt
lt_oprgtltrelgtlifeEventlt/relgtlt/_oprgt
ltvargtcustomerlt/vargtltindgtaccidentlt/indgtltvargtrep
ortlt/vargt lt/atomgt
ltatomgt lt_oprgtltrelgtcustomerUnder25lt/relgt
lt/_oprgt ltvargtcustomerlt/vargt
lt/atomgtlt/andgt lt/_bodygt lt/impgt
RuleML
76
A Semantic Web Scenario in Insurance (Contd)
ltimpgt lt_rlabgtltindgtfamilylt/indgtlt/_rlabgt
lt_sprioritygtltindgt0.9lt/indgtlt/_sprioritygt
lt_headgt ltatomgt lt_oprgtltrelgtcalculat
ePremiumlt/relgtlt/_oprgt ltvargtcustomerlt/vargtlt
indgt0lt/indgt lt/atomgt lt/_headgt
lt_bodygtltandgt ltatomgt
lt_oprgtltrelgtInsurancePolicylt/relgtlt/_oprgt
ltvargtcustomerlt/vargtltvargtinsurancelt/vargt
lt/atomgt ltatomgt
lt_oprgtltrelgtlifeEventlt/relgtlt/_oprgt
ltvargtcustomerlt/vargtltindgtaccidentlt/indgtltvargtrep
ortlt/vargt lt/atomgt
ltatomgt lt_oprgtltrelgtFamilyAutoPlanlt/relgtlt
/_oprgt ltvargtcustomerlt/vargtltva
rgtfamilyautolt/vargt lt/atomgtlt/andgt
lt/_bodygt lt/impgt
RuleML
77
A Semantic Web Scenario in Insurance (Contd)
Formalizing the relevant facts

• Olivia is under 25

ltfactgt lt_headgt ltatomgt
lt_oprgtltrelgtcustomerUnder25lt/relgtlt/_oprgt
ltindgtOlivialt/indgt lt/atomgt lt/_headgt lt/factgt

• Olivia has an insurance policy and this document
  has link .../IMA-0835

• Olivia is in a family auto plan and this document
  has link .../FMA-0142

ltfactgt lt_headgt ltatomgt
lt_oprgtltrelgtInsurancePolicylt/relgtlt/_oprgt
ltindgtOlivialt/indgt ltind href
http//www.BostonInsurance.com/policy/IMA-0835
/gt lt/atomgt lt/_headgt lt/factgt

• Olivia's accident report is available at
  TrafficReport.biz

ltfactgt lt_headgt ltatomgt lt_oprgt
ltrelgtFamilyAutoPlanlt/relgtlt/_oprgt
ltindgtOlivialt/indgt ltind href
http//www.BostonInsurance.com/policy/FMA-0142
/gt lt/atomgt lt/_headgt lt/factgt
RuleML
ltfactgt lt_headgt ltatomgt
lt_oprgtltrelgtLifeEventlt/relgtlt/_oprgt
ltindgtOlivialt/indgt ltindgtaccidentlt/indgt
ltind href http//www.TrafficReport.biz/
MA/report0712 /gt lt/atomgt lt/_headgt lt/factgt
78
A Semantic Web Scenario in Insurance (Contd)
Conflict Resolution using Meta facts (a la BRML)
ltimpgt lt_rlabgt ltindgtbeginnerslt/indgt lt/_rlabgt
. . . lt/impgt
ltimpgt lt_rlabgt ltindgtfamilylt/indgt lt/_rlabgt
. . . lt/impgt
RuleML
ltfactgt lt_headgt ltatomgt
lt_oprgtltrelgtOverrideslt/relgtlt/_oprgt
ltindgtfamilylt/indgt ltindgtbeginnerslt/indgt
lt/atomgt lt/_headgt lt/factgt
79
A Semantic Web Scenario in Insurance (Contd)
Conflict Resolution using Meta facts (a la BRML)
ltimpgt lt_rlabgt ltindgtbeginnerslt/indgt lt/_rlabgt
. . . lt/impgt
ltimpgt lt_rlabgt ltindgtfamilylt/indgt lt/_rlabgt
. . . lt/impgt
RuleML
ltfactgt lt_headgt ltatomgt
lt_oprgtltrelgtOverrideslt/relgtlt/_oprgt
ltindgtfamilylt/indgt ltindgtbeginnerslt/indgt
lt/atomgt lt/_headgt lt/factgt
80
RuleML Conclusions
Ontologies The big Picture and future RuleML
Versions

• RuleML rulebases embedded in, or referring to,
  XML and RDFdocuments. Using RuleML in other XML
  namespaces (like for, say, MathML), incl. RDF(S)
  namespaces (ruleml namespace prefix)
• RuleML rule premises could be DAMLOIL concept
  descriptionsor UML object descriptions
• RuleML derivation rules integrated with reaction
  rules, e.g.Situated LP or ECA Framework
• RuleML and RDF Query talking about a joint Rule
  and Query effortas part of W3C Ontology Working
  Group

RuleML
81
Simple HTML/XML Ontology Extensions
SHOE
SHOE
82
SHOE Basics
SHOE (Simple HTML Ontology Extensions) (http//www
.cs.umd.edu/projects/plus/SHOE/) provides
distributed ontologies consisting of Categories
Organized hierarchically, with multiple
inheritance, for classifying instances Relationsh
ip rules Horn clauses (the first well-known Horn
language publishing KBs in the Web) SHOE
originally specified in HTML (before the
definition of XML) meanwhile also specified as
an XML DTD
SHOE
83
Instances (Individuals) as URLs/URIs
Individual constants in SHOE are represented
through an (official) URL/URI In the earlier
Horn-rule example there appear two
individuals, which could be represented in SHOE,
e.g., as eurostar http//www.eurostar.com/ ch
annel-tunnel http//www.eurotunnel.com/
SHOE
84
A SHOE Rule
With these URLs/URIs, the rule in SHOE becomes
ltDEF-INFERENCE DESCRIPTION"travel(?someone,
http//www.eurotunnel.com/) if
carry(http//www.eurostar.com/,?so
meone)"gt ltINF-IFgt ltRELATION
NAME"carry"gt ltARG POS"1"
VALUE"http//www.eurostar.com/"gt
ltARG POS"2" VALUE"someone" USAGE"VAR"gt
lt/RELATIONgt lt/INF-IFgt
ltINF-THENgt ltRELATION NAME"travel"gt
ltARG POS"1" VALUE"someone"
USAGE"VAR"gt ltARG POS"2"
VALUE"http//www.eurotunnel.com/"gt
lt/RELATIONgt lt/INF-THENgt lt/DEF-INFERENCEgt
SHOE
85
XML Namespaces
Namespaces
N'spaces
86
XML Namespaces and Programming-Language
Modules

• XML namespaces are akin to namespaces, packages,
  and modules in programming languages
• Disambiguation of tagand attributenames from
  different XML applications (spaces) through
  different prefixes
• A prefix is separated from the local name by a
  , obtaining prefixname tags
• Namespaces constitute a layer on top of XML 1.0,
  since prefixname is again a valid tag name and
  namespace bindings are ignored by some tools

N'spaces
87
Namespace Bindings

• Prefixes are bound to namespace URIs by attaching
  an xmlnsprefix attribute to the prefixed element
  or one of its ancestors, prefixname1 ,...,
  prefixnamen
• The value of the xmlnsprefix attribute is a URI,
  which may or (unlike for DTDs!) may not point to
  a description of the namespaces syntax
• An element can use bindings for multiple
  name-spaces via attributes xmlnsprefix1 ,...,
  xmlnsprefixm

N'spaces
88
Namespaceless ExampleAddress Variant
Namespaceless XML Markup
ltaddressgt ltnamegtXaver M. Lindelt/namegt
ltstreetgtWikingerufer 7lt/streetgt lttowngt10555
Berlinlt/towngt ltbillgt12.50lt/billgt
ltphonegt030/1234567lt/phonegt ltphonegt030/1234568lt/
phonegt ltfaxgt030/1234569lt/faxgt
ltbillgt76.20lt/billgt lt/ addressgt
bill is ambiguous tag (name clash from two XML
applications)
N'spaces
89
Two-Namespace Example Snail-Mail
and Telecoms Address Parts
Namespace XML Markup
ltmailaddress xmlnsmail"http//www.deutschepost.
de/" xmlnstele"http//www
.telekom.de/"gt ltmailnamegtXaver M.
Lindelt/mailnamegt ltmailstreetgtWikingerufer
7lt/mailstreetgt ltmailtowngt10555
Berlinlt/mailtowngt ltmailbillgt12.50lt/mailbillgt
lttelephonegt030/1234567lt/telephonegt
lttelephonegt030/1234568lt/telephonegt
lttelefaxgt030/1234569lt/telefaxgt
lttelebillgt76.20lt/telebillgt lt/ mailaddressgt
bill disambiguation through mail and tele
prefixes
N'spaces

• The root element, mailaddress, as well as the
  children mailname, mailstreet, mailtown, and
  mailbill, use the mail prefix, bound to a
  deutschepost URI
• The telephone, telefax, and telebill children
  use the tele prefix, bound to a telekom URI

90
Acquiring and Processing Knowledge Markups
Acquire and Process
AP
91
Acquiring and Processing Knowledge Markups

• acquisition
• Protégé with XML Plugin
• Web Onto
• transformation techniques and stylesheet
  languages
• CSS
• XSLT
• query languages
• XQL and XPath
• XML-QL
• XQuery

AP
92
Acquiring XML Knowledge Bases
Acquisition
Acquisition
93
Protégé-2000 as an XML Editor

• Represents the latest in a series of interactive
  tools for knowledge-system development
• Facilitates construction of knowledge bases in a
  principled fashion from reusable components
• Allows a variety of plug-ins to facilitate
  customization in various dimensions
• One plug-in used for XML import/export,
  i.e.Protégé proposed as an XML editor (also as
  an RDFS and OIL editor)

Protégé
94
Knowledge-Base Development with Protégé-2000

1. Build or import a domain ontology (a conceptual
   model of the application area)
2. Custom-tailor GUI for acquisition of content
   knowledge
3. Elicit content knowledge from application
   specialists
4. Map domain ontology to appropriate problem
   solvers for automation of particular tasks
5. Export ontology and content knowledge to target
   format (OKBC, XML, RDFS, OIL, DAMLOIL ...)

Protégé
95
Protégé as an OKBC-Compliant System (Open
Knowledge Base Connectivity)

• OKBC
• Standard mechanism for knowledge bases stored as
  frames of classes, slots, facets, instances,
  ...
• Adopted by several well-known knowledge-representa
  tion systems (Ontolingua, LOOM, Protégé-2000,
  XOL)
• Allows Protégé-2000 to be used as an ontology-
  and knowledge-editing system for any
  OKBC-compliant server

Protégé
96
XML Import Strategy

• tag/element names become class names, except
  leaves which become slots
• example
• ltCustomergt
• ltNamegt
• ltFirstNamegtBilllt/FirstNamegt
• ltLastNamegtBuckramlt/LastNamegt
• lt/Namegt
• ltCardnumgt234 ...lt/Cardnumgt
• lt/Customergt

Protégé
97
Example (Import)Book Order
Protégé
98
XML Export Strategy

• instances
• unreferenced instances become top level elements
  (cyclic references are handled)
• classes and slots become tag names
• objects that are referenced more thanonce are
  shared/reused with id/idref
• ontology
• as simple XML tree, RDF schema, XOL, (future
  work)

Protégé
99
Example (Export)Newspaper Instances
Protégé
100
Example Newspaper Ontology As XML Tree
Protégé
101
Processing XML
Processing
Processing
102
Cascading Style Sheets

• CSS is a language for applying styles such as
  bold and Arial to XML elements
• also works with HTML (supported in most modern
  browsers)
• example (style sheet for poems)
• poem display block
• title display block font-size 16pt
  font-weight bold
• poet display block margin-bottom 10px
• stanza display block margin-bottom 10px
• verse display block
• attached to XML documents with processing
  instructionlt?xml-stylesheet type"text/css"
  href"poem.css"?gt

CSS
103
XSLT (XSL Transformations)

• XSL (Extensible Stylesheet Language) XSLT
  Formatting Objects
• XSLT is a rule-based transformation language for
  XML documents/trees
• result of a transformation usually is again an
  XML document, but may also be HTML or plain text
• transformation takes place
• offline (useful for XML-to-HTML transformation)
• on server (e.g., with Apaches Cocoon or Xalan)
• in client (browser, preliminary support in
  Netscape 6 and IE 5.x)

XSLT
104
XML to HTML XSLT Example Input
ltaddressesgt ltaddressgt ltnamegtXaver M.
Lindelt/namegt ltstreetgtWikingerufer 7lt/streetgt
lttowngt10555 Berlinlt/towngt lt/addressgt
ltaddressgt ltnamegtJohn Doelt/namegt
ltstreetgt42 Gary Cooper Streetlt/streetgt
lttowngtStanwyck Citylt/towngt lt/addressgtlt/address
esgt
XSLT
105
XML to HTML XSLT Example Stylesheet
ltxslstylesheet xmlnsxsl"http//www.w3.org/1999/
XSL/Transform"gt ltxsltemplate match"/"gt
lthtmlgt ltheadgtlttitlegtAddresseslt/titlegtlt/headgt
ltbody bgcolor"white"gt
ltxslapply-templates/gt lt/bodygt lt/htmlgt
lt/xsltemplategt ltxsltemplate
match"address"gt ltpgt ltigtltxslvalue-of
select"name"/gtlt/igtltbr/gt ltxslvalue-of
select"street"/gtltbr/gt ltbgtltxslvalue-of
select"town"/gtlt/bgt lt/pgt lt/xsltemplategtlt/
xslstylesheetgt
template for document root
XSLT
template for address elements
106
XML to HTML XSLT Example Output
lt!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http//www.w3.org/TR/REC-html40/strict.dtd"gtlth
tmlgt ltheadgtlttitlegtAddresseslt/titlegtlt/headgt
ltbody bgcolor"white"gt ltpgtltigtXaver M.
Lindelt/igtltbrgt Wikingerufer 7ltbrgt
ltbgt10555 Berlinlt/bgt lt/pgt ltpgtltigtJohn
Doelt/igtltbrgt 42 Gary Cooper Streetltbrgt
ltbgtStanwyck Citylt/bgt lt/pgt
lt/bodygtlt/htmlgt (The HTML code was produced with
Apaches Cocoon in HTML mode, henceltbr/gt became
ltbrgt)
XSLT
107
Transformational (Operational) Semantics
Practical need for Web semantics
Corresponding semantic techniques
Getting meaning from XML Web pages through
processing results
Operational semantics via XSLT stylesheets
transforms XML into other XML and HTML documents
using Cocoon, Xalan, ...
XSLT
108
XML to XML Transformational Semantics via an
XSLT Stylesheet
ltaddressesgt ltaddressgt ltnamegtMe2XMLlt/namegt
ltstreetgt96 Hyper Roadlt/streetgt
lttowngtBostonlt/towngt lt/addressgt ltaddressgt
ltnamegtRDF4Alllt/namegt ltstreetgt2001
Broadwaylt/streetgt lttowngtNew Yorklt/towngt
lt/addressgt ltaddressgt ltnamegtXML4Yoult/namegt
ltstreetgt96 Hyper Roadlt/streetgt
lttowngtBostonlt/towngt lt/addressgtlt/addressesgt
XSLT
109
XML to XML XSLT Stylesheet with a
Tree-Transforming Template 1
lt!-- process addresses and position address
nester --gt ltxsltemplate match"/addresses"gt
ltaddressesgt ltxslapply-templates/gt
lt/addressesgt lt/xsltemplategt
XSLT
110
XML to XML XSLT Stylesheet with a
Tree-Transforming Template 2
lt!-- apply address nester to each flat address
--gt ltxsltemplate match"address"gt
ltaddressgt ltnamegtltxslvalue-of
select"name"/gtlt/namegt ltplacegt
ltstreetgtltxslvalue-of select"street"/gtlt/streetgt
lttowngtltxslvalue-of select"town"/gtlt/towngt
lt/placegt lt/addressgt lt/xsltemplategt
XSLT
111
XQL and XPath

• XSLT uses XPath to select parts of the input XML
  documents, e.g.
• ltxsltemplate match"/"gt document root
• ltxslvalue-of select"name"/gt element name
• syntax is not XML-based, but intended to be used
  in URLs (XPointer) and XSLT as above
• XQL is a variant of XPath especially designed for
  querying XML documents
• XPath/XQL expressions select parts of XML
  documents (no transformations!)

XQL
112
XQL Expressions 1

• XQL expressions (relative to a context node)
• addressselect element nodes with tag name
  address
• address/nameselect name element nodes directly
  below address element nodes
• address/nameJohn Doeas before, plus the
  content of the name element must be John Doe
• book//nameselect name element nodes anywhere
  below book element nodes

XQL
113
XQL Expressions 2

• absolute XQL expressions
• /document root (the node that contains the
  document element)
• /addresses/address/name
• //namename element nodes anywhere in the
  document
• expressions with attributes (prefixed with _at_)
• address/_at_typeattribute nodes with name type
  below address element nodes
• address/_at_typeemailas above, plus the value of
  the type attribute is email

XQL
114
XQL Expressions 3

• filter expressions
• addressname select address element nodes
  with a direct name sub-element node
• addressnameJohn Doeas above, plus the
  content of the name element is John Doe
• address_at_typeemailselect address element
  nodes that have a type attribute whose value is
  email

XQL
115
XML-QL

• borrows features of query languages developed by
  the database research community for
  semistructured data
• similar to SQL
• (simplified) base construct is WHERE pattern1 IN
  URI1, ... CONSTRUCT patternnwhere the patterns
  are XML fragments with variables (prefixed with
  )
• XML-QL introduces an abbreviated XML syntax for
  simplicity lttaggt...lt/gt instead of lttaggt...lt/taggt

XML-QL
116
XML-QL Example 1

• return short addresses (town-city renaming,
  without street)WHERE ltaddressgt
  ltnamegtnlt/gt lttowngttlt/gt lt/gt IN
  "www.test.org/addresses.xml" CONSTRUCT
  ltshortaddressgt ltnamegtnlt/gt ltcitygttlt/gt
  lt/gt

ltaddressgt ltnamegtXaver M. Lindelt/namegt
ltstreetgtWikingerufer 7lt/streetgt lttowngt10555
Berlinlt/towngt lt/addressgt
ltstreetgt elements are also matched
XML-QL
ltshortaddressgt ltnamegtXaver M. Lindelt/namegt
ltcitygt10555 Berlinlt/citygt lt/shortaddressgt
117
XML-QL Example 2

• XML-QL allows joining by valueWHERE
  ltaddressgt ltnamegtnlt/gt lt/gt ELEMENT_AS a IN
  "www.test.org/addresses.xml", ltbookgt
  ltauthorgtnlt/gt lttitlegttlt/gt lt/gt IN
  "www.test.org/books.xml"CONSTRUCT ltbookgt
  lttitlegttlt/gt a lt/gt

XML-QL
118
XQuery

• derived from Quilt
• borrows features from several languages
• XPath and XQL path expression syntax
• XML-QL notion of binding variables and then
  using the bound variables to create new
  structures
• SQL series of clauses based on keywords that
  provide a pattern for restructuring data (the
  SELECT-FROM-WHERE pattern in SQL)
• OQL functional language composed of several
  different kinds of expressions that can be nested
  with full generality

XQuery
119
XQuery Examples 1

• Path expressions
• In the second chapter of the document named
  "zoo.xml", find the figure(s) with caption "Tree
  Frogs"document("zoo.xml")/chapter2//figurecap
  tion "Tree Frogs"
• Ranges Find all the figures in chapters 2
  through 5 of the document named
  "zoo.xml"document("zoo.xml")/chapterRANGE 2 TO
  5//figure
• Dereferencing Find captions of figures that are
  referenced by ltfigrefgt elements in the chapter of
  "zoo.xml" with title "Frogs"document("zoo.xml")/
  chaptertitle "Frogs"//figref/_at_refid-gtfig/capt
  ion

XQuery
120
XQuery Examples 2

• FLWR (FOR-LET-WHERE-RETURN) E