XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Generating New Knowledge by Deductive Reasoning usingSchematron

 On Sun, 21 Nov 2010 16:46:22 +0000, 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.

 ISO Schematron defines an output markup language, Schematron Validation 
 Report Language presents many details.


 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?)

 Sure.  General facts can be added as a value-of  or, in the latest 
 Schematron, directly in markup.

 <sch:let name="dogs">
   <my:dogs>
       <my:dog>Pip</my:dog>
       <my:dog>Sam</my:dog>
       <my:dog>Nipper</my:dog>
 </sch:let>

 You can have assertions that are untestable too, by the way:

  <sch:assert test="true()">The element names should be limpid and 
 efflorescent</sch:assert>


> 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

 At the moment, SVRL does not output structured values copied from the 
 input. It can transmit values in dynamic text or into a template (the 
 new <Sch:property> element).

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

 TAG is very good for its domain.
 
> 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?

 The intent of Schematron is to stay close to the markup, and avoid 
 building meta-layers apart from phases/patterns/extensions/properties  
 directly: modesty!  (The point being that the more difficult it is to 
 represent the constraints/deductions in Schematron, the more difficult 
 it will be to code in any XML-based representation/API directly. This is 
 particularly true where there are arbitrarily long inheritance paths for 
 some document that span documents.) Schematron allows XSLT2 functions to 
 be defined, so you can always make your own identity tests if necessary.

 I guess one thing that Schematron has in this area is the abstract 
 pattern notion (which can be parameterized too.)

 <sch:pattern id="criminal"  abstract="true">
    ...
 <sch:pattern>

 <sch:pattern id="robber"  is-a="criminal" >
    ...
 </sch:pattern>

 This could be used to declare levels of metamodeling if necessary, but 
 the info is not available inside the schema XPaths nor in the SVRL at 
 the moment. So the secondary stage (that marks the SVRL) would need to  
 open up the original schema to get access to this information.

 Cheers
 Rick Jelliffe


 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS