Re: AW: AW: AW: [PRD] ACTION-531 Update PRD examples complete

Adrian,

I did not see that email before I sent my message about the proposed
solutions to the current discussions. Sorry. I hope there is not
contradiction :-(

I will read and reply to your email on Monday.

Cheers,

Christian

Adrian Paschke wrote:

> Christian
> 
> Unfortunately we could not cover PRD in the last telecon and I will travel
> next week. But we need to find more time to talk about PRD. Maybe we could
> establish some additional telecons between you and Gary and me beside the
> RIF telecons (as the plan was that we could assist you as editors of PRD,
> anyway, which is much more efficient than going through the lengthy cycles
> of reviews).
> 
> I think we all agree that the first working draft should be published as
> soon as possible. My proposal is to reach a basic, maximally consensual"
> PRD-Version as FPWD (like we have it for logic dialect with BLD).
> Accordingly, I propose to remove the following critical expressive
> constructs from the FPWD (ordered by my view on how critical and complex
> they are with respect to their semantics):
> 
> - special nested Forall with pattern constraints (section 2.3.1.2)
> - XPath expressions e.g. see Example 2.5 in section 2.1.2.5
> - Execute actions (section 2.2.1.3)
> - support for non-standard built-in types and functions (section 2.1.1.1)
> - typed variables
> - NmNot negations (instead of general Not) (section 2.1.3.5)
> 
> To make clear, all of the above expressive constructs are very useful and
> are needed for many real-word use cases, but we have not sufficiently
> discussed their semantics and their effects on other (including future)
> dialects of RIF, yet. For instance, if we introduce an Execute action it
> might interfere with call to external user-defined functions (procedural
> attachments) in the body of a rule which use External. Another example, if
> we introduce NmNot to denote a special type of negation this would lead to
> many new constructs for different types of negation in different dialects
> (e.g. weak negation, negation-as-finite-failure, default negation, polymorph
> negation, scoped negation...). 
> 
> 
> Further important open questions / issues from my reviews about PRD which
> have not been considered/discussed yet are:
> 
> - "if then [actions]" or "if do [actions]" to denote the action part of a
> production rule? (section 2.3.1.1)
> - Atoms in PRD do not support slots (section 2.1.2.1) (what about the
> classical production rule systems such as OPS5, Jess? For instance, here a
> Jess example with slots "coordinate (x ?x) (y ?y)")
> - "Equal" is not oriented (section 2.1.2.2; see discussion about equal in
> BLD)
> - "NmNot" used (instead of Not) (section 2.1.3.5)
> - "Execute" action instead of reusing "External", e.g. with an attribute
> denoting the external call to a procedural attachment which might have a
> side-effect (section 2.2.1.3)
> - do we use an explicit "And" in the head of a rule for multiple actions or
> simply that that by default we assume conjunction
> 
> 
> The semantics for INSTANTIATE, PICK and FINAL becomes very complex because
> we have highly expressive features such as negation + retract, general
> execute action, etc. 
> What I really want to avoid is that we define a more or less normative
> semantics in our first PRD, which already prevents well-known production
> rule systems to be compliant with the first basic PRD dialect, which is not
> a unifying semantics capable of being extensible with respect to other
> dialects (e.g. reaction rules dialects, logical dialects, other production
> rules dialects), and which might have unforeseen side effects on RIF in
> general. See also my remarks about open PRD issues, e.g. 
> 
> http://lists.w3.org/Archives/Public/public-rif-wg/2008Jun/0168.html
> http://lists.w3.org/Archives/Public/public-rif-wg/2008Jun/0164.html
> http://lists.w3.org/Archives/Public/public-rif-wg/2008Jun/0162.html
> 
> 
> 
> Minor issues are e.g.:
>  
> -think we should refer to original definitions from standard text books for
> the well-described things such as substitution, ground substitution, pattern
> matching, labeled transition systems, classical production rules.
> - I would prefer a writing "w \ {f}" instead of "w-f" to denote the set
> difference, in particular as we also use w ¡È {f}
> - use of symbols in the semantics could be a bit more consistent in the way
> symbols are used from the arabic, greek, ... alphabet, e.g. Term¦² (¦² is
> never introduced; why do we introduce a greek symbold here?; would e.g. make
> sense if we would define ¦² as alphabet of PRD with Term being in the
> signature of PRD denoting the set of all ground terms)
> - Another example, ¦£ and T are hard to distinguish if you print the PRD
> document and don't use a high-resolution printer
> 
> Cheers,
> 
> Adrian
> 
> 
> -----Urspr¨¹ngliche Nachricht-----
> Von: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org] Im
> Auftrag von Boley, Harold
> Gesendet: Mittwoch, 25. Juni 2008 03:30
> An: Gary Hallmark
> Cc: Christian de Sainte Marie; Adrian Paschke; pu >> RIF WG
> Betreff: RE: AW: AW: [PRD] ACTION-531 Update PRD examples complete
> 
> 
> I referred to the "tuple ID" of tuples (ground facts) in the
> "valve" relation. While BLD strictly separates the levels of
> IRIMETA annotations and content, other dialects might try to
> 'amalgamate' (cf. http://citeseer.ist.psu.edu/context/15688/0)
> both levels. Normal IRIMETA usage proceeds from the ID to the
> tuple it is annotating.
> 
> 1. Proceeding from a query to the IDs of matching tuples is
> indeed problematic -- it calls for a non-deterministic Query
> primitive: in my example, Query(?f1 valve(?v open)) would bind
> ?f1 to "http://sample.org/tupleID1"^^rif:iri and ?v to v1001
> (?f1 and ?v coming from the annotation and content level, resp.),
> while Query(?f1 valve(?v ?state)) would even enumerate two
> solutions, incl. two bindings for the 'ID variable' ?f1.
> 
> 2. When we generalize the use of IDs from annotating ground facts
> to annotating (non-ground) rules, our (* ... *) syntax applies
> the ID (an IRI, which cannot be easily 'parameterized' by logic
> variables such as ?x, ?y) to the rule as one (non-ground) term.
> A parameterized non-IRI ID "generated" by a Skolem function would
> go beyond that as in your valveID(?x ?y) example, similar to what
> was discussed earlier for generating objects of frames.
> 
> BTW, coming back to our LC edits, you proposed a _new construct.
> I think Michael's question about it was not answered yet:
> http://lists.w3.org/Archives/Public/public-rif-wg/2008Jun/0089.html
> I'd be in favor of trying to still put it in.
> 
> -- Harold
> 
> 
> -----Original Message-----
> From: Gary Hallmark [mailto:gary.hallmark@oracle.com] 
> Sent: June 24, 2008 7:06 PM
> To: Boley, Harold
> Cc: Christian de Sainte Marie; Adrian Paschke; pu >> RIF WG
> Subject: Re: AW: AW: [PRD] ACTION-531 Update PRD examples complete
> 
> I don't think this works -
> 1. I don't see a way to retrieve the ID in a rule condition
> 2. I don't see a way to assign an ID when the valve predicate is in a 
> rule head and the predicate arguments are variables
> 
> Instead, I think we'd have to translate all n-ary relations to n+1-ary 
> relations and designate the first argument to be the ID "generated" by a
> 
> Skolem function, e.g.
> 
> valve(valveID(?x ?y) ?x ?y) :- And(P(?x) Q(?y))
> 
> Boley, Harold wrote:
> 
>>>It is the "tuple ID" of a matching tuple in the "valve" relation. ...
>>>    
>>
>>. . .
>>  
>>
>>>I don't suppose we can quickly add IDs to BLD relations?
>>>    
>>
>>We are about to finish their introduction as one application of
>>optional IRIMETA (* ... *) annotations for Atoms:
>>
>>Group
>>(
>>  (* "http://sample.org/tupleID1"^^rif:iri *)
>>  valve(v1001 open)
>>
>>  (* "http://sample.org/tupleID2"^^rif:iri *)
>>  valve(v1002 closed)
>>)
>>
>>-- Harold
>>
>>
>>-----Original Message-----
>>From: public-rif-wg-request@w3.org
> 
> [mailto:public-rif-wg-request@w3.org]
> 
>>On Behalf Of Gary Hallmark
>>Sent: June 24, 2008 2:30 PM
>>To: Christian de Sainte Marie
>>Cc: Adrian Paschke; 'pu >> RIF WG'
>>Subject: Re: AW: AW: [PRD] ACTION-531 Update PRD examples complete
>>
>>
>>Christian de Sainte Marie wrote:
>>  
>>
>>>Adrian Paschke wrote:
>>>
>>>    
>>>
>>>>Actually,
>>>>
>>>>?f1 <- (valve ?v open)
>>>>
>>>>in Clips means: Match a valve fact whose first parameter is variable
> 
> 
>>>>?v and
>>>>second parameter is constant 'open'. When you find a match, then ?f1
> 
> 
>>>>is the
>>>>ID of this fact which can be used in the head of a rule to assert
> 
> it,
> 
>>>>      
>>
>>  
>>
>>>>i.e.
>>>>... -> assert(?f1)
>>>>      
>>>
>>>I still do not get it: if ?f1 is a fact, you cannot bind it to a 
>>>variable without reifying it. If it is not, what is it?
>>>    
>>
>>It is the "tuple ID" of a matching tuple in the "valve" relation.  BLD
> 
> 
>>doesn't have such a notion, so we have to decide how to "simulate" it 
>>using either relations or frames.
>>
>>In some cases, the tuple ID is only used to retract the tuple, and so
> 
> a 
> 
>>RIF translator could replace Retract(?f1) with
>>Retract(valve(?v open)).  In general, though, the ID can be used as an
> 
> 
>>object reference to build trees and lists of facts, so in general it 
>>seems one would need to use frames and not relations to model Clips 
>>facts, although this requires frame axioms (additional rules),
> 
> including
> 
>>rules with equality in the head, to make the frames behave as
> 
> "relations
> 
>>with tuple IDs".
>>
>>I don't suppose we can quickly add IDs to BLD relations?
>>
>>  
>>
>>>Or is it the identifier of an object that has several valve
> 
> properties
> 
>>>    
>>
>>  
>>
>>>with value "open" (or "closed", I guess)?
>>>
>>>I mean, rewritten with frames, is it something like this:
>>>
>>>  ?v#valve AND ?v[status->open]
>>>
>>>or is it rather something like that:
>>>
>>>  ?f1[?v->open], where ?v binds to the name of one of ?f1 valve 
>>>properties?
>>>
>>>(thinking aloud: no, it cannot be what you mean, because, then, you 
>>>would assert ?f1[?v->open], not ?f1)
>>>
>>>So, no, I still do not get it :-(
>>>
>>>Why do not you assert valve(?v open)?
>>>
>>>Actually, I do not even understand why you need to assert it: if it 
>>>matches, does not that mean that it has been asserted already?
>>>
>>>(As you see, I do not know CLIPS :-)
>>>
>>>    
>>>
>>>>But, I agree as our goal is to have an uncontroversial minimal PRD
>>>>      
>>
>>which
>>  
>>
>>>>works for all production rule systems and is aligned with BLD, we 
>>>>should not
>>>>include it in the first working draft.
>>>>      
>>>
>>>I do not agree that this is our goal, as you know.
>>>
>>>    
>>
>>
>>  
> 
> 
> 
>

Received on Friday, 27 June 2008 15:32:42 UTC