Tutorial on Knowledge Markup Techniques - PowerPoint PPT Presentation

Loading...

PPT – Tutorial on Knowledge Markup Techniques PowerPoint presentation | free to download - id: 1281c8-ZTlkN



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Tutorial on Knowledge Markup Techniques

Description:

Harold Boley. Stefan Decker. Michael Sintek. ECAI 2000 Berlin. 22 August 2000 (last updated: 25 April 2001) 25-Apr-01 ... Increasing demand for formalized ... – PowerPoint PPT presentation

Number of Views:89
Avg rating:3.0/5.0
Slides: 162
Provided by: michael653
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Tutorial on Knowledge Markup Techniques


1
Tutorial on Knowledge Markup Techniques
  • Harold Boley Stefan Decker Michael Sintek

ECAI 2000 Berlin 22 August 2000 (last
updated 25 April 2001)
2
Overview and Tutorial Mindmap
  • Increasing demand for formalized knowledge on
    the Web AIs chance!
  • XML-based markup languages provide a 'universal'
    storage and interchange format for such
    Web-distributed knowledge representation
  • Tutorial introduces key techniques for knowledge
    markup we show how to marry AI representations
    (e.g., logics and frames) and XML (incl. RDF and
    RDF Schema)

Namespaces
CSS
DTDs
XSLT
Stylesheets
FRODO
Agents
Ontobroker
Transformations
XML
HornML
Rules
XQL
Queries
RFML
XML-QL
SHOE
RDFS
Frames
Acquisition
XOL
Protégé
3
Extensible Markup Language
XML
XML
4
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
5
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
6
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
7
Address Example HTML to XML
HTML Markup
ltemgtXaver M. Lindelt/emgt ltbrgt Wikingerufer
7 ltbrgt ltstronggt10555 Berlinlt/stronggt
XML tags are chosen for representation needs
XML
XML Markup
ltaddressgt ltnamegtXaver M. Lindelt/namegt
ltstreetgtWikingerufer 7lt/streetgt lttowngt10555
Berlinlt/towngt lt/addressgt
8
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
. . .
9
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
10
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
11
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
12
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"
13
Address Example The Element Tree
XML
Node-Labeled, (Left-to-Right-)Ordered Element
Tree
tree
subtrees
14
Address Example Document 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
Document Type Tree
address
name
street
town
PCDATA
PCDATA
PCDATA
15
Address Example Document 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
16
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/
17
Mail-Box Example Address Variant
XML
Node-Labeled, (Left-to-Right-)Ordered Element
Tree
18
""-Disjoined Street/Mail-Box Example Document
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
19
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
20
""/""-Repetitive-Phone -Fax Example Document
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
21
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
22
"?"-Optional-Country Example Document 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
23
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")
24
Horn Logic Markup Languages
HornML
HornML
25
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
26
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
27
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
28
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
29
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
30
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
31
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
32
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 separate knowledge
base) lthn id"john-channel"gt ltrelationshipgt
ltrelatorgttravellt/relatorgt
ltindgtjohnlt/indgt ltindgtchannel-tunnellt/indgt
lt/relationshipgt lt/hngt
HornML
33
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
34
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
35
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!
36
DTDs Generation 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
37
DTDs Generation of the Example Rule (2)
lthngt ltrelationshipgt ltrelatorgttravellt/relat
orgt ltvargtsomeonelt/vargt
ltindgtchannel-tunnellt/indgt lt/relationshipgt
ltrelationshipgt ltrelatorgtcarrylt/relatorgt
ltindgteurostarlt/indgt ltvargtsomeonelt/vargt
lt/relationshipgt lt/hngt
HornML
38
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
39
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
40
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
41
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
42
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
43
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
44
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
45
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
46
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
47
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
  • 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
48
Relational-Functional Markup Language
RFML
RFML
49
A 10-Step Strategy to Publish and Reuse
Declarative Programs as XML Markups
  • Specify the declarative programming language
    through an XML document type definition (DTD)
  • Convert any to-be-published declarative program
    from its source syntax to an XML document
    according to the DTD
  • Upload such an XML document to a Web server for
    publication
  • Also offer the declarative programs for
    server-side querying (e.g. CGI) and advertise
    their XML-document version to search engines
    etc., ideally using metadata markup (e.g.
    RDF/XML)
  • Distribute these documents to requesting clients
    via standard Web protocols (e.g. HTTP)
  • If necessary, transform such an XML document to a
    declarative target language with a different DTD,
    possibly using an (XSLT) stylesheet
  • Download any requested XML document at the client
    site
  • Convert this XML document to the client's target
    syntax, possibly using (XSLT CSS) stylesheets
  • Query the target version via the client's program
    interpreter and optionally download the servers
    source-program interpreter (once) for client-side
    querying, ultimately as a browser plug-in
  • Reuse the target version, say in existing programs

Distribute (transform)
RFML
Reuse
Query
Note ProgramSource may be identical to
ProgramTarget
50
Cross-Fertilizations of XML and Declarative
Programming Languages
  • Separate vs. joint assertion and query languages
  • XML Still separate schema and query of elements
  • DPL Mostly joint storage and retrieval of
    clauses
  • Generating XML markup from more compact
    special-purpose notations (and vice versa)
  • XML validators and DPL compilers
  • XML stylesheets and DPL transformers
  • Specification, correctness, and efficiency
    technology
  • Early case study with the declarative language
    RFML (Relational-Functional Markup Language)

RFML
51
Basics of the Relational-Functional Markup
Language RFML
  • Much of Web knowledge constitutes definitions of
    relations and functions
  • Kernel of Relational-Functional language suited
    for XML knowledge markup
  • Uniform, rather small language
  • Sufficient expressive power for practical use
  • RFML is an XML application for integrated
    relational-functional information
  • Relational (hn) and functional (ft) clauses
    together define a unified notion of operators
  • RFML DTD small and open to various extensions

RFML
52
Relational Facts From Tables to Prolog
Collect data on consumer behavior in ...
Relational Table
satisfied( Customer, Item, Price ) john wine 17.9
5 peter beer 06.40
RFML
Prolog (Ground) Facts
satisfied( Customer, Item, Price ) satisfied( john
, wine, 17.95 ). satisfied( peter, beer, 06.40 ).
53
Relational Facts From Prolog to RFML
Prolog (Ground) Facts
satisfied(john,wine,17.95). satisfied(peter,beer,6
.40).
RFML (Ground) Markup
lthngt lthngt ltpattopgt ltpattopgt
ltcongtsatisfiedlt/congt ltcongtsatisfiedlt/congt
ltcongtjohnlt/congt ltcongtpeterlt/congt
ltcongtwinelt/congt ltcongtbeerlt/congt
ltcongt17.95lt/congt ltcongt6.40lt/congt
lt/pattopgt lt/pattopgt lt/hngt lt/hngt
RFML
54
Relational Rules From Prolog to RFML
Infer data on consumer behavior via ...
Prolog (Non-Ground) Rule
satisfied(C,I,P) - buy(week1,C,I,P),
buy(week2,C,I,P).
RFML (Non-Ground) Markup
lthngt ltpattopgt ltcongtsatisfiedlt/congtltvargtClt/vargtlt
vargtIlt/vargtltvargtPlt/vargt lt/pattopgt ltcallopgt
ltcongtbuylt/congtltcongtweek1lt/congtltvargtClt/vargtltvargtIlt/
vargtltvargtPlt/vargt lt/callopgt ltcallopgt
ltcongtbuylt/congtltcongtweek2lt/congtltvargtClt/vargtltvargtIlt/
vargtltvargtPlt/vargt lt/callopgt lt/hngt
RFML
55
Functional Facts From Unconditional Equations to
RFML
Discriminate on payment method via ...
Unconditional (Ground) Equations
pay(john,fred,17.95) cheque
pay(peter,fred,6.40) cash
RFML (Ground) Markup
ltftgt ltpattopgt ltcongtpaylt/congt
ltcongtjohnlt/congt ltcongtfredlt/congt
ltcongt17.95lt/congt lt/pattopgt
ltcongtchequelt/congt lt/ftgt
ltftgt ltpattopgt ltcongtpaylt/congt
ltcongtpeterlt/congt ltcongtfredlt/congt
ltcongt6.40lt/congt lt/pattopgt
ltcongtcashlt/congt lt/ftgt
RFML
56
Functional Queries Joint Assertion and Query
Language
The pay function can be queried
(non-ground) directly via a callop
markup ltcallopgt ltcongtpaylt/congt
ltcongtjohnlt/congt ltvargtmerchantlt/vargt
ltvargtpricelt/vargt lt/callopgt binding the two
variables to the corresponding constants in the
definition pattern and returning the constant
'cheque' Same indirectly as the right side of a
conditional equation ...
RFML
57
Functional Rules From Conditional Equations to
Relfun
Predict consumers acquisition behavior via ...
Conditional (Non-Ground) Equation
acquire(Customer,Merchant,Item,Price)

pay(Customer,Merchant,Price)
if satisfied(Customer,Item,Price)
RFML
Relfun (Non-Ground) Footed Rule
acquire(Customer,Merchant,Item,Price) -
satisfied(Customer,Item,Price)
pay(Customer,Merchant,Price).
58
Functional Rules From Relfun to RFML
Relfun (Non-Ground) Footed Rule
acquire(C,M,I,P) - satisfied(C,I,P) pay(C,M,P).
RFML (Non-Ground) Markup
ltftgt ltpattopgt ltcongtacquirelt/congtltvargtclt/vargt
ltvargtmlt/vargtltvargtilt/vargtltvargtplt/vargt lt/pattopgt
ltcallopgt ltcongtsatisfiedlt/congtltvargtclt/vargtltvar
gtilt/vargtltvargtplt/vargt lt/callopgt ltcallopgt
ltcongtpaylt/congtltvargtclt/vargtltvargtmlt/vargtltvargtplt/vargt
lt/callopgt lt/ftgt
RFML
59
Relational-Functional Computations What Items
John Buys, and How
A query of the acquire function now leads to the
following RFML computation (4-step animation)
ltcallopgt ltcongtacquirelt/congt
ltcongtjohnlt/congt ltcongtfredlt/congt
ltvargtitemlt/vargt ltcongt17.95lt/congt lt/callopgt
RFML
It binds the variable 'item' to the constant
'wine' (RFML bindings represented as XML
attributes) and returns the constant 'cheque'
60
Relational-Functional Computations What Items
John Buys, and How
A query of the acquire function now leads to the
following RFML computation (4-step animation)
ltcallopgt ltcongtacquirelt/congt
ltcongtjohnlt/congt ltcongtfredlt/congt
ltvargtitemlt/vargt ltcongt17.95lt/congt lt/callopgt
RFML
It binds the variable 'item' to the constant
'wine' (RFML bindings represented as XML
attributes) and returns the constant 'cheque'
61
Relational-Functional Computations What Items
John Buys, and How
A query of the acquire function now leads to the
following RFML computation (4-step animation)
RFML
It binds the variable 'item' to the constant
'wine' (RFML bindings represented as XML
attributes) and returns the constant 'cheque'
62
Relational-Functional Computations What Items
John Buys, and How
A query of the acquire function now leads to the
following RFML computation (4-step animation)
RFML
It binds the variable 'item' to the constant
'wine' (RFML bindings represented as XML
attributes) and returns the constant 'cheque'
63
Relational-Functional Computations What Items
John Buys, and How
A query of the acquire function now leads to the
following RFML computation (4-step animation)
RFML
It binds the variable 'item' to the constant
'wine' (RFML bindings represented as XML
attributes) and returns the constant 'cheque'
64
The RFML DTD (1)
lt!-- ENTITIES use non-terminals of Relfun grammar
(Boley 1999) 'untagged', --gt lt!-- e.g. term
con var anon struc tup, just specifying,
say, --gt lt!-- ltvargt X lt/vargt term instead of
nesting lttermgt ltvargt X lt/vargt lt/termgt
--gt lt!ENTITY variable "(var anon)"
gt lt!ENTITY appellative "(con variable
struc)" gt lt!ENTITY term
"(appellative tup)" gt lt!-- ELEMENTS use
non-terminals of Relfun grammar 'tagged', so var
... --gt lt!-- itself becomes ltvargt X lt/vargt
--gt lt!--
rfml is the document root, the possibly empty
knowledge-base top-level --gt lt!-- of hn or ft
clauses
--gt lt!ELEMENT rfml (hn ft)
gt lt!-- hn clauses are a pattop before zero
(facts) or more terms or callop's --gt lt!-- ft
clauses are a pattop before at least one term or
callop (the foot) --gt lt!ELEMENT hn
(pattop, (term callop)) gt lt!ELEMENT ft
(pattop, (term callop)) gt lt!-- a
pattop clause head is an operator appellative and
a (rest) pattern --gt lt!ELEMENT pattop
(appellative,
(term), (rest,
(variable tup))?) gt
RFML
65
The RFML DTD (2)
lt!-- a callop clause body premise or foot is a
(nested) operator call --gt lt!ELEMENT
callop ((appellative callop),
(term callop),
(rest, (variable tup callop))?)
gt lt!-- a struc is a constructor appellative with
argument terms (and a rest) --gt lt!ELEMENT struc
(appellative,
(term), (rest,
(variable tup))?) gt lt!-- a tup is a list of
terms (zero or more), perhaps followed by a rest
--gt lt!ELEMENT tup ((term),
(rest, (variable tup))?)
gt lt!-- con and var are just parsed character
data (character permutations) --gt lt!ELEMENT
con (PCDATA)gt lt!ELEMENT var
(PCDATA)gt lt!-- anon (Relfun "_") and rest
(Relfun "") are always-empty elements
--gt lt!ELEMENT anon EMPTY gt lt!ELEMENT
rest EMPTY gt
RFML
66
RFML Summary
  • RFML combines relational-functional
    knowledge-representation and declarative-programmi
    ng languages on the Web
  • It has been implemented as a (Web-)output syntax
    for declarative knowledge bases and computations
  • RFML stylesheets for Prolog, Relfun, and other
    languages are under development
  • Further descriptions, examples, the DTD, and
    download information are available at
    http//www.relfun.org/rfml/

RFML
67
Simple HTML/XML Ontology Extensions
SHOE
SHOE
68
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
69
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
70
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
71
XML-Based Ontology Exchange Language
XOL
XOL
72
XOL XML-based Ontology Exchange Language
(by Peter Karp, Vinay Chaudhri, Jerome Thomere,
SRI)
  • A language for specifying ontologies
  • A language for exchanging ontologies
  • Can also be used for exchange of databases
  • Frame-based semantic model OKBC-Lite
  • Expressive power similar to Ontolingua
  • XML-based syntax (kernel DTD)

XOL
73
Essential Form of an XOL File
  • ltmodulegt
  • . . .
  • ltclassgt.....lt/classgt
  • ltclassgt.....lt/classgt
  • ltslotgt.....lt/slotgt
  • ltslotgt.....lt/slotgt
  • ltindividualgt.... lt/individualgt
  • ltindividualgt.... lt/individualgt
  • lt/modulegt

XOL
74
Module-Header Definition
  • ltmodulegt
  • ltnamegtGeneslt/namegt
  • ltversiongt1.2lt/versiongt
  • ltdocumentationgtAn Ontology for the functional
    classification of geneslt/documentationgt
  • . . .
  • lt/modulegt

XOL
75
Class Definition
  • ltclassgt
  • ltnamegtGeneslt/namegt
  • ltdocumentationgtThe class of all Genes. Each
    subclass of class Genes describes a specific
    category of gene function.lt/documentationgt
  • lt/classgt
  • ltclassgt
  • ltnamegtGC001lt/namegt
  • ltsubclass-ofgtGeneslt/subclass-ofgt
  • lt/classgt

XOL
76
Slot Definition
  • ltslotgt
  • ltnamegtcommon-namelt/namegt
  • ltdocumentationgtA string that encodes the
    official name of the entity.lt/documentationgt
  • ltdomaingtGeneslt/domaingt
  • ltslot-cardinalitygt1lt/slot-cardinalitygt
  • ltslot-value-typegtstringlt/slot-value-typegt
  • lt/slotgt

XOL
77
Individual Definition
  • ltindividualgt
  • ltnamegtEG10115lt/namegt
  • ltdocumentationgtThe trpC genelt/documentationgt
  • ltinstance-ofgtGC001lt/instance-ofgt
  • ltslot-valuesgt
  • ltnamegtcommon-namelt/namegt
  • ltvaluegttrpClt/valuegt
  • lt/slot-valuesgt
  • ....
  • lt/individualgt

XOL
78
XML Namespaces
Namespaces
N'spaces
79
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
80
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
81
Namespaceless Example Address 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
82
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

83
Acquiring and Processing Knowledge Markups
Acquire and Process
AP
84
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

AP
85
Acquiring XML Knowledge Bases
Acquisition
Acquisition
86
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 editor)

Protégé
87
Knowledge-Base Development with Protégé-2000
  • Build or import a domain ontology (a conceptual
    model of the application area)
  • Custom-tailor GUI for acquisition of content
    knowledge
  • Elicit content knowledge from application
    specialists
  • Map domain ontology to appropriate problem
    solvers for automation of particular tasks
  • Export ontology and content knowledge to target
    format (OKBC, XML, RDFS, ...)

Protégé
88
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é
89
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é
90
Example (Import) Book Order
Protégé
91
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 than once are
    shared/reused with id/idref
  • ontology
  • as simple XML tree, RDF schema, XOL, … (future
    work)

Protégé
92
Example (Export) Newspaper Instances
Protégé
93
Example Newspaper Ontology As XML Tree
Protégé
94
Processing XML
Processing
Processing
95
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
    instruction lt?xml-stylesheet type"text/css"
    href"poem.css"?gt

CSS
96
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)
  • in client (browser, preliminary support in
    Netscape 6 and IE 5.x)

XSLT
97
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/addressgt lt/address
esgt
XSLT
98
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/xsltemplategt lt/
xslstylesheetgt
template for document root
XSLT
template for address elements
99
XSLT Example Output
lt!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http//www.w3.org/TR/REC-html40/strict.dtd"gt lth
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/bodygt lt/htmlgt (The HTML code was produced with
Apaches Cocoon in HTML mode, hence ltbr/gt became
ltbrgt)
XSLT
100
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
101
XQL Expressions 1
  • XQL expressions (relative to a context node)
  • address select element nodes with tag name
    address
  • address/name select name element nodes directly
    below address element nodes
  • address/nameJohn Doe as before, plus the
    content of the name element must be John Doe
  • book//name select name element nodes anywhere
    below book element nodes

XQL
102
XQL Expressions 2
  • absolute XQL expressions
  • / document root (the node that contains the
    document element)
  • /addresses/address/name
  • //name name element nodes anywhere in the
    document
  • expressions with attributes (prefixed with _at_)
  • address/_at_type attribute nodes with name type
    below address element nodes
  • address/_at_typeemail as above, plus the value of
    the type attribute is email

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

XQL
104
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 patternn where 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
105
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
106
XML-QL Example 2
  • XML-QL allows joining by value WHERE
    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
107
XML-Based Agent Techniques
Agents
Agents
108
XML-based Agent Techniques
  • XML-RPC
  • remote procedure calls using HTTP as the
    transport and XML as the encoding
  • DAML
  • DARPA Agent Markup Language
  • FRODO framework
  • under development at DFKI Kaiserslautern in the
    Knowledge Management Group
  • Ontobroker
  • AIFB/University of Karlsruhe

Agents
109
The FRODO Agent Framework
  • integration of
  • separately developed OM (organizational memory)
    solutions and legacy (DB) systems
  • DAU (document analysis and understanding)
    components (e.g., for wrapping)
  • distributed problem solving
  • based on
  • declarative knowledge representation
  • agents / speech acts / protocols
  • Internet-enabled HTTP, XML, RDF, ...

FRODO
110
Involved XML Technologies
  • FIPA-like agents communicate with XML messages
  • communication via HTTP
  • involved XML technologies
  • XSLT for message transformation and information
    extraction
  • RDF for representing meta-information
  • RDF Schema for representing ontologies
  • XML/RDF-based query and transformation languages
    for distributed inferences
  • first prototypical realization of an RDF/RDF
    Schema query agent (based on an F-Logic
    implementation for RDF SiLRI, Karlsruhe /
    Stanford)

FRODO
111
Agents Communicate Via XML Messages
ltmessage type"message-type"
sender"sender-url"
receiver"receiver-url"
additional-information gt contents lt/messagegt
FRODO
  • message types inform, request, agree, cancel,
    confirm, disconfirm, subscribe, ... (speech acts,
    FIPA)
  • additional information reply-with, in-reply-to,
    language, ontology, reply-by, protocol, ...
  • contents XML forest


112
Message Exchange is Based on Internet Techniques
HTTP
HTML Form
Agent 1
Browser
Agent n
Servlet
Java Applet
Servlet-enabled HTTP Server
FRODO
Browser
Java Application
CGI 1
CGI n
C/C etc. Application
(standard) HTTP Server
113
Simple Integration of Foreign Software Components
is Enabled
  • all foreign software components which are
    designed as CGI programs are immediately usable
    as agents (no explicit wrappers needed)
  • access to agents simple for all software
    components that have access to a HTTP library
    (Java, C, C, ...)

FRODO
114
Ontobroker Application
Ontobroker
Ontobroker
115
Ontobroker/On2broker (AIFB/University of
Karlsruhe)
Ontobroker
116
Example Ontology
Ontobroker
117
Annotated HTML Pages
lthtmlgt ltheadgtltTITLEgt Richard Benjamins
lt/TITLEgt lta ontopageResearchergt lt/agt
lt/headgt ltH1gt ltA HREFpictures/id-rich.gifgt
ltIMG alignmiddle SRCpictures/richard.gifgtlt/A
gt lta ontopagephotohref HREFhttp//www.iii
a.csic.es/richard/pictures/richard.gif
gtlt/agt lta ontopagefirstNamebodygtRichardlt/agt
lta ontopagelastNamebodygtBenjamins lt/agt
lt/h1gt ltpgt ltA ontopageaffiliationbody
HREFcardgt Artificial Intelligence Research
Institute (IIIA)lt/Agt - lta hrefhttp//www.csic.e
s/gtCSIClt/agt, Barcelona, Spain ltbrgt and ltbrgt ltA
ontopageaffiliationbody HREFhttp//www.swi
.psy.uva.nl/gt Dept. of Social Science
Informatics (SWI)lt/Agt - ltA HREFhttp//www.uva.n
l/uva/english/gtUvAlt/Agt, Amsterdam, the
Netherlands
Ontobroker
118
Ontobroker Query Tool
Ontobroker
119
Resource Description Framework
RDF
RDF
120
Disclaimer
There is nothing interesting in what we are
doing. The only interesting thing is the scale
upon which we are attempting to do it.
RDF
R.V. Guha, Epinions
121
Outline
  • Motivation Why XML is not enough
  • Introduction to RDF
  • Requirements for KR on the Web
  • The RDF Data Model
  • RDF Schema
  • Extensions of RDF(S)
  • Tools for RDF and RDF Schema
  • Parser, Query, and Inference Engines

RDF
122
Why The Shift Towards More Semantics?
  • Information Overload
  • Information on the Web currently aiming at Human
    Consumption
  • Information Consumption is too time consuming
  • Search Engines fail more and more
  • combined coverage is less than 42 of the
    HTML-Web
  • Data Interchange growing (e.g. B2B)
  • needs a common semantics
  • XML?

RDF
123
Extensible Markup Language (XML) Revisited
  • Key idea separate structure from presentation
  • XML DTDs or Schema define document structure
  • Replace HTML with two things
  • A domain specific markup language (defined in
    XML)
  • A map from that markup language to HTML (defined
    using XSL)
  • DTD enables document recipients to tell whether
    theyve received a well-formed document
  • Gives a minimal level of validation

RDF
124
Why XML is Not Enough
  • Main advantage of using XML is reusing the
    parser and document validation
  • Many different possibilities to encode a domain
    of discourse
  • Leads to difficulties when understanding of
    foreign documents is required
  • gt Next step separate content from structure!

RDF
125
Encoding of Knowledge Example
The Creator of the Resource http//www.w3.org/Ho
me/Lassila is Ora Lassila
http//www.w3.org/Home/Lassila
Creator
Endless encoding possibilities in XML
RDF
126
Point to Point Communication for
Machine-Understandable Data
Conceptual Domain Model (Objects and Relations)
Person is_a Mammal Student is_a Person
----
Translation Step
DTD or XML Schema
ltxsdschema xmlnsxsd"http//..."gt
ltxsdannotationgt A-Schema lt/xsd... lt/xsdsche
magt
RDF
Deployment
Recipient using DTD A
Common Semantics
127
Many Previously Unknown Communication Partners
RDF
128
New Partners Dont Understand Each Other
?
Communication Partner using DTD B
Communication Partner using DTD C
?
?
RDF
XML-based Communication using DTD A
Parse Tree
XML- Parser
Sender using DTD A
Recipient using DTD A
129
Merging Steps Between Models
DTD A
Steps
DTD B
ltxsdschema xmlnsxsd"http//..."gt
ltxsdannotationgtB-Schema lt/xsd... lt/xsdschem
agt
ltxsdschema xmlnsxsd"http//..."gt
ltxsdannotationgtA-Schema lt/xsd... lt/xsdschem
agt
Reengineering of the conceptual model
Matching
RDF
Matching
XML Document Translation Generation (e.g. in
XSLT)
ltxslstylesheet version"1.0 xmlnsxsl"http//.
...Transform" ltxsltemplate match"/"gt
.... lt/xsltemplategt lt/x
About PowerShow.com