- From: Boley, Harold <Harold.Boley@nrc-cnrc.gc.ca>
- Date: Fri, 19 Sep 2008 21:50:03 -0400
- To: "RIF WG" <public-rif-wg@w3.org>
This is a reminder about the Core telecon Monday, September 22: http://lists.w3.org/Archives/Public/public-rif-wg/2008Sep/0112.html It's also a fwd of, and preliminary answer to, an email Dave sent today to the Core co-editors. I wonder if all might agree with the PROPOSEDs where Dave agrees (... or would not formally object): > > http://www.w3.org/2005/rules/wg/track/issues/48 > > PROPOSED: Keep membership/subclass in Core > > My preference is to drop membership/subclass but I don't think I'd go as > far as formally objecting to them being included. > > http://www.w3.org/2005/rules/wg/track/issues/71 > > PROPOSED: Core should keep unrestricted equality and external function > > calls in rule bodies and keep external functions calls in rule heads. > > Agreed. > > http://www.w3.org/2005/rules/wg/track/issues/74 > > PROPOSED: Core should keep both frames/objects and > > (positional-argument) predicates/relations. > > I'd accept this but would like to check what others think. > > http://www.w3.org/2005/rules/wg/track/issues/75 > > PROPOSED: Core should keep disjunction in rule bodies (cf. Gary's UC). > > Reluctantly agreed, so long as marked as "at risk" at this stage. > > http://www.w3.org/2005/rules/wg/track/issues/76 > > PROPOSED: Core should keep unrestricted equality in rule bodies (cf. > > ISSUE-71). > > Agreed. Also some clarification: > > http://www.w3.org/2005/rules/wg/track/issues/70 > > PROPOSED: Parameterize the conformance clauses of Core with > > safeness requirements "strict", "weak", and "none" (default: "none"). > > This is the one I didn't understand. > > What does this parameterization mean? Is it a property of an > implementation (in which case what does "default" mean) or of a rule set? > What is the definition of these different class of safeness requirement? > > My preferred resolution is (c) on the list on the issues pages: > . . . see below . . . I meant "strictly-safe" (a), "weakly-safe" (b), and "unsafe" (d) conformance levels similarly as defined/linked in/from issue 70. Perhaps a version of Dave's (c) could become another level. Harold -----Original Message----- From: Dave Reynolds [mailto:der@hplb.hpl.hp.com] Sent: September 19, 2008 11:32 AM To: Boley, Harold Cc: Axel Polleres; Gary Hallmark; Adrian Paschke; kifer@cs.sunysb.edu; team-rif-chairs@w3.org Subject: Re: RIF-Core: proposing resolutions to current issues Boley, Harold wrote: > Hi All, I started to incorporate Axel's suggestions in the unbundled > update below. Thanks. I didn't quite understand your response on my request to take the discussion to the wider list but I've been out for a couple of days. Let me respond here for now. > http://www.w3.org/2005/rules/wg/track/issues/48 > PROPOSED: Keep membership/subclass in Core My preference is to drop membership/subclass but I don't think I'd go as far as formally objecting to them being included. In general I'd rather keep Core as small as possible to simplify implementation of Consumers, dropping things which are essentially syntactic sugar. In this case there is the specific (but non-technical) problem of the confusion with the RDFS constructs. My primary interest is in having RIF Core be able to exchange semantic web rules and the introduction of constructs which are similar but not identical to the existing ones will lead to confusion and support load. The relationship between #/## and rdf:type/rdfs:subClassOf has been precisely defined and implementation cost is small but for us support costs swamp implementation costs. > (maybe limiting these constructs to rule bodies). How would that be useful? In the case of object-based systems such as Oracle's (which I take to be the motivation for this suggestion) then the member/subclass are defined externally to the rule set and need to be made accessible to rules. My understanding was that this would be done as a set of RIF facts which obviously correspond to rule heads, not to rule bodies. There is also the question of new/skolem functions. > http://www.w3.org/2005/rules/wg/track/issues/70 > PROPOSED: Parameterize the conformance clauses of Core with > safeness requirements "strict", "weak", and "none" (default: "none"). This is the one I didn't understand. What does this parameterization mean? Is it a property of an implementation (in which case what does "default" mean) or of a rule set? What is the definition of these different class of safeness requirement? My preferred resolution is (c) on the list on the issues pages: No safety criteria for Core itself. The conformance statement for a Core Consumer only requires conformance over a safe subset. Jos, argued for (d) saying [1] the current notion of a conformance based on translation to an "implementation language" implicitly allows for incomplete processors. I don't understand precisely what that means for implementers enough to be completely happy with it but it seems like a valid option. Follow up Jos' suggestion was one reason I wanted to take this discussion to the wider list. > http://www.w3.org/2005/rules/wg/track/issues/71 > PROPOSED: Core should keep unrestricted equality and external function > calls in rule bodies and keep external functions calls in rule heads. Agreed. > http://www.w3.org/2005/rules/wg/track/issues/72 > PROPOSED: Do not include Skolem functions or a 'New' builtin for Core > (a 'New' construct can be developed for PRD). I would prefer to include the "new" builtin and have that available in both BLD and PRD. My primary motivation is that a substantial number of "in the wild" RDF rule sets do something like this to construct new bNodes. For the observed usages then the proposed "new" builtin would be sufficient and would be implementable in both a BLD and PRD setting. However, PRD seems to be opting for the "new" action, rather than the builtin/skolem function, and that seems to have a Gensym semantics. That's clearly a problem. I assume PRD doesn't want two different forms of "new" and the true Gensym form can't be in Core. I'd like to at least understand the PRD position here before agreeing to this proposal. > http://www.w3.org/2005/rules/wg/track/issues/74 > PROPOSED: Core should keep both frames/objects and > (positional-argument) predicates/relations. I'd accept this but would like to check what others think. The reason for raising the issue is that the rule languages I'm interested in exchanging between represent facts as either objects or RDF triples. Given that a a lot of PRD systems use an object model or something like Jess' unordered facts it seems reasonable to ask whether relations are really in the PRD/BLD overlap or whether frames-only is closer to the common denominator. > http://www.w3.org/2005/rules/wg/track/issues/75 > PROPOSED: Core should keep disjunction in rule bodies (cf. Gary's UC). Reluctantly agreed, so long as marked as "at risk" at this stage. I would like to argue that this is syntactic sugar and can be removed by L-T but Gary's argument that the result of such a transform blows up enough to be non-tractable in practical settings is a good one. It remains a worry though. Including it in Core means that languages without disjunction (a lot of them, ours included) will not be able to effectively implement Core (by Gary's argument). I recall Jos being particularly opposed to inclusion of disjunction. I'd like to understand whether he has other reasons for this. > http://www.w3.org/2005/rules/wg/track/issues/76 > PROPOSED: Core should keep unrestricted equality in rule bodies (cf. > ISSUE-71). Agreed. Dave [1] http://lists.w3.org/Archives/Public/public-rif-wg/2008Aug/0148.html -- Hewlett-Packard Limited Registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England
Received on Saturday, 20 September 2008 01:50:47 UTC