W3C home > Mailing lists > Public > public-rif-wg@w3.org > May 2009

RE: "ground" lists

From: Paul Vincent <pvincent@tibco.com>
Date: Fri, 1 May 2009 09:14:52 -0700
Message-ID: <A92210407BA7004199621BE5F0AC5D8BE30AF1@NA-PA-VBE04.na.tibco.com>
To: "Sandro Hawke" <sandro@w3.org>, "Dave Reynolds" <der@hplb.hpl.hp.com>
Cc: "Jos de Bruijn" <debruijn@inf.unibz.it>, "RIF" <public-rif-wg@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:08 GMT