Note that although I am a member of the DAWG working group, the review below reflects only my personal opinion and not necessarily the opinion of DAWG. I am of the opinion that the whole document needs a complete reorganization: Do not first write a long stories of use cases and afterwards point out single features/requirements. The reader looses the overview. Instead: - Enumerate first all the features/requirements of RIF without referring to use cases - Then name the single feature/requirement in the title of the section and make the feature/requirement clear by an use case. In later versions of the document, the use cases should be more worked out! Be more specific, showing rules in different rule languages, their translated intermediate language representation and the translation to the rule language of the partner to which the RIF representation has been transmitted to. Section "Abstract" Please be more specific: Which kind of Use Cases in Phase 1 and which in Phase 2? Where will be the difference in the document? Section "1. Use Cases" If you start reading, it is not clear what is RIF about. Give a more proper introduction. I see two possible ways to realize the RIF: 1) Some kind of intermediate language for rules is provided, which is then exchanged. There are also source-to-source translations from other rule languages to RIF provided. Note that this RIF intermediate language needs only to cover a core set of language constructs, as it is not meant to be extensively used by humans, only by the source-to-source translations. (Or is it another feature of RIF to be human user convenient and thus is a complete language to be used by human users?) 2) Provide a framework, which allows mixed-language support of different rule languages. For a different rule language you just have to download and install a software package, which makes the specific rule run on your machine. The software package implements some kind of standard api so that it can be easily integrated. I guess you will provide a variant of 1): Please state this very early in the document for clarification. Section 1.1: Is there only exchange of the facts or also of the rules itself? Section 1.2: Sometimes the features/requirements overlap with previous features/requirements. Reorganization of the document would improve the readibility. Section 1.7: You could give already examples in OWL-DL and RDF. Also here: First emphasize the requirements, then give the examples. There is no summary/conclusions in the paper. Please add! There are also no references (e.g. to resources of the real-world examples). Please add...