Re: Grammar presentation syntax FLD and BLD

Looks ok.  I'd suggest

 RULECONTENT     ::= 'Forall' Var+ '(' FREECONTENT ')' | GROUNDCONTENT

 GROUNDCONTENT ::= FREECONTENT

FREECONTENT ::= ATOMIC (':-' CONDITION)?

This forbids nested Forall and gives a place to explain that ground 
content is syntactically the same as free content but has no free 
variables, and a place to explain that the Var+ of the Forall should 
name exactly the free variables in FREECONTENT.

Further, to dramatically improve readability of examples and test cases, 
I'd suggest

  Const          ::= LITERAL '^^' SYMSPACE  |  NUMERIC  |  ALPHANUMERIC

where the last 2 options are sugar that allows one to omit any enclosing 
"" or trailing ^^xsd:decimal or ^^rif:local.

I.e  Ruleset(Rule(p(1)) is syntactically correct.


Jos de Bruijn wrote:
> Dear all,
>
> At the face-to-face I agreed to create a grammar for the presentation 
> syntax of FLD [2] which acknowledges the difference between atomic 
> formulas and terms in the productions, as well as a grammar for BLD 
> [3] that is a restriction of the FLD grammar.
>
> When writing the grammar I came across a number of issues, which I 
> mention below.
>
> Incidentally, I think there is a problem with the syntax for rules, as 
> specified in FLD.  Namely, a rule is an implication phi :- psi; no 
> quantification seems to be allowed. In the grammar below I also 
> allowed rules with universal quantification.
>
> I included the noncontroversial part of the metadata proposal and the 
> built-ins. The production absolute-IRI is defined in [1].
> Incidentally, I also removed the Implies production, because I did not 
> really understand what it is for.
>
>  Ruleset         ::= 'Ruleset( ' absolute-IRI? Metadata* Rule* ' ) '
>  Rule            ::= 'Rule( ' absolute-IRI? Metadata* RULECONTENT ' ) '
>  RULECONTENT     ::= 'Forall' Var+ '(' RULECONTENT ')' | CONDITION 
> (':-' CONDITION)?
>
>   UNITERM        ::= TERM '(' (TERM* | (Const '->' TERM)*) ')'
>
>   CONDITION      ::= 'And' '(' CONDITION* ')' |
>                      'Or' '(' CONDITION* ')' |
>                      'Exists' Var+ '(' CONDITION ')' |
>                      'Forall' Var+ '(' CONDITION ')' |
>                      'Neg' CONDITION |
>                      'Naf' CONDITION |
>                      ATOMIC
>   ATOMIC         ::= Predicate | Equal | Member | Subclass | Frame
>   Predicate      ::= UNITERM | 'Builtin ( ' UNITERM ' ) '
>   Equal          ::= TERM '=' TERM
>   Member         ::= TERM '#' TERM
>   Subclass       ::= TERM '##' TERM
>   Frame          ::= TERM '[' (TERM '->' TERM)* ']'
>
>   TERM           ::= Const | Var | Function| Equal | Member | Subclass 
> | Frame
>   Const          ::= LITERAL '^^' SYMSPACE
>   Var            ::= '?' VARNAME
>   Function       ::= UNITERM | 'Builtin ( ' UNITERM ' ) '
>
>   Metadata       ::= ' Metadata ( ' METADATALIST ' ) '
>   METADATALIST   ::= absolute-IRI MetadataValue | METADATALIST ' ; ' 
> METADATALIST
>   METADATAVALUE  ::= Const | ' [] ' | ' [ ' METADATALIST ' ] '
>
>
>   SYMSPACE       ::= absolute-IRI
>
>
> I suppose that in the textual description which say that LITERAL and 
> VARNAME are sequences of Unicode characters.
> Actually, I would propose to make VARNAME just a sequence of 
> alphanumeric characters and to always delimit LITERAL with double quotes.
>
> Then, it is not really clear from [2] what the syntax is of the names 
> in named-argument predicates and functions.  I would propose these 
> names to be absolute IRIs.
>
>
> Below is diagram restricted to the case of BLD.  Only three 
> restrictions were necessary:
> - a rule head may only be an atomic formula, not arbitrary condition
> - conditions may not contain negation  universal quantification
> - function and predicate identifiers may not be terms
>
>
>  Ruleset         ::= 'Ruleset( ' absolute-IRI? Metadata* Rule* ' ) '
>  Rule            ::= 'Rule( ' absolute-IRI? Metadata* RULECONTENT ' ) '
>  RULECONTENT     ::= 'Forall' Var+ '(' RULECONTENT ')' | ATOMIC (':-' 
> CONDITION)?
>
>   UNITERM        ::= Const '(' (TERM* | (Const '->' TERM)*) ')'
>
>   CONDITION      ::= 'And' '(' CONDITION* ')' |
>                      'Or' '(' CONDITION* ')' |
>                      'Exists' Var+ '(' CONDITION ')' |
>                      ATOMIC
>   ATOMIC         ::= Predicate | Equal | Member | Subclass | Frame
>   Predicate      ::= UNITERM | 'Builtin ( ' UNITERM ' ) '
>   Equal          ::= TERM '=' TERM
>   Member         ::= TERM '#' TERM
>   Subclass       ::= TERM '##' TERM
>   Frame          ::= TERM '[' (TERM '->' TERM)* ']'
>
>   TERM           ::= Const | Var | Function
>   Const          ::= LITERAL '^^' SYMSPACE
>   Var            ::= '?' VARNAME
>   Function       ::= UNITERM | 'Builtin ( ' UNITERM ' ) '
>
>   Metadata       ::= ' Metadata ( ' METADATALIST ' ) '
>   METADATALIST   ::= absolute-IRI METADATAVALUE | METADATALIST ' ; ' 
> METADATALIST
>   METADATAVALUE  ::= Const | ' [] ' | ' [ ' METADATALIST ' ] '
>
>
>   SYMSPACE       ::= absolute-IRI
>
>
> Another thing: why do we allow nesting of Forall statements in rules 
> if one can already specify multiple variables?
> I would propose to either remove the nesting or only allow mentioning 
> of 1 variable. I would prefer the former.
>
>
> best, Jos
>
>
> [1] Internationalized Resource Identifiers. RFC 3987. 
> http://www.ietf.org/rfc/rfc3987.txt
> [2] FLD editors draft. 
> http://www.w3.org/2005/rules/wg/draft/ED-rif-fld-20080219/
> [3] BLD editors draft. 
> http://www.w3.org/2005/rules/wg/draft/ED-rif-bld-20080219/
>
>

-- 


Oracle <http://www.oracle.com>
Gary Hallmark | Architect | +1.503.525.8043
Oracle Server Technologies
1211 SW 5th Avenue, Suite 800
Portland, OR 97204

Received on Thursday, 28 February 2008 21:43:31 UTC