- From: Michael Kifer <kifer@cs.sunysb.edu>
- Date: Fri, 29 Feb 2008 10:21:57 -0500
- To: Jos de Bruijn <debruijn@inf.unibz.it>
- Cc: Gary Hallmark <gary.hallmark@oracle.com>, RIF <public-rif-wg@w3.org>
Jow wrote:
>
> Gary Hallmark wrote:
> > Looks ok. I'd suggest
> >
> > RULECONTENT ::= 'Forall' Var+ '(' FREECONTENT ')' | GROUNDCONTENT
> >
> > GROUNDCONTENT ::= FREECONTENT
(replying to Gary)
I think GROUNDCONTENT complicates the picture. If we want to insist on
quantification, then we could allow Var* instead of Var+. So, the ground
content would be represented by an empty quantifier. This grammar is
simpler and more uniform. In XML, this would lead to fewer number of
different tags.
> > 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.
>
> agreed. It was an error in the BNF that nesting is allowed.
But there are simpler ways to disallow nesting.
> > 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 agree that we want to improve readability of examples. incidentally,
> I think it is much more convenient to abbreviate IRIs rather than local
> symbols, since local symbols will not be used very often (I think): the
> names of local symbols are not accessible outside the rule set.
> However, I'm not sure this BNF is the place. I think we can just say
> something like:
>
> For readability, in the examples throughout this document and in other
> documents we use the following abbreviations:
> * "ns#localname"^^rif:iri as compact URIs of the form prefix:localname
> * "numeric+(.numeric+)?"^^xsd:decimal as numbers numeric+(.numeric+)?
I am reluctant to do this in the official RIF specification, because it is
supposed to illustrate how exactly things are supposed to be written in the
language. (Unofficial) tutorials and papers are a different matter. There
people can do whatever they want.
--michael
> best, Jos
>
> >
> > 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/
> >>
> >>
> >
>
> --
> debruijn@inf.unibz.it
>
> Jos de Bruijn, http://www.debruijn.net/
> ----------------------------------------------
> One man that has a mind and knows it can
> always beat ten men who haven't and don't.
> -- George Bernard Shaw
>
> --------------ms070303060800090803060705
> Content-Type: application/x-pkcs7-signature; name="smime.p7s"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment; filename="smime.p7s"
> Content-Description: S/MIME Cryptographic Signature
>
> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJEzCC
> AuQwggJNoAMCAQICEB1TmNgyHOKRUL43eSjaINgwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
> BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
> I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUxMDA3NTMwOFoX
> DTA4MDUwOTA3NTMwOFowRzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEkMCIG
> CSqGSIb3DQEJARYVZGVicnVpam5AaW5mLnVuaWJ6Lml0MIIBIjANBgkqhkiG9w0BAQEFAAOC
> AQ8AMIIBCgKCAQEA4mJofW3+kMtlQKNG0am5Km+8qlA18tMV9Q5oPrOgBoReGVwbcc1oXrSJ
> 1lhTAFjCVjasdS61TpwsYWWzrNfygNKHPVvmDWJRDVUCyqvsLUhhWiIT2GoJCKlWXXpzNdWQ
> e1pXwFCLVniOD+SrWXx4qtdSYk9XmUX/k3ymZupqcGeFIokk+jrA97b2K+7QEwoiyGyStXcU
> NI5r/690Htyck7nmc+tBX5t/aq0EtVpBi4VKNas7Pc4kGb0Knne1VUP1dS3V1GgHg18Vay+D
> p5SjScZiJEYMYk06X7qzJOu79ZpEN87b3pIrnI+j2qrblcrWRH54ovOF0xmMUpbPIYFQLwID
> AQABozIwMDAgBgNVHREEGTAXgRVkZWJydWlqbkBpbmYudW5pYnouaXQwDAYDVR0TAQH/BAIw
> ADANBgkqhkiG9w0BAQUFAAOBgQAApmPQlsZUuIaP4F/Jmev1uvgt/FrcXcVCr9s5YHcoTfl2
> nKrfoev1IXti4w/IY8q1l7AgN3eulgkB0pws0qLQ7dGg812vXO+CEqN9Vs0+0zeOz4l4lppc
> uuppnlj+MKk25ZRFoXs6XGvLZdhupslDZSPgswqkYyj0As67RBSXhDCCAuQwggJNoAMCAQIC
> EB1TmNgyHOKRUL43eSjaINgwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNV
> BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz
> b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUxMDA3NTMwOFoXDTA4MDUwOTA3NTMw
> OFowRzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEkMCIGCSqGSIb3DQEJARYV
> ZGVicnVpam5AaW5mLnVuaWJ6Lml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
> 4mJofW3+kMtlQKNG0am5Km+8qlA18tMV9Q5oPrOgBoReGVwbcc1oXrSJ1lhTAFjCVjasdS61
> TpwsYWWzrNfygNKHPVvmDWJRDVUCyqvsLUhhWiIT2GoJCKlWXXpzNdWQe1pXwFCLVniOD+Sr
> WXx4qtdSYk9XmUX/k3ymZupqcGeFIokk+jrA97b2K+7QEwoiyGyStXcUNI5r/690Htyck7nm
> c+tBX5t/aq0EtVpBi4VKNas7Pc4kGb0Knne1VUP1dS3V1GgHg18Vay+Dp5SjScZiJEYMYk06
> X7qzJOu79ZpEN87b3pIrnI+j2qrblcrWRH54ovOF0xmMUpbPIYFQLwIDAQABozIwMDAgBgNV
> HREEGTAXgRVkZWJydWlqbkBpbmYudW5pYnouaXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B
> AQUFAAOBgQAApmPQlsZUuIaP4F/Jmev1uvgt/FrcXcVCr9s5YHcoTfl2nKrfoev1IXti4w/I
> Y8q1l7AgN3eulgkB0pws0qLQ7dGg812vXO+CEqN9Vs0+0zeOz4l4lppcuuppnlj+MKk25ZRF
> oXs6XGvLZdhupslDZSPgswqkYyj0As67RBSXhDCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcN
> AQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT
> CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp
> ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG
> cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNv
> bTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYD
> VQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy
> c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
> xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV
> cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq
> VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMG
> A1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZy
> ZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp
> dmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIX
> oUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx
> VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x
> ggNkMIIDYAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu
> ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu
> ZyBDQQIQHVOY2DIc4pFQvjd5KNog2DAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJ
> KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODAyMjkwODIzNTlaMCMGCSqGSIb3DQEJBDEW
> BBTFcdm3KHv+9pCRBlWFcFMd82bOmTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G
> CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB
> hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
> bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz
> c3VpbmcgQ0ECEB1TmNgyHOKRUL43eSjaINgwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYD
> VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
> AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEB1TmNgyHOKRUL43eSja
> INgwDQYJKoZIhvcNAQEBBQAEggEAwE/yEbwvb4KMzsmzXWAYaY3ZCeUTHjWFNktoAud06Je0
> rV9qPqrP/dEwBpHmBwOUSfYE3hvMoxTiSGP6+zNcF54yTnawOi6F3qYiYizirlj5KZqUMqjT
> Qxjoercwl8NKQvGxrAk7Mn/Da4DJ1sSK5rRjdlHCqZiMQw463uFHLx4ZgCPMX7agZ5okmeYd
> l+AiZWD8vj+1kUOAHjeC1vyXNlNlCQh0q52frt9tXScgXq/TGfFb6HpyIff7pXu//ZtYBTus
> LRmL5/VIxWHUfI4EF1CWTkrJ8VxX5S+my3+rgWt6avSqz2G3vmVSuFk5iMMLt4n4XCvbABFs
> G9I+AaWIKwAAAAAAAA==
> --------------ms070303060800090803060705--
>
>
Received on Friday, 29 February 2008 15:22:43 UTC