Re: external frames

On Sat, 27 Sep 2008 13:22:43 +0100
Dave Reynolds <der@hplb.hpl.hp.com> wrote:

> 
> My point was slightly different.
> 
> For your use cases where you go to an external source and query it then 
> it seems to me much better modelling to separate the address from the 
> query components and to have that address be part of the external call.
> 
> So one would have:
> 
> 1.   External(src, P(x,.. y))
> 2.   External(src, o[p->s  .. p'->s'])

I agree. When I designed that I was not thinking how exactly one finds out
where to go to get the answers. I assumed there will be a convention, but an
explicit address is better, I agree.


> Your use cases for frame access seem to be rather better satisfied by a 
> construct like (2) above.

yes.

> In your example you are forced to go to each 
> university whereas I might want to go to a central clearing house, or 
> dbpedia or whatever to query the same information.

For this particular case,
I was thinking about a distributed case with no central address.
But I agree that (2) is more flexible. It makes it easy to define
this use case as centralized and also as a distributed one.


> I agree that frame or predicate form are both reasonable in this case.
> 
> The case of builtins are different. In that case there is no external 
> source to go to and all our current builtins are handled perfectly find 
> as predicates and functions and there seemed to be no use cases for 
> builtin frames.

In general a set of builtins might be implemented externally.
For instance, the first argument could be "local" or something like that.
This would mean to use some known local implementation.


	--michael  


> Dave
> 
> Michael Kifer wrote:
> > Even though a number of people said that they understood the issue, a good
> > example, I think, would help.
> > 
> > CSMA and others raised two issues:
> > 
> > 1. How does one know the address of the external entity to which to send
> >     the external query?
> > 2. Why frames if everything can be encoded with predicates?
> > 
> > 
> > 1. First, even with predicates one cannot know the address of the external
> >    entity to which to send the request. For instance, consider
> >    External(http://a.b.c/d/e/f/g(1,?X)).
> >    Which address should one use? http://a.b.c/d/e/f/g? http://a.b.c/d/e/f?
> >    http://a.b.c/d/e? Or http://a.b.c/somethingelse?
> >    I claim that without a convention it is impossible to know.
> >    With a convention, however, the same applies to frames.
> >    I would say that in case of the frames the convention should be that
> >    it is the object (not the property) that determines the external entity
> >    (as usual in the object-oriented modeling). The rest of the convention
> >    should be the same as in the case of predicates.
> > 
> > 2. Now to an example. Let's suppose that we have a system that all
> >    universities adopt in order to provide a query access to their statistical
> >    and other info. Let's suppose that they adopt a common ontology
> >    so they would use common terms like (where ac is a prefix for the
> >    ontology)
> > 
> >    ac:president
> >    ac:employee_number
> >    ac:budget
> >    ac:department
> >    etc.
> > 
> >    Let suny be the prefix for the State U of NY, uc for Univ of CA, etc.
> >    Each university might put out an object to represent itself and then one
> >    would be able to ask queries like (note the use of terms to simulate
> >    methods):
> > 
> >     // total # of employees in the EE dept + total UC budget
> >    External(uc:berkeley[ac:employee_number(uc:ee)->?Y
> >                         ac:budget->?X])
> > 
> >     // budget of CS dept + SBU President
> >    External(suny:stonybrook[ac:budget(suny:cs)->?X
> >                             ac:president->?X])
> > 
> > 
> >    Now try the same using predicates for comparison.
> >    First, you will notice that you would have to use a whole bunch of
> >    builtins AND two External(...) queries
> >    in each case. In general, one might need to use 3 or more externals.
> >    Second, you might not quite like how the model looks like when you use
> >    predicates. (This is, of course, subjective, but whatever one can say
> >    against the use of frames in External(...) can be also said against the
> >    use of frames in RIF in general and, in fact, against object-oriented
> >    languages as such.)
> > 
> >    
> > 
> > 
> > 	--michael  
> > 
> 
> 
>

Received on Saturday, 27 September 2008 14:29:18 UTC