Semantic Web Techniques - Lecture Notes - Harold Boley Bruce Spencer NRC-IIT Fredericton University of New Brunswick CS 6905 SWT 17 September 2003

Semantic Web Techniques- Lecture Notes -

Harold BoleyBruce SpencerNRC-IIT Fredericton University of New Brunswick

CS 6905 SWT

17 September 2003

17-Sep-03CS6905 Semantic Web Techniques2

Introduction to the Semantic Web


National Research Council

Research Institutes and Facilities across Canada17 research institutes

4 innovation centres

3,500 employees; 1,000 guest workers

National science facilities

S&T information for industry and scientific communityCISTI: Canadian Inst. for Science and Tech

InformationNetwork of technology advisors supporting SME

IRAP: Industrial Research Assistance Program


Institute for Information Technology

There are two aspects to IIT– A mature research organization of ~80 people in Ottawa– New labs being developed in four cities in New

Brunswick and Nova Scotia involving ~60 new people

The whole organization is evolving to accommodate our new distributed nature


NRC’s plans for New Brunswick

What?– NRC is building an e-business research team in New Brunswick– E-business includes e-learning, e-government, e-health.

Using information and communication technology to help us to educate, govern and take care of ourselves, to create wealth.

– New Brunswick and Canadian companies already have strengths in all three areas

– NB’s communications infrastructure and interested telco– Bilingual workforce


Bruce

MMath 83, BNR 83-86, Waterloo PhD 86-90, UNB prof 90-01, NRC 01-now

Automated reasoning– data structures in theorem proving– eliminate redundant searching– smallest proofs– deductive databases

Java in curriculum since 1997


Harold

Harold joined NRC-IIT Fredericton as a research officer in Sept. 2002. Before that, he was a senior researcher at the German Research Center for Artificial Intelligence (DFKI), where he acted as the W3C Advisory Committee Representative and led the EU project Clockwork on Web-based knowledge management for collaborative engineering. He also was a senior lecturer of computer science and mathematics at the University of Kaiserslautern, where he conceived AI-oriented XML and RDF courses. His focus has been XML-based knowledge markup and RDF-based Semantic Web techniques. He was a visiting researcher in the Knowledge Modeling Group at Stanford University in 1999. Before that, he led several government and industrial projects in knowledge representation, compilation, and evolution. He received his PhD and Habilitation degrees in computer science from the Universities of Hamburg and Kaiserslautern, respectively. He developed the Relational-Functional Markup Language (RFML) and, together with Said Tabet, launched the Rule Markup Initiative (RuleML).


Overview and Course 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

Course 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

RACSA


The Semantic Web Activityof the W3C

“The Semantic Web is a vision: the idea of havingdata on the Web defined and linked in a way thatit 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)


What your computer sees in HTML

Joe’s Computer Store



 

365 Yearly Drive

What your computer sees in XML<location><name>Joe’s Computer Store</name><address> 365 Yearly Drive</address></location>

Presentation information

Content description

(less ambiguous)


What a computer could understand

<mail:address xmlns:mail=“http://www.canadapost.ca”>

<mail:name>Joe’s Computer Store </mail:name>

<mail:street> 365 Yearly Drive </mail:street>

</mail:address>

www.canadapost.ca could define address, name, street, …Search engines could then identify mail addressesConsider shopbots being able to find

– price, quantity, feature, model number, supplier, serial number, acquisition date

Assumes that namespaces will be used consistently


Semantic Web

Semantics = meaningGood Idea: Dictionary

– Create a dictionary of terms– Put it on the web– Mark up web pages so that terms are linked to these

dictionary-entries– This allow more precise matching

Better idea: Thesaurus – has hierarchies of terms– shades of meaning

Best idea: Ontology – hierarchy of terms and logic conditions


Semantic Web

An agent-enabled resource“information in machine-readable form, creating a

revolution in new applications, environments and B2B commerce”

W3C Activity launched Feb 9, 2001DAML: DARPA Agent Markup Language

– US Gov funding to define languages, tools– 16 project teams

OIL is Ontology Inference Layer– DAML+OIL is joint DARPA-EU

Knowledge Representation is a natural choice



•SmokedSalmon is the intersection of Smoked and Salmon

Smoked Salmon


•Gravalax is the intersection of Cured and Salmon, but not Smoked


Smoked Salmon

Gravalax


•Lox is Smoked, Cured Salmon



Smoked Salmon

Gravalax

Lox


A search for keywords Salmon and Cured should return pages that mention Gravalax, even if they don’t mention Salmon and Cured

A search for Salmon and Smoked will return smoked salmon, should also return Lox, but not Gravalax

Smoked Salmon

LoxGravalax

The Semantic Web is about having the Internet use common sense.


OWL

Smoked Salmon

LoxGravalax


Tim Berners- Lee’s Semantic Web


RDF Resource Description Framework

Beginning of Knowledge Representation influence on Web

Akin to Frames, Entity/Relationship diagrams, or Object/Attribute/Value triples


RDF Example

<rdf:ProductSpecs about=

“http://www.lemoncomputers.ca/model_2300”>

<specs:colour>yellow</specs:colour>

<specs:size>medium</specs:size>

</rdf:ProductSpecs>

model_2300

size

medium

colour

yellow


RDF Class Hierarchy

All lemon laptops get packed in cardboard boxes

Allows one to customize existing taxonomies– Example: palmtop

computers still get packed in boxes

lemon_palmtop_20000

is_a

model_2300

size

medium

colour

yellow




Ontology Web Language: W3C

Previously known as DAML+OIL – US: DARPA Agent Markup Language – EU: Ontology Interchange Layer (Language)

Composed of a hierarchy with additional conditions

Based on Description logic, limited expressivenss– Reasoning procedures are well-behaved– Just enough power


Identifying Resources

URL/URI– Uniform resource locator / identifier– Information sources, goods and services– financial instruments

money, options, investments, stocks, etc.

“Where do you want to go today?” – becomes “What do you want to find?”


Ontology

Branch of philosophy dealing with the theory of being Tarski’s assumption:

– individuals, relationships and functions “A common vocabulary and agreed-upon meanings to

describe a subject domain”– What real-world objects do my tags refer to? – How are these objects related?

Communication requires shared terms– others can join in


Ontology Layer

Widens interoperability and interconversion– knowledge representation

More meta-information– Which attributes are transitive, symmetric– Which relations between individuals are 1-1,

1-many, many-many

Communities exist– DL, OIL, SHOE (Hendler)– New W3C working group


Transitive, Subrole example

One wants to ask about modes of transportation from Sydney to Fredericton

“connected by Acadian Lines bus” is a role in a Nova Scotia taxonomy

“connected by SMT bus” from New Brunswick Both are subroles of “connected” “connected” is transitive Note that ontologies can be combined at runtime


Combining Rich Ontologies

Only these facts are explicit– in separate ontologies

“Connected by bus” – is superset– is symmetric and

transitive

Route from Sydney to Fredericton is inferred

Connected by Acadian Lines

Connected by Acadian Lines

Sydney

Truro

Amherst

Fredericton

Connected by SMT Lines

Sussex

Connected by SMT Lines

Amherst




Logic Layer

Clausal logic encoded in XML– RuleML, IBM CommonRules

Special cases of first-order logic– Horn Clauses for if-then type reasoning and integrity

constraintsStandard inference rules based on Resolution

– Various implementations: SQL, KIF, SLD (Prolog), XSB– J-DREW reasoning tools in Java.

Modus operandi: build tractable reasoning systems– trade away expressiveness, gain efficiency


Logic Architecture Example

Contracting parties integrate e-businesses via rules

BusinessRules

BusinessRules

OPS5Prolog

Contract Rules Interchange

Seller E-Storefront Buyer’s ShopBot


Negotiation via rules

usualPrice:

price(per-unit, ?PO, $60) purchaseOrder(?PO, supplierCo, ?AnyBuyer) shippingDate(?PO, ?D) (?D 24April2001).

volumeDiscountPrice:

price(per-unit, ?PO, $55) purchaseOrder(?PO, supplierCo, ?AnyBuyer) quantityOrdered(?PO, ?Q) (?Q 1000) shippingDate(?PO, ?D) (?D 24April2001).

overrides(volumeDiscount, usualPrice).


Hot Research Topics:

Tools to create ontologies– Ontolingua– Protégé-2000 (Stanford)– OILED– …

Tools to learn ontologies from a large corpus such as corporate data– Merging / aligning two different ontologies from different

sources on the same topic

Searching cum reasoning tools– SHOE


Eventual Goal of these Efforts

Agents locate goods, services– use ontologies– unambiguous– business rules– expressive language but reasoning tractable– combine from various sources

Gives rise to need of trust, privacy and security– e.g. semantic web project to determine eligibility of

patients for a clinical trial


Extensible Markup Language


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 whichAI knowledge representation (KR) can profit:


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


Address Example: External to HTML

Xaver M. LindeWikingerufer 710555 Berlin

Xaver M. Linde Wikingerufer 7 10555 Berlin

External Presentation:

HTML Markup:

HTML tags are stillpresentation-oriented


Address Example: HTML to XML

Xaver M. Linde Wikingerufer 7 10555 Berlin

HTML Markup:

XML tags are chosen forcontent-structuring needs

<address> <name>Xaver M. Linde</name> <street>Wikingerufer 7</street> <town>10555 Berlin</town></address>

XML Markup:

While not conveyingany formal semantics:


Address Example: XML to External


XML Markup:

Xaver M. LindeWikingerufer 710555 Berlin

External Presentations:

XML stylesheets are,e.g., usable to generatedifferent presentations

Xaver M. LindeWikingerufer 710555 Berlin. . .


<address> <name>Xaver M. Linde</name> <place> <street>Wikingerufer 7</street> <town>10555 Berlin</town> </place></address>

Address Example: XML to XML


XML Markup 1:

XML Markup 2:XML stylesheets arealso usable to transformXML representations


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



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 canselect subelementsof XML elements

element

ssubelements

<binding> <s>Wikingerufer 7</s> <t>10555 Berlin</t> </binding>


address( name("Xaver M. Linde"), street("Wikingerufer 7"), town("10555 Berlin"))

Address Example: Prolog Queries

Prolog Term:

Prolog Query:

Prolog queries canselect substructuresof Prolog structures

S = "Wikingerufer 7"T = "10555 Berlin"

structure

ssubstructures

address( name("Xaver M. Linde"), street(S), town(T))


Address Example: The Element Tree

address( name("Xaver M. Linde"), street("Wikingerufer 7"), town("10555 Berlin"))

Prolog Term:structure

ssubstructures<address> <name>Xaver M. Linde</name> <street>Wikingerufer 7</street> <town>10555 Berlin</town></address>

XML Markup:element

ssubelements

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

address

Xaver M. Linde Wikingerufer 7 10555 Berlin

name street townsubtrees

tree


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 townname ::= PCDATAstreet ::= PCDATAtown ::= PCDATA

Extended Backus-Naur Form (EBNF):


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


address

PCDATA

PCDATA PCDATA

name

street town

place


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 byvalidators such as

http://www.stg.brown.edu/service/xmlvalid/


Mail-Box Example: Address Variant


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


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


address


name street town

PCDATA

box

"|": ChoiceThe above box address and the original streetaddress are valid w.r.t.this "|"-DTD


Phone & Fax Example: Address Variant


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


name street town

030/1234567 030/1234569030/1234568

phone phone fax


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


address


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


Country Example: Address Variant


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


name street town

Germany

country

Prolog Term:


"?"-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) >


address


name street town

PCDATA

country

"?": One or ZeroThe above country address and the original countrilessaddress are valid w.r.t.this "?"-DTD


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


Horn Logic Markup Languages


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>


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:


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”


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>


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>


Horn Clauses: Rules

Then, Horn rule is asserted as <hn> Element that has ahead <relationship> element followed by at least onebody <relationship> elementSo, 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


Attributes for Extended Logics

Nested elements - trees - allow representation ofarbitrary information, but in some situations leadto unnecessarily deeply/widely nested representations

Therefore XML attributes:Start-Tag is ‘attributed’ with n attribute-value pairs ai=vi

Element: <tag a1=v1 ... an=vn> . . . </tag>

Helpful Prolog uses of XML attributes are arity labelings ofrelation 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 arbitraryelement levels: mode declarations for logic variables,determinism specifications for clauses or procedures,and context conditions for entire knowledge bases


ID and IDREF

Attribute types ID and IDREF for naming andreferencing of elements

ID-typed value must uniquely identify an elementand IDREF-typed value must occur as ID value ofan 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>


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


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


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!


(Start-)symbol kb brackets derived clause(s) as linearizedstart-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)


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


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)


2nd Example (Execution): Append an ATTLIST declaration that specifies, for the hn respectively prop elements, the attributesid - as optional ID type - respectivelyidref - 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)


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


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


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>


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




<relationship> <relator>travel</relator> <ind>fred</ind> <var>where</var></relationship>


3-Step Animation:





3-Step Animation:

<relationship someone="fred" where="channel-tunnel"> <relator>carry</relator> <ind>eurostar</ind> <var>someone</var></relationship>





3-Step Animation:

<ind where="channel-tunnel"> true</ind>


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 theWeb is assumed, in this “open world” logical completeness,in particular, can hardly still be asked for


The Java Deductive Reasoning Engine for the Web


Train people to build the Rule-based web services

Courses on systems employing rule engines and Internet applications– Writing deduction engines in Java/C/C++ – Interfacing with Internet API– Old techniques (Prolog 30 years ago)– New techniques from CADE System Competition

Meier and Warren’s book: Programming in Logic, 1988– Updated in Java?– Specific to Prolog at low level


Will such a course work?

No – Guts of Prolog, Internet API’s, how to program in logic– At least three courses here

Yes– Students understand recursion– How to build a tree

how to search a spacePropositional theorem prover

– how to interface to Internet


This talk

Architecture for building deduction systems – first order– easily configured

forward or backward– embedded – supports calls to and from rest of system

Tour of internals– backward & forward engines– tree/proof– terms– bindings– discrimination tree

Prototypes


Choose the right abstractions

Goal, Unifier, ProofTree use Java iterators: pay as you go

– for finding the next proof

Make every Goal responsible for its list of matching clauses – hasNextMatchingClause()– attachNextMatchingClause()

Place Goals in stack of backtrack points– popped in reverse chronological order


Propositional Prover

initially proofTree has an open Goalloop if(proofTree.hasNoOpenGoal()) halt('success'); else Goal g = proofTree.selectOpenGoal(); g.createMatchingClauseList(); if(g.hasMoreMatchingClauses()) DefiniteClause c = g.nextClause();

g.attachClause(c); choicePoints.push(g); else chronologicalBacktrack();

Java Iterator

chronologicalBacktrack while(choicePoints.nonEmpty()) Goal g = choicePoints.pop(); g.removeAttachedClause(); if(g.hasMoreClauses()) return; halt('failure')

Create bindings

Remove bindings


Tree with initial goal p(Z)

p(X) :- q(X), r(X).q(g(X)).q(k).r(g(h))

p(Y1) :- q(Y1), r(Y1)

?:-p(Z)

a

a ChoicePoints

b

Z/Y1

q(g(Y2)) r(g(h))b c

c

Y1/g(Y2)

Y2/h

q(k) Y1/k

b’

b’


Moving to First Order Logic

Students struggle with variables– Unification– Composition of substitutions– Unbinding on backtracking

Can we hide the hard stuff?– Powerful abstraction


Shallow or deep variables?

Deep– variable binding is a list of replacements– traverse list for each lookup– undoing: remove most recent replacements

{X f(Y)} {Y a}

Shallow– an array of (all) variables and their current values

[X f(a) Y a …]

– undoing: pop stack of previous values (trail)


Goal Tree and flatterms

Each node has head and body atoms

Body atoms form goals– attach children

resolved p1 from d p1, …, pm

against q from q q1, …, qn

resolved pm against r .

p

q

q1 qn

r

N

CD

p1 pm


Flatterms to represent atoms

j-DREW uses flatterms– Array of pairs:

symbol table ref length of subterm

– Not structure sharing

Flatterms save theorem provers time and space (de Nivelle, 1999)

Data transfer between deduction engine and rest of application


Variables are clause-specific

Variables use negativeindexes

Bindings are references to flatterm &position

Unifier X g2

Y f(g2)W h(g2) Z f(g2)


Composing and undoing Bindings

Local shallow bindings currently do not allow composition– bindings must be done to a flatterm– new binding on a new flatterm

Backtracking is integrated with unbinding– for quick unbinding, we use a stack of flatterms for

each goal.


Discrimination trees

Given a goal we want to access matching clauses quickly

Every-argument addressing– unlike Prolog’s first argument addressing

Useful for RDF triples– a pattern may have variable in first argument– rdf(X, ownedby, ‘Ora Lassila’)


Discrimination trees

Given a goal, want to access input clauses with matching heads quickly

Index into clauses via a structure built from heads

Replace vars by *– imperfect discrimination

merge prefixes as much as possible– a tree arises

*

p q r

f

g1 h

*

h

h

g1 *

f

g2

*

• We added p(f(g1 ),h(g2 ),g1 )p(f(h( X )),h(Y ),f(Z, Z))


Finding heads for goal p(X,h(g2),Y)

replace vars in goal by *– p(*,h(g2),*)

Find instances of goal– * in goal, skip subtree

• Find generalizations of goal–* in tree, skip term in goal

p(f(g1 ),h(g2 ),g1 )p(f(h( X )),h(Y ),f(Z, Z))

p q r

f

g1 h

*

h

h

g1 *

f

g2

*•Find unifiable

–combination of both


Iterator for matching clauses

We use Java idioms where possible Java’s iterators give access to sequence

– next()– hasNext()

Used for access to sequence of matching clauses– used in discrimination tree for access to roots leaves of

skipped tree(McCune’s term: jump-list)




Smoked Salmon




Smoked Salmon

Gravalax


•Lox is Smoked, Cured Salmon



Smoked Salmon

Gravalax

Lox


A search for keywords Salmon and Cured should return pages that mention Gravalax, even if they don’t mention Salmon and Cured

A search for Salmon and Smoked will return pages with smoked salmon, should also return pages with Lox, but not Gravalax

Smoked Salmon

LoxGravalax

The Semantic Web vision is to make information on the web “understood” by computers, for searching,categorizing, …


Smoked Salmon

LoxGravalax


One possible encoding

Search criteria:retrieve(P) :-

about(P, cured),about(P, salmon).

Ontology:about(P, cured) :- about(P, gravalax).about(P, salmon) :- about(P, gravalax).

A search for keywords Salmon and Cured should return pages that mention Gravalax, even if they don’t mention Salmon and Cured.

about(p1, gravalax).

retrieve(p1) succeeds


retrieve(P) :- about(P, smoked),about(P, salmon).

about(P, cured) :- about(P, lox).about(P, salmon) :- about(P, lox).about(P, smoked) :- about(P, lox).about(P, cured) :- about(P, gravalax).about(P, salmon) :- about(P, gravalax).

A search for Salmon and Smoked will return pages with smoked salmon, should also return pages with Lox, but not Gravalax.

about(p1, gravalax).about(p2, lox).

retrieve(p1) failsretrieve(p2) succeeds


Working Prototypes:

Basic Prolog Engine– Accepts RuleML, or Prolog, or mixture– Iterator for instances of the top goal– Main loop is same code as propositional theorem prover

(shown earlier)– Builds, displays deduction tree

available to rest of system

– Negation as failure


More working prototypes:Variants of Top-Down Engine

User directed– User selects goals– User chooses clauses

keeps track of clauses still left to try

– Good teaching toolBounded search

– iteratively increase bound– every resolution in search space will eventually be tried– a fair selection strategy

Original variable names supplied– particularly important for RuleML


Bottom-Up / Forward Chaining

Set of support prover for definite clauses Facts are supports Theorem: Completeness preserved when

definite clause resolutions are only between first negative literal and fact.– Proof: completeness of lock resolution (Boyer’s PhD)

Use standard search procedure to reduce redundant checking (next)

Unlike OPS/Rete, returns proofs and uses first order syntax for atoms


Theorem Prover’s Search Procedure

Priority queue– new facts

Discrimination trees: – used facts – rules, indexed on

first goal

main loop select new fact for each matching rule resolve process new result add to old facts

process new result(C) if C is rule for each old fact matching first goal resolve process new result add C to rules else add C to new facts


Event – Condition - Action

Suppose theorem prover saturates– may need datalog, subsumption– Then a new fact is added from

push process Java event listener

– adding a fact restarts saturation could generate new Java events

ECA interaction with Java 1.1 events


j-DREW sound and complete

Sound unification Search complete variant

– fair search procedure rather than depth-first– uses increasing bounds

Sound negation– delay negation-as-failure subgoals – until ground or until only NAF goals remain


Related Work

j-DREW compared to Prolog– j-DREW not compiled– More flexible

Dynamic additions Web-ized Programmer’s API

– Performance requirements different j-DREW unlikely to yield megalips


Summary

Architecture for Java-based reasoning engines– forward & backward

Backward: variable binding/unbinding automatic– tied with choicepoints– configurable

Integrated with other Java APIs Small footprint

– Depolyed as thread, on server, on client, mobileDynamic additions to rules

– Integration of RuleML and Prolog rules in same proofsProofs available


The Rule Markup Language


Motivation (I)

Rules in (and for) the Web have become a mainstream topic since– inference rules were

marked up for E-Business identified as a Design Issue of the Semantic Web

– transformation rules were used for document generation from central XML repository

• Rule interchange is becoming more important in Knowledge Representation (KR), especially in– Intelligent Agents– Web Services


Motivation (II)

The Rule Markup Initiative has taken initial steps towards

defining a shared Rule Markup Language (RuleML) for

interoperation between the currently 34 Participant Groups

around the world

RuleML permits rules in XML & RDF/DAML+OIL for

– derivation, query, transformation (stable DTDs/Schemas)

– integrity checking (still regarded as special queries)

– reactive behavior (currently as translators to, e.g., Jess)


Semantic Web and Web ServicesUse Databases and Rule Systems

Databases: SQL

(Integration of) Schemas & Dictionaries

(Distributed) Transaction Processing

Triggers & Events

Rule Systems: RuleML

Derivation Rules

Transformation Rules

Reaction Rules

Category-Based Search Engines& Document Retrieval

Formal Ontologies& Metadata Repositories

First-Order Logic& Knowledge Representation

Semantic Web: DAML+OIL

Mediator Agents& Information Integration

Interface Descriptions& CGI Scripts

Communication Protocols& Remote Procedure Calls

Web Services : WSDL


Merchant1 Merchantm

. . .

Customer or Company

publishrulebase1

publishrulebasem

compare, instantiate,and run rulebases

Rule Systems forWeb-Based B2C or B2B Rule Exchange

translate tostandard format(e.g., RuleML)


From Natural Language to Horn Logic

Prolog-like formalization (syntax generated from XML):

''The discount for a customer buying a product is 5.0 percentif the customer is premium and the product is regular.''''The discount for a customer buying a product is 7.5 percentif the customer is premium and the product is luxury.''. . .

English Business Rules:


RuleML: Markup and Tree

''The discount for a customer buying a product is 5.0 percentif the customer is premium and the product is regular.''

<imp> <_head> <atom> <_opr><rel>discount</rel></_opr> <var>customer</var> <var>product</var> <ind>5.0 percent</ind> </atom> </_head> <_body> <and> <atom> <_opr><rel>premium</rel></_opr> <var>customer</var> </atom> <atom> <_opr><rel>regular</rel></_opr> <var>product</var> </atom> </and> </_body> </imp>

imp head atom opr rel discount var customer var product ind 5.0 percent

body and atom opr rel premium var customer

atom opr rel regular var product


Intertranslating RuleML and RFML

''The discount for a customer buying a product is 5.0 percentif the customer is premium and the product is regular.''

<imp> <_head> <atom> <_opr><rel>discount</rel></_opr> <var>customer</var> <var>product</var> <ind>5.0 percent</ind> </atom> </_head> <_body> <and> <atom> <_opr><rel>premium</rel></_opr> <var>customer</var> </atom> <atom> <_opr><rel>regular</rel></_opr> <var>product</var> </atom> </and> </_body> </imp>

<hn>

<pattop> <con>discount</con> <var>customer</var> <var>product</var> <con>5.0 percent</con> </pattop>

<callop> <con>premium</con> <var>customer</var> </callop> <callop> <con>regular</con> <var>product</var> </callop>

</hn>

ruleml2rfml.xsl

rfml2ruleml.xsl


Structure of the RuleML DTD Hierarchy

Our system of DTDs (current version: 0.8) uses a modularization approach similar to XHTML in order to accomodate the various rule subcommunities

The evolving hierarchy of RuleML DTDs forms a partial order with ruleml as the greatest element (a ruleml-rooted DAG) -- many ‘smallest’ elements

Each DTD node in the hierarchy (conformance “lattice”) corresponds to a specific RuleML sublanguage:– ‘Union’ (join) of sublanguages reached via outgoing links:

to smaller or equal nodes below– ‘Intersection’ (meet) of sublanguages via incoming links:

from greater or equal nodes above


The Module Hierarchy of RuleML DTDs

urc-bin-data-ground-facturc-bin-data-ground-log

urc-bin-datalog

bin-datalogurc-datalog

ur-datalog

ur-hornlog

ur-equalog

hornlog

equalog

datalog

ur

Rooted DAG will be extended withbranches for further sublanguages

URL/URI-like‘ur’-objects

ruleml

RDF-like triples

ur-datalog =

join(ur,datalog)


Planned RuleML Extensions

Reaction Rules: Encompass Situated, ECA, ... Rule Modules: ‘Send’ queries to agents Negations: Strong negation & negation as failure Rule Prioritizing: Labels and/or salience factors Integrity Constraints: Directly (not as queries)


RuleML Conclusions

RuleML DTD 0.8, a system of DTDs, is available at http://www.dfki.de/ruleml/indtd0.8.html; sample rulebases at http://www.dfki.de/ruleml/0.8/exa, use cases at http://www.dfki.de/ruleml/library

RuleML DTD 0.81 also has transformation rules with call-by-value function nestings

Further rule categories (e.g. integrity constraints and reaction rules) will be available via main RuleML page at http://www.dfki.de/ruleml

Distributed KR can already be based on current DTDs -- using (XSLT) transformations to reach follow-up and Participants’ DTDs


Simple HTML/XML Ontology Extensions


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


Instances (Individuals) as URLs/URIs

Individual constants in SHOE are represented throughan (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/


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>


XML Namespaces


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


Namespace Bindings

Prefixes are bound to namespace URIs by attaching

an xmlns:prefix attribute to the prefixed element or

one of its ancestors, prefix:name1 ,..., prefix:namen

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:prefix1 ,..., xmlns:prefixm


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)


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


Acquiring and Processing Knowledge Markups


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


Acquiring XML Knowledge Bases


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)


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


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


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>


Example (Import):Book Order


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 or RDF Schema


Example (Export):Newspaper Instances


Example: Newspaper Ontology As XML Tree


Processing XML


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.css"?>


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 Apache´s Cocoon or Xalan)– in client (browser, preliminary support in Netscape 6 and

IE 5.x)


XML to HTML: XSLT Example – Input

<addresses>

<address> <name>Xaver M. Linde</name> <street>Wikingerufer 7</street> <town>10555 Berlin</town> </address>

<address> <name>John Doe</name> <street>42 Gary Cooper Street</street> <town>Stanwyck City</town> </address>

</addresses>


XML to HTML: XSLT Example – Stylesheet

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <html> <head><title>Addresses</title></head> <body bgcolor="white"> <xsl:apply-templates/> </body> </html> </xsl:template>

<xsl:template match="address"> <xsl:value-of select="name"/> <xsl:value-of select="street"/> <xsl:value-of select="town"/> </xsl:template>

</xsl:stylesheet>

template for document root

template for address elements


XML to HTML: XSLT Example – Output

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">

<html> <head><title>Addresses</title></head> <body bgcolor="white"> Xaver M. Linde Wikingerufer 7 10555 Berlin John Doe 42 Gary Cooper Street Stanwyck City </body></html>

(The HTML code was produced with Apache´s Cocoon in HTML mode, hence became )


XML to XML: Transformational Semantics via an XSLT Stylesheet

<addresses> <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> <address> <name>XML4You</name> <street>96 Hyper Road</street> <town>Boston</town> </address></addresses>

% 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

<addresses> <address> <name>Me2XML</name> <place> <street>96 Hyper Road</street> <town>Boston</town> </place> </address> <address> <name>RDF4All</name> <place> <street>2001 Broadway</street> <town>New York</town> </place> </address> <address> <name>XML4You</name> <place> <street>96 Hyper Road</street> <town>Boston</town> </place> </address></addresses>

XSLT templates


XML to XML: XSLT Stylesheet with a Tree-Transforming Template 1

addresses

Subtree Subtree. . .

addresses

. . .

Subtree Subtree

 <xsl:template match="/addresses"> <addresses> <xsl:apply-templates/> </addresses> </xsl:template>


XML to XML: XSLT Stylesheet with a Tree-Transforming Template 2

address


name street town

address

PCDATA

PCDATA PCDATA

name

street town

place

 <xsl:template match="address"> <address> <name><xsl:value-of select="name"/></name> <place> <street><xsl:value-of select="street"/></street> <town><xsl:value-of select="town"/></town> </place> </address> </xsl:template>


XQL and XPath

XSLT uses XPath to select parts of the input XML documents, e.g.:– <xsl:template match="/"> document root– <xsl:value-of select="name"/> 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 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/name=´John Doeás before, plus the content of the name element must be ´John Doe´

– book//nameselect „name“ element nodes anywhere below „book“ element nodes


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

– address/@typeattribute nodes with name „type“ below „address“ element nodes

– address/@type=émailás above, plus the value of the „type“ attribute is émail´


XQL Expressions 3

filter expressions:– address[name]

select „address“ element nodes with a direct „name“ sub-element node

– address[name=´John Doe´]as above, plus the content of the „name“ element is ´John Doe´

– address[@type=émail´]select „address“ element nodes that have a „type“ attribute whose value is émail´


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: <tag>...</> instead of <tag>...</tag>


XML-QL Example 1

return short addresses (town-city renaming, without street):

WHERE <address> <name>$n</> <town>$t</> </> IN "www.test.org/addresses.xml" CONSTRUCT <shortaddress> <name>$n</> <city>$t</> </>


<shortaddress> <name>Xaver M. Linde</name> <city>10555 Berlin</city></shortaddress>

<street> elementsare also matched


XML-QL allows joining by value:

WHERE <address> <name>$n</> </> ELEMENT_AS $a IN "www.test.org/addresses.xml", <book> <author>$n</> <title>$t</> </> IN "www.test.org/books.xml"CONSTRUCT <book> <title>$t</> $a </>

XML-QL Example 2


XQuery

derived from Quilt

borrows features from several languages:– XPath and XQL: path expression syntax

– XML-QL: notion of binding variables and then using the bound

variables to create new structures

– SQL: series of clauses based on keywords that provide a

pattern for restructuring data (the SELECT-FROM-WHERE

pattern in SQL)

– OQL: functional language composed of several different kinds

of expressions that can be nested with full generality


Path expressions:

– In the second chapter of the document named "zoo.xml", find

the figure(s) with caption "Tree Frogs":

document("zoo.xml")/chapter[2]//figure[caption = "Tree Frogs"]

– Ranges: Find all the figures in chapters 2 through 5 of the

document named "zoo.xml":

document("zoo.xml")/chapter[RANGE 2 TO 5]//figure

– Dereferencing: Find captions of figures that are referenced by

<figref> elements in the chapter of "zoo.xml" with title "Frogs":

document("zoo.xml")/chapter[title = "Frogs"]

//figref/@refid->fig/caption

XQuery: Examples 1


XQuery: Examples 2

FLWR (FOR-LET-WHERE-RETURN) Expressions and Element Constructors:

– List the titles of books published by Morgan Kaufmann in 1998:

FOR $b IN document("bib.xml")//book

WHERE $b/publisher = "Morgan Kaufmann"

AND $b/year = "1998"

RETURN $b/title[xyz:*]

– List each publisher and the average price of its books:

FOR $p IN distinct(document("bib.xml")//publisher)

LET $a := avg(document("bib.xml")/book[publisher = $p]/price)

RETURN

<publisher>

<name> $p/text() </name> ,

<avgprice> $a </avgprice>

</publisher>

element constructor


XQuery: Examples 3

Functions (& Namespaces, XML Schema Data Types):

– Find the maximum depth of the document named "partlist.xml" :

NAMESPACE xsd = http://www.w3.org/2000/10/XMLSchema-datatypes

FUNCTION depth(ELEMENT $e) RETURNS xsd:integer

{

-- An empty element has depth 1

-- Otherwise, add 1 to max depth of children

IF empty($e/*) THEN 1

ELSE max(depth($e/*)) + 1

}

depth(document("partlist.xml"))



Todays Topics

Resolution – top down and bottom up

j-DREW BU procedure Subsumption

– change to procedure

Infinite Loops RuleML input

– Prolog output


Resolution

Clausal Logic: Syntax– an atom in logic is (syntactically) a relation symbol

followed by its arguments, each of which is a term– a term is either a variable, a constant or a function

symbol followed by its arguments (which are also terms) brother(‘Harry’, future_king(‘England’)) passes(‘Fang’, cs6999)

– each clause is a disjunction of positive or negative atoms attends(Student, Course) \/ ~passes(Student, Course) Rule Notation: a \/ b \/ ~c \/ ~d becomes a \/ b c /\ d

– a literal is a positive or negative atom Definite clauses have

– one positive literal and any number of negative literals


Resolution

Given two clauses, to form the resolvent:– find two literals, one from each clause, that

can be made to match (with assignments to the variables) differ in sign

– construct the disjunction of all literals except these two– apply the substitution

Resolve – b(X) \/ ~c(X, 3) against c(2, Y) \/ ~d(Y, Z)– gives b(2) \/ ~d(3, Z)

In rule notation– b(X) c(X, 3) against c(2, Y) d(Y, Z) – gives b(2) d(3, Z)


Bottom Up Reasoning

Single literal definite clauses are called facts– passes(‘Fang’, cs6999)

Resolving a fact against a condition in a rule is called forward reasoning– attends(Student, Course) passes(Student, Course)– Resolvent: attends(‘Fang’, cs6999)

Usually a derivation tree is viewed with given facts at the bottom and derived facts at the top– so forward reasoning also called bottom up reasoning

Prolog does top-down, backward reasoning– starting from a negative clause, called a query


j-DREW Bottom Up

More or less efficient than top down?– depends on details of each search method

More – can reuse subderivations – saves space and time

Less– Less goal directed– Much unfocused search

Infinite loops possible with both





first goal

main loop select new fact for each matching rule resolve process new result add to old facts



Preventing Infinite Loops

To prevent infinite loops in the search procedure, use subsumption (next slides) and either 1a) use ground facts and rules only, or 1b) use no function symbols

Sometimes it helps if the positive literal has no new variables (that do not already occur in the body)


Subsumption

A clause C subsumes a clause D if there is a substitution such that C D– C is more general than D– Given C you do not need D

We use subsumption between facts (atoms)– Atoms C subsumes atom D if

there exists such that C = D

Subsumption is checked by – first grounding all variables in D to new constants – then trying to unify C with grounded D


Forward subsumption

New result is checked against old results to see if it is more general

We can prevent some infinte loops by checking subsumption of new fact against old facts

Should this be done when the new fact is derived or when it is selected?– experience shows that subsumption on selection is

better

What about subsumption of rules?





first goal

main loop select new fact if it is not forward subsumed for each matching rule resolve process new result add to old facts



Event – Condition - Action

Suppose theorem prover saturates– Then a new fact is added from

push process Java event listener

– adding a fact restarts saturation could generate new Java events

ECA interaction with Java 1.1 events


System Architecture

Event Broadcaster

j-DREW BU

Old Facts

Rules

New Facts

New Fact

New Facts

ListenerListener

Listener

Listener

j-DREW runs

Listeners register with Broadcaster

New fact added

New conclusions drawn

Events sent to Listeners


RuleML

Input to j-DREW BU may also be RuleML

RuleML queries are ignored currently

<imp> <_head> <atom> <_opr><rel>discount</rel></_opr> <var>customer</var> <var>product</var> <ind>5.0 percent</ind> </atom> </_head> <_body> <and> <atom> <_opr><rel>premium</rel></_opr> <var>customer</var> </atom> <atom> <_opr><rel>regular</rel></_opr> <var>product</var> </atom> </and> </_body></imp>

discount(customer,product1,'5.0 percent') :- premium(customer),regular(product).


Related Literature

Set of support prover for definite clauses Facts are supports Theorem: Completeness preserved when

definite clause resolutions are only between first negative literal and fact.– Proof: completeness of lock resolution (Boyer’s PhD)

Use standard search procedure to reduce redundant checking

Unlike OPS/Rete, returns proofs and uses first order syntax for atoms


XML-Based Agent Techniques


XML-Based Agent Techniques

XML-Protocol, SOAP, XML-RPC, WSDL

– remote procedure calls starting with HTTP for the transport

and XML for the encoding

FIPA (Foundation of Intelligent Physical Agents)

– XML (and RDF) as language for message contents

DAML

– DARPA Agent Markup Language

ACORN

– Keyphrase-Based Information Sharing Multi-Agent Architecture: Virendra C.

Bhavsar and Ali A. Ghorbani

RACSA

– Rule Applying Comparison Shopping Agent


RACSA (1)

The RACSA project contributes to the Semantic Web,especially to e-commerce in the Semantic Web

Unlike in standard comparison shopping,the main idea of RACSA is

• marking up shopping web pages with Semantic Web languages

• based on their list prices, computing the real end prices by applying various business rules


RACSA (2)

From a more technical point of view,

RACSA is a rule-empowered shopping agent, using RuleML as the XML-based rule language and Mandarax (a Java-based Prolog engine) as the inference component for processing knowledge and data bases (i.e. facts and rules)

The goal of RACSA is to demonstrate an e-commerce application enabled by the Semantic Web techniques: Supporting purchase-decisions by simplifying price comparisons


RACSA (3)

The project is restricted to an exemplary domain:

Refrigerators/freezers offered by 3 small fictitious shops

Rule application takes place in a wide variety of areas:

• gross/net prices• calculation of warranty time• additional insurance and transport costs• payment and customer discounts

Online Demo: http://www.dfki.de/racsa/


Resource Description Framework


“There is nothing interesting in what we are doing. The only interesting thing is the scale upon which we are attempting to do it.” R.V. Guha, Epinions

Disclaimer and Footnote

Adobe’s eXtensible Metadata Platform (XMP) now uses RDFfor Photoshop® 7.0, Acrobat® 5.0, and FrameMaker®:http://www.adobe.com/products/xmp/main.html


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


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?


Extensible Markup Language (XML) Revisited

Key idea: separate structure from presentation

XML DTDs or Schemas 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

XSLT)

DTD enables document recipients to tell whether

they’ve received a grammar-conforming document– Gives a minimal level of validation


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

==> Next step: separate content from structure!


Encoding of Knowledge: Example

http://www.w3.org/Home/Lassila Creator

Endless encoding possibilities in XML:<Creator> <uri>http://www.w3.org/Home/Lassila</uri> <name>Ora Lassila</name></Creator>

<Document uri=“http://www.w3.org/Home/Lassila” <Creator>Ora Lassila</Creator></Document>

<Document uri=“http://www.w3.org/Home/Lassila” Creator=“Ora Lassila”/>

“The Creator of the Resource “http://www.w3.org/Home/Lassila” is Ora Lassila

Ora Lassila


Point to Point Communicationfor Machine-Understandable Data

Translation Step

<xsd:schema xmlns:xsd="http://..."> <xsd:annotation> A-Schema

</xsd:...</xsd:schema>

Conceptual Domain Model(Objects and Relations)

DTD or XML Schema

Deployment

Recipient using DTD A

XML-based Communicationusing DTD A

Sender using DTD A

XML-Parser

Parse Tree

Person is_a Mammal Student is_a Person ----

Common Semantics


Many Previously Unknown Communication Partners


New Partners Don’t Understand Each Other

XML-based Communicationusing DTD A

Sender using DTD A Recipient using DTD A

XML-Parser

Parse Tree

Communication Partner using DTD B

? ?

Communication Partner using DTD C

?


Merging Steps Between Models

<xsd:schema xmlns:xsd="http://..."> <xsd:annotation>A-Schema


<xsd:schema xmlns:xsd="http://..."> <xsd:annotation>B-Schema


<xsl:stylesheet version="1.0” xmlns:xsl="http://....Transform" <xsl:template match="/"> .... </xsl:template></xsl:stylesheet>

<xsl:stylesheet version="1.0” xmlns:xsl="http://....Transform" <xsl:template match="/"> .... </xsl:template></xsl:stylesheet>

Matching

Reengineeringof the conceptual model

XML Document Translation Generation(e.g. in XSLT)

DTD A DTD B

XML Document Translation fromDTD A to DTD B(and B to A)

Steps

Matching


Merging/Aligning Models

Reengineering step is costly and unnecessary,

when a conceptual language is in use

Generation document translation procedures is

again complicated and unnecessary

==> use a level on top of XML

What are requirements for such a level?


Postulates: Fundamental Requirements for KR on the Web

1. Knowledge on the Web is distributed (link Knowledge on the Web)

2. Knowledge on the Web is biased - there is no universal truth it must be possible to dispute statements

3. Many different user communities: Extensibility and Simplicity

==> Resource Description Framework (RDF)


Introduction to RDF

RDF (Resource Description Framework)– Beyond Machine readable to Machine understandable

RDF unites a wide variety of stakeholders:– Digital librarians, content-raters, privacy advocates, B2B

industries, AI...– Significant (but less than XML) industrial momentum,

lead by W3C RDF consists of two parts

– RDF Model (a set of triples)– RDF Syntax (different XML serialization syntaxes)

RDF Schema for definition of Vocabularies (simple Ontologies) for RDF (and in RDF)


RDF Data Model

Resources– A resource is a thing you talk about (can reference)– Resources have URI’s– RDF definitions are themselves Resources (linkage, see

requirement 1) Properties

– slots, define relationships to other resources or atomic values

Statements– “Resource has Property with Value”– (Values can be resources or atomic XML data)

Similar to Frame Systems


A Simple Example

Statement– “Ora Lassila is the creator of the resource

http://www.w3.org/Home/Lassila”

Structure– Resource (subject)

http://www.w3.org/Home/Lassila– Property (predicate)

http://www.schema.org/#Creator– Value (object) "Ora Lassila”

Directed graphhttp://www.w3.org/Home/Lassila s:Creator Ora Lassila


Another Example

To add properties to Creator, point through an intermediate Resource.

http://www.w3.org/Home/Lassila

s:Creator

Person://fi/654645635

Name

Ora Lassila [email protected]

Email


Collection Containers

Multiple occurrences of the same PropertyType don’t establish a relation between the values– The Millers own a boat, a bike, and a TV set– The Millers need (a car or a truck)– (Sarah and Bob) bought a new car

RDF defines three special Resources:– Bag unordered values rdf:Bag– Sequence ordered values rdf:Seq– Alternative single value rdf:Alt

Core RDF does not enforce ‘set’ semantics amongst values


Example: Bag

The students incourse 6.001 are Amy, Tim,John, Mary,and Sue

Rdf:Bag

/Students/Amy

/Students/Tim

/Students/John

/Students/Mary

/Students/Sue

bagid1

/courses/6.001

students

rdf:type

rdf:_1

rdf:_2

rdf:_3

rdf:_4

rdf:_5


Example: Alternative

The source code for X11 may be found at ftp.x.org, ftp.cs.purdue.edu, or ftp.eu.net

http://x.org/package/X11rdf:Alt

ftp.x.org

ftp.cs.purdue.edu

ftp.eu.net

altid

rdf:type

rdf:_1

rdf:_2

rdf:_3

source


Statements About Statements (Requirement 2: Dispute Statements)

Making statements about statements requires a

process for transforming them into Resources

– subject the original resource

– predicate the original property

– object the original value

– type rdf:Statement


Example: Reification

Ralph Swick believes that – the creator of the resource

http://www.w3.org/Home/Lassila is Ora Lassila

rdf:Statement

rdf:type

genid1

Ralph Swick

b:believedBy


rdf:subject

Ora Lassila

rdf:object

s:Creatorrdf:predicate

s:Creator


A Formal Model of RDF

RDF itself is mathematically straightforward:

– Basic Definitions Resources

Properties Resources

Literals

Statements Properties Resources ResourcesLiterals

– Typing rdf:type Properties

{RDF:type, sub, obj} Statements obj Resources

– for triples like {p,r1,r2} the RDF spec should use some different bracketing, like (p,r1,r2)


Formal Model of RDF II

– Reification rdf:Statement Resources \ Properties

rdf:predicate, rdf:subject, rdf:object Properties

Reification of a triple pred, sub, obj of Statements is an element r of Resources representing the reified triple and the elements s1, s2, s3, and s4 of Statements such that

– s1: {RDF:predicate, r, pred}– s2: {RDF:subject, r, sub} – s3: {RDF:object, r, obj} – s4: {RDF:type, r, [RDF:Statement]}

– Collections RDF:Seq, RDF:Bag, and RDF:Alt Resources \ Properties There is a subset of Properties corresponding to the ordinals (1, 2, 3, ...) called Ord.

We refer to elements of Ord as RDF:_1, RDF:_2, RDF:_3, ...


RDF Syntax I

Data model does not enforce particular syntax Specification suggests many different syntaxes

based on XML General form:

<rdf:RDF> <rdf:Description about="http://www.w3.org/Home/Lassila"> <s:Creator>Ora Lassila</s:Creator> <s:createdWith rdf:resource=“http://www.w3c.org/amaya”/> </rdf:Description></rdf:RDF>

Starts an RDF-Description

Properties

Subject (OID)

Literal

Resource (possibly another RDF-description)


Resulting Graph

<rdf:RDF> <rdf:Description about="http://www.w3.org/Home/Lassila"> <s:Creator>Ora Lassila</s:Creator> <s:createdWith rdf:resource=“http://www.w3c.org/amaya”/> </rdf:Description></rdf:RDF>

http://www.w3c.org/amaya


Ora Lassila

s:createdWiths:Creator


RDF Syntax II: Syntactic Varieties

<s:Homepage rdf:about="http://www.w3.org/Home/Lassila” s:Creator=“Ora Lassila”/>

<s:createdWith> <s:HTMLEditor rdf:about=“http://www.w3c.org/amaya”/> </s:createdWith> </s:Homepage>

Typing Information In-Element Property

Property

Subject (OID)

http://www.w3c.org/amaya


Ora Lassila

s:createdWiths:Creator

HTMLEditor

s:Homepagerdf:type

rdf:type


RDF Schema (RDFS)

RDF just defines the data model

Need for definition of vocabularies for the data

model - an Ontology Language!

RDF schemas are Web resources (and have

URIs) and can be described using RDF


Most Important Modeling Primitives

Core Classes– Root Class rdfs:Resource

– MetaClass rdfs:Class

– Literals rdfs:Literal

rdfs:subclassOf property

Inherited from RDF: properties (slots) rdfs:domain & rdfs:range rdfs:subPropertyOf property

rdfs:label, rdfs:comment, etc.

Inherited from RDF: InstanceOf (rdf:type)


RDF-Schema: Example (incomplete)

rdfs:Resource

xyz:MotorVehicle

s

xyz:Truck

s

xyz:PassengerVehicle

s = rdfs:subClassOf

xyz:Van s

s

xyz:MiniVan s

s


RDF-Schema: Example

rdfs:Resource

xyz:MotorVehicle rdfs:Class

s s

t

t

xyz:Truck

s

t

xyz:PassengerVehicle

s = rdfs:subClassOf t = rdf:type

xyz:Van s

s

xyz:MiniVan s

s

t

t

t

t


Example: RDF-Schema in RDF-Schema

Namespace-URL:http://www.w3.org/2000/01/rdf-schema#

<rdfs:Class rdf:ID="Resource"> <rdfs:label xml:lang="en">Resource</rdfs:label> <rdfs:label xml:lang="fr">Ressource</rdfs:label> <rdfs:comment>The most general class</rdfs:comment></rdfs:Class><rdfs:Class rdf:ID="Class"> <rdfs:label xml:lang="en">Class</rdfs:label> <rdfs:label xml:lang="fr">Classe</rdfs:label> <rdfs:comment>The concept of Class</rdfs:comment> <rdfs:subClassOf rdf:resource="#Resource"/></rdfs:Class><rdf:Property ID="subClassOf"> <rdfs:label xml:lang="en">subClassOf</rdfs:label> <rdfs:label xml:lang="fr">sousClasseDe</rdfs:label> <rdfs:comment>Indicates a subclass of a class</rdfs:comment> <rdfs:range rdf:resource="#Class"/> <rdfs:domain rdf:resource="#Class"/></rdf:Property>


Extensibility of RDF

Define an Ontology of your Language with RDF

Schema (like RDF-Schema itself)

Describe Instance Data using your new

Vocabulary

Advantage: all Languages use the same Data

Model (simplifies Interoperability)


Photo Archive Using RDF: Introduction

W3C project for describing & retrieving (digitized)

photos with (RDF) metadata

– Explained in a W3C Note by Yves Lafon and Bert Bos

Metadata separated into three different schemas:

1. Dublin Core schema: Title, date, subject, etc.

2. Technical schema: Photo and camera details

3. Content schema: Vocabulary for DC "subject" property


Photo Archive Using RDF: Sample Photo


Photo Archive Using RDF: Photo Metadata

<?xml version="1.0"?><rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://www.w3.org/1999/09/28-Photo-ns#" xmlns:DC="http://purl.oclc.org/dc/documents/rec-dces-199809.htm#" xmlns:Technical="http://www.w3.org/2000/PhotoRDF/technical-1-0#"> <rdf:Description about=""> <DC:Description>Waves breaking in a small gulf on an island near Brisbane</DC:Description> <DC:Type>image/jpeg</DC:Type> <DC:Subject>Landscape</DC:Subject> <DC:Source>35mm slide</DC:Source> <DC:Rights>http://www.w3.org/People/Lafon/Copyright?1998</DC:Rights> <DC:Title>Sea near Brisbane</DC:Title> <DC:Date>1998-04-20</DC:Date> <DC:Coverage>Brisbane - Australia</DC:Coverage> <DC:Creator>http://www.w3.org/People/Lafon/</DC:Creator> <Technical:devel-date>2000-05-01</Technical:devel-date> <Technical:lens>Minolta AF70-210</Technical:lens> <Technical:camera>http://www.w3.org/People/Lafon/Minolta800i</Technical:camera> <Technical:film>Fuji</Technical:film> </rdf:Description></rdf:RDF>


Photo Archive Using RDF: RDFS Excerpt

<rdf:RDF xmlns:rdfs="http://www.w3.org/TR/1999/PR-rdf-schema-19990303#“ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

<rdf:Property rdf:ID="title"> <rdfs:label xml:lang="en">Title</label> <rdfs:subPropertyOf rdf:resource="http://purl.org/dc/elements/1.1/title"/> </rdf:Property>

<rdf:Property rdf:ID="creator"> <rdfs:label xml:lang="en">Author/creator</label> <rdfs:subPropertyOf rdf:resource="http://purl.org/dc/elements/1.1/creator"/> </rdf:Property>

<rdf:Property rdf:ID="subject"> <rdfs:label xml:lang="en">Subject</label> <rdfs:subPropertyOf rdf:resource="http://purl.org/dc/elements/1.1/subject" /> <rdfs:range rdf:resource="http://www.w3.org/2000/PhotoRDF/content-1-0#Keywords"/></rdf:Property>

. . .

</rdf:RDF>

This is an excerpt of a minimal RDF Schema for the Dublin Core: Each property is a restriction of the DC property of the same name,as found in http://purl.org/dc/elements/1.1/ :


Protégé-2000 as RDF[S]-Editor

<rdfs:Class rdf:about="&mv;MotorVehicle"> <rdfs:subClassOf rdf:resource="&rdfs;Resource"/></rdfs:Class>

<rdfs:Class rdf:about="&mv;PassengerVehicle"> <rdfs:subClassOf rdf:resource="&mv;MotorVehicle"/></rdfs:Class>

<rdf:Property rdf:about="&mv;rearSeatLegRoom" a:maxCardinality="1" a:range="integer"> <rdfs:domain rdf:resource="&mv;MotorVehicle"/> <rdfs:range rdf:resource="&rdfs;Literal"/></rdf:Property>


Ontology Languages on Top of RDF:The Principle

Definition uses the data model of

Defined in terms of

RDF

RDF SchemaOntologyLanguage

Instance Data

Is extension of

Legend:


The Semantic Web

A Web of machine understandable Data, based on declarative languages on top of RDF (all use the same data model!) Intelligent Agent enabling architecture W3C’s vision for the Semantic Web Architecture:


Tools

Tools for RDF and RDF Schema

– Editors

Protégé-2000 (SMI)

HTML Annotation Tool (Siegfied Handschuh)

– Parsers and Generators

RDF-API (Sergey Melnik, Stanford)

– Query and Inference Engines

N3 (Tim Berners-Lee)

Squish (Libby Miller)

SiLRI (Stefan Decker & Juergen Angele)

TRIPLE (Stefan Decker and Michael Sintek)


RDF Resources

RDF-Editor: Protégé www-smi.stanford.edu/projects/protege

RDF-Parser and APIs/Query Engines– http://www-db.stanford.edu/~melnik/rdf– http://www.aifb.uni-karlsruhe.de/~sde/rdf

RDF Knowledge Sources– DMOZ - Open Directory (largest human created Web-

directory) http://www.dmoz.org General Information:

– RDF Interest Mailing list: [email protected]: http//lists.w3.org/Archives/Public/www-rdf-interest/

– SemanticWeb.org


Open Issues of RDF

RDF-Schema is still evolving

URIs: What is the URI of a person?

Other real world entity?

“Killer Applications”: Search Engines? B2B-

Communication (e.g. ebXML.org ?)

Interoperability between RDF-Schemas


Description Logic:Class-Forming Operations


Class Intersection:Example

Man

TallThing

s

s

s = rdfs:subClassOf

TallMan := TallThing Π Man

Intensional conjunction of classes: TallThingΠMan(x) TallThing(x) Man(x)Intensional disjunction of classes similar but computationally more complex


Class Intersection and Definition: Example

Man

TallThing

s

s

TallMan:=

s = rdfs:subClassOf := = daml:Class

TallMan := TallThing Π Man


Class Complement:Example

Person

c

Car ¬Person

c = daml:complementOf


Class Complement and Subsetting:Example

Person

c

c = daml:complementOf

Car ¬Person

Cars

s = rdfs:subClassOf


Qualified Role:Example

Over17

t

age

t = rdf:type

RipeThing := age.Over17

Existential role: age.Over17(x) y age(x,y) Over17(y)Universal role similar


Qualified Role and Definition :Example

Over17

t

RipeThing := age.Over17

RipeThing age

t = rdf:type

:=

:= = daml:Class


DAML+OIL


DARPA Agent Markup Language, OIL, and OWL

OIL: European Ontology Interchange Language DARPA funded Research Program (also funded

the Development of the ARPANNET -> Internet):– Foundation for the Semantic Web: http://www.daml.org

Ontology Language DAML+OIL: Result of a Joint (European + American) Committee

Rule Language in preparation, jointly with RuleML W3C’s new OWL (Ontology Web Language)

mainly divides DAML+OIL into two sublanguages:– OWL Light: Frames– Full OWL: Description logic

http://www.w3.org/2001/sw/WebOnt/


DAML+OIL

Extension of RDF Schema Ontology Language DAML+OIL: Result of a Joint

(European + US-American) Committee Extension of RDF Schema

– Class Expressions (Intersection, Union, Complement)– XML Schema Datatypes– Enumerations– Property Restrictions

Cardinality Constraints Value Restrictions


Example: Intersection & Synonyms

<daml:Class rdf:ID="TallMan"> <daml:intersectionOf rdf:parseType="daml:collection">

<daml:Class rdf:about="#TallThing"/> <daml:Class rdf:about="#Man"/>

</daml:intersectionOf> </daml:Class>

<daml:Class rdf:ID="HumanBeing"><daml:sameClassAs rdf:resource="#Person"/>

</daml:Class>


Example: Disjoint & Complement

<daml:Disjoint rdf:parseType="daml:collection"><daml:Class rdf:about="#Car"/> <daml:Class rdf:about="#Person"/> <daml:Class rdf:about="#Plant"/>

</daml:Disjoint>

<daml:Class rdf:ID="Car"><rdfs:comment>no car is a person</rdfs:comment> <rdfs:subClassOf>

<daml:Class><daml:complementOf rdf:resource="#Person"/>

</daml:Class> </rdfs:subClassOf>

</daml:Class>

Disjoint not strictly necessary, since expressible via pairwise subClassOfof complementOf, as for Car and Person:


Example: Properties (Transitive, Inverse, subProperty, UniqueProperty, range, Datatypes)

<daml:TransitiveProperty rdf:ID="hasAncestor"/>

<daml:ObjectProperty rdf:ID="hasChild"><daml:inverseOf rdf:resource="#hasParent"/>

</daml:ObjectProperty>

<daml:UniqueProperty rdf:ID="hasMother"><rdfs:subPropertyOf rdf:resource="#hasParent"/><rdfs:range rdf:resource="#Female"/>

</daml:UniqueProperty>

<daml:DatatypeProperty rdf:ID="age"><rdf:type rdf:resource="http://www.daml.org/2001/03/daml+oil#UniqueProperty"/><rdfs:range rdf:resource="http://www.w3.org/.../XMLSchema#nonNegativeInteger"/>

</daml:DatatypeProperty>


Using User-defined Datatypes(based on XML Schema)

<xsd:simpleType name="over17">  <xsd:restriction base="xsd:decimal"> <xsd:minInclusive value="18"/> </xsd:restriction>

</xsd:simpleType>

<daml:Class rdf:ID="Adult"><daml:intersectionOf rdf:parseType="daml:collection">

<daml:Class rdf:about="#Person"/> <daml:Restriction><daml:onProperty rdf:resource="#age"/><daml:hasClass rdf:resource="somefile#over17"/>

</daml:Restriction> </daml:intersectionOf> </daml:Class>


Instances (Individuals)

<Person rdf:ID="Adam"> <rdfs:label>Adam</rdfs:label> <rdfs:comment>Adam is a person.</rdfs:comment> <age><xsd:integer rdf:value="13"/></age> <shoesize>

<xsd:decimal rdf:value="9.5"/></shoesize>

</Person>

<daml:Class rdf:ID="Person"> . . .</daml:Class>


Protégé as OIL Editor

supports following subset of OIL:

– class definitions with subclass and slot constraints (property restrictions) with class expressions: and, or, not, class[names], slot constraints, top, and bottom

slot constraints: has-value, value-type, max-cardinality, min-cardinality, cardinality

missing: concrete-type-exp, filler-exp

– slot definitions: subslot-of, inverse (using Protégé's inverse slot mechanism), domain, range

properties (transitive, symmetric, functional)

– global axioms (disjoint, covered, disjoint-covered, equivalent)

– missing: instance-of, related

special widgets for displaying OIL expressions

connects to FaCT description logic classifier for classification and

satisfiability checking

generates SHIQ LaTeX output


Protégé as OIL Editor: Screenshot


TRIPLE


TRIPLE: Motivation

RDF data available Needed: Query and Inference Language for/in

RDF Existing Approaches:

– SiLRI– Metalog– RQL– …


What’s wrong with existing approaches?

Built in Semantics (e.g. SiLRI, RQL)

– Many RDF based languages with different Semantics

(DAML+OIL, RDF-Schema, UML/RDF,…)

No support for RDF-Models

– One large heap of RDF-Data


Graph Separated in Models

source2source1

source3


New System: Triple

Native support for– Resources + Namespaces– Models (sets of RDF statements)– Reification– Data Integration/Translation– Rules with Expressive Bodies (Full FOL Syntax)


Object Expressions + Models

http://..123[age->”32”;spouse->http//..256]. http://..123[age->”32”;spouse->http//..256[age->”31”]]. http://..123[age->”32”]@mod1 http://..123[age->”32”]@(mod1 intersect mod2) http://..123[age->”32”]@(mod1 union mod2) http://..123[age->”32”]@(mod1 \ mod2) http://..123[age->”32”]@test(X)


Reification

http://…1234

believedBy

“Ralph Swick”

“Ora Lassila”hasAuthor

<http://…1234[hasAuthor->”OraLassila”]>[believedBy->”Ralph Swick”].


Example: RDF-Schema

rdf := 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'.

rdfs := 'http://www.w3.org/TR/1999/PR-rdf-schema-19990303#'.

type := rdf:type.

subPropertyOf := rdfs:subPropertyOf.

subClassOf := rdfs:subClassOf.

FORALL Mdl @rdfschema(Mdl) {

FORALL O,P,V O[P->V] <- O[P->V]@Mdl.

FORALL O,P,V O[P->V] <- EXIST S S[subPropertyOf->P] AND O[S->V].

FORALL O,V O[subClassOf->V] <-

EXISTS W (O[subClassOf->W] AND W[subClassOf->V]).

FORALL O,V O[subPropertyOf->V] <-

EXISTS W (O[subPropertyOf->W] AND W[subPropertyOf->V]).

FORALL O,T O[type->T] <-

EXISTS S (S[subClassOf->T] AND O[type->S]).}

NamespaceDeclarations

Abbreviations

Model Block

TransitivityRule


Mapping to Horn Logic

first implementation (and informal semantics) by mapping to Horn Logic / XSB system (Prolog with tabled resolution)

Lloyd-Topor transformation for quantifiers etc.

RDF-specific transformations given as rewrite rules:


Summary

New RDF specific Query and Inference Language

Allows specification of multiple semantics

Integration/Translation of heterogeneous data

(InterDataWorking.com)

Every Horn Logic Inference Engine can be used

Provides a formal foundation for N3

Part of RuleML ( http://www.dfki.de/ruleml )


Topic Maps


Topic Maps

• Aiming at User Support for classifying and navigating large corpora of resources

• Topic Navigation Maps generalize:

– indexes

– glossaries

– thesauri

– catalogs

– cross-references

• Allow browsing as well as querying of Information

• ISO Standard (ISO13250) (defined by the SGML/XML Community)


Topic Navigation Maps in a Nutshell I

• Topics (e.g. Germany)

– have a topic-type (e.g. Country)

– at least one base-name (Germany)

– multiple display names (e.g. Federal Republic of Germany)

– have occurrences (in external resources)(eg. In CIA-World Fact Book: http://www.odci.gov/cia/publications/factbook/gm.html)

• occurrences have a role: eg. “MENTION” (again a Topic)


Topic Navigation Maps in a Nutshell II

Topics can be related to each other via associations (eg. “Rau is_head_of Germany”)

Association-Types (eg. “is_head_of”) are again a topics. Association-Roles define the role of a topic in a

association(“President” for “Rau”, and “Country” for “Germany”). Association-Roles are again topics.

An association may have a scope(eg. “Rau is_head_of Germany” has scope “1999-now”)

Axioms (eg. Transitivity or Symmetry) are considered useful, but not part of the ISO-Standard


Example of a Browsing Interface


XML Topic Maps (XTM): Design Goals

1. XTM shall be straightforwardly usable over the Internet2. XTM shall support a wide variety of applications3. XTM shall be compatible with XML, XLink, and ISO 132504. It shall be easy to write programs that process XTM

documents5. The number of optional features in XTM is to be kept to the

absolute minimum, ideally zero6. XTM documents should be human-legible and reasonably

clear7. The XTM design should be prepared quickly8. The design of XTM shall be formal and concise9. XTM documents shall be easy to create10. Terseness in XTM markup is of minimal importance


XML Topic Maps (XTM): Purpose of a Topic Map

The purpose of a topic map is to

convey knowledge about resources

through a superimposed layer, or map,

of the resources

A topic map capturesthe subjects of which resources speak,

and the relationships between subjects, in a way that is implementation-independent


XML Topic Maps (XTM): Topics, Associations, and Occurrences

• A topic is a resource within the computer that stands in for (or “reifies”) some real-world subject. Examples of subjects: the play Hamlet, the playwright William Shakespeare, or the “authorship” relationship

• Topics can have names. They can also have occurrences: information resources considered relevant to their subject. Finally, topics can participate in relationships, called associations, in which they play roles as members

• Thus, topics have three kinds of characteristics: names, occurrences, and roles played as members of associations. Characteristics considered valid within scope or context

• Topic maps can be merged: at the discretion of the user or application (at runtime), or indicated by the topic map's author at the time of its creation

• Terseness in XTM markup is of minimal importance


XML Topic Maps (XTM):Sample Topic

<topic id="hamlet"> <instanceOf><topicRef xlink:href="#play"/></instanceOf> <baseName> <baseNameString>Hamlet, Prince of Denmark</baseNameString> </baseName> <occurrence> <instanceOf> <topicRef xlink:href="#plain-text-format"/> </instanceOf> <resourceRef xlink:href="ftp://www.gutenberg.org/pub/gutenberg/etext97/1ws2610.txt"/> </occurrence></topic>

A topic representing one of William Shakespeare's playsin XTM might look like this:


XML Topic Maps (XTM):Sample Association

<association> <instanceOf><topicRef xlink:href="#written-by"/></instanceOf> <member> <roleSpec><topicRef xlink:href="#author"/></roleSpec> <topicRef xlink:href="#shakespeare"/> </member> <member> <roleSpec><topicRef xlink:href="#work"/></roleSpec> <topicRef xlink:href="#hamlet"/> </member></association>

An association representing the relationshipbetween Shakespeare and the play Hamletmight look like this:


Acknowledgements

Stefan Decker and Michael Sintek for their key contributions to starting it all:

http://www.dfki.uni-kl.de/km/knowmark/, http://www.dfki.uni-kl.de/km/kmrs/

William Grosso, Rohit Khare, Peter Karp, Dan Brickley for their kind permission

to use material

Andreas Abecker, Heiko Maus, Andreas Lauer, Hansi Hein, Stefan Klink, Bertin

Klein, and other colleagues at DFKI for fruitful discussions

All colleagues at Karlsruhe, Stanford, ISI, NRC, and UNB for related interactions

Peter Fankhauser for valuable input on query languages

Elliotte Rusty Harold for his XML Bible: http://www.ibiblio.org/xml/books/bible2/

The Joint (Agent Markup Language) Committee and the Rule Markup Initiative

for discussions: http://www.daml.org/committee/, http://www.ruleml.org


References


References

CocoonThe Cocoon Publishing Framework. Available at http://xml.apache.org/cocoon/index.html

CSS2Cascading Style Sheets, level 2. Available at http://www.w3.org/TR/REC-CSS2/

DAMLDARPA Agent Markup Language. Availabe at http://www.oasis-open.org/cover/daml.html ,http://dtsn.darpa.mil/iso/programtemp.asp?mode=347 , and http://www.daml.org/

Dublin CoreAvailable at http://purl.oclc.org/dc/

Fernandez99 XML Query Languages: Experiences and Exemplars, Mary Fernandez, Jérôme Siméon, Philip Wadler, 1999. Available at http://www.w3.org/1999/09/ql/docs/xquery.html

FRODOThe FRODO Project. Homepage available at http://www.dfki.uni-kl.de/frodo/

OILOntology Interchange Language. Availabe at http://www.ontoknowledge.org/oil/

Protégé-XMLThe Protégé XML-Tab. Available at http://smi-web.stanford.edu/people/sintek/


References

Q&TQuerying and Transforming XML. Available at http://www.w3.org/TandS/QL/QL98/pp/query-transform.html

RACSA Online Demo at http://www.dfki.de/racsa/

RDFHomepage: http://www.w3.org/RDF/Specification: http://www.w3.org/TR/REC-rdf-syntaxFAQ: http://www.w3.org/RDF/FAQTutorial: Carl Lagoze et al: WWW7 Tutorial. Available at http://purl.oclc.org/~emiller/talks/www7/tutorial

RDF-SchemaSpecification at http://www.w3.org/TR/rdf-schema

RuleMLThe Rule Markup Language. Homepage at http://www.ruleml.org or http://www.dfki.de/ruleml

Semantic WebPortal at http://www.SemanticWeb.org

SHOESimple HTML Ontology Extensions. Available at http://www.cs.umd.edu/projects/plus/SHOE/

XMLExtensible Markup Language (XML), Version 1.0. W3C Recommendation. Available at http://www.w3.org/TR/1998/REC-xml-19980210


References

XML NamespacesNamespaces in XML. W3C Recommendation at http://www.w3.org/TR/REC-xml-names/

XML-QLXML-QL: A Query Language for XML. Available at http://www.w3.org/TR/NOTE-xml-ql/

XML-RPCXML Remote Procedure Calls. Available at http://www.xmlrpc.com/

XPathWorld Wide Web Consortium. XML Path Language. W3C Recommendation. Available at http://www.w3.org/TR/xpath

XPointerWorld Wide Web Consortium. XML Pointer Language (XPointer). W3C Working Draft. Available at http://www.w3.org/TR/xptr

XQueryA Query Language for XML. Available at http://www.w3.org/TR/xquery/

XQLXML Query Language (XQL). Available at http://www.w3.org/TandS/QL/QL98/pp/xql.html

XSL

World Wide Web Consortium. Extensible Stylesheet Language (XSL). W3C Working Draft. Available at http://www.w3.org/TR/WD-xsl

XSLTWorld Wide Web Consortium. XSL Transformations (XSLT). W3C Recommendation. Available at http://www.w3.org/TR/xslt

Documents

Semantic Web Techniques - Lecture Notes - Harold Boley Bruce Spencer NRC-IIT Fredericton University of New Brunswick CS 6905 SWT 17 September 2003