Re: [xml-dev] Generating New Knowledge by Deductive Reasoning using Sche

[Stephen Green <stephengreenubl@gmail.com>]

In essence what I think is needed here is to have the report be XML.
Can Schematron do this? If not maybe the report could be as escaped
XML with a second step (e.g. with Xproc) running some XSLT to unescape
it. Then you could have the Schematron deduction do the following:

<sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron";
   xmlns:xs="http://www.w3.org/2001/XMLSchema";
   queryBinding="xslt2">

   <sch:pattern id="Check-Speeder-For-Relationship-To-Recent-Events">

      <sch:rule context="driversLicenseNumber">

         <sch:let name="speeder-driversLicenseNumber" value="."/>

         <sch:let name="GunLicense" value="for $i in
collection('GunLicenseFolder?select=*.xml;recurse=yes;on-error=ignore')
                                           return
$i/GunLicense[.//Person/driversLicenseNumber eq
$speeder-driversLicenseNumber]"/>

        <sch:report test="($speeder-driversLicenseNumber eq
$GunLicense//Person/driversLicenseNumber) and
            ($GunLicense/registeredGun/Gun/serial eq
doc('Robbery.xml')/RobberyEvent/evidence/Gun/serial) and
            (count($GunLicense) eq 1) and
            (count($GunLicense//Person) eq 1)">
           &lt;RobberyEvent&gt;
           &lt;datetime&gt;<sch:value-of
select="doc('Robbery.xml')/RobberyEvent/datetime"/>&lt;/datetime&gt;
           &lt;description&gt;<sch:value-of
select="doc('Robbery.xml')/RobberyEvent/description"/>&lt;/description&gt;
           &lt;evidence&gt;
           &lt;Gun&gt;
           &lt;serial&gt;<sch:value-of
select="doc('Robbery.xml')/RobberyEvent/evidence/Gun/serial"/>&lt;/serial&gt;
           &lt;/Gun&gt;
           &lt;/evidence&gt;
           &lt;robber&gt;
           &lt;Person&gt; <sch:value-of
select="parent::Person/child::name"/> &lt;/Person&gt;
           &lt;/robber&gt;
           &lt;/RobberyEvent&gt;
         </sch:report>

      </sch:rule>

   </sch:pattern>

</sch:schema>

This way the report can simply be (either from one or two steps):

<RobberyEvent>
    <datetime>2010-11-16T0500-00-00</datetime>
    <description>Robbery occurred, gun was dropped while fleeing</description>
    <evidence>
        <Gun>
            <serial>ABCD</serial>
        </Gun>
    </evidence>
    <robber>
        <Person>Fred Blogs</Person>
    </robber>
</RobberyEvent>


which allows further deductions to be made which include this report in
their input.

Best regards

Steve
---
Stephen D Green




On 21 November 2010 16:46, Stephen Green <stephengreenubl@gmail.com> wrote:
> Thanks Rick. Great stuff to look into. I'm especially interested in how
> best to output the report such that the report can be 'queried' by some
> subsequent Schematron rules. Now it occurs to me that there are two
> features which might need to be a lot more mature so that we can have
> a kind of logic ecosystem supporting automated deduction alongside
> statements in prose which are not necessarily for automated deduction:
>
> 1. The assertions could be more general statements of 'facts' rather than
> being limited to test assertions. (Can a Schematron assertion/rule include a
> 'statement' of fact which is not necessarily a assertion to be tested?)
>
> 2. The output from both assertion-driven 'tests' and more general 'deductions'
> based on the more general 'statements' can be marked up in the same markup
> so that they provide input for further tests and deductions
>
> I worked with OASIS TAG TC on something similar, as you know, but even
> here there may need to be more progress or external development such that
> 'test' and 'deduction' results can share the same markup with the
> input. i.e. that
> markup may need to be generalised beyond 'assertions' to include other kinds
> of statements too so that any output can be represented with the same markup.
> Plus the 'deduction' side of things put forward by Roger could perhaps do with
> more support.
>
> Ontology languages might need adaptation too to support their use in both
> representing categories of 'contexts' and in providing input for deductions
> (so that the deduction 'Fred Blogs is the robber' includes that 'Fred Blogs is
> a criminal', since 'robber' is a subclass or subcategory of
> 'criminal', etc). Having
> Schematron allow such 'is-a' relationships regarding its contexts or allowing
> category ontologies to be written such that Schematron and other such tools
> can read them might help create this ecosystem too. Or is that already part
> of Schematron?
>
> Best regards
>
> Steve
> ---
> Stephen D Green
>
>
>
>
> On 21 November 2010 11:45, rjelliffe <rjelliffe@allette.com.au> wrote:
>> On Fri, 19 Nov 2010 14:56:35 +0000, Stephen Green
>> <stephengreenubl@gmail.com> wrote:
>>>
>>> A very nice example, Roger. Maybe what would make it look more
>>> useful would be to demonstrate how to chain the deductions so that
>>> the deductions can themselves add to the 'knowledge' and further
>>> deductions be made based on those initial deductions. This might then
>>> provide an improved parallel methodology to the more typical OWL
>>> or RDF knowledge-base / triple-store / inference-engine approach.
>>>
>>
>> Just use the <sch:let> expressions more. You can have arbitrarily long
>> chains of deductions, and pull all the logic out of the assert or report
>> tests.
>>
>> <sch:let name="speeder-driversLicenseNumber" value="."/>
>>
>> <sch:let name="GunLicense"
>> value="for $i in
>> collection('GunLicenseFolder?select=*.xml;recurse=yes;on-error=ignore')
>> return $i/GunLicense[.//Person/driversLicenseNumber eq
>> $speeder-driversLicenseNumber]"/>
>>
>> <sch:let name="matching-drivers-license"
>> value="$speeder-driversLicenseNumber eq
>> $GunLicense//Person/driversLicenseNumber" />
>>
>> <sch:let name="matching-gun" value="$GunLicense/registeredGun/Gun/serial eq
>> doc('Robbery.xml')/RobberyEvent/evidence/Gun/serial" />
>>
>> <sch:let name="has-gun-license"  value="count($GunLicense) eq 1"/>
>>
>> <sch:let name="only-person-licensed"  value="count($GunLicense//Person) eq
>> 1" />
>>
>> <sch:let name="is-bad-guy"  value="$matching-drivers-license and
>> $matching-gun and $has-gun-license and $only-person-licensed" />
>>
>> <sch:let name="is-our-bad-guy"  value="parent::Person/child::name =
>> document('licensed-to-kill.xml')/agents/agent/name "/>
>>
>> <sch:report test="$is-bad-guy  and not( $is-our-bad-guy)" >
>> Therefore, <sch:value-of select="parent::Person/child::name"/> is the
>> Robber.
>> </sch:report>
>>
>>
>> So you can add extra deductions on the same subject.  (The let expressions
>> are scoped to schema, pattern, or rules, but I don't know that this is a
>> disadvantage.)
>>
>> Another way to approach this is neural net fashion: you have one Schematron
>> schema generating individual deductions, then subsequent schemas as layers
>> generating deductions based on the results of layer before (eg the SVRL
>> output.)  (Schematron supports an attribute "flag" to help declare the found
>> properties of a pattern/rule/assertion too (such as "incomplete data" or
>> "security risk found".)  You can physically combine the patterns for the
>> different layers into the same text file using the phases mechanism, if
>> appropriate too. (Of course, command-line parameterization has been
>> available for the last decade with Schematron, however a WWW technology may
>> be more interested in configuration from XML documents at some URLs rather
>> than just command line arguments.)
>>
>> By the way, there has been a version of Schematron that operated on RDF not
>> XML: Schemarama used the Squish query language. However, I imagine that
>> there are a lot of research tools available for RDF.
>>
>> Cheers
>> Rick Jelliffe
>>
>>
>