- 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