THIS SLIDE INTENTIONALLY LEFT BLANK DAMLOIL Schema Parameter
THIS SLIDE INTENTIONALLY LEFT BLANK
DAML+OIL Schema Parameter Interface Format IHMC DAML+OIL has no natural role for variables, and no variable binders. This may well be seen as an advantage: (subclass A B) <==> (forall (? x)(implies (A ? x)(B ? x))) P is restriction of Q on R to S <==> (forall (? x) (iff (P ? x)(and (Q ? x)(exists (? y)(and (R ? x ? y) (S ? y))))))
DAML+OIL Schema Parameter Interface Format IHMC However, many uses of, and likely future extensions to, DAML+OIL require the use of variables to allow patternmatching: 1. allowing external software to bind values to parameters (Co. ABS policy tool; DAML-S applications) 2. syntax for atomic component of 'rules' and queries 3. controlling use of URL's across networks (as in HORUS)
DAML+OIL Schema Parameter Interface Format IHMC Changing DAML to include variables raises a host of semantic issues which we propose to completely avoid. This is a purely syntactic proposal. No semantics is provided for the variables until they have been completely instantiated. In logical terms, these are schematic (not quantified) variables; in programming language terms, they are macros. To avoid confusion we call them parameters. DAML+OIL distinguishes two kinds of 'name': URIs and literals. The proposal is an extended notation in which URI's may be replaced by URI parameters and literals by literal parameters.
DAML+OIL Schema Parameter Interface Format IHMC Uri-parameter : : = ? word / Literal-parameter : : = ? ? word / word : : = [^< > ? / space ]+ <Or some other syntax would do> A URI [literal] term is either a URI [literal] or a URI [literal] parameter. A substitution is a sequence of substitution pairs consisting of a URI [literal] parameter and a URI [literal] term.
DAML+OIL Schema Parameter Interface Format IHMC <daml: Class rdf: ID=“? action. Type/” > <rdfs: label>? action. Type/</rdfs: label> <rdfs: sub. Class. Of rdf: resource="#Ordinary Action"/> <rdfs: sub. Class. Of> <daml: Restriction daml: Cardinality="1”> <daml: on. Property rdf: resource="#performed. By"/> <daml: to. Class rdf: resource="? performer/"/> </daml: Restriction> </rdfs: sub. Class. Of> </daml: Class>
DAML+OIL Schema Parameter Interface Format IHMC <daml: Class rdf: ID=“? action. Type/” > <rdfs: label>? action. Type/</rdfs: label> <rdfs: sub. Class. Of rdf: resource="#Ordinary Action"/> <rdfs: sub. Class. Of> <daml: Restriction daml: Cardinality="1”> <daml: on. Property rdf: resource="#performed. By"/> <daml: to. Class rdf: resource=”? performer/"/> </daml: Restriction> </rdfs: sub. Class. Of> </daml: Class> ? action. Type/ #Delegate. Action ? performer/ #Domain_Manager ? action. Type/ #Multi_Actor_Action ? performer/ #Actor. Group
A more compact notation (with Frank v. Harmelen) IHMC <rdfs: Class rdf: ID="elephant"> <rdfs: sub. Class. Of> <rdfs: Class rdf: about="#animal"/> </rdfs: sub. Class. Of> <daml: Restriction> <daml: on. Property rdf: resource="#eats"/> <daml: to. Class> <rdfs: Class rdf: about="#plant"/> </daml: to. Class> </daml: Restriction> </rdfs: sub. Class. Of> <daml: Restriction> <daml: on. Property rdf: resource="#colour"/> <daml: has. Value> <daml: Concrete. Type. Expression>EQUAL ``grey'' </daml: Concrete. Type. Expression> </daml: has. Value> </daml: Restriction> </rdfs: sub. Class. Of> </rdfs: Class> Class elephant Sub. Class. Of #animal [which #eats #plant; which #color EQUAL `grey’]
A more compact notation (with Frank v. Harmelen) IHMC <rdfs: Class rdf: ID="herbivore"> <daml: intersection. Of> <rdfs: Class rdf: about="#animal"/> <daml: Restriction> <daml: on. Property rdf: resource="#eats"/> <daml: to. Class> <rdfs: Class> <daml: union. Of> <rdfs: Class rdf: about="#plant"/> <daml: Restriction> <daml: on. Property rdf: resource="#is_part_of"/> <daml: has. Value> <rdfs: Class rdf: about="#plant"/> </daml: has. Value> </daml: Restriction> </daml: union. Of> </rdfs: Class> </daml: to. Class> </daml: Restriction> </daml: intersection. Of> </rdfs: Class> Class herbivore Intersection. Of [#animal which #eats Union. Of [#plant; which #is_part_of has. Value #plant] ]
IHMC A brief essay inspired by conversations with Lynn Stein Bill Andersen Jim Hendler Adam Pease Jerry Hobbs and others too numerous to mention
IHMC <rdf: RDF xmlns: rdf =http: //www. w 3. org/1999/02/22 -rdf-syntax-ns# xmlns: a =http: //someplace. org/this_ontology# xmlns: b=http: //some_other_place. gov/that_ontology# <daml: Class rdf: ID=”Barble"> <rdfs: sub. Class. Of> <daml: Restriction> <daml: on. Property rdf: resource=”a#foodle"/> <daml: to. Class rdf: resource=”b#bazset"/> </daml: Restriction> </rdfs: sub. Class. Of> </daml: Class>
IHMC If I use a term from your ontology, how much of your ontology am I assuming?
IHMC If I use a term from your ontology, how much of your ontology am I assuming? A 1: Only the parts that I explicitly endorse or include
IHMC If I use a term from your ontology, how much of your ontology am I assuming? A 1: Only the parts that I explicitly endorse or include A 2: Enough to establish the intended meaning of the term
IHMC If I use a term from your ontology, how much of your ontology am I assuming? A 1: Only the parts that I explicitly endorse or include A 2: Enough to establish the intended meaning of the term A 3: All of it
IHMC If I use a term from your ontology, how much of your ontology am I assuming? A 1: Only the parts that I explicitly endorse or include A 2: Enough to establish the intended meaning of the term A 3: All of it A 4: None of it
IHMC If I use a term from your ontology, how much of your ontology am I assuming? Wrong answer: The question doesn’t arise since we are all basically part of One World Wide Ontology
IHMC OK, at least we are using the same notation, which is a good start.
IHMC OK, at least we are using the same notation, which is a good start. BUT if you are using a closed world assumption and I am not, we will misunderstand one another.
IHMC OK, at least we are using the same notation, which is a good start. BUT
IHMC You say… Employees are a subclass of persons I say… Employment is a property some people have
IHMC You say… Things are physical objects I say… Things include ideas, integers, intentions, states of mind, The Grinch…
IHMC You say… Things are physical objects I say… Things include ideas, integers, intentions, states of mind, The Grinch, fluents, tropes, eventualities, ways of being, possible worlds, whatever
IHMC You say… Things are physical objects I say… Things are physical objects
IHMC You say… Things are physical objects I say… Things are physical objects BUT You say… Physical objects retain their identity through time and change their properties I say… Physical objects have temporal parts which have timeless properties
IHMC You say… Things are physical objects I say… Things are physical objects BUT You say… Physical objects retain their identity through time and change their properties I say… Physical objects have temporal parts which have timeless properties
Describing events/actions/processes/occurrents/happenings… Things change…so need to make assertions relative to times Trickle. Down: push temporal parameters as deep into the expression as they need to go (but no further). R(a, b, c) + T Often most natural language for humans [R(a, b, c), T] simple proposition true at time [R, T](a, b, c) time-indexed relation (eg position) R(a, b, c, [T]) time-relative assertion R([a, T], b, [c, T]) dynamic entities Corresponds to linguistic analyses Often most effective for action planning Often most effective for automatic reasoning about complex domain
IHMC You say… holes are physical things, and holes can only be whole I say… holes are spatio-temporal but not physical, and can have parts He says… holes aren’t physical, but are necessarily located in physical things and cannot have parts And he says… holes don’t exist as entities, but are locations which are empty.
IHMC Which ontology should be chosen/adopted/made into the standard?
IHMC Which ontology should be chosen/adopted/made into the standard? WRONG QUESTION ! All these viewpoints have their uses, are internally coherent and are legitimate points of view. There is no single best answer.
IHMC Long Term Ways to broker meanings between different ontological perspectives (translation techniques, known safe routes, neutral ontological territory. ) Medium Term Ways to SAY what parts of one ontology are being included into another, and to analyze the consequences. Short Term Agree that there is a problem to be solved. LUNCH
- Slides: 31