W3C home > Mailing lists > Public > public-rif-wg@w3.org > May 2006

Re: [RIF] New diagram with Goals, CSFs, and Requirements

From: Dave Reynolds <der@hplb.hpl.hp.com>
Date: Tue, 30 May 2006 15:01:25 +0100
Message-ID: <447C5035.6010409@hplb.hpl.hp.com>
To: Paula-Lavinia Patranjan <paula.patranjan@ifi.lmu.de>
CC: public-rif-wg@w3.org

Hi Paula,

>> o As already stated I would prefer the third goal to be "Basis for a 
>> future semantic web rules language". This would imply support for 
>> requirements such as: 
>> http://www.w3.org/2005/rules/wg/wiki/Standard_RIF_must_be_able_to_expres_RDF_deduction_rules 
>> which are not currently included.
> First, the third stated goal, 'W3C Consistency', is more general than 
> your proposed goal and it expresses excatly what we need for RIF. 
> Second, I don't think that our goal in this WG is to develop a basis for 
> a future Semantic Web rule language, but to enable interchange between 
> existing  and future (Semantic) Web rule languages (this is different in 
> my opinion).

Agreed, it is different, that's the point. The question for me is 
whether the working group wants this as one of its explicit goals. What 
I hear from many people, though not everyone, is "no". However, I would 
like to get this goal explicitly considered and adopted or ruled out and 
if ruled out I'd like that decision to be written down somewhere in a 
form that can I reference as part of my recommendations back to HP.

> The text below the diagram is not complete yet; that is why the support 
> of RDF deduction rules is missing, but this comes actually under 
> 'Support RDF'. 

OK I'll wait to see that.

>> o 1.1.c Meta language features. I'm unsure about this on several levels.
>> First, why does this appear under "no surprises"? To me it seems only 
>> related to coverage. Second, priorities seem like a different issue 
>> from meta-level rules, perhaps they should be separated. Third, I'm 
>> not convinced that general metalevel rules really fall above the cut 
>> line for us before phase 3. Fourth there needs to be "opposes" links 
>> from this to at least "low cost of implementation"; doesn't this also 
>> make ruleset combination hard?
> Regarding your first comment: Take as an example a set of rules where 
> priorities are used; if through interchange this information is lost 
> then you get a kind of surprise in the sense that 'unexpected' results 
> might be obtained.

That's an argument for "coverage" not for "no surprises".

> Regarding your second comment: You're right, they are different...but at 
> the same time one can consider that they express some meta-level 
> features; so, for keeping the diagram as simple as possible we consider 
> them falling in the same category.


> To your third comment: the proposed DC diagram and the whole work we 
> have done on goals, CSFs, and requirements do  not take the different 
> RIF Phases into consideration.

I wasn't just commenting on phasing but on where the cut line goes. I 
can see that priorities are needed for coverage but am not yet convinced 
that general meta-level rules are within scope for the current charter.

>> o I don't understand the phrasing of 1.1.a Formal Semantics. The text 
>> seems to be about multiplicity of semantics in which case there needs 
>> to be a separate requirement that RIF Core should have a (i.e. at 
>> least one) formal semantics. The phrasing is unclear on whether this 
>> is addressing RIF Core or the sum of RIF dialects, if the proposal is 
>> that the Core should itself not be "unitary" then that needs to spelt 
>> out more clearly so we can argue about it.
>> [Actually, difference between RIF Core and RIF dialects us unclear at 
>> several places in the text.]
> As mentioned above, the DC proposal does not differentiate between 
> different RIF phases or RIF core and dialects. I think it is best 
> leaving this separation for future work, say after taking a decision on 
> the overall DCs. So, the requirement states the need for multiple 
> semantics for RIF but gives no information on which RIF is meant here. 

By the end of the f2f I assume we'll want to be quite clear on what is 
actually in the Core and whether it is a rule language with a single 
semantics, a rule syntax with a set of semantics, or a set of components 
(such as a condition language) from which rule languages can be 
constructed. Perhaps that is mostly design rather than UCR but *if* we 
were to adopt the "basis for a semantic web rule language" as a goal 
then that might support a need for a "unitary" semantics for the core.

> However, I agree that the text needs refinement and I'll do that 
> together with Frank in the next days.

OK, I'll await the new text.

>> o Markup of semantics. I guess I still don't understand what people 
>> mean by this phrase. Is this supposed to be:
>> (a) machine processable definition of the semantics in some general 
>> formalism like an operational semantics?
>> (b) metadata tags attached to symbols to distinguish divergent use of 
>> apparently similar symbols (e.g. ->)?
>> (c) different symbols for constructs with different semantics so that 
>> each symbol is unambiguous?
>> (d) any and all of the above?
> In my opinion, markup of semantics does not refer to the items listed 
> above. This requirement states that there is a means to specify the 
> formal semantics of a rule set to be interchanged so that the system 
> using this rule set through RIF knows about its formal semantics; this 
> does not mean that the algorithm for evaluating the rule set comes with 
> the interchanged rules.


> It might well be just a URI where the 
> specification of the rule set's formal semantics is given. Also, such a 
> formal semantics is to be attached only to rule sets.

That's fine by me and is an example of what I meant by (b).

>> Lesser comments:
>> o Why is "Support XML" linked to "Extensibility"? That doesn't seem 
>> intuitive to me and I couldn't spot the explanation in the narrative.
> I think Frank can explain best this link :)
>> o Conformance model. I've not yet seen an example of when a default 
>> behaviour other than "ignore ruleset" could be used and question the 
>> linking of conformance model to the "default behaviour" proposal 
>> (which currently only has one named champion).
> The conformance model is more general than just 'ignore ruleset'. It 
> also relates to the multiple formal semantics for different rule sets, 
> e.g. in case one needs to combine two rule sets with different 
> semantics. There are also other examples such as interchange between 
> systems supporting priorities for rules and systems without such support 
> where other conformance models than just ignore rules could make sense.

Perhaps I was reading too much into the link to the "default behaviour" 
requirement. I assume there is then a need for someone to edit a page on 
a conformance model requirement.

Received on Tuesday, 30 May 2006 14:01:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:39 UTC