[ARCH] RIF extensibility

Some thoughts on extensiblity/towards an arch document

Let me summarize my overall understanding of RIF rule 
interchange/extensibility:

I think we should base on the following assumptions (pasted into IRC 
yestrerday):

=================================================================
  1) We have a *GENERIC* abstract model for conditions, rules, etc.

  2) syntactically, the XML exchange syntax of any RIF dialect MUST 
reflect/express this abstract model

  3) What is a dialect:

   a) it MUST restricts/define which parts of the abstract model you are 
allowed to use and how

   b) it MUST assign a semantics to this restricted part 
(model-theoretic, proof-theoretic, operational in that order of preference)

   c) it MAY assign "roundtrippable" own syntaxes (arbitrary many, if 
you want ;-) ) ... and even define the semantics in terms of one of 
those special syntaxes

  4) BLD should define a minimal dialect and other dialects MUST agree 
with the semantics of BLD *on the part of the abstract model they share 
with BLD

=================================================================

Let me discuss these points quickly:

1) The model could be in asn, but I personally would prefer some OWL 
and/or RDFS model.
  A dialect could then be defined in derms of constraints on that 
metamodel, such as exemplified in the presentation I gave in Feb remotely:
  http://lists.w3.org/Archives/Public/public-rif-wg/2007Feb/0083.html
  A would sart off adapting this to the latest metamodel UML/asn07
and trying to formalize the BLD constraints on the use of that model.

If this works out (which I assume/hope shouldn't be too hard), it could 
even lead to a very natural OWL or RDF "syntax" for BLD or other dialects.


2) It would be important to them specify how to get from/to the (BLD) 
XML from that metamodel ... For those who wonder how this relates to the 
decision we made in the present F2F to leave the formal model our of the 
next WD, this is perfectly consistent, it just means we switched from

  BLD <--> Abstract model <--> XML

    to

  BLD <--> XML <--> Abstract model

  and go from there.

3) a) is for BLD defined in terms of the constraints mentioned before.

  b) has a model-theoretic semantics, other dialects can use arbitrary 
other definitions of their semantics, as long as 4) is guaranteed. The 
reason why BLD kept its semantics more generic (truth values, etc.) than 
necessary was that other dialects could then pick it up and go from 
there and that this would make showing 4) easier for diealects doing so.

  c) dialects can define their own syntaxes an even define theri 
semantics in terms of these, BLD being the first example.

4) That is basically my understanding of what extensibility means:
    Relate to the generic abstract model, and at least agree with BLD on
    whatever you reuse from it. This definition leaves open restrictions
    and extensions of BLD at the same time, as we cannot expect that any
    rules language includes all of BLD. Datalog, for instance would be a
    dialect which could just be defined in terms of syntactically
    *RESTRICTING* BLD, Datalog with (well-founded or stable) naf an
    extension of a restriction

Other issues not covered so far:

  Extensibility/Arch needs
    ruleset merge
    signature definitions
  resolved, IMO

If nobody objects, that would be what I would suggest to go after.

Axel


-- 
Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/

Received on Friday, 28 September 2007 21:25:26 UTC