Semantic Web Techniques Lecture Notes

1
Semantic Web Techniques- Lecture Notes -

• Harold BoleyBruce Spencer
• NRC-IIT Fredericton University of New Brunswick

CS 6905 SWT 17 September 2003
2
Introduction to the Semantic Web
Intro
Intro
3
National Research Council

• Research Institutes and Facilities across Canada
• 17 research institutes
• 4 innovation centres
• 3,500 employees 1,000 guest workers
• National science facilities
• ST information for industry and scientific
  community
• CISTI Canadian Inst. for Science and Tech
  Information
• Network of technology advisors supporting SME
• IRAP Industrial Research Assistance Program

Intro
4
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

Intro
5
NRCs 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
• NBs communications infrastructure and interested
  telco
• Bilingual workforce

Intro
6
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

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

Intro
8
Five main points

• Tim Berners-Lees vision
• web information should be machine understandable
• Taxonomies of words shared within web communities
• no single ontology
• RDF meta-tags link XML tags to their roles
• US and European buy-in
• Wheres Canada
• Aligns with IIT Frederictons thrusts
• multi-agent, security, OneWeb, voice

Intro
9
Overview and Course Mindmap

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

Namespaces
CSS
DTDs
XSLT
Stylesheets
DAML
Agents
Transformations
RACSA
XQL
XML
HornML
Rules
Queries
RuleML
XQuery
Intro
XML-QL
SHOE
RDFS
Frames
Acquisition
TopicMaps
Protégé
10
The Semantic Web Activityof the W3C

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

Intro
11
What your computer sees in HTML

• ltbgtJoes Computer Store
• lt/bgt
• ltbrgt
• 365 Yearly Drive

Presentation information
What your computer sees in XML
Intro
ltlocationgt ltnamegtJoes Computer
Store lt/namegt ltaddressgt 365 Yearly
Drive lt/addressgt lt/locationgt
Content description (less ambiguous)
12
What a computer could understand

• ltmailaddress xmlnsmailhttp//www.canadapost.ca
  gt
• ltmailnamegtJoes Computer Store lt/mailnamegt
• ltmailstreetgt 365 Yearly Drive lt/mailstreetgt
• lt/mailaddressgt
• www.canadapost.ca could define address, name,
  street,
• Search engines could then identify mail addresses
• Consider shopbots being able to find
• price, quantity, feature, model number, supplier,
  serial number, acquisition date
• Assumes that namespaces will be used consistently

Intro
13
Semantic Web

• Semantics meaning
• Good 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

Intro
14
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, 2001
• DAML DARPA Agent Markup Language
• US Gov funding to define languages, tools
• 16 project teams
• OIL is Ontology Inference Layer
• DAMLOIL is joint DARPA-EU
• Knowledge Representation is a natural choice

Intro
15

Intro
16

• SmokedSalmon is the intersection of Smoked and
  Salmon

Intro
17

• SmokedSalmon is the intersection of Smoked and
  Salmon

Intro
18

• SmokedSalmon is the intersection of Smoked and
  Salmon

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

Intro
19

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

• A search for keywords Salmon and Cured should
  return pages that mention Gravalax, even if they
  dont mention Salmon and Cured
• A search for Salmon and Smoked will return smoked
  salmon, should also return Lox, but not Gravalax

Smoked Salmon
Intro
Lox
20
OWL
Smoked Salmon
Lox
21
Tim Berners- Lees Semantic Web
Intro
22
RDF Resource Description Framework

• Beginning of Knowledge Representation influence
  on Web
• Akin to Frames, Entity/Relationship diagrams, or
  Object/Attribute/Value triples

Intro
23
RDF Example

• ltrdfProductSpecs about
• http//www.lemoncomputers.ca/model_2300gt
• ltspecscolourgtyellowlt/specscolourgt
• ltspecssizegtmediumlt/specssizegt
• lt/rdfProductSpecsgt

Intro
model_2300
size
colour
medium
yellow
24
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

Intro
model_2300
size
colour
medium
yellow
25
Tim Berners- Lees Semantic Web
Intro
26
Ontology Web Language W3C

• Previously known as DAMLOIL
• 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

Intro
27
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?

Intro
28
Ontology

• Branch of philosophy dealing with the theory of
  being
• Tarskis 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

Intro
29
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

Intro
30
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

Intro
31
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

Intro
32
Tim Berners- Lees Semantic Web
Intro
33
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 constraints
• Standard 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

Intro
34
Logic Architecture Example

• Contracting parties integrate e-businesses via
  rules

Seller E-Storefront
Buyers ShopBot
Business Rules
Business Rules
Intro
Contract Rules Interchange
OPS5
Prolog
35
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).

Intro
36
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

Intro
37
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

Intro
38
Extensible Markup Language
XML
XML
39
General Advantages of XML for KR
XML offers new general possibilities, from
which AI knowledge representation (KR) can profit
(1) Definition of self-describing data in
worldwide standardized, non-proprietary
format (2) Structured data and knowledge
exchange for enterprises in various
industries (3) Integration of information from
different sources (into uniform documents)
XML
40
Specific Advantages of XML for KR
XML provides the most suitable infrastructure for
knowledge bases on the Web (incl. for W3C
languages such as RDF) Additional special KR
uses of XML are

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

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

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

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

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

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

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

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

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

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

HornML
82
The Java Deductive Reasoning Engine for the Web
j-DREW
j-DREW
83
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 Warrens book Programming in Logic,
  1988
• Updated in Java?
• Specific to Prolog at low level

j-DREW
84
Will such a course work?

• No
• Guts of Prolog, Internet APIs, how to program in
  logic
• At least three courses here
• Yes
• Students understand recursion
• How to build a treehow to search a space
• Propositional theorem prover
• how to interface to Internet

j-DREW
85
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

j-DREW
86
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

j-DREW
87
Propositional Prover 1

• initially proofTree has an open Goal
• loop
• if(proofTree.hasNoOpenGoal())
• halt('success')
• else
• Goal g proofTree.selectOpenGoal()
• g.createMatchingClauseList()
• if(g.hasMoreMatchingClauses())
• g.attachNextMatchingClause()
• choicePoints.push(g)
• else
• chronologicalBacktrack()

j-DREW
88
Propositional Prover 2

• chronologicalBacktrack
• while(not choicePoints.empty())
• Goal g choicePoints.pop()
• g.removeAttachedClause()
• if(g.hasMoreMatchingClauses())
• return
• halt('failure')

j-DREW
89
Propositional Prover
chronologicalBacktrack
while(choicePoints.nonEmpty()) Goal
g choicePoints.pop()
g.removeAttachedClause()
if(g.hasMoreClauses())
return halt('failure')

• initially proofTree has an open Goal
• loop
• 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()

NEW
j-DREW
90
Tree with initial goal p(Z)

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

NEW
?-p(Z)
a
ChoicePoints
j-DREW
p(Y1) - q(Y1), r(Y1)
b
a
Z/Y1
91
Moving to First Order Logic

• Students struggle with variables
• Unification
• Composition of substitutions
• Unbinding on backtracking
• Can we hide the hard stuff?
• Powerful abstraction

j-DREW
92
Hiding the hard stuff
proof tree goal

• When attaching a clause to a Goal
• Matching clause must be an instance of input
  clause
• Semi-unification creates the instance
• Bindings to variables in goal may be propagated
  through tree now or later
• When removing the clause
• relax any propagated variable bindings

p(a, Y)
input clause
p(X, b) -
j-DREW
clause instance
p(a, b) -
propagated binding
Y?b
93
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
  valuesX ? f(a) Y ? a
• undoing pop stack of previous values (trail)

j-DREW
94
Choosing between shallow and deep

• Deep
• pay for each lookup (deep search)
• unbinding is cheap
• Shallow
• lookup is cheap (shallow search)
• may need many large arrays of possible variables
• j-DREW uses local shallow
• each clause has own array of just local
  variables, named 1, -2,
• scope is clause-wide
• so propagation necessary

j-DREW
95
Goal Tree and flatterms
N
p

• Each node has head and body atoms
• Body atoms form goals
• attach children
• resolved p1 from d ? p1, , pmagainst q
  from q ? q1, , qn
• resolved pm against r ?.

p1
pm
D
q
C
j-DREW
q1
qn
96
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

j-DREW
97
Variables are clause-specific

• Variables use negativeindexes
• Bindings are references to flatterm position
• Unifier X ? g2Y ? f(g2)W ? h(g2) Z ? f(g2)

j-DREW
98
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.

j-DREW
99
Evaluation of local shallow bindings

• Disadvantage for backtracking
• must propagate bindings to other nodes
• Advantage
• fast interaction with rest of system
• simple, no environments to pass around
• compact, no large arrays
• Appropriate
• for forward chaining
• no backtracking, no propagation
• Probably appropriate when backward chaining
  function-free logic
• Design decision to revisit

j-DREW
100
Discrimination trees

• Given a goal we want to access matching clauses
  quickly
• Every-argument addressing
• unlike Prologs first argument addressing
• Useful for RDF triples
• a pattern may have variable in first argument
• rdf(X, ownedby, Ora Lassila)

j-DREW
101
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

j-DREW

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

102
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

j-DREW

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

• Find unifiable
• combination of both

p(f(g1 ),h(g2 ),g1 )p(f(h( X )),h(Y ),f(Z, Z))
103
Iterator for matching clauses

• We use Java idioms where possible
• Javas 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(McCunes term jump-list)

j-DREW
104

NEW
j-DREW
105

• SmokedSalmon is the intersection of Smoked and
  Salmon

NEW
j-DREW
106

• SmokedSalmon is the intersection of Smoked and
  Salmon

NEW
j-DREW
107

• SmokedSalmon is the intersection of Smoked and
  Salmon

NEW

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

j-DREW
108

NEW

• A search for keywords Salmon and Cured should
  return pages that mention Gravalax, even if they
  dont 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
j-DREW
Lox
The Semantic Web vision is to make information on
the web understood by computers, for
searching, categorizing,
109
NEW
Smoked Salmon
j-DREW
Lox
110
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
dont mention Salmon and Cured.
NEW
j-DREW
about(p1, gravalax). retrieve(p1) succeeds
111

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

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

NEW
j-DREW
about(p1, gravalax). about(p2, lox). retrieve(p1)
fails retrieve(p2) succeeds
112
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

j-DREW
113
More working prototypesVariants of Top-Down
Engine

• User directed
• User selects goals
• User chooses clauses
• keeps track of clauses still left to try
• Good teaching tool
• Bounded 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

j-DREW
114
When to propagate bindings?

• When all subgoals closed (1)
• best option if selecting deepest goal
• When new clause is attached
• to all delayed goals (2)
• best option if sound negation or delaying goals
• to all open goals (3)
• best option if user selects
• Propagation on demand (4)
• lazy propagation
• Currently (1) and (3) working

proof tree goal
p(a, Y)
input clause
p(X, b) -
j-DREW
clause instance
p(a, b) -
propagated binding
Y?b
115
Not-yet-working Calls to users Java code

• Want this to incur little overhead
• Java programmer uses flatterms
• Interface to symbol table
• symbol lookup
• add new symbols
• Argument list an array of symbols
• Works with backtracking
• Users Java procedure is an iterator
• Works with forward reasoning

j-DREW
116
Dynamic additions

• Some asynchronous process loads new rules
• push technology
• Backward chaining
• additions are unnatural
• Using iterative bounds
• look for additions between bounds
• Forward chaining (next)

j-DREW
117
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 (Boyers
  PhD)
• Use standard search procedure to reduce redundant
  checking (next)
• Unlike OPS/Rete, returns proofs and uses first
  order syntax for atoms

j-DREW
118
Theorem Provers Search Procedure
main loop select new fact for each
matching rule resolve process new
result add to old facts

• Priority queue
• new facts
• Discrimination trees
• used facts
• rules, indexed onfirst goal

NEW
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
j-DREW
119
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
120
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

j-DREW
121
Related Work

• j-DREW compared to Prolog
• j-DREW not compiled
• More flexible
• Dynamic additions
• Web-ized
• Programmers API
• Performance requirements different
• j-DREW unlikely to yield megalips

j-DREW
122
Related Work

• Mandarax
• easy to use RuleML editor and engine
• CommonRules
• compiles priorities
• Datalog
• also top-down, bottom up
• shares view of single semantics for both

j-DREW
123
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, mobile
• Dynamic additions to rules
• Integration of RuleML and Prolog rules in same
  proofs
• Proofs available

j-DREW
124
The Rule Markup Language
RuleML
RuleML
125
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

RuleML

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

126
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/DAMLOIL for
• derivation, query, transformation (stable
  DTDs/Schemas)
• integrity checking (still regarded as special
  queries)
• reactive behavior (currently as translators to,
  e.g., Jess)

RuleML
127
Semantic Web and Web ServicesUse Databases and
Rule Systems
RuleML
128
Rule Systems forWeb-Based B2C or B2B Rule
Exchange
. . .
translate to standard format (e.g., RuleML)
publish rulebase1
publish rulebasem
RuleML
compare, instantiate, and run rulebases
129
From Natural Language to Horn Logic
RuleML
130
RuleML Markup and Tree
''The discount for a customer buying a product is
5.0 percent if the customer is premium and the
product is regular.''
ltimpgt lt_headgt ltatomgt
lt_oprgtltrelgtdiscountlt/relgtlt/_oprgt
ltvargtcustomerlt/vargt ltvargtproductlt/vargt
ltindgt5.0 percentlt/indgt lt/atomgt
lt/_headgt lt_bodygt ltandgt ltatomgt
lt_oprgtltrelgtpremiumlt/relgtlt/_oprgt
ltvargtcustomerlt/vargt lt/atomgt
ltatomgt lt_oprgtltrelgtregularlt/relgtlt/_oprgt
ltvargtproductlt/vargt lt/atomgt
lt/andgt lt/_bodygt lt/impgt
RuleML
131
Intertranslating RuleML and RFML
''The discount for a customer buying a product is
5.0 percent if the customer is premium and the
product is regular.''
ltimpgt lt_headgt ltatomgt
lt_oprgtltrelgtdiscountlt/relgtlt/_oprgt
ltvargtcustomerlt/vargt ltvargtproductlt/vargt
ltindgt5.0 percentlt/indgt lt/atomgt
lt/_headgt lt_bodygt ltandgt ltatomgt
lt_oprgtltrelgtpremiumlt/relgtlt/_oprgt
ltvargtcustomerlt/vargt lt/atomgt
ltatomgt lt_oprgtltrelgtregularlt/relgtlt/_oprgt
ltvargtproductlt/vargt lt/atomgt
lt/andgt lt/_bodygt lt/impgt
lthngt ltpattopgt ltcongtdiscountlt/congt
ltvargtcustomerlt/vargt ltvargtproductlt/vargt
ltcongt5.0 percentlt/congt lt/pattopgt
ltcallopgt ltcongtpremiumlt/congt
ltvargtcustomerlt/vargt lt/callopgt ltcallopgt
ltcongtregularlt/congt ltvargtproductlt/vargt
lt/callopgt lt/hngt
RuleML
132
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

RuleML
133
The Module Hierarchy of RuleML DTDs
ruleml
ur-equalog
Rooted DAG will be extended with branches for
further sublanguages
equalog
ur-hornlog
hornlog
ur-datalog
ur-datalog join(ur,datalog)
RuleML
datalog
bin-datalog
urc-datalog
ur
URL/URI-like ur-objects
urc-bin-datalog
urc-bin-data-ground-log
urc-bin-data-ground-fact
RDF-like triples
134
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
135
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

RuleML
136
Simple HTML/XML Ontology Extensions
SHOE
SHOE
137
SHOE Basics
SHOE (Simple HTML Ontology Extensions) (http//www
.cs.umd.edu/projects/plus/SHOE/) provides
distributed ontologies consisting of Categories
Organized hierarchically, with multiple
inheritance, for classifying instances Relationsh
ip rules Horn clauses (the first well-known Horn
language publishing KBs in the Web) SHOE
originally specified in HTML (before the
definition of XML) meanwhile also specified as
an XML DTD
SHOE
138
Instances (Individuals) as URLs/URIs
Individual constants in SHOE are represented
through an (official) URL/URI In the earlier
Horn-rule example there appear two
individuals, which could be represented in SHOE,
e.g., as eurostar http//www.eurostar.com/ ch
annel-tunnel http//www.eurotunnel.com/
SHOE
139
A SHOE Rule
With these URLs/URIs, the rule in SHOE becomes
ltDEF-INFERENCE DESCRIPTION"travel(?someone,
http//www.eurotunnel.com/) if
carry(h