Knowledge Markup and

sounderslipInternet και Εφαρμογές Web

22 Οκτ 2013 (πριν από 3 χρόνια και 9 μήνες)

149 εμφανίσεις

Tutorial on

Knowledge Markup and

Resource Semantics

Harold Boley

Stefan Decker

Michael Sintek

IJCAI
-
01 Seattle

6 August 2001
(version: 20 August 2001)

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

1

Overview and Tutorial Mindmap


Increasing demand for
formalized knowledge

on the Web:
AI’s
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]

DTDs

XML

RDF[S]

Namespaces

Stylesheets

CSS

XSLT

XQL

Queries

XML
-
QL

Transformations

Acquisition

Protégé

Agents

Frames

Rules

SHOE

HornML

RuleML

DAML

XQuery

TopicMaps

Ontobroker

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

2

Web Languages for

Knowledge 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

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

3

Web Languages for

Machine Interpretation


XML (
E
x
tensible
M
arkup
L
anguage
):

Semiformal documents range between
non
-
formatted texts

and
fully formatted
databases


RDF (R
esource
D
escription
F
ramework
):

Structured metadata describe arbitrary
heterogeneous

Web pages/objects in a
homogeneous

manner

Machines (e.g. search engines) can analyze

XML or RDF markups better than full HTML

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

4

The Semantic Web Activity

of 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
)

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

5

The Semantic Web Layered Architecture

(
http://www.w3.org/2001/Talks/0228
-
tbl/slide5
-
0.html
)

Tim Berners
-
Lee:

“Axioms, Architecture and Aspirations”

W3C all
-
working group plenary Meeting

28 February 2001

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

6

The Semantic Web Layered Architecture:
Where are the Semantic Web Semantics?

(
http://www.w3.org/2001/Talks/0228
-
tbl/slide5
-
0.html
)

Tim Berners
-
Lee:

“Axioms, Architecture and Aspirations”

W3C all
-
working group plenary Meeting

28 February 2001

This tutorial discusses
knowledge markup

for the Semantic Web,

together with the required
resource

semantics

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

7

Partial Orders

Hierarchical
structure (i.e., the
“taxonomy” part of
an “ontology”) for
arbitrary domains
of discourse

Practical need for
Web semantics:

Corresponding
semantic techniques:

Partial orders over sets
of arbitrary objects
(classes, relations, ...)
permit inheritance
down the “>”
-
links of
tree
-
generalizing DAGs
(
D
irected
A
cyclic
G
raphs)

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

8

Financial Math Excerpt from
Mathematics
International Ontology

as RDF Schema

RDF Schema:

<rdf:Class rdf:ID="management_mathematics_fm">


<rdfs:subClassOf rdf:resource="#fm"/>

</rdf:Class>

<rdf:Class rdf:ID="math_fm">


<rdfs:subClassOf rdf:resource="#fm"/>

</rdf:Class>


Prolog
-
like Syntax:

subsumes(fm,management_mathematics_fm).

subsumes(fm,math_fm).

DAG

(Relfun’s

sortbase

browser):

XSLT Stylesheet:

DAG (
FRODO RDFSViz

rendering):


taxonomy.gif


rfml2rdfs.xsl

XML Syntax:
RFML

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

9

Metadata (Resource) Semantics

Annotating
arbitrary Web
objects in
RDF/XML for
semantic retrieval

Practical need for
Web semantics:

Corresponding
semantic techniques:

Metadata semantics in
XML
-
based RDF and
RDF Schema enables
high
-
precision search
engines for Berners
-
Lee’s "Semantic Web"

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

10

Knowledge Markup &

Resource

Semantics:


XML Documents with RDF Annotations

<addresses>


<rdf:RDF xmlns=
“http://www.w3.org/…”
>


<rdf:Description about=
“”
>


<Shape>
flat
</Shape>


<ConvertsTo


resource=“http://addr.nest.com”
/>


</rdf:Description>


</rdf:RDF>



<address>


<name>
Me2XML
</name>


<street>
96 Hyper Road
</street>



<town>
Boston
</town>


</address>


<address>


<name>
RDF4All
</name>


<street>
2001 Broadway
</street>


<town>
New York
</town>


</address>


. . .

</addresses>

<addresses>


<rdf:RDF xmlns=
“http://www.w3.org/…”
>


<rdf:Description about=
“”
>


<Shape>
nested
</Shape>


<ConvertsTo


resource=“http://addr.flat.com”
/>


</rdf:Description>


</rdf:RDF>



<address>


<name>
Me2XML
</name>


<place>


<street>
96 Hyper Road
</street>



<town>
Boston
</town>


</place>


</address>


. . .

</addresses>

http://addr.flat.com

http://addr.nest.com

ConvertsTo

nested

flat

Shape

Shape

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

11

Extensible Markup Language

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

12

General Advantages of XML for KR

(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 offers new general possibilities, from which

AI knowledge representation (KR) can profit:

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

13

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.

Even transformation/compilation of AI source programs
using XML markup and annotations is possible

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

14

Address Example: External to HTML

Xaver M. Linde

Wikingerufer 7

10555 Berlin

<em>
Xaver M. Linde
</em>

<br>

Wikingerufer 7

<br>

<strong>
10555 Berlin
</strong>

External Presentation:

HTML Markup:

HTML tags are still

presentation
-
oriented

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

15

Address Example: HTML to XML

<em>
Xaver M. Linde
</em>

<br>

Wikingerufer 7

<br>

<strong>
10555 Berlin
</strong>

HTML Markup:

XML tags are chosen for

content
-
structuring

needs

<address>


<name>
Xaver M. Linde
</name>


<street>
Wikingerufer 7
</street>



<town>
10555 Berlin
</town>

</address>

XML Markup:

While not conveying

any formal semantics
:

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

16

Address Example: XML to External

<address>


<name>
Xaver M. Linde
</name>


<street>
Wikingerufer 7
</street>



<town>
10555 Berlin
</town>

</address>

XML Markup:

Xaver M. Linde

Wikingerufer 7

10555 Berlin

External Presentations:

XML stylesheets are,

e.g., usable to generate

different

presentations

X
aver
M
.
L
inde

Wikingerufer 7

10555 Berlin

. . .

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

17

<address>


<name>
Xaver M. Linde
</name>


<place>


<street>
Wikingerufer 7
</street>



<town>
10555 Berlin
</town>


</place>

</address>

Address Example: XML to XML

<address>


<name>
Xaver M. Linde
</name>


<street>
Wikingerufer 7
</street>



<town>
10555 Berlin
</town>

</address>

XML Markup 1:

XML Markup 2:

XML stylesheets are

also usable to
transform

XML representations

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

18

Address Example: Some Stylesheets Will
Contain Term
-
(Tree
-
)Rewriting Rules

address

N

S

T

name

street

town

address

name

street

town

place

N

S

T

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

19

<address>


<name>
Xaver M. Linde
</name>


<street>
Wikingerufer 7
</street>



<town>
10555 Berlin
</town>

</address>

WHERE


<address>


<name>
Xaver M. Linde
</name>


<street>
$s
</street>



<town>
$t
</town>


</address>

CONSTRUCT


<binding>


<s>
$s
</s>


<t>
$t
</t>


</binding>

Address Example: XML Queries

XML Markup:

XML Query (XML
-
QL):

XML queries can

select subelements

of XML elements

e
l
e
m
e
n
t

s

subelements


<binding>


<s>
Wikingerufer 7
</s>


<t>
10555 Berlin
</t>


</binding>

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

20

address(


name(
"Xaver M. Linde"
),


street(
"Wikingerufer 7"
),


town(
"10555 Berlin"
)

)

Address Example: Prolog Queries

Prolog Term:

Prolog Query:

Prolog queries can

select substructures

of Prolog structures

S

= "Wikingerufer 7"

T

= "10555 Berlin"

s
t
r
u
c
t
u
r
e

s

substructures

address(


name(
"Xaver M. Linde"
),


street(
S
),


town(
T
)

)

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

21

Address Example: The Element Tree

address(


name(
"Xaver M. Linde"
),


street(
"Wikingerufer 7"
),


town(
"10555 Berlin"
)

)

Prolog Term:

s
t
r
u
c
t
u
r
e

s

substructures

<address>


<name>
Xaver M. Linde
</name>


<street>
Wikingerufer 7
</street>



<town>
10555 Berlin
</town>

</address>

XML Markup:

e
l
e
m
e
n
t

s

subelements

Node
-
Labeled, (Left
-
to
-
Right
-
)Ordered Element Tree:

address

Xaver M. Linde

Wikingerufer 7

10555 Berlin

name

street

town

s
u
b
t
r
e
e
s

tree

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

22

Address Example:

Document Type Definition and Tree (1)

<!ELEMENT
address

(
name
,
street
,
town
) >

<!ELEMENT
name

(#
PCDATA
) >

<!ELEMENT
street

(#
PCDATA
) >

<!ELEMENT
town

(#
PCDATA
) >

Document Type Definition (DTD):

Document Type Tree:

address

PCDATA

PCDATA

PCDATA

name

street

town

address
::=

name

street

town

name
::=


PCDATA

street
::=


PCDATA

town
::=


PCDATA

Extended Backus
-
Naur Form (EBNF):

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

23

Address Example:

Document Type Definition and Tree (2)

Document Type Tree:

<!ELEMENT
address

(
name
,
place
) >

<!ELEMENT
place

(
street
,
town
) >

<!ELEMENT
name

(#
PCDATA
) >

<!ELEMENT
street

(#
PCDATA
) >

<!ELEMENT
town

(#
PCDATA
) >

Document Type Definition (DTD):

address

PCDATA

PCDATA

PCDATA

name

street

town

place

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

24

Well
-
Formedness and Validity


Open and close all tags


Empty tags end with />


There is a unique root
element


Elements may not overlap


Attribute values are quoted


< 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 principles for a
document being
well
-
formed
:

XML principle for
a document being
valid

with respect to (w.r.t.) a DTD

:

Checked by

validators

such as
http://www.stg.brown.edu/s
ervice/xmlvalid/

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

25

Mail
-
Box Example: Address Variant

Node
-
Labeled, (Left
-
to
-
Right
-
)Ordered Element Tree:

address(


name(
"Xaver M. Linde"
),


box(
"2001"
),


town(
"10555 Berlin"
)

)

Prolog Term:

<address>


<name>
Xaver M. Linde
</name>


<box>
2001
</box>



<town>
10555 Berlin
</town>

</address>

XML Markup:

address

Xaver M. Linde

2001

10555 Berlin

name

box

town

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

26

"|"
-
Disjoined Street/Mail
-
Box Example:

Document Type Definition and Tree

Document Type Tree:

<!ELEMENT
address

(
name
, (
street
|
box
),
town
) >

<!ELEMENT
name

(#
PCDATA
) >

<!ELEMENT
street

(#
PCDATA
) >

<!ELEMENT
box

(#
PCDATA
) >

<!ELEMENT
town

(#
PCDATA
) >

Document Type Definition (DTD):

address

PCDATA

PCDATA

PCDATA

name

street

town

PCDATA

box

"|": Choice

The above box address
and the original street

address are valid w.r.t.

this "|"
-
DTD

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

27

Phone & Fax Example: Address Variant

Node
-
Labeled, (Left
-
to
-
Right
-
)Ordered Element Tree:

address(


name(
"Xaver M. Linde"
),


street(
"Wikingerufer 7"
),


town(
"10555 Berlin"
),


phone(
"030/1234567"
),


phone(
"030/1234568"
),


fax(
"030/1234569"
)

)

Prolog Term:

<address>


<name>
Xaver M. Linde
</name>


<street>
Wikingerufer 7
</street>



<town>
10555 Berlin
</town>


<phone>
030/1234567
</phone>


<phone>
030/1234568
</phone>


<fax>
030/1234569
</fax>

</address>

XML Markup:

address

Xaver M. Linde

Wikingerufer 7

10555 Berlin

name

street

town

030/1234567

030/1234569

030/1234568

phone

phone

fax

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

28

"+"/"*"
-
Repetitive
-
Phone &
-
Fax Example:

Document Type Definition and Tree

Document Type Tree:

<!ELEMENT
address

(
name
,
street
,
town
,

phone
+,
fax
*) >

<!ELEMENT
name

(#
PCDATA
) >

<!ELEMENT
street

(#
PCDATA
) >

<!ELEMENT
town

(#
PCDATA
) >

<!ELEMENT
phone

(#
PCDATA
) >

<!ELEMENT
fax


(#
PCDATA
) >

Document Type Definition (DTD):

address

PCDATA

PCDATA

PCDATA

name

street

town

PCDATA

phone

PCDATA

fax

"+"/"*": 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!)


20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

29

Country Example: Address Variant

Node
-
Labeled, (Left
-
to
-
Right
-
)Ordered Element Tree:

address(


name(
"Xaver M. Linde"
),


street(
"Wikingerufer 7"
),


town(
"10555 Berlin"
),


country(
"Germany"
)

)

<address>


<name>
Xaver M. Linde
</name>


<street>
Wikingerufer 7
</street>



<town>
10555 Berlin
</town>


<country>
Germany
</country>

</address>

XML Markup:

address

Xaver M. Linde

Wikingerufer 7

10555 Berlin

name

street

town

Germany

country

Prolog Term:

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

30

"?"
-
Optional
-
Country Example:

Document Type Definition and Tree

Document Type Tree:

<!ELEMENT
address

(
name
,
street
,
town
,
country
?) >

<!ELEMENT
name

(#
PCDATA
) >

<!ELEMENT
street

(#
PCDATA
) >

<!ELEMENT
town

(#
PCDATA
) >

<!ELEMENT
country

(#
PCDATA
) >

Document Type Definition (DTD):

address

PCDATA

PCDATA

PCDATA

name

street

town

PCDATA

country

"?": One or Zero

The above country
address and the
original countriless

address are valid w.r.t.

this "?"
-
DTD

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

31

Country Address: A Complete XML
Document Referring to an External DTD

<?xml version="1.0" standalone="no"?>

<!DOCTYPE address SYSTEM "country
-
address.dtd">

<address>


<name>Xaver M. Linde</name>


<street>Wikingerufer 7</street>


<town>10555 Berlin</town>


<country>Germany</country>

</address>

XML Document (just ASCII, e.g. stored in a file):

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
-
address.dtd")

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

32

Horn Logic Markup Languages

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

33

Herbrand Terms: Individual Constants,

Variables, Flat Ground Structures, ...


Individual constant

for channel
-
tunnel between Britain and
France: element
<ind>
channel
-
tunnel
</ind>



Ground structure


undersea
-
connection(britain,france)


is
<struc>
element with embedded element for constructor,
followed by elements for argument terms:

Representation of Herbrand terms in XML as

<ind>

and

<struc>

elements (
<var>
similar):

<struc>


<constructor>
undersea
-
connection
</constructor>


<ind>
britain
</ind>


<ind>
france
</ind>

</struc>

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

34

Herbrand Terms: ...,

Nested Ground Structures

service
-
tunnel(


undersea
-
connection(


britain,


surrounded
-
country(


belgium,


luxembourg,


germany,


switzerland,


italy,


spain)))

<struc>


<constructor>
service
-
tunnel
</constructor>


<struc>


<constructor>
undersea
-
connection
</constructor>


<ind>
britain
</ind>


<struc>


<constructor>
surrounded
-
country
</constructor>


<ind>
belgium
</ind>


<ind>
luxembourg
</ind>


<ind>
germany
</ind>


<ind>
switzerland
</ind>


<ind>
italy
</ind>


<ind>
spain
</ind>


</struc>


</struc>

</struc>

Embedded
<struc>

elements:

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

35

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”

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

36

Horn Clauses: Relation Symbol
Applications

Predicate or
relation symbol

in XML is
<relator>

element.

For example, relation symbol travel is

<relator>
travel
</relator>


Relation symbol application to terms

is labeled with

<relationship>

element.

Application travel(john,channel
-
tunnel)

on two individual constants thus is


<relationship>


<relator>
travel
</relator>


<ind>
john
</ind>


<ind>
channel
-
tunnel
</ind>

</relationship>

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

37

Horn Clauses: Facts

Hence, Horn fact can be asserted as
<hn>

element that
possesses
<relationship>

elements as subelements


In the example, the Prolog fact


travel(john,channel
-
tunnel).


becomes


<hn>


<relationship>


<relator>
travel
</relator>


<ind>
john
</ind>


<ind>
channel
-
tunnel
</ind>


</relationship>

</hn>

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

38

Horn Clauses: Rules

Then, Horn rule is asserted as
<hn>

Element

that has a

head
<relationship>

element followed by at least one

body
<relationship>

element

So, above example generalized to Prolog rule


travel(Someone,channel
-
tunnel) :
-

carry(eurostar,Someone).


<hn>


<relationship>


<relator>
travel
</relator>


<var>
someone
</var>


<ind>
channel
-
tunnel
</ind>


</relationship>


<relationship>


<relator>
carry
</relator>


<ind>
eurostar
</ind>


<var>
someone
</var>


</relationship>

</hn>

and rewritten as

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

39

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
-
Tag is ‘attributed’ with
n

attribute
-
value pairs
a
i
=
v
i

Element:
<
tag

a
1
=
v
1

...
a
n
=
v
n
>

. . .
</
tag
>



Helpful Prolog uses of XML attributes are arity labelings of

relation symbols such as our binary relation symbol travel:

Prolog’s travel/2 in XML with an arity attribute becomes

<relator

arity="2"
>
travel
</relator>


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

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

40

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)
:


<hn

id="john
-
channel"
>


<relationship>


<relator>
travel
</relator>


<ind>
john
</ind>


<ind>
channel
-
tunnel
</ind>


</relationship>

</hn>

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

41

Now a “modal Prolog fact”


belief(mary,travel(john,channel
-
tunnel)).


can access the "john
-
channel" assertion:


<hn>


<relationship>


<relator>
belief
</relator>


<ind>
mary
</ind>


<prop

idref="john
-
channel"
/>


</relationship>

</hn>


Propositional argument of the belief operator written as
<prop

idref="john
-
channel"
/>

(XML abbreviation of
empty elements
<
tag

...
>

</
tag
>

to
<
tag

...
/>
)


Also disbelief fact has "john
-
channel" access with
idref: ID/IDREF “break out of the tree” and enable
‘sharing’

ID and
IDREF

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

42

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

DTDs: Elements as Derivation Trees

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

43

Syntactic ELEMENT declaration of Horn logic as a
knowledge base (kb) of zero or more Horn clauses (hn*):


<!ELEMENT kb





(hn*) >


<!ELEMENT hn





(relationship, relationship*) >


<!ELEMENT relationship

(relator, (ind | var | struc)*) >


<!ELEMENT struc




(constructor, (ind | var | struc)*) >


<!ELEMENT relator



(#PCDATA) >


<!ELEMENT constructor

(#PCDATA) >


<!ELEMENT ind





(#PCDATA) >


<!ELEMENT var





(#PCDATA) >

DTDs: Defining Horn Logic in XML

Note

struc

recursion!

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

44

(Start
-
)symbol kb brackets derived clause(s) as linearized

start
-
tag/end
-
tag
-
tree representation
<kb>

. . .
</kb>
:


kb


<kb>

hn*
</kb>

. . .

<kb> <hn>

relationship relationship
</hn> </kb>

. . .

<kb>


<hn>


<relationship>


<relator>
#PCDATA
</relator> <var>
#PCDATA
</var> <ind>
#PCDATA
</ind>


</relationship>


<relationship>


<relator>
#PCDATA
</relator> <ind>
#PCDATA
</ind> <var>
#PCDATA
</var>


</relationship>


</hn>

</kb>

DTDs:

Generation of the Example Rule (1)

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

45

<kb>


<hn>


<relationship>


<relator>
travel
</relator>


<var>
someone
</var>


<ind>
channel
-
tunnel
</ind>


</relationship>


<relationship>


<relator>
carry
</relator>


<ind>
eurostar
</ind>


<var>
someone
</var>


</relationship>


</hn>

</kb>

DTDs:

Generation of the Example Rule (2)

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

46

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):


<!ATTLIST relator arity CDATA #IMPLIED >


2nd Example (Preparation):

define the extended Horn logic
with (named hn clauses and) embedded propositions:


<!ELEMENT relationship

(relator, (ind|var|struc|prop)*) >


<!ELEMENT prop EMPTY >

Attribute DTDs (1)

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

47

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:


<!ATTLIST hn



id



ID



#IMPLIED >


<!ATTLIST prop


idref

IDREF

#REQUIRED >


With entire DTD now, e.g., earlier "john
-
channel"
-
named fact and
its accessing facts can be generated

Attribute DTDs (2)

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

48

Assume fact:


<hn>


<relationship>


<relator>
carry
</relator>


<ind>
eurostar
</ind>





carry(eurostar,fred).


<ind>
fred
</ind>


</relationship>

</hn>


A Horn
-
logic interpreter can use it to answer this query:


<relationship>


<relator>
carry
</relator>


<ind>
eurostar
</ind>






carry(eurostar,Someone)


<var>
someone
</var>

</relationship>


by binding


<var>
someone
</var>






Someone


to

<ind>
fred
</ind>








fred


Horn Queries in XML Notation

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

49

Assume the fact is extended by prem(ises)/arity/pos(ition) attributes:


<hn
prem='0'
>


<relationship
arity='2'
>


<relator>
carry
</relator>


<ind
pos='1'
>
eurostar
</ind>


<ind
pos='2'
>
fred
</ind>


</relationship>

</hn>


Then in XML
-
QL the query can be implemented like this:


WHERE


<hn
prem='0'
>


<relationship
arity='2'
>


<relator>
carry
</relator>


<ind
pos='1'
>
eurostar
</ind>


<ind
pos='2'
>
$someone
</ind>


</relationship>


</hn>

CONSTRUCT


<binding>

<someone>
$someone
</someone>

</binding>

Horn Queries in XML
-
QL Implementation

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

50

With carry basis fact



















carry(eurostar,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

Horn Inferences in XML Notation (1)

Someone=fred


Where=channel
-
tunnel


Where=channel
-
tunnel

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

51

Rule:

<hn>


<relationship>


<relator>
travel
</relator>


<var>
someone
</var>


<ind>
channel
-
tunnel
</ind>


</relationship>


<relationship>


<relator>
carry
</relator>


<ind>
eurostar
</ind>


<var>
someone
</var>


</relationship>

</hn>

Horn Inferences in XML Notation (2)

<relationship>


<relator>
travel
</relator>


<ind>
fred
</ind>


<var>
where
</var>

</relationship>

<relationship
someone="fred"

where="channel
-
tunnel"
>


<relator>
carry
</relator>


<ind>
eurostar
</ind>


<var>
someone
</var>

</relationship>


<ind
where="channel
-
tunnel"
>


true

</ind>


Fact:

<hn>


<relationship>


<relator>
carry
</relator>


<ind>
eurostar
</ind>


<ind>
fred
</ind>


</relationship>

</hn>

3
-
Step Animation:

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

52

Rule:

<hn>


<relationship>


<relator>
travel
</relator>


<var>
someone
</var>


<ind>
channel
-
tunnel
</ind>


</relationship>


<relationship>


<relator>
carry
</relator>


<ind>
eurostar
</ind>


<var>
someone
</var>


</relationship>

</hn>

Horn Inferences in XML Notation (2)

<relationship>


<relator>
travel
</relator>


<ind>
fred
</ind>


<var>
where
</var>

</relationship>

Fact:

<hn>


<relationship>


<relator>
carry
</relator>


<ind>
eurostar
</ind>


<ind>
fred
</ind>


</relationship>

</hn>

3
-
Step Animation:

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

53

Rule:

<hn>


<relationship>


<relator>
travel
</relator>


<var>
someone
</var>


<ind>
channel
-
tunnel
</ind>


</relationship>


<relationship>


<relator>
carry
</relator>


<ind>
eurostar
</ind>


<var>
someone
</var>


</relationship>

</hn>

Horn Inferences in XML Notation (2)

Fact:

<hn>


<relationship>


<relator>
carry
</relator>


<ind>
eurostar
</ind>


<ind>
fred
</ind>


</relationship>

</hn>

3
-
Step Animation:

<relationship
someone="fred"

where="channel
-
tunnel"
>


<relator>
carry
</relator>


<ind>
eurostar
</ind>


<var>
someone
</var>

</relationship>

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

54

Rule:

<hn>


<relationship>


<relator>
travel
</relator>


<var>
someone
</var>


<ind>
channel
-
tunnel
</ind>


</relationship>


<relationship>


<relator>
carry
</relator>


<ind>
eurostar
</ind>


<var>
someone
</var>


</relationship>

</hn>

Horn Inferences in XML Notation (2)

Fact:

<hn>


<relationship>


<relator>
carry
</relator>


<ind>
eurostar
</ind>


<ind>
fred
</ind>


</relationship>

</hn>

3
-
Step Animation:


<ind
where="channel
-
tunnel"
>


true

</ind>


20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

55

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

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

56

Model
-
Theoretic Semantics

Modeling formal
XML elements by
constructing sets of
logically derivable
XML elements

Practical need for
Web semantics:

Corresponding
semantic techniques:

Model
-
theoretic
semantics explicates
rule consequences by
generating Herbrand
models for XML
knowledge bases of
relations and functions

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

57

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

% start fact base for collocated


collocated(


name(
"Me2XML"
),


name(
"XML4You"
)


).


% end fact base for collocated

The
Herbrand model

of

the rule and addresses

is the set of the
collocated

and
address

ground facts

<collocateds>


<collocated>


<name>
Me2XML
</name>


<name>
XML4You
</name>


</collocated>

</collocateds>

% start rule base for collocated


collocated(
N1
,
N2
)
:
-


address(
N1
,
P
),


address(
N2
,
P
),


lexiless(
N1
,
N2
).

% end rule base for collocated

Horn rule

<kb>


<hn>


<relationship>


<relator>collocated</relator>


<var>
N1
</var>


<var>
N2
</var>


</relationship>


. . .


</hn>

</kb>

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

58

The Rule Markup Language

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

59


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

Agenda

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

60



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


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



RuleML


20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

61

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


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


20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

62

Modular Syntax & Semantics of RuleML

RuleML hierarchy top
-
level:

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

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

63

Modular Syntax & Semantics of RuleML
(Cont

d)

urc
-
bin
-
data
-
ground
-
fact

urc
-
bin
-
data
-
ground
-
log

urc
-
bin
-
datalog

bin
-
datalog

urc
-
datalog

ur
-
datalog

ur
-
hornlog

ur
-
equalog

hornlog

equalog

datalog

ur

Rooted DAG will be extended with

branches for further sublanguages

URL/URI
-
like

‘ur’
-
objects

derivation rules

RDF
-

like triples

ur
-
datalog =
join(ur,datalog)


Sublanguage

hierarchy:

RDF Rules

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

64

Modular Syntax & Semantics of RuleML
(Cont

d)

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

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 DAML+OIL lists are used

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

65

RuleML DTDs: release 0.8

<fact>


<_head>


<atom>


<_opr><rel href="http://www.eeebizz.com/rdf
-
sch#Approval"/></_opr>


<ind href="http://www.eeebico.org/docs/joint
-
mission.html"/>


<ind>full</ind>


</atom>


</_head>

</fact>

RDF
-
like triple:

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)

roles

Concrete markup:

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

66

Negation Handling in RuleML

IF

isPresent(?someCar)


AND

NOT

isAssignedToRentalOrder(?someCar
)


AND

NOT

requiresService(?someCar)


AND



THEN

isAvailable(?someCar)

The Closed
-
World Negation
NOT

UML
Diagram:

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

67

Negation Handling in RuleML (Cont

d)

<_body>


<and>


<atom>


<_opr><rel>
isPresent
</rel></_opr>


<var>Car</var>


</atom>


<
not
>


<atom>


<_opr><rel>
isAssignedToRentalOrder
</rel></_opr>


<var>Car</var>



</atom>


<
/not
>


. . .


</and>

</_body>


NOT

in RuleML: an example

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

68

Negation Handling in RuleML (Cont

d)


NOT

=
non
-
truth (or failure)


NEG

= falsity





Default rules:



IF

NOT

hasApproval(?URL)


THEN

NEG

isOfficialDocument(?URL)

Open
-
World Reasoning with

NOT

and

NEG

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

69

Priorities/Evidences in RuleML



Quantitative Priorities:


Static numerical salience


Dynamically calculated priorities



Qualitative Priorities

Using the
Overrides

Fact

over rule labels

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

70

Priorities/Evidences in RuleML (Cont

d)

<imp>


<_rlab><ind>beginners</ind></_rlab>


<_spriority><ind>
0.75
</ind></_spriority>



<_head> ....... </_head>


<_body>


<atom>



<_opr><rel>customerUnder25</rel></_opr>



<var>customer</var>


</atom>


</_body>

</imp>


Static Salience Example:

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

71

Priorities/Evidences in RuleML (Cont

d)

Dynamic Salience Example:

<imp>


<_rlab><ind>beginners</ind></_rlab>


<_dpriority><rel>calculateSalience</rel></_dpriority>



<_head> ....... </_head>


<_body>


<atom>



<_opr><rel>customerUnder25</rel></_opr>



<var>customer</var>


</atom>


</_body>

</imp>


20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

72

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
-
output environment for RuleML
(0.8)

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

73

A Semantic Web Scenario in Insurance

A teenager after her first car accident:


how much will my premiums increase and how does this
accident affect my insurance policy?


Principle: Uniform RuleML representation of
derivation

rule
s and

underlying
document

metadata


20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

74

<imp>


<_rlab><ind>
beginners
</ind></_rlab>


<_spriority><ind>0.75</ind></_spriority>




<_head>



<atom>




<_opr><rel>calculatePremium</rel></_opr>




<var>customer</var> <ind>40</ind>




</atom>



</_head>



<_body><and>




<atom>




<_opr><rel>InsurancePolicy</rel></_opr>





<var>customer</var><var>insurance</var>





</atom>




<atom>




<_opr><rel>lifeEvent</rel></_opr>




<var>customer</var><ind>accident</ind><var>report</var>





</atom>




<atom>




<_opr><rel>customerUnder25</rel></_opr>






<var>customer</var>





</atom></and>


</_body>

</imp>

A Semantic Web Scenario in Insurance
(Cont

d)

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

75

A Semantic Web Scenario in Insurance
(Cont

d)

<imp>


<_rlab><ind>
family
</ind></_rlab>


<_spriority><ind>0.9</ind></_spriority>




<_head>



<atom>




<_opr><rel>calculatePremium</rel></_opr>




<var>customer</var><ind>0</ind>




</atom>



</_head>



<_body><and>




<atom>




<_opr><rel>InsurancePolicy</rel></_opr>




<var>customer</var><var>insurance</var>




</atom>




<atom>




<_opr><rel>lifeEvent</rel></_opr>




<var>customer</var><ind>accident</ind><var>report</var>





</atom>




<atom>




<_opr><rel>FamilyAutoPlan</rel></_opr>






<var>customer</var><
var>familyauto</var>





</atom></and>


</_body>

</imp>

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

76

A Semantic Web Scenario in Insurance
(Cont

d)

Formalizing the relevant facts


Olivia is under 25


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
:


Olivia's accident report is available at TrafficReport.biz

:

<fact>


<_head>



<atom>




<_opr> <rel>FamilyAutoPlan</rel></_opr>




<ind>Olivia</ind>




<ind href = “
http://www.BostonInsurance.com/policy/FMA
-
0142”

/>



</atom>


</_head>

</fact>

<fact>


<_head>



<atom>




<_opr><rel>LifeEvent</rel></_opr>




<ind>Olivia</ind>




<ind>accident</ind>




<ind href = “
http://www.TrafficReport.biz/MA/report0712”

/>



</atom>


</_head>

</fact>

<fact>


<_head>



<atom>




<_opr><rel>InsurancePolicy</rel></_opr>




<ind>Olivia</ind>




<ind href = “
http://www.BostonInsurance.com/policy/IMA
-
0835”

/>



</atom>


</_head>

</fact>

<fact>


<_head>



<atom>




<_opr><rel>customerUnder25</rel></_opr>




<ind>Olivia</ind>



</atom>


</_head>

</fact>


20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

77

A Semantic Web Scenario in Insurance
(Cont

d)

Conflict Resolution: using Meta facts (a la BRML)

<imp>


<_rlab>



<ind>
beginners
</ind>


</_rlab>


. . .

</imp>

<imp>


<_rlab>



<ind>
family
</ind>


</_rlab>


. . .

</imp>

<fact>


<_head>



<atom>




<_opr><rel>
Overrides
</rel></_opr>




<ind>
family
</ind>




<ind>
beginners
</ind>



</atom>


</_head>

</fact>


20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

78

A Semantic Web Scenario in Insurance
(Cont

d)

Conflict Resolution: using Meta facts (a la BRML)

<imp>


<_rlab>



<ind>
beginners
</ind>


</_rlab>


. . .

</imp>

<imp>


<_rlab>



<ind>
family
</ind>


</_rlab>


. . .

</imp>

<fact>


<_head>



<atom>




<_opr><rel>
Overrides
</rel></_opr>




<ind>
family
</ind>




<ind>
beginners
</ind>



</atom>


</_head>

</fact>


20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

79

RuleML Conclusions


RuleML rulebases embedded in, or referring to, XML and RDF

documents. Using RuleML in other XML namespaces (like for, say,
MathML), incl. RDF(S) namespaces (
ruleml:

namespace prefix)



RuleML rule premises could be DAML+OIL concept descriptions

or 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 effort

as part of W3C Ontology Working Group

Ontologies: The big Picture and future RuleML Versions

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

80

Simple HTML/XML Ontology Extensions

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

81

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


Relationship 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

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

82

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/


channel
-
tunnel


=

http://www.eurotunnel.com/

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

83

A SHOE Rule

With these URLs/URIs, the rule in SHOE becomes



<DEF
-
INFERENCE


DESCRIPTION="travel(?someone,http://www.eurotunnel.com/) if


carry(http://www.eurostar.com/,?someone)">


<INF
-
IF>


<RELATION NAME="carry">


<ARG POS="1" VALUE="http://www.eurostar.com/">


<ARG POS="2" VALUE="someone" USAGE="VAR">


</RELATION>


</INF
-
IF>


<INF
-
THEN>


<RELATION NAME="travel">


<ARG POS="1" VALUE="someone" USAGE="VAR">


<ARG POS="2" VALUE="http://www.eurotunnel.com/">


</RELATION>


</INF
-
THEN>

</DEF
-
INFERENCE>

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

84

XML Namespaces

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

85

XML Namespaces and
Programming
-
Language Modules


XML namespaces are akin to namespaces,
packages, and modules in programming languages


Disambiguation of tag

and attribute

names from
different XML applications (“spaces”) through
different prefixes


A
prefix

is separated from the local
name

by a “:”,
obtaining
prefix
:
name

tags


Namespaces constitute a layer on top of XML 1.0,
since
prefix
:
name

is again a valid tag name and
namespace bindings are ignored by some tools

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

86

Namespace Bindings


Prefixes are bound to namespace URIs by attaching
an xmlns:
prefix

attribute to the prefixed element or
one of its ancestors,
prefix
:
name
1
,...,

prefix
:
name
n


The value of the xmlns:
prefix

attribute is a URI,
which may or (unlike for DTDs!) may not point to a
description of the namespace’s syntax


An element can use bindings for multiple name
-
spaces via attributes xmlns:
prefix
1
,...,

xmlns:
prefix
m

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

87

Namespaceless Example:

Address Variant

<address>


<name>
Xaver M. Linde
</name>


<street>
Wikingerufer 7
</street>



<town>
10555 Berlin
</town>


<bill>
12.50
</bill>


<phone>
030/1234567
</phone>


<phone>
030/1234568
</phone>


<fax>
030/1234569
</fax>


<bill>
76.20
</bill>

</ address>

Namespaceless XML Markup:

bill

is ambiguous
tag (name clash
from two XML
applications)

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

88

Two
-
Namespace Example:
Snail
-
Mail and Telecoms Address Parts

<
mail
:
address
xmlns:
mail
="http://www.deutschepost.de/"


xmlns:
tele
="http://www.telekom.de/"
>


<
mail
:
name>
Xaver M. Linde
</
mail
:
name>


<
mail
:
street>
Wikingerufer 7
</
mail
:
street>



<
mail
:
town>
10555 Berlin
</
mail
:
town>


<
mail
:
bill>
12.50
</
mail
:
bill>


<
tele
:
phone>
030/1234567
</
tele
:
phone>


<
tele
:
phone>
030/1234568
</
tele
:
phone>


<
tele
:
fax>
030/1234569
</
tele
:
fax>


<
tele
:
bill>
76.20
</
tele
:
bill>

</
mail
:
address>

Namespace XML Markup:


The root element,
mail
:
address
, as well as the children
mail
:
name
,

mail
:
street
,
mail
:
town
,

and
mail
:
bill
, use the
mail

prefix, bound to a deutschepost URI


The
tele
:
phone
,

tele
:
fax
,

and

tele
:
bill
children use the
tele

prefix, bound to a telekom
URI

bill

disambiguation
through
mail
and
tele

prefixes


20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

89

Acquiring and Processing

Knowledge Markups

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

90

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

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

91

Acquiring XML Knowledge Bases

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

92

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 RDF[S]
and OIL
editor)

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

93

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, RDF[S],
OIL, DAML+OIL
...)

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

94

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
-
representation 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

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

95

XML Import Strategy


tag/element names become class names, except
“leaves” which become slots


example:


<Customer>


<Name>



<FirstName>Bill</FirstName>



<LastName>Buckram</LastName>


</Name>


<Cardnum>234 ...</Cardnum>

</Customer>


20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

96

Example (Import):

Book Order

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

97

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)

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

98

Example (Export):

Newspaper Instances

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

99

Example: Newspaper Ontology As XML
Tree

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

100

Processing XML

20
-
Aug
-
01

IJCAI
-
01 Knowledge Markup and Resource Semantics

101

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:

<?xml
-
stylesheet type=
"
text/css
"

href=
"
poem