Re: Two issues with RIF-Core

Gary Hallmark wrote:
> ok, I can implement quantification over property names using Java
> reflection, so how about
> 
> Frame ::= TERM '[' ((Const|Var) '->'  TERM)* ']'

That doesn't help you because you can still do things like:

     :p ( List(1 2 3) ).
     :s[?x -> 42] :-  :p( ?x ).

What's more even with Const you can have things like:
     :s[1 -> 2].

and you can't have a number as a field/member name in java.

To restrict the types of things that can be slot names that would have 
to go in the semantics rather than the syntax (that was my error in my 
too-quick-reply). E.g. restrict the domain of Iframe to be 
SetOfFiniteBags((Dind - Dlist) x Dind)

My feeling is that to fully implement frames using Java classes you'll 
have to pick an encoding for RIF objects (literal values, IRIs, lists) 
which can map them into legal java names, e.g.:

    Literal_1_http_3A_2F_2Fwww$w3$org_2F2001_2FXMLSchema_23integer

Or you have to represent frames by hashtables[*].

Dave

[*] Actually I the way I'd personally do it would be to have a base "RIF 
Frame" class which supports set(slot, value) and get(slot, value) which 
uses a hashtable as the default. Then have your domain specific classes 
inherit from RIFFrame and override set/get to route the slot names you 
know and care about to the correct field name and let the any others 
default to the hashtable.

> 
> On Fri, May 8, 2009 at 9:13 AM, Dave Reynolds <der@hplb.hpl.hp.com> wrote:
>> Sandro Hawke wrote:
>>>>> 2. PRD and Core allow frame properties to be TERMs, i.e. Frame ::=
>>>>> TERM '[' (TERM '->' TERM)* ']'
>>>>>
>>>>> This is likely to be a problem for most production rule engines. It
>>>>> would be much easier if Frame ::= TERM '[' (Const'->' TERM)* ']'
>>>> Agreed.
>>> I'm not sure this is a good idea.
>>>
>>> Partly for the sake of argument, let me suggest an alternative.  Take
>>> frames out of Core and PRD.  If we restrict frames as you're proposing,
>>> then (as far as I can tell) they don't actually provide any
>>> functionality.  Wherever you were using s[p->o], just use p(s,o).  Why
>>> have two parallel features that provide exactly the same functionality?
>>> As I understood it, the whole point of frames was to allow for
>>> quantifying over predicates.
>>>
>>> Dave, with this change, how would you implement RDFS (etc) rules?
>> Sorry, I was misunderstanding the suggested change and spoke without
>> thinking clearly. Must have been still asleep.
>>
>> I assumed, wrongly, that what Gary was trying to do was to exclude Lists and
>> external functions from frame slots, not stop you using vars to quantify
>> over slot names.
>>
>> You are right, forcing frame slots to be only constants would be too strong
>> and would invalidate their use in RDF.
>>
>> I withdraw my "Agreed" and will go get some more caffeine to see if I can
>> get my brain working again.
>>
>> Dave
>>
>> [Though of course frames are just syntactic sugar for something like
>> rif:triple(s,p,o), they don't provide any added expressivity.]
>>
>> --
>> Hewlett-Packard Limited
>> Registered Office: Cain Road, Bracknell, Berks RG12 1HN
>> Registered No: 690597 England
>>
>>
> 
> 
>

Received on Sunday, 10 May 2009 09:03:26 UTC