Hekate Translation Framework

HaThoR is an XML-based framework for knowledge translation from/to the Hekate Markup Language (DTD versioned in the HathoR CVS repo) to other formats, mainly:

• RDF, OWL → attributes,
• RIF, SWRL (OWL) → rules,
• XMI → rules with tables,
• GraphViz → ard/xtt (for presentation).

Currently the framework is in an alpha stage.

It can be used by registered developers on a dedicated page.

The framework has been developed by Justyna Szostek Janik, supervised by Grzegorz J. Nalepa.

HaThoR is part of HaDEs.

See also the developemnt page.

UML-based Translators are based on Analysis of UML Representation for XTT and ARD Rule Design Methods CSL Technical Report no. 5/2009 AGH University of Science and Technology (for more reports...):

• ABC-KRAKOW record of the report
• CSL Technical Report no. 5/2009 online

Download:

Translators: translators.tar.gz

Requirements:

• The xsltproc tool (or similar XSLT processor)
• hml.dtd file

HOW TO:

An exemplary translation from hml file to xmi file:

xsltproc translator.xsl hekate_case_nazwa.hml > hekate_case_nazwa.xmi

HaThoR (v.2.0) is a set of XSLT translators which translate (parts of) HML files into other knowledge representation languages.

• Information about the first version of HaThoR can be found here.
• Evaluation of the first version (including miw projects: XTT->SWRL and XTT->RIF) can be found here.

HaThoR v.2.0 consists of the following translators:

• ATTML → OWL (RDF/XML syntax)
• ATTML → OWL2 (RDF/XML syntax)

• ARDML → OWL (RDF/XML syntax)
• ARDML → OWL2 (RDF/XML syntax)

• XTTML → SWRL (RDF/XML syntax)
• XTTML → RIF Core
• XTTML → RIF PRD

• STATE → OWL (RDF/XML syntax)
• STATE → OWL2 (RDF/XML syntax)

• HML → SWRL/OWL (RDF/XML syntax)
• HML (without XTTML) → OWL2 (RDF/XML syntax)

hathor2-final.tar.gz

HaThoR online

HeKatE cases:

• cardio
• cashpoint
• health
• hello
• thermostat
• upsell

Download: hekate cases translated with hathor2

• attml2owl1 attml2owl1.xsl
  • based on hathor1 by JSJ
  • syntactic changes
  • HML2 compliance
    • some potentially misleading changes of datatype properties:
      • range(ordered)={ordered,unordered} → range(tpeIsOrdered)=boolean
      • range(att_value)={single,multiple} → range(attHasClass)={simple,general}
      • range(att_class)={ro,rw,wo,state} → range(attHasComm)={in,io,out,state}
• attml2owl2 attml2owl2.xsl
  • hierarchy of types (SymbolicType, NumericType as subclasses of Type)
  • datatypes (XSD) and value ranges in domain declarations
• ardml2owl ardml2owl1.xsl
• ardml2owl2 ardml2owl2.xsl
  • based on hathor1 by JSJ
• xttml2rif xtt2rif-prd-simple.xsl, xtt2rif-core.xsl
  • based on miw_08_rif (but it's for RIF-BLD)
  • nested groups as in jsj-msc
  • variables removed
• xttml2swrl xttml2swrl.xsl
  • production rules can be encoded but will not work, as in Upsell case study
  • no support for conditions like: attr > Tuesday (swrlb:greaterThan, SWRLJessTab)
• state2owl state2owl1.xsl
• state2owl2 state2owl2.xsl
  • attTakesValue(att,value)
• hml2owl2 hml2owl2.xsl
  • attml2owl2+ardml2owl2+state2owl2 (NO RULES)
• hml2swrl hml2swrl.xsl
  • attml2owl1+ardml2owl+xttml2swrl+state2owl1

• The main classes are Attribute and Type.
• Class Attribute represents attributes from the ATTML attributes section, and types of attributes from ATTML types section are represented by subclasses of a class Type.

• Each type is represented by a class deriving from the superclass Type, and for each type an instance is generated
• there are main subclasses of the class Type NumericType and SymbolicType, thhey are created based on information from HML
• multiple properties for types and attributes (translated attributes of HML elements <attribute> and <type>) - One can describe the attributes in details, e.g. the use of the attribute in the system, its type and class, description etc.
• in attml2owl1 the domains are represented as strings, e.g. 0-24. In atttml2owl2 the data ranges are used.
• in attml2owl1 the domains are represented with properties (for each type a new property is defined), in attml2owl2, types are defined by the values they allow, e.g. Boolean ≡ tpeHasValues {0,1}

• ARDML properties are represented in OWL as instances of a class Property.
• Relations between properties are represented using Objet Property hasAttribute, dependsOn for dependencies betweeen attribute, and transformedInto for TPH relations.

2 approaches: simple and frame-based

• simple: using representing attributes and their values by defining/using external predicates construct extensively
  • attributes references are constanst identified with URIs (rif:iri)
  • attributes' values are bound using predicates xtt:name_of_the_relation(attr,value_or_a_set)
• frame-based: representing attributes as frames, to be considered in future?

General remarks (common for both translations):

• XTTML model as a RIF Group,
• XTT tables as RIF Nested Groups,
• XTT rules as RIF Rules; the rule conditions are placed in the <if> section, and the decisions in <then> realized in RIF ACTION_BLOCK
• Connections between XTT tables represented with xtt:link predicate (calling external action)
• Logical operators used in rule preconditions are externally defined using RIF <op> tag
• primitive datatypes as defined in RIF DTB
• new operators and predicates for XTT: xtt:range for ranges <a;b> and xtt:set for sets {a,b,c} (previously: xtt:set and xtt:complex_set)
• in the decision part external actions are used - for better compatibility with RIF BLD and beause of the nuances of Assert, Retract, Modify (e.g. should we assert or modify the attribute value?)

• not compatible with other translations, but in this case I think it doesn't matter. In the end the others may change, in RIF alternative there are some interesting ideas, e.g:
  • attr in any

• problems: no RIF PRD Validators, only syntax checking (the translator produces valid XML documents)

• based on the above translator, only some PRD constructs removed
• validated with RIFLE Validator - yields analogous warnings as for the standard W3C RIF files...

• no support for production rules in SWRL → rules translated, and asserting new facts can be done (e.g. by JessSWRLTab in Protege), but updating an attribute value would not work
• translated rules' conditions: att=val,att>val,att<val, att in {v1,v2,v3} only partly: if this is the only condition in a rule (as in thermostat)
• translated rules' conclusions: att:=val.
• example rule:

    attTakesValue(att_10, "workday")  ∧ attTakesValue(att_11, ?var_att_11)  ∧ swrlb:lessThan(?var_att_11, "9") → attTakesValue(att_7, "not_during_business_hours")

• no support for symbolic ranges (e.g. att> Tuesday)

• A state of a system is modelled with the following properties (role assertions): attTakesValue(a,d) for simple attributes and attTakesValue(a,v1),attTakesValue(a,v2)…attTakesValue(a,vn) for generalized ones.
• each state in an instance of a class State,with a set of datatype property assertions: stDescibeAttribute(state,att)