Hi Lukasz,
Here is a typical Capability Description from my first set of bootstrap cases:
(capability
name: "defineInstanceVariable"
description: "Defines an instance variable having the given name and object
type."
preconditions:
(<rdf:type> ?variable-name <cyc:NonEmptyCharacterString>)
(<rdf:type> ?object-type <owl:Thing>)
(<rdf:type> ?variable-comment <cyc:NonEmptyCharacterString>)
(<rdf:type> ?variable-invariant-conditions <cyc:Tuple>)
(implies
(<cyc:memberOfTuple> ?variable-invariant-condition
?variable-invariant-conditions)
(<rdf:type> ?variable-invariant-condition <cyc:CycLFormula>))
input-roles:
(<texai:blRole> ?variable-name "a variable name")
(<texai:blRole> ?object-type "a type")
(<texai:blRole> ?variable-comment "a comment")
(<texai:blRole> ?variable-invariant-conditions "some invariant conditions")
output-roles:
(<texai:blRole> ?defined-instance-variable "the defined instance variable")
postconditions: ;;TODO properties of the output with regard to the inputs
(<rdf:type> ?defined-instance-variable
<texai:org.texai.bl.domainEntity.BLInstanceVariable>)
)
I think that the restriction you propose is not expressive enough to handle
this case. If I am wrong please correct me. The matching is performed on the
preconditions, postconditions and invariant-conditions. The latter is not
illustrated in this example but consist of implications similar in form to the
one found in the preconditions of this example.
For the others on this list following my progress, the example is from a set of
essential capability descriptions that I'll use to bootstrap the skill
acquisition facility of the the Texai dialog system. The subsumption-based
capability matcher is done. I'm writing Java code that implements each of
these capabilities. That should be completed in a few more days, and then I'll
fit that into the already completed dialog system. At that point I should be
able to begin exploring what essential utterances will be needed to acquire
skills by being taught, and generate Java programs to perform them.
-Steve
Stephen L. Reed
Artificial Intelligence Researcher
http://texai.org/blog
http://texai.org
3008 Oak Crest Ave.
Austin, Texas, USA 78704
512.791.7860
----- Original Message ----
From: Lukasz Stafiniak <[EMAIL PROTECTED]>
To: [email protected]
Sent: Saturday, May 17, 2008 12:40:28 PM
Subject: [agi] Uninterpreted RDF terms
Steve,
How severe would you consider a restriction on RDF graphs that would
allow at most one incoming and at most one outgoing edge with a given
label, for capability descriptions? This would allow to do unification
(and generalization aka. intersection) on graphs easily (not as easily
as on terms, but nearly). Outside the system where it would be needed
(I have automatic programming / program analysis in mind), the
theory/graphs can be extended of course. For example, the parenting
relation would have to be split into "x offspring_i y" means "x is the
i-th offspring of y", and we could also add "outgoing" and "incoming"
restrictions, e.g. that a node cannot have incoming "offspring_i" and
"offspring_j" edges for i <> j. Outside, we would have the implication
"x offspring_i y ==> x offspring y".
Best wishes.
-------------------------------------------
agi
Archives: http://www.listbox.com/member/archive/303/=now
RSS Feed: http://www.listbox.com/member/archive/rss/303/
Modify Your Subscription: http://www.listbox.com/member/?&;
Powered by Listbox: http://www.listbox.com
-------------------------------------------
agi
Archives: http://www.listbox.com/member/archive/303/=now
RSS Feed: http://www.listbox.com/member/archive/rss/303/
Modify Your Subscription:
http://www.listbox.com/member/?member_id=8660244&id_secret=103754539-40ed26
Powered by Listbox: http://www.listbox.com
