W3C home > Mailing lists > Public > public-rif-wg@w3.org > September 2008

Re: external frames

From: Axel Polleres <axel.polleres@deri.org>
Date: Sat, 27 Sep 2008 11:29:10 -0400
Message-ID: <48DE5146.9030907@deri.org>
To: kifer@cs.sunysb.edu
CC: Dave Reynolds <der@hplb.hpl.hp.com>, RIF WG <public-rif-wg@w3.org>

Michael Kifer wrote:
> 
> 
> 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'])

that basically looks more and more like

External( ?t1 ... ?tn )

where ?ti are TERMs. instead of  External( ATOMIC ) or External( Atom )

doesn't it? Anyway, you can wrap this into External ( Atom ) easily, e.g. by

External( call( ?t1 ... ?tn ) )

or whatever.




> 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  
>>>
>>
>>
> 


-- 
Dr. Axel Polleres, Digital Enterprise Research Institute (DERI)
email: axel.polleres@deri.org  url: http://www.polleres.net/

Everything is possible:
rdfs:subClassOf rdfs:subPropertyOf rdfs:Resource.
rdfs:subClassOf rdfs:subPropertyOf rdfs:subPropertyOf.
rdf:type rdfs:subPropertyOf rdfs:subClassOf.
rdfs:subClassOf rdf:type owl:SymmetricProperty.
Received on Saturday, 27 September 2008 15:29:58 GMT

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