Response to AR3
Thanks for your continued support of RIF, and for the use cases in support of equality.
May we list your implementation on the RIF implementations page:
Alexandre Riazanov wrote: > Hi everybody, > > I am working on prototype for semantic querying of relational databases > (http://www.freewebs.com/riazanov/query_answering.pdf), > and RIF BLD is envisaged as one of the input languages (TPTP, OWL 2, SWRL > and Derivational RuleML are the others). > Since (a branch of) the Vampire prover is currently the core of the system, > it will essentially become a rule engine for BLD, supporting query > answering. > > The first implementation will simply convert BLD to TPTP, so it will be > useable with all TPTP reasoners. > Since it's basically just a Java API, the toolkit may be useful for purposes > other than TPTP conversion: > it will have a factory for the abstract syntax + JAXB-based parser/renderer. > > All the software will be open source. I am expecting to publish an alpha in > September. > > Since the positive equality in BLD is still in danger, I would like to > mention a couple of > examples I came across recently, working on the RDB stuff. > > Use case 1. Semantic querying requires semantic mapping of RDB schemas, > e.g., > by linking the tables to application domain concepts and relations. > Typically, > a part of a schema is just a declaration of functional dependencies between > attributes > of tables. These can be easily expressed if our language allows equality, > e.g. > the following rule states that the table_person.name functionally depends on > table_person.sin : > > ?NAME1 = ?NAME2 > :- > And > ( > table_person(sin -> ?SIN, name -> ?NAME1), > table_person(sin -> ?SIN, name -> ?NAME2) > ) > > > Such rules can be used by the reasoner for search space reduction, e.g, by > contextual rewriting. > > > Use case 2. Suppose we use several RDBs designed by different people for > different purposes. > The same entities can be represented differently in different DBs. For > example, the same > person can be identified with his SIN in one DB, and with a surrogate > integer key in another DB: > > person_for_sin(?SIN) # Person > :- > db1.table_person(sin -> ?SIN, name -> ?NAME) > > > > person_for_key(?KEY) # Person > :- > db2.table_person(key -> ?KEY, sin -> ?SIN, name -> ?NAME) > > > hasSIN(person_for_key(?KEY),?SIN) > :- > db2.table_person(key -> ?KEY, sin -> ?SIN, name -> ?NAME) > > > > > So, for cross-querying we absolutely need something like this: > > person_for_sin(?SIN) = ?P > :- > And( > ?P # Person, > hasSIN(?P,?SIN) > ) > > > Please note that these are just recent examples that are fresh in my mind. > I have seen others.