Re: BLD: Frozen Drafts for Review

> Comments by section, prefixed with A, B, C etc for referencing in any
> discussions:

Thanks, Paul. Unfortunately, I do not know what to do about most of your
comments :-(


> 1. Intro.
> 
> A. I like diagrams, even simple ones, which help annotate the text for
> many "casual" readers. Simple suggestion attached, although I should
> probably make the terminology in this compliant with the doc text...

Diagrams are fine, but I could not understand what you had in mind.
The diagram you sent as an attachment told nothing to me.


> B. There seems to be a bit missing on (as implied by Jos' RDF+OWL doc):
> the fact that RIF covers not just multiple rule types, but also deals
> with multiple data model representations for the terms and facts used in
> the rules. Possibly this is considered "obvious", but not to me. Without
> this reference the intro seems incomplete. [And I see I have compounded
> this by referencing an OWL+RDF RIF dialect in the attached diagram, when
> the RDF+OWL is probably/mostly orthogonal to the rule type eg Horn Logic
> + RDF/OWL, PR + RDF/OWL, etc].

Do you have a concrete proposal for a piece of text?


> C. A thought occurred to me to encourage feedback (if this is a goal),
> an idea used in RUP: make the chapter headings links to mailto to the
> group for that section...
> 
> 2.1.1
> 
> A. I could not relate to the examples like in 2.1.1.2 (but maybe I'm not
> the audience for them!).

Perhaps. In the next iteration this will be split into 2 docs, which should
alleviate the mismatch.


> 2.1.1.1
> 
> A. Shouldn't signature name be defined before the term signature?

Is it not the case?


> B. After reading about arrows a few times I think I got the idea. I
> wonder if the authors might want to consider some simplification or an
> appendix for dummies like me, explaining the rationale for some of the
> definitions? For example: << For defining signatures, we need to
> represent the context of the terms used in signatures, usually in real
> life determined by 1 or more parameters like "John(lives)". To this end
> we describe below the idea of "arrows" to indicate "context" for a term
> when used as a signature.>> Generally things are much easier to
> understand if you have an idea of the motivation.

Yes, this might be useful. As I said, in the next iteration this part will
be split off, and then it will be appropriate to give this kind of
mini-tutorials.

> 
> 2.1.1.4
> 
> A. Comments like <<RIF-BLD requires no extra syntax for declaring
> signatures, since signatures can be inferred. Indeed, RIF-BLD requires
> that each symbol is associated with a unique signature.>> would be nice
> if the "requires" text linked to the section stating the requirement,
> for traceability.

I fail to understand this one. What requirement? This says that there is no
need for this.


> 2.1.2.1
> 
> A. Similar comments as to 2.1.1.1 B. I notice we don't have an
> "Audience" section at the start of the doc. If we did I think it would
> say "Formal Language Specification readers".

When the doc will be split then it will be possible to do this (if the
group decides). Right now things are too much intertwined. This is one of
the reasons why I proposed the split.


> Overall, the general impression was that this was a good model-based
> definition for BLD, and nothing screamed "not implementable for PR".

But this is not for PR!


	cheers
	  --michael  

> 
> Cheers
> =20
> 
> Paul Vincent
> TIBCO | ETG/Business Rules=20

Received on Monday, 22 October 2007 23:12:31 UTC