1 / 203

Tutorial on Knowledge Markup and Resource Semantics

Tutorial on Knowledge Markup and Resource Semantics. Harold Boley Stefan Decker Michael Sintek. IJCAI-01 Seattle 6 August 2001 (version: 20 August 2001). Overview and Tutorial Mindmap. Increasing demand for formalized knowledge on the Web: AI’s chance!

judd
Download Presentation

Tutorial on Knowledge Markup and Resource Semantics

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Tutorial onKnowledge Markup andResource Semantics Harold BoleyStefan DeckerMichael Sintek IJCAI-01 Seattle6 August 2001 (version: 20 August 2001)

  2. Overview and Tutorial Mindmap • Increasing demand for formalized knowledge on the Web: AI’s chance! • XML- & RDF-based markup languages provide a 'universal' storage/interchange format for such Web-distributed knowledge representation • Tutorial introduces knowledge markup & resource semantics: we show how to marry AI representations (e.g., logics and frames) with XML & RDF [incl. RDF Schema] Namespaces CSS DTDs XSLT DAML Stylesheets Agents Transformations Ontobroker XQL XML HornML Rules Queries XQuery RuleML Mindmap XML-QL SHOE RDF[S] Frames Acquisition TopicMaps Protégé IJCAI-01 Knowledge Markup and Resource Semantics

  3. Web Languages forKnowledge Capturing • Human knowledge is (partially) captured on the Web as informal texts, semiformal documents, and structured metadata • Each kind of knowledge has its (preferred) markup language Knowledge Markup IJCAI-01 Knowledge Markup and Resource Semantics

  4. Web Languages forMachine Interpretation • XML (Extensible Markup Language): Semiformal documents range between non-formatted texts and fully formatted databases • RDF (Resource Description Framework): Structured metadata describe arbitrary heterogeneous Web pages/objects in a homogeneous manner Knowledge Markup Machines (e.g. search engines) can analyze XML or RDF markups better than full HTML IJCAI-01 Knowledge Markup and Resource Semantics

  5. The Semantic Web Activityof the W3C • “The Semantic Web is a vision: the idea of having • data on the Web defined and linked in a way that • it can be used by machines not just for display purposes, • but for • automation, • integration and • reuse of data across various applications.” • (http://www.w3.org/2001/sw/Activity) Semantic Web IJCAI-01 Knowledge Markup and Resource Semantics

  6. The Semantic Web Layered Architecture Tim Berners-Lee: “Axioms, Architecture and Aspirations” W3C all-working group plenary Meeting 28 February 2001 Semantic Web (http://www.w3.org/2001/Talks/0228-tbl/slide5-0.html) IJCAI-01 Knowledge Markup and Resource Semantics

  7. The Semantic Web Layered Architecture: Where are the Semantic Web Semantics? Tim Berners-Lee: “Axioms, Architecture and Aspirations” W3C all-working group plenary Meeting 28 February 2001 Semantic Web (http://www.w3.org/2001/Talks/0228-tbl/slide5-0.html) This tutorial discusses knowledge markup for the Semantic Web, together with the required resource semantics IJCAI-01 Knowledge Markup and Resource Semantics

  8. Partial Orders Practical need for Web semantics: Corresponding semantic techniques: Hierarchical structure (i.e., the “taxonomy” part of an “ontology”) for arbitrary domains of discourse Partial orders over sets of arbitrary objects (classes, relations, ...) permit inheritance down the “>”-links of tree-generalizing DAGs (Directed Acyclic Graphs) Partial Orders IJCAI-01 Knowledge Markup and Resource Semantics

  9. Financial Math Excerpt from Mathematics International Ontology as RDF Schema Prolog-like Syntax: subsumes(fm,management_mathematics_fm). subsumes(fm,math_fm). XML Syntax: RFML DAG (Relfun’s sortbase browser): Application RDF Schema: <rdf:Class rdf:ID="management_mathematics_fm"> <rdfs:subClassOf rdf:resource="#fm"/> </rdf:Class> <rdf:Class rdf:ID="math_fm"> <rdfs:subClassOf rdf:resource="#fm"/> </rdf:Class> XSLT Stylesheet: rfml2rdfs.xsl DAG (FRODO RDFSViz rendering):taxonomy.gif IJCAI-01 Knowledge Markup and Resource Semantics

  10. Metadata (Resource) Semantics Practical need for Web semantics: Corresponding semantic techniques: Annotating arbitrary Web objects in RDF/XML for semantic retrieval Metadata semantics in XML-based RDF and RDF Schema enables high-precision search engines for Berners-Lee’s "Semantic Web" Metadata IJCAI-01 Knowledge Markup and Resource Semantics

  11. Shape Shape flat nested ConvertsTo Knowledge Markup &Resource Semantics: XML Documents with RDF Annotations http://addr.flat.com http://addr.nest.com <addresses> <rdf:RDF xmlns=“http://www.w3.org/…”> <rdf:Description about=“”> <Shape>flat</Shape> <ConvertsTo resource=“http://addr.nest.com”/> </rdf:Description> </rdf:RDF> <address> <name>Me2XML</name> <street>96 Hyper Road</street> <town>Boston</town> </address> <address> <name>RDF4All</name> <street>2001 Broadway</street> <town>New York</town> </address> . . . </addresses> <addresses> <rdf:RDF xmlns=“http://www.w3.org/…”> <rdf:Description about=“”> <Shape>nested</Shape> <ConvertsTo resource=“http://addr.flat.com”/> </rdf:Description> </rdf:RDF> <address> <name>Me2XML</name> <place> <street>96 Hyper Road</street> <town>Boston</town> </place> </address> . . . </addresses> KM & RS IJCAI-01 Knowledge Markup and Resource Semantics

  12. Extensible Markup Language XML XML IJCAI-01 Knowledge Markup and Resource Semantics

  13. General Advantages of XML for KR XML offers new general possibilities, from which AI knowledge representation (KR) can profit: (1) Definition of self-describing data in worldwide standardized, non-proprietary format (2) Structured data and knowledge exchange for enterprises in various industries (3) Integration of information from different sources (into uniform documents) XML IJCAI-01 Knowledge Markup and Resource Semantics

  14. Specific Advantages of XML for KR XML provides the most suitable infrastructure for knowledge bases on the Web (incl. for W3C languages such as RDF) Additional special KR uses of XML are: • Uniform storage of knowledge bases • Interchange of knowledge bases between different AI languages • Exchange between knowledge bases and databases, application systems, etc. XML Even transformation/compilation of AI source programs using XML markup and annotations is possible IJCAI-01 Knowledge Markup and Resource Semantics

  15. Address Example: External to HTML External Presentation: Xaver M. Linde Wikingerufer 7 10555 Berlin HTML tags are still presentation-oriented XML HTML Markup: <em>Xaver M. Linde</em> <br> Wikingerufer 7 <br> <strong>10555 Berlin</strong> IJCAI-01 Knowledge Markup and Resource Semantics

  16. Address Example: HTML to XML HTML Markup: While not conveying any formal semantics: <em>Xaver M. Linde</em> <br> Wikingerufer 7 <br> <strong>10555 Berlin</strong> XML tags are chosen for content-structuring needs XML XML Markup: <address> <name>Xaver M. Linde</name> <street>Wikingerufer 7</street> <town>10555 Berlin</town> </address> IJCAI-01 Knowledge Markup and Resource Semantics

  17. Address Example: XML to External XML Markup: <address> <name>Xaver M. Linde</name> <street>Wikingerufer 7</street> <town>10555 Berlin</town> </address> 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 . . . IJCAI-01 Knowledge Markup and Resource Semantics

  18. Address Example: XML to XML XML Markup 1: <address> <name>Xaver M. Linde</name> <street>Wikingerufer 7</street> <town>10555 Berlin</town> </address> XML stylesheets are also usable to transform XML representations XML XML Markup 2: <address> <name>Xaver M. Linde</name> <place> <street>Wikingerufer 7</street> <town>10555 Berlin</town> </place> </address> IJCAI-01 Knowledge Markup and Resource Semantics

  19. Address Example: Some Stylesheets Will Contain Term-(Tree-)Rewriting Rules address name street town T S N XML address name place street town N T S IJCAI-01 Knowledge Markup and Resource Semantics

  20. Address Example: XML Queries XML Markup: subelements element <address> <name>Xaver M. Linde</name> <street>Wikingerufer 7</street> <town>10555 Berlin</town> </address> s XML Query (XML-QL): WHERE <address> <name>Xaver M. Linde</name> <street>$s</street> <town>$t</town> </address> CONSTRUCT <binding> <s>$s</s> <t>$t</t> </binding> XML XML queries can select subelements of XML elements <binding> <s>Wikingerufer 7</s> <t>10555 Berlin</t> </binding> IJCAI-01 Knowledge Markup and Resource Semantics

  21. Address Example: Prolog Queries Prolog Term: substructures address( name("Xaver M. Linde"), street("Wikingerufer 7"), town("10555 Berlin") ) s structure XML Prolog Query: Prolog queries can select substructures of Prolog structures address( name("Xaver M. Linde"), street(S), town(T) ) S = "Wikingerufer 7" T = "10555 Berlin" IJCAI-01 Knowledge Markup and Resource Semantics

  22. Prolog Term: substructures address( name("Xaver M. Linde"), street("Wikingerufer 7"), town("10555 Berlin") ) s structure Node-Labeled, (Left-to-Right-)Ordered Element Tree: tree XML Markup: address subelements <address> <name>Xaver M. Linde</name> <street>Wikingerufer 7</street> <town>10555 Berlin</town> </address> element s subtrees name street town Xaver M. Linde Wikingerufer 7 10555 Berlin Address Example: The Element Tree XML IJCAI-01 Knowledge Markup and Resource Semantics

  23. Document Type Tree: address name street town PCDATA PCDATA PCDATA Address Example:Document Type Definition and Tree (1) Document Type Definition (DTD): Extended Backus-Naur Form (EBNF): <!ELEMENT address (name, street, town) > <!ELEMENT name (#PCDATA) > <!ELEMENT street (#PCDATA) > <!ELEMENT town (#PCDATA) > address ::= namestreettown name ::= PCDATA street ::= PCDATA town ::= PCDATA XML IJCAI-01 Knowledge Markup and Resource Semantics

  24. Address Example:Document Type Definition and Tree (2) Document Type Definition (DTD): <!ELEMENT address (name, place) > <!ELEMENT place (street, town) > <!ELEMENT name (#PCDATA) > <!ELEMENT street (#PCDATA) > <!ELEMENT town (#PCDATA) > Document Type Tree: XML address name place street town PCDATA PCDATA PCDATA IJCAI-01 Knowledge Markup and Resource Semantics

  25. 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) Well-Formedness and Validity XML principles for a document being well-formed: XML principle for a document being validwith respect to (w.r.t.) a DTD : XML Checked by validators such as http://www.stg.brown.edu/service/xmlvalid/ IJCAI-01 Knowledge Markup and Resource Semantics

  26. XML Markup: Prolog Term: <address> <name>Xaver M. Linde</name> <box>2001</box> <town>10555 Berlin</town> </address> address( name("Xaver M. Linde"), box("2001"), town("10555 Berlin") ) address name town box Xaver M. Linde 10555 Berlin 2001 Mail-Box Example: Address Variant XML Node-Labeled, (Left-to-Right-)Ordered Element Tree: IJCAI-01 Knowledge Markup and Resource Semantics

  27. "|"-Disjoined Street/Mail-Box Example:Document Type Definition and Tree Document Type Definition (DTD): <!ELEMENT address (name, (street | box), town) > <!ELEMENT name (#PCDATA) > <!ELEMENT street (#PCDATA) > <!ELEMENT box (#PCDATA) > <!ELEMENT town (#PCDATA) > "|": Choice The above box address and the original street address are valid w.r.t. this "|"-DTD XML Document Type Tree: address name town street box PCDATA PCDATA PCDATA PCDATA IJCAI-01 Knowledge Markup and Resource Semantics

  28. XML Markup: <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> 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/1234568 030/1234569 IJCAI-01 Knowledge Markup and Resource Semantics

  29. "+"/"*"-Repetitive-Phone & -Fax Example:Document Type Definition and Tree Document Type Definition (DTD): <!ELEMENT address (name, street, town, phone+, fax*) > <!ELEMENT name (#PCDATA) > <!ELEMENT street (#PCDATA) > <!ELEMENT town (#PCDATA) > <!ELEMENT phone (#PCDATA) > <!ELEMENT fax (#PCDATA) > "+"/"*": 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 IJCAI-01 Knowledge Markup and Resource Semantics

  30. XML Markup: <address> <name>Xaver M. Linde</name> <street>Wikingerufer 7</street> <town>10555 Berlin</town> <country>Germany</country> </address> 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 IJCAI-01 Knowledge Markup and Resource Semantics

  31. "?"-Optional-Country Example:Document Type Definition and Tree Document Type Definition (DTD): <!ELEMENT address (name, street, town, country?) > <!ELEMENT name (#PCDATA) > <!ELEMENT street (#PCDATA) > <!ELEMENT town (#PCDATA) > <!ELEMENT country (#PCDATA) > "?": 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 IJCAI-01 Knowledge Markup and Resource Semantics

  32. Country Address: A Complete XML Document Referring to an External DTD XML Document (just ASCII, e.g. stored in a file): <?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 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") IJCAI-01 Knowledge Markup and Resource Semantics

  33. Horn Logic Markup Languages HornML HornML IJCAI-01 Knowledge Markup and Resource Semantics

  34. Herbrand Terms: Individual Constants,Variables, Flat Ground Structures, ... Representation of Herbrand terms in XML as<ind> and<struc>elements (<var> similar): • 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: HornML <struc> <constructor>undersea-connection</constructor> <ind>britain</ind> <ind>france</ind> </struc> IJCAI-01 Knowledge Markup and Resource Semantics

  35. Herbrand Terms: ...,Nested Ground Structures <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: service-tunnel( undersea-connection( britain, surrounded-country( belgium, luxembourg, germany, switzerland, italy, spain))) HornML IJCAI-01 Knowledge Markup and Resource Semantics

  36. Interim Discussion: Tag and Type • In Prolog not clear, in isolation, that channel-tunnel is individual constant, whereas service-tunnel is constructor • In XML, as in strongly typed LP languages, made explicit - however at every occurrence of a symbol • Example gives impression of self-description advantage - but also ‘space requirement’ - of this generous application of “syntactic sugar” HornML IJCAI-01 Knowledge Markup and Resource Semantics

  37. 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> HornML IJCAI-01 Knowledge Markup and Resource Semantics

  38. 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> HornML IJCAI-01 Knowledge Markup and Resource Semantics

  39. Horn Clauses: Rules Then, Horn rule is asserted as <hn> Element that has a head <relationship> element followed by at least one body <relationship> element So, above example generalized to Prolog rule travel(Someone,channel-tunnel) :- carry(eurostar,Someone). <hn> <relationship> <relator>travel</relator> <var>someone</var> <ind>channel-tunnel</ind> </relationship> <relationship> <relator>carry</relator> <ind>eurostar</ind> <var>someone</var> </relationship> </hn> and rewritten as HornML IJCAI-01 Knowledge Markup and Resource Semantics

  40. Attributes for Extended Logics Nested elements - trees - allow representation of arbitrary information, but in some situations lead to unnecessarily deeply/widely nested representations Therefore XML attributes: Start-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 of relation symbols such as our binary relation symbol travel: Prolog’s travel/2 in XML with an arity attribute becomes <relator arity="2">travel</relator> Analogously, annotations become possible on arbitrary element levels: mode declarations for logic variables, determinism specifications for clauses or procedures, and context conditions for entire knowledge bases HornML IJCAI-01 Knowledge Markup and Resource Semantics

  41. ID and IDREF Attribute types ID and IDREF for naming and referencing of elements ID-typed value must uniquely identify an element and IDREF-typed value must occur as ID value of an element E.g., clause can be named (in a hypothesis knowledge base): <hn id="john-channel"> <relationship> <relator>travel</relator> <ind>john</ind> <ind>channel-tunnel</ind> </relationship> </hn> HornML IJCAI-01 Knowledge Markup and Resource Semantics

  42. ID and IDREF 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’ HornML IJCAI-01 Knowledge Markup and Resource Semantics

  43. DTDs: Elements as Derivation Trees Up to now: Examples for Horn Logic in XML etc. Now: General language definition XML's Document type definitions (DTDs) initially only as ELEMENT declarations for non-attributed elements For nonterminals: DTD  ordinary context-free grammar in modified (EBNF) notation For terminals: Usually arbitrary permutations of the base alphabet ("PCDATA'') instead of fixed terminal sequences DTD grammar derives context-free word patterns: derivation trees themselves - linearized through brackets - as generated result XML element is valid with respect to DTD: can be generated from DTD as linearized derivation tree HornML IJCAI-01 Knowledge Markup and Resource Semantics

  44. DTDs: Defining Horn Logic in XML Syntactic ELEMENT declaration of Horn logic as a knowledge base (kb) of zero or more Horn clauses (hn*): <!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) > HornML Note struc recursion! IJCAI-01 Knowledge Markup and Resource Semantics

  45. DTDs:Generation of the Example Rule (1) (Start-)symbol kb brackets derived clause(s) as linearized start-tag/end-tag-tree representation <kb> . . . </kb>: kb <kb> hn* </kb> . . . <kb> <hn> relationship relationship </hn> </kb> . . . <kb> <hn> <relationship> <relator>#PCDATA</relator> <var>#PCDATA</var> <ind>#PCDATA</ind> </relationship> <relationship> <relator>#PCDATA</relator> <ind>#PCDATA</ind> <var>#PCDATA</var> </relationship> </hn> </kb> HornML IJCAI-01 Knowledge Markup and Resource Semantics

  46. DTDs:Generation of the Example Rule (2) <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> HornML IJCAI-01 Knowledge Markup and Resource Semantics

  47. Attribute DTDs (1) DTDs for attributed elements: ATTLIST declarations, which associate element name with an attribute name plus attribute type and possible occurrence indication 1st Example: declare the relator attribute arity as CDATA-typed (cf. #PCDATA) and occurring optionally (#IMPLIED): <!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 > HornML IJCAI-01 Knowledge Markup and Resource Semantics

  48. Attribute DTDs (2) 2nd Example (Execution): Append an ATTLIST declaration that specifies, for the hn respectively prop elements, the attributes id - as optional ID type - respectively idref - as mandatory IDREF type: <!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 HornML IJCAI-01 Knowledge Markup and Resource Semantics

  49. Horn Queries in XML Notation 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 HornML IJCAI-01 Knowledge Markup and Resource Semantics

  50. Horn Queries in XML-QL Implementation Assume the fact is extended by prem(ises)/arity/pos(ition) attributes: <hn prem='0'> <relationship arity='2'> <relator>carry</relator> <ind pos='1'>eurostar</ind> <ind pos='2'>fred</ind> </relationship> </hn> Then in XML-QL the query can be implemented like this: WHERE <hn prem='0'> <relationship arity='2'> <relator>carry</relator> <ind pos='1'>eurostar</ind> <ind pos='2'>$someone</ind> </relationship> </hn> CONSTRUCT <binding><someone>$someone</someone></binding> HornML IJCAI-01 Knowledge Markup and Resource Semantics

More Related