Re: external frames

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'])

Your use cases for frame access seem to be rather better satisfied by a 
construct like (2) above. 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.

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.

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 12:23:28 UTC