Re: [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):

It is a good start. However, there are some questions and omissions.

We need to define what it means for one dialect to extend another dialect.

   - This should be done both in terms of syntax and semantics,
     but I can see that syntax-only extensions might also be useful
   - Syntactic extensions really need to be only at the level of XML. I do
     not see why presentation syntaxes must extend each other (although that
     would be useful and in many cases extensions will also happen at the
     presentation level).
   - Semantic extensions might not always be model-theoretic. In case they
     are not model-theoretic (and use different formalisms), we will need
     to figure out what that means.
     But we do not need to do it in Phase 1, if ever. It is likely that all
     logical dialects will use model theory and all PR-like dialects will
     use some form of procedural semantics. So, we will only need to define
     semantic extensions for these two kinds of semantics.

The first two are not difficult, and the 3d probably also is not hard. But
they must be spelled out.


> =================================================================
>   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

Interesting idea, but it is hard to come up with such a global model and
reach consensus.


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

Note that your model talks only about syntax. We also need a similar model
for the semantics (some kind of lattice). A dialect is a function not only
of syntax, but also of that semantic lattice. One difficulty is that the
syntactic ontology and the semantic lattice are not orthogonal (the
semantics cannot be combined with syntax at will).

So, I consider the above program quite ambitious and wish you luck :-)


>    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

Do not understand what you are talking about here.

>   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

Correction: logic-based dialects.


> 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.

It would be nice to see the details and better explanations. I did not
understand from the slides how you are going to rest the rule sets exactly.
But it looks interesting.


> 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.

I could never understand why such syntaxes are necessary or desirable.
(As opposed to the models, which you described.)


> 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.


Seems like you got carried away. Dialects will extend BLD. How can they be
mapped into BLD?


> 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

Did you mean "semantic restriction" (to Herbrand models)?
I do not see why one needs to restrict syntax.

> Other issues not covered so far:
> 
>   Extensibility/Arch needs
>     ruleset merge
>     signature definitions
>   resolved, IMO

Actually, I am not sure we need a language for defining signatures.
I suspect that for the dialects that we'll be dealing with in the next 2-3
years (given our current speed :-) the signatures will be derivable from
the context.

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

Go get it! :-)

I am not sure we can achieve your ambitious goals, but I think we can have
a reasonable story about extensibility.


	--michael  


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

Received on Saturday, 29 September 2007 01:46:44 UTC