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 Translation

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


Translators: translators.tar.gz


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


An exemplary translation from hml file to xmi file:

xsltproc translator.xsl hekate_case_nazwa.hml > hekate_case_nazwa.xmi

HaThoR v.2.0

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
  • STATE → OWL (RDF/XML syntax)
  • STATE → OWL2 (RDF/XML syntax)
  • HML → SWRL/OWL (RDF/XML syntax)
  • HML (without XTTML) → OWL2 (RDF/XML syntax)


HaThoR online


HeKatE cases:

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

Download: hekate cases translated with hathor2

Translators - shortly

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

Translators - more details

Translation ATTML - OWL/RDF

  • 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}

Translation ARDML - OWL/RDF

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

Translation XTTML - RIF


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:
  • problems: no RIF PRD Validators, only syntax checking (the translator produces valid XML documents)
RIF Core

Translation XTTML - SWRL

  • 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)
hekate/hathor.txt · Last modified: 2019/06/27 15:49 (external edit)
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0