Previous topic  Top  Next topic  Print this Topic
 

General Syntactic Changes

 

In the years since the publication of the original paper on F-logic in 1995, new ideas have been proposed and a number of systems based on F-logic have been 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.

Basic syntax

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

Cardinality constraints on attributes and methods

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.

OWL-like properties

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,

?P1[marriedTo -> ?P2] :- ?P2:Person[marriedTo -> ?P1:Person].

General constraints

For more general constraints, we will use the syntax

!- constraintBody

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.

Variables, quantification, and Lloyd-Topor extensions

a) All variables are denoted as ?Var

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 variable is anonymous. As in Prolog, each denote a unique new variable that does not occur anywhere else.

b) Explicit quantification

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

c) Implicit quantification

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.

d) If-then

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

Rule labels and other metadata

Every rule and query can be preceded by a metadata annotation of the form

@{metaannotation} rule/query/constraint
The annotation has the form:

metaannotation ::= '@{' id | frames | id ',' frames '}'
frames ::= frame (',' frame)*)?

Id is a constant, which represents the rule/query/constraint label. It should be unique within the rule set. The frames in the conjunction are intended to represent metadata associated with the rule/query/constraint to which the annotation is attached.

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

sort(asc(?X),desc(?Y),...)

Sort the output of the query in the ascending order of bindings for ?X, descending order of bindings for ?Y, etc. The asc(...) specification is implied and can be left out. For instance, sort(?X,desc(?Y),...) is the same as sort(asc(?X),desc(?Y),...).

outorder(?Y,?X)

The output to the query should be a set of tuples (?Y,?X), i.e., the bindings for ?Y go first.

maxanswers(NUMBER)

Specifies that only (at most) the first NUMBER of answers needs to be computed.

maxtime(NUMBER)

Stop the computation after this NUMBER of seconds.

 Examples:

 @{rule12}

 bar :- foo.

 

 @{rule15,rule15[author->Bob, date-> "1979-09-13T17:31:41-02:30"^^_dateTime]}

 foo :- bar.

 

 @{options[outorder(?Y)]}        

 ?- ?X[?Y->?Z].

 

 @{query13,

   query13[author->Martin],

   options[sort(asc(?X),desc(?Y)),outorder(?X,?Y),maxnumber(1)]}

 ?- ?X[name->?Y].

   

Methods with arguments, HiLog syntax

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.

Structural inheritance

We will use *=> for inheritable types and => for the non-inheritable ones with the following inference rules:

C2::C1, C1[M *=> T] |= C2[M *=> T]
O::C, C[M *=> T] |= O[M => T]

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

 

Builtin predicates and functions.

These are described in detail in a separate document.

Aggregates

This forum adopted the syntax for aggregates proposed in FLORA-2:

?Var = count{?Var [GroupingVarList] | Query}
?Var = sum{?Var [GroupingVarList] | Query}
?Var = avg{?Var [GroupingVarList] | Query}
?Var = max{?Var [GroupingVarList] | Query}
?Var = min{?Var [GroupingVarList] | Query}
?Var = collectset{?Var [GroupingVarList] | Query}
?Var = collectbag{?Var [GroupingVarList] | Query}

Modules

Modules are described in a separate document.

Name space prefixes and related issues.

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:

:- prefix prefix-name = "IRI".

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

:- default prefix "IRI".

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

Anonymous resources

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.

Data types

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