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

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 Thursday, 26 June 2008 11:54:53 UTC