- From: Axel Polleres <axel.polleres@urjc.es>
- Date: Wed, 24 May 2006 09:33:16 +0200
- To: "Boley, Harold" <Harold.Boley@nrc-cnrc.gc.ca>
- CC: public-rif-wg@w3.org
Boley, Harold wrote: > Axel and all, > > This refers to http://www.w3.org/2005/rules/wg/track/actions/25 and > http://lists.w3.org/Archives/Public/public-rif-wg/2006May/0197.html, > http://lists.w3.org/Archives/Public/public-rif-wg/2006May/0198.html > (to your former email, explicitly; to your latter one, implicitly). > > > Most Discriminators you are missing go beyond Phase 1, but the RIFRAF > has already been extended towards Phase 2 through Hassan's email > (http://lists.w3.org/Archives/Public/public-rif-wg/2006May/0179.html, > http://lists.w3.org/Archives/Public/public-rif-wg/2006May/0184.html). > However, it would make sense to keep a Phase 1 / Phase 2 distinction > with (or within certain values of) the Discriminators. +1 some more comments inline. >>Syn: Syntactic Discriminators >> . . . >> --> comment axel: Also concerning the recent mailinglist >> discussions I miss an own category for typed vs. >> untyped variables in the RIFRAF classification. > > > I agree, could be spliced in thus: > > 1. Restricted vs. Unrestricted Use of Logic Variables > 2. Typed vs. Untyped Variables > * Types can reuse class definitions in RDFS and OWL > 3. Predicate Variables Permitted vs. Not Permitted > > > >> SYN.1.3. (FURTHER RESTRICTIONS FROM STATIC ANALYSIS RESEARCH) >> >> --> comment axel: unclear, please explain? > > > E.g.: Allowing vs. Not Allowing Body-Only Variables Ok, I suggest to make these explicit. >>SYN.3. MONOTONIC LLOYD-TOPOR EXTENSIONS ALLOWED VS. NOT ALLOWED >> . . . >> --> comment axel: this shows us that there rewritings >> beyond extensions of Lloyd-Topor, which also allow >> formulae in the rule head. Has not been considered >> in current RAF, but might be worthwhile at least for phase 2 > > The rule head can be a formula such as head1 AND head2: > http://www.w3.org/Submission/SWSF-SWSL/#swsl-rules-mon-lt Yes, but the rewriting I am speaking of allows *arbitrary* head formulae (as it reduces to disjunctive logic programs)... as I said, I agree this is a phase 2 issue. >>SES.1. HOMOGENEOUS (BODY HAS SINGLE EXPRESSIVENESS CLASS) VS. HYBRID > > (BODY > >> HAS TWO EXPRESSIVENESS CLASSES) RULES >> . . . >> --> comment axel: however, I am not sure whether this discriminator > > is > >> really applicable, in principle, what Harold mentioned in his >> comment to Hassan: >> "'constraints' (e.g., solved by DL engines) goals." >> are achievable by dlvhex predicates. >> >> --> comment axel (alternative): In case this refers to the terms >> homogeneous vs. heterogeneous ontology integration as described > > in > >> http://rewerse.net/deliverables/m12/i3-d3.pdf >> (which would IMO probably be the better discriminator here, >> I'd reformulate this as follows: > > > It is meant in the sense of the REWERSE deliverable m12, and the > heterogeneous option is further explained as splitting the body into > 'resolution' goals and 'constraint' goals, where the latter are > delegated to a decidable solver (e.g., an OWL-DL engine). so, could we slightly rephrase it? >> --> comment axel: I didn't find anything on binding patterns in the >> descriminators, but most systems which support interpreted >> functions support such different binding patterns, >> e.g. that the interpreted function X = Y + Z is used with the >> binding patterns "bfb","bbf","fbb", where "b" stands for >> 'bound' and "f" for 'free'. Probably this should be added in >> the discriminators for interpreted functions? > > Such 'mode declarations' are most useful when interpreted functions > are used but can also be helpful for relations such as to restrict > the invertibility of Prolog's append. However, since modes are an > 'extra-logical' feature, they should go to PRAGMATIC DISCRIMINATORS. > They may be especially useful for specifying partial interchange/ > interoperation: a target system may accept rules only in a submode > (with more "b" arguments) of their definitions in a source system. ok. how would you formulate this discriminator (I guess this could already go into phase 1) >> SES.4.1. VARIABLE-FUL (NON-GROUND) VS. VARIABLE-FREE (GROUND) FACTS >> (ALSO UNDER "FACT-ONLY ... BASES") >> . . . >> --> comment axel: there seems to be an overlap with this >> discriminator with SYN1.2 and SES2.1 > > > It is the same as SES2.1 since these are orthogonal Discriminators > (see also MichaelK's taxonomy lattice). Also overlaps with SYN1.2 not sure whether I understand. If it is the same, why do we need it twice? >> SES.7.1. LABELS ALLOWED VS. NOT ALLOWED AS ARGUMENTS OF USER > > PREDICATES > >> . . . >> --> comment axel: Please clarify this criterion! If you mean named >> attributes in relations, I don't see this as a subcriterion >> of labels for rules. >> What exactly is meant by "user predicates"? > > > This is the basic option to use names of clauses ('labels') as > arguments of predicates in clauses (some systems may also allow: > as arguments of functions). Example (prioritized Nixon diamond): > http://www.w3.org/Submission/SWSF-SWSL/#swsl-rules-courteous > If the 'overrides' predicate of a fact like overrides(rep,qua) is > a "user predicate" in the intended sense, then the definition of > overrides can be specified not only by providing such ground > facts, but also by providing rules, say for a limited form of > 'overrides' transitivity or for conditional overriding. ok, in this sense: [DLV] no [wrl] yes, you can use axiom ids as arguments, but is has no logical extra meaning. --> so we also need to discriminate the semantic implications of such reuse, in the sense you are talking about, it is the extra semantics of the predicate overrides, for example. >> SES.7.2. LABELS ALLOWED VS. NOT ALLOWED AS ARGUMENTS OF >>PRIORITY-GIVING SYSTEM PREDICATE 'OVERRIDES' (CF. SCLP) >> . . . >> --> comment axel: Please clarify this criterion! The current >> formulation seems to suggest a particular framerwork for >> modeling preferences/priorities, while as we see for instance >> in the example there are many options for this. > > If the 'overrides' predicate of a fact like overrides(rep,qua) is > a "system predicate" in the intended sense, then the definition of > 'overrides' can only be specified by ground facts, so hard-coded > axioms for, say, standard transitivity have to be employed. I was referring to the fact, that the current discriminators concerning priority seem to suggest only ONE priority framework where there are several in the literature. I suggest to come up with a classification... would appreciate help on that! >> SEM.1. TERMINATING (ALL QUERIES TERMINATE) VS. NON-TERMINATING (AT >>LEAST ONE QUERY DOES NOT TERMINATE) RULEBASES >> . . . >> --> comment axel: obviously even simple interpreted functions >> can cause non-termination even for a datalog based engine, which >> makes such syntactic restrictions useful. In what way will >> we be able to describe such syntactic restrictions in RIF? >> It is probably important to also be able to exchange >> such syntactic restrictions (which e.g. prohibit certain uses >> of recursvie rules in a formally defined way. > > > Cf. the Eighth International Workshop on Termination (WST 2006): > http://www.cs.mu.oz.au/wst2006 > Annotating rulebases with results of static (termination) analysis > appears to be a good example of using metadata / semantic attributes > (see PHASE 1, section 9., of the F2F2 Preliminary Design Roadmap at > http://lists.w3.org/Archives/Public/public-rif-wg/2006Feb/0255.html). agree. >> PRAG.1.2. INCREMENTAL VS. EXHAUSTIVE >> . . . >> --> comment axel: I am not sure about how this criterion fits to >> forward-chaining but several answer sets. If it concerns the >> strategy of forward-chaining evaluation, then I'd say. However, >> DLV incrementally computes all stable models, >> i.e. incrementally, whereas one could also compute ALL and only >> give the cautious entailments in ALL stable models. > > I meant one-solution-at-a-time (for finite and infinite models) vs. > all-solutions-at-once (for finite models) for backward-chaining, but > it could be broadened to also encompass DLV's approach to incremental > forward-chaining etc. I am not sure whether this is what I maent to say. you can choose between one/all MODELs at a time. >> PRAG.3.2. TEST CASES >> . . . >> --> comment axel: I am not sure what you put here, at least >> "test cases" do not seem to be a proper "discriminator", unless >> you put a set of several practical test caes and ask: "Can this be >> expressed/solved in your rule language/engine?" I.e. the WG should >> provide these test cases derived from these discriminators, yes? > > > Right, the test cases of various systems will be hard to compare, but > the WG could encourage work on an increasing set of shared test cases. agreed. >> PRAG.3.3. MAPPINGS >> . . . >> --> comment axel: ???? I still don't really sure to understand that >> criterion, even after Harold's comment: "Does the system have >> pre-defined mappings between various of it own sublanguages?" >> Please clarify if I misinterpreted this. > > You interpreted it as I had intended: Mapping a language's syntactic > extensions back to its core looks like the most important 3.3.1. case. ok. >> PRAG.3.3.1. WITHIN EXPRESSIVE EQUIVALENCE CLASSES ("CLUSTERS") >> >> --> comment axel: ???? see above. > > See above. :-) >> PRAG.3.3.2. BETWEEN EXPRESSIVE EQUIVALENCE CLASSES (IMPERFECT OR >> "LOSSY") > > >> --> comment axel: ???? see above. I think for some extensions this >> discriminator cannot be answered yes or no. Depends how you >> define lossy/imperfect. > > Let me expand 'lossy/imperfect' to 'with unavoidable information loss': > E.g., mappings from the Horn logic (with Unfixed Function Nesting Depth) > class to the Datalog class entail some unavoidable information loss. > Yet, such approximative mappings may be relevant to prepare partial > interchange/interoperation with another, less expressive, language. ok. Suggest to include this comment for clrification. >> PRAG.3.4. (FURTHER INTEROPERABILITY DISCRIMINATORS SHOULD GO HERE) >> >>--> comment axel: Features, I didn't find a category for: >> >>- preference/priorities of rules: DLV's weak constraint and several >> other ASP extensions supports a certain kind of preference >> definition between rule derivations, which can be adopted in case of >> conflicting conclusions. I'd assume that this is an important feature also >> supported by other rule languages? (P.S.: priorization/preference >> frameworks for rules probably would deserve an own ontology to be >> analyzed in this WG, although for sure not in phase 1) > > This seems to be a different priorization approach than the one in > SES.7.1. yes, that's what I meant to say! RAF shouls also encounter for different priorization approaches and not be fixed to one. >>- Aggregates: In which discriminator do features such as the use of >> aggregates in rule bodies (e.g. sum/avg/max/min) go? (yes, this is >> also probably phase 2) > > The charter's "3.2.6. Knowledge Base Access" primitives as well as > the cwm/SWRL/Forum built-ins and XQuery and XPath Functions and > Operators > (http://www.w3.org/TR/xpath-functions) for arithmetics etc. should be > reconsidered as Discriminators. this could be an approach, yes. axel -- Dr. Axel Polleres email: axel@polleres.net url: http://www.polleres.net/
Received on Wednesday, 24 May 2006 07:33:59 UTC