General Syntactic Changes Relative to the Original F-logic Syntax

In the years since the publication of the original paper on F-logic in 1995, new ideas were proposed and a number of systems based on F-logic were developed. This forum attempts to organize these ideas and propose a unifying syntax and semantics that incorporates the best ideas. It is expected that the various systems, such as FLORA-2 and OntoBroker, and the related specifications, such as WSML and SWSL, will be largely compatible with this syntax.

  1. Basic syntax
  2. The original F-logic distinguished between functional and set-valued attributes and methods. In this forum we decided to abandon this distinction and replace it with a more general mechanism of cardinality constraints.

    We will use only set-valued attributes and eliminate the double-arrows —>> and =>>. The arrows -> and => will be used for everything. Functional property of the attributes will be expressed using cardinality constraints.

    Instead of using ; to separate the different parts in an F-logic molecule, use the comma or and. The semicolon or or will be used for disjunctions in the rule body.

  3. Cardinality constraints on attributes and methods
  4. Syntax: a[foo {2:3} => type]. The symbol * in the upper bound part is used for infinity. The constraint {0:1} enforces the functional property and hence functional methods can be expressed using this type of constraints.

  5. OWL-like properties
  6. The above syntax will be extended to also accommodate OWL-like properties of F-logic attributes: symmetric and inverseOf(Attr). For instance, Person[marriedTo{1:1,symmetric}=>Person], Person[childOf{0:2,inverseOf(parent)}=> Person].

    Unlike the cardinality specification, symmetric and inverseOf(...) are not constraints. Instead, they are treated as a shortcut that avoids the need to specify a rule explicitly. For instance,

  7. General constraints
  8. For more general constraints, we will use the syntax

    rather than ?- constraintBody. It will be up to the implementation to decide when constraints are invoked: when the file is loaded or when an update occurs. A constraint will be said to be violated if posing constraintBody as a query yields a solution.

  9. Multiple types in signatures
  10. In the original F-logic it was allowed to specify multiple types. For instance, o[meth => {class1, class2}], meaning that the type of meth is an intersection of class1 and class2. This is no longer supported. Instead, for every pair of classes, class1 and class2, their intersection (class1 and class2) (alternatively (class1 , class2)) and union (class1 or class2) (alternatively (class1 ; class2)) will be defined. So, one will be able to write the following instead:

    (This assumes that and and , is associative and that (a,b,c) is equivalent to ((a,b),c).)

  11. Signatures for predicates
  12. The original F-logic did not define a syntax for signatures of predicates. In this forum, the following syntax was decided upon:

    For Boolean methods, the following syntax will be used:

  13. Variables, quantification, and Lloyd-Topor extensions
    1. All variables are denoted as ?Var
    2. Uppercasing (as in Prolog) will not be used, so uppercase identifiers will be permitted without the quotes. The name of a variable can be any sequence of alphanumeric symbols plus the underscore _.

      The variables ?_ and ? are anonymous. As in Prolog, they denote a unique new variable that does not occur anywhere else.

    3. Explicit quantification
    4. Explicit quantification in the rule body is allowed to support the Lloyd-Topor extensions. Both universal (forall) and existential (exist) quantification is permitted.

    5. Implicit quantification
    6. All variables that are not quantified explicitly are assumed to be quantified implicitly outside of the rule with the forall quantifier. No explicit universal quantifier for the whole rule will be needed and will not be supported.

    7. If-then
    8. Allow the if-then-else syntax as well as the a<--b and a-->b alternatives for if-then.

  14. Rule labels and other metadata
  15. Every rule and query can be preceded by a metadata annotation of the form

    There is a predefined meta data object options[...] to control the execution and output behaviour of a query. It can contain following options (specified as Boolean methods):


    	bar :- foo.
    	@{rule15,rule15[author->Bob, date-> "2008-12-15"^^_dateTime]}
    	foo :- bar.
    	?- ?X[?Y->?Z].
    	?- ?X[name->?Y].
  16. Methods with arguments, HiLog syntax
  17. The original F-logic used the @-syntax to separate the method name from the method arguments (e.g., o[m@(a,b)->v]). The purpose of this separation was to allow variables over the method names. In this forum it was decided to abandon the @-syntax and use the HiLog syntax instead.

    The HiLog syntax is an optional extension. In the basic case, we will not have variables over method names — only over attributes and method invocations (i.e., X[?Y->Z] will be allowed but X[?Y(P,Q)->Z] will not be. In the HiLog extension, variables over method names will be permitted, e.g., X[?Y(P,Q)->Z].

  18. Structural inheritance
  19. We will use *=> for inheritable types and => for the non-inheritable ones with the following inference rules:

    For data-molecules, both -> and *-> are allowed. In the basic case, they will have the same semantics, except that => will specify the type for -> and *=> the type for *->.

  20. Behavioral inheritance
  21. This is an extension feature. The arrow *-> now denotes inheritable methods with the semantics described in the   Yang and Kifer paper in ODBASE-2002.

  22. Builtin predicates and functions.
  23. These are described in detail in a separate document.

  24. Aggregates
  25. This forum adopted the syntax for aggregates proposed in FLORA-2:

  26. Modules
  27. Modules are described in a separate document.

  28. Direct superclasses.
  29. A direct superclass of an object or another class is a superclass such that there is no other superclass in-between. For instance, c1 is a direct superclass of c2 iff c2::c1 and there is no c (distinct from c1 and c2) such that c2::c and c::c1. Similarly, c1 is a direct superclass of an object o iff o:c1 and there is no c such that o:c and c::c1.

    Because there is a frequent need to query for such direct superclasses, we introduce special syntax for them: o<:c means that c is a direct superclass of its member-object o and c1<::c means that c is a direct superclass of its subclass c1.

    Note that <: and <:: are derived relations and, therefore, they are allowed only in the bodies of rules, in queries, or in the bodies of constraints. Also note that in patological cases of badly designed knowledge bases immediate superclasses might not exist. This is possible only in the presence of function symbols.

  30. Name space prefixes and related issues.
  31. To simplify the job of writing IRIs, RDF has proposed a syntax of the form prefix:localPart, which was adopted from the syntax of QNames (qualified names) in XML. Unfortunately, the meaning of such a construct in RDF is different from its meaning in XML and the issue is further confused by the fact that RDF also calls their construct a QNname. In RDF, prefix is a macro that expands to a IRI and prefix:localPart denotes a IRI that is constructed by concatenating the macro-expansion of prefix with localPart. In XML, prefix:localPart does not denote a IRI. Instead, it is a pair of the form (macro-expansion of prefix, localPart). To avoid this confusion, we will call the RDF construct an sQName (serialized QName) and use the syntax prefix#localPart.

    Prefixes can be declared as follows:

    The syntax for full IRIs is described in the Data Types document.

    We will also support default IRI prefixes with the statements of the form

    The default prefix affects IRI specified as #localName (without the prefix name).

  32. Anonymous resources
  33. Will adopt the FLORA-2 semantics and syntax for anonymous oids. This has also been adopted by WSML and SWSL. According to this proposal, _# means a completely new identifier (each occurrence) and numbered versions _#1, _#2, ... mean completely new identifiers except that within the same clause different occurrences of the same anonymous oid (e.g., _#2) denote the same identifier.

  34. Data types
  35. Data types will be represented as terms, not strings. A complete list of base data types is found in a separate document.

  36. Reification
  37. Reification is the process of making objects out of formulas. The syntax is ${formula}, where formula is any formula that can occur as a rule body, or it can be a rule. A reified formula can be bound to a variable and later called in the rule body or passed to an insert/delete statement. (Insertion of reified formulas that contain disjunctions or other Lloyd-Topor extensions is not permitted.) Reification is an optional extension.

  38. Introspection - postponed
  39. By introspection here we mean the syntax for creating facts out of the rules. Note that introspection is related, but is different from reification. The former makes facts out of the rules, while the latter makes objects out of them. OntoBroker explicitly makes facts out of rules and then queries the rules using the usual mechanisms. An alternative is to have a construct, e.g., clause, which would permit queries over the rule base. This approach is taken in Prolog and FLORA-2.

    The use of clause is simpler, but making facts out of clauses is potentially more powerful. For instance, given the following rule:

    	?Y:OldPerson <- ?Y:Person[hasAge->?X] and ?X > 70.

    the following facts could be generated:

    	a1:ElementOf[element->t1; concept->c1].
    	a2:ElementOf[element->t1, concept->c2].
    	a3:DataAtom[relationName->hasAge; value->t3, object->t1].
    	a4:PAtom[predicateSymbol->greater, arity->2, arguments->[t3,t4]].
    	r1:Rule[headLength->1, bodyLength->2, bodies->[a2,a3], heads->[a1]].

    Now one could define concept dependencies in a rule like:

    	depends(?C1,?C2)<- ?R:Rule[bodies->?B, heads->?H] and contains(?B,?A1)
                               and contains(?H,?A2) and ?A1:ElementOf[concept->?C1]
                               and ?A2:ElementOf[concept->?C2].

    The difficulty with this approach is that this would require a complete ontology that mimics the way the parser works. In addition, it is necessary to resolve how this ontology can be made extensible so that future extensions to the language would be covered. It was decided to postpone this issue.

  40. Verbose syntax - decided to use only and/or as an alternative to "," and ";"
  41. Verbose syntax is an alternative for symbolic syntax. We have already agreed to allow and as verbose syntax for comma and or for the semicolon. However, one could go further. For instance, WSML uses only the verbose syntax. For instance, they would write

    instead of

    Probably enough to use just hasValue, hasInheritableValue, hasType (or ofType), hasInheritableType (or ofInheritableType), member, subclass.

  42. Evaluable functions
  43. Evaluable functions are functions such that expressions involving these functions are replaced by their values. These functions can be built-in or they can be user-defined (in this case they are typically defined by rules and are derived from predicates that underlie their definition). At present, the syntax for user-defined evaluable functions has been shelved, and only builtin evaluable functions are considered.

    There is an issue of whether evaluable functions are to be evaluated by default or a special eval-like syntax should be required. It has been decided that this behavior should be regulated by a compiler directive:

    The default is off.

    The special syntax for forcing the evaluation of the evaluable functions (when the above switch if off) and for protecting these function from being evaluated by default (when the switch is on) has not been agreed upon. One proposal was to use _{...}.

  44. XML syntax
  45. Proposal: Use RuleML as the avenue for that.

  46. Define layering of the various extensions to the base F-logic language. -- unresolved
  47. Develop a reference parser -- pending

$Date: 2008/07/15 01:57:48 $