RE: "ground" lists

Thinking this out aloud:

PRD also falls into the "grounded list" category (no unbound variables
in list specifications; for example lists are comparable to Java arrays
or UML associations).

If I wanted to represent in PRD / a production rule engine something
like
"the set of dog, cat, and whatever AuntMabel's pet is" e.g. (dog, cat,
?AuntMabelsPetType) 

I would typically specify that knowledge in the -operations- on that
list:
"is X a dog, cat, or whatever AuntMabelsPet is?"

Rulevar/binding: ?x is any Animal
Condition: ?x == dog || ?x == cat || ?x == auntMabelsPet.type
Action: ...

Or for a more generic set of lists of animals

Rulevar/binding: ?x is any Animal; ?y is any PetList
Condition: ?y.animal.contains( ?x) || ?x == auntMabelsPet.type
Action: ...

Note that from a KR perspective, some BREs also allow you to re-use
declarations and conditions across rules - ie you could specify the
above pattern once for the operation of finding matches in such a list.

So:
1/ I guess the issue of non-grounded lists is more a knowledge
representation issue only for the those RIF dialects concerned with that
2/ I presume the nearest we probably get to non-grounded lists in the
software world would be in "regular expressions".

[ref http://www.perl.com/doc/manual/html/pod/perlre.html ]


Paul Vincent 
+1 650 206 2493 / mobile +44 781 493 7229 

> -----Original Message-----
> From: public-rif-wg-request@w3.org
[mailto:public-rif-wg-request@w3.org]
> On Behalf Of Sandro Hawke
> Sent: 01 May 2009 16:34
> To: Dave Reynolds
> Cc: Jos de Bruijn; RIF
> Subject: "ground" lists
> 
> > Jos de Bruijn wrote:
> >
> > >>>> [*] By the way, is this rule set in RIF Core? During the f2f
> discussion
> > >>>> on "grounded lists" in the core I found it hard to follow on
the
> phone
> > >>>> what people were meaning by grounded lists.
> > >>> No. We were talking about ground lists, and ground=no variables.
> > >> My confusion was whether we meant the resulting lists are ground
> i.e.
> > >> are we just ruling out prolog lists with unbound variables in
them
> or
> > >> blocking all "runtime" construction of lists. You are saying the
> later
> > >> which was my impression also.
> > >>
> > >> In that case Lists are completely useless in Core.
> > >>
> > >> Am I allowed to have a DTB builtin for constructing lists? I
> remember
> > >> this being discussed at the f2f but couldn't follow the argument
> against
> > >> it.
> > >
> > > Yes, you can use the builtins. Because of this the lists are not
> useless
> > > and, also, your system is not guaranteed to terminate.
> >
> > So why the restriction to ground lists? Could we not just define
> safety
> > over List terms analogously to externals?
> >
> > As far as I can see I can translate any usage of List with variables
> to
> > an equivalent using externals:
> >
> >     ... List(?x ?y) ...
> >
> > =>
> >
> >     And( ... ?Z ...,
> >        ?Z = func:insert-before(func:insert-before(List(), 0, ?y),
> 0, ?x))
> >
> > The syntactic restriction to ground List elements doesn't seem to be
> > serving any purpose.
> 
> During the meeting, I understood "ground lists" to mean lists that
> store
> Consts, not unbound Vars.  That is, we decided they should not be like
> Prolog's weird (but fun) lists.  (In Prolog terminology, a ground list
> is one that doesn't have any unbound variables in it; outside of
prolog,
> that's just 'a list', since XPath, Perl, Java, etc, never have unbound
> variables in lists.)
> 
> Beyond that, there's the question about whether the cons operator
> ("List") should be a part of the syntax of the language, or just a
> builtin.  If it's a part of the syntax of the language, should it be
> defined as:
> 
>   LIST ::= 'List(' TERM* ')' | 'List(' TERM+ '|' TERM ')'
> 
> or something like:
> 
>   LIST ::= 'List(' Const* ')' | 'List(' Const+ '|' TERM ')'
> 
> I don't know if anyone really wanted the second form here.  As you
> point
> out, it doesn't really buy you anything, since you can still do what
> you
> want with builtins.  So I hope no one is seriously considering it.
I'm
> not sure where in the state of flux the various documents are now to
> know which view they reflect.
> 
> If this is going to be confusing, I wouldn't be opposed to having
lists
> be purely a DTB and SWC matter; I don't see Core/BLD/PRD needing to
say
> anything about them.  (That said, I'd need some help getting the math
> right in their definition in DTB, if we went that route.)
> 
>      -- Sandro

Received on Friday, 1 May 2009 16:15:38 UTC