- From: Dave Reynolds <der@hplb.hpl.hp.com>
- Date: Fri, 15 Aug 2008 16:07:45 +0100
- To: RIF WG <public-rif-wg@w3.org>
We have discussed the starting points for Core as: - roughly the datalog subset of BLD, plus Frame syntax and externs - the intersection of PRD and BLD - something as simple to implement as possible while still being useful I thought it might be useful to try to enumerate the questions that would need to be resolved to ground this out. I'm not proposing all of these as formal issues yet, nor describing them in adequate detail, just trying to collect an initial list to get a sense of where the problems are. 1. Decidability? Should there be a rule safety criteria? Should it be normative? 2. Handling of external functions? DTB defines many operations that would be useful in CORE but defines them as functions rather than predicates. Options here would include: (a) allow some syntactically restricted assignment-like use of equality in CORE to allow the results of external functions to be accessed; (b) define predicate versions of those functions as part of CORE. (c) define predicate versions of those functions in DTB. 3. Support for skolem functions or some equivalent? C.f. Gary's thread. In applications terms it's useful to be able to create new objects (to use PR terminology). In BLD this can be achieved by use of function symbols. Some equivalent is a requirement on PRD. How does this impact CORE? Options here might include: (a) not in CORE (b) restricted use of function symbols just for this purpose, if the restrictions can be well defined (c) some genSym builtin 4. Membership/subclass? We've previously suggested these be omitted form CORE on the grounds that CORE is minimal and those were contentious. For PR systems based on an object model there seems to be some argument these are needed and are thus in the intersection of PRD and BLD. So should they be in CORE? 5. Frames only? Not sure this is a serious option but thought I'd raise it. As far as I can tell many PR systems only support an object data model and so would natively only support Frames, not uniterms. The same is also true of RDF rule languages like N3 and Jena. It would in principle be possible to have a CORE with just Frame syntax plus external predicates but no non-external uniterms which would reduce the implementation barrier for such systems. What other issues have I missed? Dave -- Hewlett-Packard Limited Registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England
Received on Friday, 15 August 2008 15:09:11 UTC