Re: [UCR] Proposal for RIF' design constraints hierarchy

Hi Dave,

Find below some comments to your raised issues.

>
> Thanks very much for this, I have three non-trivial comments and a few 
> minor questions/quibbles.
>
> First, this seems to focus on maximizing expressivity. There are a lot 
> of requirements in here covering everything from probabilistic 
> reasoning, to courteous logic to FOL. I don't see anything aimed at 
> narrowing the scope to improve cohesion. For effective interchange 
> there has to be some encouragement to moderate the expressivity of 
> individual dialect to increase the chances of there being reasonably 
> complete implementations of a given dialect.
>

I think that the proposed hierarchy gives the impression of maximizing 
expressivity (at least in part) because there is no distinction between 
RIF Core, Standard and Extensions. Perhaps it would be good to 
concentrate first on the general goals for a rule interchange format and 
then split the critical success factors and the requirements into two: 
Core + Extensions. For the proposed version, I've tried not to leave out 
requirements that have been explicitly posed by use cases or proposed at 
F2F2 or as a design constraint. This is also one of the reasons why the 
proposal doesn't seem to converge to something that could be perhaps the 
RIF to start with. I agree with you that we need to refine this proposal 
with respect to the issue you mentioned.

> Second, I don't see much in here which connects RIF to the web other 
> than the requirement to ingest XML/RDF/OWL. There is no requirement 
> for webization (URIs and all that), no requirement for external access 
> to web data sources (e.g. SPARQL), no overall goal expressed towards 
> make RIF relevant towards rule use on the semantic web.
>

My last comment in the proposal recognizes the fact that the 'webized 
nature of RIF' is still missing in this
hierarchy; however, we need to find a suitable place for this in the 
hierarchy. Do you have a proposal on this?

> Third, the top level division into goals isn't quite intuitive for me. 
> I'm not sure whether this is simply a matter of phrasing to make them 
> read more like goals or whether there is a structural problem here or 
> whether it's just me. For example, 1.3.4 (probabilistic information on 
> propositions) I would have expected to see related to expressivity 
> rather than data sources. I would have thought semantics was needed 
> achieve the interchange goal and don't quite understand why it's a 
> separate goal rather than a CSF for the rule exchange goal.
>
The semantics- and conformance-aware interchange is a separate goal (and 
not under the goal Rules as subject of interchange) to stress the fact 
that these two issues are of high importance for interchange; also, I 
don't see the semantics-aware interchange implied by the fact that what 
we are interchanging are rules. However, I'm not sure whether this is 
really a goal or a critical succes factor for the interchange of rules 
(as I already stated as last comment for goal 2).

> Minor questions/comments:
>
> o A final version presumably will distinguish between the phases 1/2/n.
>
Though hard, I think we need to decide this. :)
> o 1.2 RIF rules are made of RIF component languages ...
>   Not clear what that means. Is it really a CSF? Seems more like a 
> solution we may or may not have chosen than a critical success factor.
>
A component language could be for example the condition language 
proposed by Harold et al. This component language is to be used both as 
body for deductive rules and as C(ondition) part of ECA rules. Another 
component language could be an action language.

This is a CSF determined by the different types of rules and our desire 
of having a RIF with clear design paradigms and easy to understand and 
use. Solutions would be then the concrete component languages.

> o 1.3.4 Support degrees of truth ...
>   That needs more debate.
>
Agree. I will try to find time to do this.
> o 1.4.4 Meta rules for meta reasoning ...
>   This needs rather more definition but is in any case out of place in 
> "Inexpensive representation of rules", it seems more like part of 
> expressivity.
>
Good point, thanks.
> o 2.1.1 Format for specifying the intended interpretation (semantics 
> interchange format)
>   There is a requirement that the semantics intended for a given rule 
> set be clear but not necessarily for a separate "semantics interchange 
> format". Up until now we've talked about some form of metadata tags to 
> indicate the semantics intended and I've presumed that those semantics 
> would be defined in separate (standard) documents and are not 
> themselves directly exchanged. Is this requirement really calling for 
> an interchange format for semantics?
>

You can think of these metadata tags as the format for specifying the 
semantics; my statement abstracts away from any solution to this, it 
just says that there is a need for specifying the semantics a rule set 
uses. I don't know at moment which way to take for realizing this. 
Perhaps, it would be better to reformulate this statement to make it 
more clearer.

> o 2.2.1 Definition of default behavior(s)
>   Not happy with this one but that's because I don't understand what 
> Christian is trying to express here. To me this should be part of the 
> specification of the relevant RIF language construct, not something 
> that "RIF must carry" (which implies per-rule or per-ruleset 
> behaviour). Furthermore, I struggle see cases there are where there 
> can be a behaviour other than "IGNORE_RULESET".
>
I'll try to come up with a concrete example for this; however, I'll be 
happy if Christian or others from the group could also try to find such 
examples.


Regards,
Paula