- From: Adrian Giurca <giurca@tu-cottbus.de>
- Date: Tue, 06 Mar 2007 18:13:28 +0100
- To: RIF WG <public-rif-wg@w3.org>
- CC: Dave Reynolds <der@hplb.hpl.hp.com>
- Message-ID: <45EDA138.3050900@tu-cottbus.de>
Dear all, According with Dave comments I updated the proposed diagram. First of all now sorts are referenced. Second, I separate individuals from data literals, and to refer to the sorts by using URIs. I hope that this design can be useful. I can use MagicDraw if there is some interest for the XMI. And then the Sorts diagram is: According with this new design the EBNF is: CONDITION ::= 'And' '(' {CONDITION} ')' | 'Or' '(' {CONDITION} ')' | 'Exists' '(' 'declare('Var {Var}')' CONDITION ')' | POSITIVE POSITIVE::= 'Equal' '(' TERM TERM ')' | 'Uniterm' '(' 'functor' '(' Individual ')' 'arguments' '(' {TERM} ')' ')' TERM ::= Var | CONST | 'Uniterm' '(' 'functor' '(' Individual ')' 'arguments' '(' {TERM} ')' ')' Var ::= 'Var' '(' name ['type' '(' sortRef ')'] ')' CONST ::= 'Individual' '(' id ['type' '(' sortRef')'] ')' | 'DataLiteral' '(' lexicalForm ['type' '(' sortRef')'] ')' SORT ::= PSORT | 'ASort' '(' SORT {SORT} ')' | BSort PSORT ::= xs:integer | xs:decimal | xs:time | xs:dateTime | xs:string name::= xs:NCName id ::= xs:anyURI sortRef ::= xs:anyURI lexicalForm ::= xs:string Regards, Adrian Dave Reynolds wrote: > > Dave Reynolds wrote: >> >> I like some of the better names but I don't quite see how this >> version of the sort sub-diagram solves the issues. Though that might >> just be the lateness of the hour :-) >> >> First, Constants include things like numbers and dates, so they can't >> uniformly have an xs:anyURI id. You could split Constants into >> Symbols and Literals (or TypedValues or something) - Symbols could >> have an id (xs:anyURI) whereas TypedValues would have a lexicalForm >> (an xs:string). >> >> Second, just considering Symbols I don't see how this resolves the >> divergence between the metamodel reading and the abstract syntax >> reading. Your BNF suggests that you intend this to have an abstract >> syntax reading but I don't think we are saying that a Symbol used in >> a predicate position (for example) would have an ASort specification >> inline in the syntax at the point of use (at least I hope not). > > Sigh, of course that should have been either function/Asort or > predicate/Bsort ... definitely too late ... > > Dave
Received on Tuesday, 6 March 2007 17:11:51 UTC